编者按：

CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域，笔者将通过系统性的梳理、浅显易懂的文字描述，同时结合笔者的思考和观点，对每个实践域的目标以及所基本涵盖的内容进行描述，希望能抛砖引玉、相互碰撞，燎原出契合读者各自心中的答案。

CMMI2.0之我见-需求开发和管理RDM

需求在软件工程中的重要性不言而喻，开发软件系统最困难的部分就是准确说明开发什么，同样也包括编写出详细的需求，需求包含面向用户、面向硬件和其它软件系统的接口。宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。

需求是项目实施的根源，需求工作的好坏对项目影响最大。目前很多软件公司的通病是：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。为了解决这一问题，我们需要真正搞清楚谁是客户、谁是用户、谁是间接用户等等；简单理解：掏钱买单的人称为客户，而真正操作软件的人叫最终用户，客户与最终用户可能是同一个人也可能不是同一个人。

需求开发的目的是通过调研与分析，获取用户需求并定义产品需求。

需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并管理需求的变更。

CMMI2.0的需求开发与管理RDM这个实践域是1.3版本中需求开发过程域和需求管理过程域的组合。从实践的描述我们可以看出其中的一些变化：1.3版本中需求只分为客户需求和产品组件需求，2.0版本中需求分为客户需求、解决方案需求和接口三种需求。

将解决方案需求代替了原来的产品需求，可以看出新版本不仅适应于软件产品，也同样适用于系统和服务，将接口需求与解决方案需求并列，也可以看出去2.0非常重视接口需求。

同时，我们也看到2.0描述需求开发活动要一直在整个开发周期内进行，让需求开发活动贯穿整个生命周期，而不仅仅只是在设计之前，这让开发者们认识到需求的重要性和连续性，需要在整个项目过程中持续识别和细化需求。

关于需求开发活动，这部分涉及一些需求分析方法，比如调查表法、座谈法、原型法、头脑风暴法、6W3H设问法、用户画像法、场景推演法等等。

最后我们也发现，CMMI2.0中在描述相关利益者参与需求活动由之前的被动方式变成了主动参与，让干系人积极主动参与，让他们能够看到需求的演变。

上面的这些变化是新版本在需求开发与管理上的一些明显的提升，让需求开发和需求管理变得更加紧密并融为一体。

在实际的需求开发和管理的执行层面上，项目需要采取适当的方法来确保已确认的需求得到有效管理，以支持项目计划与执行的需要。当项目需求完成获取之后，应在将这些需求纳入项目计划之前，与需求提供方一起评审这些需求，以解决问题并避免误解。

一旦需求提供方与需求接收方达成一致，应从项目参与者处获得对需求的承诺。随着需求的演变，项目重点关注的是对需求变更的管理，重点是识别在计划、工作产品与需求间的不一致，这是需求阶段的重要工作。

所有项目都有需求，也极易发生需求变更，变更是对已有的需求、设计、功能的变更。变更可能是由于客户需要的演变、技术上的成熟或不一致的理解等等而产生的；需求变更可能记录在客户或最终用户提出的变更请求中，也可能是从需求开发过程中接收的新需求的形式。不管是何种形式，由需求变更所驱动的活动都应得到相应的管理。

经验之谈

需求分析：我们在做需求分析时，拿到客户的需求首先进行需求分析，需要跟客户进行交流，围绕客户需求进行思考，思考我们应该提供什么的功能来满足客户需求，因为有时客户也不知道自己所需要的真正需求是什么。然后我们会整理一个大概的功能列表，让客户来确认。整个需求开发过程，我们需要注意以下几点：

①需求分析人员跟客户的理解一致，这点是非常重要的。我们可以通过一些辅助文档、原型之类的，来达到这个目的；

②对于功能的设计，都要围绕客户需求来完成。整个推敲分析过程，都不要忘记回头看看客户的真正需求，不要被带偏；

③用户是最终使用这个系统的人，他们的真实需求很重要；

④需求一定要形成文档，文档的形式可以多样，记录下来。必须形成文档给到相关人员进行确认；

⑤关注需求范围和约束，在需求反复讨论沟通中，不要随意蔓延需求范围，要考虑到系统约束，“丑话”可以说到前面。

需求管理：需求管理者是需要检查需求开发人员是否遵守了这些定义的。拿到需求之后，需求的计划是什么，目前的状态是什么，制定了哪些阈值，这些都是属于需求管理的范围。当我们遇到需求变更时，是否允许此需求变更？我们需要分析需求变更对范围、资源、进度等的影响。

在需求阶段还要关注需求基线的建立，需求基线就是将需求产物都固化和确定下来,说明这些需求已经确定下来，新增需求或修改原有的需求都必须通过需求变更流程来执行，它的作用是防止需求的变化给后续工作造成重大影响以及避免工作产品与需求之间的不一致性。

总结

需求开发和管理对于项目来说很重要，甚至会影响到项目的成功与否。可以说需求管理好，项目就成功了一半。一个好的需求管理流程不仅可以推动项目的进行，还可以提高项目的成功率，也一定会达到事半功倍的效果！

作者：唐三

CMMI2.0之我见-需求开发和管理RDM相关推荐

CMMI2.0之我见-过程管理PCM过程资产开发PAD
编者按: CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域,笔者将通过系统性的梳理.浅显易懂的文字描述,同时结合笔者的思考和观点,对每个实践域的目标以及所基本涵盖 ...
CMMI2.0之我见-管理性能和度量MPM
编者按: CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域,笔者将通过系统性的梳理.浅显易懂的文字描述,同时结合笔者的思考和观点,对每个实践域的目标以及所基本涵盖 ...
CMMI2.0之我见-配置管理CM
编者按: CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域,笔者将通过系统性的梳理.浅显易懂的文字描述,同时结合笔者的思考和观点,对每个实践域的目标以及所基本涵盖 ...
CMMI2.0之我见-技术解决方案TS产品集成PI
编者按: CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域,笔者将通过系统性的梳理.浅显易懂的文字描述,同时结合笔者的思考和观点,对每个实践域的目标以及所基本涵盖 ...
CMMI2.0之我见-过程质量保证PQA
编者按: CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域,笔者将通过系统性的梳理.浅显易懂的文字描述,同时结合笔者的思考和观点,对每个实践域的目标以及所基本涵盖 ...
我说CMMI2.0 之需求开发与管理
RDM,是需求开发与管理的简写,该PA合并了CMMI1.3版本的RD与REQM两个PA.它包含了需求获取.需求分析.需求描述.需求验证与确认.需求管理等五个需求工程的活动. 实践列表 RDM 1.1 ...
产品研发过程管理专题——软件工程（软件目的需求开发与管理）
需求开发与管理是软件项目中一项十分重要的工作,据调查显示在众多失败的软件项目中,由于需求原因导致的约占到45%,因此,需求工作将对软件项目能否最终实现产生至关重要的影响.虽然如此,在项目开发工作中,很 ...
软件目的需求开发与管理
作者:云中客的专栏出处:CSDN 需求开发与管理是软件项目中一项十分重要的工作,据调查显示在众多失败的软件项目中,由于需求原因导致的约占到45%,因此,需求工作将对软件项目能否最终实现产生至关重要的 ...
我说CMMI2.0 之过程资产开发（PAD）
PAD, process assesses development 过程资产开发,也可以翻译为过程财富开发. 过程资产指什么?与过程有关的组织级方针.过程描述.裁剪指南.检查单.模版.规程定义.培训材 ...

CMMI2.0之我见-需求开发和管理RDM

编者按：

目录：

CMMI2.0之我见-需求开发和管理RDM

经验之谈

总结

CMMI2.0之我见-需求开发和管理RDM相关推荐

最新文章

热门文章