概論：
需求首先是客戶在專案立項時就有的乙個願景，而後不斷的細化。形成實現願景的具體的活動。 在細化的過程中，方式1：客戶通過不斷的調查相同的案例，並結合自身的實際情況，形成細化的需求方案（客戶自己形成需求規格，而後交給承辦方進行開發）。方式2：客戶通過和多家承辦方接觸溝通，根據自身的願景、約束、業務規則，並結合承辦方的建議，現成細化的需求方案。
客戶根據需求還會決定，在整個專案的需求中，要承辦方具體要做些什麼（即承辦方的任務， 承辦方具體要實現哪些需求）。
形成了彼此認可的需求方案後，一般承辦方就可以估計出整個專案的資金、進度、初步的活動規劃。並同客戶方協商形成合同。 需求規格書講作為合同的附件。在今後發生合同爭議時需求規格書將作為重要的依據。
承辦方在明確了需求後，就會開始後期的設計、開發、測試、部署等工作。在後期的專案實施的過程中，由於承辦方（發現某個具體需求無法實現 或於另乙個需求矛盾）或客戶方（業務規整變化、 想要增加乙個功能）的原因，需求都會被變更。需求的變更將引起進度、費用、驗收標準的變化。 故需求的變更要被嚴格的管理，要得到雙方的認可。這就是需求的變更管理。
同時為了可以方便的明確後期的需求變更會造成多大的影響（進度、費用），在對於具體的需求項上要跟蹤實現需求做了些什麼工作、工作產品是什麼、已經花費的時間、費用多少。這樣當乙個需求項被要求變更時，可以正確的估計損失， 以及追加的資源。
專案的不同，客戶會提出不同層次的需求。根據不同層次的需求，在需求的獲取和管理階段會有不同的要求。
情況1：客戶只是有個目標，希望通過**商提供一套軟體系統可以解決問題。 在這種情況下，其實客戶需要的是對於實現目標的解決方案，是個包括業務模型以及相應軟體系統的整體方案。 在這種情況下，需求包含兩個部分的內容，其一：業務建模； 其二：軟體需求；在這種情況下，同使用者達成一致的首先是使用者的業務模型。其後，編寫實現業務模型中軟體任務的軟體需求。軟體需求也會和使用者確認，使用者驗證軟體需求是否全部包含了業務模型中的對於軟體的任務，以及是否考慮到了使用者的約束條件。使用者驗收時，是根據軟體需求說明，驗收軟體是否完成了軟體需求。同時也會求證**商提出的業務模型是否實現了目標或者是否可以運作。
在沒有完成業務模型的確認前，無法了解軟體的規模，無法完成**。合同可以簽署為兩階段合同，階段一：業務建模，採用時間－原料法進行**； 階段二：軟體開發，採用固定**法。 另一種情況： 若**商提供的是產品（**固定），可以採用固定**＋額外費用的方法。
情況2：客戶有目標，同時也有了業務領域的解決方案。需要軟體**商提供的是乙個可以完成業務模型中任務的軟體。在這種情況下，客戶明確了解要些什麼功能，輸入、輸出、處理。 在此情況下，**商就是提供軟體需求，並同客戶就需求達成一致。（其實是對軟體做些什麼，如何做達成一致）。在需求的確認上會力求細緻準確。在專案完成的驗收時，驗證軟體是否完成了軟體需求。
在完成了需求的簽署後，一般可以估計出工作量，合同可以採取固定**法。
情況3： 客戶有目標，也有了解決方案，並且也告訴**商關於設計層的要求。要求**商按要求完成。 這種情況，一般出現在專案的維護階段， 比如客戶要求增加乙個報表。 也會出現在coding外包專案上，客戶有詳細的介面設計、中間的處理過程，**商完成實現。這時需求更多的是，驗證客戶提出的需求是否可以實現，把客戶的需求更細化，補充完整，同時需求中要包含客戶對於設計的要求。 客戶和**商直接對軟體需求達成一致。在專案完成的驗收時，驗證軟體是否完成了軟體需求。
由於對工作量可以比較精確的估計，合同可以採用固定**法。
需求匯出：
當專案開始時，往往客戶的it部門會作為最初的溝通者和**商溝通，並傳達客戶方的需求。在系統開發、實施、維護的很長時間內也會作為乙個客戶方需求的提出視窗於**商聯絡。但真正的需求並不在it部門手裡。而且最後的驗收，也是由終端使用者確定。
因此，需求的匯出一定要抓住關鍵人物（決定需求的人）。
1、組建需求團隊
**商需求團隊： 專案經理；系統分析人員； 開發及測試技術骨幹；
在這個團隊中要解決需求的獲取， 需求的確認， 需求變更的決策（是否接收變更， 變更的影響的認可），業務流程重組的決定和方案， 系統根據需求的驗收。
2、通過各種匯出技術獲得需求
乙個完整詳細的需求，是通過一系列的中間產品推斷出來的。
中間工作成果：
? 業務領域的當前工作說明；
? 業務領域的當前問題；
? 目標、關鍵問題；
? 未來系統的構想；
? 後果和風險；
? 相關人員認可； 相關人員衝突協議；
? 需求優先順序；
? 最終需求；
? 需求是否完備和必要；
工作方式：
? 訪談： 用於高層了解目標、未來構想；
? 任務示範：了解業務領域的當前工作說明；業務領域的當前問題；
? 專題討論會：相關人員衝突協議；需求優先順序；關鍵問題；後果和風險；bpr的決定；最終需求；需求是否完備和必要；
? 問卷調查： 分析人員無法到場情況下可採用，了解初步需求。
需求編寫：
資料需求： 描述進出系統的資料。
? e/r 圖： 優點：直接轉化成資料庫設計； 缺點：太專業，使用者無法確認
? 資料字典： 優點：客戶捕獲大量細節，使用者易理解； 缺點：編寫工作量大；
? 虛擬介面： 優點：可直接從手工表單獲得，使用者易理解，完成部分介面的設計和確認； 缺點：容易過於的細化為介面設計。
功能需求：記錄使用者如何進入系統對功能模組進行操作，輸入、處理、輸出。
? 用例的事件說明： 說明具體功能模組的人、機職責劃分。
備註： 由於用例的事件流的說明中已經包含了設計層的需求， 故作為驗證是否實現了業務領域的任務是很好的，同時也可以作為後期操作手冊和測試用例的基礎資料使用。但是過於的細化，不宜作為產品的介紹、給予客戶驗收的需求規格使用。 給予客戶的需求規格可以使用細化些的總用例圖（用例包＋功能列表）
功能細節：複雜功能的描述； 有特別演算法；出錯糾正；業務規則；報表；
特性需求：客戶業務處理中非常規的情況。 以及處理方式。
是整合測試和驗收測試的乙個重點。 同時，特性需求容易在一開始的需求匯出時遺漏。 特性需求往往會產生乙個新功能分支或特別的設計。故越早發現越好。
螢幕顯示和原型：可以先期進行可用性測試。故對於可用性非常關注的新開發系統，可用採用原型方法。在採用商業成品時，在需求時定義介面就為時過早。
任務說明：描述業務領域的需求，適用於成品專案的介紹。體現為用例的概要描述（用例做什麼的，由哪些任務組成）
任務及支援：描述業務領域的需求，以及產品的解決方案。 適用於成品專案的介紹（售前）。同時也適用於成品專案二次開發前期同客戶進行確認需求時的成品介紹。
補充需求：
質量：
效能：
維護：
平台需求：
產品整合：
系統準確性需求：
安全性：
需求變更：
在需求被客戶簽署後，任何的變動都將納入到需求變更中。需求的變更不但是要記錄好變更，還要保證變更的需求，被實現。故在對於變更的評估當中，還要確認影響的其他工作產品。
需求的變更的另乙個難點在於費用的確認上，一般客戶會很容易的接收變更所提出的技術方案，但是在對於變革造成的損失以及追加的費用方面難於確認。這個首先將取決於需求跟蹤表的建立，讓客戶明確在目前的時間點，需求已經被實現到什麼階段，已經花費的成本。其次取決於合同中規定的變更需求工作量的核算方法。
流程如下：
需求跟蹤：
確認：
目標?--------------?業務領域?-------------------?需求
驗證：
需求?------------? 設計、程式設計、使用者文件 ?---------------? 執行
需求的跟蹤是通過『需求跟蹤矩陣』維護工作產品間的關係， 通過評審制度，檢查需求是否被實現。
客戶驗證：
客戶對於需求的驗證，包括事前、和事後兩個部分。 事前是指對於**商寫的需求進行檢查和確認。 事後是指對於產出的產品進行驗收。
對於事前需求的檢查和確認，乙個是通過場景的排演，模擬業務模型的每個工作場景中的工作任務和特殊情況，在需求中都有體現。另乙個是同需求編寫的質量標準進行檢查。
質量標準：
? 正確；
? 完整；
? 無歧意
? 一致
? 確定重要性、穩定性等級
? 可驗證
? 可追溯；
? 變更被記錄；
對於事後的驗證，大多通過uat測試和系統試執行完成。依據是需求，具體的做法將在val中討論。
備註： 客戶往往無法確認產品的事件列表和功能列表，但是可以確認業務領域的事件和任務。
專案收尾結算：
這個階段主要是根據驗收的情況，明確需求遺留的問題。以及後期的方案。另外對於因為需求變更引起的實際費用的增加也要和客戶進行說明和結算。
當然若是對於產品型的專案，更有乙個需求總結和提煉的過程。要重新對於所有需求進行優先順序的排序，提煉出行業通用的『行業軟體需求列表』，比如『服侍門店管理系統需求列表』。同時要評估需求的變更，對於雙方誤解引起的需求變更要求整理成『問題調查表』。當下乙個同行業軟體開發時，就可以根據『問題調查表』把問題澄清。同時這些總結的資料可以更好的支援銷售和售前的諮詢。
專案管理之需求管理
需求的變化問題 在軟體開發過程中如果只有一條真理的話，那一定是 需求的變化是永恆的，需求不可能是完備的。軟體開發的過程實際上是同變化做鬥爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業機會，對市場敏感的人可以從需求的變化中發現市場機會。需求變化的原因很多，如 一開始沒有識別全，需要增加需求 ...
專案管理使用者需求分析
使用者反饋分析 不過這種方式更適合於前台的產品，後台的產品主要使用使用者就是公司內部員工，或者是比較少的開放出去的管理員，這部分的使用者反饋相對來說容易收集的多，可以制定特別的渠道來獲取反饋。產品資料分析 還可參考一些公共調研機構出具的一些資料分析報告，比如艾瑞資訊等對網際網路行業裡面所做的一些資料...
談談專案和需求
你是否有過你的專案注定要失敗的感覺，也許你現在可以建議結束它，並且為出資人省下一些錢。1.挖掘需求的時候，要找出使用者為何做特定事的原因 而不只是他們目前做這件事的方式。你的開發必須解決他們的商業問題，而不只是滿足他們陳述的需求。2.成為產品的使用者。與使用者一樣工作，一樣思考。我們很容易被吸進 只...