笔记-项目范围管理-需求工程-需求管理

1. 需求管理（Requirements Management，REQM）

Requirements management is the process of documenting，analyzing，tracing，prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders。It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
需求管理是记录，分析，跟踪，确定优先级，就需求达成一致的过程，然后控制变更和与相关的干系人进行沟通的过程。它是一个贯穿整个项目的连续过程。需求是项目（产品或服务）成果应符合一种能力。

“需求”指的是由项目接受的或项目产生的产品和产品构件需求，包括由组织征集的对项目的需求。这种需求既有技术性的，也有非技术性的。

需求工程分为需求获取、需求分析、需求定义和需求验证。或：分为5个独立的阶段：需求获取、需求建模、形成需求规格、需求验证和需求管理。

需求管理（Requirements Management，REQM）目的：

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型，需求基线是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合，经评审批准，这些文档就定义了开发工作的需求基线，这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。

• 确保各方对需求的一致理解；
• 管理和控制需求的变更；
• 从需求到最终产品的双向跟踪，维护需求并且确保能把对需求的更改反映到项目计划、活动和工作产品中。

2. 需求开发

需求开发分为需求获取、需求分析、需求定义和需求验证。

2.1. 需求获取

积极的与用户进行交流，捕捉、分析和修正用户对目标系统的需求，并提炼出符合解决问题的用户需求，产生《用户需求说明书》。

collecting requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
收集需求是确定、记录和管理干系人的需求和要求以满足项目目标的过程。

2.2. 需求分析

需求分析的目的是对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。

2.2.1. 需求分析的方法

需求分析的方法主要有三种：结构化分析方法、面向对象分析方法和面向问题域的分析方法。

2.2.1.1. 结构化分析方法

结构化分析方法的实质是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。所以面向数据流分析方法属于结构化分析方法的范畴。

2.3. 需求定义

需求定义的目标是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。

2.4. 需求验证

需求验证是指开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

“需求管理”与“需求开发”密切合作；
“需求开发”涉及到把项目关系人的需要转换成产品需求和决定如何在各个产品构件之间安排或分配需求。
在“需求管理”中，要收集需求的变更和变更的理由，并且维持对原有需求和所有产品及产品构件需求的双向跟踪。在软件成熟度模型集成（CMMI）中，“需求开发”对应“需求开发”过程域，“需求管理”对应“需求管理”过程域。

3. 需求管理流程

需求管理流程主要包括6大部分：制订需求管理计划、求得对需求的理解、求得对需求的承诺、管理需求变更、维护对需求的双向跟踪性、识别项目工作与需求之间的不一致性。另外，与此流程相关的还有：关于组织的总体方针和需求管理模板。

3.1. 制订需求管理计划

需求管理计划的主要内容包括确定需求管理软硬件资源、需求跟踪性矩阵、需求变更请求表等。由项目经理审批该计划。制订需求管理计划，以便于需求管理人员按计划地开展需求管理工作，并保持需求管理工作的一致性。

3.2. 求得对需求的理解

设法理解需求提供者提出的这些需求的含义，实际就是我们平常所说的“确认需求”活动。

随着项目的成熟和各项需求的派生，所有各项活动或工程学科都要接受相应的需求。为了避免这些需求漫无边际地外延或“遗漏”，要建立一些准则，以便指明接受需求的适当的渠道或正式来源。接受需求的活动应该与需求提供者的需求分析活动一起进行，以确保对需求的含义达成共识。分析和对话的结果是达成一致的需求集合。

3.3. 求得对需求的承诺

这个特定实践实现从各个项目参加者处求得对需求的承诺。

即使某个实践以前实现过与需求提供者对需求的共识，但是现在实施这个实践时，还是要在那些必须进行各项为实现这些需求所需的活动人员之间达成一致和建立承诺。在整个项目推进中，特别是在“需求开发”过程域的各项活动的进程中，需求可能会演变。随着需求的演变，要求在所有项目干系人之间对己批准的现行需求重新建立承诺，并且对项目计划、活动和工作产品中的后续变更做出承诺。

3.4. 管理需求变更

这个特定实践实现各项需求在项目推进期间发生演变的同时，对需求的变更进行管理。

在项目推进期间，需求会由于各种各样原因而发生变更。随着原来的需要发生变化和工作的推进，将会产生一些附加的需求，因此必然要对现行的需求做出相应的变更。有效地管理这些需求和需求变更相当重要。有必要了解每个需求的来源，并且做出变更理由的文件。项目经理可能希望跟踪相应的需求变化度量数据，以便判断是否需要采取新的控制措施或对已有的控制做出调整。

3.5. 维护对需求的双向跟踪性

这个特定实践维护在需求与项目计划和工作产品之间的双向跟踪性。

这个特定实践的目的在于维护对每个产品分解层的双向跟踪性。如果需求管理得好，就可以建立起从来源需求到它的较低层次需求的跟踪性，和从较低层次的需求到它们的来源需求的跟踪性。这种双向跟踪性有助于确定是否所有来源需求都完全得到处理，是否所有的低层需求都可以跟踪到有效的来源。需求的跟踪性还可以覆盖与其他实体的关系，例如与产品、设计文档的变更、测试计划、验证、确认以及工作任务等的关系。跟踪性应该覆盖横向和纵向（例如接口两边）的关系。在评估需求变更对项目计划、活动，以及工作产品的影响时，尤其需要跟踪性。

3.6. 识别项目工作与需求之间的不一致

这个特定实践识别项目计划和工作产品与需求之间的不一致之处。

虽然通过这项活动产生的一些工作产品将成为经过更新的项目计划、活动和工作产品，但是，这些工作产品属于“项目策划”过程的产品，而不是“需求管理”的。这个特定实践旨在发现需求与项目计划和工作产品之间的不一致，并且启动纠正措施。

关于需求管理的描述，正确的是（）。
A.需求管理包括在产品生存周期中维持需求一致性和精确性的所有活动
B.从测试用例和测试报告可得描述中追踪到用户原始需求的过程是正向追踪
C.需求文件之间的跟踪用于检查需求分解中可能出现的错误或遗漏
D.需求跟踪矩阵中可以不体现测试策略和测试场景的跟踪结果

需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动；
从测试用例和测试报告可得描述中追踪到用户原始需求的过程是反向追踪；
需求跟踪矩阵中可以体现测试策略和测试场景的跟踪结果。

转载/整理：
希赛教育的试题解释：https://www.educity.cn/