第七章 需求工程之获取需求
发布时间:2023年12月29日
获取需求
- 需求开发的核心是需求获取,是为软件系统确定各类干系人的需要和约束的过程
- 需求获取不等同于“收集需求”,也不是简单地将用户所说的全部记录下来。
- 获取是一个综合性协作和分析的过程,其活动包括收集、发现、提炼和定义需求
- 获取的目的是为了发现业务需求、用户需求、功能需求和非功能需求及其他类型信息
- 需求获取可能是软件开发各个方面最具有挑战性、最关键、最容易出错和最需要密集沟通的。
- 让用户专心参与获取过程,能够为项目赢得支持和认同。
- 试着理解用户在陈述需求时的思维过程
- 通过研究用户执行任务所做决策的过程,提炼出潜在的逻辑。
- 业务分析师须营造一种环境,以便对正在拟定的产品进行彻底、全面的探索。
- 不能强迫用户理解技术术语
- 不能想当然地认为所有参与方对产品定义的理解都是一致的
- 客户必须明白,即对可能的功能进行讨论并不代表必须将其纳入产品之中。
- 需求开发的目的是使各类项目干系人对需求达成共识。
- 参与需求获取的人避免在理解问题本质之前就开始设计系统
- 我们要强调用户任务而非用户界面
- 关注真正的用户需求而非口头诉求
需求获取技巧
- 引导活动
- 聚焦于发现业务和用户需求
- 很有必要与用户直接合作
- 为了获取业务需求,要与诸如项目发起人等干系人协同工作。
- 独立互动
- 独立获取技巧是对用户提交的需求进行补充
- 揭示最终用户都没有注意到的必要功能。
访谈
- 访谈是一种系统的需求输入来源
- 敏捷项目会广泛使用访谈机制,让用户直接参与进来
- 专家访谈可以迅速提升自己
- 一对一或小型访谈更能让用户主动参与项目或检查现有需求
建立融洽的关系
不脱离范围
提前准备好问题和稻草人模型(某种假设)
提出看法
- 当用户不能真正表达需求的时候,你可以观察他们的工作,并提出一些建设性的方案以提升他们的工作效率。
- 业务分析师要摆脱思想的羁绊,乙方一叶障目。
主动倾听
工作坊
- 工作坊能鼓励干系人在定义需求时精诚合作
- 工作坊是一种结构性的会议,会议中有经过仔细甄选的干系人群体和内容专家,大家协同定义、创造、精炼并对代表用户需求的交付达成最终意见。
- 引导式带领人们朝着一致目标努力而奋斗的艺术,其引导方式注重鼓励所有人参与、自主和生产效率
建立和执行基本规则
为所有团队成员设定角色
引导式必须要保证参加工作坊的人能完成下列任务
- 做记录
- 守时
- 范围管理
- 基本规则管理
- 保证每个人能听得清楚
- 记录员记录当时的情况
- 另外一个看着钟表。
准备会议日程
- 每个工作坊都需要清晰计划
- 提前制定计划和工作坊的议程,然后传达给参与者,让他们指导会议的目标和预期的结果并做相应的准备。
坚守范围
找出遗漏的需求
需求遗漏是一种常见的需求缺陷,由于遗漏的需求是不可见的,所以很难发现。
- 将概要需求详细分解,揭示出真正的需要。模糊的概要需求会耗费读者大量的精力去揣摩,使需求提出人的想法与开发人员开发的内容出现偏差
- 保证所有用户类别都提供了输入。
- 追溯系统需求、用户需求、事件响应列表和业务规则至其相应的功能需求,确保全部功能需求都已经提炼出来。
- 检查边界值以免遗漏需求。如一个需求说小于100元运费为5元,大于100元运费为价格的6%,但是等于100元的需求没有提出。
- 表达需求信息的方式不止一种,如果某种模型中两个方框之间应有一个箭头,则这个遗漏的箭头就是遗漏的需求。
- 用复杂的布尔逻辑来描述需求通常是不完整的。在表达复杂逻辑时,可以使用决策表或决策树涵盖所有可能的条件。
- 为项目创建一个常用功能领域检查表,包括错误登录、备份和恢复、访问安全、报告、打印、预览能力和配置用户喜好。
- 数据模型可以揭示遗漏的功能。系统所控制的所有数据实体必须要有对应的功能性,CRUD。
文章来源:https://blog.csdn.net/bekeer/article/details/135260234
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:chenni525@qq.com进行投诉反馈,一经查实,立即删除!