我说CMMI2.0 之需求开发与管理

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确认需求以确保最终的解决方案可以在目标环境中运行

要确保需求满足了用户的真正需求，此条实践确认的是需求而不是最终交付的产品，所以对需求的确认是通过评审、模拟或仿真来实现的。