需求驗證

驗收測試是以用戶需求爲基礎的，系統測試是以功能需求爲基礎的，而集成測試是以系統的體系結構爲基礎的。在相應的開發階段，必須規劃測試活動併爲每一種測試設計測試用例。不可能在需求開發階段真正進行任何測試，因爲還沒有可執行的軟件。然而，你可以在開發組編寫代碼之前，以需求爲基礎建立概念性測試用例，並使用它們發現軟件需求規格說明中的錯誤、二義性和遺漏，還可以進行模型分析。
  
需求驗證是需求開發的第四部分（其餘三個爲獲取、分析和編寫規格說明），需求驗證所包括的活動是爲了確定以下幾方面的內容： 
    • 軟件需求規格說明正確描述了預期的系統行爲和特徵。
    • 從系統需求或其它來源中得到軟件需求。
    • 需求是完整的和高質量的。
    • 所有對需求的看法是一致的。
    • 需求爲繼續進行產品設計、構造和測試提供了足夠的基礎。

    正式技術評審的最好類型叫作審查（ i n s p e c t i o n）（Ebenau and Strauss 1994; Gilb and
Graham 1993）。對需求文檔的審查是可利用的最高級軟件質量技術。一些公司已經認識到：
在審查需求文檔或其它軟件產品上花費一個小時，可節省十個小時的工作時間（ G r a d y 1 9 9 4）。
我尚不知道有哪些其它的軟件開發或質量評估可以產生十倍的回收投資比。
    如果你對提高軟件的質量持有認真的態度，那麼就審查所編寫需求文檔的每一行。雖然
對大型的需求文檔進行詳細審查很無聊並且也很費時，但是我所知道的採用需求審查的人都
一致認爲他們所花的每一分鐘都是值得的。如果你認爲沒有時間詳細審查每個方面，那麼就
使用簡單的風險分析模型來區分需求文檔哪些部分是需要詳細審查的和那些不重要部分只要
用非正式評審就能滿足質量要求。