開發文檔遺漏了某些重要內容或某些設計，不能全部滿足既定的技術指標; 或存在邏輯錯誤、引用錯誤; 再或者引入了不必要的風險。這些問題在軟件開發文檔中屢見不鮮，而軟件驗證技術就是著力于解決這些問題，力爭使開發文檔臻于完善。

　　通過圖1可以發現，軟件缺陷錯誤絕大多數是在需求和設計階段引入的，不清晰的需求分析、不合理的系統設計常常導致后續的開發活動困難重重。因此，需求驗證和設計驗證是軟件驗證的重點，對于排除軟件缺陷而言是非常關鍵的。

　　軟件需求驗證

　　一份未經驗證的《軟件需求規格說明》（以下簡稱《需求說明》），極可能是包含著種種隱藏的軟件缺陷，這些缺陷如果被帶入到后續的開發階段或當系統投入使用時才被發現，將會導致較高代價的返工，因為需求的變化常會導致系統設計和實現的相應變化，從而使系統重新經歷編碼、集成、系統測試、交付等階段。需求的驗證過程主要是檢查需求規格說明，對該文檔中定義的各需求項執行多種類型的驗證。一般來說，需求驗證主要包括以下內容：

　　1．有效性驗證

　　有效性驗證是指開發人員和用戶應該對需求規格說明中各用戶需求項進行認真地審核，以確保用戶的需求被充分、正確地表達了出來，并且對于規格說明中提出的各項軟件需求，必須保證它確實能夠滿足用戶的相關需要、解決用戶的問題。

　　2．一致性驗證

　　一致性是指各需求項之間以及需求項和相應的規范或標準之間沒有沖突，對同一個系統功能不應出現不同的描述或矛盾的約束。一致性驗證主要包括四方面內容：一是驗證各個需求項之間是否一致; 二是驗證《需求說明》中規定的模型、算法和數值方法相互是否兼容; 三是驗證《需求說明》中所采用的技術和方法是否與用戶要求的技術及方法保持一致; 四是驗證各需求項中涉及到的軟硬件接口是否具有兼容性。

　　3．完備性驗證

　　完備性驗證是指檢查需求文檔是否包括用戶需要的所有的功能、性能和約束，是否滿足用戶的所有要求。一個完備的需求文檔應該對所有可能的狀態、狀態變化、轉入條件、相關約束等都進行了完整、準確的描述。

　　完備性驗證主要包括對《需求說明》六個方面的驗證：是否包括了所有有意義的需求，并按優先級排序; 是否明確規定了哪些是絕對不能發生的故障或設計缺陷; 所有的需求項是否都被列入需求描述表，并被編號，能支持索引或回溯; 各圖表、表格是否都有標號，各類專業術語及測量單位是否都給出相應的定義或引用的標準化文件; 時間關鍵性功能是否都被清晰地標識出來，對時間的具體要求是否作了規定; 是否包括了對所有異常的響應，尤其是對各種有效的、無效的輸入值的響應規定，對各種操作模式下的環境條件、系統響應時間等是否都作了相應的規定。

　　4．可行性驗證

　　可行性驗證是指根據現有的軟硬件技術水平和系統的開發預算、進度安排，對需求的可行性進行驗證，以保證所有的需求都能實現。包括驗證《需求說明》中定義的需求對軟件的設計、實現、運行和維護而言是否是可行的，驗證其規定的模型、算法和數值方法對于要解決的問題而言是否合適，驗證約束性需求中所規定的質量屬性是個別地還是成組地可以達到。

　　5．可驗證性驗證

　　可驗證性是指為了減少客戶和開發商之間可能產生的爭議，系統需求應該能夠通過一系列檢查方法來進行驗證，以確定交付的系統是否滿足需要。它包括驗證各個需求項是否能夠通過測試軟件產品和軟件開發文檔來證明這些需求項已經被實現; 各個需求項描述是否清楚、最好能量化; 每一個需求是否都對應于一個驗證方法。

　　6．可跟蹤性驗證

　　可跟蹤性是指需求的出處應該被清晰地記錄，如每一項功能都能夠追溯到要求它的用戶需求或相關文件。主要驗證每個需求項是否都具有惟一性并且被惟一標識，需求項定義描述中是否都明確地注明了該項需求源于上一階段中哪個文檔，以及是否可以從上一階段的文檔中找到需求定義中的相應內容。

　　7．可調節性驗證

　　可調節性是指需求的變更不會對其他系統帶來大規模的影響，主要驗證需求項是否被組織成可以允許修改的結構，例如采用列表形式; 驗證每個特定的需求的具體規定是否多于一次，有沒有出現冗余的說明; 以及是否有一套規則用來在后續的軟件生命周期里對《需求說明》進行維護。

　　8．其他方面的驗證

　　另外，對《需求說明》的驗證還包括編寫格式是否符合相應的規范或標準（如GB 8567-88、或GJB1091-91），需求中提出的算法和方法方面的需求項是否有科技文獻或其他文獻作為基礎，以及是否出現“待定”之類的不確定性詞匯，如果出現，是否注明是何種原因導致的不確定性。

　　對于一個中型軟件項目而言，以上驗證項絕大多數是必須的，各測試團隊可以根據項目的實際工程環境對此做裁減和細化。需求驗證的執行應該遵循“策劃→執行→檢查→評估”的順序完成。驗證采取的形式可以是走查、審查、會議評審以及用戶正式、非正式會議。不管采用哪種形式，上述驗證的內容應該盡量覆蓋到。

　　概要設計驗證

圖2 某桌面程序的開發流程

　　從圖2可以看出，概要設計是軟件開發過程中決定軟件產品質量的關鍵階段。這個階段設計人員需要站在全局的高度，在比較抽象的層次上分析、對比多種可能的系統實現方案和多種可能的軟件體系結構，從中選出最佳的方案和最合理的軟件結構。概要設計驗證可以確保《概要設計說明書》（以下簡稱《設計說明》）中所描述的軟件概要設計在總體結構、外部接口、主要部件功能分配、全局數據結構以及各主要部件之間的接口等方面的合適性、完整性，從而以保證用較低的成本開發出較高質量的軟件系統。

　　1．驗證設計系統在項目軟件中所處的層次結構描述是否準確以及在后續設計階段中的指導性作用

　　這里主要是驗證《設計說明》中對所要設計的系統在整個項目軟件中所處的地位、作用，及其與同級、上級系統之間的關系描述是否準確; 以及是否可以作為《詳細設計規格說明》撰寫的基礎性文檔。

　　2．驗證系統描述是否具有可追溯性

　　重點對《設計說明》做以下驗證：每一部分的設計是否都可以追溯到《需求說明》、《接口設計說明書》或其他開發文檔; 非功能需求項（如接口需求等）是否已經分配到《概要設計規格說明》中; 不完整、易變動或潛在的需求項是否都進行了相應的設計分析，對各種設計限制是否做了全面的考慮; 模塊的規格及大小劃分是否和《需求說明》中的功能需求項以及約束性需求項之間保持一致。

　　3．驗證總體設計是否合理

　　重點對《設計說明》進行以下驗證: 設計目標描述是否明確清晰; 是否闡述了設計所依賴的運行環境，核對是否和《需求說明》中規定的運行環境一致; 業務邏輯是否準確、完備; 是否對不同的設計方案作了介紹并比較，是否有選擇方案的結論，是否清楚闡述了方案選擇的理由; 是否合理地劃分了模塊并對各模塊之間的關系作了清晰的闡述; 系統設計結構和數據處理流程是否能滿足軟件需求規格說明中所要求的全部功能性需求。

　　4．接口設計是否合理

　　這方面主要是驗證《設計說明》中用戶接口設計是否正確全面，是否有單獨的用戶界面設計文檔，是否包括硬件接口、軟件接口、通信接口等的設計，以及是否描述了各類接口的功能、各接口與其他接口或模塊之間的關系以及接口的設計是否具有可測試性。

　　5．驗證模塊及模塊內部的設計是否合理

　　主要驗證模塊的劃分是合適、模塊與模塊之間是否具有一定的獨立性; 每個模塊的功能和接口定義是否正確; 數據結構的定義是否正確，比如面向對象編程中的數據封裝是否適當等; 模塊內的數據流和控制流的定義是否正確。

　　6．驗證概要設計是否包含相關屬性設計

　　驗證《設計說明》中是否有可靠性、安全性、可維護性、可移植性、可測試性等方面的設計，并且是否合理、有效。

　　7．驗證計算機資源的利用和余量設計是否合理

　　這里考察《設計說明》是否對余量設計做了相應考慮。包括CPU的處理能力要求、內存的容量要求、外存儲設備的容量要求等是否留有余量; 外存儲設備的容量要求是否留有余量; 算法的效率是否可接受; 關鍵軟件部件發生故障時是否有快速恢復能力等等。

　　各測試團隊可以根據待測項目的規模進行裁減和細化。對于沒有概要設計階段的軟件開發項目，此階段的驗證活動可以相應地略去。概要設計在執行中采取的形式以評審會為多，也可以采用非正式內部審查或專題會議的形式進行。由于概要設計的驗證在很大程度上與軟件需求規格說明的內容有關，建議聘請軟件需求規格說明的起草人員和驗證人員參與到概要設計的驗證活動中來。