系
4. 需求驗(yàn)證
　　1）審查需求文檔：對需求文檔進(jìn)行正式審查是保證軟件質(zhì)量的很有效的方法。組織一個(gè)由不同代表（如分析人員，客戶，設(shè)計(jì)人員，測試人員）組成的小組，對需求規(guī)格說明書及相關(guān)模型進(jìn)行仔細(xì)的檢查。另外在需求開發(fā)期間所做的非正式評審也是有所裨益的。
　　2）依據(jù)需求編寫測試用例：根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例?？蛻敉ㄟ^使用測試用例以確認(rèn)是否達(dá)到了期望的要求。還要從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結(jié)果與測試用例相一致。同時(shí)，要使用測試用例來驗(yàn)證需求模型的正確性，如對話框圖和原型等。
　　3）編寫用戶手冊：在需求開發(fā)早期即可起草一份用戶手冊，用它作為需求規(guī)格說明的參考并輔助需求分析。優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。而輔助需求如質(zhì)量屬性、性能需求及對用戶不可見的功能則在需求規(guī)格說明書中予以說明。
　　4）確定合格的標(biāo)準(zhǔn)：確定合格的標(biāo)準(zhǔn)讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。將合格的測試建立在使用情景描述或使用實(shí)例的基礎(chǔ)之上。
二、需求管理
　　需求開發(fā)的結(jié)果應(yīng)該有項(xiàng)目視圖和范圍文檔、使用實(shí)例文檔、軟件需求規(guī)格說明及相關(guān)分析模型。經(jīng)評審批準(zhǔn)，這些文檔就定義了開發(fā)工作的需求基線。這個(gè)基線在客戶和開發(fā)人員之間就構(gòu)筑了計(jì)劃產(chǎn)品功能需求和非功能需求的一個(gè)約定。需求約定是需求開發(fā)和需求管理之間的橋梁，需求管理包括在工程進(jìn)展過程中維持需求約定集成性和精確性的所有活動。
　　 1．確定需求變更控制過程，確定一個(gè)選擇、分析和決策需求變更的過程。所有的需求變更都需遵循此過程，商業(yè)化的問題跟蹤工具都能支持變更控制過程。
　　2．建立變更控制委員會，組織一個(gè)由項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者組成的小組作為變更控制委員會，由他們來確定進(jìn)行哪些需求變更，此變更是否在項(xiàng)目范圍內(nèi)，估價(jià)它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設(shè)置實(shí)現(xiàn)的優(yōu)先順序，制定目標(biāo)版本。
　　3．進(jìn)行需求變更影響分析，應(yīng)評估每項(xiàng)選擇的需求變更，以確定它對項(xiàng)目計(jì)劃安排和其它需求的影響。明確與變更相關(guān)的任務(wù)并評估完成這些任務(wù)需要的工作量。通過這些分析將有助于變更控制委員會作出更好的決策。影響分析可以提供對建議的變更的準(zhǔn)確理解，幫助做出信息量充分的變更批準(zhǔn)決策。通過對變更內(nèi)容的檢驗(yàn)，確定對現(xiàn)有的系統(tǒng)做出是修改或拋棄的決定，或者創(chuàng)建新系統(tǒng)以及評估每個(gè)任務(wù)的工作量。進(jìn)行影響分析的能力依賴于跟蹤能力數(shù)據(jù)的質(zhì)量和完整性。
　　4．跟蹤所有受需求變更影響的工作產(chǎn)品當(dāng)進(jìn)行某項(xiàng)需求變更時(shí)，參照需求跟蹤能力矩陣找到相關(guān)的其它需求、設(shè)計(jì)模板、源代碼和測試用例，這些相關(guān)部分可能也需要修改。這樣能減少因疏忽而不得不變更產(chǎn)品的機(jī)會，這種變更在變更需求的情況下是必須進(jìn)行的。
　　5．建立需求基準(zhǔn)版本和需求控制版本文檔確定一個(gè)需求基準(zhǔn)，這是一致性需求在特定時(shí)刻的快照。之后的需求變更就遵循變更控制過程即可。每個(gè)版本的需求規(guī)格說明都必須是獨(dú)立說明，以避免將底稿和基準(zhǔn)或新舊版本相混淆。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。
　　6．維護(hù)需求變更的歷史記錄記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負(fù)責(zé)更新和更新的新版本號等。版本控制工具能自動完成這些任務(wù)。版本控制是管理需求的一個(gè)必要方面。需求文檔的每一個(gè)版本必須被統(tǒng)一確定。組內(nèi)每個(gè)成員必須能夠得到需求的當(dāng)前版本，必須清楚地將變更寫成文檔，并及時(shí)通知到項(xiàng)目開發(fā)所涉及的人員。為了盡量減少困惑、沖突、誤傳，應(yīng)僅允許指定的人來更新需求。這些策略適用于所有關(guān)鍵項(xiàng)目文檔。
　　7．跟蹤每項(xiàng)需求的狀態(tài)建立一個(gè)數(shù)據(jù)庫，其中每一條記錄保存一項(xiàng)功能需求。保存每項(xiàng)功能需求的重要屬性，它包括狀態(tài)（如已推薦的，已通過的，已實(shí)施的，或已驗(yàn)證的），這樣在任何時(shí)候都能得到每個(gè)狀態(tài)類的需求數(shù)量。
　　8．衡量需求穩(wěn)定性記錄基準(zhǔn)需求的數(shù)量和每周或每月的變更（添加、修改、刪除）數(shù)量。過多的需求變更"是一個(gè)報(bào)警信號"，意味著問題并未真正弄清楚，項(xiàng)目范圍并未很好地確定下來或是政策變化較大。
　　9．使用需求管理工具商業(yè)化的需求管理工具能幫助你在數(shù)據(jù)庫中存儲不同類型的需求，為每項(xiàng)需求確定屬性，可跟蹤其狀態(tài)，并在需求與其它軟件開發(fā)工作產(chǎn)品間建立跟蹤能力聯(lián)系鏈。

    項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~

    http://m.vanceur.cn/pmqhd/index.html