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