CMMI过程域详解-需求管理（REQM）之概述

过程域需求管理（REQM）是CMMI-DEV成熟度2 级项目管理类过程域

一、REQM过程域的目的

需求管理（Requirements Management，REQM）的目的在于管理项目的产品与产品组件需求，并确保那些需求与项目计划和工作产品间的协调一致。

二、REQM过程域的简介

“需求管理”过程管理所有由项目收到或产生的需求，包括技术与非技术需求，以及由组织赋予项目的需求。

特别要指出的是，如果实施了“需求开发”过程域，由该过程域中的各过程产生的产品与产品组件需求也将由需求管理过程来进行管理。在各个过程域中使用到的术语“产品”与“产品组件”，其含义也包含了服务、服务系统以及它们的组件。

当“需求管理”、“需求开发”与“技术解决方案”过程域都得到实施时，其相关的过程能够紧密结合并同时执行。

项目应采取适当的步骤来确保已批准的需求集得到管理，以支持项目计划与执行的需要。当项目从已批准的需求提供方处接收了需求，应在将这些需求纳入项目计划之前，与需求提供方一起评审这些需求，以解决问题并避免误解。一旦需求提供方与需求接收方达成一致，应从项目参加者处获得对需求的承诺。随着需求的演变，项目对需求的变更进行管理，并识别在计划、工作产品与需求间的不一致。需求管理活动还包括将需求变更及其依据文档化，并维护源需求、所有产品与产品组件需求，以及其它规定的工作产品之间的双向可追溯性。

所有项目都有需求。在维护活动中，变更是对已有的需求、设计或实现的变更。在增量式交付产品能力的项目中，其变更可能是由于客户需要的演变、技术上的成熟或过时以及标准的演变而产生的。在上述两种情况下，需求变更（如果有的话）可能记录在客户或最终用户提出的变更请求中，也可能是从需求开发过程中接收的新需求的形式。不管是何种来源或形式，由需求变更所驱动的活动都应得到相应的管理。

在敏捷环境中，需求通过如产品工作清单（product backlog）、故事卡（story card）与屏幕模型（screen mock-up）等机制得以沟通与跟踪。对于需求的承诺由团队集体作出或由授权的团队领导者作出。基于已取得的进展、对需求理解的加深以及解决方案的逐步显现，定期地（如每天、每周）进行工作分配的调整。需求与工作产品的可追溯性与一致性也可通过上述机制以及在迭代开始或迭代结束活动（如“回顾会”或“演示日”等）中得到处理。（见第一部分中的“使用敏捷方法时对CMMI的解读”。）