RDM，是需求开发与管理的简写，该PA合并了CMMI1.3版本的RD与REQM两个PA。它包含了需求获取、需求分析、需求描述、需求验证与确认、需求管理等五个需求工程的活动。
实践列表
| RDM |
1.1 |
Record requirements. |
记录需求 |
| RDM |
2.1 |
Elicit stakeholder needs, expectations, constraints, and interfaces or connections. |
引导干系人的需要、期望、约束、接口或连接。 |
| RDM |
2.2 |
Transform stakeholder needs, expectations, constraints, and interfaces or connections into prioritized customer requirements. |
转换干系人的需要、期望、约束、接口或连接为排列了优先级的客户需求 |
| RDM |
2.3 |
Develop an understanding with the requirements providers on the meaning of the requirements. |
和需求提供者关于需求的含义达成一致的理解 |
| RDM |
2.4 |
Obtain commitment from work effort participants that they can address the requirements. |
从工作投入的参与者处获得他们对需求可实现的承诺 |
| RDM |
2.5 |
Develop, record, and maintain bidirectional traceability among requirements, activities, and work products. |
建立、记录、维护需求与活动、工作产品之间的双向可跟踪性 |
| RDM |
2.6 |
Ensure that plans, activities, and work products remain consistent with requirements. |
确保计划、活动和工作产品与需求保持一致 |
| RDM |
3.1 |
Develop and keep requirements updated for the solution and its components in accordance with the organizational process. |
根据组织级的过程，开发和保持更新解决方案和其构件需求 |
| RDM |
3.2 |
Develop operational concepts and scenarios. |
定义操作概念和场景 |
| RDM |
3.3 |
Allocate the requirements to be implemented. |
分配待实现的需求 |
| RDM |
3.4 |
Identify, develop, and keep updated interface or connection requirements. |
识别、定义、保持更新接口与连接需求 |
| RDM |
3.5 |
Ensure that requirements are necessary and sufficient. |
确保需求是必要的和充分的 |
| RDM |
3.6 |
Balance stakeholder needs and constraints. |
平衡干系人的需要和约束 |
| RDM |
3.7 |
Validate requirements to ensure the resulting solution will perform as intended in the target environment. |
确认需求以确保最终的解决方案可以在目标环境中运行 |
通俗解释
RDM1.1记录需求
需求文档化。
RDM2.1引导干系人的需要、期望、约束、接口或连接。
引导，意味着需求工程师要启发客户、用户提出自己真实需求，要有引导的手段，比如访谈、原型、问卷调查等。
干系人包括了客户、最终用户、间接用户，包括了高层，中层，操作层的人的需求，包括了内部客户与外部客户，包括了产品生命周期各个阶段的干系人。在捕获需求时，要将干系人识别完备，否则就会遗漏需求。
需求在CMMI模型中分成了四部分：
需要：必需的、不可裁剪的需求；
期望：最好能实现、越多越好、可以裁剪的需求；
约束：实现需要与期望的限制条件，可能是技术的、管理的、商务的、环境的限制；
接口或连接：与其他产品或系统之间的衔接关系，任何一个系统都不是孤立存在的！
RDM2.2转换干系人的需要、期望、约束、接口或连接为排列了优先级的客户需求
客户需求要文档化。客户需求中要包含了需要、期望、约束、接口或连接，并且需求要划分了优先级。
需求一定客户划分优先级，没有划分优先级的需求类似一堆垃圾，因为后续无法根据优先级排列开发顺序，无法尽早给客户交付有价值的需求，无法进行多快好省的平衡。
需求划分优先级的方法有多种：
卡诺模型：把需求划分为基本的需求、期望的需求、兴奋型需求；
百分制法：参与划分需求优先级的每个人都有100点，可以根据自己的理解分解100点到每个需求上，然后累计每个需求得到的点数，从高到低排序即可得到需求的优先级。
ROI方法：让客户或客户代表对每个需求的业务价值给出相对的分值，让开发团队针对每个需求给出开发成本的相对分值，二者相除得到相对的投入产出比，然后排序得到优先级。
……
RDM2.3和需求提供者关于需求的含义达成一致的理解
这是讲需求理解的外部一致性，即开发方要和需求提供方对需求的理解达成一致。双方要采用面对面的沟通、原型展示、需求评审等多种手段对需求达成一致。
RDM2.4从工作投入的参与者处获得他们对需求可实现的承诺
这是讲需求理解的内部一致性，即实现需求的人要对需求理解一致，认为技术上需求是可以实现的，从工期上也是可以保证的。这是需求实现者对需求提供方的承诺，不是需求方承诺需求不变。
需求的内外部沟通交流是很重要的一个作业环节。可以采用需求交底，需求反讲，需求梳理会议，原型展示等多种手段进行需求的内外部沟通。
RDM2.5建立、记录、维护需求与活动、工作产品之间的双向可跟踪性
要确保：
所有的需求都分配到人了；
所有的需求都被设计了；
所有的需求都被实现了；
所有的需求都被测试了；
从需求能跟踪到对应的设计，也能从设计跟踪到对应的需求，这就是双向跟踪性。
接口需求、非功能性需求是在实践中最容易忽略的进行跟踪的需求。
RDM2.6确保计划、活动和工作产品与需求保持一致
通过各种评审、测试、验证与确认活动确保设计、代码、测试用例、计划等与需求保持一致。
当发生了需求变更时，也要维持相关配套文档与活动与需求的一致性。
RDM3.1根据组织级的过程，开发和保持更新解决方案和其构件需求
解决方案和构件需求就是产品和产品构件需求，就是需求规格，就是对需求的详细定义。
需求变更时要执行需求变更影响的分析、评审、认可。
RDM3.2定义操作概念和场景
场景，就是各种正常或异常的业务操作路径，要包含产品全生命周期的场景。
操作概念，就是用户在各种场景下如何使用产品的描述。
在描述软件的功能需求时，如果采用use case的方式，把各种正常流，异常流都描述清楚了即是操作概念的描述。
RDM3.3分配待实现的需求
所谓的分配需求就是把整体的系统需求分配到每个产品构件上。比如，关于一个杯子的需求，杯子分为杯盖与杯桶，容量的需求主要是分配给杯桶，温度的需求要分配给杯盖与杯桶，比如杯盖要承受110度的温度，杯桶可以承受105度的问题，这就是把整体的系统需求分配到每个产品构件上。
RDM3.4识别、定义、保持更新接口与连接需求
接口需求分为外部接口需求与内部接口需求。外部接口需求在需求获取时是必须获取的，内部接口需求是在分配了待实现的需求后，就产生了内部接口需求，就如同上边那个例子，把杯子划分为杯盖和杯桶之后，就产生二者之间的接口需求，这是产品内部不同构件之间的接口，是内部接口。
RDM3.5确保需求是必要的和充分的
需求是必要的，就是需求不是多余的，不是也有可无的，不做无用功。需求是充分的，就是需求是不可缺少的。所以这条实践就是要求需求是不多不少的，是刚刚好的。
在需求评审时，需求确认时可以检查需求是否是充分的、必要的。
RDM3.6平衡干系人的需要和约束
平衡需要和约束，就是做多快好省的平衡，把需求和工期、质量、投入进行平衡。平衡的前提是要对需求划分了优先级。参见RDM2.2。
RDM3.7确认需求以确保最终的解决方案可以在目标环境中运行
要确保需求满足了用户的真正需求，此条实践确认的是需求而不是最终交付的产品，所以对需求的确认是通过评审、模拟或仿真来实现的。
