：
系統(tǒng)準確性需求：
安全性：
需求變更：
在需求被客戶簽署后，任何的變動都將納入到需求變更中。需求的變更不但是要記錄好變更，還要保證變更的需求，被實現(xiàn)。故在對于變更的評估當中，還要確認影響的其他工作產(chǎn)品。
需求的變更的另一個難點在于費用的確認上，一般客戶會很容易的接收變更所提出的技術(shù)方案，但是在對于變革造成的損失以及追加的費用方面難于確認。這個首先將取決于需求跟蹤表的建立，讓客戶明確在目前的時間點，需求已經(jīng)被實現(xiàn)到什么階段，已經(jīng)花費的成本。其次取決于合同中規(guī)定的變更需求工作量的核算方法。
流程如下：
需求跟蹤：
確認：
目標?--------------à業(yè)務(wù)領(lǐng)域?-------------------à需求
驗證：
需求?------------à 設(shè)計、編程、用戶文檔 ?---------------à 運行
需求的跟蹤是通過‘需求跟蹤矩陣’維護工作產(chǎn)品間的關(guān)系， 通過評審制度，檢查需求是否被實現(xiàn)。
客戶驗證：
客戶對于需求的驗證，包括事前、和事后兩個部分。 事前是指對于供應(yīng)商寫的需求進行檢查和確認。 事后是指對于產(chǎn)出的產(chǎn)品進行驗收。
對于事前需求的檢查和確認，一個是通過場景的排演，模擬業(yè)務(wù)模型的每個工作場景中的工作任務(wù)和特殊情況，在需求中都有體現(xiàn)。另一個是同需求編寫的質(zhì)量標準進行檢查。
質(zhì)量標準：
正確；
完整；
無歧意
一致
確定重要性、穩(wěn)定性等級
可驗證
可追溯；
變更被記錄；
對于事后的驗證，大多通過UAT測試和系統(tǒng)試運行完成。依據(jù)是需求，具體的做法將在VAL中討論。
備注： 客戶往往無法確認產(chǎn)品的事件列表和功能列表，但是可以確認業(yè)務(wù)領(lǐng)域的事件和任務(wù)。
項目收尾結(jié)算：
這個階段主要是根據(jù)驗收的情況，明確需求遺留的問題。以及后期的方案。另外對于因為需求變更引起的實際費用的增加也要和客戶進行說明和結(jié)算。
當然若是對于產(chǎn)品型的項目，更有一個需求總結(jié)和提煉的過程。要重新對于所有需求進行優(yōu)先級的排序，提煉出行業(yè)通用的‘行業(yè)軟件需求列表’，比如‘服侍門店管理系統(tǒng)需求列表’。同時要評估需求的變更，對于雙方誤解引起的需求變更要求整理成‘問題調(diào)查表’。當下一個同行業(yè)軟件開發(fā)時，就可以根據(jù)‘問題調(diào)查表’把問題澄清。同時這些總結(jié)的資料可以更好的支持銷售和售前的咨詢。
參考文獻：
Soren Lauesen 《軟件需求》 電子工業(yè)出版社