一、     关键过程域中的特殊实践都有哪些？

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

 

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

 

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

 

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

 

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

 

二、  具体该怎么做？

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

子实践：

1.建立区别适当需求提供者的准则清单。

2.建立客观的需求评估及接受准则。

3.分析需求，以确保其符合已建立的准则的要求。

4.与需求提供者达成需求共识，使项目成员可对需求承诺。

 

 

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

子实践：

1.评估需求对现有承诺的影响。需求变更或新需求发生时，评估其对项目成员的影响。

2.协商并记录承诺。在项目成员对需求或需求改变承诺之前，对现有承诺的改变，应先协商。

 

 

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

子实践：

1.记录所有的需求和需求变更，不论是项目本身产生的或外界的要求。

2.维护需求变更纪录，以及每次变更的理由。维护变更的历史纪录，有助于追踪需求变更的状态

3.从相关干系人的观点，评估需求变更的影响。

4.确保项目人员能取得需求和变更的资料。

 

 

SP1.4 维护需求双向追溯性：可以在需求开发过程中建立客户需求到产品需求，产品需求到产品需求的跟踪矩阵，可以在设计过程中建立设计到产品需求的跟踪矩阵，在测试过程中建立测试用例到产品需求的跟踪矩阵，以此类推。

子实践：

1.维护需求追溯性，确保已记录低阶(或衍生)需求的来源。

2.维护需求追溯性，从需求到衍生需求，以及需求分配到功能、接口、对象、人员、过程及工作产品。

3.制作需求追溯表。

 

 

SP1.5 界定项目工作与需求的差异：可以在需求评审、设计评审、代码评审、测试用例评审、测试、用户手册评审、需求变更、设计变更等流程中体现识别不一致的活动。

子实践：

1.审查项目计划、活动及工作产品，是否与需求及需求变更相符。

2．界定差异来源及其理由。

3.当需求基线有变动时，界定有关计划及工作产品所需的变更。

4.启动矫正措施。

 

 

三、  与CMM中对应过程域的实践活动的区别与联系？

 

区别：CMMI模型中比CMM进一步强化了对需求的重视。

在CMM中，关于需求只有需求管理这一个关键过程域，也就是说，强调对有质量的需求进行管理，而如何获取需求则没有提出明确的要求。

在CMMI的阶段模型中，2级需求管理过程域中，增加了双向追溯性，强调界定项目工作与需求的差异。CMMI模型对工程活动进行了一定的强化。

 

联系：CMMI以CMM为基础演化而来。

CMMI继承了CMM收集需求、文档化需求等关键过程域活动。