第七章 需求工程之获取需求

获取需求

• 需求开发的核心是需求获取，是为软件系统确定各类干系人的需要和约束的过程
• 需求获取不等同于“收集需求”，也不是简单地将用户所说的全部记录下来。
• 获取是一个综合性协作和分析的过程，其活动包括收集、发现、提炼和定义需求
• 获取的目的是为了发现业务需求、用户需求、功能需求和非功能需求及其他类型信息
• 需求获取可能是软件开发各个方面最具有挑战性、最关键、最容易出错和最需要密集沟通的。
• 让用户专心参与获取过程，能够为项目赢得支持和认同。
• 试着理解用户在陈述需求时的思维过程
• 通过研究用户执行任务所做决策的过程，提炼出潜在的逻辑。
• 业务分析师须营造一种环境，以便对正在拟定的产品进行彻底、全面的探索。
• 不能强迫用户理解技术术语
• 不能想当然地认为所有参与方对产品定义的理解都是一致的
• 客户必须明白，即对可能的功能进行讨论并不代表必须将其纳入产品之中。
• 需求开发的目的是使各类项目干系人对需求达成共识。
• 参与需求获取的人避免在理解问题本质之前就开始设计系统
• 我们要强调用户任务而非用户界面
• 关注真正的用户需求而非口头诉求
  

需求获取技巧

• 引导活动
  • 聚焦于发现业务和用户需求
  • 很有必要与用户直接合作
  • 为了获取业务需求，要与诸如项目发起人等干系人协同工作。
• 独立互动
  • 独立获取技巧是对用户提交的需求进行补充
  • 揭示最终用户都没有注意到的必要功能。

访谈

• 访谈是一种系统的需求输入来源
• 敏捷项目会广泛使用访谈机制，让用户直接参与进来
• 专家访谈可以迅速提升自己
• 一对一或小型访谈更能让用户主动参与项目或检查现有需求

建立融洽的关系

不脱离范围

提前准备好问题和稻草人模型（某种假设）

提出看法

• 当用户不能真正表达需求的时候，你可以观察他们的工作，并提出一些建设性的方案以提升他们的工作效率。
• 业务分析师要摆脱思想的羁绊，乙方一叶障目。

主动倾听

工作坊

• 工作坊能鼓励干系人在定义需求时精诚合作
• 工作坊是一种结构性的会议，会议中有经过仔细甄选的干系人群体和内容专家，大家协同定义、创造、精炼并对代表用户需求的交付达成最终意见。
• 引导式带领人们朝着一致目标努力而奋斗的艺术，其引导方式注重鼓励所有人参与、自主和生产效率

建立和执行基本规则

• 一次只针对一个话题
• 每个人都发挥自己的作用

为所有团队成员设定角色

引导式必须要保证参加工作坊的人能完成下列任务

• 做记录
• 守时
• 范围管理
• 基本规则管理
• 保证每个人能听得清楚
• 记录员记录当时的情况
• 另外一个看着钟表。

准备会议日程

• 每个工作坊都需要清晰计划
• 提前制定计划和工作坊的议程，然后传达给参与者，让他们指导会议的目标和预期的结果并做相应的准备。

坚守范围

找出遗漏的需求

需求遗漏是一种常见的需求缺陷，由于遗漏的需求是不可见的，所以很难发现。

• 将概要需求详细分解，揭示出真正的需要。模糊的概要需求会耗费读者大量的精力去揣摩，使需求提出人的想法与开发人员开发的内容出现偏差
• 保证所有用户类别都提供了输入。
• 追溯系统需求、用户需求、事件响应列表和业务规则至其相应的功能需求，确保全部功能需求都已经提炼出来。
• 检查边界值以免遗漏需求。如一个需求说小于100元运费为5元，大于100元运费为价格的6%，但是等于100元的需求没有提出。
• 表达需求信息的方式不止一种，如果某种模型中两个方框之间应有一个箭头，则这个遗漏的箭头就是遗漏的需求。
• 用复杂的布尔逻辑来描述需求通常是不完整的。在表达复杂逻辑时，可以使用决策表或决策树涵盖所有可能的条件。
• 为项目创建一个常用功能领域检查表，包括错误登录、备份和恢复、访问安全、报告、打印、预览能力和配置用户喜好。
• 数据模型可以揭示遗漏的功能。系统所控制的所有数据实体必须要有对应的功能性，CRUD。