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