6. 應用質(zhì)量功能調(diào)配要

1）將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。

2）明確那些是客戶為關(guān)注的特性。

3）將需求分為三類：

–期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意

–普通需求

–興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責備

六、編寫需求規(guī)則說明書

1. 采用軟件需求規(guī)格說明模版

1）為記錄功能需求和各種其它與需求相關(guān)的重要信息提供了統(tǒng)一的結(jié)構(gòu)。

2）其目的并非是創(chuàng)建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。

2. 指明需求的來源

1）為了讓所有項目風險承擔者明白需求規(guī)格說明書中為何提供這些功能需求，要都能追溯每項需求的來源；

2）可能是一種使用實例或其它客戶要求，也可能是某項更高層系統(tǒng)需求、業(yè)務(wù)規(guī)范、政府法規(guī)、標準或別的外部來源。

3. 為每項需求注上標號

1）可跟蹤性和可修改性的質(zhì)量標準，必須確定每個軟件需求。

2）為每項需求注上標號制定一種慣例來為需求規(guī)格說明書中的每項需求提供一個獨立的可識別的標號或記號。

3）這種慣例應當很健全，允許增加、刪除和修改。

4）作了標號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態(tài)和變更活動建立度量。

5）需求標識方法有序列號;層次化編碼;使用"待確定"（to be determined， TBD）符號等。

4. 記錄業(yè)務(wù)規(guī)范

1）是指關(guān)于產(chǎn)品的操作原則，比如誰能在什么情況下采取什么動作。

2）將這些編寫成需求規(guī)格說明書中的一個獨立部分，或一獨立的業(yè)務(wù)規(guī)范文檔。

七、需求驗證

1. 審查需求文檔

1）在需求開發(fā)期間進行非正式評審。

2）對需求文檔進行正式審查是保證軟件質(zhì)量的很有效的方法。

3）組織一個由不同代表（如分析人員，客戶，設(shè)計人員，測試人員）組成的小組，對需求規(guī)格說明書及相關(guān)模型進行仔細的檢查。

2. 依據(jù)需求編寫測試用例

1）根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例。

2）客戶通過使用測試用例以確認是否達到了期望的要求。

3）從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結(jié)果與測試用例相一致。

4）要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。

3. 確定合格的標準

1）確定合格的標準讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。

2）將合格的測試建立在使用情景描述或使用實例的基礎(chǔ)之上。