- 用户故事
- 功能分解（特别是对于复杂的网络物理系统）
- 功能描述
- 确定相关利益相关者
- 建立项目目标和目的
- 从利益相关者那里获取需求
- 记录需求
- 确认需求
- 确定需求的优先级
- 客户利益相关者
- 决策者
- 用户
- 系统管理员
- 其他受影响的客户部门
- 内部利益相关者
- 高管
- 工程
- 营销
- 销售
- 客户支持（包括现场维护团队，如果适用）
- 主要供应商
- 分销商和其他合作伙伴
- 您的团队可以轻松浏览和理解
- 可供所有利益相关者查看
- 提供可追溯到其他文档的便利。
需求收集是了解您要构建的内容以及构建它的原因的过程。需求收集通常被视为开发软件应用程序或信息物理系统（如飞机、航天器和汽车）的一部分（其中规范涵盖软件和硬件）。但它可以应用于任何产品或项目，从设计新帆船到建造露台甲板再到改造浴室。
需求收集的三个主要子过程
需求收集过程的关键要素是三个重叠的子过程：需求获取、需求文档和需求理解。
需求获取是从所有相关利益相关者那里索取和收集顶级需求的过程。应努力考虑客户、其用户、您自己公司内部利益相关者以及您的主要供应商的需求。
需求文档将需求获取过程的输入组织成适合您组织的任何格式。此格式可能包括：
这些将收集在顶级需求规范中，如产品需求文档 (PRD) 或系统规范。此顶级规范的目的是让项目团队的所有成员都能看到这些故事和描述。
需求确认是确保所有利益相关者和团队成员对您要构建的内容有共同理解的过程。这涉及审查和细化需求。它很可能还需要额外的引出和修改文档。
需求收集有哪些好处？
除了有需求可依托这一明显优势之外，良好的需求收集流程还具有以下优势：
大大提高了客户和用户获得所需内容的机会。利益相关者通常难以用语言准确表达他们的需求。您必须帮助他们，而且需要进行一些挖掘。
降低项目失败的可能性。在项目失败后，经常听到的抱怨是“需求不明确”。
通过在开发开始前发现需求问题来降低项目的总成本。模糊或未完全理解的需求通常会导致代价高昂的废品和返工。许多研究表明，修复需求错误的成本在后续开发阶段呈指数级增长。
需求收集的一些关键挑战
项目因需求不充分而失败的原因之一是：需求收集并不容易。以下是一些主要挑战：
找到所有合适的利益相关者
项目通常有“隐藏的”利益相关者。发现他们很重要。您调查的群体应该不仅仅包括明显的决策者。不要忘记与客户支持代表、维护技术人员和其他与客户直接接触的人交谈。实际上，他们自己就是您现有产品的用户。
Phase2 Technology 创新总监 Jordan Hirsch 表示：“每天被迫使用未经他们同意设计的系统的不满用户是项目失败的关键因素。”
了解利益相关者真正想要什么
您的利益相关者可能对自己想要什么没有清晰的认识。他们可能无法告诉您完整的故事。他们可能有隐藏的痛点或愿望、未说明的目标或假设。您将不得不提出大量探索性问题并比较答案。您还需要对流程进行多次迭代才能达成共识。
规划变更
在整个需求收集过程中，您会遇到忘记询问的问题和利益相关者忘记告诉您的事情。您会遇到不断变化的优先事项和实施过程中遇到的问题。
制定应对这些变化的计划是明智的。您需要留出时间来解决问题、记录新需求并进行额外审查。
6 步需求收集流程
需求收集流程包含六个步骤。其中三个步骤（步骤三至步骤五——流程的主要部分）我们已经提到为需求收集的关键子流程。完整的六个步骤是：
需要注意的是，虽然这些步骤通常按列出的顺序启动，但它们之间存在大量重叠和迭代。因此，当我们单独查看每个步骤时，最好将它们视为子流程而不是步骤。
确定相关利益相关者
从每个相关利益相关者组中寻找合格的代表。根据您的项目，这些可能包括：
记得搜索“隐藏的利益相关者”。在开始引出需求之前，在早期会议中提出探索性问题。确定需要参与的所有利益相关者群体。理想情况下，您希望从每个有切身利益的群体那里获得意见；让他们都有机会陈述自己的需求。
建立项目目标和目的
您想通过这个新产品或项目实现什么目标？您的客户希望从产品中获得什么样的总体结果？贵公司的业务目标是什么？要实现这些目标和结果，您需要实现哪些可操作、可衡量的目标？
把它们写下来。清楚地陈述它们，并让所有利益相关者签署它们。您的目标和目的将作为您决策的框架。
您编写的每个需求都应有助于满足项目目标并实现目标。如果不能，您应该将其丢弃或将其作为未来版本的候选。
从利益相关者那里获取需求
这是三个需求收集子流程中的第一个，这些子流程具有高度迭代性和重叠性。即使在敏捷环境中，您也可能会经历几个获取、记录和审查/确认周期，然后才能获得可行的规范以开始开发。
获取可以通过多种方式进行。久经考验的技术包括调查、问卷和访谈。访谈和后续会议将在以后的迭代中盛行。
务必在访谈期间积极倾听。提出探索性问题并做大量笔记。之后，整理您的笔记并根据需要跟进。彻底记录每个练习或遭遇。
记录需求
一旦需求开始从您的获取过程中出现，就开始记录它们。
将它们写下来并以贵组织同意的任何格式收集起来。这可能是贵公司设计的产品需求文档 (PRD)、政府规定的系统需求规范、供应商提供的需求管理 (RM) 工具（如 Jama Connect）、电子表格、数据库或整个团队可以访问的任何其他适当的存储库。
最重要的是需求文档……
模板非常有用，无论是对于整个规范还是单个需求。可靠的、经过实战考验的模板和标准化格式有助于提供清晰度和帮助导航。
确认需求
与所有利益相关者一起审查需求。确保需求清楚地表达了意图，并且各方对每个需求都有共同的理解。如果您发现需求中有任何歧义，请修改它。
您还应该尽可能通过原型设计和测试来验证您的需求。现代原型设计工具可以快速轻松地创建符合您规范的工作模型。然后，您可以使用该模型执行可行性、可用性和产品概念测试。
在确定各个需求后，让利益相关者签字同意。在最终审查期间对整个规范执行相同的操作。
确定需求的优先级
大多数工程开发计划在过程中都会遇到意想不到的挑战。遇到意想不到的障碍。时间表延误。优先级发生变化。能够适应这些挑战和变化很重要。
这就是为什么根据每个需求如何影响您发布的目标和目的来确定需求的优先级至关重要。
许多产品经理通过给功能贴上标签来确定其优先级，例如“必须有”、“非常想要”和“最好有”。但它对这些类别中的每个需求进行排序也很重要。这样做有两个原因。
首先是上市时间。时间表经常会延误。如果出现这种情况，您可能需要削减功能和需求以满足发布日期。您不希望您的团队首先实现最简单的需求，结果却发现没有足够的时间来完成所有必需的需求。
第二个原因是需求在不断发展。在实施过程中，您可能会发现新的需求。有些需求可能至关重要，并且在优先级上取代了现有需求。您需要知道这些新需求在您的优先级中处于什么位置。如果您不知道，不太重要的因素将决定首先实施什么，这可能会对产品的成功产生不利影响。
常见的需求收集陷阱
对听到的内容做出假设
小心简单、宽泛的需求。不要假设您完全了解它们的含义。最重要的是，不要假设所有利益相关者都以相同的方式解释这些需求。
诸如“网站应有博客”之类的宽泛陈述可能会掩盖大量潜在的假设。仔细研究此类需求。提出大量问题。帖子将如何显示？作者应如何管理？评论、类别、标记如何？是否应该有 RSS 源？……等等。
交叉检查您收到的答案。然后提出一组更具体、可验证的需求，每个人都可以同意。
关注如何而不是什么
需求解决两件事。第一是产品必须做什么（功能需求）。第二是产品如何工作的必要约束（非功能需求）。
需求不应解决产品如何完成其必须完成的工作。换句话说，在非功能性需求的约束范围内，您的规范应尽可能与实现无关。
在需求获取过程中，尽量不要考虑如何实现产品。忘记您的工程部门痴迷的最新技术、软件团队的日常工具以及您认为产品基线缺少的功能。而是专注于利益相关者的需求。
首先倾听利益相关者的意见。然后收集、审查和完善您的需求。最后，完成所有这些后，找出基线中的差距，并确定哪些技术可以满足您的客户和利益相关者的真正需求。
与利益相关者的协商不足
系统工程师和产品经理在收集需求时犯的最大错误可能是未能充分咨询利益相关者。利益相关者协商有几个方面。
首先，深入研究（并跟进）每个利益相关者群体以充分了解他们的需求至关重要。未能做到这一点是导致需求失败的主要原因之一。
第二个重要方面是透明度。每次采访、会议和调查后，都要清理笔记并分享。最简单的方法是使用所有团队成员都可以访问的现代 RM 工具。Jama Connect 等工具允许您将笔记附加到需求本身，以便进行可追溯性。这大大提高了流程速度并简化了审查任务。
该领域的第三个潜在陷阱是审查不足。一定要举行审查，让利益相关者可以审查需求、提供反馈、提出反对意见并捍卫自己的立场。让所有相关利益相关者参与的公开讨论有助于发现和纠正需求缺陷并达成共识。
最后，让所有利益相关者签署需求，承认他们理解这些需求，并且这些需求足以让他们完成工作。一定要让利益相关者清楚他或她的签名意味着什么。
敏捷开发的需求收集
敏捷的需求收集有何不同？
首先，敏捷团队期望快速行动。因此，他们的需求管理解决方案必须满足开发人员对速度的需求。
透明度是另一个优先事项。需求文档必须不断更新、易于注释并提供清晰的可追溯性。
这两种需求使得 Word 文档和 Excel 电子表格成为敏捷团队的不良 RM 选择。它们的静态性质使它们更新繁琐且共享繁琐。这些缺点使得很难让每个人都快速访问最新配置并让他们保持一致。此外，文档和电子表格不提供注释和可追溯性的原生功能。
RM 产品（如 Jama Connect）可帮助敏捷团队简化需求收集并在整个 ALM 产品开发过程中实时协作管理需求。
您是否在敏捷开发环境中工作？下载我们的数据表，了解 Jama Connect 如何简化需求收集和管理。
