以需求實現為單位規劃項目實施
小版本發布需要為每個版本制定實施目標，確定在本次版本中需要實現的功能以及計劃修改的以前版本的缺陷。而用戶需求是功能的表達方式，因此使用用戶需求作為小版本是順理成章的。當然根據粒度不同，也可以使用軟件需求做為小版本發布的內容。
在定下版本計劃的目標后，就需要規劃實施。不過由于用戶需求描述的是客戶的業務和對系統的期望，因此直接采用用戶需求作為開發任務安排的起點并不合適。從用戶需求導出的軟件需求則是以開發團隊能夠理解的語言和結構描述的，很適合作為安排需求實現的基礎。需求追蹤矩陣可以幫助我們找到版本目標中的那些用戶需求相關的軟件需求，項目經理則為找到的這些軟件需求的實現制定開發任務，從而形成開發任務集的主線，再輔以集成測試和缺陷追蹤，就形成了完整的開發計劃。這樣的分解方式自然而且清晰，易于上手。
項目的進度監控
前文說到用戶需求是客戶與開發團隊間的契約，因此用戶需求自然成為客戶參與項目時候關心的重點。但是，在實際項目過程中，當客戶真正參與項目、試圖了解項目進展狀況時，卻發現除了用戶文檔外，再也找不到這些需求的影子，取而代之的是一堆花花綠綠的項目任務進展報告、甘特圖、統計報告等。這些報表也許準確地反映了現在項目中任務的分布和實現狀況，但是與用戶關心的需求實現狀態沒有什么直接聯系，因而與缺少了共同的語言。
這個問題來源于傳統項目管理過程中以任務為中心的理念和實踐。在這種理念下，項目被認為是一個任務的集合，主要的工作就是任務的分解（WBS： Work Breakdown Structure）、分派、實現和審核。在一個項目組內部，這的確是工作的主要內容。但是，現代的軟件開發過程都強調用戶的參與，項目進展僅僅以任務為視角展現就不是很合適了。對于客戶而言，他們所熟悉的問題描述，即用戶需求，已經被分解成幾十甚至上百個大大小小的任務，再難看出它們之間的聯系，客戶自然會感到迷茫，更別說從中看出需求實現的狀態了。
而RDPM中提供的是需求實現狀態圖，需求變化趨勢，需求數量完成率，需求規模完成率，工時消耗率等指標。這些指標對于客戶來說更有意義。
需求的變更
“需求變更”是業界公認的項目管理重大挑戰，尤其是項目后期產生的需求變更，對項目的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對項目和系統的了解，很有可能提出新的需求或者對原有的需
求作出修正。因此，需求的變化是不可避免的。
對于如何應對需求變更，主要的思路有兩條：首先是從源頭做起，提高需求質量，減少變更的可能性，這個在前文已經提過，不再贅述；另一個就是建立流程嚴格控制需求變更。
做任何變更之前，我們都要考慮后果(consequence)。由于需求在開發中所處的中心地位，一旦需求發生變化，影響面是很廣的。我們通過建立需求追蹤矩陣，來分析需求的沖擊面，即一個需求如果變更，將導致哪些其他的需求，測試用例、設計、編碼進行變更。這個客觀的信息將為項目經理提供一個做出合理判斷的有力依據。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
