问题描述：我们公司快要成立测试部了，之前我们一直是研发部下的测试小组，在成立之前，我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求，我们几个都没有相关的经验，所以我在此求助大家，邀大家来讨论下：如何进行需求评审？怎样的需求评审机制才是有效的？

精彩回答：

　　1、需求评审的重要性

　　软件的缺陷并不是在编程的时候才出现的，需求和设计阶段都会产生问题，如果缺陷发现的越迟，修正这个错误就要返回到以前的状态，反攻的时间就花费的很多了，如果错误还不能够被及时发现，那就可能带来更大的危害，缺陷发现的越找，修正的越早，所用的成本就月低，越迟，成本就越高。所以我们对需求评审要认真对待了。概括下有几点

　　a 对软件需求进行正确性的检查，能发现需求定义中的错误，从而节约成本，使后续过程的变更减少，降低风险。

　　b 保证软件需求的可测试性，即确认客户的需求是明确的，可遇见的。可以用测试用例反应出来

　　c 通过产品需求，可以使产品，开发，测试等部门相互沟通，达成一致

　　d 通过产品需求的评审，更好的理解产品的功能性和非功能性需求，为制订测试计划，测试范围，工作量等提供参考。

　　2、需求评审的注意点

　　a 明确自己的角色和责任，熟悉评审的内容

　　b 针对问题表达自己的观点，对事不对人。分清主要问题和次要问题，先把主要问题说出来。

　　c 提高自己的沟通能力，

　　d 最主要的一点就是要善于提问，自己问自己问题。是否这个需求不明确，是否需求画蛇添足，站在最终用户角度想问题，而并不是绝对的站在需求提供方的角度。

　　本文出自51Testing软件测试网，感谢会员阿七在每周一问（08-11-10）中的精彩回答。
　　http://bbs.51testing.com/forum-157-1.html

　　3、评审的形式

　　a 交叉评审 b 轮查c 走查d 小组评审e 审查 （这些大家应该都经历过吧，O(∩_∩)O 不多说了）

　　4、评审的标准

　　组织和完整性

　　● 所有需求的编写在细节上是否都一致或者合适？

　　● 是否包括了每个需求的实现优先级？

　　● 软件需求规格说明中是否包括了所有客户代表或系统的需求？

　　● 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。

　　● 是否记录了所有可能的错误条件所产生的系统行为？