4. 需求確認(rèn)簽字
1）在主要的業(yè)務(wù)清楚以后即可以進(jìn)行需求確認(rèn)
2）目的是確定需求基線
3）不要期望所有的需求在簽字后不變
八、需求管理
1. 需求基線
1）軟件需求規(guī)格說明及相關(guān)分析模型。經(jīng)評審批準(zhǔn)，這些文檔定義了開發(fā)工作的需求基線；
2）建立需求基準(zhǔn)版本和需求控制版本文檔確定一個需求基準(zhǔn)，這是一致性需求在特定時刻的快照；
3）之后的需求變更遵循變更控制過程；
4）每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準(zhǔn)或新舊版本相混淆。
2. 需求變更控制
1）確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。
2）需求變更控制流程
3. 建立變更控制委員會
1）組織一個由項目風(fēng)險承擔(dān)者組成的小組作為變更控制委員會，由他們來確定進(jìn)行哪些需求變更，此變更是否在項目范圍內(nèi)，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設(shè)置實現(xiàn)的優(yōu)先順序，制定目標(biāo)版本；
2）變更控制委員會成員可以是甲方與乙方的人員共同組成；
3）定期進(jìn)行需求變更評審會議；
4）每次評審要有評審報告。
4. 需求變更影響評估
1）進(jìn)行需求變更影響分析，應(yīng)評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。
2）明確與變更相關(guān)的任務(wù)并評估完成這些任務(wù)需要的工作量。
5. 需求變更時，修改需求跟蹤能力矩陣
1）跟蹤所有受需求變更影響的工作產(chǎn)品當(dāng)進(jìn)行某項需求變更時，參照需求跟蹤能力矩陣找到相關(guān)的其它需求、設(shè)計模板、源代碼和測試用例，這些相關(guān)部分可能也需要修改。
6. 維護(hù)需求變更的歷史記錄
1）記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負(fù)責(zé)更新和更新的新版本號等。
2）在需求基線的基礎(chǔ)上記錄變更歷史記錄；
3）針對每一個需求形成一個單獨記錄；
通過對于軟件需求分析的學(xué)習(xí)，知道需求分析要承擔(dān)著很多風(fēng)險，因此做好計劃以及風(fēng)險控制是非常重要的。
