2. CMMI级别二的需求管理

处在级别二的组织必须已经检查过一系列关键域，并建立起可重复性的流程。

过程域：需求管理

在该级别上，CMMI对于需求管理过程域的目标是：

“需求是可管理的。项目计划和产品开发间的不一致性是可以识别的。”

所有产品的目标都是可以满足其责任人（Stakeholders）和客户 （Customers）的需求，但它也必须遵守其内部功能上和质量上的约束。需求管理过程在这一点上起到了非常重要的作用。近的Standish行业分 析报告明确的指出， 50%的成功项目把成功归功于建立了良好的需求管理过程。

为达到需求管理流程目标而必须建立的一系列佳经验概括如下：

组织必须定义一组需求

CMMI中建议：
“与需求提出者一起得出对需求的真正理解。”
“从项目参与者得到对需求的确认。”

任何需求管理过程的第一步都是确保所有的责任人（Stakeholders）理解项目的目标和目标设立的原因。 因此，在组织级别上必须建立一整套流程可以涵盖所有责任人参与需求的定义，并终对这些需求达成一致。在项目的进展过程中，组织能够从终的结果反向追踪 到初的目标，以确保两者的匹配度。除此之外，任何针对需求的修改都需经过审核。

因此，为了建立和管理一整套具有良好定义的需求，需求管理工具应该能够让不同的用户查阅/修改需求文档，并可以 识别需求的性。用户也同样能够简便地建立起不同阶段的需求（例如，用户需求和产品需求）和项目的其他工件（例如设计和测试）间的可追溯性报告。需求管 理工具同样也应该可以提供一套可审核的追踪过程，从而保证需求即使在发生变更的情况下仍然可以得到实现。

维护需求的修改历史也同样重要，因此需求管理工具也应该支持对需求文本的基线化版本管理。

组织必须管理需求的变更

CMMI中建议：
“在项目中进行过程中管理需求变更。”

一旦需求建立被捕获或产生，所有的项目参与人员必须能够得到需求的新信息。因此整个组织必须懂得：

需求变更的提出和产生。.

这些变更将对整个项目有怎样的影响。 
对于这些变更，相关责任人采取了怎样的一致行动。 
这些经过审批的变更是否已经反映到终的产品。 
需求的变更是不可避免的，也是允许的，但必须加以管理和控制。相关工具必须提供一个可协作的，可配置的需求变更控制流程。用户在这个流程中必须能够：

针对需求提交变更请求。 
在变更控制流程中，将单一需求项的多个变更请求作为一个独立的条目进行管理。 
将相关的多个需求变更对应到一组需求上，以达到同步的更新。 
将需求变更分派给相关评审人员。 
能在线评审并评注需求变更，这样所有人都能够看见所有的评注。 

迅速全面的评估对某个变更对于需求，设计和测试的影响。 
根据评审人员的意见批准或拒绝变更请求。 
自动地实施批准的变更以确保不发生任何的错误。 
组织必须确保需求被满足

CMMI中建议：
“必须维护/保持需求、项目计划和产品开发之间的双向可追踪性。”

只有完整的可追踪性才可以确保所有正确的需求都是以正确的方式实现的。因此，组织必须能够检查在开发过程的每一个阶段需求都被满足，并且说明终产品的某一个具体特性是怎样反向对应到其需求的。

没有工具的强有力支持，创建、维护和报告需求的追踪性是极其耗时和容易出错的。因此，工具必须能够确保迅速，简单地建立起追踪连接。为了达到CMMI的要求，不仅要在各个需求之间，而且也要在需求和项目计划和产品开发（例如设计和测试）之间建立可追踪性。

需求管理工具必须能够收集/同步开发过程中所使用的其他工具中的信息，同时为了支持迭代和递增的开发流程，也必须在需求文本的不同版本间建立和维护可追踪性。一旦建立了追踪性，需求管理工具必须能够在一个窗口中查看需求之间，需求和计划，工件之间的关联状况。

组织必须确保项目计划，开发产品和需求是一致的

CMMI中建议：
“必须识别出项目计划，开发产品和需求之间的矛盾(或不一致性)。”

识别这些矛盾可以确保组织的开发工作是正确的，这样所有工作都遵从新的相关信息并且没有忽视任何需求。

因此，组织必须建立起一套流程以确保所有的项目计划，开发产品和需求保持一致。这套流程中包括评审，分析，和管理所发生的需求变更。

项目计划和需求声明必须紧密关联，需求管理工具必须确保项目任务和需求数据是同步的，这样两者之间才可以建立起可追踪性。可追踪性的建立可以帮助我们更好地评估需求变更对项目的影响度。