概論：
需求首先是客戶在項目立項時就有的一個愿景，而后不斷的細化。形成實現(xiàn)愿景的具體的活動。 在細化的過程中，方式1：客戶通過不斷的調(diào)查相同的案例，并結(jié)合自身的實際情況，形成細化的需求方案（客戶自己形成需求規(guī)格，而后交給承辦方進行開發(fā)）。方式2：客戶通過和多家承辦方接觸溝通，根據(jù)自身的愿景、約束、業(yè)務(wù)規(guī)則，并結(jié)合承辦方的建議，現(xiàn)成細化的需求方案。
客戶根據(jù)需求還會決定，在整個項目的需求中，要承辦方具體要做些什么（即承辦方的任務(wù)， 承辦方具體要實現(xiàn)哪些需求）。
形成了彼此認可的需求方案后，一般承辦方就可以估計出整個項目的資金、進度、初步的活動規(guī)劃。并同客戶方協(xié)商形成合同。 需求規(guī)格書講作為合同的附件。在今后發(fā)生合同爭議時需求規(guī)格書將作為重要的依據(jù)。
承辦方在明確了需求后，就會開始后期的涉及、開發(fā)、測試、部署等工作。在后期的項目實施的過程中，由于承辦方（發(fā)現(xiàn)某個具體需求無法實現(xiàn) 或于另一個需求矛盾）或客戶方（業(yè)務(wù)規(guī)整變化、 想要增加一個功能）的原因，需求都會被變更。需求的變更將引起進度、費用、驗收標準的變化。 故需求的變更要被嚴格的管理，要得到雙方的認可。這就是需求的變更管理。
同時為了可以方便的明確后期的需求變更會造成多大的影響（進度、費用），在對于具體的需求項上要跟蹤實現(xiàn)需求做了些什么工作、工作產(chǎn)品是什么、已經(jīng)花費的時間、費用多少。這樣當一個需求項被要求變更時，可以正確的估計損失， 以及追加的資源。
需求項的實現(xiàn)被跟蹤記錄的另一個好處時，當被完整記錄后，記錄的數(shù)據(jù)可以作為項目后期評估使用。以及作為歷史參考數(shù)據(jù)，為下一個項目工作量、進度、成本的估計提供數(shù)據(jù)。
明確需求層次：（重要，且與合同的制定，報價模式的制定密切相關(guān)）
項目的不同，客戶會提出不同層次的需求。根據(jù)不同層次的需求，在需求的獲取和管理階段會有不同的要求。
情況1：客戶只是有個目標，希望通過供應(yīng)商提供一套軟件系統(tǒng)可以解決問題。 在這種情況下，其實客戶需要的是對于實現(xiàn)目標的解決方案，是個包括業(yè)務(wù)模型以及相應(yīng)軟件系統(tǒng)的整體方案。 在這種情況下，需求包含兩個部分的內(nèi)容，其一：業(yè)務(wù)建模； 其二：軟件需求；在這種情況下，同用戶達成一致的首先是用戶的業(yè)務(wù)模型。其后，編寫實現(xiàn)業(yè)務(wù)模型中軟件任務(wù)的軟件需求。軟件需求也會和用戶確認，用戶驗證軟件需求是否全部包含了業(yè)務(wù)模型中的對于軟件的任務(wù)，以及是否考慮到了用戶的約束條件。用戶驗收時，是根據(jù)軟件需求說明，驗收軟件是否完成了軟件需求。同時也會求證供應(yīng)商提出的業(yè)務(wù)模型是否實現(xiàn)了目標或者是否可以運作。
在沒有完成業(yè)務(wù)模型的確認前，無法了解軟件的規(guī)模，無法完成報價。合同可以簽署為兩階段合同，階段一：業(yè)務(wù)建模，采用時間－原料法進行報價； 階段二：軟件開發(fā)，采用固定價格法。 另一種情況： 若供應(yīng)商提供的是產(chǎn)品（價格固定），可以采用固定價格＋額外費用的方法。
情況2：客戶有目標，同時也有了業(yè)務(wù)領(lǐng)域的解決方案。需要軟件供應(yīng)商提供的是一個可以完成業(yè)務(wù)模型中任務(wù)的軟件。在這種情況下，客戶明確了解要些什么功能，輸入、輸出、處理。 在此情況下，供應(yīng)商就是提供軟件需求，并同客戶就需求達成一致。（其實是對軟件做些什么，如何做達成一致）。在需求的確認上會力求細致準確。在項目完成的驗收時，驗證軟件是否完成了軟件需求。
在完成了需求的簽署后，一般可以估計出工作量，合同可以采取固定報價法。
情況3： 客戶有目標，也有了解決方案，并且也告訴供應(yīng)商關(guān)于設(shè)計層的要求。要求供應(yīng)商按要求完成。 這種情況，一般出現(xiàn)在項目的維護階段， 比如客戶要求增加一個報表。 也會出現(xiàn)在Coding外包項目上，客戶有詳細的界面設(shè)