如果需求收集只是简单地询问你的客户和利益相关者希望你的系统能做什么，那该多好。不幸的是，事情从来都不是那么简单的。
在大多数情况下，需求提出者（如客户、用户等）可能不完全了解在开发特定产品时所有的可能选择。因为他们深陷于当前的工作状态或环境，他们的视野可能受到限制，难以脱离他们现在的方式，想象出与当前状态完全不同的解决方案或产品特性。
此外，并不存在一劳永逸的需求收集技术。我们不可能使用万能需求收集技术可以保证所收集的需求完整且经得起验证。
因此，采取多角度、多种方法的策略进行需求收集是更有效的做法。这意味着根据需求收集过程的不同阶段和环境，灵活地使用不同的技术和方法。这些可能包括访谈、问卷调查、用户观察、文档分析等等，从而使得收集到的需求更为全面和准确。
本文将根据需求收集技术一般应用顺序，为大家介绍11种有效的需求收集技术。在实践中，并非所有这些技术都必须应用，可根据特定需求选择合适的技术组合，从而增加需求覆盖率，减少在软件开发过程中及其后期出现的需求相关问题。
1: 采访
采访（面对面或远程的对话形式）是开始收集需求的一个非常有效的方法。通过采访，我们可以收集到许多重要的背景信息，包括商业需求、客户和用户遇到的问题，以及支持人员和其他相关利益相关者的关注点。这种方法不仅可以在需求收集的初期阶段使用，而且在需求收集的后期阶段也可以通过采访来收集更详细的信息。这样，我们就能更深入地理解各方的需求和期望，从而能更有效地制定和优化产品的设计和功能。
在进行需求收集的采访时，需要确保采访的对象覆盖了系统利益相关者的多样性和代表性，包括各种类型的客户和用户。这样做的目的是要确保从各方的角度理解竞争需求，以避免系统需求过度偏向某一特定群体。
采访时应尽量提问开放式问题，这些问题不能仅用“是”或“否”回答，需要被采访者详细阐述他们的想法和理由。这样的问题有助于提取更深层次的信息，并为评估和验证需求提供必要的背景。
此外，在采访过程中，应提出大量后续问题以深入了解详细信息或获取整体情况的概述。这样的问题有助于更好地理解被采访者的观点。对于那些倾向于讨论具体情况和例外情况的人，你可能需要将问题的焦点提升到更高的层面，以获取整体的情况概述。而对于那些只谈论大环境但不涉及具体细节的人，你需要进一步深入询问，以获取他们看法的具体内容。总的来说，这是为了在采访过程中获取尽可能全面和深入的信息。
2: 问卷或调查
组织个人访谈时我们会面临一系列问题，比如：等待排期要花费很多时间；获取的需求太表面；并不是每个人都善于回答所跟进的问题。
问卷调查或调研可以作为一种高效的替代方案，可以同时跟进多个利益相关者。
认真构思问卷，要包含探索性问题，这样可以有效揭示出利益相关者自己都意识不到的潜在需求，这些需求对于项目成功极为关键。
3: 观察用户
理解用户真正需求的最好方式之一是观察他们的日常行为。
观察用户可以主动进行，即在观察用户行为的同时，向他们提问以理解他们当前的工作流程；也可以被动进行，如收集用户对设计原型的反馈（参见技巧#11）。
在进行用户观察时，要对他们的行为和活动进行详细记录。注意哪些问题在困扰客户，要关注用户频繁遇到的难题。
通过实地观察用户在真实环境中如何执行任务，可以深入理解他们所面临的挑战和需要改进的地方。只有抓住问题所在，我们才会知道如何改进用户的工作流程，继而提高他们的生产力和效率。
4: 文档分析
文档分析经常被忽视，却能帮助我们高效收集需求。
深入分析现行系统的文档有助于我们进行当前的流程分析和差距分析。流程分析可帮助我们找到优化用户流程的可能路径，而差距分析可以帮助我们明确通过采访、问卷调查、用户观察所收集到的业务需求有哪些尚未得到满足。
在分析系统需求文档的同时，也应审查其他系统级别的文档，如用户手册和问题报告。
规范说明和设计文档常常隐藏着关于当前系统为什么会如此运行的重要信息。通过分析这些文档，我们可以进一步提出相关问题，同时还能评估需求集是否完整。
5：界面分析
界面分析是为了确保需求的完整性和系统的可用性，无论这些界面是人的还是机器的。
对于软件产品，其界面可能包括以下几种：
- 终端用户：即使用该软件产品的人。
- 与软件交互的系统组件：这些可以是传感器或其他外围设备。
- 与软件交互的外部系统：比如其他软件或网络服务。
进行彻底的界面分析，即深入理解系统的交互环境，通常可以揭示出一些对用户来说不那么明显，但对于系统功能实现非常重要的需求。
6: 头脑风暴
头脑风暴可以激发创新思维还可以收集需求。它可以作为研讨会的一个活动或单独组织。
在头脑风暴环节，团队成员分别探讨系统的不同部分，探索各种假设场景和拓展思路，是突破传统思维和现有框架的好机会。
过程中，可用于头脑风暴会议的工具包括白板、思维导图软件以及用户移情图。
7: 研讨会
在收集各种利益相关者的需求时，可能会出现不同的观点，甚至产生冲突。在开始实施项目之前，你需要解决这些冲突。
需求研讨会是一种解决冲突的有效方式。你可以在定义和组织了一系列的候选需求后，召集所有的利益相关者，一起讨论这些需求。在这个过程中，要求大家公平地听取彼此的观点，给每个人足够的机会来解释他们的立场，同时也收集更多的详细信息。
这个过程的目的是解决分歧和冲突，达成共识，并验证你的需求。这些步骤对于确保你的系统最好地满足所有用户和利益相关者的需求非常重要，而不仅仅是那些最善于发言的群体。
8: 角色扮演
角色扮演有助于我们满足不同用户类型的需求，特别适用于那些需要满足多种用户需求的系统，如企业资源计划（ERP）系统。
在角色扮演活动中，参与者扮演不同用户类型，模拟他们在实际使用系统时的行为和互动，可从多个角度审视系统需求，引发讨论、促进新想法的提出。
角色扮演本质上是头脑风暴技巧的扩展，有助于我们深入理解系统各个组成部分在完成整体流程时是如何协作的。
9:用例和场景
当你有了初步的高级功能需求后，就可以开始探索各种可能的用例和场景了。
用例是系统需要实现的具体的、单一的业务目标，以及在各种不同情况下一个特定的功能将如何被使用。它们描述了哪些外部实体会对系统进行操作，以及他们如何与系统交互以实现业务目标。用例通常以清单的形式列出一个过程中需要执行的各个步骤。
场景，也被称为用户故事，也描述了系统如何执行过程以达成业务目标。但它们的形式通常是叙述，而不是像用例那样的步骤列表。场景就像是以用户为主角的短篇故事，描述了用户需要执行的任务，用户看到的信息，以及用户如何与系统交互。
用例和场景可以用于验证系统在各种不同情况下是否能满足特性和功能需求。他们还可以帮助你发现需要考虑的特例和边界情况。
10: 焦点小组
焦点小组（或用户小组）是一个由客户或用户代表组成的小组，他们与你一起：
- 对你的产品提供反馈
- 表达他们的需求
- 帮助指导你的软件开发
焦点小组可以用来：收集开发需求的信息，或获取针对之前提出的需求的反馈。
焦点小组与头脑风暴有所不同，头脑风暴通常涉及内部利益相关者，而焦点小组通常涉及外部利益相关者。
很多系统工程师和业务分析师都怀疑使用焦点小组的方法来收集需求的效果。因为这样的会议可能会被观点狭隘的人主导，在需求和功能方面的强烈分歧也可能导致会议收效甚微。在一些情况下，焦点小组可能收效很好，例如，评估设计原型（参见技术#11）可以帮助验证和最终确定需求。
11: 原型制作
在展示设计方案后，系统工程师和用户组之间的对话可能如下：：
系统工程师：“对于这个设计，您有什么看法？”
用户组：“我们并不喜欢。”
系统工程师：“我明白，那您想要什么样的设计呢？”
用户组：“其实我们也不确定……但是肯定不是现在这个样子。”
最终的用户和其他利益相关者并不清楚他们真正需要什么，也无法确切知道所有可行的方案，但是在成果展示后，他们又通常可以明确指出喜欢和不喜欢的地方。
原型制作就变得极为重要。通过构建并展示原型设计，用户可以直接体验潜在的解决方案。如今，通过使用快速原型制作工具，开发人员能够迅速组合出交互式模型并让用户试用。
一旦构建出初始的原型，开发过程将变为迭代式：
- 用户试用原型
- 收集用户的反馈
- 对原型进行修改
现代原型制作工具的设计有助于开发人员快速进行修改，我们利用用户反馈就能够快速地找到满足用户需求的方案。一旦功能原型中的某些功能被用户接受并确认，对这些已接受的功能进行逆向工程分析就会相对简单。
