- 访谈
- 问卷或调查
- 用户观察
- 文档分析
- 界面分析
- 研讨会
- 头脑风暴
- 角色扮演
- 用例和场景
- 焦点小组
- 原型设计
- 最终用户
- 软件与之交互的系统组件（例如传感器或其他外围设备）
- 软件与之交互的外部系统
- 用户执行的任务
- 用户看到的信息
- 用户如何与系统交互
- 提供有关您产品的反馈
- 表达自己的需求
- 帮助指导您的软件开发
- 收集用于制定需求的信息，或者
- 获得旨在验证先前引发的需求的反馈
- 用户试用原型
- 用户反馈
- 修改原型
如果需求收集就像询问客户和利益相关者他们希望您的系统做什么一样简单，那就太好了。不幸的是，事情从来都不是那么简单。
在大多数情况下，利益相关者并不知道在开发特定产品时存在的所有替代方案。沉浸在现状中，他们的视野往往有限。用户很难摆脱他们目前的做事方式——想象与他们现在拥有的东西有很大不同的可能性。
此外，没有灵丹妙药。没有一种单一的需求收集技术可以帮助您得出一套完整的需求，这些需求将填补每个空白并在验证过程中经得起审查。
这就是为什么采取多方面的方法进行需求收集是个好主意。需求工程最佳实践建议使用针对流程不同阶段的各种方法。
本文介绍了 11 种有效的需求收集技术。它们将大致按照它们在需求收集过程中通常出现的顺序进行介绍。没有必要在每个项目中都使用所有这些技术，但根据具体项目的需求选择这些技术的健康组合可能会提高您的需求覆盖率，并帮助您减少软件开发期间和之后与需求相关的问题。
技巧1：访谈
访谈是开始需求获取过程的绝佳方式。它们对于收集有关业务需求、客户和用户问题以及支持人员和其他相关利益相关者的关注点的背景信息非常有用。访谈还可用于后续收集更详细的信息。
访谈应涵盖系统利益相关者的多样化和代表性横截面。您将希望包括所有客户和用户资料。这对于正确了解相互竞争的需求是必要的，这样您的系统需求就不会偏向某一群体。
进行访谈时，重要的是要提出开放式问题。开放式问题是那些不能用简单的“是”或“否”来回答的问题。它们会引出具体信息。它们要求受访者解释他们的想法并提供理由，从而为评估和验证需求提供背景。
您还需要在访谈期间提出大量后续问题。好的后续问题要么深入挖掘更多细节，要么向上拉出以概览背景。有些人会倾向于谈论具体细节和例外情况。与他们交谈时，你需要深入了解。其他人则会谈论背景，而不会深入讨论细节。与这些人交谈时，你需要深入探讨。
技巧 2：问卷或调查
个人访谈面临多项挑战。安排访谈时间可能很棘手，而且对访谈者来说也很耗时。此外，您收集到的需求可能只是触及表面；并非每位访谈者都擅长实时提出后续问题。
问卷（或调查）可以提供一种有效的替代方案。它们允许同时与多个利益相关者进行跟进。
经过深思熟虑的问卷（提出探索性问题的问卷）是了解利益相关者可能没有完全意识到但对成功设计至关重要的那些基本需求的好工具。
技巧 3：用户观察
了解用户真正需要什么的最佳方法之一是观察他们执行日常任务。
用户观察可以是被动的，也可以是主动的。主动观察（在观察用户的同时向用户提问）是了解现有流程的最佳方法。在收集用户对设计原型的反馈时，被动观察更为有效（参见技巧 11）。
观察用户时，记录发生的操作和活动。哪些已经运行良好？是什么导致用户遇到困难？注意用户必须经常克服的障碍。
通过在最终用户执行任务的真实环境中观察他们，您将真正了解他们面临的问题以及他们需要哪些改进才能表现得更好。然后，您将能够更好地指定一个成功重塑用户流程并赋予他们更高生产力和可用性的系统，而不是简单地为他们提供渐进式改进。
技术 #4：文档分析
文档分析经常被忽视，但它是另一种非常有效的需求收集技术。
查看您要替换的当前系统的文档可以帮助您执行 AS-IS 流程分析和差距分析。前者可以帮助您了解可以改进用户流程的地方。后者将帮助您确定之前通过访谈、问卷调查和用户观察发现的业务需求未得到满足的地方。
当然，如果有的话，您需要分析系统的需求文档，但您还应该查看其他系统级文档，例如用户手册和问题报告。
关于现有系统为何如此运作的信息通常隐藏在规范和设计文档中。从文档分析中获得的见解可以帮助您提出进一步的问题并评估需求集的完整性。
需求收集技术 #5：界面分析
分析系统的界面（包括人机界面）对于确保需求完整且系统可用至关重要。
软件产品的界面包括：
彻底的界面分析（真正了解系统的交互环境）通常会发现用户不易发现的需求。
技巧 #6：头脑风暴
头脑风暴可以作为研讨会的一部分进行（参见下文技巧 #7），也可以单独进行，可以大组也可以小组进行。
在头脑风暴会议中，分别考虑系统的不同部分。探索各种假设情景和空想。总体思路是打破现有惯例。考虑突破当前界限的远见卓识。
头脑风暴会议的有用工具包括白板、思维导图软件和同理心地图（后者用于探索用户需求）。
技巧 #7：研讨会
当从广泛的利益相关者那里收集需求时，您自然会听到相互矛盾的意见。但是，您需要在实施开始之前解决这些问题。
需求研讨会是解决此类冲突的好方法。
一旦您定义并组织了广泛的候选需求，就召集您的利益相关者并一起讨论这些候选需求。收集更多细节。公平地听取反对意见。给予每个人充足的机会来陈述他们立场的理由。
寻求解决分歧和冲突，达成共识并验证您的需求。这些活动对于确保您的系统能够最好地满足所有用户和利益相关者的需求（而不仅仅是最直言不讳的群体）至关重要。
技巧 #8：角色扮演
某些系统（例如 ERP 等特定类型的企业软件）必须满足各种用户类型的需求。角色扮演有助于确保满足所有用户的需求。
在角色扮演环节中，不同的人扮演不同类型的用户。让各种角色相互交流有助于从不同角度审视各个系统需求，并产生讨论和新想法。
实际上，角色扮演是一种额外的头脑风暴技巧。这是一种很好的方法，可以深入了解系统的各个部分如何运作以支持整个流程。
需求收集技巧 #9：用例和场景
一旦您有了高级功能需求，探索各种用例和场景是一个好主意。
用例是系统必须实现的具体、单独的业务目标以及将使用给定特性或功能的各种情况。它们描述了作用于系统的各种外部实体以及它们与系统进行的特定交互以实现业务目标。用例以流程期间执行的任务的分步列表表示。
场景，也称为用户故事，类似于用例，因为它们描述了系统将如何执行流程以实现业务目标。但它们的形式是叙述，而不是枚举列表。它们本质上是短篇故事，用户扮演主角。场景描述：
用例和场景可用于在各种情况下验证系统的特性和功能需求。它们还可以帮助您发现需要考虑的异常和边界情况。
需求收集技巧 #10：焦点小组
焦点小组（或用户组）是与您会面的客户或用户代表的聚会
焦点小组可以召集：
焦点小组与头脑风暴不同。头脑风暴是一个管理过程，通常涉及内部利益相关者。焦点小组通常涉及外部利益相关者。
许多系统工程师和业务分析师对使用焦点小组收集需求持怀疑态度。会议可能由议程狭窄的直言不讳的个人主导。对需求和功能的强烈分歧会使这些会议没有成效。然而，焦点小组在某些情况下非常有用。其中之一是评估设计原型（参见技巧 #11），以帮助验证和最终确定需求。
需求收集技术 #11：原型设计
系统工程师之间流传着一个老笑话，说设计演示后与用户组的讨论通常是这样的……
系统工程师：“那么，您觉得怎么样？”
用户组：“我们讨厌它。”
系统工程师：“啊……好吧，嗯……那么你想要什么？”
用户组：“嗯……我们不知道……但不是那样！”
通常，最终用户和其他利益相关者并不清楚他们真正想要什么。在大多数情况下，他们无法很好地掌握什么是可能的。但是，如果您可以给他们一些东西去尝试，他们通常可以告诉您他们喜欢什么和不喜欢什么。
这就是原型设计的用武之地。
原型设计让用户有机会尝试下一个解决方案的想法。当今的快速原型设计工具允许开发人员快速组合任意数量的交互式模型供用户尝试。
一旦构建了初始模型，该过程就是一个迭代过程：
现代原型设计工具使开发人员能够轻松地即时修改原型，因此用户可以帮助您快速发现什么能让他们满意。从该工作模型开始，对描述可接受功能的需求进行逆向工程就变得相对简单了。
自动化需求收集流程
在收集和开发需求时，拥有一个灵活、用户友好的系统来收集、组织需求并向相关利益相关者提供需求是大有裨益的。在敏捷开发中尤其如此，因为文档和电子表格可能特别麻烦。
要了解 Jama Connect 如何简化敏捷团队的需求收集和管理，请单击此处。
