1 需求評審的重要性
軟件的缺陷並不是在編程的時候纔出現的,需求和設計階段都會產生問題,如果缺陷發現的越遲,修正這個錯誤就要返回到以前的狀態,反攻的時間就花費的很多了,如果錯誤還不能夠被及時發現,那就可能帶來更大的危害,缺陷發現的越早,修正的越早,所用的成本就越低,越遲,成本就越高.所以我們對需求評審要認真對待了.概括下有幾點
a 對軟件需求進行正確性的檢查,能發現需求定義中的錯誤,從而節約成本,使後續過程的變更減少,降低風險.
b 保證軟件需求的可測試性,即確認客戶的需求是明確的,可遇見的.可以用測試用例反應出來
c 通過產品需求,可以使產品,開發,測試等部門相互溝通,達成一致
d 通過產品需求的評審,更好的理解產品的功能性和非功能性需求,爲制訂測試計劃,測試範圍,工作量等提供參考.
2 需求評審的注意點
a 明確自己的角色和責任,熟悉評審的內容
b 針對問題表達自己的觀點,對事不對人.分清主要問題和次要問題,先把主要問題說出來.
c 提高自己的溝通能力,
d 最主要的一點就是要善於提問,自己問自己問題.是否這個需求不明確,是否需求畫蛇添足,站在最終用戶角度想問題,而並不是絕對的站在需求提供方的角度.
3 評審的形式
a 交叉評審 b 輪查 c 走查 d 小組評審 e 審查
4 評審的標準
組織和完整性
* 所有需求的編寫在細節上是否都一致或者合適？
* 是否包括了每個需求的實現優先級？
* 軟件需求規格說明中是否包括了所有客戶代表或系統的需求？
* 是否在需求中遺漏了必要的信息？如果有的話，就把它們標記爲待確定的問題。
* 是否記錄了所有可能的錯誤條件所產生的系統行爲？
正確性
* 是否有需求與其它需求相沖突或重複？
* 是否簡明、簡潔、無二義性地表達每個需求的？
* 是否每個需求都能通過測試、演示、審查得以驗證或分析？
* 是否任一個特定的錯誤信息都具有唯一性和明確的意義？
質量屬性
* 是否合理地確定了性能目標？
* 是否合理地確定了安全與保密方面的考慮？
* 在確定了合理的折衷情況下，是否詳實地記錄了其它相關的質量屬性？
可跟蹤性
* 是否每個需求都具有唯一性並且可以正確地識別它？
* 是否可以根據高層需求（如系統需求或使用實例）跟蹤到軟件功能需求？
特殊的問題
* 是否所有的需求都是名副其實的需求而不是設計或實現方案？
* 是否確定了對時間要求很高的功能並且定義了它們的時間標準？
5. 進入和退出審查的標準
當軟件需求文檔滿足特定的前提條件時，你就可以進行需求審查了。這些標準還可以使審查小組避免把時間浪費在審查之前就應該解決的問題上。調解者在決定進行審查之前，可以把進入審查的標準作爲一種清單，並以此作爲判斷的標準。
* 文檔符合標準模板,並且已經做過拼寫檢查和語法檢查。
* 在文檔中打印了行序號以方便在審查中對特定位置的查閱。
* 所有未解決的問題都被標記爲（待確定）。
* 包括了文檔中使用到的術語詞彙表。
相似地，在調解者宣佈審查結束之前，你應該定義所滿足的退出審查的標準。
* 已經明確闡述了審查員提出的所有問題。
* 已經正確修改了文檔。
* 修訂過的文檔已經進行了拼寫檢查和語法檢查。
* 所有（待確定）的問題已經全部解決，或者已經記錄下每個待確定問題的解決過程，目標日期和提出問題的人。
* 文檔已經登記入項目的配置管理系統。
6 總結
基本上能做到以上說的幾點,需求就應該很明確了.接下來的流程也會走的很順了!