我了解的一般的客戶，寫個word文檔，發封email，或打個電話，就把需求甩給開發團隊了。能寫一個結構完整、內容嚴謹需求的客戶很少。在美國，基本上用戶會寫需求，RFP（Request for Proposal）。國內有時候項目經理或做需求分析的工程師會幫助用戶整理用戶需求。用戶需求比較粗。有了用戶需求之后，再對其細化，寫出軟件需求。對于應用系統來說，軟件需求寫好了，開發的工作就簡單多了。
這兩種需求分別記錄。里程碑一般以用戶需求為目標。用戶需要關聯到多個軟件需求上。
項目規劃和進度監控
將需求作為項目規劃和實施的目標，這是RDPM的核心。一切以需求為中心。
通過小版本發布逐步實現需求
在項目計劃和進度控制方面，我們采用迭代的方法。
將項目目標分解為較小的、易于管理的子目標，這對于減少項目失敗風險很有幫助。項目目標分解可以從各個角度進行，采用小版本發布分階段實現項目需求是目前越來越被認同的一種。尤其是現在流行的敏捷開發方法，更是提倡迭代開發。有個普遍的誤解就是以為敏捷開發方法只適用于小規模的開發團隊，其實對大的團隊一樣適用。大的開發團隊 可以按照實現不同的模塊分成很多小的項目小組，給個項目小組其實就是一個小團隊。一般5、6個人最為合適，團隊合作和溝通成本之間有一個很好的平衡。
小版本發布是針對以前瀑布式開發的缺點而提出的開發方式。在以前的模式中，項目往往經過一個漫長的需求開發、設計、編碼和測試階段后才能夠與客戶見面，而客戶在這個時間段上進入了“盲區”，直到開發團隊“隆重推出”開發成果。而恰恰這個時候是項目風險最大的時候，由于在過程中缺乏交流機會，客戶往往會發現這個產品與他們想象的很不一樣，因此很有可能導致項目拖延或者失敗。
小版本發布則不同，它將系統的實現分解為多個連續的版本，每一個都實現一部分的系統功能。當每個小版本結束后，都會邀請客戶評估這一版本實現的狀況，并且根據用戶反饋制定和調整下一個小版本的目標。這樣做的好處是顯而易見的：客戶越早看到產品，就能越早發現與開發團隊間就用戶需求方面的理解差異， 盡早調整需求，從而避免了在項目后期調整需求帶來的巨額代價。另一個潛在的好處是，這一部分產品功能經過驗收后就有可能投入使用，從而盡早為用戶提供價值。 當然，小版本發布會不可避免地面臨較多的需求變更請求，因此需要仔細的管理需求變更。
以需求實現為單位規劃項目實施
小版本發布需要為每個版本制定實施目標，確定在本次版本中需要實現的功能以及計劃修改的以前版本的缺陷。而用戶需求是功能的表達方式，因此使用用戶需求作為小版本是順理成章的。當然根據粒度不同，也可以使用軟件需求做為小版本發布的內容。
在定下版本計劃的目標后，就需要規劃實施。不過由于用戶需求描述的是客戶的業務和對系統的期望，因此直接采用用戶需求作為開發任務安排的起點并不合適。從用戶需求導出的軟件需求則是以開發團隊能夠理解的語言和結構描述的，很適合作為安排需求實現的基礎。需求追蹤矩陣可以幫助我們找到版本目標中的那些用戶需求相關的軟件需求，項目經理則為找到的這些軟件需求的實現制定開發任務，從而形成開發任務集的主線，再輔以集成測試和缺陷追蹤，就形成了完整的開發計劃。這樣的分解方式自然而且清晰，易于上手。
項目的進度監控
前文說到用戶需求是客戶與開發團隊間的契約，因此用戶需求自然成為客戶參與項目時候關心的重點。但是，在實際項目過程中，當客戶真正參與項目、試圖了解項目進展狀況時，卻發現除了用戶文檔外，再也找不到這些需求的影子，取而代之的是一堆花花綠綠的項目任務進展報告、甘特圖、統計報告等。這些報表也許準確地反映了現在項目中任務的分布和實現狀況，但是與用戶關心的需求實現狀態沒有什么直接聯系，因而與缺少了共同的語言。
這個問題來源于傳統項目管理過程中以任務為中心的理念和實踐。在這種理念下，項目被認為是一個任務的集合，主要的工作就是任務的分解（WBS： Work Breakdown Structure）、分派、實現和審核。在一個項目組內部，這的確是工作的主要內容。但是，現代的軟件開發過程都強調用戶的參與，項目進展僅僅以任務為視角展現就不是很合適了。對于客戶而言，他們所熟悉的問題描述，即用戶需求，已經被分解成幾十甚至上百個大大小小的任務，再難看出它們之間的聯系，客戶自然會感到迷茫，更別說從中看出需求實現的狀態了。
而RDPM中提供的是需求實現狀態圖，需求變化趨勢，需求數量完成率，需求規模完成率，工時消耗率等指標。這些指標對于客戶來說更有意義。
需求的變更
“需求變更”是業界公認的項目管理重大挑戰，尤其是項目后期產生的需求變更，對項目的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對項目和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。
對于如何應對需求變更，主要的思路有兩條：首先是從源頭做起，提高需求質量，減少變更的可能性，這個在前文已經提過，不再贅述；另一個就是建立流程嚴格控制需求變更。
做任何變更之前，我們都要考慮后果(consequence)。由于需求在開發中所處的中心地位，一旦需求發生變化，影響面是很廣的。我們通過建立需求追蹤矩陣，來分析需求的沖擊面，即一個需求如果變更，將導致哪些其他的需求，測試用例、設計、編碼進行變更。這個客觀的信息將為項目經理提供一個做出合理判斷的有力依據。
有效管理需求變更有幾個需要特別注意的環節：
1. 建立正式的申請和處理流程
雖然眾多項目管理人員對于變更可能帶來的巨大影響有深刻的理解，但令人不解的是我們常�？吹竭@些變更的提出、討論和執行卻常常停留在口頭上。這樣做有兩個弊端：首先是時間一長，無論是當事人還是開發團隊的其它成員都說不清楚變更是因何發生以及結果怎么樣了。顯然，這對于提高項目管理質量、改進開發過程是很不利的。其次是由于缺乏形式上的約束和對變更沖擊的定量化分析，變更會被非常隨意地提出、或被草率地執行，大大影響了項目的進展和開發質量。因此建立一個正式的變更處理流程并真正得以實施非常重要。
2. 定量化的變更沖擊分析
變更作為一個計劃外的風險因素對項目肯定存在沖擊，只是大小的差別。因此，如果能夠定量化地評估變更帶來的影響就能幫助開發團隊作出正確的應對決策。這就是變更管理中的沖擊分析環節。上面談到了，分析的基礎是追蹤矩陣，它記錄了項目管理要素之間的聯系關系。從這些關聯關系中我們可以找到每一個潛在會受到影響的要素，評估對其的影響，從而組合出變更對整個項目可能造成的沖擊。
 |
從上面的例子可以看到，即使是加了一個看似與其他關系不大的需求，也會造成一系列的潛在影響，更不用說是在需求眾多、關系復雜的大型應用系統開發項目中了。
3. 組成變更控制管理委員（CCB）
作為變更管理的一個核心控制環節，變更控制委員會（簡稱CCB）起決策和管理作用。它通常由客戶代表和開發團隊代表共同組成，負責評估變更沖擊以及 決定是否要實施這樣的變更。這種綜合了需求方（客戶）和開發方（開發團隊）力量的委員會能夠較好地權衡變更代價，從而減少了單方面考慮變更所帶來的不利影響。
4. 不要忽視變更執行的管理
在實踐中很多開發團隊雖然組成了CCB并有一定的處理流程，卻往往忽視了對于變更執行的管理。而變更實施的好壞、完整性對于項目本身的影響同樣是巨大的。在這方面，根據沖擊分析和變更評審的結果，建立一個變更任務列表并且追蹤它的執行是一個很好的實踐。
總結
軟件項目與傳統的工程項目有著很大的不同，這種不同導致描述需求的方式，實現需求，進行項目計劃、監控項目進度的方式都有很大的不同。由于這種不同，傳統的基于任務的項目管理方法對于應用類的軟件項目并不適用。這里我們提出以需求為中心的軟件項目管理。 通過提高需求描述的質量、采用小版本發布策略、將用戶需求作為小版本的目標來組織和計劃項目開發、積極應對需求變更、提供以用戶需求為中心的項目進展視圖，從而和客戶一起來保證項目的成功。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
