|
需求驗證主要是分析需求規格說明的正確性和可行性，檢驗需求是否反映客戶的意願，從而確定能否轉入概要設計階段；而概要設計驗證主要是檢查《概要設計規格說明》是否滿足《軟件需求規格說明》的各項要求，設計是否合理，是否可以據此產生《詳細設計規格說明》，並確定能否轉入詳細設計階段。
軟件需求驗證
如果在構造設計開始之前，通過驗證基於需求的測試計劃和原型測試來驗證需求的正確性及其質量，就能大大減少項目後期的返工現象。而如果在後續的開發或當系統投入使用時才發現需求文檔中的錯誤，就會導致更大代價的返工，因爲需求的變化總會帶來系統設計和實現的改變，從而使系統必須重新測試，由需求問題對系統做變更的成本比修改設計或代碼錯誤的成本要大得多。需求的驗證過程主要是檢查需求規格說明，這個過程中要對需求文檔中定義的需求執行多種類型的驗證，主要包括：
1． 有效性驗證
有效性驗證是指開發人員和用戶應該對需求進行認真地複查，以確保將用戶的需要充分、正確地表達出來，並且對於提出的每項需求，必須保證它確實能夠滿足用戶的需要、解決用戶的問題。
2． 一致性驗證
一致性是指需求之間以及需求和相應的規範或標準之間不應該出現衝突，對同一個系統功能不應出現不同的描述或矛盾的約束。一致性驗證主要包括四方面內容：一是驗證各個需求之間是否一致，是否有衝突或矛盾；二是驗證《軟件需求規格說明》中規定的模型、算法和數值方法相互是否兼容；三是驗證《軟件需求規格說明》中所採用的技術和方法是否與用戶要求的技術及方法保持一致；四是驗證需求的軟硬件接口是否具有兼容性。
3． 完備性驗證
完備性驗證是指檢查需求文檔是否包括用戶需要的所有功能和約束，滿足用戶的所有要求。一個完備的需求文檔應該對所有可能的狀態、狀態變化、轉入、約束都進行了完整、準確的描述。主要包括以下六個方面的內容：一是驗證《軟件需求規格說明》是否包括了所有需求，並且是否按優先級作了排序；二是驗證《軟件需求規格說明》是否明確規定了哪些是絕對不能發生的故障或設計缺陷；三是驗證《軟件需求規格說明》中出現所有的需求項是否都被列入需求描述表，在這張表中各需求項是否都被編號並能支持索引或回溯；四是驗證《軟件需求規格說明》中出現的各種圖表、表格是否都有標號，各類專業術語及測量單位是否都給出了相應的定義或引用的標準化文件；五是驗證軟件需求規格說明中時間關鍵性功能是否都被清晰地標識出來了，對時間的具體要求是否作了規定。六是驗證功能需求部分是否包括了對所有異常的響應（尤其是對各種有效的、無效的輸入值的響應規定），對各種操作模式（如：正常、非正常、有干擾等）下的環境條件、系統響應時間等是否都作了相應的規定。
4． 可行性驗證
可行性驗證是指根據現有的軟硬件技術水平和系統的開發預算、進度安排，對需求的可行性進行驗證，以保證所有的需求都能實現。
可行性驗證主要包括以下三方面的內容：一是驗證《軟件需求規格說明》中定義的需求對軟件的設計、實現、運行和維護而言是否是可行的；二是驗證《軟件需求規格說明》中規定的模型、算法和數值方法對於要解決的問題而言是否合適，他們是否能夠在給定的約束條件下實現；三是驗證約束性需求中所規定的質量屬性是個別地還是成組地可以達到。
5． 可驗證性驗證
可驗證性是指爲了減少客戶和開發商之間可能產生的爭議，系統需求應該能夠通過一系列檢查方法來進行驗證，以確定交付的系統是否滿足需要。
可驗證性驗證主要包括以下三個方面的內容：一是驗證各個需求項是否能夠通過測試軟件產品和軟件開發文檔來證明這些需求項已經被實現；二是驗證各個需求項描述是否清楚、最好能量化。避免使用模糊不清的詞彙；三是驗證《軟件需求規格說明》中每一個需求是否都對應於一個驗證方法。
6．可跟蹤性驗證
可跟蹤性是指需求的出處應該被清晰地記錄，每一項功能都能夠追溯到要求它的需求，每一項需求都能追溯到用戶的要求。可跟蹤性驗證主要包括以下三方面的內容：一是驗證每個需求項是否都具有唯一性並且被唯一標識，以便被後續開發文檔引用；二是驗證在需求項定義描述中是否都明確地註明了該項需求源於上一階段中哪個文檔，包含該文檔中哪些有關需求和設計約束；三是驗證是否可以從上一階段的文檔中找到需求定義中的相應內容。
7． 可調節性驗證
可調節性是指需求的變更不會對其他系統帶來大規模的影響。可調節性驗證主要包括以下三方面的內容：一是驗證需求項是否被組織成可以允許修改的結構，（例如採用列表形式）；二是驗證每個特有的需求是否被規定了多餘一次，有沒有如何冗餘的說明？（可以考慮採用交叉引用表避免重複）；三是驗證是否有一套規則用來在餘下的軟件生命週期裏對《軟件需求規格說明》進行維護，（這很重要，原則上講，SRS不是可以隨便修改的）。
8． 其他方面的驗證
主要包括以下幾個方面內容：一是驗證《軟件需求規格說明》編寫格式是否符合相應的規範或標準（如GB 8567-88、或GJB1091-91）；二是驗證需求中提出的算法和方法方面的需求項是否有科技文獻或其他文獻作爲基礎；三是驗證《軟件需求規格說明》中是否出現“待定”之類的不確定性詞彙，如果出現，是否註明是何種原因導致的不確定性。
對於一箇中型軟件項目而言，以上驗證項絕大多數是必須的，各測試團隊可以根據項目的實際工程環境對此做裁減和細化。需求驗證的執行應該遵循“策劃→執行→檢查→評估”的順序完成。驗證採取的形式可以是走查、審查、會議評審以及用戶正式、非正式會議。不管採用哪種形式，上述驗證的內容應該儘量覆蓋到。
概要設計是軟件開發過程中決定軟件產品質量的關鍵階段。這個階段設計人員需要站在全局的高度，在比較抽象的層次上分析、對比多種可能的系統實現方案和多種可能的軟件體系結構，從中選出最佳的方案和最合理的軟件結構。概要設計驗證在這個階段是非常必要的，通過驗證可以確保《軟件設計說明書》中所描述的軟件概要設計在總體結構、外部接口、主要部件功能分配、全局數據結構以及各主要部件之間的接口等方面的合適性、完整性，從而以保證用較低的成本開發出較高質量的軟件系統。
1.1概要設計驗證的主要內容
（1）設計系統在項目軟件中所處的層次結構描述是否準確以及在本設計系統中的指導性作用。
重點驗證以下兩個方面：
一是驗證《概要設計規格說明》中對所要設計的系統在整個項目軟件（或在大系統中）中所處的地位、作用，及其與同級、上級系統之間的關係描述是否準確；二是《概要設計規格說明》是否可以作爲《詳細設計規格說明》撰寫的基礎性文檔是否對《詳細設計規格說明》具有指導性作用。
（2） 驗證系統描述是否具有可追溯性
重點驗證以下四個方面
一是驗證《概要設計規格說明》的每一部分的設計是否都可以追溯到《軟件需求說明書》、《接口設計說明書》或其他開發文檔；二是驗證非功能需求項（如：接口需求、操作需求、資源需求、可靠性需求、安全性需求等）是否已經分配到《概要設計規格說明》中。三是驗證對《軟件需求說明書》中不完整、易變動或潛在的需求項是否都進行了相應的設計分析，對各種設計限制是否做了全面的考慮；四是驗證《概要設計說明書》中模塊的規格及大小劃分是否和《軟件需求說明書》中的功能需求項以及約束性需求項之間保持一致。
（3）驗證總體設計是否合理
重點驗證以下五個方面：
一是檢查《概要設計規格說明》的設計目標描述是否明確清晰；二是檢查《概要設計規格說明》是否闡述了設計所依賴的運行環境，並覈對是否和《軟件需求規格說明》中規定的運行環境相一致；三是檢查《概要設計規格說明》中的業務邏輯是否準確並且完備；四是《概要設計規格說明》中是否對不同的設計方案作了介紹並比較，是否有選擇方案的結論，是否清楚闡述了方案選擇的理由。五是檢查
《概要設計規格說明》是否合理地劃分了模塊並對各模塊之間的關係作了清晰的闡述。六是檢查《概要設計規格說明》中給出的系統設計結構和數據處理流程是否能滿足軟件需求規格說明中所要求的全部功能性需求。
（4）接口設計是否合理
重點驗證以下幾個方面：
一是驗證《概要設計規格說明》中用戶接口設計是否正確全面，是否有單獨的用戶界面設計文檔；二是驗證《概要設計規格說明》是否包含有硬件接口設計，硬件接口設計是否正確且全面；三是驗證概要設計規格說明是否包含有軟件接口設計，軟件接口設計是否正確且全面；四是驗證《概要設計規格說明》是否包含有通信接口設計，通信接口設計是否正確且全面；五是驗證《概要設計規格說明》是否描述了各類接口的功能、各接口與其他接口或模塊之間的關係已經接口的設計是否具有可測試性。
（5） 驗證模塊及模塊內部分的設計是否合理
重點驗證以下四個方面：
一是驗證模塊的劃分是合適（如：代碼規模是否適中？是否便於協同開發？）、模塊與模塊之間是否具有一定的獨立性（如：模塊與模塊之間應做到低耦合，模塊設計應做到高內聚）。二是驗證每個模塊的功能和接口定義是否正確（如：數據的輸入輸出、模塊間的通信等等）。三是驗證數據結構的定義（比如面向對象編程中的數據封裝是否適當？繼承的使用是否合適？各方法中的的參數定義及使用是否適當？各數據項的數據類型是否適當？數據項的初始值設定和值域範圍是否有考慮？等等）是否正確。四是驗證模塊內的數據流和控制流的定義（如：串行操作和並行操作、同步和異步等）是否正確。
（6） 驗證概要設計是否包含相關屬性設計
重點驗證以下幾個方面：
一是驗證《概要設計規格說明》中是否有可靠性設計，設計是否合理、有效；二是驗證概要設計規格說明中是否有安全性設計，設計是否合理、有效；三是驗證《概要設計規格說明》中是否有可維護性設計，設計是否合理、有效；四是驗證《概要設計規格說明》中是否有可移植性設計，設計是否合理、有效。五是驗證《概要設計規格說明中》是否有可測試性設計，設計是否合理、有效。六是驗證是否對上述屬性設計進行了性能分析，是否有論證過程的性能數據。
（7） 驗證計算機資源的利用和餘量設計是否合理
重點驗證《概要設計規格說明》是否對餘量設計做了相應考慮。包括：CPU的處理能力要求是否留有餘量；內存的容量要求是否留有餘量；外存儲設備的容量要求是否留有餘量；算法的效率是否可接受；安全關鍵軟件部件發生故障時是否有快速恢復能力等等。
以上我們討論了概要設計驗證的一般性內容，各測試團隊可以根據待測項目的規模進行裁減和細化。概要設計在執行中採取的形式以評審會形式爲多，也可以採用非正式審查或內部專題會議的形式進行。由於概要設計的驗證在很大程度上與軟件需求規格說明的內容有關，建議聘請軟件需求規格說明的起草人蔘與到概要設計的驗證活動中來。
|
|
需求驗證主要是分析需求規格說明的正確性和可行性，檢驗需求是否反映客戶的意願，從而確定能否轉入概要設計階段；而概要設計驗證主要是檢查《概要設計規格說明》是否滿足《軟件需求規格說明》的各項要求，設計是否合理，是否可以據此產生《詳細設計規格說明》，並確定能否轉入詳細設計階段。
軟件需求驗證
如果在構造設計開始之前，通過驗證基於需求的測試計劃和原型測試來驗證需求的正確性及其質量，就能大大減少項目後期的返工現象。而如果在後續的開發或當系統投入使用時才發現需求文檔中的錯誤，就會導致更大代價的返工，因爲需求的變化總會帶來系統設計和實現的改變，從而使系統必須重新測試，由需求問題對系統做變更的成本比修改設計或代碼錯誤的成本要大得多。需求的驗證過程主要是檢查需求規格說明，這個過程中要對需求文檔中定義的需求執行多種類型的驗證，主要包括：
1． 有效性驗證
有效性驗證是指開發人員和用戶應該對需求進行認真地複查，以確保將用戶的需要充分、正確地表達出來，並且對於提出的每項需求，必須保證它確實能夠滿足用戶的需要、解決用戶的問題。
2． 一致性驗證
一致性是指需求之間以及需求和相應的規範或標準之間不應該出現衝突，對同一個系統功能不應出現不同的描述或矛盾的約束。一致性驗證主要包括四方面內容：一是驗證各個需求之間是否一致，是否有衝突或矛盾；二是驗證《軟件需求規格說明》中規定的模型、算法和數值方法相互是否兼容；三是驗證《軟件需求規格說明》中所採用的技術和方法是否與用戶要求的技術及方法保持一致；四是驗證需求的軟硬件接口是否具有兼容性。
3． 完備性驗證
完備性驗證是指檢查需求文檔是否包括用戶需要的所有功能和約束，滿足用戶的所有要求。一個完備的需求文檔應該對所有可能的狀態、狀態變化、轉入、約束都進行了完整、準確的描述。主要包括以下六個方面的內容：一是驗證《軟件需求規格說明》是否包括了所有需求，並且是否按優先級作了排序；二是驗證《軟件需求規格說明》是否明確規定了哪些是絕對不能發生的故障或設計缺陷；三是驗證《軟件需求規格說明》中出現所有的需求項是否都被列入需求描述表，在這張表中各需求項是否都被編號並能支持索引或回溯；四是驗證《軟件需求規格說明》中出現的各種圖表、表格是否都有標號，各類專業術語及測量單位是否都給出了相應的定義或引用的標準化文件；五是驗證軟件需求規格說明中時間關鍵性功能是否都被清晰地標識出來了，對時間的具體要求是否作了規定。六是驗證功能需求部分是否包括了對所有異常的響應（尤其是對各種有效的、無效的輸入值的響應規定），對各種操作模式（如：正常、非正常、有干擾等）下的環境條件、系統響應時間等是否都作了相應的規定。
4． 可行性驗證
可行性驗證是指根據現有的軟硬件技術水平和系統的開發預算、進度安排，對需求的可行性進行驗證，以保證所有的需求都能實現。
可行性驗證主要包括以下三方面的內容：一是驗證《軟件需求規格說明》中定義的需求對軟件的設計、實現、運行和維護而言是否是可行的；二是驗證《軟件需求規格說明》中規定的模型、算法和數值方法對於要解決的問題而言是否合適，他們是否能夠在給定的約束條件下實現；三是驗證約束性需求中所規定的質量屬性是個別地還是成組地可以達到。
5． 可驗證性驗證
可驗證性是指爲了減少客戶和開發商之間可能產生的爭議，系統需求應該能夠通過一系列檢查方法來進行驗證，以確定交付的系統是否滿足需要。
可驗證性驗證主要包括以下三個方面的內容：一是驗證各個需求項是否能夠通過測試軟件產品和軟件開發文檔來證明這些需求項已經被實現；二是驗證各個需求項描述是否清楚、最好能量化。避免使用模糊不清的詞彙；三是驗證《軟件需求規格說明》中每一個需求是否都對應於一個驗證方法。
6．可跟蹤性驗證
可跟蹤性是指需求的出處應該被清晰地記錄，每一項功能都能夠追溯到要求它的需求，每一項需求都能追溯到用戶的要求。可跟蹤性驗證主要包括以下三方面的內容：一是驗證每個需求項是否都具有唯一性並且被唯一標識，以便被後續開發文檔引用；二是驗證在需求項定義描述中是否都明確地註明了該項需求源於上一階段中哪個文檔，包含該文檔中哪些有關需求和設計約束；三是驗證是否可以從上一階段的文檔中找到需求定義中的相應內容。
7． 可調節性驗證
可調節性是指需求的變更不會對其他系統帶來大規模的影響。可調節性驗證主要包括以下三方面的內容：一是驗證需求項是否被組織成可以允許修改的結構，（例如採用列表形式）；二是驗證每個特有的需求是否被規定了多餘一次，有沒有如何冗餘的說明？（可以考慮採用交叉引用表避免重複）；三是驗證是否有一套規則用來在餘下的軟件生命週期裏對《軟件需求規格說明》進行維護，（這很重要，原則上講，SRS不是可以隨便修改的）。
8． 其他方面的驗證
主要包括以下幾個方面內容：一是驗證《軟件需求規格說明》編寫格式是否符合相應的規範或標準（如GB 8567-88、或GJB1091-91）；二是驗證需求中提出的算法和方法方面的需求項是否有科技文獻或其他文獻作爲基礎；三是驗證《軟件需求規格說明》中是否出現“待定”之類的不確定性詞彙，如果出現，是否註明是何種原因導致的不確定性。
對於一箇中型軟件項目而言，以上驗證項絕大多數是必須的，各測試團隊可以根據項目的實際工程環境對此做裁減和細化。需求驗證的執行應該遵循“策劃→執行→檢查→評估”的順序完成。驗證採取的形式可以是走查、審查、會議評審以及用戶正式、非正式會議。不管採用哪種形式，上述驗證的內容應該儘量覆蓋到。
概要設計是軟件開發過程中決定軟件產品質量的關鍵階段。這個階段設計人員需要站在全局的高度，在比較抽象的層次上分析、對比多種可能的系統實現方案和多種可能的軟件體系結構，從中選出最佳的方案和最合理的軟件結構。概要設計驗證在這個階段是非常必要的，通過驗證可以確保《軟件設計說明書》中所描述的軟件概要設計在總體結構、外部接口、主要部件功能分配、全局數據結構以及各主要部件之間的接口等方面的合適性、完整性，從而以保證用較低的成本開發出較高質量的軟件系統。
1.1概要設計驗證的主要內容
（1）設計系統在項目軟件中所處的層次結構描述是否準確以及在本設計系統中的指導性作用。
重點驗證以下兩個方面：
一是驗證《概要設計規格說明》中對所要設計的系統在整個項目軟件（或在大系統中）中所處的地位、作用，及其與同級、上級系統之間的關係描述是否準確；二是《概要設計規格說明》是否可以作爲《詳細設計規格說明》撰寫的基礎性文檔是否對《詳細設計規格說明》具有指導性作用。
（2） 驗證系統描述是否具有可追溯性
重點驗證以下四個方面
一是驗證《概要設計規格說明》的每一部分的設計是否都可以追溯到《軟件需求說明書》、《接口設計說明書》或其他開發文檔；二是驗證非功能需求項（如：接口需求、操作需求、資源需求、可靠性需求、安全性需求等）是否已經分配到《概要設計規格說明》中。三是驗證對《軟件需求說明書》中不完整、易變動或潛在的需求項是否都進行了相應的設計分析，對各種設計限制是否做了全面的考慮；四是驗證《概要設計說明書》中模塊的規格及大小劃分是否和《軟件需求說明書》中的功能需求項以及約束性需求項之間保持一致。
（3）驗證總體設計是否合理
重點驗證以下五個方面：
一是檢查《概要設計規格說明》的設計目標描述是否明確清晰；二是檢查《概要設計規格說明》是否闡述了設計所依賴的運行環境，並覈對是否和《軟件需求規格說明》中規定的運行環境相一致；三是檢查《概要設計規格說明》中的業務邏輯是否準確並且完備；四是《概要設計規格說明》中是否對不同的設計方案作了介紹並比較，是否有選擇方案的結論，是否清楚闡述了方案選擇的理由。五是檢查
《概要設計規格說明》是否合理地劃分了模塊並對各模塊之間的關係作了清晰的闡述。六是檢查《概要設計規格說明》中給出的系統設計結構和數據處理流程是否能滿足軟件需求規格說明中所要求的全部功能性需求。
（4）接口設計是否合理
重點驗證以下幾個方面：
一是驗證《概要設計規格說明》中用戶接口設計是否正確全面，是否有單獨的用戶界面設計文檔；二是驗證《概要設計規格說明》是否包含有硬件接口設計，硬件接口設計是否正確且全面；三是驗證概要設計規格說明是否包含有軟件接口設計，軟件接口設計是否正確且全面；四是驗證《概要設計規格說明》是否包含有通信接口設計，通信接口設計是否正確且全面；五是驗證《概要設計規格說明》是否描述了各類接口的功能、各接口與其他接口或模塊之間的關係已經接口的設計是否具有可測試性。
（5） 驗證模塊及模塊內部分的設計是否合理
重點驗證以下四個方面：
一是驗證模塊的劃分是合適（如：代碼規模是否適中？是否便於協同開發？）、模塊與模塊之間是否具有一定的獨立性（如：模塊與模塊之間應做到低耦合，模塊設計應做到高內聚）。二是驗證每個模塊的功能和接口定義是否正確（如：數據的輸入輸出、模塊間的通信等等）。三是驗證數據結構的定義（比如面向對象編程中的數據封裝是否適當？繼承的使用是否合適？各方法中的的參數定義及使用是否適當？各數據項的數據類型是否適當？數據項的初始值設定和值域範圍是否有考慮？等等）是否正確。四是驗證模塊內的數據流和控制流的定義（如：串行操作和並行操作、同步和異步等）是否正確。
（6） 驗證概要設計是否包含相關屬性設計
重點驗證以下幾個方面：
一是驗證《概要設計規格說明》中是否有可靠性設計，設計是否合理、有效；二是驗證概要設計規格說明中是否有安全性設計，設計是否合理、有效；三是驗證《概要設計規格說明》中是否有可維護性設計，設計是否合理、有效；四是驗證《概要設計規格說明》中是否有可移植性設計，設計是否合理、有效。五是驗證《概要設計規格說明中》是否有可測試性設計，設計是否合理、有效。六是驗證是否對上述屬性設計進行了性能分析，是否有論證過程的性能數據。
（7） 驗證計算機資源的利用和餘量設計是否合理
重點驗證《概要設計規格說明》是否對餘量設計做了相應考慮。包括：CPU的處理能力要求是否留有餘量；內存的容量要求是否留有餘量；外存儲設備的容量要求是否留有餘量；算法的效率是否可接受；安全關鍵軟件部件發生故障時是否有快速恢復能力等等。
以上我們討論了概要設計驗證的一般性內容，各測試團隊可以根據待測項目的規模進行裁減和細化。概要設計在執行中採取的形式以評審會形式爲多，也可以採用非正式審查或內部專題會議的形式進行。由於概要設計的驗證在很大程度上與軟件需求規格說明的內容有關，建議聘請軟件需求規格說明的起草人蔘與到概要設計的驗證活動中來。
|