1．思想

前面已经说过，由于Review被翻译成“评审”，导致很多人将其与中国人常说的评审相混淆，其实它们之间是有区别的：中国人常说的评审是评价，而Review应该是复查，是发现问题。这一点，必须成为所有组织、参加需求评审会的人员都应该建立的统一认识。

隐喻：

当测试团队严肃、认真地对你说：“经过我们三天时间的测试，发现你提交的程序一个Bug也没有！”请问你会作何理解呢？

A、我的程序很牛！
B、这个测试团队的方法或态度有问题。

我想很多人会选择B吧！因为“人非圣贤，孰能无过！”应该是测试手段还存在问题，导致潜在的问题没有被暴露。

可是，“我的需求评审通过了！”之类的话题总是被许多需求人员以很开心、愉快的方式说出来，我怎么听怎么觉得像听到“我的程序真牛！”。

就像我们不是想花大量的测试成本来验证自己的程序无错一样，采用成本昂贵的评审技术也不是为了验证需求文档是无错的，而是帮助我们尽早地发现问题、找到错误，避免因问题被延误到后期解决而付出惨痛的代价。

SERU诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。

2．方法

统一了思想之后，接下来的重点就是“方法得当”。

SERU诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，是创建企业评审文化的有效手段。

3．语言

SERU诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。

4．人员

要开好评审会，选择合适的参与人员是很重要的；要点在于合适，而不是越多越好。具体来说，包括三个方面的要点：

同级：别忘了，在CMM/CMMI中提到的是Peer Review，Peer就是同级，千万不要一开评审会就请高阶领导。

该来的人要请：也就是评审的内容所涉及的第一责任人，要想办法请他们参加。

不该来的人不要请：也就是评审不是越多人参加越好的，通常应该保持比较小的范围，要直接相关的人员参与；一方面可以保证参与者对评审内容熟悉，另一方面也可以保证参与者关心评审过程。
SERU诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。

5．内容

建议大家控制在9条之内，理由就是心理学中的“7±2” 原则，也就是人们容易记住的信息条目在5～9条之间。因此大家也可以根据实际的情况做一些变通。

除了要对缺陷检查表的规模进行压缩之外，还应该对评审的需求规格说明书进行压缩。根据笔者的经验，一个较熟悉的团队，要对需求进行相对有效的评审，应该控制在每小时30～40页之间。
那么在实际的工作中，我们如何对需求文档进行切分呢？是开一个时间周期很长的评审会，还是多次时间周期较短的评审会呢？似乎这两种方法都不尽可行。

解决该问题的关键在于必须对需求规格说明书进行拆分，根据读者的层次、所关心问题域的不同进行拆分，具体的方法我们在第4～6章中已经做了很多说明。

SERU诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30～40页的速度来准备，缺陷检查表尽量在9条之内。