需求工程練習題

一、選擇題

1. 軟件需求規格說明書的內容不應包括對（ ）的描述。

• A. 主要功能
• B. 算法的詳細過程
• C. 用戶界面及運行環境
• D. 軟件的性能

*正確答案:*B:算法的詳細過程;

2. 需求分析最終結果是產生（ ）

• A. 項目開發計劃
• B. 可行性分析報告
• C. 需求規格說明書
• D. 設計說明書

*正確答案:*C:需求規格說明書;

3. 需求分析中，開發人員要從用戶那里解決的最重要的問題是（ ）

• A. 讓軟件做什么
• B. 要給軟件提供哪些信息
• C. 需求軟件工作效率怎樣
• D. 讓軟件具有何種結構

*正確答案:*A:讓軟件做什么;

4. 需求規格說明書的作用不應包括（ ）

• A. 軟件設計的依據
• B. 用戶與開發人員對軟件要做什么的共同理解
• C. 軟件驗收的依據
• D. 軟件可行性研究的依據

*正確答案:*D:軟件可行性研究的依據;

5. 軟件需求分析階段的工作，可以分成4個方面：需求獲取，需求分析，編寫需求規格說明書以及（ ）

• A. 用戶
• B. 需求評審
• C. 總結
• D. 都不正確

*正確答案:*B:需求評審;

6. 需求驗證應該從下述幾個方面進行驗證：（ ）

• A. 可靠性、可用性、易用性、重用性
• B. 可維護性、可移植性、可重用性、可測試性
• C. 一致性、現實性、完整性、有效性
• D. 功能性、非功能性

*正確答案:*C:一致性、現實性、完整性、有效性;

7. 需求分析階段研究的對象是 （ ）

• A. 用戶需求
• B. 分析員要求
• C. 系統要求
• D. 軟硬件要求

*正確答案:*A:用戶需求;

8. 需求分析階段建立原型的目的是 （ ）。

• A. 確定系統的功能和性能的需求
• B. 確定系統的運行要求
• C. 確定系統是否滿足用戶需求
• D. 確定系統是否滿足開發人員需要

*正確答案:*A:確定系統的功能和性能的需求;

9. 需求分析的目的是保證需求的（ ）。

• A. 目的性和一致性
• B. 完整性和一致性
• C. 正確性和目的性
• D. 完整性和目的性

*正確答案:*B:完整性和一致性;

10. 軟件開發的需求活動，其主要任務是 （ ）

• A. 給出軟件解決方案
• B. 給出系統模塊結構
• C. 定義模塊算法
• D. 定義需求并建立系統模型

*正確答案:*D:定義需求并建立系統模型;

二、填空題

1. 需求分析的步驟 , , , 。

• 正確答案：

  (1) 調查研究 (2) 分析與綜合(3) 書寫文檔(4) 需求分析評審

答案解析：

也可以說：需求獲取、需求分析、文檔編輯、需求驗證

2. 需求分析階段需編寫的文檔有 ， ， 。

• 正確答案：

  (1) 需求規格說明書(2) 初步用戶使用手冊(3) 確認測試計劃

3. 系統規格說明，數據要求， ， ,這四份文檔資料是在書寫文檔階段必需完成的。

• 正確答案：

  (1) 用戶系統描述 (2) 修正的開發計劃

4. 軟件需求的邏輯視圖給出 , 而不是實現的細節。

• 正確答案：

  (1) 數據字典

5. 優秀的需求規格說明應該具備 7個特性,即完整性、正確性、精確性、可行性、必要性、無歧義和 。

• 正確答案：

  (1) 可驗證性

6. 需求分析階段研究的對象是軟件項目的 。

• 正確答案：

  (1) 用戶要求

7. 需求工程突出工程化的思想，強調以________、_________和可重復化的方法與技術進行與軟件需求相關的活動。

• 正確答案：

  (1) 系統化 (2) 條理化

8. 需求是客戶行為在__________內希望看到的效果。

• 正確答案：

  (1) 問題域

9. 非功能需求由___________與_____________構成。

• 正確答案：

  (1) 性能需求 (2) 約束與限制

10. 目標需求限定了項目的_________和項目應達到的_____________。

• 正確答案：

  (1) 范圍 (2) 目標

三、判斷題

1. 需求工程包括需求獲取和需求開發兩個方面。

*正確答案:*錯

2. 需求驗證是需求工程中最后一個活動。

*正確答案:*錯

3. 規格說明是問題域為滿足用戶需求而提供的解決方案,規定了解系統的行為特征。

*正確答案:*錯

4. 業務需求具有明顯的目的性和較高的抽象性,經過明確和細化的處理,可以直接轉化為系統需求。

*正確答案:*錯

5. 需求開發的一些特性決定了需求開發過程只能是一個簡單的線性增量過程。

*正確答案:*錯

6. 嚴格意義上的原型主要被用在需求分析階段。

*正確答案:*對

7. 要完成相同的功能,構建拋棄式原型比構建演化式原型所花費的代價要大得多。

*正確答案:*錯

8. 結構化分析方法適合于數據處理類型軟件的需求分析。

*正確答案:*對

9. 軟件需求描述的是“如何做”，而不是“做什么”。

*正確答案:*錯

10. 軟件需求的層次包括業務需求、用戶需求、功能需求。

*正確答案:*對

四、簡答題

1. 簡述需求工程的主要任務。

• 正確答案：

  需求工程有以下三個主要任務：①需求工程必須說明軟件系統將被應用的環境及其目標,說明用來達成這些目標的軟件功能,還要說明在設計和實現這些功能時上下文環境對軟件完成任務所用方式、方法所施加的限制和約束,也即要同時說明軟件需要“做什么”和“為什么”需要做。②需求工程必須將目標、功能和約束反映到軟件系統中,映射為可行的軟件行為,并對軟件行為進行準確的規格說明。需求規格說明是需求工程最為重要的成果,是項目規劃、設計、測試、用戶手冊編寫等很多后繼軟件開發階段的工作基礎。③現實世界是不斷變化的世界,因此需求工程還需要妥善處理目標、功能和約束隨著時間的演化情況。同時,為了節省開支和進行需求規格說明的重用,需求工程還需要對目標、功能和約束在軟件產品族中的演化和分布情況進行綜合考慮與處理。

2. 簡述常見的需求定義錯誤。

• 正確答案：

  在實踐和研究過程中,人們發現關于需求定義的具體的錯誤主要有以下幾種：**①需求并沒有反映用戶的真實需要。**實踐表明,獲取用戶的真實需求是非常困難的。**②模糊和歧義的需求。**在實踐中,人們總是會有意和無意地寫出模糊和歧義的需求定義。無意中寫出模糊和歧義的需求定義往往是因為選詞造句不當,導致不同的人對同一項需求產生了不同的理解。③信息遺漏。 信息遺漏也是一類常見的問題,包括明顯的信息遺漏和不明顯的信息遺漏。明顯的信息遺漏,其主要原因在于項目的范圍定義不當,可以通過加強對業務需求的處理得以解決。不明顯的信息遺漏,是因為相關信息難以發現,只能靠需求工程師的經驗來加以避免。**④不必要的需求。**產生不必要需求的原因主要是：其一是用戶將一些不必要的需求作為和開發人員談判的籌碼,然后通過自己對不必要需求的要求而在和開發人員的談判當中取得真正想要的利益,例如金錢。對此問題,唯一需要的就是開發人員代表的談判技巧。其二是用戶在交流中,總是害怕信息有所遺漏,并因此產生不利后果,因此用戶總是傾向于表達各種各樣的需要。**⑤不切實際的期望。**不切實際的期望也是實踐中常見的需求定義問題,而且它在很大程度上影響著項目的成敗。面對不切實際的期望,要求軟件開發者提供可行性、成本等足夠的技術參考信息,幫助用戶對其進行取舍和調整。

3. 需求分析階段需要執行哪些活動？

• 正確答案：

  ①問題分析對問題進行分析，定義解決方案②確定系統邊界將所有問題的解決方案進行綜合，就可以得到整個解系統的功能和邊界③需求建模對需求進行建模，完成從問題世界向計算機世界的轉換④需求細化明確用戶需求的隱含信息，展開為明確的對軟件系統的行為期望，即系統需求。⑤確定需求優先級對需求進行分級，保證等級更高的需求得到更多的實現保證⑥需求協商檢測沖突的存在，并提供信息以幫助和引導協商活動的開展

4. 需求規格說明書由哪些部分組成？各部分之間的關系是什么？

• 正確答案：

  軟件需求說明書一般包括如下內容：1）引言部分 編寫目的；項目背景 (應包括：a.項目的委托單位、開發單位和主管部門；b．該軟件系統與其他系統的關系。) ；定義；(列出文檔中所用到的專門術語的定義和縮寫詞的原文。)參考資料。 2）任務概述 目標；運行環境；條件與限制。 3）數據描述 靜態數據；動態數據 (包括輸入數據和輸出數據) ；數據庫描述 (給出使用數據庫的名稱和類型) ；數據詞典；數據采集。 4）功能要求 功能劃分；功能描述。 5）性能需求 數據精確度；時間特性(如響應時間、更新處理時間、數據轉換與傳輸時間、運行時間等)；適應性(在操作方式、運行環境、與其他軟件的接口以及開發計劃等發生變化時，應具有的適應能力。) 6）運行需求 用戶界面(如屏幕格式、報表格式、菜單格式、輸入輸出時間等)；硬件接口；軟件接口；故障處理。 7）其他要求 如可使用性、安全保密、可維護性、可移植性等。 8）附錄

需求建模方法與技術

一. 單選題（共10題，100分）

1. (單選題)（ ）用于描述數據的處理過程。

• A. 數據字典
• B. 決策樹
• C. 決策表
• D. 數據流圖

*正確答案:*D:數據流圖;

2. (單選題)需求驗證應該從下述幾個方面進行驗證：（ ）

• A. 可靠性、可用性、易用性、重用性
• B. 可維護性、可移植性、可重用性、可測試性
• C. 一致性、現實性、完整性、有效性
• D. 功能性、非功能性

*正確答案:*C:一致性、現實性、完整性、有效性;

3. (單選題)面向對象技術中，對象是類的實例。對象有三種成分（ ）、屬性和方法（或操作）。

• A. 標識
• B. 規則
• C. 封裝
• D. 消息

*正確答案:*A:標識;

4. (單選題)在原型法中，開發人員根據（ ）的需求不斷修改原型，直到滿足客戶要求為止。

• A. 用戶
• B. 開發人員
• C. 系統分析員
• D. 程序員

*正確答案:*A:用戶;

5. (單選題)常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向對象的分析方法（OOA），下列( )不是結構化分析方法的圖形工具。

• A. 決策樹
• B. 數據流圖
• C. 數據字典
• D. 快速原型

*正確答案:*D:快速原型;

6. (單選題)下列軟件開發模型中，（??）只有在開發人員具有風險分析和排除風險的經驗及專門知識時，才能獲得成功。

• A. 原型模型
• B. 瀑布模型
• C. 噴泉模型
• D. 螺旋模型

*正確答案:*D:螺旋模型;

7. (單選題)從瀑布模型看，在它的生命周期中的八個階段中，下面的幾個選項中哪個環節出錯，對 軟件的影響最大（????）。

• A. 詳細設計階段
• B. 概要設計階段
• C. 需求分析階段
• D. 測試和運行階段

*正確答案:*C:需求分析階段;

8. (單選題)傳統的（????）要求，必須等前一階段的工作完成之后，才能開始后一階段的工作；前 一階段的輸出文檔，就是后一階段的輸入文檔。

• A. 原型模型
• B. 瀑布模型
• C. 螺旋模型
• D. 噴泉模型

*正確答案:*B:瀑布模型;

9. (單選題)需求獲取中常見的困難不包括下列哪個( )。

• A. 用戶越俎代庖
• B. 知識理解困難
• C. 用戶存在認知困境
• D. 模型建立

*正確答案:*D:模型建立;

10. (單選題)建立需求基線的作用不包括（ ）。

• A. 防止需求的濫變給程序架構造成重大影響
• B. 為開發工件提供了一個定點和快照
• C. 可以拓展應用
• D. 可以重新建立基于某個特定發布版本的配置

*正確答案:*C:可以拓展應用;

二. 填空題（共8題，100分）

1. (填空題)軟件開發的生命周期包括（ ）、設計、編碼、（ ）、（ ）、維護，共六個階段。

• 正確答案：

  (1) 需求分析和定義;需求分析(2) 測試(3) 運行

2. (填空題)在軟件開發中，使用原型時可采取兩種不同的策略，即：（ ）策略和（ ）策略。

• 正確答案：

  (1) 廢棄(2) 進化;追加

3. (填空題)數據流圖和數據字典共同構成了系統的 模型，是需求規格說明書的主要組成部分。

• 正確答案：

  (1) 邏輯

4. (填空題)通常來說,如果用戶需求出現了模糊、不清晰、不完整等具有一定不確定性的特征,就可以考慮使用_____________。

• 正確答案：

  (1) 原型法

5. (填空題)模型語言的三要素：語法、語義、語用。其中_______給出了一個模型元素描述的更寬廣的上下文,以及影響該模型元素意義的約束和假定。

• 正確答案：

  (1) 語用

6. (填空題)UML行為模型的_______是依據處理流程進行的用例實現。

• 正確答案：

  (1) 活動圖

7. (填空題)UML行為模型的________通常描述的是單個用例的典型場景。

• 正確答案：

  (1) 交互圖

8. (填空題)需求基線的維護主要包括配置管理和____________。

• 正確答案：

  (1) 狀態維護

三. 判斷題（共10題，100分）

1. (判斷題)需求驗證并不是一個可以一次結束的活動,它可能需要多次、反復地執行驗證。

*正確答案:*對

2. (判斷題)數據流圖中每個加工至少有一個輸入數據流，但可以沒有輸出數據流。

*正確答案:*錯

3. (判斷題)業務規則包括企業方針、政府條例、工業標準、會計準則和計算方法等。業務規劃本身就是軟件需求。

*正確答案:*錯

4. (判斷題)需求工程包括需求獲取和需求開發兩個方面。

正確答案:*錯

5. (判斷題)需求開發的一些特性決定了需求開發過程只能是一個簡單的線性增量過程。

*正確答案:*錯

6. (判斷題)軟件需求分析的關鍵是為真實世界的問題建立模型,即問題域建模。

*正確答案:*對

7. (判斷題)軟件成功的標準是用戶在用，并且可以很容易做完要做的事。

*正確答案:*對

8. (判斷題)獲取需求活動的展開只要保證項目的范圍，可以有需求遺漏。

*正確答案:*錯

9. (判斷題)在軟件生命周期中，工程量最大的階段就是編寫程序。

*正確答案:*錯

10. (判斷題)開發人員和客戶對軟件質量因素的認可是完全一致的。

*正確答案:*錯

四. 論述題（共2題，100分）

1. (論述題)如何有效的處理需求的變化是很多現代軟件開發技術的主題，請從需求變更的原因，一般過程以及控制對策等方面談談你的看法。

• 正確答案：

  需求變更的原因有：①問題放生了改變 ②環境發生了改變 ③需求基線存在缺陷另一些因素：用戶變動，用戶對軟件的認識變化，相關產品的出現一般過程：看書；在形成需求基線之后，進行需求的變更控制看法根據書上內容然后展開。

2. (論述題)簡述軟件開發中為何使用原型工具以及使用的好處。

• 正確答案：

  因為原型是在最終系統產生之前的一個局部真實表現,所以原型方法可以讓人們在系統的開發過程中,就能夠對一些具體問題進行基于實物的有效溝通,從而幫助人們盡早解決軟件開發過程中存在的各種不確定性。不確定性是指人們已經擁有的知識是不充分的,不足以預測將來的事件發展,或者不足以清晰、準確地描述某個事物。實踐證明,利用原型有如下好處：①及時、有力地響應用戶需求的變化。②減少返工。③幫助控制不完整需求所帶來的風險。16 ④可以將一個大的難以處理的開發過程細分成一些更小更容易處理的步驟。⑤減少開發成本,提高經濟效益。⑥增加開發者之間的交流,幫助確定技術解決方案的可行性。⑦有效地識別風險和解決風險,幫助進行風險管理。⑧提高用戶在軟件開發中的參與程度。

需求獲取課后習題

一. 填空題（共6題，30分）

1. (填空題)需求開發計劃的基本任務是確定需求開發的________________，給出收集需求活動的具體__________和_________。

• 正確答案：

  (1) 實施步驟

  (2) 安排

  (3) 進度

2. (填空題)需求獲取得到的信息和需求開發應該建立的軟件系統解決方案之間有著很大的差距。________________就是用來解決這個差距的需求工程活動。

• 正確答案：

  (1) 需求分析

3. (填空題)______________是從人、文檔或者環境當中獲取需求的過程，需求工程師必須要利用各種方法和技術來“發現”需求。

• 正確答案：

  (1) 需求獲取

4. (填空題)確定項目目標與范圍階段的基本任務是把項目相關人員定位到一個共同的和明確的_____上，并決定軟件系統的______。

• 正確答案：

  (1) 方向

  (2) 范圍

5. (填空題)項目的目標主要包括軟件開發的_______________，以及軟件系統應實現的_____________。

• 正確答案：

  (1) 目的和意義

  (2) 目標（即目標需求）

6. (填空題)實地調查人員通常分為三步________________、__________________以及______________________進行。

• 正確答案：

  (1) 向掌握“全局”的負責人調查

  (2) 向部門負責人調查

  (3) 向業務人員調查

二. 單選題（共6題，30分）

7. (單選題)用例之間的關系主要有（ ）三種。

• A. 包含、擴展和簡化
• B. 合取、析取和擴展
• C. 包含、多態和繼承
• D. 包含、擴展和泛化

*正確答案:*D:包含、擴展和泛化;

8. (單選題)項目前景與范圍文檔中，項目前景不應包括什么信息（ ）。

• A. 前景概述
• B. 詳細的功能需求
• C. 主要特性
• D. 假設與依賴

*正確答案:*B:詳細的功能需求;

9. (單選題)下列不屬于需求開發的活動的是( )。

• A. 需求獲取
• B. 需求管理
• C. 需求驗證
• D. 需求分析

*正確答案:*B:需求管理;

10. (單選題)需求獲取的成果（ ）。

• A. 獲取筆錄、錄音或攝像
• B. 客戶
• C. 需求規格說明文檔
• D. 設計說明書

*正確答案:*A:獲取筆錄、錄音或攝像;

11. (單選題)采用觀察方法進行需求獲取的原因（ ）。

• A. 用戶多
• B. 客戶變化
• C. 事件的情景性
• D. 存在默認知識

*正確答案:*C:事件的情景性;

12. (單選題)需求跟蹤是（ ）中的一個活動。

• A. 需求獲取
• B. 需求驗證
• C. 需求分析
• D. 需求管理

*正確答案:*D:需求管理;

三. 判斷題（共4題，20分）

13. (判斷題)用例的內容只能包含有正常流程,而不能包含有異常流程。

*正確答案:*錯

14. (判斷題)發起或觸發用例的外部用戶以及其他軟件系統等角色被稱為參與者。

*正確答案:*對

15. (判斷題)在需求不明確時，若找不到決策者，開發人員可以進行決定。

*正確答案:*錯

16. (判斷題)獲取需求活動的展開只要保證項目范圍，可以有需求遺漏。

*正確答案:*錯

四. 簡答題（共4題，20分）

17. (簡答題) 需求獲取分為哪幾個階段？

• 正確答案：

  1、確定需求開發計劃；2、確立項目的目標和范圍；3、確定調查對象；4、實地收集需求信息；5、確定非功能需求。

18. (簡答題)確定項目范圍的好處是？

• 正確答案：

  1、可以判斷用戶所提出的需求信息是否對項目合適；2、有些用戶需求信息可能是建議，這些建議是項目之外的，但可能有價值，因此可以改變項目范圍適應這樣的需求，但要考慮對進度、資金的影響。

19. (簡答題)實地收集需求信息時通常會遇到怎樣一些困難？

• 正確答案：

  1、能提出軟件需求的用戶可能覺得沒有時間與開發人員進行交流和討論；2、有時用戶希望通過簡單的方法與說明，或者通過簡單的回答開發人員的詢問后，軟件開發人員就能清楚理解他們的需求，而不需要花費太多的時間進行討論；3、用戶和開發人員只考慮自己的利益；4、用戶本身不能提出明確的需求；5、開發人員沒有相關的業務知識。

20. (簡答題)按照需求的層次，怎樣進行用戶分類？

• 正確答案：

  1、提出目標需求的用戶；2、提出業務需求和功能需求的用戶；3、軟件開發人員，主要是指系統分析員。

需求分析課后題

一. 單選題（共6題，42.6分）

1. (單選題)需求分析的目的是保證需求的（ ）

• A. 目的性和一致性
• B. 完整性和一致性
• C. 正確性和目的性
• D. 完整性和目的性

*正確答案:*B:完整性和一致性;

2. (單選題)分析的活動主要包括識別、定義和結構化,它的目的是獲取某個可以轉換為知識的事物的信息,這種分析活動被稱為（ ）。

• A. 需求信息獲取
• B. 建立軟件系統解決方案
• C. 需求信息轉化
• D. 建立需求分析模型

*正確答案:*D:建立需求分析模型;

3. (單選題)（ ）是建模最為常用的兩種手段。

• A. 具體和抽象
• B. 抽象和分解
• C. 分解和細化
• D. 抽象和細化

*正確答案:*B:抽象和分解;

4. (單選題)抽象通過強調本質的特征,（ ）了問題的復雜性。

• A. 調整
• B. 避免
• C. 增加
• D. 減少

*正確答案:*D:減少;

5. (單選題)系統關聯圖描述系統與外部實體之間的（）,并確定了接口的信息流和物質流。

• A. 界限與外觀
• B. 邊界和環境
• C. 界限和接口
• D. 輸入和輸出

*正確答案:*C:界限和接口;

6. (單選題)UML使用的行為模型有三種,即：（ ）。

• A. 交互圖、狀態圖和順序圖
• B. 順序圖、通信圖和時間圖
• C. 交互圖、狀態圖和活動圖
• D. 交互概述圖、通信圖和時間圖

*正確答案:*C:交互圖、狀態圖和活動圖;

二. 填空題（共4題，28.6分）

7. (填空題)需求獲取得到的信息和需求開發應該建立的軟件系統解決方案之間有著很大的差距。______________就是用來解決這個差距的需求工程活動。

• 正確答案：

  (1) 需求分析

8. (填空題)需求分析的根本任務是：建立______________并創建解決方案。

• 正確答案：

  (1) 分析模型

9. (填空題)建立__________________主要是根據需求獲取階段確定的系統范圍，用圖形表示系統與外部實體間的關聯。

• 正確答案：

  (1) 系統關聯圖

10. (填空題)分析需求可行性的基本任務是在允許的___________________以及系統的范圍內，分析每項需求得以實施的________。

• 正確答案：

  (1) 成本和性能要求

  (2) 可能性

三. 名詞解釋（共2題，14.4分）

11. (名詞解釋)需求分析：

• 正確答案：

  需求分析是利用建模與分析技術對獲取筆錄的內容進行明確、整理、匯總,建立一個綜合考慮問題域特性和需求的系統模型,然后根據系統模型將用戶需求轉化為系統需求的需求工程活動。

12. (名詞解釋)范圍（scope）：

• 正確答案：

  范圍指出當前項目是要解決產品長遠規劃中的哪一部分,范圍聲明它為項目劃定了需求的界線。

四. 簡答題（共2題，14.4分）

13. (簡答題)請說明為何要確定需求的優先級。

• 正確答案：

  在理想的情況下,開發者應該讓最終的軟件系統完美地滿足用戶提出來的所有需求。但是這種理想的情況并不總是會在現實中發生,甚至是很少在現實中發生。作為一項工程,軟件開發總是在一定的環境限制下進行的,成本效益比是它成功的一個基本衡量標準。因此,在工程環境下,需求與需求之間并不是同等重要的,一些需求應該優于另一些需求得到更多 在實踐中,確定優先級的活動尤為重要的情況有：①一個項目的資源（時間、人力、成本等）有限,無法滿足用戶的所有需求。此時項目管理者就需要確定一種最佳方案,在既定的成本下取得最大的效益。需求優先級就是項目管理者進行此項工作的重要基礎。②項目采用了分階段的開發方式。為了最大化地體現項目的成本效益,項目應該在第一階段就交付用戶最重要和最緊急的需求,并將用戶最不重要和最不緊急的需求放在開發的最后一個階段。這就需要通過確定需求優先級的方式來劃分需求的重要性和緊急性等級。③在項目的開始階段,并不能明確所有的用戶需求,或者無法保證會最終滿足所有的用戶需求。這個情況是實踐中最為常見的情況,迭代式的開發基本都屬于這種情況。對這種情況,要區分用戶需求的優先級,優先迭代級別高的需求,保證項目最終最大程度地滿足了用戶的需求。

14. (簡答題)需求分析的具體工作包括：

• 正確答案：

  1、建立系統關聯圖；2、分析需求的可行性；3、構建用戶接口原型；4、確定需求的優先級；5、需求建模；6、建立數據字典。

結構化分析方法課后練習

一. 單選題（共4題，57.1分）

1. (單選題)數據建模技術能夠彌補過程建模在（ ）方面的缺陷,它描述數據的定義、結構和關系等特性。

• A. 需求分析
• B. 需求轉換
• C. 數據說明
• D. 數據分析

*我的答案:*C:數據說明;*正確答案:*C:數據說明;

2. (單選題)（ ）是結構化分析方法的核心技術,它表明系統的輸入、處理、存儲和輸出,以及它們如何在一起協調工作。

• A. 數據流圖DFD
• B. 實體聯系圖ERD
• C. 狀態轉換圖
• D. 上下文圖

*正確答案:*A:數據流圖DFD;

3. (單選題)抽象通過強調本質的特征,（ ）了問題的復雜性。

• A. 調整
• B. 避免
• C. 增加
• D. 減少

*正確答案:*D:減少;

4. (單選題)DFD的基本符號不包括下列哪種（ ）

• A. 數據字典
• B. 加工
• C. 外部實體
• D. 數據存儲文件

*正確答案:*A:數據字典;

二. 簡答題（共2題，28.6分）

5. (簡答題)簡述使用 DFD描述系統過程模型是必須遵守哪些規則。

• 正確答案：

  使用 DFD描述系統過程模型是必須遵守一些規則,這些規則可以保證過程模型的正確性。這些規則有：①過程是對數據的處理,必須有輸入,也必須有輸出,而且輸入數據集和輸出數據集應該存在差異。如果過程在沒有輸入的情況下產生了輸出,稱之為“奇跡”,即輸出數據在沒有任何可見來源的情況下就奇跡般產生了。如果過程接收了數據輸入卻沒有產生輸出,稱之為“黑洞”。它浪費了輸入的數據資源,卻沒有做出應有的貢獻。過程是對數據的處理,這種處理是要產生附加價值的,即進行了數據的加工和變換,而不是簡單的數據轉移。②數據流是必須和過程產生關聯的,它要么是過程的數據輸入,要么是過程的數據輸出。③DFD當中所有的對象都應該有一個可以唯一標識自己的名稱。過程使用動詞,外部實體、數據流和數據存儲使用名詞。

6. (簡答題)請說明 DFD層次結構的建立的主要步驟。

• 正確答案：

  DFD層次結構的建立的主要步驟是：①創建上下文圖。②發現并建立 DFD片斷。③根據 DFD片斷組合產生 0層圖。④對 0層圖的過程進行功能分解,產生 N層圖。

三. 其它（共1題，14.3分）

7. (其它)請按下列描述,畫出“食物訂貨系統”的過程模型圖（DFD）。 食物訂貨系統主要和 3種外部的實體：顧客、管理者和廚房存在交互行為。首先,食物訂貨系統需要接收顧客的食物訂單,并在接收后向顧客呈送一個收條,然后將訂單轉交系統內部的功能處理。其次,食物訂貨系統要能夠將已經接收的食物訂單及時的轉交給廚房,這樣廚房才能夠根據訂貨的情況進行生產。最后,食物訂貨系統要能夠基于一段時間的事務積累,為管理者提供管理報表,反映組織的生產狀況。 食物訂貨系統的內部功能主要有 4個。第一個功能是接收顧客的食物訂單,向顧客呈送收條,并將訂單及時轉交廚房,同時啟動對訂單的后續處理（第二個功能和第三個功能）。第二個功能是處理顧客食物訂單,根據訂單生成并記錄食物的銷售事務。第三個功能也是處理顧客食物訂單,但其目的是根據訂單更新庫存信息,以保證生成的原材料供應。第四個功能是根據一段時間內的食物銷售情況和庫存管理情況,生成管理報表,向管理者反映組織的生產狀況。 在食物訂貨系統中,食物銷售記錄和庫存記錄是為了完成系統的功能（產生管理報表）,組織希望儲存的數據。

• 正確答案：

  參考答案：

需求分析技術

一、選擇題（每題2分，共10分）

1. 設定需求優先級的主要目的是什么？
   A. 幫助開發團隊更好地理解需求
   B. 確定首發版中必須包括的需求與可以延后的需求
   C. 增加客戶的參與度
   D. 提高開發團隊的工作效率

2. 在設定需求優先級時，以下哪種方法是基于價值、費用和風險的優先級設定方法？
   A. 三類優先級劃分法
   B. 質量功能開發(QFD)
   C. 完全質量管理(TQM)
   D. B和C都是

3. 風險危害值的計算方式是什么？
   A. 風險發生的可能性+潛在損失的規模
   B. 風險發生的可能性×潛在損失的規模
   C. 風險發生的可能性-潛在損失的規模
   D. 風險發生的可能性÷潛在損失的規模

4. 需求優先級計算公式中，以下哪項表述是正確的？
   A. 優先級 = 總價值 / (相對費用 + 相對風險)
   B. 優先級 = 總價值 × (相對費用 + 相對風險)
   C. 優先級 = 總價值 × (相對費用 × 相對風險)
   D. 優先級 = 相對費用 / 總價值

5. 以下哪項不屬于需求獲取階段的風險？
   A. 產品視圖與范圍不清
   B. 需求優先級劃分不當
   C. 客戶對產品需求意見不一致
   D. 未明確說明的隱含需求

6. B（確定首發版中必須包括的需求與可以延后的需求）

7. D（B和C都是）

8. B（風險發生的可能性×潛在損失的規模）

9. A（優先級 = 總價值 / (相對費用 + 相對風險)）

10. B（需求優先級劃分不當，屬于需求分析階段的風險）

二、填空題（每題2分，共10分）

1. 設定需求優先級的一般方法是將需求分成________類。

2. 質量功能開發(QFD)和完全質量管理(TQM)是兩種用于________的方法。

3. 風險管理就是使用某些工具或步驟把項目風險限制在一個________范圍內。

4. 需求開發工作應占全部工作量的約________%。

5. 在升級或重做的項目中，開發人員不得不通過現有產品的________來獲取需求。

6. 三

7. 設定需求優先級

8. 可接受的

9. 15

10. 逆向工程(reverse engineering)

三、判斷題（每題2分，共10分）

1. 設定需求優先級是開發者的責任。（ ）

2. 風險無處不在，因此項目管理者應該具有風險意識并采取預防措施。（ ）

3. 編寫風險文檔和制定風險管理計劃是同一回事。（ ）

4. 需求規格說明中，應說明"做什么"而不是"怎么做"。（ ）

5. 用戶積極合作參與可以顯著減少需求變更的發生。（ ）

6. ×（設定需求優先級是客戶的責任之一）

7. √

8. ×（編寫風險文檔和制定風險管理計劃是兩個不同的活動）

9. √

10. √

四、簡答題（每題10分，共30分）

1. 簡述設定需求優先級的步驟。

2. 解釋風險條目跟蹤模板中各要素的含義及作用。

3. 列舉并簡要說明需求獲取階段可能面臨的風險。

4. 設定需求優先級的步驟：

   • 列出要設定優先級的所有需求、特性或使用實例

   • 估計每個特性提供給客戶或業務的相關利益-價值(1-9分)

   • 估計如果沒有實現該特性將帶來的損失(1-9分)

   • 計算總價值(相對利潤和相對損失的總和)

   • 估計實現每個特性的相對費用(1-9分)

   • 估計與每個特性相關的技術風險程度(1-9分)

   • 計算每個特性的優先級(優先級=總價值/(相對費用+相對風險))

   • 按優先級降序排列特性列表

5. 風險條目跟蹤模板要素含義及作用：

   • 序列號：為風險提供唯一標識

   • 確定日期：記錄風險被識別出的日期

   • 撤消日期：記錄風險被解決或撤銷的日期

   • 描述：以"條件-結果"的形式描述風險

   • 可能性：表示風險轉變為問題的概率

   • 影響：描述如果風險變成事實將造成的損失

   • 危害值：可能性×影響，用于評估風險的嚴重程度

   • 降低風險計劃：控制、避免或最小化風險的方法

   • 負責人：解決風險的責任承擔者

   • 截止日期：完成降低風險措施的時間限制

6. 需求獲取階段可能面臨的風險：

   • 產品視圖與范圍不清：沒有對產品功能達成清晰共識

   • 需求開發時間不足：因項目緊張而壓縮需求開發時間

   • 需求規格說明不完整或不正確：導致開發方向錯誤

   • 革新產品的需求獲取困難：缺乏市場反饋信息

   • 非功能需求不明確：過于關注功能性需求而忽略非功能性需求

   • 客戶對需求意見不一致：不同客戶有不同期望

   • 未明確說明的隱含需求：客戶有未表達的期望

   • 將已有產品作為需求基線：通過逆向工程獲取需求的不足

   • 用戶給出期望的解決方案：掩蓋了實際需求

五、論述題（每題20分，共40分）

1. 結合實際項目經驗，論述如何有效地進行需求變更管理以降低項目風險。

2. 分析需求優先級設定與風險管理之間的關系，并探討如何將兩者結合以提高軟件項目的成功率。

3. 需求變更管理與項目風險降低：

需求變更是軟件項目中不可避免的現象，有效的變更管理對降低項目風險至關重要。首先，應建立正式的變更控制流程，包括變更請求記錄、影響分析、評審、批準和實施追蹤等環節。其次，將項目視圖與范圍文檔作為變更的參照基準，可以有效控制項目范圍蔓延。

實踐中，可采用以下策略降低需求變更帶來的風險：
(1) 促進用戶積極參與：研究表明，用戶積極合作參與可把需求變更減少近一半。應在項目早期就讓客戶代表參與需求獲取和驗證過程。
(2) 實施早期質量控制：通過需求評審、原型驗證等方式早期發現需求錯誤，可減少后期變更的可能性。
(3) 靈活的設計和實現：對于易變的需求，可采用多種方案實現，并在設計時注重可修改性。
(4) 建立變更管理的紀律和氛圍：成立變更控制委員會，使用變更管理工具，確保變更過程的規范化。
(5) 采用增量式開發：對階段遞增式的生存期制定計劃，在早期版本中實現核心功能，并在后續階段逐步增加實現需求。

2. 需求優先級設定與風險管理的關系：

需求優先級設定與風險管理是軟件項目管理中密切相關的兩個方面，它們的結合可顯著提高項目成功率。

首先，需求優先級設定本身就是一種風險管理策略。通過識別高價值、低風險的需求優先實現，可以確保項目在有限資源條件下交付最有價值的功能，降低項目失敗的風險。當項目環境發生變化或者資源受限時，可以基于優先級決定哪些需求可以延后或刪除，從而保證項目的關鍵目標能夠實現。

其次，風險管理可以為需求優先級設定提供重要參考。在評估需求優先級時，除了考慮業務價值外，還需考慮實現風險。通過風險分析，可以識別出哪些需求實現難度大、技術風險高，這些信息直接影響需求的優先級計算。例如，在優先級計算公式中，風險是與費用一起作為分母項存在的，風險越高，優先級越低。

兩者結合的有效策略包括：
(1) 使用基于價值、費用和風險的優先級設定方法，如QFD或TQM，確保對需求的全面評估。
(2) 建立需求與風險的關聯矩陣，識別哪些需求可能帶來高風險，并制定相應的風險緩解計劃。
(3) 采用增量式開發方法，將高優先級、低風險的需求安排在早期迭代中實現，高風險需求則安排在后期迭代，以便有更多時間進行風險評估和緩解。
(4) 定期回顧和調整需求優先級，響應新發現的風險和項目環境變化。
(5) 與客戶密切合作，確保優先級設定和風險評估反映業務實際情況。

需求驗證課后練習題

一. 填空題（共6題，37.2分）

1. (填空題)需求驗證嚴格地說就是檢驗軟件（ ）。

• 正確答案：

  (1) 需求規格說明

2. (填空題)需求驗證非常重要，其能（ ）需求規格說明書存在的問題，并避免在軟件系統設計和實現時出現返工。

• 正確答案：

  (1) 發現和修復

3. (填空題)需求驗證要求各方人員從不同的技術角度對需求規格說明文檔做出（ ）評價。

• 正確答案：

  (1) 綜合性

4. (填空題)需求評審分為（ ），正式評審兩類。

• 正確答案：

  (1)非正式評審

5. (填空題)需求評審的工作就是評審（ ）的內容，發現其中的不確定性和二義性要求等。

• 正確答案：

  (1) 需求規格說明

6. (填空題)（ ）是指使用圖形，圖像或者圖片等技術，使一些不可見的對象、表達或者抽象概念變成可見的符號。

• 正確答案：

  (1) 可視化

二. 簡答題（共4題，25分）

7. (簡答題)需求驗證包含哪些活動？

• 正確答案：

  1、軟件需求規格證明是否正確描述了目標系統的行為和特征；2、從其它來源中（包括硬件的系統需求規格說明書）得到軟件需求；3、需求是完整的和高質量的；4、所有人對需求的看法是一致的；5、需求為進一步的軟件開發和測試提供了足夠的基礎。

8. (簡答題)審查人員由哪些人員組成？

• 正確答案：

  1、從事軟件系統需求開發的相關人員；2、具有編寫需求規格說明經驗和知識的人員，以及具有評審工作經驗的領域專家等；3、客戶或同戶代表，他們可以保證需求規格說明能正確地和完整的描述他們的需求；4、將依據需求規格說明開展工作的軟件開發人員，如設計人員，測試人員，項目經理等。

9. (簡答題)審查清單可以列舉哪些問題？

• 正確答案：

  (1) 需求是否完整？ (2)需求是否一致？(3)需求是否可理解？ (4)需求是否明確？(5)需求是否可實現？ (6)需求是否可跟蹤？(7)需求是否易于修改？ (8)需求規格說明文檔是否完整？

10. (簡答題)需求評審面臨的困難有哪些？

• 正確答案：

  1、開發人員最重要的是后面的開發工作，從而導致需求評審成為“走過場” ;2、需求評審的工作量大；3、過大的評審小組。

三. 單選題（共6題，37.8分）

11. (單選題)下面（ ）不屬于需求驗證內容。

• A. 一致性
• B. 完整性
• C. 驗證性
• D. 現實性

*正確答案:*C:驗證性;

12. (單選題)目前驗證需求的方法除（ ）外，主要靠人工技術審查和驗證軟件需求規格說明。

• A. 結構化方法
• B. 形式化方法
• C. 面向對象方法
• D. 自然語言方法

*正確答案:*B:形式化方法;

13. (單選題)需求評審就是（ ）評審，是由非軟件開發人員對軟件系統的進行檢查以發現該系統所存在的問題。

• A. 文檔
• B. 技術
• C. 變更
• D. 驗證

*正確答案:*B:技術;

14. (單選題)為需求設計測試用例的目的是確認（ ）而不能確認系統。

• A. 系統
• B. 需求
• C. 軟件
• D. 業務

*正確答案:*B:需求;

15. (單選題)用（ ）解釋需求模型，有利于評審人員理解和評審需求規格說明。

• A. 形式化方法
• B. 自然語言
• C. 圖形
• D. 可視化

*正確答案:*B:自然語言;

16. (單選題)軟件需求檢測和驗證理論、技術的發展，是將（ ）與形式化需求驗證方法相結合。

• A. 可視化技術
• B. 形式化技術
• C. 圖形化技術
• D. 動畫技術

*正確答案:*A:可視化技術;

需求變更管理課堂練習題

一、選擇題（每題2分，共20分）

1. 需求變更管理的主要目標是（）B

A. 完全阻止需求變更

B. 控制和管理需求變更

C. 隨意接受所有變更請求

D. 減少項目溝通

2. 需求變更請求的初步審核主要關注（）B

A. 變更的技術實現細節

B. 變更的合理性和必要性

C. 變更的具體成本

D. 變更的實施人員

3. 需求跟蹤的主要目的是（）B

A. 限制需求變更

B. 建立需求與系統元素間的關聯關系

C. 降低項目成本

D. 減少項目文檔

4. 變更控制過程中，風險評估的主要內容包括（）B

A. 僅評估財務風險

B. 評估對項目進度、成本和質量的影響

C. 只關注技術風險

D. 忽略所有潛在風險

5. 需求變更的最終審批通常由（）B

A. 項目一線開發人員

B. 項目管理委員會

C. 單個項目經理

D. 客戶代表

6. 需求變更的歸檔主要目的是（）B

A. 增加文檔工作量

B. 為未來參考和追溯提供依據

C. 延長項目周期

D. 限制團隊溝通

7. 變更請求的生命周期中，以下哪個階段最關鍵（）B

A. 初步提交

B. 詳細評估

C. 實施驗證

D. 歸檔

8. 需求跟蹤的類型不包括（）C

A. 需求-源可跟蹤性

B. 需求-設計可跟蹤性

C. 需求-營銷可跟蹤性

D. 需求-用戶界面可跟蹤性

9. 變更控制的核心原則是（）B

A. 隨意修改基準需求

B. 控制對基準需求規格說明的變動

C. 完全不允許變更

D. 僅聽取開發人員意見

10. 需求變更的影響分析應考慮（）C

A. 僅技術影響

B. 僅成本影響

C. 多方面影響，如進度、成本、質量、范圍等

D. 忽略所有影響

二、填空題（每題2分，共20分）

1. 需求變更管理的核心是______和______需求變更。

2. 需求變更請求的生命周期包括提交、、、實施和______等階段。

3. 進行需求變更控制的關鍵在于建立明確的______和______機制。

4. 需求跟蹤的目的是建立______和______之間的關聯關系。

5. 變更請求的狀態可能包括：、、______、______和______等。

6. 需求管理的最佳實踐包括建立______的變更控制流程和______的文檔管理。

7. 變更影響分析應評估對______、______和______的潛在影響。

8. 需求變更控制的重點是______對基準需求規格說明的變動。

9. 項目團隊應對______和______的變更保持警惕和謹慎。

10. 需求變更管理的核心原則是______和______。

11. 控制、管理

12. 審核、評估、驗證

13. 流程、控制

14. 需求、系統元素

15. 提交、評估、接受、實施、驗證

16. 明確、版本化

17. 進度、成本、質量

18. 控制

19. 范圍、復雜性

20. 透明、溝通

三、判斷題（每題2分，共20分）

1. 需求變更管理的目標是完全阻止任何需求變更。（）F

2. 每個需求變更請求都應該經過詳細的影響分析。（）T

3. 項目經理可以隨意批準所有變更請求。（）F

4. 需求跟蹤有助于理解需求的來源和依賴關系。（）T

5. 變更控制過程可以完全避免項目風險。（）F

6. 需求變更管理應該建立在透明和溝通的基礎上。（）T

7. 所有的需求變更都應該無條件接受。（）F

8. 需求變更的歸檔對項目管理很重要。（）T

9. 變更請求的審批僅需要考慮技術可行性。（）F

10. 有效的需求管理能夠提高項目的可預測性和成功率。（）T

四、簡答題（每題5分，共20分）

1. 解釋需求變更管理的重要性，并列舉其主要任務。

重要性：

- 控制項目范圍

- 管理項目風險

- 保持需求一致性

主要任務：變更控制、需求跟蹤、影響分析、文檔管理

2. 描述需求變更請求的典型生命周期，并說明每個階段的關鍵活動。

生命周期：

- 變更請求提交

- 初步審核

- 詳細評估

- 風險成本分析

關鍵活動:

- 審批決策

- 實施

- 驗證

- 歸檔

3. 論述需求跟蹤的意義及其主要類型。

需求跟蹤意義：

- 建立需求間關聯

- 追蹤需求來源

- 理解需求依賴

主要類型：源可跟蹤性、理由可跟蹤性、需求可跟蹤性等

4. 闡述需求變更管理中風險評估的作用和主要內容。

風險評估：

- 分析變更對項目的影響

- 評估技術可行性

- 評估成本和進度影響

- 識別潛在風險

五、論述題（每題10分，共20分）

1. 詳細分析需求變更管理對項目成功的影響，并提出有效的變更控制策略。

需求變更管理影響：

- 影響項目范圍和目標

- 控制項目風險

策略：

* 建立清晰流程

* 定期評估

* 靈活但受控

2. 針對需求變更管理，討論如何平衡項目的靈活性和穩定性，并舉例說明具體的管理方法。

平衡靈活性和穩定性：

- 建立變更評估機制

- 設置變更門檻

- 保持溝通透明

- 靈活調整但有原則

需求分析技術課程引導問題回答

考核點1：需求優先級設定（頁面2-9）

引導問題1：為什么在軟件開發中需要設定需求優先級？

根據PPT內容，設定需求優先級的原因如下：

- 開發組不能同時交付一個包羅萬象且具有高質量的產品，需要區分首發版必須包括的需求與可放入后續版本的需求

- 在資源有限的情況下，必須理解所要求特性、用例和功能需求的相對優先級

- 有助于項目經理解決沖突、安排階段性交付，并做出必要的取舍

- 當客戶期望高、開發時間短且資源有限時，必須盡早確定最重要的功能

- 建立每個功能的相對重要性有助于規劃軟件構造，以最少費用提供產品的最大功能

- 在時間盒圖或漸增式開發中，設定優先級特別重要

- 幫助項目經理在接受新的高優先級需求時，有依據地刪除低優先級需求或將其推遲到下一版本

引導問題2：在需求優先級設定過程中，客戶和開發者應該扮演什么角色？

客戶角色：

- 負責指明哪些需求必須包括在首發版中，哪些需求可以延期實現

- 設定需求優先級是客戶的責任之一

- 往往讓可以給他們帶來最大利益的需求享有最高優先級

- 可能在了解開發者指出的費用、難度、技術風險等因素后，調整優先級觀點

開發者角色：

- 提供關于實現需求的費用、難度、技術風險等方面的信息

- 可能認為需要在早期階段先實現一些優先級較低的功能，因為它們會影響系統的體系結構

- 評估各需求的技術可行性和對系統架構的影響

雙方合作：

- 設定優先級意味著權衡每個需求的業務利益和費用，以及軟件結構基礎和產品未來評價

- 客戶和開發者代表應一起討論需求優先級設定結果，達成共識

引導問題3：設定需求優先級的三層規模分類法是如何工作的？

三層規模分類法是將需求分為三個優先級類別：

1. 高優先級（必須有）：

- 對于產品成功至關重要的功能

- 如果缺少這些功能，產品將無法滿足客戶的核心需求

- 在首發版中必須實現

2. 中優先級（應該有）：

- 對產品有重要價值但不是絕對必須的功能

- 這些功能可以提高產品的競爭力和用戶體驗

- 在資源允許的情況下應當實現

3. 低優先級（可以有）：

- 如果有時間和資源才實現的功能

- 這些是"錦上添花"的功能，對產品的基本功能影響不大

- 可以延遲到后續版本中實現

這種三層分類是一種簡單實用的方法，可以快速對需求進行分類，幫助團隊集中在最重要的功能上。PPT中提到，這是設定優先級的一般方法。

考核點2：質量功能展開(QFD)和完全質量管理(TQM)（頁面7-9）

引導問題1：質量功能展開(QFD)如何幫助確定產品特性的優先級？

根據PPT內容，質量功能展開(QFD)幫助確定產品特性優先級的方式如下：

- QFD是為產品提供用戶價值與性能相聯系的一種綜合方法

- 它用于確定產品開發中各個特性的優先級

- QFD首先識別核心特性，確定哪些特性對于產品交付是必不可少的，這些是最高優先級的特性

- 這些核心特性通常是產品成功所必需的關鍵功能或性能指標，不適用于優先級排序模型

- 一旦核心特性被識別和固定，其余的可變動特性（非必需但可能增加產品價值的特性）就可以使用優先級設定模型來排序

- QFD通過評估每個特性的市場需求、成本、技術可行性等因素，確定相對優先級，并據此安排開發計劃

引導問題2：完全質量管理(TQM)與需求優先級設定有什么關系？

根據PPT內容，TQM與需求優先級設定的關系如下：

- TQM是以多個重大項目成功的標準來評價每個需求，并計算出一個分值用于編排需求的優先級

- TQM的核心之一是以客戶為中心，確保客戶需求和期望得到滿足

- 在TQM框架中，需求優先級的管理是關鍵組成部分，幫助組織確定哪些需求對客戶滿意度最為關鍵

TQM中的需求優先級管理包括：

1. 需求識別：從客戶角度出發，識別客戶需求和期望，包括直接的產品/服務性能需求和間接需求
2. 需求分類：將需求分為不同類別（必需、重要、一般），根據對客戶滿意度的影響程度排序
3. 需求評估：不斷評估客戶需求變化和市場動態，確保持續改進活動與客戶需求保持一致
4. 優先級調整：隨著市場和技術變化，靈活調整需求優先級，以響應這些變化

引導問題3：為什么盡管QFD和TQM方法精確，但很少有公司愿意采用？

PPT中明確指出："QFD、TQM盡管精確，卻很少有公司愿意用它。"雖然PPT沒有詳細解釋原因，但從內容可以推斷以下幾點：

1. 復雜性：這些方法涉及復雜的評估過程和數學計算，需要投入大量時間和精力
2. 資源密集：實施這些方法需要組織投入大量資源，包括人力、時間和培訓成本
3. 實施難度：這些方法要求組織有較高的過程成熟度和嚴格的管理流程
4. 實用性考慮：在快速變化的市場環境中，公司可能更傾向于使用簡單、靈活的方法（如三層規模分類法）
5. 投入產出比：相比于簡單方法，這些精確方法的額外收益可能不足以證明其額外成本的合理性

考核點3：優先級設定工具的使用步驟（頁面10-12）

引導問題1：在使用優先級設定工具時，如何評估需求的價值和成本？

根據PPT內容，評估需求價值和成本的方法如下：

評估價值：

1. 估計每個特性提供給客戶或業務的相關利益（價值），使用1~9劃分等級，1代表可忽略的利益，9代表最大的價值
2. 估計如果沒有把應該實現的特性包括到產品中，將會給客戶或業務帶來的損失，使用1~9劃分等級，1代表基本無損失，9代表嚴重損失
3. 總價值是相對利潤和相對損失的總和

評估成本：

1. 估計實現每個特性的相對費用，使用1（低）~9（高）劃分等級
2. 根據需求的復雜度，所需求的用戶界面的實現情況、重用當前代碼的潛在能力、所需要的測試量和文檔等等，開發者可以估算出費用
3. 算出費用百分比：將每個需求的費用除以所有需求費用的總和

這種評估方法綜合考慮了需求對客戶和業務的價值，以及實現需求所需的成本，為優先級排序提供了量化的依據。

引導問題2：需求優先級的計算公式中各個參數代表什么含義？

根據PPT內容，需求優先級計算公式中的參數含義如下：

優先級 = 價值% / (成本% × 風險%)

其中：

- 價值%：表示該需求的總價值（相對利潤+相對損失）占所有需求總價值的百分比，反映了需求的相對重要性

- 成本%：表示實現該需求的費用占所有需求實現費用總和的百分比，反映了需求的相對實現成本

- 風險%：表示與需求相關的技術或其他風險程度占所有需求風險總和的百分比，反映了實現該需求的相對風險

這個公式的核心思想是：優先級最高的需求是那些以最小的費用比例和風險比例產生出最大產品價值比例的需求。價值越高，優先級越高；成本和風險越低，優先級越高。

引導問題3：為什么說優先級設定工具的結果只能作為指導策略而非絕對依據？

根據PPT第12頁的內容，優先級設定工具的結果只能作為指導策略而非絕對依據的原因是：

1. 這種半定量方法從數學上講并不嚴密
2. 其準確程度受到對每個項目的利潤、損失、費用和風險的估算能力的影響
3. 這些估算通常是主觀的，不同人員可能會有不同的評估結果
4. 優先級計算結果需要通過客戶和開發者代表的討論來驗證
5. 最終目標是在評價和優先級排序結果上達成共識，而不是盲目遵循計算結果

PPT強調："客戶和開發者代表應該討論整個平面圖，從而在評價和優先級排序結果上達成共識。"這表明工具只是輔助決策的手段，最終決策仍需要人的判斷和共識。

考核點4：軟件需求與風險管理（頁面13-16）

引導問題1：軟件項目中的風險是指什么？風險管理包括哪些主要活動？

根據PPT內容，軟件項目中的風險定義如下：

- 風險是指可能給項目的成功帶來威脅或損失的情況

- 在項目中，可能出現差錯的事情常常比可能意想不到地正常運行的事情多

- 風險無處不在，需要有風險意識

風險管理的主要活動包括：

1. 風險管理：使用某些工具或步驟把項目風險限制在一個可接受的范圍內
2. 風險評價（assessment）：檢查工程項目并識別潛在風險區域的過程
3. 風險分級（prioritization）：通過評價每項風險的潛在危害值，優先處理最嚴重的風險
4. 風險避免：采取措施避免風險發生
5. 風險控制：采取措施減輕風險影響
6. 編寫項目風險文檔：將風險編寫成文檔并妥善管理
7. 制定風險管理計劃：不僅列出風險，還要有針對性的管理措施

PPT強調：“防患于未然：要有預防措施”，表明風險管理的核心是預防而非事后補救。

引導問題2：為什么說需求在軟件項目中扮演著核心角色？

根據PPT第15頁內容，需求在軟件項目中扮演核心角色的原因如下：

1. 需求是軟件開發的基礎，定義了系統應該做什么，為整個開發過程提供方向
2. 需求問題會直接影響項目的成功與否，精明的項目管理者會在初期就指明與需求相關的風險并積極控制它們
3. 需求與客戶期望直接相關，需求的質量直接影響客戶滿意度
4. 需求相關的風險很多，如需求的誤解、不恰當的用戶參與、不確定或隨意變更項目范圍和目標等
5. 需求問題通常需要與客戶或客戶代表合作才能解決，體現了需求的復雜性和重要性

PPT特別指出："項目管理者只能通過與客戶或客戶代表（如市場人員）合作來控制需求風險。"這進一步強調了需求的核心地位，以及在需求問題上必須重視客戶合作。

引導問題3：編寫項目風險文檔的目的是什么？

根據PPT第14和18頁內容，編寫項目風險文檔的目的是：

1. 系統化管理風險：僅僅認識到項目面臨的風險是遠遠不夠的，需要系統地記錄和管理風險
2. 提高風險透明度：將風險編寫成文檔使項目相關人員都能了解風險情況
3. 便于跟蹤：文檔化便于在整個項目開發過程中跟蹤風險狀態的變化
4. 促進溝通：有利于風險承擔者了解風險情況狀態
5. 提供決策依據：文檔化的風險信息可以幫助項目管理者做出更好的決策
6. 實現風險的可控性：通過文檔化，使風險管理變得可操作、可量化、可跟蹤

項目風險文檔不僅是風險的清單，還包含了風險的詳細信息、可能性、影響、降低風險計劃等內容，是風險管理的重要工具。

考核點5：風險評價和管理（頁面17-20）

引導問題1：風險危害值是如何計算的？它在風險管理中有什么作用？

根據PPT內容，風險危害值的計算和作用如下：

計算方法：

- 風險危害值 = 可能性 × 影響

- 其中，可能性是指風險轉變為問題的可能性（通常用0-1之間的小數表示）

- 影響是指如果風險變成了事實將造成的損失（通常用1-9的數字表示）

在風險管理中的作用：

1. 風險分級的基礎：通過計算風險危害值，可以對不同風險進行排序，優先處理最嚴重的風險
2. 資源分配依據：危害值高的風險應分配更多資源來管理
3. 決策支持：幫助項目管理者決定哪些風險需要制定降低風險計劃
4. 客觀評估：提供相對客觀的方法來評估風險的嚴重程度
5. 風險溝通：為團隊成員和利益相關者提供一種量化的方式來討論風險

例如，PPT中給出的示例風險條目中，風險危害值計算為：0.6（可能性）× 7（影響）= 4.2，這個數值可以用來與其他風險的危害值比較，確定處理優先級。

引導問題2：風險條目跟蹤模板包含哪些關鍵元素？

根據PPT第18-19頁內容，風險條目跟蹤模板包含以下關鍵元素：

1. 序列號：風險的順序號，用于唯一標識風險
2. 確定日期：風險被識別出的日期
3. 撤消日期：撤消風險確定的日期（風險不再存在時填寫）
4. 描述：以"條件-結果"的形式描述風險
5. 可能性：風險轉變為問題的可能性（通常為0-1之間的數值）
6. 影響：如果風險變成了事實將造成的損失（通常為1-9的數值）
7. 危害值：可能性×影響，用于評估風險的嚴重程度
8. 降低風險計劃：一種或多種用來控制、避免、最小化及降低風險的方法
9. 負責人：解決風險的責任承擔者
10. 截止日期：完成降低風險措施的截止日期

PPT中給出了一個具體的風險條目示例，展示了如何使用這個模板來記錄和跟蹤風險。

引導問題3：如何確定風險降低計劃的有效性？

雖然PPT中沒有直接討論如何確定風險降低計劃的有效性，但結合風險管理的一般原則和PPT內容，可以推斷以下判斷標準：

1. 風險危害值的減少：有效的降低風險計劃應能顯著降低風險的危害值，即降低風險的可能性和/或影響
2. 可操作性：計劃應具體明確，有明確的責任人和截止日期
3. 資源效率：降低風險的成本應低于風險可能造成的損失
4. 可衡量性：計劃的執行和效果應該可以被監控和衡量
5. 持續性：計劃應能持續有效，而不只是短期解決方案

以PPT提供的示例為例，風險降低計劃包括具體的三個步驟：

1. 在第一階段早期就要收集易學、易用的需求
2. 與產品代表一起召開JAD會議以開發需求
3. 通過產品代表和用戶評估，包含核心功能的用戶界面

這個計劃有具體的行動、明確的負責人（Helen）和截止日期（在6/16/99前完成JAD會議），這些特性使其成為可能有效的風險降低計劃。

考核點6：與需求有關的風險（需求獲取）（頁面21-24）

引導問題1：為什么產品視圖與范圍的不清晰會導致項目范圍的逐漸擴大？

根據PPT第21頁內容，產品視圖與范圍不清晰導致項目范圍擴大的原因如下：

1. 缺乏明確界限：沒有對產品功能達成清晰共識，就無法確定什么是必須的、什么是可選的
2. 沒有參考標準：缺乏明確的產品視圖，新需求提出時就沒有判斷其是否超出原始范圍的依據
3. 利益相關者期望管理不足：不清晰的產品視圖會導致不同利益相關者對產品有不同的理解和期望
4. 缺乏變更控制基準：沒有明確的范圍文檔，就無法有效控制和評估變更請求

PPT建議在項目早期就編寫一份項目視圖與范圍文檔，將業務需求涵蓋在內，并將其作為新的需求及修改需求的指導。這樣可以提供一個基準線，幫助控制范圍蔓延。

引導問題2：在處理非功能需求時，開發團隊常犯哪些錯誤？

根據PPT第22-23頁內容，在處理非功能需求時，開發團隊常犯的錯誤是：

1. 忽視非功能需求：一般強調產品的功能性要求，非常容易忽略產品的非功能性需求
2. 未明確定義非功能需求：即使意識到非功能需求的存在，也可能未充分定義和量化這些需求
3. 缺乏驗收標準：沒有為非功能需求建立明確的可驗證標準
4. 在開發后期才考慮非功能需求：導致對架構和設計產生重大影響，造成大量返工
5. 未與客戶充分溝通非功能需求：未能了解客戶對性能、可用性、可靠性等方面的真實期望

PPT建議的解決方法是：詢問客戶關于產品性能、使用性、完整性、可靠性等質量特性，編寫非功能需求文檔和驗收標準，作為可接受的標準。

引導問題3：當用戶給出期望的解決方案而非實際需求時，需求分析師應如何應對？

根據PPT第24頁內容，當用戶給出期望的解決方案而非實際需求時，需求分析師應：

1. 認識到問題：理解用戶推薦的解決方法往往掩蓋了用戶的實際需求，可能導致業務處理的低效，或者給開發人員帶來壓力以至做出很差的設計方案
2. 挖掘真實需求：從客戶敘說的解決方法中提煉出其本質核心，即用戶真正想要實現的業務目標
3. 關注"做什么"而非"怎么做"：將用戶的解決方案轉化為功能需求，描述系統應該做什么，而不是如何做
4. 提問"為什么"：通過詢問用戶為什么需要某個特定解決方案，了解背后的真實需求和業務問題
5. 提供替代方案：基于對真實需求的理解，可能提出更有效的替代解決方案
6. 與用戶合作驗證：確保轉換后的需求描述仍然滿足用戶的實際業務需求

這種方法可以幫助分析師避免被用戶的解決方案所限制，更好地理解和滿足用戶的真實需求。

考核點7：與需求有關的風險（分析、規格說明和驗證）（頁面25-26）

引導問題1：為什么需求理解的不同會構成項目風險？如何減輕這種風險？

根據PPT第25頁內容，需求理解不同構成項目風險的原因和減輕措施如下：

原因：

1. 誤解導致實現偏差：不同團隊成員對需求的不同理解會導致設計和實現與客戶期望不符
2. 溝通問題：理解差異表明團隊內部和與客戶之間的溝通不暢
3. 范圍蔓延：不同理解可能導致范圍不斷擴大或變化
4. 返工風險：后期發現理解錯誤需要大量返工，增加成本和延誤進度
5. 集成困難：不同組件基于不同理解開發，可能導致集成問題

減輕風險的方法：

1. 評審團隊應包括開發人員、測試人員和客戶，確保不同角色對需求有一致理解
2. 使用清晰、無歧義的術語描述需求
3. 創建需求驗證原型，讓用戶確認理解是否正確
4. 建立需求追蹤矩陣，確保需求正確傳遞到設計和實現
5. 定期與客戶溝通，驗證理解的準確性

這些措施有助于確保團隊成員對需求有一致的理解，減少誤解帶來的風險。

引導問題2：需求規格說明中包含設計元素有什么危害？

根據PPT第25頁內容，需求規格說明中包含設計元素的危害包括：

1. 限制解決方案：過早引入設計決策會限制開發團隊探索更優解決方案的空間
2. 混淆"做什么"和"怎么做"：需求應該專注于系統應該做什么，而設計則關注如何做
3. 導致實現固化：特定設計元素可能將系統綁定到特定技術或架構上，限制未來的靈活性
4. 增加維護難度：當底層技術需要更新時，混合了設計的需求文檔也需要更新
5. 混淆責任界限：需求由客戶主導，設計由開發團隊主導，混合會導致責任不清

PPT建議的解決方法是：“說做什么，而不是說怎么做”。需求規格說明應該清晰地描述系統的功能和行為，而不是規定如何實現這些功能。

引導問題3：如何提高需求審查的有效性？

根據PPT第26頁內容，提高需求審查有效性的方法包括：

1. 組建多角色審查團隊：評審團隊應包括開發人員、測試人員和客戶，確保不同視角都能參與審查
2. 使用結構化的審查過程：采用正式的審查流程，如同行評審、檢查會議等
3. 使用審查清單：為不同類型的需求制定審查清單，確保覆蓋常見問題
4. 專注于需求質量屬性：確保需求的完整性、一致性、明確性、可驗證性等
5. 確保及時審查：在需求定稿前進行審查，避免后期發現問題造成大量返工
6. 記錄并跟蹤問題：系統記錄審查中發現的問題，并確保這些問題得到解決
7. 驗證審查結果：確保審查后的需求確實滿足了質量標準

有效的需求審查可以早期發現并解決需求中的問題，降低項目風險，提高開發效率和產品質量。

考核點8：需求管理中的風險（頁面27-28）

引導問題1：需求變更為什么不可避免？如何減少需求變更的負面影響？

根據PPT第27頁內容，需求變更不可避免的原因和減少負面影響的方法如下：

需求變更不可避免的原因（雖未在PPT中明確列出，但可推斷）：

1. 業務環境變化：市場、法規、競爭環境等外部因素變化
2. 用戶理解的演進：隨著項目進展，用戶對系統的理解不斷深入
3. 技術限制的發現：在開發過程中可能發現某些需求在技術上難以實現
4. 優先級變化：客戶業務優先級的調整可能導致需求變更

減少需求變更負面影響的方法：

1. 使用項目視圖與范圍文檔作為變更的參照，減少項目范圍的延伸
2. 促進用戶積極合作參與，可把需求變更減少近一半
3. 采用早期發現需求錯誤的質量控制方法，減少以后發生變更的可能
4. 針對易于變更的需求，在設計時使用多種方案實現，并更注重其可修改性
5. 建立變更管理的紀律和氛圍，使用變更控制委員會和工具來管理變更
6. 采用階段遞增式的生存期，在早期版本中實現核心功能，并在以后階段逐步增加需求

這些措施不是為了阻止變更，而是為了控制變更的影響，確保變更是有序和可管理的。

引導問題2：一個有效的需求變更過程應包含哪些關鍵要素？

根據PPT第27頁內容，有效的需求變更過程應包含以下關鍵要素：

1. 明確的變更管理流程：建立正式的變更管理機制，明確每個變更都需要經過評估和批準
2. 變更控制委員會：由相關利益方組成的委員會負責評估和決定是否接受變更
3. 變更請求表單：標準化的表單用于記錄變更的詳細信息、理由和影響
4. 影響分析：對每個變更請求進行全面分析，評估其對進度、成本、質量和其他需求的影響
5. 優先級評估：評估變更的緊急性和重要性，確定實施的優先順序
6. 追蹤機制：使用工具記錄和跟蹤所有變更請求的狀態
7. 溝通機制：確保所有相關方了解變更及其影響
8. 基線管理：維護需求基線，明確標識經過批準的變更后的需求版本
9. 紀律和氛圍：培養團隊對變更管理過程的尊重和遵守

有效的變更過程不是為了阻止變更，而是確保變更是經過充分考慮、評估和控制的，從而減少其負面影響。

引導問題3：什么是需求跟蹤能力矩陣？它如何幫助解決未實現需求的風險？

根據PPT第28頁內容，需求跟蹤能力矩陣是一種工具，用于跟蹤需求從規格說明到設計、實現和測試的映射關系。

需求跟蹤能力矩陣如何幫助解決未實現需求的風險：

1. 完整性驗證：矩陣可以清晰顯示每個需求是否已經被設計、實現和測試，幫助識別可能被遺漏的需求
2. 影響分析：當需求發生變更時，可以通過矩陣快速識別受影響的設計、代碼和測試組件
3. 覆蓋率分析：可以評估測試用例對需求的覆蓋率，確保所有需求都得到充分測試
4. 責任明確：矩陣可以明確每個需求的實現責任人，減少"責任空白"導致的需求遺漏
5. 進度跟蹤：通過矩陣可以跟蹤每個需求的實現進度，及早發現可能延遲的需求
6. 溝通工具：作為團隊間溝通的工具，確保所有人對需求實現狀態有共同理解

通過這些機制，需求跟蹤能力矩陣可以有效減少需求未實現或實現不完整的風險，提高項目交付質量。