我说CMMI之七：需求管理过程域--转载

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dylanren/article/details/5951912

我说CMMI之七：需求管理过程域

先讲讲需求管理的含义。

何谓需求管理？需求管理就是管理需求的一致性。

这里讲的需求指什么?指的产品与产品构件需求，对于软件而言通常就是软件需求规格说明书（SRS）。在CMMI模型中将需求分成了2类：客户需求，产品与产品构件需求。客户需求是采用用户的术语表达的，用户验收的依据，一般是由客户提出需求，由开发人员记录、描述、整理下来。客户需求是平衡了客户的需要、期望、约束和接口需求后的结果。产品与产品构件需求是采用开发人员的属于表达的，是开发方验收的依据。产品与产品构件的需求是基于客户需求派生而得到的，但是又并非仅仅基于客户需求，还可能由开发方附加了一些需求，还可能由于技术路线的实现约束而附件了一些需求。

谁和需求的一致性呢？用户需求、设计文档、代码、测试文档、用户手册、安装手册、项目计划书等文档。

在何时保证和需求的一致性呢？在需求开发的初期，在设计时，在编码时，在编写测试用例时，在编写用户手册时，在需求发生变更时，在设计、编码、测试用例、用户手册发生变更时！

需求管理是CMMI 2级中的唯一的一个工程类过程域，工程类过程域包括需求管理、需求开发、技术解决方案、产品集成、验证、确认，只有将需求管理放在了CMMI的2级，为什么呢？无论需求是如何获取的如何描述的，首先要管理需求的变更！这里隐含了一个前提，即需求是文档化的，需求管理的对象是需求，需求不能是虚无飘渺的，要固化下来，固化下来就是需求文档。

在此过程域中包含了5条特定实践，翻译如下：

SP1.1 理解需求：与需求的提供者对需求的含义达成一致

SP1.2 获得对需求的承诺：获得项目组成员对需求的承诺

SP1.3 管理需求的变更：在项目进行中，管理需求的变更

SP1.4 维护需求的双向可跟踪性：维护需求和工作产品之间的双向可跟踪性

SP1.5 确定项目工作和需求间的差异：识别项目计划、工作产品和需求之间的不一致

每条实践都有一个编号，以“SP1.3 管理需求的变更：在项目进行中，管理需求的变更”来说明一下，SP代表特定实践，1代表是第1个目标的实践，3代表是第3条实践。每条实践有一个名字，“管理需求的变更”即是这条实践的名字，“在项目进行中，管理需求的变更”是这条实践的正文。编号和名字都是解释性的信息，是帮助记忆的，每条实践的正文是“期望的”。

逐条解释每条实践：

SP1.1理解需求：与需求的提供者对需求的含义达成一致。

模型的每条实践都是动宾结构的描述方式，是没有主语的，我们在理解时要结合公司的实际情况，加上主语。对于这条实践，是谁与需求的提供者对需求的含义达成一致呢？是需求分析人员，是项目组的开发人员，是乙方。

需求的提供者是谁呢？是甲方，是客户、最终用户与间接用户。客户是出资者，是花钱买系统的人，最终用户是真正使用系统的人，间接用户是既不用系统也不掏钱买系统的，但是对系统是否上市、能否成功起了重要作用的人。举例来讲，你们家小孩需要买个手机，你是出资者、小孩子是最终用户、国家工信部是间接用户，三者的需求是不一样的，关注点是不同的。手机要既满足你的需求、小孩子的需求、政府的要求才可以销售出去。注意三者是and的关系，不是or的关系，缺一不可。

在CMMI中将需求分成了4个组成部分：需要，期望，约束条件和接口需求。需要是最基本的、不可裁剪的需求；期望是可以实现也可以不实现，最好能实现的需求，期望是可以妥协的需求；约束条件是对需要和期望的限制条件，是实现需要和期望的环境与障碍；接口需求是系统与其他系统之间的衔接关系，任何一个系统都不是孤立存在的。

何谓“一致”？是需求分析人员认可需求并且需求的提供者也认可了需求。仅仅是需求分析人员认可，需求提供者不认可，这显然是不成的，最终验收时肯定无法通过；仅仅是需求提供者一厢情愿，需求分析人员或者开发方不认可也是无法实现的。需求提供者关注什么？其一是正确性：是否准确表达了自己的需求？其二是完备性：是否遗漏了需求？开发人员关注什么？除了上述的正确性与完备性，还关注无二义性、可测试性、可实现性等等。

如何达成一致呢？通常是需求提供者（客户+最终用户+间接用户）讲解需求，需求提供者提供最初的需求，由需求分析人员整理需求，然后再给需求提供者确认需求，确认后一般是签字认可、邮件确认或体现在会议纪要中。

SP1.2 获得对需求的承诺：获得项目组成员对需求的承诺。

这条实践所讲的承诺是指对需求可实现性的承诺，是项目组成员对客户的承诺，承诺什么呢？是承诺需求是可以实现的。注意，这个承诺不是客户对项目组的承诺，不是客户承诺需求不变。

项目的参与人员在了解的需求之后，在和客户对需求的理解达成一致后，在评估了需求的技术可行性之后对客户承诺需求是可以实现的。SP1.1是本条实践的基础，是本条实践的前提。

在CMMI模型中主要在3处提到了承诺的管理，（1） REQM的SP1.2；（2）PP过程域中SP2.3:对需求进行承诺;（3）IPM过程域中SP2.2管理关键依赖的子实践，管理存在关键依赖关系的人员之间的承诺。这3处分别描述了对需求的承诺、对计划的承诺、对关键依赖关系的承诺，承诺的层次是逐步细化的，从宏观到微观，要求逐步加深。

中国人自古以来讲究一诺千金，这个“诺”是一种口头的承诺，是一种做人的信誉，在模型中提到的承诺要求一定要文档化，有记录，是书面的承诺，可以作为一种官方的依据，不能空口白说。

在实践中可以通过项目组的核心承诺对需求进行了评审、进行了估算、进行技术可行性的确认之后书面签字确认来记录。在SP1.1中要求了客户认可开发方对需求理解，客户需要书面确认，这里开发方也要进行书面承诺，二者都可能表现为书面的签字，签字的含义不同。

SP1.3 管理需求的变更

管理这个单词是在CMMI中出现频率很高的一个单词，这个单词的宾语不同含义是不同的，这里所说的管理就同这个PA的名字中的管理的含义是一致的：即保证需求的一致性。

这里所说的管理首先是要确定这个变更是应该变更的，其次要确保变更了所有相关内容，最后要确保修改的正确性，即不多改、不少改、不错改。评价是否需要变更时，需要由客户方与开发方的人员都要参与评价，不能仅仅由一方说了算，需要双方成立决策的小组，对需求的变更进行综合的评估。要考虑需求更变的技术影响、管理影响：

技术影响：

修改需求

修改设计

修改代码

修改测试用例

修改用户操作手册

产生的技术风险

……

管理影响：

变更工期

变更工作量

变更成本

变更计划

变更质量目标

……

需要建立需求变更的控制流程，是否所有的需求变更都走相同的流程呢？未必！

理解CMMI模型要灵活，不要僵化，要根据自己企业的实际情况进行裁剪。

有一家客户将需求的变更划分了高级别与低级别的两种变更，低级别的变更PM批准即可了，高级别的变更需要CCB批准：

高级别的需求变更：

影响其他项目组或者影响项目外部承诺的变更；

单次变更估算规模大于项目总体估算规模5%；

单次变更导致工作量成本增加超过1人周；

项目总体累计变更规模大于项目总体估算规模30%后的变更。

低级别的需求变更：

除上述高级别变更以外的变更。

在需求变更的流程中有几个要点需要强调：

（1）   变更的波及范围分析要完备；在进行波及范围分析时要参考需求跟踪矩阵；

（2）   需求的变更要有评审、批准；

（3）   需求变更完成后要验证变更的正确性；

（4）   变更完成后要变更基线，重新发布基线，通知相关人员。

SP1.4建立需求跟踪矩阵

需求跟踪矩阵一般简写为RTM，RTM可以表达2类跟踪关系：

横向跟踪关系：需求与需求之间的影响关系；

纵向跟踪关系：需求到设计、代码、用户文档、测试用例、计划之间的影响关系。

并非所有的跟踪关系都要建立矩阵，要根据企业的实际情况进行取舍，比如有的企业只建立客户需求到产品需求，产品需求到产品需求，产品需求到设计，产品需求到系统测试用例的跟踪关系。也并非所有的需求都要建立跟踪矩阵，比如有的企业仅对全局性的需求建立了跟踪关系。

这条实践在很多企业中都被忽略了，或者即使做了也只是形式上有了RTM，实际中并没有发现有何作用，而白白地增加了工作量。其实这条实践的作用与项目的规模很有关系，项目规模越大，这条实践的作用也越大，项目规模越小，这个实践的作用也越小。

针对RTM在我之前的博客中有多篇博文都讨论了，这里不再多说了，请搜索相关的博文看看吧。

SP1.5 识别项目计划、工作产品与需求之间的不一致性

这条实践中的字眼就是工作产品，这里说的工作产品指的设计文档、代码、用户手册、测试用例等之类的技术文档。这句话可以改写为：

识别项目计划与需求的不一致：即是否有的需求没有责任到人去开发呢？

识别设计与需求的不一致：是否有的需求没有被设计呢？是否有的设计不能满足需求呢？

识别代码与需求的不一致：是否有的需求没有被实现呢？是否有的实现不能满足需求呢？

…….

如何理解上述的识别2字呢？

识别就是找出来，识别就发现出来，识别就是评审出来，识别就是测试出来。识别的手段包括了评审、测试等验证与确认手段。这个识别不是一次性的，而是在项目进展过程持续进行多次的，这个识别是要参考RTM的。

如果发现了不一致，怎么办？记录问题，定义措施，跟踪关闭，使其保持一致！

以上对REQM的5条特定实践进行了解释，如何建立需求管理的流程呢？其实这个PA并非一定要去编写一个需求管理的流程。需要仔细分析一下，下面给出一种思路供参考：

SP1.1 可以编写到需求获取的流程中，当需求获取完成后，由客户确认需求理解的一致性；

SP1.2 可以编写到需求评审的流程中，当需求评审完成后，由开发人员确认需求的可实现性；

SP1.3 需要编写一个需求变更的流程，该流程可以合并到配置管理的变更管理流程中；

SP1.4 可以在需求开发过程中建立客户需求到产品需求，产品需求到产品需求的跟踪矩阵，可以在设计过程中建立设计到产品需求的跟踪矩阵，在测试过程中建立测试用例到产品需求的跟踪矩阵，以此类推；

SP1.5 可以在需求评审、设计评审、代码评审、测试用例评审、测试、用户手册评审、需求变更、设计变更等流程中体现识别不一致的活动。

不一定需要写一个需求管理的流程吧！

模型，要用活了！
————————————————
版权声明：本文为CSDN博主「麦哲思科技任甲林」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dylanren/article/details/5951912