二、确定评审的关键点
　　评审的关键点一般需要事先整理在评审检查单上，供参与评审的人员了解，并以此作为评审过程的主要依据。这些内容需要认真分析项目的特点，针对评审对象的质量要点进行整理。下面是针对需求分析、系统设计及测试方案几方面进行评审建议的关键点，但不局限于此。仅供参考：
　　1.对用户需求分析进行评审
　　需求文档是否按照项目规定的文档模板进行编写?
　　是否已经清晰的描述了系统的业务背景、目标?
　　是否已按照用户特点对目标用户进行分类，而且定义是的?
　　系统用户和系统的间接用户是否已经识别?
　　是否识别定义了在将来可能会变化的需求?
　　是否已考虑了项目特定技术的限制，如接口，数据库，并行操作，通讯协议，设计约定，编程规范等。
　　本项目与其他项目间的依赖关系是否已明确描述?
　　本软件同其他软件之间的公共接口、数据通信协议等要求是否明确?
　　对于用户的业务流程是否清晰描述，并对关键业务流程绘制了标准的、易于理解的流程图?
　　用户对界面的要求描述是否清晰，易于理解?
　　是否说明了如何进行系统输入的合法性检查?
　　业务功能的描述符合假设、约束的要求吗?
　　各个需求之间是否一致?是否有冲突和矛盾?
　　用户对软件、硬件、网络环境的要求是否已清晰描述?
　　用户对系统质量的要求是否已清晰描述，并给出了详细的指标参数;
　　需求定义是否足够清楚和明确，以满足能够作为开发设计规约和功能性测试数据基础?
　　2.对系统设计进行评审
　　设计文档是否按照项目规定的文档模板进行编写?
　　所提出的技术方案在技术上是否可行?
　　技术方案实施的复杂程度是否可接受?
　　系统现有能力(包括功能、性能等)是否已不能满足业务需求?
　　对系统存在问题的分析是否清晰准确?
　　所提出的技术解决方案是否采用成熟技术，是否经济合理?
　　是否对方案实施后，系统的处理能力及可适应业务变化的情况进行了量化分析和预测?
　　是否对限定条件和假设条件进行了说明?
　　是否考虑了系统的易升级性、扩充性和可靠性
　　是否满足系统的安全性要求?
　　是否对与其它相关系统的接口进行了明确说明?
　　是否有其它可替代方案?是否进行了对比分析?
　　是否对实施风险进行了分析?
　　所提出的方案是否比其它方案在综合比较上具有优越性?
　　有关方案中的数据计算和推断是否合理?
　　3.对测试计划和测试用例进行评审
　　测试计划和测试用例是否按照项目规定的标准模板编写?
　　测试计划中是否清楚地描述了测试方法及测试环境要求?
　　测试用例结构是否清晰、组织是否合理?编号是否正确、?
　　测试用例内容描述是否正确、清晰明确、易读性强?
　　是否每个需求(或需求条件分支)都有对应的测试用例?
　　是否在测试用例中列举了一些过去常存在的错误?
　　是否测试了典型的中间值、临界值进行了测试?
　　是否对复合临界值，即组合输入数据可能导致错误输出进行了测试?
　　测试用例是否检查误操作对系统的影响(健壮性)?
　　是否设计了系统数据初始状态时的测试用例
　　是否存在安装卸载测试用例?
　　是否存在非功能性测试用例?如易用性、兼容性?
　　三、评审会的操作规则
　　为了保证评审会组织的有效性，根据我们实际工作的经验总结出一些组织评审会时应把握的操作规则：
　　会场要保持有良好的协作气氛。要求各参加评审的人员跳出自己在建设中所处的角色，均站在用户的角度，站在为整个项目负责的角度考虑问题、分析问题;
　　关注评审产品，而不是评审具体的设计者或编写者(不能使当事人有任何压力);
　　指明问题范围，限制争论与反驳。因评审会的目的不是为了解决问题，而是尽可能多的发现问题;
　　采用投影和白板书写的方式清楚地展示论述的问题;
　　为每次技术评审尽可能安排充足的时间资源，以保证实际效果，但一次评审会的时间好不要超过3个小时;
　　事先给参会者提供被评审内容的文档进行预评审，会上只梳理要点以提高效率;
　　评审会上要安排专人进行会议纪要的记录与整理，并在会后整理出文字供与会者签字确认。
　　四、做好评审后的跟踪工作
　　在评审会后，需要根据评审人员提出的问题进行评价与整理，必须明确所提出的问题哪些是致命的错误，哪些是一般性错误;哪些必须纠正，哪些可以不纠正，并给出充分的、客观的理由与证据，以形成书面的评审报告。确定了需要纠正的问题后，要责成责任人在规定的时间范围内进行修改并提交新一版的文档。对于错误不多的评审对象，可以仅安排参与评审的人员对修改后的内容简单的进行文档会签评审;而对于发现错误较多的关键的评审内容，在变更修改完成后，必须要安排时间再次开会进行复审。切忌评审完毕后，不再对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。我们曾为一个评审内容先后举行过两次复审会议。