原始要求正确的规格说明错误的规格说明需求分析设计正确的设计错误的设计对错误说明的设计编码正确编码错误编码对错误设计的编码对错误说明的编码测试正确功能 可改正的错误不可改正的错误潜伏的错误不完善的软件产品评审方法间的区别各种评审的正式程度最正式最随意评审方法间的区别所有的评审活动都是下列活动的组合：计划研究评审对象举行评审会议修正错误确认修正评审种类计划准备会议修正确认检视有有有有有团队评审有有有有有走查有无有有无结对编程有无持续的进行有有同行检查无有可能会有有无特别检查无无有有无选择评审方法最有效的标准是：对于最可能产生风险的工作成果，要采用最正式的评审方法。对于需求分析报告，因为它的不准确和不完善会给软件的后期开发带来极大的风险，所以必须要采用最正式的评审方法，如或者。又如，核心代码的失效也会带来很严重的后果，所以也应该采用或者的方法进行评审，而一般的代码，采用或者就可以满足要求了。会议之前对评审材料没有足够的了解，于是出现了评审会议变成了技术报告的怪现象。
