实例化需求方法的整理与思考
2023-03-08 17:11:53 3 举报AI智能生成
实例化需求是一组方法，它以一种对开发开发团队有所帮助的方式（理想情况下表现为可执行的测试）描述计算机系统的功能和行为，让不懂技术的利益相关者也可以理解，即使客户的需求在不断变化，它也具有很好的可维护性，可以保持需求的相关性。从而帮助团队交付正确的软件产品。
作者其他创作
大纲/内容
为什么需要实例化需求
需求相关因素是软件项目成败的主因
项目成功的十大要素
项目不成功的十大要素
需求困境
需求不清晰
真的没好好搞清楚需求就开始了开发
需求理解不一致
项目干系人并没有对需求有着一致的理解
需求总变更
不是我不明白，是这世界变化快
需求不全面
过于依赖个人的认知结构
需求困境的原因
业务领域的复杂性
系统往往非常庞大
问题域的专家对软件系统知之甚少
软件分析人员往往不是问题域的专家
在该领域工作的人员往往仅仅熟悉部分信息
沟通的复杂性
总是有变化
用户往往是看到了系统之后，才发现和设想的不同
在项目进展过程中，商业环境发生了变化
技术方案的演进
频繁的变化加剧了文档的过时
实例化需求的目标
做正确的事情：在需求进入开发前，充分澄清需求，明确其验收标准，确保相关人员对其理解一致
准确：避免模棱两可和功能缺失造成的返工
一致：干系人对交付哪些东西有一致的理解
可检验：能够清晰判断该需求是否已经完成
保鲜：活文档，易于支持功能变更
什么是实例化需求
实例化需求的定义
实例化需求 (Specification by Example) 是一种协作方法，它使用真实的例子，而不是抽象的语句，来捕获和说明需求；
通过应用这种方式定义软件产品的需求，产生面向业务的功能测试，来帮助团队交付正确的软件产品。
实例与需求和测试
实例化需求（SBE）的核心要素
有效沟通：有效的交流沟，通确保有足够的时间澄清需求
举例：使用举例的方法澄清需求
集思广益：具有不同领域背景的干系方一同参与，规避认知局限
集体讨论：可以确保大家对于交付哪些东西有一致的理解
经济考量：用最少成本使文档保鲜，并避免过度说明产生浪费
自动化：采用自动化测试实现实例，代码开发出来即可以验证
实例化需求的两种模型
以验收测试为中心的模型
接收测试驱动开发 （ATDD）
侧重自动化测试，将其作为实例化需求过程一部分
开发目标更明确，并防止功能退化
以系统功能规范为主导的模型
行为驱动开发 （BDD）
侧重制定系统行为的场景
通过协作和需求澄清，在项目干系人和团队之间建立共识
优点
更好的协作：配合短迭代（ Scrum ）或流模式开发方法（看板方法），使得分析、开发和测试活动更好地协作。
减少返工：帮助对预期达成共识，显著地减少由于误解需求或忽视客户期望而造成的返工，使团队第一次实现的就是客户所要的。
更高的产品质量：改善了团队成员之间的协作，促进业务人员更好的参与，清晰地定义了预期，使得验证过程更高效。
保鲜的文档：拥有活文档，它是系统功能的可靠信息来源，可以有效地分享知识，实施变更。
实例化需求的三个特征：
用例子来澄清需求；
这些例子成为测试用例；
开发完毕，用这些例子来验证需求。
实例化需求的过程模式
从目标中获取范围
构建正确的范围
理解“为什么”和“谁”（在不同层面）
理解价值从何而来（在目标层次的讨论）
了解用户的预期输出
（建议）让开发人员提供用户故事的“我想要…”部分
工具和方法：精益画布、影响地图、故事地图、需求梳理、多层次需求管理
协作确定范围
询问“为什么这些东西有用”（直至答案开始提及“钱”）
询问替代方案（如果不提供这个功能，会怎么做）
不要只顾最低层次的功能（分层，兼顾高层次和低层次的功能）
确保团队交付完整的功能（组建特性团队）
通过协作制定需求说明
协作模型
大型工作坊
神勇三蛟龙（Three Amigos）（需要频繁澄清领域问题时）
结对编写（成熟的产品）
开发人员评审测试用例
非正式交谈（坐在一起的时候且有空）
准备协作
需求沟通会/澄清会上高层的验收标准，简单的列表
邀请项目干系人参与需求说明的协作
邀请团队共同参与编写需求说明
准备一些初始的实例
不要过度准备，从而阻碍的讨论
使用例子进行
从场景出发，举例子，以用户的操作实例来澄清需求
举例说明更加场景化，激发参与和讨论；
实例能避免歧义，进行准确沟通，确保达成共识
例子必须具有精确性，完整性，真实性，并易于理解
可以为用户界面布局和易用性开发低保真原型
例子应该关注用户和系统之间的交互，而非关注系统本身的处理流程
在场景特别复杂的情况下，还可以使用流程图来辅助举例
如果发现实例太复杂，就把它的复杂度降低，分解成若干个实例
提炼需求说明
需将协作讨论（步骤2,3）的结果以某种形式记录
原始的例子要在建立大家对相关领域的共识的讨论的结果，包含了太多细节
关键实例是从这些实例中提炼出来的，虽然精简但足以说明业务。这些提炼好的实例本身就可以当作交付的验收条件
只列出关键有代表性的实例，使得需求说明简短易懂
实例要精确可测
不要写成脚本和流程式的描述
关注业务功能，而不是软件设计
对于Web项目，不要陷入用户界面细节
检查需求说明是否不言自明（展示给别人看并保持沉默，）
格式化需求描述
使用Given-When-Then
在不改变需求说明的情况下完成自动化验证
概念
并非一定要自动化（SBE目的是取得需求共识，这个通过协作和举例说明得到）
谨慎使用自动化（工具的易用性，成本支出，短期效率下降，而收益是中长期的）
自动化能带来收益
公正客观的完成标准
获得长远利益（活文档）
经常执行，频繁检查
快速反馈
Tips
对自动化进行规划
不要拖延（写代码前，或迭代内完成）
不要委派他人（开发人员自己编写）
尽可能在用户界面之下进行自动化
不要太依赖于现存数据（除非万不得已）
不要在测试代码中引入业务流程或逻辑
自动化提炼好的需求说明应尽量减少改动
频繁验证
提高稳定性
搭建专用的持续验证环境
全自动部署
使用Mock
选择性隔离外部系统
不要用可执行需求说明做端到端测试
尝试多级验证
渐进解决高优先级稳定性问题
加快反馈速度
将大批测试分割成小模块
把快速和缓慢的测试分开
为当前迭代创建一个测试包
并行执行测试
在有时间约束时引入业务时间
演进出一个文档
创建活文档
需求实例创造了活文档主体
在构建系统的过程中增量产生
自动化，直接与系统相连接
使用SBE工具来管理需求说明
通过一些方式组织活文档，使之易于访问
活文档的特点
它是权威和可靠的
它是清晰和易理解的
它是易于阅读和修改的
它及时更新
它前后一致
实例化需求的实施
澄清价值
澄清当前需求的背景和现在；澄清当前需求想要实现的目标和解决的问题。
澄清用户问题和业务目标。需求最终要解决用户的问题，从而实现产品的业务目标。因此，在讨论具体的需求前，我们还要澄清用户是谁，要解决他们什么问题。
识别场景
示例通常是从场景和工作流中获得，复杂需求往往在会议之前已经在准备文档中初步识别场景
注意以下几个问题
（1）比如流程是否合理和高效？任务走查是一个非常好的验证方法，这块后续再议。
（2）是否覆盖所有场景，异常场景有无考虑，是否全面？
（3）流程是否可以更简单？
获得实例
举例说明，以激发对需求的思考和讨论，使用GTW或表格来提炼实例，并将其作为验收条件
实例化需求的应用调查
实例化需求是关于协作的
实例化需求关注目标、功能和业务规则
实例化需求的目标是探索和发现
实例化需求包含一组过程模式
实例化需求可以自然演进到开发和测试
实例化需求可以被一组工具所支持
0 条评论
下一页
