需求管理是專案管理的重點之一 ---- 專案範圍管理的重要組成部分，對於需求管理失敗，一直是導致it專案管理失敗的主要原因之一。
專案管理思想中核心強調的預則立，不預則廢，需求管理作為專案管理範圍管理的一部分，也同樣遵守本原則。
需 求的詳細工作包括了需求調研、需求分析與設計、需求確認、需求跟蹤維護以及需求變更管理等方面的內容，在專案生命週期的任一階段，都需要進行管理的管理。 因此需求的生命週期貫穿於專案的整體生命週期過程中，在專案啟動階段，也應該對需求進行當貫穿需求的生命週期的管理規劃，制訂詳細的需求管理的整體策略， 選擇適當的需求管理的方法、技術和工具，制訂明確的流程以各方的職責，以指導專案的需求管理工作。
（1）整個專案的需求實現的整體策略
當 啟動乙個專案時，需求管理作為專案範圍管理，是專案啟動工作的重要部分，對使用者需求的滿足程度，往往決定了專案質量，而如何控制專案的質量，提高使用者的滿 意度，使專案順利完成，在專案啟動時，應該了解使用者專案干係人對整體專案的總體需求，即是對整體專案的需求方面的要求。
比如：對既定的專案需求，建設的期望是什麼，達到什麼真正的可達成的目標？應用的期望是什麼？
每 乙個專案的使用者對專案的建設的期望與應用的期望都會有差異，甚至在一些涉及到範圍比較廣的專案中，同乙個使用者關鍵關係人對同乙個專案中的建設子項的建設期 望與應用期望都存在差異。對於這一點，往往我們從專案的招標書或者是合同書中並不能看出，但是，這種情況是實實在在存在的，有時候，使用者自己本身也不了 解，而是需要專案經理與使用者的專案負責人進行進一步的溝通、抽絲剝繭後再加以引導才能明確。也就是說，這是整個專案的專案需求的需求。
很 多時候，特別是一些涉及到資訊管理等方面，使用者的目標往往是不切實際，比較理想化，把前景想像得很美，特別是在資訊化建設方面沒有什麼經驗的使用者，這一點 尤其突出。如果我們的專案經理在這個時候，盲目的與使用者的理想目標保持一致的話，就可能把專案引入到乙個比較危險的環境。經驗豐富的專案經理，會充分認識 到同乙個目標也是需要分層次的。需要進一步與使用者的專案負責人明晰、分解專案的目標，確認可以達到的目標。
比如：對同乙個業務的處理，可以是備案式的規則簡單的、可以是備案式規則複雜的、可以是流程化規則簡單的、也可以嚴格流程化規則複雜的等多種不同程度的實現，這對於達成專案目標方面卻是一致的。
在 專案中，有可能選擇以上任何一種方式進行建設，但是，這每一種方式對專案成功建設的時間、成本、風險、資源要求、專案的成功率等方面的差異較大，明顯第一 種是最小的，而第四種則是最大的，那麼是否全部進行一種的選擇呢？這個問題，是專案經理在需求整體規劃時應該考慮的問題，但卻並不是專案經理可以決定。主 要是原因，由使用者的需求來決定，在這個過程中，專案經理可以影響和引導使用者的需求。
專案經理應當與使用者的專案負責人一起，分析專案背景、使用者背景（特別是資訊化方面的背景）、使用者應用層次與背景、使用者應用的環境等。
對於資訊化背景不同程度的使用者，使用者負責人在處理不同的業務時，會有不同的態度。這個主要是由客觀原因：使用者的資訊化背景與認識造成。對於資訊化比較強 的，使用者採用較多的通過業務重整與流程重構來通過資訊化提高業務處理水平以及資料處理水平；而對於資訊化相對比較弱的，則希望通過引導與初步應用，達到引 導資訊化建設的初步目標。試想如果將不具有紮實功底的使用者引入到乙個嚴格、流程化管理的產品中，即使開發商可以根據需求生產出來產品，但是在應用時，會遇 到很大的困難，從而造成專案的失敗。也就是說，生產出乙個複雜的產品，但是沒有人或只有少數人願意使用。
因此，我們專案經理在這個時候，應該對整體需求進行分析分解，與使用者的負責人員進行協商，定下整個專案需求的策略，從而在整體專案需求調研的過程中，安排需求工程師進行引導。
（2）整個專案在需求過程的活動中採用的方法、技術與工具的選擇
將使用者的需求了解明白，清楚，需要各類的方法、技術與工具。
從需求調研計畫開始，到完成多方簽字確認的需求規格說明書，包括了一系列的需求活動。在各種活動中，每次所採用的方法、技術與工具差異也較大，而不同的方 法、技術與工具所取得的效果也是不一樣。專案經理在需求管理規則時，根據專案質量和進度要求、使用者背景、專案組可以達到的程度來選擇各種需求活動的方法、 技術與工具。
需求方法包括了調研的方法、需求演示的方法、需求跟蹤方法等，需求工具如各類模版；技術如原型製作技術等。這些的選擇對於專案需求的定義非常重要，好的方法、工具與技術可以引導需求工程師定義出好的需求，並可以適當彌補因人員經驗不足方面帶來的缺陷。
以下，以需求規格說明書模版和使用者需求評審為例來進行說明。
對於需求規格說明書的模版的選擇，不同的專案是不同的。如下表，是在規格說明書中，這個表所消耗的工作量會比較大，但對專案需求的影響到底會有多大呢？這 就需要專案經理進行分析：專案是一次性專案還是可持續的專案呢？使用者對於需求要求的嚴格程度如何？系統設計時應該考慮到哪些問題？專案經理對整體專案進行 分析後，權衡利弊，再決定在模版選擇中是否需要裁剪。
使用者需求評審是需求確認的乙個方法是否採用，也是要根據專案的實際情況來選擇。有使用者需求評審這個環節，對於提高使用者的滿意度方面肯定有幫助，對後期的需 求控制也有利。但是，使用者是否具有需求評審的能力？對於初次合作的或者是複雜的需求，需求評審的確是有必要的，但是對於多次合作且雙方合作良好的或者是比 較簡單的需求，則評審不一定有效果。
因此，在需求整體規劃中，應形成乙份需求管理的方法、工具與技術的清單。
（3）整個專案過程中需求活動的互動流程以及執行的嚴格程度
任何專案都是乙個團隊協作的過程。在專案管理中，清晰的流程與明確的職責是多方進行有效協作的基礎。
需求過程是乙個複雜的過程，與使用者之間的互動頻繁，在需求整體規劃中，應對各方互動的流程、職責、執行的嚴格程度以及閥值處理方案進行明確，多方達成一致，形成文件作為專案的管理章程，指導專案需求管理工作的執行。
在需求管理過程中，需求計畫過程、需求調研與需求分析過程、需求確認過程、合同內和合同外需求變更過程、需求評估過程、需求跟蹤與完善過程幾個較明顯的過 程。對於成熟的專案管理的公司，一般都有明確的流程與職責的定義，此時，專案經理只需要根據現有的過程進行裁剪，如果有的專案暫時還未形成正式的流程與過 程以及明確的職責前，則專案經理需要根據專案情況進行定義。
定義好了需求流程後，對流程執行的嚴格程度影響整個需求的管理。比如，在需求調研計畫中，使用者是否指定了業務負責人把握整體需求？在需求調研階段，使用者現 場的需求調研記錄使用者是否簽字確認？補充的需求使用者如何確認？如何確保使用者已理解了需求？每乙個需求細節的執行都將影響專案的執行，因此，在規劃中對需求 過程執行的嚴格程度決定了整個專案的需求的質量。
總結：需求管理前期規劃的結果應該包括以下三部分內容：
1、專案需求管理的總體指導思想；
2、專案需求管理的活動清單、每乙個活動所採用的方法、使用的工具與技術；
3、專案需求活動的角色、流程說明，角色流程圖、執行嚴格程度。
前期總結 合同管理BS需求
1 概要設計不充分，資料庫在 編修階段遭反覆修改。2 需求自定，挖掘不充分，導致初始需求殘缺，進而使功能設計不完全，螺旋迭代過程中需求迸發。3 糾纏 不注重邏輯部分。4 與客戶交流不足，進度，設計理念未實時共享。5 時間控制不完善。6 前期時間浪費在興奮需求的滿足上，不僅難度大，而且最後又否定該類需...
Hadoop系列之 前期準備
先安裝好vmware，和centos6.5版本，配置好網路 nat 注意關閉dhcp，需要配置靜態的ip等，方便下次開機使用。安裝xshell方便使用。通過xshell連線linux，進行相關設定 藍色是注釋 1.關閉防火牆，輸入 chkconfig iptables off 防火牆開機時不啟動，c...
持續化思考之 前期思考（需求 產品定義）有多重要？
問題背景描述 創業團隊。我們最近在做乙個產品，乙個規模比較大的web應用。由於具有創新性，國內市場沒有成熟的產品可以參考。正因如此，我們簡單想好基本的功能和架構，心中有了乙個大概的樣子，就開始編碼了。在整個開發過程中，我們一邊開發，一邊思考新功能是不是要加，一邊思考舊功能的優化和刪減，因為之前思考和...