「需求工程」需求工程——需求驗證(第4部分)

確保規定要求知足客戶需求的過程。

需求驗證

它是一個確保特定需求知足客戶需求的過程。它關心的是找到需求中的問題。

當這些問題在後期發現時，或者在系統投入使用後，這些問題會致使大量的返工成本。

經過系統變動來修復需求問題的成本一般比修復設計或代碼錯誤的成本要大得多。由於對需求的更改一般意味着設計和實現也必須更改，並從新測試。

在需求驗證過程當中，應對需求進行不一樣類型的檢查。這些檢查包括:

• 有效性檢查:涉衆提出的功能應該與系統須要執行的功能保持一致。稍後您可能會發現須要其餘或不一樣的功能。

• 一致性檢查:文檔中的需求不該該衝突或同一功能的不一樣描述

• 完整性檢查:文檔應該包括全部的需求和約束。

• 真實性檢查:確保需求可以利用現有技術、預算、進度等方面的知識實際實現。

• 可驗證性:編寫需求時應該讓它們可以被測試。這意味着您應該可以編寫一組測試來證實系統知足指定的需求。

您可使用一些技術來驗證需求，根據您的須要，您能夠同時使用其中的一個或多個。

需求評審

系統客戶團隊;那些與客戶交互以收集需求的人，以及系統開發人員開始閱讀文檔中的需求，並進行詳細調查，以檢查錯誤、不一致、衝突和任何不明確之處。

而後他們可能會與客戶協商如何解決發現的問題和錯誤。

原型設計

咱們已經討論了做爲(非獨立的)軟件過程方法之一的原型設計，它被用做完整方法的一部分，而且咱們還在需求工程中提到了它。

在這種驗證方法中，系統的可執行模型被向客戶和最終用戶進行驗證，並確保它是否知足他們的須要。

原型設計一般在需求不明確時使用。爲此，咱們對系統進行了快速設計，以驗證需求。若是失敗了，咱們就改進它，並再次檢查，直到它知足客戶的需求。

這確定會下降成本，由於有一個清晰的、能夠理解的、一致的需求。

測試用例的生成

正如咱們剛纔提到的，需求須要是可測試的。若是需求測試是做爲驗證過程的一部分添加的，這一般會揭示需求問題。

若是a測試很難或不可能設計，這一般意味着需求將很難實現，應該從新考慮。

這裏的術語「測試」並不意味着爲每一個函數編寫和運行一些代碼。它意味着編寫執行每一個功能的「輸入」、「指望值」和「採起的步驟」的文本描述。

這是一個測試用例的模板。

測試用例模板

要證實一組需求確實知足了用戶的需求是很困難的。由於用戶須要在操做中使用系統，並想象該系統將如何適應他們的工做。所以，進一步的需求變化是不可避免的。