优秀实践之需求获取活动

1、定义产品愿景和项目范围

愿景和范围文档包含产品的业务需求。愿景描述可以是所有干系人对产品的产出有一致的理解。范围界定了发布或者迭代中哪些功能应该或不应该出现。愿景与范围提供了一种参考，方便对大家所提议的需求进行评估。愿景在整个项目过程中时相对稳定的，每个计划的发布或迭代都有自己的范围。

2、识别用户类型及其特征

为了避免遗漏任何用户团体的需求，我们要为产品识别出不同的用户组。在使用频率、所用特性、权限级别以及经验方面，这些组别可能不同。记下他们的工作任务、态度、位置或个性，这些都可能影响产品设计。建立用户角色---也就是一种虚拟人物---来代表特定用户类型。

3、为每类用户选出用户代表

为每类用户找出一个能精确传达用户心声的个人---产品用户代表。他提出用户组的需求，并代表用户组做决策。在内部信息系统的开发中，这是最容易做到的，因为你的用户就是你的同事。对于商业产品的开发，则要按照你与大客户的现有关系或是beta测试网站来锁定合适的产品用户代表。

4、安排由典型用户组成的焦点小组

将以前产品或类似产品的用户代表组成小组。收集他们期望有的产品功能及质量。焦点小组对商业产品尤其重要，因为你可能要面对数量巨大切形形色色的客户。与产品用户代表不同，焦点小组通常没有决策权。

5、与用户代表协同发现用户需求

要与用户代表共同探讨他们需要软件完成什么任务以及他们希望获得哪些价值。用户需求的表达方式包括用例、用户故事或场景。讨论内容还包括用户与能使其完成各项任务的系统之间的互动关系。

6、识别系统事件和反应

列出系统可能经历的外部事件及其对每个事件可能做出的反应。外部事件可以分为三类。信号事件是指控制信号或从外部硬件接收到的数据。时间或时间相关事件会触发一个响应，例如系统每天晚上导出外部数据。业务事件在业务应用中触发用例。

7、举办获取访谈

访谈可以是一对一的，也可以是和一个小组干系人。这是一个获取需求 的高效方式，可以避免占用干系人过多时间。因为你只跟每个人讨论对他们很重要的需求。面谈十分有用，它可以分别启发出每个人的需求并且为讨论会做准备。在讨论会上大家聚在一起解决冲突。

8、举办并引导需求获取讨论会

通过需求获取讨论会，分析师和客户能够精诚合作，高效的探索用户需求和起草需求文档。这样的讨论会有时称作“联合应用设计”会议。

9、观察用户如何工作

观察用户如何完成其任务目标，能够了解到一个新应用在这些用户中的潜在用途。简易的流程图可以描述出每个步骤以及所涉及的决策，并且展示不同用户组如何交互的。如果能将业务流程图记录成文档，你就能识别出解决方案是否能够支持此流程的需求。

10、分发调查问卷

调查问卷这种方式就是调查大量用户群并判断他们有哪些需要。如果用户群体比较大，就适合使用调查问卷，特别是用户群比较分散是，效果更好。如果问题设计得好，调查问卷可以帮助你快速获得关于需求的分析结果。这样一来，获取需求的其他工作量就可以按照调查问卷结果来确定。

11、分析文档

现有的文档可以解释系统目前如何运行或人们期望它如何运行。文档中的书面信息涉及现有系统、业务流程、需求规范说明、对竞争对手的研究以及产品上架发行时的用户手册。检查并分析这些文档可以帮助你发现什么样的功能需要保留，什么功能是没有被用到，人们现在如何完成他们的工作，竞争对手提供什么功能，软件供应商如何描述产品功能。

12、检查现有系统在需求方面的问题报告

从用户那里获取问题报告和改进请求为我们提供了丰富的候选项，我们可以将这些新增需求或改进建议纳入到下一个发布或新产品中。客户支持或售后服务可以为未来开发工作挺很多有价值的需求。

13、重用现有需求

如果客户所要的功能跟现有系统已经提供的功能类似，就要看需求及客户是否能够通过变通，允许重用或者改写已有组件。例如符合组织业务规则的安全需求或者符合政府法规的可访问性需求，就经常可以重用。另一些可以重用的东西包括词汇表、数据模型、定义、干系人信息、用户类型描述以及用户角色等。