5.2 收集需求
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅在项目的预定义点开展。图 5-4 描述本过程的输入、工具与技术和输出。图 5-5 是本过程的数据流向图。
图 5-5收集需求：数据流向图
《PMBOK® 指南》并没有专门讨论产品需求，因为产品需求因行业而异。《从业者商业分析：
实践指南》[7] 提供了有关产品需求的更深入信息。让相关方积极参与需求的探索和分解工作（分解成项目和产品需求），并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。
采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建 WBS。相反，在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。
适用于本过程的数据分析技术包括（但不限于）备选方案分析。本技术用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。
图 5-5收集需求：数据流向图
见 1.2.6 节。会影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准。
会影响收集需求过程的事业环境因素包括（但不限于）：
会影响收集需求过程的组织过程资产包括（但不限于）：
适用于收集需求过程的决策技术包括（但不限于）：
见 4.1.2.3 节。可用于本过程的人际关系与团队技能包括（但不限于）：
- 名义小组技术。名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式，由四个步骤组成：
- 向集体提出一个问题或难题。每个人在沉思后写出自己的想法。
- 主持人在活动挂图上记录所有人的想法。
- 集体讨论各个想法，直到全体成员达成一个明确的共识。
- 个人私下投票决出各种想法的优先排序，通常采用 5 分制，1 分最低，5 分最高。为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。
- 观察和交谈。观察和交谈是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。观察，也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
- 引导。见 4.1.2.3 节。引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。
研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于相关方达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。
适合采用引导技能的情境包括（但不限于）：
- 联合应用设计或开发 (JAD)。JAD 会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程。
- 质量功能展开 (QFD)。制造行业则采用 QFD 这种引导技能来帮助确定新产品的关键特征。QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。
- 用户故事。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个相关方将从功能中受益（角色），他需要实现什么（目标），以及他期望获得什么利益（动机）。
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要。
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是，为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。图 3-4 描述了本过程的输入和输出。