CMMI级别二的需求管理 
　　处在级别二的组织必须已经检查过一系列关键域，并建立起可重复性的流程。 
　　过程域：需求管理 
　　在该级别上，CMMI对于需求管理过程域的目标是： 
　　“需求是可管理的。项目计划和产品开发间的不一致性是可以识别的。” 
　　所有产品的目标都是可以满足其责任人（Stakeholders）和客户（Customers）的需求，但它也必须遵守其内部功能上和质量上的约束。需求管理过程在这一点上起到了非常重要的作用。最近的Standish行业分析报告明确的指出， 50%的成功项目把成功归功于建立了良好的需求管理过程。 
　　为达到需求管理流程目标而必须建立的一系列最佳经验概括如下： 
　　组织必须定义一组需求 
　　CMMI中建议： 
　　“与需求提出者一起得出对需求的真正理解。” 
　　“从项目参与者得到对需求的确认。” 
　　任何需求管理过程的第一步都是确保所有的责任人（Stakeholders）理解项目的目标和目标设立的原因。因此，在组织级别上必须建立一整套流程可以涵盖所有责任人参与需求的定义，并最终对这些需求达成一致。在项目的进展过程中，组织能够从最终的结果反向追踪到最初的目标，以确保两者的匹配度。除此之外，任何针对需求的修改都需经过审核。 
　　因此，为了建立和管理一整套具有良好定义的需求，需求管理工具应该能够让不同的用户查阅/修改需求文档，并可以识别需求的唯一性。用户也同样能够简便地建立起不同阶段的需求（例如，用户需求和产品需求）和项目的其他工件（例如设计和测试）间的可追溯性报告。需求管理工具同样也应该可以提供一套可审核的追踪过程，从而保证需求即使在发生变更的情况下仍然可以得到实现。 
　　维护需求的修改历史也同样重要，因此需求管理工具也应该支持对需求文本的基线化版本管理。 
　　组织必须管理需求的变更 
　　CMMI中建议： 
　　“在项目中进行过程中管理需求变更。” 
　　一旦需求建立被捕获或产生，所有的项目参与人员必须能够得到需求的最新信息。因此整个组织必须懂得： 
　　需求变更的提出和产生。. 
　　这些变更将对整个项目有怎样的影响。 
　　对于这些变更，相关责任人采取了怎样的一致行动。 
　　这些经过审批的变更是否已经反映到最终的产品。 
　　需求的变更是不可避免的，也是允许的，但必须加以管理和控制。相关工具必须提供一个可协作的，可配置的需求变更控制流程。用户在这个流程中必须能够： 
　　针对需求提交变更请求。 
　　在变更控制流程中，将单一需求项的多个变更请求作为一个独立的条目进行管理。 
　　将相关的多个需求变更对应到一组需求上，以达到同步的更新。 
　　将需求变更分派给相关评审人员。 
　　能在线评审并评注需求变更，这样所有人都能够看见所有的评注。 
　　迅速全面的评估对某个变更对于需求，设计和测试的影响。 
　　根据评审人员的意见批准或拒绝变更请求。 
　　自动地实施批准的变更以确保不发生任何的错误。