系统功能。当每个小版本结束后，都会邀请客户评估这一版本实现的状况，并且根据用户反馈制定和调整下一个小版本的目标。这样做的好处是显而易见的：客户越早看到产品，就能越早发现与开发团队间就用户需求方面的理解差异， 尽早调整需求，从而避免了在项目后期调整需求带来的巨额代价。另一个潜在的好处是，这一部分产品功能经过验收后就有可能投入使用，从而尽早为用户提供价值。 当然，小版本发布会不可避免地面临较多的需求变更请求，因此需要仔细的管理需求变更。
以需求实现为单位规划项目实施
小版本发布需要为每个版本制定实施目标，确定在本次版本中需要实现的功能以及计划修改的以前版本的缺陷。而用户需求是功能的表达方式，因此使用用户需求作为小版本是顺理成章的。当然根据粒度不同，也可以使用软件需求做为小版本发布的内容。
在定下版本计划的目标后，就需要规划实施。不过由于用户需求描述的是客户的业务和对系统的期望，因此直接采用用户需求作为开发任务安排的起点并不合适。从用户需求导出的软件需求则是以开发团队能够理解的语言和结构描述的，很适合作为安排需求实现的基础。需求追踪矩阵可以帮助我们找到版本目标中的那些用户需求相关的软件需求，项目经理则为找到的这些软件需求的实现制定开发任务，从而形成开发任务集的主线，再辅以集成测试和缺陷追踪，就形成了完整的开发计划。这样的分解方式自然而且清晰，易于上手。
项目的进度监控
前文说到用户需求是客户与开发团队间的契约，因此用户需求自然成为客户参与项目时候关心的重点。但是，在实际项目过程中，当客户真正参与项目、试图了解项目进展状况时，却发现除了用户文档外，再也找不到这些需求的影子，取而代之的是一堆花花绿绿的项目任务进展报告、甘特图、统计报告等。这些报表也许准确地反映了现在项目中任务的分布和实现状况，但是与用户关心的需求实现状态没有什么直接联系，因而与缺少了共同的语言。
这个问题来源于传统项目管理过程中以任务为中心的理念和实践。在这种理念下，项目被认为是一个任务的集合，主要的工作就是任务的分解（WBS： Work Breakdown Structure）、分派、实现和审核。在一个项目组内部，这的确是工作的主要内容。但是，现代的软件开发过程都强调用户的参与，项目进展仅仅以任务为视角展现就不是很合适了。对于客户而言，他们所熟悉的问题描述，即用户需求，已经被分解成几十甚至上百个大大小小的任务，再难看出它们之间的联系，客户自然会感到迷茫，更别说从中看出需求实现的状态了。
而RDPM中提供的是需求实现状态图，需求变化趋势，需求数量完成率，需求规模完成率，工时消耗率等指标。这些指标对于客户来说更有意义。
需求的变更
“需求变更”是业界公认的项目管理重大挑战，尤其是项目后期产生的需求变更，对项目的影响是非常大的。但是，需求开发不可能做到完美无瑕，而且随着客户对项目和系统的了解，很有可能提出新的需求或者对原有的需求作出修正。因此，需求的变化是不可避免的。
对于如何应对需求变更，主要的思路有两条：首先是从源头做起，提高需求质量，减少变更的可能性，这个在前文已经提过，不再赘述；另一个就是建立流程严格控制需求变更。
做任何变更之前，我们都要考虑后果(consequence)。由于需求在开发中所处的中心地位，一旦需求发生变化，影响面是很广的。我们通过建立需求追踪矩阵，来分析需求的冲击面，即一个需求如果变更，将导致哪些其他的需求，测试用例、设计、编码进行变更。这个客观的信息将为项目经理提供一个做出合理判断的有力依据。
有效管理需求变更有几个需要特别注意的环节：