6. 應用質(zhì)量功能調(diào)配要
1）將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。
2）明確那些是客戶為關注的特性。
3）將需求分為三類：
–期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意
–普通需求
–興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責備
六、編寫需求規(guī)則說明書
1. 采用軟件需求規(guī)格說明模版
1）為記錄功能需求和各種其它與需求相關的重要信息提供了統(tǒng)一的結構。
2）其目的并非是創(chuàng)建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。
2. 指明需求的來源
1）為了讓所有項目風險承擔者明白需求規(guī)格說明書中為何提供這些功能需求，要都能追溯每項需求的來源；
2）可能是一種使用實例或其它客戶要求，也可能是某項更高層系統(tǒng)需求、業(yè)務規(guī)范、政府法規(guī)、標準或別的外部來源。
3. 為每項需求注上標號
1）可跟蹤性和可修改性的質(zhì)量標準，必須確定每個軟件需求。
2）為每項需求注上標號制定一種慣例來為需求規(guī)格說明書中的每項需求提供一個獨立的可識別的標號或記號。
3）這種慣例應當很健全，允許增加、刪除和修改。
4）作了標號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態(tài)和變更活動建立度量。
5）需求標識方法有序列號;層次化編碼;使用"待確定"（to be determined， TBD）符號等。
4. 記錄業(yè)務規(guī)范
1）是指關于產(chǎn)品的操作原則，比如誰能在什么情況下采取什么動作。
2）將這些編寫成需求規(guī)格說明書中的一個獨立部分，或一獨立的業(yè)務規(guī)范文檔。
七、需求驗證
1. 審查需求文檔
1）在需求開發(fā)期間進行非正式評審。
2）對需求文檔進行正式審查是保證軟件質(zhì)量的很有效的方法。
3）組織一個由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小組，對需求規(guī)格說明書及相關模型進行仔細的檢查。
2. 依據(jù)需求編寫測試用例
1）根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例。
2）客戶通過使用測試用例以確認是否達到了期望的要求。
3）從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結果與測試用例相一致。
4）要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。
3. 確定合格的標準
1）確定合格的標準讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。
2）將合格的測試建立在使用情景描述或使用實例的基礎之上。
