实例化需求不仅解决了需求分析和撰写的问题，也给出了需求沟通和澄清的方法。本文从实例化需求的定义出发，从使用实例化需求的原因、实例化需求的产生输出、自动化测试和操作流程这几个方面对实例化需求进行了说明介绍，与大家分享。

01 什么是实例化需求？

实例化需求的英文是 Specification by Example，简称 SBE，直译过来就是用实例说明需求。

实例化需求是一组方法，它以一种对开发开发团队有所帮助的方式（理想情况下表现为可执行的测试）描述计算机系统的功能和行为，让不懂技术的利益相关者也可以理解，即使客户的需求在不断变化，它也具有很好的可维护性，可以保持需求的相关性。从而帮助团队交付正确的软件产品。

为避免需求沟通过程中的「知识诅咒」，“实例化需求”方法从场景出发，以用户的操作实例来澄清需求。

相比一般的规格说明，实例更加场景化，能够激发参与和深度讨论；同时，实例是具体的，其典型形式是：「在什么情况下，做什么操作，会得到什么结果」。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。

上图是对实例化需求的概念说明：

• 用例子来分析和澄清需求。
• 这些例子随后会转化为测试用例。
• **再通过测试验证需求。

如此形成闭环，这个三角是实例化需求的核心概念。

在「实例化需求」中，开发、测试和业务人员一起沟通需求，避免信息传递的噪音和损耗。

02 为什么使用实例化需求？

实例化需求的核心是，让项目的所有干系方进行有效的协作和沟通，用实例的方式说明需求，用自动化测试的方式频繁地验证需求，从实例化的需求说明和自动化测试用例中演进出一套“活文档系统”。这套“活文档系统”既可以有效地对系统进行说明，又可以当做交付验收的标准。

• 有效的交流沟通确保有足够的时间澄清需求。
• 使用举例的方法澄清需求能在第一时间识别出需求是否足以支撑开发。
• 所有的干系方参与需求讨论，可以确保大家对于交付哪些东西有一致的理解。
• 具有不同领域背景的干系方一同参加需求讨论，可以规避因个人认知局限带来的需求问题。
• ”活文档系统”对于变更有着先天优势，可以以最少的维护成本维持文档的相关性和可靠性。又能避免过度说明需求而产生浪费，避免花时间在开发前有可能发生变化的细节上，对于变更天然友好。
• 采用自动化测试的方法实现业务实例，代码开发出来即可以验证，无须经过冗长的手动回归测试，降低返工。

03 产生哪些输出？

实例化需求有9个过程模式：从目标获取范围、协作产生需求说明、举例说明、提炼需求说明、在不修改需求说明的情况下实现自动化验证、频繁验证、以及演化出一个活文档系统。这 9 个过程模式涉及了如下的输出（制品）：目标和范围、需求说明、例子、自动化测试及活文档系统。

下面我们一个个来详细说明。