需求管理（Requirements Management， REQM）的目的在于管理项目的产品与产品组件需求，并确保那些需求与项目计划和工作产品间的协调一致。
一、概述
“需求管理”过程管理所有由项目收到或产生的需求，包括技术与非技术需求，以及由组织赋予项目的需求。特别要指出的是，如果实施了“需求开发”过程域，由该过程域中的各过程产生的产品与产品组件需求也将由需求管理过程来进行管理。在各个过程域中使用到的术语“产品”与“产品组件”，其含义也包含了服务、服务系统以及它们的组件。当“需求管理”、“需求开发”与“技术解决方案”过程域都得到实施时，其相关的过程能够紧密结合并同时执行。项目应采取适当的步骤来确保已批准的需求集得到管理，以支持项目计划与执行的需要。当项目从已批准的需求提供方处接收了需求，应在将这些需求纳入项目计划之前，与需求提供方一起评审这些需求，以解决问题并避免误解。一旦需求提供方与需求接收方达成一致，应从项目参加者处获得对需求的承诺。随着需求的演变，项目对需求的变更进行管理，并识别
在计划、工作产品与需求间的不一致。需求管理活动还包括将需求变更及其依据文档化，并维护源需求、所有产品与产品组件需求，以及其它规定的工作产品之间的双向可追溯性。（见术语表中“双向可追溯性”的定义。）所有项目都有需求。在维护活动中，变更是对已有的需求、设计或实现的变更。在增量式交付产品能力的项目中，其变更可能是由于客户需要的演变、技术上的成熟或过时以及标准的演变而产生的。在上述两种情况下，需求变更（如果有的话）可能记录在客户或最终用户提出的变更请求中，也可能是从需求开发过程中接收的新需求的形式。不管是何种来源或形式，由需求变更所驱动的活动都应得到相应的管理。在敏捷环境中，需求通过如产品工作清单（product backlog）、故事卡（storycard）与屏幕模型（screen mock-up）等机制得以沟通与跟踪。对于需求的承诺由团队集体作出或由授权的团队领导者作出。基于已取得的进展、对需求理解的加深以及解决方案的逐步显现，定期地（如每天、每周）进行工作分配的调整。需求与工作产品的可追溯性与一致性也可通过上述机制以及在迭代开始或迭代结束活动（如“回顾会”或“演示日”等）中得到处理。（见第一部分中的“使用敏捷方法时对 CMMI 的解读”。）
二、特定目标与特定实践摘要
SG 1 管理需求
SP 1.1 理解需求
SP 1.2 获得对需求的承诺
SP 1.3 管理需求变更
SP 1.4 维护需求的双向可追溯性
SP 1.5 确保项目工作与需求间的协调一致
SG 1 管理需求
需求得到管理，与项目计划和工作产品间的不一致得到识别。
项目通过以下活动来在整个项目期间维护当前已批准的需求集：
• 管理所有需求变更
• 维护需求、项目计划与工作产品之间的关联关系
• 确保需求、项目计划与工作产品之间的协调一致
• 采取纠正措施
参阅“需求开发”过程域以进一步了解如何分析并确认需求。
参阅“技术解决方案”过程域中的“开发备选解决方案和选择准则”特定实践以进一步了解如何确定需求的可行性。
参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施直至关闭。
SP 1.1 理解需求
与需求提供方一起达成对需求含义的理解。
随着项目的逐步成熟和需求的产生，所有的项目活动或专业领域将接收需求。为避免需求蔓延，应建立准则来指定接收需求的适当渠道或官方来源。需求接收方与提供方一起对需求进行分析，以确保对于需求的含义达成一个相容的、共同的理解。这些分析和对话的结果是已批准的需求集。
工作产品实例
1. 区分适当的需求提供方的准则列表
2. 评价与验收需求的准则
3. 基于准则的分析结果
4. 已批准的的需求集
子实践
1. 建立区分适当的需求提供方的准则。
2. 建立评价与验收需求的客观准则。
缺少评价与验收需求的准则通常会导致不充分的验证、代价高昂的返工或客户的拒绝
评价与验收准则的实例有：
• 描述清晰而适当
• 完整
• 彼此一致
• 可唯一识别
• 与架构方法与质量属性的优先级划分相一致
• 适于实现
• 可验证（即可测试）
• 可追溯
• 可实现
• 与业务价值结合紧密
• 被认定为客户的一个高优先级需求
3. 分析需求以确保建立的准则得到了满足。
4. 与需求提供方达成对需求的理解，从而使项目参与者能够对其作出承诺
SP 1.2 获得对需求的承诺
获得项目参与者对需求的承诺。
参阅“项目监督与控制”过程域以进一步了解如何监督承诺。
前一条特定实践处理的是与需求提供方达成对需求的理解。本特定实践处理的是在执行必要的需求实现活动的人员之间达成一致与承诺。需求在项目期间会逐渐演变。本特定实践确保项目参与者随着需求的演变，对当前的、已批准的需求及其导致的项目计划、活动与工作产品的变更作出承诺。
工作产品实例
1. 需求影响评估
2. 对需求与需求变更的文档化的承诺
子实践
1. 评估需求对已有承诺的影响。
当需求变更或新需求产生时，应评价其对项目参与者的影响。
2. 协商并记录承诺。
在项目参与者对新需求或需求变更作出承诺前，应先协商对既有承诺的变更
SP 1.3 管理需求变更
随着项目进行中需求的演变，对需求变更进行管理。
参阅“配置管理”过程域以进一步了解如何跟踪并控制变更。
需求变更有各种原因。随着要求的变化与工作的进展，可能必须对已有需求进行变更。有必要高效而有效地管理这些新增需求与变更。为有效地分析变更的影响，有必要了解每个需求的来源，并将变更的依据文档化。项目可能要对需求易变性的适当的度量项进行跟踪，以判断是否有必要采用新的变更控制方法或修订已有的变更控制方法。
工作产品实例
1. 需求变更请求
2. 需求变更影响报告
3. 需求状态
4. 需求数据库
子实践
1. 将对项目提出的或由项目产生的所有需求与需求变更文档化。
2. 维护需求变更历史信息，包括变更的依据。
维护变更历史信息有助于跟踪需求易变性。
3. 从相关干系人的立场评价需求变更的影响。
影响产品架构的需求变更可能会对很多干系人产生影响
4. 确保需求与变更的数据对项目可用。
SP 1.4 维护需求的双向可追溯性
维护需求与工作产品之间的双向可追溯性。
本特定实践旨在维护需求的双向可追溯性（见术语表中“双向可追溯性”的定义。） 当需求得到有效管理时，我们能够建立起从源需求到其较低层次需求以及从较低层次需求回溯到源需求的可追溯性。这种双向可追溯性有助于确定是否所有的源需求都得到了完全的处理以及是否所有较低层次需求都可以追溯到一个有效的来源。需求可追溯性也包括与其它实体如中间的与最终的工作产品、设计文档的变更以及测试计划等的关联。可追溯性既包括垂直关联，也包括水平关联，如接口两端。在评估需求变更对项目活动与工作产品的影响时，可追溯性尤为重要。
可追溯性要考虑的方面，实例有：
• 可追溯性的范围：可追溯性所需的边界
• 可追溯性的定义：需要建立逻辑关联的元素
• 可追溯性的类别：何时需要建立水平与垂直可追溯性
此类双向可追溯性并不总是自动化的。可以用电子表格、数据库及其它通用工具来手工实现。
工作产品实例
1. 需求可追溯性矩阵
2. 需求跟踪系统
子实践
1. 维护需求可追溯性，以确保将低等级（即衍生的）需求的来源文档化。
2. 维护从需求到其衍生需求及其在工作产品中的分配的需求可追溯性。
可能需要维护其可追溯性的工作产品包括：架构、产品组件、开发迭代（或增量）、功能、接口、对象、人员、过程及其它工作产品。
3. 创建需求可追溯性矩阵。
SP 1.5 确保项目工作与需求间的协调一致
确保项目计划和工作产品与需求之间保持协调一致。
本特定实践识别需求与项目计划、工作产品之间的不一致，并采取纠正措施来纠正这些问题。
工作产品实例
1. 需求与项目计划、工作产品之间不一致的记录文档，包括来源与条件
2. 纠正措施
子实践
1. 评审项目计划、活动以及工作产品与需求及其变更的一致性。
2. 识别不一致的来源（如果有的话）。
3. 识别由需求基线的变更引起的，应对计划与工作产品进行的变更。
4. 启动必要的纠正措施
Doker 做好产品，做暖心服务的3C品牌！！！
文章下方有交流学习区！一起学习进步！也可以前往官网，加入官方微信交流群！！！
你的支持和鼓励是我创作的动力❗❗❗
官网：Doker 多克;
