CMMI V2.0 “RDM需求开发和管理”过程域详解
发布时间：2020-07-19 12:02:29

从“需求开发和管理（RDM）”实践域的目的、价值、实践、关键点、注意点和评估中的常见问题，来详细讲解此过程域。

目的：挖掘需求，确保和干系人理解一致，并调整需求、计划和工作产品。


 

价值：确保客户的需求和期望得到满足。

 

实践概述

 

第1级

RDM 1.1记录需求。

第2级

RDM 2.1挖掘干系人的需求、期望、约束条件和接口或连接。

RDM 2.2将干系人的需求、期望、约束条件、接口或连接转化为划分了优先级的客户需求。

RDM 2.3与需求提供者就需求的含义达成一致。

RDM 2.4获得可以落实这些需求的项目参与者的承诺。

RDM 2.5开发、记录和维护需求和活动或工作产品之间的双向可追溯性。

RDM 2.6确保计划和活动或工作产品与需求保持一致。

第3级

RDM 3.1建立并持续更新解决方案及其组件的需求。

RDM 3.2建立操作概念和场景。

RDM 3.3分配要落实的需求。

RDM 3.4识别、开发并持续更新接口。

RDM 3.5确保需求是必要且充分的。

RDM 3.6在干系人的需求和约束条件之间取得平衡。

RDM 3.7确认需求，以确保生成的解决方案在目标环境中按照预期工作。

 

关键点

 

项目的源头是需求。如果需求出错，后续的开发和最终的交付产品也是错误的。所以，清晰、明确地找出客户的需求至关重要。但是原始需求在大多数情况下又是不明确的，即使是用户或客户也不一定能够明确地提出需求。这是为什么在RDM 2.1里要挖掘需求的原因。

 

用户或客户提出的需求是软件需求。软件需求是面向用户或客户的，是对最终产品输出结果的期望。对于开发人员来说，只是对结果的期望还不够，还需要有待开发产品的定义，或者软件规格描述。这就需要系统分析师把客户需求进化成软件需求规格说明，也叫软件需求。用户需求的描述通常以用户或客户为主语，例如“公司财务需要每个月打印财务报表。”而软件需求的描述通常以待开发的系统为主语，例如：“财务报表系统必须在每个月的最后一天下午5点以前生成可打印的月度财务报表，并自动地通过邮件的形式发给主管财务去打印。”

 

需求分为功能需求，非功能需求或性能需求，和接口需求。

 

需求是有优先级之分的。在Scrum敏捷方法里，在Backlog里最上面的需求优先级最高，越往下优先级越低。在使用敏捷方法进行新产品开发时，往往舍弃最底端的20%需求，因为这些需求带来的价值，往往小于开发的成本。

 

有了用户需求和软件需求之后，最终交付的软件，需要经过一道道工序，即设计、开发和测试，才能被开发出来。在开发过程中，随着需求的逐渐清晰，中间产物可能会出现与原有需求不符的情况。按照问题解决越早成本越低的原则，就需要尽早发现并解决不符合问题。需求双向跟踪矩阵对于尽早发现和解决中间产品与需求不符的问题，是一个非常有效的工具。

 

需求的不确定性在项目初期最大，在项目结项时最小，中间阶段随着需求逐渐清晰会产生一些需求变更。软件开发很大一块成本是因为需求变更产生的返工造成的。为减少返工成本，我们需要在项目初期用各种方法对需求进行确认，尽早降低需求的不确定性。仿真、原型、角色扮演等方法都是很好的需求确认方法。

 

注意点

 

RDM 3.2中的操作概念和场景，Conceptof Operations (ConOps) and Scenarios,是从用户的角度，详细描述怎样使用最终产品。操作概念和场景为用户测试用例的编写提供了很好的素材。国内有些企业采用用户需求代替操作概念和场景，是不对的。

 

RDM 3.5-6中的需求必要性和充分性评审、以及需求的折衷性评审，对确保需求不多、不少地满足客户的需要是非常重要的。但是需求评审不是需求确认的手段，无法验证需求文档中的需求的正确性。

正式评估访谈中可能问到的问题

第2级

RDM 2.1挖掘干系人的需求、期望、约束条件和接口或连接。
Q: 如何开发需求？

Q: 如何识别出客户没有提出但系统需要的需求？

RDM 2.2将干系人的需求、期望、约束条件、接口或连接转化为划分了优先级的客户需求。

Q: 有哪些需求相关的文档？

Q: 简单描述从客户处获取需求的流程？

Q: 谁参与需求的收集？

RDM 2.3与需求提供者就需求的含义达成一致。

Q: 你是如何确保客户对需求的理解的？

Q: 有哪些人需要理解需求，如何理解？

RDM 2.4获得可以落实这些需求的项目参与者的承诺。

Q: 你是如何获取项目成员对需求的承诺的？

RDM 2.5开发、记录和维护需求和活动或工作产品之间的双向可追溯性。

Q: 在整个项目的生命周期过程中，如何建立、跟踪、维护需求的双向跟踪矩阵？

RDM 2.6确保计划和活动或工作产品与需求保持一致。
Q: 你是怎么样确保设计和编码与需求保持一致的？      

第3级

RDM 3.1建立并持续更新解决方案及其组件的需求。

Q: 如何将用户需求转化为技术需求？主要包含哪些技术需求？

Q: 如何将客户需求转化为产品需求？

RDM 3.2建立操作概念和场景。

Q: 你是怎样建立操作概念和场景描述的？

Q: 为什么要建立操作概念和场景描述？

Q: 在什么时候和地方会用到操作概念和场景描述？

RDM 3.3分配要落实的需求。

Q: 在哪定义功能性需求？

Q: 如何根据总体需求细化功能性需求？

RDM 3.4识别、开发并持续更新接口。

Q: 定义了哪些类型的接口？在哪儿定义？

RDM 3.5确保需求是必要且充分的。

Q: 如何确保需求之间的一致性和完整性？

Q: 在哪记录和跟踪相关的缺陷？

Q: 谁参与需求的评审？

RDM 3.6在干系人的需求和约束条件之间取得平衡。

Q: 是否识别了与需求相关的风险？

Q: 在哪跟踪这些风险直至风险关闭？

RDM 3.7确认需求，以确保生成的解决方案在目标环境中按照预期工作。

Q: 除了需求评审之外，你是怎样在下面初期确认你的需求的正确性的？你做过Demo或者原型？

2020年10月份以后CMMI V1.3版本就退役了。在您从V1.3到V2.0的转型过程中，硕思信息将会尽最大的努力来帮助我们的客户达成转型目标。