3. 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视图能够从工作 流的角度描述系统的活动行为，并且可以识别负责这些工作流的相应组件，这些视图在描述功能性分析，以及将需求进一步分配到子系统级别时非常