BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法。行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的。这让开发者得以把精力集中在代码应该怎么写，而不是技术细节上，而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。

关于如何处理需求说明与测试，不同的组织使用不同的名称，或者说是不同的定义，但他们都有一套共同的核心原则与思想，而且当你接受他了之后，我们便可以认为他们本质上是一致的。通常有如下定义：

敏捷验收测试

验收测试驱动开发

实例驱动开发

User Story测试

BDD行为驱动开发

实例化需求说明（Specification by Example）

　　对于以上的概念，我想大家都不陌生，但可能都是一个概念，因为没有实践。当具体去实践，其实就发现跟我们平时的流程相对也很容易理解，只是方式不一样，或者执行流程不一样，当然这里要说的就是不同，那就是方法。方法都是总结出来，多实践之后，提炼出来的就是适合我们的方法。就如同我们在实施了一段时间之后，突然有一天有人问我什么是BDD（行为驱动开发），我发现我很疑惑，我不理解。但细想，我现在做的流程不就是BDD吗，而我现在做的流程准确来说被定义为实例化需求，但这个概念似乎不能把开发和测试给拉进来，而用BDD来定义，似乎就一瞬间把需求、设计、开发和测试拉绑定在了一起。

　　何为BDD？其实就是通过真实用户的行为来定义我们需要开发出什么样的产品来，个人理解。但再结合实例化需求，就会发现，我们就是把用户的行为通过一个实例化的过程描述出来，然后整理成设计、开发和测试都能看懂的，当然最重要的是用户也能看懂，而且用户看完之后就认可，这就是我想要的，这就是BDD，也就是实例化需求过程。

它既不是传统的需求文档，也不是设计文档，更不是测试用例文档，但适用于从需求、设计、开发和测试的每一个阶段，而且都是从用户的角度为出发点的。那我就认为那就是我们想要的过程模式。

本次将介绍实例化需求过程的基本流程

　　以下为实例化需求说明的主要过程模式：

　　

　　当我们获取一个业务目标时，将按照上述流程图来生产实例化需求过程

从目标中获取范围

通过用户提供的需求描述，我们将这些描述转变成另一种用户能够理解且真实用户实际地行为方式，这里就要引入User Story用户故事的概念。然后以客户的业务目标为起始，然后通过协作界定可以实现目标的范围。这里最关键的就是与用户更密切地沟通，通过不断细化，确认这才是用户想要的功能。

从协作中制定需求说明

之所以要提出协作制定需求说明，目的是让需求、设计、开发以及测试都参与进来，发挥整个Team的知识和经验，力求让项目的干系人都更多的参与到交付过程中。

举例说明

举例说明其实是项目需求交流过程中不可或缺的，团队中不同职能人都有，而且每个人的业务背景不同，通过举例说明的方式可以让目标更一致。

提炼需求说明

协作过程中的开发讨论可以建立大家对相关领域的共识，但最终得到的实例往往包含很多不必要的细节。而关键实例必须是精简的。提炼需求说明的过程，其实就伴随着实例化需求的产生，且这些提炼好的实例就可以当作交付的验收条件。

频繁验证

频繁验证的依据就是提炼需求产生的实例化需求，它是所有过程实施中都必须要反复进行的工作。需求通过频繁验证与用户进行频繁确认；设计通过实例化需求来频繁验证设计是否满足用户的需求；开发通过实例化需求频繁验证代码中业务逻辑；测试通过实例化需求来频繁验证交付的功能，并作为最后验收测试的依据。

演化出一个文档系统

通过以上的这些流程，最后演化出一个文档系统。之所以称为文档系统，主要是体现它的可靠性、权威性。所有设计、开发、变更以及测试过程都以此为出发点来考虑，并及时更新，长久维护。

实例化需求过程的核心就是与用户站在一起，从沟通开始，不断举例、细化、精简到统一确认。