软件开发的最大问题之一往往是需求，而且它也很容易的被作为替罪羊。在公司项目延迟和出大问题的最大借口，就是“需求不清楚、需求变更”。那把需求早点弄清楚不就行了嘛？听着挺容易，但要做好它却很困难。
敏捷迭代起来以后是否会好点呢？理论上会好点，因为需求在一个迭代中东西会少点，更容易理清楚。但就是因为一个迭代的周期短，在开完计划会议后，团队会更愿意直接投入到代码开发中去，他们认为需求已经可以了；项目经理也觉得讨论需求会浪费点时间，很多人包括开发者都认为写代码才是干活。
那是否有好的办法把需求质量有效得提高？解决需求当然有许许多多的办法，下面是几种常见的方式：
从TDD（测试驱动开发）引申出来的ATDD（Acceptance Test Driven Development: 验收测试驱动开发）。就是把TDD对开发者的成功经验挪到测试团队中，让测试人员在项目中起主导地位。
BDD（Behavior Driven Development：行为驱动开发）就是强调先搞清楚功能的业务需求，有它来指导后续的开发。
FDD（Feature Driven Development特性驱动开发）在FDD中，Feature（特性）是一个基本的开发单位，是用户眼中最小的有用的功能，可以在很短时间内实现（一般在两周之内）。
实例化需求（Specification by Example)：顾名思义就是要用例子的方式去阐述需求，这个概念是由Gojko Adzic提出的。
从本质上来说，实例化需求和ATDD、BDD、FDD包括其他的敏捷测试都是一个范畴。相比其他几个实践，实例化需求出现的较晚，最近几年才开始推广，我曾经所在的项目组也是2015年底才开始推广的。但它提出了更好的实践方式，减少了对工具的依赖，更容易被接受。
主要过程模式
在【实例化需求】一书中，Gojko提出了实例化需求的主要过程模式
主要过程模式主要包括以下几个重要环节：
从目标中获取范围：要一直牢记商业价值，为什么要做。很多时候执行项目时太关注怎么做了。
用例子来协作探讨需求：例子能更好得把需求描述清楚，不能含糊。
提炼需求说明：通过例子了解需求后就可以提炼出需要的需求说明。
执行需求说明并自动化：需求说明如果能执行并放入到持续集成后，信息就不会过期。
活文档：文档要长久，就必须要容易维护，从需求说明中自动产生出的活文档是最有效的方式。
举个例子：
需求主题：买书免运费
需求描述：提供读者买书优惠活动，买书超过（含）6本以上而且只含书的订单，可以免费送货到除西藏省，青海省的大陆地区。
关键例子：
一个普通客户买6本书，送货地址到上海，免运费。
一个普通客户买6本书，送货地址到西藏，运费大于0
一个普通客户买5本书，运费大于0。
一个普通客户买6本书和一个U盘，送货地址到上海，运费大于0
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
