圍之內(nèi)，是否都已充分說明；
軟件的行為和它必須處理的信息、必須完成的功能是否一致；
設(shè)計的約束條件或限制條件是否符合實際；
是否考慮了開發(fā)的技術(shù)風(fēng)險；
是否考慮過軟件需求的其它方案；
是否考慮過將來可能會提出的軟件需求；
是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義是否成功進行確認；
有沒有遺漏，重復(fù)或不一致的地方；
用戶是否審查了初步的用戶手冊或原型；
項目開發(fā)計劃中的估算是否受到了影響。
四、需求說明書評審檢查
|
＃ |
檢查項 |
Y/TBD/N/NA |
|
|
清晰性 |
|
|
|
系統(tǒng)的目標是否已定義？ |
|
|
|
是否對關(guān)鍵術(shù)語和縮略語進行定義和描述？ |
|
|
|
所使用的術(shù)語是否和用戶/客戶使用的一致？ |
|
|
|
需求的描述是否清晰，不含糊？ |
|
|
|
是否有對整套系統(tǒng)進行功能概述？ |
|
|
|
是否已詳細說明了軟件環(huán)境 (共存的軟件) 和硬件環(huán)境 (特定的配置)？ |
|
|
|
如果有會影響實施的假設(shè)情況，是否已經(jīng)聲明？ |
|
|
|
是否已經(jīng)對每個業(yè)務(wù)邏輯進行輸入、輸出以及過程的詳細說明？ |
|
|
|
完整性 |
|
|
|
是否列出了系統(tǒng)所必須的依賴、假設(shè)以及約束？ |
|
|
|
是否對每個提交物或階段實施都進行了需求說明？ |
|
|
|
需求說明書是否已包括了主要的質(zhì)量屬性，例如有效性、高效性、靈活性、完整性、互操作性、可靠性、健壯性、可用性、可維護性、可移植性、可重用性和可測試性。 |
|
|
|
依從性 |
|
|
|
該文檔是否遵守了該項目的文檔編寫標準？ |
|
|
|
一致性 |
|
|
|
需求說明是否存在直接相互矛盾的條目？ |
|
|
|
本需求說明書是否與相關(guān)需求素材一致？ |
|
|
|
可行性 |
|
|
|
所描述的所有功能是否必要并充分地滿足了客戶/系統(tǒng)目標？ |
|
|
|
需求說明書的描述的詳細程度是否足以進行詳細的設(shè)計？ |
|
|
|
已知的限制（局限）是否已經(jīng)詳細說明？ |
|
|
|
是否已確定每個需求的優(yōu)先級別？ |
|
|
|
可管理性 |
|
|
|
是否將需求分別陳述，因此它們是獨立的并且是可檢查的？ |
|
|
|
是否所有需求都可以回溯到相應(yīng)的需求素材，反之亦然？ |
|
|
|
是否已詳細說明需求變更的過程？ |
|
在需求說明書評審結(jié)束后，監(jiān)理單位應(yīng)將評審意見以專題監(jiān)理報告形式提交業(yè)主單位。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
