收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是，为定义和管理项目范围（包括产品范围）奠定基础。图5-4描述本过程的输入、工具与技术和输出，图5-5是本过程的数据流向图。

     图5-4 收集需求：输入、工具与技术和输出

     图5-5 收集需求的数据流向图

让干系人积极参与需要发掘和分解工作（分解成需求），并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，项目必须满足的条件或能力，或者产品、服务或成果必须具备的条件或能力。需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。需求将成为工作分解结构（WBS）的基础。需求也是成本、进度和质量规划的基础，有时也是采购工作的基础。收集需求从分析项目章程（见4.1.3.1节）、干系人登记册（见13.1.3.1节）及干系人管理计划（见13.2.3.1节）中的信息开始。

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

 业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。

 干系人需求。干系人或干系人群体的需要。

 解决方案需求。为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：

○ 功能需求是关于产品能开展的行为。如流程、数据，以及与产品的互动。

○ 非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量。如可靠性、安防性、性能、安全性、服务水平、可支持性、保留/清除等。

 过渡需求。从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。

 项目需求。项目需要满足的行动、过程或其他条件。

 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。

5.2.1 收集需求：输入

5.2.1.1 范围管理计划

见5.1.3.1节。范围管理计划使项目团队知道应该如何确定所需收集的需求的类型。

5.2.1.2 需求管理计划

见5.1.3.2节。需求管理计划规定了用于整个收集需求过程的工作流程，以便定义和记录干系人的需要。

5.2.1.3 干系人管理计划

见13.2.3.1节。从干系人管理计划中了解干系人的沟通需求和参与程度，以便评估并适

应干系人对需求活动的参与程度。

5.2.1.4 项目章程

见4.1.3.1节。从项目章程中了解项目产品、服务或成果的高层级描述，并据此收集详细的需求。

5.2.1.5 干系人登记册

见13.1.3.1节。从干系人登记册中了解哪些干系人能够提供需求方面的信息。干系人登记册也记录了干系人对项目的主要需求和期望。

5.2.2 收集需求：工具与技术

5.2.2.1 访谈

访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和 / 或多个被访者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付的成果特征和功能。访谈也可用于获取机密信息。

5.2.2.2 焦点小组

焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”

的访谈更热烈。

5.2.2.3 引导式研讨会

引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，研讨会能够比单项会议更早发现问题，更快解决问题。

例如，在软件开发行业，就有一种称为“联合应用设计/开发（JAD）”的引导式研讨会。这种研讨会注重把业务主题专家和开发团队集中在一起，来改进软件开发过程。在制造行业，则使用“质量功能展开（QFD）”这种引导式讨论会，来帮助确定新产品的关键特征。QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个干系人将从功能中受益（角色），他需要实现什么（目标），以及他将获得的收益（动机）。用户故事在敏捷方法中广泛使用。

5.2.2.4 群体创新技术

可以组织一些群体活动来识别项目和产品需求。下面是一些常用的群体创新技术：

 头脑风暴法。一种用来产生和收集对项目需求与产品需求的多种创意的技术。头脑风暴法本身不包含投票或排序，但常与包含该环节的其他群体创新技术一起使用。

 名义小组技术。用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。

 概念/思维导图。把从头脑风暴中获得的创意整合成一张图的技术，以反映创意之间的共性与差异，激发新创意。

 亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。

 多标准决策分析。借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。

5.2.2.5 群体决策技术

群体决策技术就是为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序。

达成群体决策的方法有很多，例如：

 一致同意。每个人都同意某个行动方案。达成一致同意的一种方法就是德尔菲技术，由一组选定的专家回答问卷，并对每轮需求收集的结果给出反馈。只有主持人可以看到专家的答复，以保持匿名状态。

 大多数原则。获得群体中超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，防止因平局而无法达成决策。

 相对多数原则。根据群体中相对多数者的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。

 独裁。在这种方法中，由某一个人为群体做出决策。

在收集需求过程中，上述群体决策技术都可以与群体创新技术联合使用。

5.2.2.6 问卷调查

问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。

5.2.2.7 观察

观察是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。观察，也称为“工作跟踪”，通常由观察者从外部来观看业务专家如何执行工作。也可以由“参与观察者”来观察，他通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

5.2.2.8 原型法

原型法是指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。因为原型是有形的实物，它使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

5.2.2.9 标杆对照

标杆对照将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。

5.2.2.10 系统交互图

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

5.2.2.11 文件分析

文件分析就是通过分析现有文档，识别与需求相关的信息，来挖掘需求。可供分析的文档很多，包括（但不限于）：商业计划、营销文献、协议、建议邀请书、现行流程、逻辑数据模型、业务规则库、应用软件文档、业务流程或接口文档、用例、其他需求文档、问题日志、政策、程序和法规文件（如法律、准则、法令等）。

5.2.3 收集需求：输出

5.2.3.1 需求文件

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

需求文件的主要内容包括（但不限于）：

 业务需求，包括：

○ 可跟踪的业务目标和项目目标；

○ 执行组织的业务规则；

○ 组织的指导原则。

 干系人需求，包括：

○ 对组织其他领域的影响；

○ 对执行组织内部或外部团体的影响；

○ 干系人对沟通和报告的需求。

 解决方案需求，包括：

○ 功能和非功能需求；

○ 技术和标准合规性需求；

○ 支持和培训的需求；

○ 质量需求；

○ 报告需求（可用文本记录或用模型展示解决方案需求，也可两者同时使用）。

 项目需求，例如：

○ 服务水平、绩效、安全和合规性等；

○ 验收标准。

 过渡需求。

 与需求相关的假设条件、依赖关系和制约因素。

5.2.3.2 需求跟踪矩阵

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

需求跟踪包括（但不限于）跟踪以下内容：

 业务需要、机会、目的和目标；

 项目目标；

 项目范围/ WBS可交付成果；

 产品设计；

 产品开发；

 测试策略和测试场景；

 高层级需求到详细需求。

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

      图5-6 需求跟踪矩阵示例