7 需求获取

7.1需求获取技巧

软件项目中的需求获取技巧很多。事实上，项目团队不可能只采用一种需求获取技巧。现实中总有很多类型的信息需要去发现，但不同的项目干系人表述信息的方式不尽相同。
获取技巧包括引导活动（期间与干系人互动以获取需求）和独立活动（期间独立工作以发现信息）。
引导活动主要聚焦于发现业务和用户需求。由于用户需求包含用户需要用系统完成的任务，因此很有必要与用户直接合作。而为了获取业务需求，你要与诸如项目发起方等干系人协同工作。
独立获取技巧是对用户提交的需求进行补充，并揭示出最终用户都没有注意到的必要功能。
大多数项目都会综合使用引导和独立获取这两种活动。它们分别为需求提供不同的探索方式，甚至可能揭示出完全不同的需求。下面描述几种常见的需求获取技巧。

访谈

要想找出软件系统用户需要，最常见的方法是对他进行提问。对于商业产品和信息系统而言，访谈是一种传统的需求输入来源，贯穿于所有软件开发方法。大多数业务分析师都会引导一些个人或者小团体形式的访谈，以这种方式来获取项目的需求。敏捷项目会广泛使用访谈机制，让用户直接参与进来。相比需求工作坊这样的大型需求调研活动，访谈更容易安排和引导。
如果你对某个应用领域不太了解，专家访谈可以迅速提升自己。可以通过这种方式来准备用于其他访谈或工作坊的需求草案和模型。如果能与受访者建立起融洽的关系，采用一对一或者小范围讨论而不是更大型的工作坊形式，会使他们感觉更安全，更有利于他们分享想法。相比于大团队设置，一对一或者小型访谈更能让用户主动参与项目或检查现有需求。
下面是针对访谈的一些建议：

• 建立融洽关系
• 不脱离范围
• 提前准备好问题和稻草人（某种假设）模型
• 提出看法
• 主动倾听

工作坊

工作坊能鼓励干系人在定义需求时精诚合作。工作坊也是一种引导会，成员包括众多干系人和正式角色，例如引导师和记录员。工作坊通常包括各种类型的干系人，比如用户、开发人员、测试人员。工作坊的目的就是要从众多的干系人中兼容并蓄，获取需求。相比和个体逐一对话，团队工作对于解决分歧更有效。同样，如果由于时间条件的限制需要快速获取需求，工作坊也能发挥作用。
业务分析师经常会引导需求获取工作坊。如果团队准备用新方法进行需求获取，可以考虑设置外围引导师或者第二位业务分析师来引导工作坊的开始部分。这样，业务分析师才能全身心投入到讨论之中。如果只有一位分析师，同时还要作为引导师，那么他在作为引导师讲话以及在参加讨论是需要精力特别集中。可以让记录员帮助记下讨论中的要点问题。同时引导、记录和参与并将这三项工作都做好，实在是太有挑战性了。
工作坊可能是资源密集型的，有时要求大量参会者一次性抽出几天时间。要想不浪费时间，就必须仔细规划会议，提前准备好材料。下面是进行高效获取工作坊所需要的一些技巧，其中很多技巧也适用于访谈。

• 建立和执行基本规则
• 为所有团队成员设定角色
• 准备会议议程
• 坚守范围
• 将条目放入“停车场”供日后考虑
• 时间盒式的讨论
• 保持团队的小规模但还要吸纳正确的干系人
• 使每个人都保持专注

焦点小组

焦点小组就是一组用户代表，他们会参加有人引导的需求获取活动，对产品的功能和质量需求提出建议和看法。焦点小组会议必须参与互动，让所有用户都有机会表达自己的诉求。焦点小组有助于探知用户的态度、感觉、偏好和需要。
很多时候，都会有大量不同类型的用户供你筛选，因此要仔细选择焦点小组成员。这些成员用过产品的以前版本或者用过与你现在开发产品类似的产品。要么选择同样类型的一群客户（针对不同用户类组织多个焦点小组），要么选择能代表所有用户群的一组人，使其有广泛的代表性。
焦点小组必须有人引导。你要使他们聚焦主题，但又不能影响他们表达观点。你可能要对会议进行记录，以便回去仔细听一听大家的观点。别指望从焦点小组中获得大量分析，你只会得到很多主观反馈，但随着需求的开发，你可以对这些反馈进行更深入的评估和排序。前面提到的工作坊技巧同样也适用于焦点小组的需求获取会议。焦点小组的参与者通常没有决策权。

观察

如果让用户描述他们的工作方式，他们表达起来可能很吃力，比如细节会遗漏或者不准确。通常这是因为任务复杂，他们很难记得住每一项细节。还有一种情况就是用户对所执行的任务太熟悉了，反而无法将其所做的所有任务都清晰表达出来。他们的工作已经形成惯性，甚至不用思考。
观察人是很耗时的，因此不适合所有用户或任务。为了不干扰用户日常工作安排，要将每次观察活动时间限制在两小时以内。选择重要或高风险任务以及若干个用户类别来观察。如果在敏捷项目中使用观察技巧，就只要求用户演示与眼前下一个迭代相关的具体任务。

问卷调查

问卷调查是一种针对大群体用户进行调研并了解其需要的方式。这种方式花费不高，是从大规模用户群获取信息的理想选择，并且很容易进行跨区域管理。问卷调查的分析结果可以作为一种输入，用于其他获取技巧。
对于问卷调查来说，最大挑战就是问题设计。下面是几个重要的技巧：

• 提供的答案选项要涵盖所有可能的反馈。
• 选择答案既要互斥，又要穷尽。
• 列出问题不能暗示有正确答案。
• 如果使用比例，在整个问卷调查中保持其一致性。
• 如果想要将问卷调查的结果用于统计分析，则使用封闭式问题，要有两个或以上的具体答案。
• 在问卷调查的设计和管理方面，可以咨询专家意见，保证你针对正确的人群提出正确的问题。
• 在发放问卷调查之前，一定要进行测试。
• 对于人们不愿回答的问题，不要穷追不舍。

系统接口分析

接口分析是一个独立的需求获取技巧，必须检查哪些系统与你的系统相关联。系统接口分析揭示的功能需求涉及系统之间的数据和服务交换。关联图和生态系统图这两种方式通俗易懂，我们可以用来发现接口并进行深入研究。

用户界面分析

用户界面（UI）分析也是一种独立的需求获取技巧，用于研究现有系统，揭示用户和功能需求。我们最好与现有系统直接交互，但是如有必要，可以使用屏幕截图。用户手册通常就包含屏幕截屏，其出发点是不错的。如果没有现有系统，可以参考类似产品的用户界面。

文档分析

文档分析是指检查现有文档，从中发现潜在的软件需求。最有用的文档包括需求规范说明、业务过程、课程学习总结以及现有或者类似程序的用户手册。文档能够描述必须遵循的公司或者工业标准，或者描述产品必须符合的制度。
文档分析这种方式的风险在于手头上可用的文件跟不上时代的潮流。需求可能已经有变化，而规范说明却没有更新，或者记录的功能在新系统中已经用不着了。

7.2制定项目需求获取计划

在项目早期，业务分析师就应当针对需求获取来规划实施方法。计划主要包括如下要点：

• 目标
• 策略和计划采用的技术
• 进度和资源估算
• 独立获取活动所需要的文件和系统
• 获取工作后的预期成果
• 获取风险

7.3准备需求获取

引导性获取会议要求有准备活动，这样才能最合理地利用每个人的时间。参与会议的人越多，准备活动就越重要。

在准备会议时，要确定会议的范围、协商会议日程、准备问题并起草会议上可能用到的材料。下面是一些技巧：

• 准备会议范围和日程
• 准备资源
• 了解干系人
• 准备问题
• 准备稻草人模型

7.4执行获取活动

下面是几点提示：

• 教育干系人
• 做好笔记
• 全面利用空间

7.5需求获取后的跟进

整理和分享会议笔记

记录提出的问题

7.6对客户的输入进行分类

不要指望客户能够给出一份简洁、完整并组织良好的需求清单。业务分析师必须对他们听到的各类需求信息单元进行归类整理，进行准确的记录和利用。

有时还剩一些信息无法准确归入上述9个类别中：

• 与软件开发无关的项目需求，例如需要培训用户使用新系统。项目约束，例如成本或进度的限制。
• 假设或依赖项。
• 历史、上下文设置或者描述特征方面的其他信息。
• 不能增加价值的冗余信息。

7.7如何知道已经完成

完成需求获取时，是没有任何信号的。实际上，永远做不到彻底完工，特别是在敏捷项目中有意增量实现一个系统时。出现以下情况，就说明已完工。

• 用户再也想不出更多用例或用户故事。
• 用户提出了新的使用场景，但是这些方案并不能引出新的功能需求。
• 用户重复以前讨论中已经提到的问题。
• 建议的新特性、用户需求或者功能需求都在范围之外。
• 提议的新需求优先级都很低。
• 用户提议的性能可能纳入“产品生命周期中的某个时间”，而不是“我们此刻所讨论的具体产品。”
• 检查某一领域需求的开发人员和测试人员提出的问题越来越少。

7.8需求获取的注意事项

需求获取讨论技巧是随经验而产生的，并且要经过访谈、小组引导、冲突解决和类似活动来练习。下面是一些注意事项：

• 平衡干系人出席的人数
• 定义范围要适当
• 避免需求对抗设计之争
• 合理调查

7.9假设的需求和隐晦的需求

你永远不可能把系统需求百分百地记录下来。但未明确指定的需求又会成为一种风险：项目交付的解决方案与干系人的期望值相去甚远。期望得不到满足有两个可能的原因：假设的需求和隐晦的需求。
假设的需求：人们期望但又没有明确表述出来的需求。
隐晦的需求：表述不明确，开发人员又不知道的需求。

7.10找出遗漏的需求

需求遗漏是一种常见的需求缺陷。由于遗漏的需求是不可见的，所以我们很难发现。下面技巧可以帮助发现没有揭示出来的需求：

• 将概要需求进行详细分解，揭示真正的需要。
• 保证所有用户类别都提供了输入。
• 追溯系统需求、用户需求、事件相应列表和业务规则至其相应的功能需求，确保所有功能需求都提炼出来。
• 检查边界值以免遗漏需求。
• 表达需求信息的方式不止一种。
• 用复杂的布尔逻辑来描述需求集合通常是不完整的。
• 为项目创建一个常用功能领域检查表，包括错误登录、备份和恢复、访问安全、报告、打印、预览能力和配置用户喜好。将这个检查表定期与已经制定好的功能进行比较，找出差距。
• 数据模型可以揭示遗漏的功能。