- 在开发开始前发现需求问题，从而降低项目成本。
- 增加用户和客户获得所需内容的可能性。
- 降低项目失败的风险。
- 文档分析，例如研究流程模型或研究法规。
- 分析系统接口和业务规则。
- 阅读可用的用户反馈。
开发项目的成功依赖于对业务需求的理解和正确需求列表的定义。需求获取是与关键利益相关者沟通和协作以收集见解并确定项目需求的过程。
本文将概述需求获取对产品团队的重要性，讨论不同的获取技术，并概述获取需求所涉及的步骤。
什么是需求引出？
业务分析师根据来自关键利益相关者的数据进行需求引出，以确定项目的业务需求、范围、假设和风险。这是需求管理的一个重要部分，因为结果会影响对项目目标的根本理解。未能明确定义业务需求可能会导致灾难性的后果，例如代价高昂的错误或系统故障
需求获取对产品团队的重要性
需求获取对于产品团队来说非常重要，因为它是确定产品需求的主要方式。获取过程可以从关键利益相关者那里挖掘需求见解。通过熟练地向主题专家提出正确的问题、进行深入对话并记录调查结果，业务分析师可以发现推动项目的真正业务需求。
如果没有正确识别业务需求和要求，开发成本将因返工而超出预算，用户/客户将无法获得他们想要的东西，项目也将失败。
需求获取流程
效的获取流程对于产品团队实现以下好处至关重要：
需求获取过程主要包括五个步骤：
1. 收集要求
您可能会想，“需求引出与需求收集有何不同？”尤其是当这两个术语经常互换使用时。这是一个好问题，随意互换它们是可以接受的。但是，在讨论需求引出过程的细节时，收集需求和需求引出之间存在细微的差异，值得指出。
根据定义，“收集”是从分散的来源收集信息的行为，而“引出”是从来源中提取信息的行为。这两种行为对于需求引出的整个过程都至关重要，需要专业知识才能正确执行。
为需求引出做准备的一种有效方法是让业务分析师收集所有可用的需求并对其进行研究以获得见解。需求收集的一些技术包括：
需求收集的结果可以帮助确定关键利益相关者，并告知哪些需求引出技术最适合该项目。然后，业务分析师就可以开始提取有用的经验来填补缺失的需求。因此，需求收集是需求获取过程中完美的第一步。
2. 确定关键利益相关者
如前所述，需求收集可以提供有关相关利益相关者的见解。重要的是要提前确定合适的人选，以便每个人都能在同一页面上开始。这样做可以避免以后填写缺失的需求，而这可能会改变项目的进程。
3. 从关键利益相关者那里获取需求
在此过程的这一部分，业务分析师需要确定哪种需求获取技术将根据手头的项目和适当的利益相关者提供最佳结果。
需求获取技术多种多样，以下是一些最流行的方法。
头脑风暴 –
用例：当前解决方案可能不够创新，无法满足项目目标。
旨在：发现新的创新想法和解决方案。
如何：召集主要利益相关者，就创新想法和解决方案进行公开对话。作为主持人，业务分析师确保对话不偏离主题，并记录讨论的想法。
焦点小组 –
用例：业务分析师需要有关项目特定方面的更多信息。时间紧迫。
旨在：帮助利益相关者更坦诚并阐明解决方案。一次获取大量信息。
如何：召集利益相关者群体的代表。主持人提出问题，让团队成员讨论特定的兴趣领域，并记录讨论的想法。
访谈 –
用例：从特定主题专家 (SME) 获得深入的观点。
旨在：获得利益相关者对给定解决方案的业务需求或可行性的一对一见解。
如何：创建问题，让 SME 能够公开讨论当前的问题。问题可以提前分享，也可以以对话的形式进行。面试官应该做笔记并与 SME 分享，以确保他或她正确理解了 SME 的观点。
观察 –
用例：当开发项目是当前工作流程的增强时。
旨在：提供利益相关者如何执行特定流程的直接视图。
如何：观察可以被动进行 – 主持人在不打断的情况下观察利益相关者的工作 – 或主动进行 – 主持人在工作进行时询问有关工作的问题。在这两种情况下，主持人都应该做笔记并从利益相关者那里获得对收集到的信息的反馈。
原型设计 –
用例：当利益相关者不理解书面技术要求并且会从查看产品版本中受益时。
旨在：通过向非技术利益相关者展示他们可以实际交互的示例来收集他们的反馈。
如何：首先，原型设计可以通过情节提要、交互式屏幕、虚拟模型、导航流程等方式执行。具体方法取决于项目，但通常是一个基于输入进行改进的迭代过程。随着更多需求的出现，将创建更详细的原型以确保它们符合记录的期望。
需求研讨会 –
用例：时间紧迫，业务需求不明确时。
旨在：在结构化的、基于时间的环境中将利益相关者聚集在一起，以引出、改进和编辑需求。利益相关者可以讨论并立即提供已确定的业务需求的意见。
如何：为研讨会设定特定的时间范围和议程。在时间表中包括头脑风暴、焦点小组和原型设计（如果适用）机会。使用这些来指导讨论和记录输入。
调查 –
用例：当业务分析师需要来自大量参与者的数据时。
旨在：从大量客户或最终用户那里获得客观反馈。
如何：根据所需标准明智地选择参与者。创建清晰的问题，不要引导受访者。问题可以有许多有限的选择，也可以是开放式的——为了获得最佳结果，请考虑问题的目标以及受访者的数量，以确定进行正确分析的最佳结构。
通常情况下，可以采用各种需求引出方法来挖掘项目的业务需求。例如，业务分析师可以在焦点小组、头脑风暴会议或观察期间提出具体的需求问题。业务分析师还可以在需求研讨会之前进行调查，或创建在观察期间使用的原型。了解针对给定项目使用哪些引出技术需要经验。
4. 记录需求
需求获取过程的下一步是记录迄今为止获取的需求。记录需求的格式多种多样：自制产品需求文档 (PRD)、政府规定的系统需求规范、需求管理工具（如 Jama Connect）、电子表格等。记录需求的最佳工具取决于项目。
如果项目有许多利益相关者、复杂的开发、合规性或功能安全标准，则最好选择需求管理工具（如 Jama Connect）。这些工具专为减轻与复杂系统和法规遵从性相关的风险而设计。评估需求和研究功能将有助于确定项目的最佳选择
5. 确认结果
一旦业务分析师记录了需求，就该确保它们被正确记录了。需求将发送给所有利益相关者进行审查，以便对正在开发的内容有一个集体的理解。利益相关者可能会做出改进。这一步也可能会引出进一步的需求，这将需要在批准之前进行修订。
业务分析师在项目开始时进行需求引出过程，并且该过程在整个开发过程中持续进行。这是因为变化总是在发生，不可能知道所有要问的问题或提前得到所有正确的答案。
成功需求引出的挑战
引出过程看似简单：询问利益相关者他们想要什么。然而，这是一项更为严格的工作。以下是需求引出过程中最常见的一些挑战。
找到合适的利益相关者 – 确定正确的主题专家并不总是那么容易。寻找“隐藏的”利益相关者，他们可以成为极好的知识来源。例子包括面向客户的人员，如销售/支持代表和维护技术人员。
发现最好的见解 – 不幸的是，利益相关者并不总是知道他们想要什么。在需求引出的实践中，可以同时使用多种引出方法来识别业务需求和最佳需求列表。专业知识在于实现最佳技术组合，以使该开发项目取得成功。
记录需求 – 使用错误的文档工具进行工作可能会造成不利影响。从审查和批准到管理变更，所有事情都可能出现问题。电子表格或自制的 PRD 可能适用于规模较小、不受监管的项目。另一方面，复杂产品或受监管行业中的产品则可从需求管理软件中受益匪浅，该软件可通过实时可追溯性和合规性管理等功能简化需求获取和整体流程。
规划变更 – 优先级发生变化，问题出现 – 最好提前规划变更。确保有一个流程，留出时间解决问题、记录变更、添加新需求并进行额外审核。
同样，在需求较少的项目中，搜索电子表格或 PDR 来管理变更并不那么费力。但是，这种手动变更管理仍会占用大量工作时间，并使项目偏离计划和预算。然而，对于复杂且受监管的产品，浪费时间和金钱的可能性要大得多。在这些情况下，像 Jama Connect 这样的工具可以在变化面前节省宝贵的时间和预算。拥有合适的工具至关重要。
简化需求获取流程
对于业务分析师来说，需求获取是一门艺术和科学的结合。他们需要熟练地知道要问哪些问题以及如何提出这些问题。此外，业务分析师必须能够在获取流程的所有阶段与关键利益相关者清晰地沟通和协作。
从事复杂或高度监管的项目的业务分析师不能依赖自己开发的 PRD 或电子表格来记录需求。他们工作的复杂程度要求他们拥有最好的需求获取工具。
Jama Connect 是一种需求管理工具，可以改变业务分析师对复杂项目执行需求获取的方式。了解 Jama 如何简化需求获取和管理。
