引言
整个项目迭代周期中，产生的bug，其原因可能来自多个方面，例如：需求分析不足/需求不符合客户需求、技术实现与需求不符、环境因素等等，这里重点说一下需求阶段引入的bug问题。
需求调研、分析、评审阶段中任何一个环节的不充分都会给需求本身留下隐患，进而在整个项目的中后期才能发现。更甚者，到了上线还没有发现，只能下次迭代进行弥补了。
需求引入问题的严重性
这里举一个身边实际发生的一个需求评估不足产生的一个问题： 当时PM提出了一个大的首页大改版，经过需求评审后，没发现什么不合理之处，技术人员经过两周的加班加点实现、测试、产品验收，最终上线了。但大产品boss一看，明显不对自己的口味，于是乎这次的大改版马上就有进行了一个大改版，改回去了原来的样子。
从上面的例子中可以看出，需求实现后又被推翻的根本原因在于： 需求调研、分析阶段上下级未达成一致，就匆匆拉技术人员进行了实现，导致了白白浪费了一大波时间。
基于需求测试的必要性
调查表明56%的缺陷其实是在软件需求阶段被引入的（James Martin, "An Information Systems Manifesto", Prentice Hall, 1984）。这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的；剩下的50%是由于需求的遗漏导致的。
上面的数字来自权威数据，具体的数字可能与每个项目有所出入，但基本可以论证对基于需求测试的必要性了。
记得自己在负责整个从0到1的项目，前大半年的时间里面，需求方面的bug占比大约20%+，这类需求从提出到修复会占用团队不少时间：测试人员提测——>产品人员确认——>技术人员实现——>测试人员测试——>产品人员验收。
基于需求测试需要做些什么
- 需求文档的质量
由于需求文档编写有问题、不明确、不清晰、不正确等都可能引入问题，因而在需求评审时，一定要对类似可能出问题的地方一一核对清楚，并让PM人员记录在需求文档中。
- 需求中的实现方案质量
由于现在的系统往往都经过了一年、两年、甚至更长周期的迭代，系统本身往往都比较复杂，涉及的功能场景很多，逻辑分支很多，往往关联到的第三方，要做到完全的覆盖几乎不可能。
需求评审中，需要对实现方案做反复斟酌，万万不可一刀切，给后续留下隐患。
- 需求中没有明确说明部分的质量
这属于需求评审中隐藏比较深的部分了，这其中暗含了：
1、需要所有成员根据经验来评估哪些部分受到了影响，而需求本身又没有明说；
2、涉及到影响的部分如何处理、实现才能符合整体需求目标；
3、与产品目前现有的实现是否有冲突，或影响产品一致性等