我说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