需求开发与管理过程(Req. Development Mgt. Process)
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层需求变更项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
需求开发的四个过程
需求开发的四个过程软件开发过程是指在软件开发过程中，从需求分析到软件维护的整个过程。
它涉及到需求的获取、设计、编码、测试、部署、维护等多个阶段。
本文将详细介绍需求开发的四个主要过程：需求获取、需求分析、需求设计和需求验证。
一、需求获取需求获取是软件开发过程中的第一个阶段，它主要涉及到与客户、用户和相关利益相关者沟通，以了解他们对软件系统的需求和期望。
在需求获取阶段，开发团队需要采用一系列的技术和方法，如面谈、问卷调查、访谈、观察等手段来获取需求。
需求获取的目的是确定软件开发的范围和目标，为后续的需求分析提供基础。
需求获取过程中，开发团队需要与客户、用户和相关利益相关者进行沟通，深入了解他们的需求和期望。
在沟通的过程中，开发团队应该关注以下几个方面：1.确定需求的优先级和重要性。
通过和客户、用户和相关利益相关者沟通，可以了解到哪些需求是必须的，哪些是可选的，以及哪些对于系统的功能和性能是最重要的。
2.确定需求的可行性和可实现性。
在需求获取过程中，开发团队需要评估需求的可行性和可实现性。
他们需要确定是否有足够的资源和技术来实现这些需求，以及实现这些需求的成本和风险。
3.确定需求的约束和限制。
在需求获取过程中，开发团队也需要了解到有哪些约束和限制对软件开发过程有影响。
这些约束和限制可以是技术上的，如硬件和软件平台的限制，也可以是非技术上的，如成本和时间的限制。
二、需求分析需求分析是软件开发过程中的第二个阶段，它主要涉及到对需求进行详细的分析和规范。
在需求分析阶段，开发团队需要将从需求获取阶段获得的需求进行整理、分类和分析，以便能够进一步确定系统的功能和性能要求。
在需求分析过程中，开发团队需要进行以下几个方面的工作：2.分类需求。
将需求进行分类，按照不同的功能和性能需求进行划分。
3.分析需求。
对需求进行进一步的分析和解读，以确定系统的功能和性能要求。
4.规范需求。
将需求进行规范化，将其转化为能够被开发团队理解和实现的形式。
软件开发过程中的需求分析与管理
软件开发过程中的需求分析与管理在软件开发过程中，需求分析和管理是非常重要的环节。
因为只有了解了客户的需求，才能为客户提供更好的服务和解决方案。
本文将探讨软件开发过程中的需求分析和管理。
一、需求分析需求分析是软件开发中的第一步。
它是了解客户需求和目标，确定可行性和实现的必要性，以及开发任务的数据和信息，包括建立和分析软件功能。
因此，确定需求是软件开发过程中的关键环节。
以下是需求分析的重要内容：1.了解客户需求客户的需求往往与实际产品有很大的差别，因此，我们需要深入了解客户的真正需求，包括功能性和非功能性需求。
这可以通过组织面向客户的会议、采取变换式的方法、开展客户调查等方式来实现。
2.分析和记录需求需求分析还包括分析和记录需求。
分析需求要求我们从客户提供的各种信息中归纳出可操作的需求，而记录需求则是将这些需求写成文档，使其他项目成员可以按照此文档来开发系统。
3.实现需求实现需求是开发人员进行需求分析之后，开始制定软件需求规格说明书，指导编码、测试、维护等软件生命周期过程。
需求规格说明书的目的是清晰明确的确容易理解，从而为开发人员提供清晰的建议，详细说明所需述的概念，建立业务场景，并提出数据字典、流程图、结构图等工具，以便让开发人员更好地理解实际情况。
二、需求管理需求管理是软件开发过程中的另一个关键环节。
为了保障项目能够按时按量地完成，我们必须对需求进行管理。
需求管理的主要内容包括：1.需求变更需求变更是软件开发过程中常见的问题之一。
因为在开发过程中，随着客户需求的变化以及新的想法的提出，需求变更是难以避免的。
因此，我们需要制定详细的需求变更管理计划，按照一定的规模、时间和审批机制来处理变更，保证改变的次数尽可能少，并且能够及时得到跟踪和管理。
2.需求溢出控制需求溢出是指开发人员在实现某个特性或功能时，意外地执行了额外的额要求。
为了避免出现这种情况，我们需要对需求进行溢出控制。
我们可以把需求分成两类：必须的（核心）和可选的（次要的）。
CSI_01_需求开发与管理过程
CMMI 文档编制指南1项目管理体系文件需求开发与管理过程编 撰 人：TMO审 核 人：批 准 人：批准日期：2010-9-1保密级别：机密文档版本：0.0.1北京中软国际信息技术有限公司需求开发与管理过程北京中软国际信息技术有限公司 第 1 页 共 21 页版本历史目录1.引言 ............................................................................................................................. 错误！未定义书签。
1.1.目的............................................................................................................................... 错误！未定义书签。
1.2.适用范围....................................................................................................................... 错误！未定义书签。
1.3.术语和缩略语............................................................................................................... 错误！未定义书签。
1.4.相关文件....................................................................................................................... 错误！未定义书签。
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
需求开发与管理
需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。
虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。
本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。
1 什么是软件需求和需求工程1.1 软件需求的定义在IEEE软件工程标准词汇表(1997年)中定义软件需求为：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
1.2 需求工程的定义需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发管理规范及管理流程
需求开发管理规范及管理流程1.目旳通过定义需求开发和管理过程，规范企业软件开发项目旳需求开发和管理活动，提高需求质量，从而提高软件生产率，减少开发成本，改善软件质量。
应调查顾客旳需求，通过需求分析工作将顾客需求转化为软件需求，同步评审需求旳对旳性，获得需求旳承诺；应控制需求旳变更，并保证项目计划、工作产品与需求旳一致性。
2．需求开发阶段旳工作文献3．需求开发阶段工作流程2.入口准则项目立项、协议签定3.出口准则顾客确认需求4.输入顾客旳需求5.输出1、软件需求规格阐明书2、需求变更表6.重要环节6.1 需求获取1．明确需求获取旳信息。
需求分析师应在需求获取前明确需要获取旳需求信息，以保证在实行需求获取时有旳放矢。
一般需求获取要获取旳信息包括三大类：●与问题域有关旳背景信息（如业务资料，组织构造图，业务处理流程等）；●与规定处理旳问题直接有关旳信息；●顾客对系统旳尤其期望与施加旳任何约束信息。
2．明确需求信息旳来源。
需求分析师在明确了所需要获取旳信息之后，应确定获取需求信息旳来源与渠道，以提高需求分析师在需求获取阶段旳工作效率，使得所搜集旳信息愈加有价值、愈加全面。
需求信息旳来源一般包括：●来自客户旳需求●实行所满足旳需求●竞争对手旳产品优势与局限性3．获取需求信息旳措施。
在明确须获取什么需求、需求旳来源与获取渠道后，应选择至少一种需求获取技术获取有关旳需求，作为需求分析旳根据。
需求获取技术包括但不限于：●客户访谈●客户调查●现场观摩顾客旳工作流程，观测顾客旳实际操作●需求讨论会4．需求信息旳保管。
根据所采用旳需求获取技术，在需求获取过程中将产生不一样旳记录和原始资料，项目组应将这些记录纳入开发库进行配置管理。
需求获取旳记录与资料包括但不限于：●顾客编写旳原始需求文档；●顾客填写旳需求调查表；●顾客访谈旳访谈纪要；●需求研讨会旳会议纪要；●有关旳政策法规文献，业务规则文献以及行业原则文献；●需求原型。
软件需求开发与管理过程研究
估其结果。 如结果无法满足其需求时 ． 则再次进行个人 信息的检索 ． 可能重新进行信息需求分析 ． 或直 接进行
行动的选择。如此循环数次 ， 直到需求满足为止。这一
作 者 简介 ： 俊 （９ ３ ， ， 苏射 阳人 ， 士 ， 徐 １７ －） 男 江 硕 高级 工 程 师 ， 究方 向为 软 件 工 程 、 件 过 程 改进 、 件 质 量 管理 研 软 软
现 计 机 ２ １１ ＠ 代 算 ０． １１
研 究 ｓ开 发
理论 ．与软件需求管理 中的需求确认和需求 变更 控制
的 原 理 是 一致 的
需求管理 的工作 内容 ： 义需求 的基准 ｆ 时提 出 定 适 摘要 以代 表 目前 同意 的需求１ 。审查需求 的变更 申请 ， 评估其 冲击后再决定是否采用 在 控制下将 同意 的需
的主要 原因 ． 并非 由于软件技术 的限制 ． 而是 由于需求
的 不确 定 性 与 管 理 的不 完 善 导 致 的 。软 件 需 求 是 软 件
意识 化状态 ， 在此 阶段 ， 用户 的需 求仍未 成形 ， 一直是
处 于似有似无 、 不稳定 的状态 ： 了第三 阶段 ， 户 可 到 用
以具体 明确地 陈述 自己的问题和需 求 ．但 仍无法和信 息 系统 （ 包括信 息系统 的提供者 ） 做有效的沟通 。最后 到了第 四阶段 ． 用户在 向信息系统提 出问题时 ． 必须 因 为信息 系统 的规则 与限制条件 ．修正 自己的询 问方式 来寻求解答
至下 一 软件 开 发 阶段 的 过 程 项 目需 求 是 制 定 项 目计
企业需 求 ： 企业组 织或有 利益关 系 的客户对 于所
进 行 的 项 目系 统 或 产 品 所 要 求 的高 阶 目标 ．包 括 企 业 对 于 项 目的前 景 与 范 围
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Req. Development & Mgt. Process 需求开发与管理过程Prep分配需求ed by拟制陈刚Date日期2006-05-16Reviewed by 评审人SEPG teamDate日期2007-4-20Approved by批准田松涛Date日期2007-4-24Revision Record 修订记录Table of Contents 目录1Purpose 目的 (5)2Scope 范围 (5)3Abbreviations and Acronyms 术语和缩略语 (5)4Policy 方针 (5)5Process Description 过程描述 (5)5.1Roles and Responsibilities 角色和职责 (6)5.2Entrance Criteria 入口准则 (6)5.3Input 输入 (6)5.4Activities 活动 (6)5.4.1Summarize 总述 (6)5.4.2Flow Chart 流程图 (7)5.4.3Requirements Development and Validation 需求开发及确认 (8)5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10)5.5Output 输出 (11)5.6Exit Criteria 出口准则 (11)6Resource and Tools 资源与工具 (11)7Configuration Management and Assets 配置管理和资产 (11)8Training 培训 (11)9Process Measurement 过程度量 (11)10Tailoring Guidelines 裁剪指南 (12)11Verification 验证 (12)12Related Process 相关过程 (12)13Reference Materials 参考文献 (12)Table List 表目录表格1术语与缩略语 (5)表格2角色和职责 (6)Figure List 图目录图表1需求开发与管理过程 (7)1 Purpose 目的为确保文思创新软件技术有限公司（简称文思创新）在软件开发项目中的工作产品质量稳定，对需求开发和需求管理过程进行规范化描述，特制定本文档。
需求开发是为了准确地获取客户方下发的需求，并对获取到的需求进行正确的理解和分析，最终形成明确的产品需求，以指导后续的设计工作。
需求管理是为了有序地对需求进行管理和控制，并确保需求之间的双向追溯性以及需求与项目计划和工作产品间的一致性。
2 Scope 范围本文档适用于南京文思创新软件技术有限公司中采用瀑布、迭代软件开发模型的软件项目。
读者为项目组成员、项目管理人员和其它相关人员。
3 Abbreviations and Acronyms 术语和缩略语4 Policy 方针1、要确保项目的参与者理解需求，并获得项目的参与者对需求的承诺。
2、要有需求跟踪矩阵来维护需求的双向追溯性，并且当需求发生变更时，及时更新需求跟踪矩阵。
3、在整个需求开发管理过程中，项目经理需时时考虑关键任务和商业驱动，并在必要时调整工作；5 Process Description 过程描述5.1 Roles and Responsibilities 角色和职责5.2 Entrance Criteria 入口准则项目已启动5.3 Input 输入（未定）《项目启动报告》等任何与用户需求相关的材料《产品设计规格》5.4 Activities 活动5.4.1 Summarize 总述本文档包含需求开发和需求管理两大过程。
其中需求开发过程从项目启动初期到所有需求文档开发结束；需求管理过程的启动略晚于需求开发过程，且和需求开发过程迭代进行，并延续至项目结束。
两大过程的具体活动描述见如下文档。
5.4.2 Flow Chart 流程图图表 1 需求开发与管理过程5.4.3 Requirements Development and Validation 需求开发及确认项目启动后，项目经理需识别该项目的需求来源并确定提供需求的客户方接口人，并与客户方接口人明确需求下发的方式及需求接收的准则并将其文档化，在获得双方认可之后纳入配置库，以作为我方人员对《产品设计规格》确认的准则。
5.4.3.1 需求澄清活动项目经理获取《产品设计规格》之后，将其纳入配置库并邮件通知项目组成员。
待项目组成员（包括开发、测试、资料）经过初步分析之后，客户方接口人需指定客户方人员进行需求澄清活动，以保证项目组成员对需求理解的正确性，一致性。
需求澄清的方式包含但不限于如下形式：1）需求澄清会：由客户方人员在需求澄清会议上讲解需求功能点。
我方对需求的疑问及需求答疑需以会议纪要的形式记录；2）需求疑问的文档跟踪：我方人员需定期或事件驱动式整理并文档化需求疑问，并及时将需求疑问的答疑结果和客户方确认。
如上所有的文档需纳入配置库进行管理。
需求澄清活动的内容包含但不限于如下内容：1）讲解《产品设计规格》中涉及到架构需求，以帮助我方人员理解所需实现的功能对架构需求的影响；2）讲解功能性需求和质量属性需求（例如性能、效率、安全性、互操作性等）的具体描述，包括其中量化的功能需求是否合理，以保证我方人员对其中的操作概念和场景描述理解的正确性；3）帮助我方人员理解对于性能、产品架构等有重大影响的关键性需求，并就需求的优先级达成共识；4）讲解接口需求定义（包含内部接口和外部接口），保证接口定义的完整性和兼容性；5）对于一些理解较困难或容易产生歧义的需求，客户方需进一步通过原型图，数据模拟图（包括数据流图、实体关系图、状态转换图等）等，来帮助我方进一步理解需求；对于需求澄清活动中发现的需求类缺陷，待客户方修改完成后，项目经理需及时将最新的《产品设计规格》在配置库上予以更新。
5.4.3.2 评审及确认《产品设计规格》需求澄清活动结束后，我方人员需对更新后《产品设计规格》进行进一步的评审，以保证需求的完整性，正确性，并确保该文档足以指导后期的需求开发活动。
《产品设计规格》评审活动结束后，项目经理按照项目前期确定的需求接收准则对《产品设计规格》进行确认，确认的内容可以包括但不限于如下内容：1)《产品设计规格》是否按照双方约定的形式下发；2)《产品设计规格》下发的时间点是否存在延期，并说明延期存在的相关风险；3)《产品设计规格》的描述是否达到前期约定的接收标准；4)《产品设计规格》的评审缺陷是否修改闭环，且该文档是否能够指导下一阶段的需求开发活动；项目经理需及时将需求确认的情况反馈给客户方，在得到双方的确认通过之后，项目组配置管理员对定稿后的《产品设计规格》进行基线化。
《产品设计规格》基线化之后下发的需求均作为需求变更进行处理，具体的需求变更的流程请参考《配置管理过程》。
5.4.3.3开发《软件需求规格说明书》《软件需求规格说明书》是界定客户的最终需求，并用技术语言对《产品设计规格》中的需求描述做进一步的细化描述。
编制的目的是为了使客户和软件开发者双方对该软件的初始规定有一个共同的理解，指导后续设计活动。
我方开发人员根据基线后的《产品设计规格》，按照指定的模板撰写《软件需求规格说明书》。
开发人员在开发《软件需求规格说明书》的时候需要考虑如下内容：1)识别需求的逻辑、类似功能或者质量属性、设计限制条件、潜在的衍生需求等，以此准则来进行进一步的需求划分，并在需求划分的过程中及时与客户接口人进行确认；2)按照需求划分为每个产品构件分配需求，如有必要还需进行更细化的分配（如子功能或者支持组件）；3)随着产品或产品组件的选择，开发详细的操作概念场景，以定义产品、最终用户及环境的相互作用，以满足操作、维护、支持和处理的需要；4)识别并文档化功能之间或对象之间的接口需求，包括内部接口、外部接口、软件、结构件、产品生命周期过程中的接口（比如测试过程需依赖的物理接口、设计过程中受相应技术的影响产生的新接口等等），并持续维护接口需求；5)定义产品或产品组件的操作环境，产品的相关配置项、网络环境、服务器环境等；6)识别并文档化技术性能的度量以便在开发阶段可以对其进行跟踪。
项目经理可以根据项目情况将如上内容纳入评审checklist，作为评审《软件需求规格说明书》的关注点；5.4.3.4 评审《软件需求规格说明书》《软件需求规格说明书》完成之后，项目经理组织相关人员进行《软件需求规格说明书》的评审活动，参与评审的人员包括但不限于项目组成员、及客户方相关人员。
《软件需求规格说明书》的评审除了关注评审checklist列的内容之外，还需满足如下要求：1)需求的说明清楚、恰当，没有二义性；2)需求的说明完备；3)需求之间彼此一致；4)需求不重复；5)适宜于实现；6)可以验证（例如，可以测试）；7)可以跟踪。
此评审过程可能会引起《产品设计规格》评审和开发《软件需求规格说明书》两个活动的反复进行。
评审活动结束后，若没有达到项目计划阶段确定的质量要求，则由项目经理及项目骨干人员经过分析之后决定是否进行重新评审；若评审通过，项目经理则根据《产品设计规格》及《软件需求规格说明书》建立《需求跟踪矩阵》，从而保证来源需求到它的较低层次需求的溯源性，和从较低层次的需求到它们的来源需求的溯源性。
5.4.4 Trace Requirements 需求跟踪5.4.4.1 维护需求的双向追溯性及与项目的一致性随着项目的开展，为了保证需求的完整性和一致性，项目经理需通过《需求跟踪矩阵》维护需求之间及需求和工作产品之间的关系。
项目组在需求跟踪活动中最低的执行标准为：《产品设计规格》—《软件需求规格说明书》—设计文档—代码；《软件需求规格说明书》—测试方案—测试用例；项目过程中，项目经理通过项目监控（PMC）过程时时监控需求跟踪活动，以识别项目计划、工作产品与需求之间的不一致性，并针对不一致的情况识别不一致的来源、条件和理由；同时也需识别由于需求变更而导致的必须对项目计划、活动和工作产品做出的变更，并启动纠正措施。
同时，项目经理需及时更新《需求跟踪矩阵》，以体现更新的工作产品和需求之间的对应关系；5.4.4.2 管理需求变更项目过程中，项目经理通过项目监控（PMC）过程时时识别需求变更。
针对识别的变更需求（需求类的变更，设计文档类的变更，代码类的变更），项目经理组织项目相关干系人参与对需求变更的影响性分析，分析的内容包括但不限于如下内容：1）需求变更的工作量；2）需求变更所影响的范围；3）实现需求变更存在的技术风险；4）实现需求变更可能对进度、质量、成本带来的风险；分析完成之后，需求提交人将相关性影响分析按照需求变更单（CR）模板中的要求填写，对需求变更的具体操作流程请参考《配置管理过程》。