聊聊实例化需求
前几天星球有同学问了一个问题：需求实例化是什么？我的回复是：将需求故事化。故事一般具有这几个特征：有背景和设定、有过程有逻辑、交代了前因后果。
对测试同学来说，日常工作的开展基本都是依托于测试用例，要设计好的测试用例，其本身要求对业务需求和被测系统有足够的理解。
但实际情况是拿到手的往往只有一份PRD，只对需求的功能做了简单描述，这样会导致在需求评审阶段浪费大量的时间去不断讨论确认不明确的点。
需求评审之后依然要花费大量时间去分析需求细节，做用例评审。而需求实例化，就是一种可行性较比高的方法，它可以对PRD或者需求进行更好的分解，得到和业务规则较为匹配的测试用例模型。
这篇文章，来聊聊关于需求实例化的内容和基本的实践步骤。
什么是实例化需求
需求实例化其实更多的被称为实例化需求，英文是Specification by Example，简称 SBE，简单来说既用实例说明需求。
你可以将它理解成一种快速理解需求的方法，它从具体的用户操作场景出发来澄清需求，相比于我们常见的PRD，它的典型表现形式为“在什么情况下，做了什么操作，产生什么结果”。
如上图所示，实例化需求的核心概念是一个三角模型。它的核心概念是：
- 首先用实例来澄清和分析需求；
- 其次这些实例会转化为测试用例；
- 最后通过转化的测试用例验证需求；
实例化需求的特征
相比于传统的产品编写简略PRD并组织开发测试人员进行评审，实例化需求更强调的是让项目中所有相关人员围绕需求进行高效的协作和沟通。
它的一般形式为用实例的方式说明需求，用自动化的方式频繁的将实例转化的测试用例进行执行以验证需求，通过实例化的需求说明和自动化测试用例来演变出一套可维护性较好的“项目文档”管理系统。
即使需求在不断迭代变化，团队人员在不断变化，这个“项目文档”管理系统也可以持续的保持需求的活力和相关性，帮助团队更好的交付高质量的软件产品。
这种灵活的持续的“项目文档”管理方式具有如下几个特征：
- 高效沟通协作，确保足够的时间来澄清需求；
- 需求实例能在第一时间被识别出是否可以投入开发；
- 项目所有相关成员都参与讨论，确保对最终交付物有一致的理解；
- 多个不同角色共同参与讨论，避免个人局限性带来的风险遗漏问题；
- 降低“项目文档”的维护成本，避免过度解释需求，提高需求的可维护性和变更灵活性；
- 用自动化测试的方式实现业务实例，代码提交即可进行测试验证，降低回归测试验证的成本；
实例化需求的实践步骤
实例化需求的主要内容为如下三点：
- 目标：团队各成员对于业务目标和最终交付目标达成一致；
- 流程：即最关键的操作流程（比如登录功能，需要输入账号名密码，同意协议，点击登录按钮）；
- 规则：规则即对关键操作流程的节点进行描述（比如账号名只支持手机号，密码最少不能低于8位）；
在实际的工作应用中，大致可分为如下五个步骤：
1、介绍背景：首先对需求的背景进行介绍，即为什么做这件事，要解决什么问题，对业务有什么价值。
2、定义目标范围：明确目标用户群体，最终交付要达成的具体目标，需求涉及的业务范围，具体是哪些模块。
3、罗列用户操作：以电商订单业务为例，用户可以执行的操作有（创建订单、取消订单、查看订单列表和详情）。
4、描述工作流程：工作流即我们常说的业务流程或者业务场景，用户通过一系列的操作，达成系统也目标的实现方式
（同样以订单模块为例，用户创建订单的步骤为登录-选择商品-点击购买-选择收货地址-点击付款-创建订单成功）。创建工作流程常用的方法有流程图、涌道图、状态机、时序图等。
5、描述业务规则：以会员等级为例（vip1需消费满100元，vip2需消费满500元，vip3需要消费满1000元。且从vip3会员开始，下单包邮；低于vip3的会员需要自费快递费用）。
以上即为实例化需求的基本概念和实践步骤，后面我会分享实例化需求方法对质量保障的带来的帮助，敬请期待。
想了解更多关于实例化需求的知识，可以关注公众号，后台回复关键字：实例化需求。获取相关PDF。
