需求规格实例化

需求规格实例化（Specification by example）也称为实例化规格，简称SBE，是一种协作方法，利用撷取实际范例和说明，来定义软体产品的需求和以业务为导向的功能测试，和其他方法用抽象的说明定义需求的做好不同。需求规格实例化常用在敏捷软件开发上，特别是行为驱动开发（behavior-driven development，BDD）。此作法特别适合用来管理重大领域以及有组织复杂度的大型专案中的需求以及功能测试^[1]。

需求规格实例化也称为实例驱动开发（example-driven development）、可执行需求（executable requirements）、允收测试驱动开发（英语：acceptance test–driven development）（ATDD^[2]或A-TDD^[3]）、敏捷允收测试（Agile Acceptance Testing）^[4]、测试驱动需求（Test-Driven Requirements、TDR）。

优点

高度抽象概念或是全新的概念在没有具体实例时，很难让人理解^{[来源请求]}。需求规格实例化的目的是要建构准确的理解，大幅减少软体开发过程的回馈回路、减少重工、提高产品品质、针对软体变更有较快的交付时间、在软体开发团队不同角色（例如测试者、分析师和开发者）的活动可以比较一致^[1]。

以实例为单一事实来源

需求规格实例化中，很重要的是创建有关专案各层面资讯的单一事实来源（英语：single source of truth）。多半情形下，商业分析师（英语：business analyst）有自己的文件，会在其文件上进行相关工作，软件开发者维护其自己的文件，测试者有另一份功能测试的文件，需要定期维护这些文件，在不同文件和不同版本之间同步，因此软件部署的效能会大幅下降。若是短的迭代周期，维护一般需要每一周或是每两周一次。利用需求规格实例化，不同角色一起参与，知道大家所理解的内容，创建单一的事实来源。实例可以清晰准确的说明，因此同一个资讯可以用来当规格以及业务导向的功能测试。在开发或是交付程中发现的新资讯（像是功能落差的澄清、缺乏需求或是需求不完整、需额外测试等）都可以加入这个单一事实来源中。因为这是唯一一份有关功能的事实来源，在交付周期中，不需再维护、翻译或是诠释相关资讯。

若应用在需要变更的情形下，一组良好的实例可以有效的成为软体功能的规格，以及业务导向的验收测试。在变更实施后，有实例的规格成为文件，说明已有的功能。随著这类文件可以自动化验证，在其频繁验证的过程中，这类文件就是软体业务功能的可靠资讯来源。为了区分这类文件以及传统的列印文件（很快就会过期）^[4]，有实例的完整规格会称为活文件（Living Documentation）^[1]。

重点实务

应用需求规格实例化的团队常常会进行以下的实务^[1]：

• 从目标推导专案规模
• 规格协作：透过整个团队的规格工作坊、较小的会议或是电话会议评审。
• 用实例来描述需求
• 完善规格
• 以实例建立自动化测试
• 时常用测试确认软体情形
• 从有实例的规格开始，演进文件系统，以支援后续的开发。

应用需求规格实例化的软体团队一般会花5%至10%的时间完善产品backlog、包括规格协作、用实例来描述需求和完善实例^[3]。

实例映射

实例映射（Example Mapping）是简单的技巧，可以在短时间带领对话，推导允收准则。此作法将故事拆解为以需求规格实例化表示的规则和范例，在BDD圈有许多人使用^[5]。

适用性

一般会将需求规格实例化应用在有相当组织复杂度和领域复杂度，从业务领域观点了解需求或沟通会造成问题的专案。需求规格实例化不适用在纯技术问题，或是其困难度不是在了解知识或沟通知识上的专案。有使用需求规格实例化的领域包括有银行投资、金融交易、保险、机票预订、线上游戏或是比价^[1]。也有记录提及将需求规格实例化用在核电厂模拟计划^[3]。

基于共享范例的测试适合归类在：以从业务角度支援团队交付软体的测试类别中（可参考Agile Testing Quadrants^[6]）确保所建构的是对的产品。这类测试无法取代以纯技术观点看待软体系统的测试（这类测试会评估软体是否以正确的方式建构，这类测试包括单元测试、模组或是技术整合测试），或是一些在产品完成后进行的测试（例如渗透测试）。

历史

最早有纪录的，用实例作为单一事实来源、需求和自动化测试的软体专案是WyCash+专案，用沃德·坎宁安在1996年的论文《A Pattern Language of Competitive Development》^[7][8]。Specification by Example的名称是由马丁·福勒在2004年所提出^[9]。

需求规格实例化是源自极限编程在1997年提出的Customer Test^[10]实务，和领域驱动设计在2004年提出的Ubiquitous Language^[11]，其中使用了Weinberg和Gause^[12]在1989年提出，以黑箱测试为需求的概念。

自动化

要成功的将需求规格实例化用在大型专案，需要频繁的用大量的实例来测试软体功能。实际上，这需要可以自动化进行以实例为基础的测试。常见的作法是将测试自动化，但让实例维持成团队非技术成员或技术成员可读取、可取得的形式，让实例是单一事实来源。有许多测试自动化的工具可以支援此过程，其作法会将测试分为两部份：规格和自动化层。测试的规格常会以文字、HTML格式出现，包括实例和辅助说明。自动化层连接待测的软体系统。这些工具有

• Behat（英语：Behat (computer science)）
• Concordion（英语：Concordion）
• Cucumber（英语：Cucumber (software)）
• FitNesse（英语：FitNesse）
• Framework for Integrated Test（英语：Framework for Integrated Test）
• Robot Framework
• .NET的 Reqnroll和SpecFlow
• Gauge (软体)（英语：Gauge (software)）