3.2 CMMI3级——需求开发(Requirements Development)

CMM的时候，是没有需求开发这个PA的，需求开发和需求管理有什么区别呢？

需求管理强调的是需求的确认以及需求变更的控制，而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。
以上两个关于需求开发的例子，都是反面教材，都没有能很好地把握需求，一个没有抓住问题的关键，一个没有能找到真正的需求提供者来获取需求。

CMMI和CMM相比，增加了很多专门针对软件工程的PA，其中需求开发(RD)就是其中之一。需求开发这个PA，从很高的层次描述了如何做好需求开发。要理解好本PA，需要先理解清楚以下几个关键的概念：
1)客户需求(Customer Requirements)
2)产品需求(Product Requirements)
3)产品组件需求(Product Component Requirements)

客户需求是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。
产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求，是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。

从另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。

以前面提到的“短信订餐系统”为例，其实这个系统，客户需求很简单，就是要解决部分员工不方便订餐的问题。我们看到，如果我们没有抓住这个客户需求，一开始就认为非要做一个短讯系统，那么就会陷入例子的陷阱中。要解决这个客户需求，办法之一就是做短讯订餐系统，但更合适的办法可能就是打电话回公司让别人代订午饭了。
我们很多需求开发没有做好的原因，大部分是没有把握好客户需求，直接进入软件的细节，去讨论要做什么功能，界面要怎样设计去了，而忘记了软件的根本目的是为了解决什么问题。

当我们明确客户需求后，就应该把客户需求转变成产品需求和产品组件需求，客户需求一般都是比较高层次的，而且描述也会比较简单，不能作为日后验收的标准，我们需要对软件的规格进行说明。一般来说，我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候，要注意产品需求和产品组件需求，必须和客户需求对应起来，通常是多对多的关系。为什么要对应起来？我们要保证，软件的每一个界面，每一个功能都是有用的，都是“源自”客户需求的，这样才能保证我们做的事情都是正确的事情，防止被不相干的事情干扰。

我们经常抱怨客户的需求在变，其实80%的原因是没有把握住客户需求，其实客户经常变的是产品需求或者是产品组件需求，客户需求是很少变的，就是因为我们没有把握住客户到底想要什么、需要什么，导致我们认为客户太难“服侍”了。只有把握住客户真正的需求，我们才能抓住根本，万变不离其中。

接着下来，我们将从每个SG和每个SP来详细讲解需求开发这个PA。

RD有三个SG，SG1开发客户需求，SG2开发产品需求，SG3分析和确认需求。
前两个SG讲述的是需求开发由顶而下、由粗到细的过程，SG3讲述的是需求分析和确认的过程。下面详细阐述：

SG1: Stakeholder needs,expectations,constraints,and interfaces are collected and translated into customer requirements.
干系人的需要、期望、约束和接口要求被收集并转化为客户需求。

SP 1.1: Elicit stakeholder needs,expectations,constrains,and interfaces for all phases of the product life cycle.
导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等。这句话要包含了几个要点：
1)干系人：干系人除了指甲方的领导、系统的最终用户，还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。
2)产品生命周期各阶段：干系人对系统的期望不一定只限于软件功能的，可能还包括数据的整理、资料录入、安装培训、维护要求等，干系人可能对软件生产的过程阶段都会提出他的要求，获取需求的时候，要注意干系人在软件生命周期不同阶段有什么要求。
3)需要、期望、约束、接口要求：甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等，都会有大致的想法。需求调研工作，首先要注意搞清楚这些内容。
4)导出：客户的原始想法可能是不明确的，或者是客户一时难表达完整的，我们需要用一定的方法，让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。

SP 1.2: Transform stakeholder needs,expectations,constraints,and interfaces into customer requirements.
转化干系人的需要、期望、约束和接口要求为客户需求。

SP1.1讲述的是通过一些方法记录客户原始的需求信息，而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求，通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。

SG2: Customer requirements are refined and elaborated to develop product and product-components requirements.
客户需求是精确和详细的，以用来开发产品需求和产品组件需求。
SG1讲述的是导出客户需求，而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。

SP 2.1: Establish and maintain product and product-component requirements,which are based on the customer requirements.
建立和维护产品和产品组件需求，这些产品和产品组件需求是基于客户需求的。产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等，比较高层次。
客户需求一般是难以验证是否已实现的，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验收的标准的。

SP 2.2: Allocate the requirements for each product component.
分配需求给每一个产品组件。
这个SP将需求开发与技术解决方案联系起来，所有的需求应该与设计的产品组件对应起来，保证需求驱动后续的设计工作，同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。

SP 2.3: Identify interface requirements
定义接口需求。接口需求包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候，并不是很明细，需要对客户需求进一步细分成产品需求、产品组件需求，然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。

SG3: The requirements are analyzed and validated,and a definition of required functionality is developed.
需求被分析和确认，并定义出具体的功能性需求。

SP 3.1: Establish and maintain operational concepts and associated scenarios.
建立和维护操作场景及相关情景。

SP 3.2: Establish and maintain a definition of required functionality.
建立和维护功能定义。

SP3.1和SP3.2是对需求描述的要求，要求描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过UML的Use Case图或者是序列图等来表达这些内容。

SP 3.3: Analyze requirements to ensure that they are necessary and sufficient.
分析需求以确认需求是必须和充分的。

SP 3.4: Analyze requirements to balance stakeholder needs and constrains.
分析需求平衡以平衡干系人的需要和约束。

SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求，除了要取得全面准确地需求，还需要平衡约束条件，保证需求在约束条件下是可实现的。

SP 3.5: Validate requirements to ensure the resulting product will perform as intended in the user's environment using multiple techniques as appropriate.
用各种合适的方法确认需求，确保最终产品能在用户的环境中按照设想运行。
这是需求开发的最后一步了，需求导出过程中尽管用了很多办法，但需求确认的时候，仍然需要采取办法确保获取的需求是符合最终的使用场景要求。

SP3.3、SP3.4和SP3.5，通常是通过需求评审来满足的。

请看下一文……

作者：张传波

创新工场创业课堂（敏捷课程）讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

www.umlonline.org创办人

3.2 CMMI3级——需求开发(Requirements Development)相关推荐

3.1 CMMI3级——11个PA简述
2级其实有很多问题还没有解决的,细心的人会发现,2级对软件工程活动的指导很弱,如:需求开发.设计.编码.测试等.在3级,你会发现: 1)有指导需求开发的需求开发(Requirements Develo ...
没有软件开发人员，可以办理CMMI3级吗？
一.什么是CMMI? CMMI全称为Capability Maturity Model Integration,即能力成熟度整合模式,是一个针对产品与服务发展的流程改善成熟度模式.它包含发展与维护的最 ...
cmmi3级包含的过程域
1.OPD:(Organizational Process Definition)组织级过程定义.建立和维护有用的组织过程资产. 2.OPF:(Organizational Process Focus ...
CMMI3级中18个过程域包含关系及目的（整理）
SSP过程类别 SSP定义的过程域与CMMI 等级3 的18个过程域包含关系目的过程管理组织过程改进(OPF) CMMI 3级,Organization Process Focus 目的在于掌 ...
cmmi3级认证有什么要求？参与人员都有哪些
如今,越来越多的公司都会去申请获得CMMI的认证,以此证明公司的实力和价值,由此可见,CMMI认证为企业带来的优势还是很大的,有些企业在办理cmmi认证的过程中也会问到我们同邦信息科技的小编,办理认证 ...
我说CMMI2.0 之需求开发与管理
RDM,是需求开发与管理的简写,该PA合并了CMMI1.3版本的RD与REQM两个PA.它包含了需求获取.需求分析.需求描述.需求验证与确认.需求管理等五个需求工程的活动. 实践列表 RDM 1.1 ...
扫盲——敏捷开发 Agile development 之 Scrum开发
觉得这篇文章写的非常好,非常有助于大家了解敏捷开发,原文链接在下面 https://www.jianshu.com/p/eb8f4448c5c8 什么是敏捷开发? 敏捷开发(Agile Develop ...
关于公司通过CMMI3级认证
个人体会: 公司能够通过CMMI3级是公司全体成员的共同努力的结果,但是通过CMMI3仅仅是一个开始,如果你体会过CMMI3中的过程管理,其中某些过程域的确可以让你的软件开发更规范,软件的重量更高,C ...
喜讯|宏时数据获得CMMI3级认证！欢迎了解自研统一运维监控平台！
2022年7月2日,美国CMMI研究院正式向宏时数据颁发了CMMI3级资质证书. 此次CMMI3级认证的顺利通过,标志着宏时数据在软件研发能力.过程组织能力.服务质量以及项目管理水平等方面得到了国际权 ...

3.2 CMMI3级——需求开发(Requirements Development)

3.2 CMMI3级——需求开发(Requirements Development)相关推荐

最新文章

热门文章