需求確認的方法和內容，瞭解一下
需求開發不是那麼好做的，有時候花費了不少時間和精力，也不一定理解了客戶的需求。所以，把需求開發的結果寫成需求規格說明，並不是需求開發的終點，最後也是最關鍵的是對需求的確認！
這也是在GJB5000A中把需求確認放在需求開發最後一個專用實踐的原因吧！
那麼需求確認就應該怎樣做呢？
在GJB5000A標準當中，給出了需求確認的方法：分析、模擬、演示。
-
分析
通過對需求規格說明的分析來確認軟體需求的方式，通常就是審查或評審。雖然全憑想像，但是有客戶和開發人員一起分析，應該可以實現確認的目的。
-
模擬
通過使用一種低保真的模型模擬軟體的方式來確認需求。由於有了可感知的東西，需求的確認更加可信。
-
演示
當具備了初步的軟體原型的時候，就可以通過軟體原型的演示對需求進行確認。這這種需求確認的方式可信度最高，因為他和將來軟體的使用場景非常接近。
-
正確性
需求描述必須是正確的。否則，實現的軟體就是錯誤的。而需求的正確性只能由客戶來確定。但是客戶的思維方式和開發人員完全不同，所以，要讓客戶做好需求正確性的確認，應當儘可能地使用客戶的語言描述或解釋需求，最好讓客戶感知到軟體的使用場景。
-
一致性
需求描述的一致性有幾個層次。首先是需求規格說明上下文的一致性。比如，對同一術語，上下文要保持一致。其次是與其他軟體需求或高層需求一致性。比如，與使用者需求的一致性；與非功能需求的一致性。
-
完整性
完整性也有兩個方面的含義。一是需求描述元素的完整性，包括狀態，狀態變化，轉入，產品和約束等。二是需求與客戶的期望相比是否有遺漏。這個層次的完整性在確認客戶需求的時候就應由客戶來做確認，在對需求規格說明進行確認時，也可以再次確認需求的完整性。
-
可行性
需求必須是可實現的。要綜合考慮技術水平、資源保障等多方面的因素。
-
必要性
客戶提出的需求不一定都是必要的。軟體開發人員應當從軟體幫助客戶解決的問題的終極目標出發，考慮技術和環境的限制，分析軟體的需求，確定哪些需求是必要的，哪些需求是冗餘的。
-
可測試性
軟體的需求一定是可測試的，否則就無法進行驗證和確認。需求的可測試性要求需求應當儘量採用量化的描述方式。
總結一下，需求確認就是通過分析、模擬或演示的技術手段，對需求規格說明中描述的需求的正確性、一致性、完整性、可行性、必要性、可測試性進行確認。