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

精彩回答：

　　1、需求评审的重要性

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

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

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

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

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

　　2、需求评审的注意点

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

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

　　c 提高自己的沟通能力，

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

　　3、评审的形式

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

　　4、评审的标准

　　组织和完整性

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

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

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

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

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

　　● 是否有需求与其它需求相冲突或重复？

　　● 是否简明、简洁、无二义性地表达每个需求的？

　　● 是否每个需求都能通过测试、演示、审查得以验证或分析？

　　● 是否任一个特定的错误信息都具有唯一性和明确的意义？

　　质量属性

　　● 是否合理地确定了性能目标？

　　● 是否合理地确定了安全与保密方面的考虑？

　　● 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？

　　可跟踪性

　　● 是否每个需求都具有唯一性并且可以正确地识别它？

　　● 是否可以根据高层需求（如系统需求或使用实例）跟踪到软件功能需求？

　　特殊的问题

　　● 是否所有的需求都是名副其实的需求而不是设计或实现方案？

　　● 是否确定了对时间要求很高的功能并且定义了它们的时间标准？

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

　　5、进入和退出审查的标准

　　当软件需求文档满足特定的前提条件时，你就可以进行需求审查了。这些标准还可以使审查小组避免把时间浪费在审查之前就应该解决的问题上。调解者在决定进行审查之前，可以把进入审查的标准作为一种清单，并以此作为判断的标准。

　　● 文档符合标准模板，并且已经做过拼写检查和语法检查。

　　● 在文档中打印了行序号以方便在审查中对特定位置的查阅。

　　● 所有未解决的问题都被标记为（待确定）。

　　● 包括了文档中使用到的术语词汇表。

　　相似地，在调解者宣布审查结束之前，你应该定义所满足的退出审查的标准。

　　● 已经明确阐述了审查员提出的所有问题。

　　● 已经正确修改了文档。

　　● 修订过的文档已经进行了拼写检查和语法检查。

　　● 所有（待确定）的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期和提出问题的人。

　　● 文档已经登记入项目的配置管理系统。

　　6、总结

　　基本上能做到以上说的几点，需求就应该很明确了。接下来的流程也会走的很顺了！