4. 需求確認簽字

1）在主要的業(yè)務清楚以后即可以進行需求確認

2）目的是確定需求基線

3）不要期望所有的需求在簽字后不變

八、需求管理

1. 需求基線

1）軟件需求規(guī)格說明及相關分析模型。經評審批準，這些文檔定義了開發(fā)工作的需求基線；

2）建立需求基準版本和需求控制版本文檔確定一個需求基準，這是一致性需求在特定時刻的快照；

3）之后的需求變更遵循變更控制過程；

4）每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。

2. 需求變更控制

1）確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。

2）需求變更控制流程

3. 建立變更控制委員會

1）組織一個由項目風險承擔者組成的小組作為變更控制委員會，由他們來確定進行哪些需求變更，此變更是否在項目范圍內，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設置實現的優(yōu)先順序，制定目標版本；

2）變更控制委員會成員可以是甲方與乙方的人員共同組成；

3）定期進行需求變更評審會議；

4）每次評審要有評審報告。

4. 需求變更影響評估

1）進行需求變更影響分析，應評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。

2）明確與變更相關的任務并評估完成這些任務需要的工作量。

5. 需求變更時，修改需求跟蹤能力矩陣

1）跟蹤所有受需求變更影響的工作產品當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能也需要修改。

6. 維護需求變更的歷史記錄

1）記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負責更新和更新的新版本號等。

2）在需求基線的基礎上記錄變更歷史記錄；

3）針對每一個需求形成一個單獨記錄；

通過對于軟件需求分析的學習，知道需求分析要承擔著很多風險，因此做好計劃以及風險控制是非常重要的。