CMMI级别三的需求管理
    在CMMI级别三中，组织需要建立、归档所有项目中所使用的公共的和一致的流程。
    过程域：需求开发
    需求开发过程将解释如何抽取责任人的需要、导出用户的需求声明，并把这些用户需求进一步分析/总结成为相应的系统需求。
    CMMI对需求开发定义了以下几个目标：
    组织必须能够将收集来的责任人的需求转换成用户需求
    CMMI中建议：
    “将收集来的责任人的需要，期望值，约束条件和接口定义转换成用户需求。”
在一般情况下，责任人的需要并没有被很好地定义和理解，这些需要甚至可能是不一致或相互矛盾的。一个责任人的典型代表必须参与产品开发的整个生命周期。在这个生命周期中，必须反复地定义，阐述和明确这些需求，最后总结出一组清晰的，被正确理解的用户需求。
    以上过程非常类似于邀请客户代表进入项目队伍参与全周期的开发工作。此外，对需求采集和阐释的技巧也是极其重要的，目前较流行的是Use Cases方法。Use Cases方法是一套在不同的使用场景下，从用户的角度出发，构造和记录功能性需求的方法。单个的UseCase只能记录简单的文本，最好的方式是使用UML中的Use Case视图对一组UseCases进行描述，并表示它们之间的相关关系。
    因此，需求管理工具必须能够支持在文本说明的需求声明中插入相关的UML视图，并可将文本和视图同时显示在一个文档中。

组织必须可从用户需求分析出系统需求
    CMMI中建议：
“对用户需求进行推敲和细化以开发出对系统需求。”
对用户需求进行彻底的分析，识别出所有已暗示但没有被清晰表述的需求，再结合所开发目标产品的技术架构细节，可得出该产品的系统需求。系统需求根据产品的规模和复杂度，可细化成系统需求、子系统需求、模块需求等。在这个过程中，必须同时建立起不同需求之间的可追踪性，为后续的决策指定提供参考，并支持需求变更影响度分析。
    根据CMMI要求，在技术架构的基础上，通过对用户需求的分析可推导出系统需求。因此，需求管理工具需要支持实现这种推导，这种推导的支持不仅包括在不同层次的需求之间创建可追踪性，还包括提供可分析上层需求的技术和相关方法。在UML建模方法中，可通过UseCase视图,Activity视图和Sequence视图等有效的方法来帮助分析和导出新的需求，上层的技术架构通过Architecture视图（也称为复合结构）进行描述。这些方法都要求在需求文档中建立模型，用来记录分析和决策过程，从而为下一步提出开发技术方案提供指导。
组织必须能够验证需求
    CMMI中建议：:
    “需求必须可以被分析和验证，同时必须开发出对“必需的功能性”的定义。”
当那些非正式的需要转化为正式的需求时，需求的分析和验证对于确定责任人需要、用户需求、系统需求等是否可行，是否可以在预算范围内达到，是否跟当前系统运行环境相匹配都是非常必要的。
    用于需求分析和验证的技术包括按时间顺序的使用场景验证需求，并提推导新的需求。场景方法是一种有效的采集，阐述和推导需求的方法，在这个方法中我们常用UML中的Activity视图或Sequence视图来表示场景。
    “必需的功能性”的定义是通过功能性分析建立起一整套功能性的架构。功能性分析描述了系统的行为，时序活动，输入输出以及其他所有对该系统应用的描述。功能性架构则从逻辑上描述了一组功能（或服务）和需求是怎样相互满足的。UML的Activity视图能够从工作流的角度描述系统的活动行为，并且可以识别负责这些工作流的相应组件，这些视图在描述功能性分析，以及将需求进一步分配到子系统级别时非常有用。因此，需求管理工具应该能够支持图形化模型和文字性的需求说明存在于一个单一的文档形式中，并且这样文档形式可以支持不同层次间需求的追踪关系（无论这些需求是以文字形式还是以UML的图形化模型表示）。
    过程域：技术解决方案
    在这个过程域中，我们需要关注的是评估和选择设计方案，进行详细设计，最终实施。那么这些和需求管理又有什么关系呢？组织必须首先确保他们可以持续地开发出满足需求的解决方案，一种方法就是通过验证所产生的设计来确保初始方案是正确的。在这个过程中，组织应该能够发现那些不切实际的，或因定义不够充分而无法实现的需求。同时，组织应该允许需求在整个设计过程中不断地充实变化，但这一点的前提死必须保证这些变化是可控制的。所以，可追踪性不仅体现在不同层次的需求之间（用户需求，系统需求，子系统需求等），也应该体现在需求和解决方案之间。
我们应该保留从责任人要求到系统和子系统需求的分析过程和分析方法，以便我们在设计和编码阶段仍然可以遵循这些过程和方法。因此，需求管理工具应该能够让后续的系统设计者和开发者可以浏览、创建和维护最初的需求和他们设计之间的可追踪性，并以此检验后续设计/开发工作对需求的依从性，以及对需求变更的影响度估计。由此，需求分析员和项目经理应该具有从系统责任人要求到系统具体设计/开发/测试间的可追踪性有一个完整概念，这个可追踪性可以让他们做到基于需求的项目过程监督，并可以保证所有的开发和测试工作与需求保持一致。
    总结
    对于那些有大型复杂的产品或系统开发项目的组织来说，CMMI是评估和改进开发流程的必由之路。许多大型公司见证了这条必由之路，如：洛克希德·马(Lockheed Martin)，波音 (Boeing)，诺斯罗普·格鲁曼(Northrop Grumman)，通用汽车以及JP摩根等。
    在CMMI 2级和3级中，重点要求达到的是有效的需求管理和需求分析实践。在这两个阶段，全面的工具支持对于帮助整个组织理解、定义和实施CMMI描述的最佳经验是必不可少的。通过在开发的生命周期中提供对需求采集/定义、需求分析以及需求变更追踪的全面支持，开发组织才能够从这些过程改进中得到最大收获