就是對項目中描述的用戶需求的普遍理解，一旦理解了需求，分析者、開發(fā)者和用戶就能探索出描述這些需求的多種解決方案。
這一階段的工作一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，由于需求獲取事物造成的對需求定義的任何改動，都將導致設計、實現(xiàn)和測試上的大量返工，而這時花費的資源和時間將大大超過仔細精確獲取需求的時間和資源。
首先，軟件需求不能如實反映用戶的真正需要。比較常見的一種誤解是需求的簡單和復雜程度決定了用戶是否能夠真正理解相應的內容：誤認為客戶只能看懂簡單的需求，但是對開發(fā)沒有直接幫助；只有復雜的需求才有用，但是大多用戶又不可能看得懂。事實上，造成這類問題的主要原因是捕獲的需求不能反映用戶的視角，因而，用戶站在自己的立場上很難判斷需求是否完備和正確，特別是在開發(fā)活動的早期。
其次，軟件需求不能被開發(fā)團隊的不同工種直接共用。理論上，開發(fā)團隊所有成員的工作內容都受軟件需求制約；現(xiàn)實中，如果不采用理想的需求捕獲方式，只有分析人員的工作看起來和軟件需求的內容直接關聯(lián)，其它人的工作內容和軟件需求的關聯(lián)并不直觀，形式上的差異或轉述往往不易察覺地造成了諸多歧義、冗余或者缺失。
本文并不會就此開始探討需求開發(fā)的問題，只是強調需求開發(fā)過程的重要，以及需求開發(fā)過程對需求變更的影響。就拿筆者親身參與的一個項目來說：我們遵循一般的軟件開發(fā)過程，通過前期一段時間的調研，做需求分析，客戶基本確認之后，開發(fā)人員就投入到緊張的開發(fā)工作中，由于項目時間要求緊迫，在經過測試人員的簡單確認之后，進入到試運行階段。
結果是，在客戶的試運行報告中，提出了很多問題，其中就有一條，關于一個數(shù)據(jù)查詢條件的設置，客戶要求的是模糊匹配查詢，而實現(xiàn)的卻是精確匹配查詢。在相關的需求文檔中，卻找不到任何相關的需求說明。
需求開發(fā)完成之后，進入系統(tǒng)構建階段，下面我們來談構建過程中如何做好需求跟蹤，以便于后期需求變更的管理。