需求决定了软件开发的方向，回答的是“做什么”的问题，因此其重要性不言而喻。
需求探索的过程基本上可以分三步走：调研 - 分析 - 验证。然而在实际过程中，获取好需求通常并非是一个直线过程，在前往终点的道路上来回折返，曲线前进是常态。
在需求调研时，调研员需要谨记：
- 问答题而非选择题，同时要注意问题的开放性，如让受访者谈谈自己面临的问题。
- 记录但不要轻易相信受访者的言论。
- 警惕受访者主动提供的指导意见和解决方案。
- 观察，包括：行为、言论、环境、人际关系等等。
- 了解相关的背景资料。
以上各条期望表达的意思归根结底一句话：解决用户真正的问题，而不是他们认为的“问题”。如果想要提供让用户拍案叫绝的东西，就不能指望用户能明确告诉你，尤其是在市面上缺乏可参照物的前提之下。
探究根本原因的一种常用方法就是丰田的5个WHY，它可以从3个层面来实施：
- 为什么会发生？从“制造”的角度。
- 为什么没有发现？从“检验”的角度。
- 为什么没有从系统上预防事故？从“体系”或“流程”的角度。
结构化的思维有助于提高分析的效率，用例分析是在软件开发中常用的一种方法。
关于用例的常见误解：
- 用例就是UML中的用例图。
- 用例图只是表达了actor和用例之间的关系，但并没有体现用例中关于用户和系统之间行为交互的部分。
- 用例和用户故事是一码事。
- 这两者提出的时间先后不一，粒度不一，不可能相同。
- 用例和用户故事是非此即彼的关系。
- 用例和用户故事并不矛盾，也不是相互替代的关系。通常来讲，用例的粒度更大，在需求分析中用的偏多；用户故事的粒度要小很多，多用在设计实现之中。一种用法就是将一个大的用例分拆成多个用户故事。
很明显，用例是本文的主角。简单的讲，用例就是<谁>与系统<交互>实现了<业务目标>。对应这个内容，在调研过程中，就要注意收集：
- 用户角色
- 现有业务及其对应的流程
再次强调，调研过程收集的这些内容是为了更好的分析和了解客户，而并非最终系统就一定按此实现。但在结构上，可以将用例和业务对应。这意味着，用例包含：
- 角色
- 流程，流程中每一步可能对应不同角色。
Alistair Cockburn在《编写有效用例》中提供了一个参考的用例模板：
- 用例名称
- 角色，对应真正触发用例的那个角色
- 描述
- 前置条件，即前提条件，如已登录且有权限
- 事件流
- 基本流，正常流程
- 备选流，异常流程，如转账过程中失败转到此处
- 后置条件，即用例结束之后处于什么状态
- 扩展点
- 业务规则，如计算公式，报表格式等等
- 特别要求，非功能性需求体现在此处
在这里特别强调一下事件流的书写：用户和系统的对话。如：
- 用户给系统提供xxx
- 系统给用户返回xxx
- 用户基于上一步的内容再给系统提供xxx
- ……
在这里特别注意不要内嵌UI实现的细节，因为在此步关心的仍然还是用户和系统之间的交互，至于如何实现交互，并不是重点。罗列在此反而会分散注意力。
因此，一个用例文档必然包括：
- 业务角色表
- 业务流程表，一个流程对应一个用例
- 各个用例详细内容
需求的验证需要注意两方面：功能性需求和非功能性需求。功能性需求决定了方向是否正确，非功能性需求则决定用户体验是否上乘。
对于需求的验证，必须：
- 将需求文档转化成纸上UI原型，方便关键用户体验
- 将验收标准量化
起目的是为了缩短反馈链条，同时迫使用户思考如何确认完工。这两点对于需求的质量至关重要。
最后，推荐温伯格的《探索需求》，它主要回答的是“什么是用户真正想要的？”，而这恰恰是高质量需求的起点。