你知道如何在需求评审阶段快速高效的发现高质量的需求问题吗？下面我将第一次公开分享我在工作中所原创的一种需求评审方法－结对需求评审法（在国内国外都是首创）
无论在任何软件企业，都会存在需求评审的环节，在这个环节我们测试人员应该如何发挥更大的质量保障的价值，是很多团队都会尝试的事。因为大家都知道在需求阶段发现问题成本、定位问题成本，修复问题成本最少。要提升整个研发的效率，减少返工浪费，最好能在需求环节尽早发现需求问题。如何快速容易的发现需求的问题，软件测试业界其实一直苦于缺乏高效的实践方法。
09年时我也曾经接到过这样的一个任务：如何进行早期测试？如何进行缺陷预防。其中必须解决的一个问题就是：如何提高测试人员在单位时间内发现的有效需求问题数？虽然我们知道需求的质量也是有维度的：二义性、可测性、完整性、前后一致性、可实现性、必要性。我们应该从这些维度来发现需求问题，其中最主要的是二义性问题。但这只解决了What的问题，应该如何解决How的问题，如何发现这些类型的需求问题，就是测试技术或
测试方法需要填补的空白。
现在有两套方案推荐给大家：
方案一：Richard Bender的RBT基于需求的测试。
方案二：我原创的DZ结对需求评审法
如果你担心用得方法听起来太简单无法体现技术含量，而希望用复杂的过程及方法来体现技术的高精尖，你可以选择方案一；
如果你希望用简单快速高效，不介意别人说你方法太简单的可以选择方案二。
下面主要分享DZ结对需求评审法
这个方法是我09年时与一位叫周博的同事，一起实践发明的。针对需求中问题数量最多，也最严重的二义性问题，体会到很难通过传统的评审会形式快速发现，而且发现效率也低。正好当时大产品团队正在实施结对编程（只对着一台电脑，一人写代码一人review代码）。我受此启发，某日灵感一现：想到结对需求评审这种形式。于是拉上周博同学，一起进行实践，实践方法如下：
<!--[if !supportLists]-->1、 <!--[endif]-->两人只对着一台电脑、由1人作为引导员来操作电脑，记录评审结论
<!--[if !supportLists]-->2、 <!--[endif]-->引导员控制时间节奏和维持结对需求评审的规则，两人针对每条需求，逐条进行固定时间窗（1－3分钟）范围内的理解
<!--[if !supportLists]-->3、 <!--[endif]-->2位评审人在单个需求的理解时间到时，直接说出每人对这条需求的理解。如果两人理解一致，就直接看下一条需求；如果理解不一致，不能进行讨论，而是由引导员直接记录下两个人的不同理解内容，这时说明这条需求至少已让2个人产生了二义性的理解，需求存在二义性问题。
关键技术活动点的理论支撑：
<!--[if !supportLists]-->1、 <!--[endif]-->一条需求（1－3行文字）如果需要你使劲思考和理解5分钟以上还不能准确说出其描述的本意，那么已说明这是一段容易让人理解出错，容易产生二义性问题的文字描述；
<!--[if !supportLists]-->2、 <!--[endif]-->如果一条需求已至少让两个人产生两种不同观点，那么就可能让更多的人同样产生二义性理解问题；
影响结对需求评审效果的关键：
1、多练习。对于方法的初次使用者，建议第一次先用1小时拿需求文档进行练习熟练后，再在正式的需求评审项目中进行使用（提高效率）。
2、参加需求评审的2名测试人员应该先了解过产品的背景和历史，才参与结对需求评审活动。（提高效率和产出质量）
参考投入产出比：
某项目用2小时发现40多条需求问题；
某项目第一次练习应用20分钟发现4条需求问题；
备注：一个需求二义性场景，需求编写人员心里想做个椭圆的盖子，开发者理解成了圆形，测试者理解成了方形（已开发了方形盖子的测试用例），然后开发者和测试者发生沟通冲突开发被迫返工。
----------------------------------------------------------------------------------------------------------------------
作者：架构师Jack
