原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。

原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。
因为原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。
原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。
故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。
在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。

本过程的主要作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅在项目的预定义点开展。

《PMBOK® 指南》并没有专门讨论产品需求，因为产品需求因行业而异。

《从业者商业分析：实践指南》[7] 提供了有关产品需求的更深入信息。

让相关方积极参与需求的探索和分解工作（分解成项目和产品需求），并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。

需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。

应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。

需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。

系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式（见图 5-6）。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

需求文件描述各种单一需求将如何满足与项目相关的业务需求。
一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。
需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。
前者是相关方的需要，后者是指如何实现这些需要。
把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求的类别包括：

• 业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
• 相关方需求。相关方或相关方群体的需要。
• 解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
• 功能需求。功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。
• 非功能需求。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
• 过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
• 项目需求。项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
• 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。
需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

跟踪需求包括（但不限于）：

• 业务需要、机会、目的和目标；
• 项目目标；
• 项目范围和 WBS 可交付成果；
• 产品设计；
• 产品开发；
• 测试策略和测试场景；
• 高层级需求到详细需求。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。
需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。
为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程做出规定：

• 制定项目范围说明书；
• 根据详细项目范围说明书创建 WBS；
• 确定如何审批和维护范围基准；
• 正式验收已完成的项目可交付成果。

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。

本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。

本过程仅开展一次或仅在项目的预定义点开展。

范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

制定范围管理计划和细化项目范围始于对下列信息的分析：

• 项目章程（见 4.1.3.1 节）中的信息、

• 项目管理计划（见 4.2.3.1 节）中已批准的子计划、

• 组织过程资产（见 2.3 节）中的历史信息和相关事业环境因素（见 2.2 节）。

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。
根据《从业者商业分析：实践指南》[7]，有些组织称之为“商业分析计划”。
需求管理计划的主要内容包括（但不限于）：

• 如何规划、跟踪和报告各种需求活动；
• 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
• 需求优先级排序过程；
• 测量指标及使用这些指标的理由；

反映哪些需求属性将被列入跟踪矩阵的跟踪结构。

可基于行业需求和组织模板创建测试与评估文件。
它们是控制质量过程的输入，用于评估质量目标的实现情况。
这些文件可能包括专门的核对单和详尽的需求跟踪矩阵。

管理质量是把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程。

本过程的主要作用是，提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因。

管理质量使用控制质量过程的数据和结果向相关方展示项目的总体质量状态。本过程需要在整个项目期间开展。

管理质量有时被称为“质量保证”，但“管理质量”的定义比“质量保证”更广，因其可用于非项目工作。
在项目管理中，质量保证着眼于项目使用的过程，旨在高效地执行项目过程，包括遵守和满足标准，向相关方保证最终产品可以满足他们的需求、期望和要求。
管理质量包括所有质量保证活动，还与产品设计和过程改进有关。
管理质量的工作属于质量成本框架中的一致性工作。

管理质量过程执行在项目质量管理计划中所定义的一系列有计划、有系统的行动和过程，有助于：

• 通过执行有关产品特定方面的设计准则，设计出最优的成熟产品；
• 建立信心，相信通过质量保证工具和技术（如质量审计和故障分析）可以使未来输出在完工时满足特定的需求和期望；
• 确保使用质量过程并确保其使用能够满足项目的质量目标；
• 提高过程和活动的效率与效果，以获得更好的成果和绩效并提高相关方的满意程度。

项目经理和项目团队可以通过组织的质量保证部门或其他组织职能执行某些管理质量活动，
例如故障分析、实验设计和质量改进。
质量保证部门在质量工具和技术的使用方面通常拥有跨组织经验，是良好的项目资源。

管理质量被认为是所有人的共同职责，包括项目经理、项目团队、项目发起人、执行组织的管理层，甚至是客户。
所有人在管理项目质量方面都扮演一定的角色，尽管这些角色的人数和工作量不同。
参与质量管理工作的程度取决于所在行业和项目管理风格。
在敏捷项目中，整个项目期间的质量管理由所有团队成员执行；但在传统项目中，质量管理通常是特定团队成员的职责。