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

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

 

随着企业对信息系统 的 日益依 赖 ,信息系统的功能 日趋完善 ,其结构也越来越复杂,这使得信息系统的开发成为 了一项挑战性 的工作。需求开发是信息系统开发过程 中的关键性工作 ,它是用户与开发人员进行 沟通 的部分 ,主要描述 了所要开发的系统应具备的功能及要求 。能否准确表达所接受的用户需求将直接影响到信息系统项 目开发 的成功与否。在信息系统开发过程 中,最理想的状况无疑是开发人员在需求获取阶段一下子就能够发现并确定 所有 的需求 ,但是 由于多方面的原 因,在实际开发过程中需求是经常变化的 ,并且这种变更将贯穿于信息系统的整个开发周期中。信息系统开发实践证 明 ,需求变更管理不善往往会导致信息系统开发项 目的失控 ,从而使得整个项 目开发 进度滞 缓、成本 突增 ,甚至失败 。因此 ,如何对需求变更加 以有效的管理 ,从而保证系统开发 的进度 、成本和质量 ,便成为信息系统开发中一个迫切需要解决的问题 。 有效的需求变更管理有助 于提 高信息 系统 的开发质量。度量是管理 的基础 ,将度量方 法引入需求变更管理 ,并基 于 CMMI提 出了信 息系统的需求变更度量框架,从 而指导信 息 系统开发 中的需求变更管理和控制 。 为了确保所构建的信息系统需求变更度量框架 的合理性 ,我们迫切 的需要一种科学 的方法来指导 它。 目前 业 界 比较 流 行 的 指 导 方 法 有ISO9000,全 面 质 量 管 理 (TQM)、六 西 格 玛(6sigama)和 CMMI等。IS09000、TQM 以 及6sigama虽然致力于质量改进,强调需求管理 ,但流程繁琐 ,相比来 CMMI的操作性较强 ,启动更容易 ,参 与 性 更 强。CMMI(Capability MaturityModelIntegration)即能力成熟度集成模型 ,是 由美国卡内基 ·梅隆大学的软件工程研究所 (SEI)在美国国防部 的资助下所创立的。CMMI是组织进行软件过程改善和软件评估的一个有效的指导框架 ,其 目的是提高产品和服务的开发、获取和维护 能力 。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值