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