| 本文根据2005中国软件工程大会暨系统分析员年会演讲提纲整理而得，主要转载原作者在需求与设计评审学习与实践中的一些体会，内容包括评审的必要性、评审的目的、评审的流程、评审的层次与角度，评审的准备工作、评审角色构成、评审角色职责、评审人员的选择、评审中的常见问题、注意事项，以及评审工作的持续改进等。
评审的必要性
软件阶段评审是软件质量管理中较重要的措施之一，做得好可以及时有效地发现一些错误。对于评审的必要性相信读者都有一定的认识，但是认识未必是一致的，这里列举一个社会新闻中的典型事例来说明：
前一阵子在电视上有一条新闻，为了防止长途客车上的抢劫与盗窃，有关单位在福州开往漳州的大巴上安装了摄像头监控装置。记者为此采访了一些乘客，大部分的乘客都表示这是一个防抢防盗的有力措施，必将有效控制日益猖獗的车上抢劫与盗窃行为。然而也有少数乘客提出了反对意见，他们认为小偷只是少数，安装摄像头监控让他们的个人隐私暴露无遗。有时想和女友亲热一下都要被人监视，没有必要为少数犯罪分子来侵犯大家的隐私权。由以上事例可见，对于某些问题的防范措施的出台的必要性并不是大家都有共识，而是会有各种不同的声音。对一件事情有不同的声音是正常的，我们也没有必要以对错来评判，每一种意见都要考虑才能更好地做到适度管理。
在质量管理方面，每次出台一项措施也会有不同的声音。这些措施包括检查、评审、测试和验收等，必然会给辛勤劳动的一线人员带来一些不便，给公司增加预防成本。但采取必要措施而增加适当的预防成本还是很有必要的，只是要遵守适度控制和具体问题具体分析的原则。当然质量管理不是监视，更不是对付坏人，而是针对工作中可能发生的错误。
为了进一步说明评审的必要性，我们引述美国著名的认知心理学家诺曼（Donald
A. Norman）先生在其《设计心理学》中的一段精辟的论述：“每一项新技术问世时，新一代的设计人员总会重蹈覆辙。从过去的错误中吸取经验教训不是技术人员的专长。他们总是展望未来，而不愿回顾历史，因此重复出现同样的错误。”（这个观点是不是有点打击技术人员，不知读者是否认同他的观点？技术人员可要争口气！）
中国人说：“人非圣贤，孰能无过。神仙打鼓，也会出错”。老外说：“It’s
a human error!”。所以人都可能有错，而且有些错误较容易逃过自己的眼睛。特别是有些人，比较容易看到别人的错误，却难以看到自己身上的错误。其原因不外乎思维定势（即思维习惯和心智模式等）、学识局限（没有谁是万能的），以及无意疏忽（老虎也有打盹时）。
Karl E.Wiegers在《软件同级评审》中说：“如果你没有时间采用同级评审来提高产品质量，则将需要更多的时间去纠正测试人员或客户发现的缺陷。……评审的最主要障碍来自开发人员没有意识到他们已经犯了多少错误，因此他们也看不到查找或减少错误的必要性。”
所以为了有效地提高软件质量，我们很有必要用他人的眼睛来审视自己。邀请不同背景的评审人员从不同的角度检查，弥补个人的不足，及时发现并解决自己发现不了的错误，即使是两次发现同一个错误总比把它漏掉好。需求与设计评审就是在进行下一步工作之前“互相用他人的眼睛来审视自己”，必然会提高项目的成本。而这种成本是质量成本的一部分——预防成本，其目的是减少失败成本（包括返工、维护、变更、重新测试、满意度下降、形象损坏，以及顾客流失造成的损失）。
评审的作用、目的和概念
在团队开发中，充分的沟通是非常有必要的，沟通的方式之一就是通过文档。不论评审的效果如何，发现多少问题都可以让相关人员了解需求与设计。而通过相互之间的讨论，澄清一些模糊的认识，进一步理解文档的含义。评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以利用企业内部各种优秀成员的智慧，为软件开发寻找最佳的解决方案。
评审的作用和目的主要是尽早发现潜在的问题，尽早纠正缺陷，控制纠正成本的滚雪球效应。本阶段造成的错误如果能够及时地发现，或者在后面越早的阶段发现，就能够及早发现潜在的风险，及时做好防范的对策，做到未雨绸缪。
评审的过程不仅是为了发现问题，而且为了便于跟踪及改正，还应当对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。正如著名软件大师Gerald
M Weinberg在《你的灯亮着吗？》所说：“一旦我们知道问题是什么，那么该问题的解答或解决对问题本身来说就是一件微不足道的事情。”
确实，人们经常会把一些表面的现象当成问题，而不知道根本的问题是什么？不知道真正的问题出在哪里？这样解决问题时就很有可能头痛医头，脚痛医脚。
具体来说，评审最直接的作用和目的当然是要改进需求与设计文档本身，为下一阶段工作提供正确的基础，并通过评审的过程提高相关人员的总体分析设计及文档写作水平。当然，写需求或设计等技术文档，并不等于会“做”需求分析和设计。因此有些刚参加工作的新手急于找一些模板或样例照葫芦画瓢，把文档完成就说“我会做分析”、“我会做设计”，其实只是刚起步而已。而评审不仅能够看出文档本身的问题和水平，也可以看出分析设计的过程和水平。
评审的作用和目的还在于强化开发人员的责任感，这是基于“把关效应”。即分配工作任务时，是否事先声明设置检查点，直接关系到工作任务完成的质量和效率。日本软件开发企业非常重视用验证与确认来强化开发人员的责任感。丰富行业业务经验和评审经验并改进评审流程，使项目进度安排更加合理也可以作为评审的作用和目的。当然，评审的最终目的无疑是提高软件质量，减少各种无形损失。
广义的评审概念包括走查、检查、正规检视、评审、评阅、审计、评估、结对编程、同级桌查、轮查及临时评审等，有时会出现同一个英语词汇翻译的不同。主要常用的概念如下：
- 走查（Walkthrough）：快速扫读。
- 检查（Inspection）：按照CheckList检查错误，也称为“正规检视”。
- 评审或复审（Review）：正式的研讨会。
- 审计（Audit）：审查预算、财务状况。
- 评阅：是一种文档检查形式，指检查人员各自检查并提出修改意见。但不做是否放行通过的评判，相当于“初审”。这个概念是用来与评审做一个区隔，这里的“评审”具有审批的责任，“评审者”相当于联合国常任理事国，具有否决权。而“评阅者”相当于联合国非常任理事国，可以提出自己的意见和建议，但不必说明文档是否批准通过。
评审是由项目阶段成果的作者以外的其他人来检查工作成果，发现问题，提出意见和建议，以达到改进质量的目的。本文以下所说的评审为“广义评审”指软件项目中评审的总体活动，而不具体考虑如何进行这些评审。另外，这里的评审不涉及审计、评估等含义。
需求与设计评审的特点
据不完全统计，软件项目在整个生命周期中按照不同阶段的划分，共有下列一些工作成果需要评审。
- 市场需求报告、可行性报告和立项报告。
- 标书、解决方案、承建合同和外包合同（协议）。
- 策划：项目计划、质量管理计划、配置管理计划、测试计划和风险计划。
- 需求：业务、系统和软件。
- 设计：概念、架构、概要和详细。
- 代码走查、单元测试和系统测试。
- 验收报告和总结报告。
当然上面的成果是可裁剪的，成果的评审也是可裁剪的。一些工作成果经过计划裁剪可以不需要产生，或不需要评审。
由于每种工作成果的评审特点与要求不但具有共性，又有特性，所以限于篇幅，我们只讨论需求与设计的评审。相对于项目中的其他评审而言，需求与设计的评审有以下特点：
- 需求与设计评审工作对项目成败至关重要，需求与设计的成果是软件质量的基础，也是软件开发项目成败的关键。
- 需求与设计评审工作既要考虑技术问题，也要考虑项目管理问题，对于研发类软件开发项目还要同时考虑市场问题。
- 需求与设计评审重点发现“战术方向”问题，“战术”是相对于前期的售前、销售、立项和策划所考虑的“战略”问题而言的；“方向”是相对于编码、测试的“按图索骥”而言的。售前、销售、立项和策划的评审是为了发现“战略方向”问题；编码、测试的评审是为了发现“战术实现”或“战术方法”问题。
需求与设计一方面具有继承性和限制性，另一方面也具有前瞻性和抽象性。所谓继承性，指需求与设计的成果必须继承前面各个阶段的工作成果，是前期工作成果按照一定规则与技术的进一步发展；所谓限制性，指需求与设计的成果也受到前期工作成果的各种约定的限制；所谓前瞻性，指需求与设计的成果还是一个中间的成果，在最终成果（软件系统）完成前，给人以外部特性和内部特性的前期描述；所谓抽象性，指需求与设计的成果不像已经完成的软件系统那样直观，那样给人可直接操作的感觉，它只是提供了一个基于纸面的测试机制。因此需求与设计的评审也要考虑继承性、限制性和前瞻性和抽象性。
当然，由于评审只是提供了一个基于纸面的测试机制，因此有些质量特性要求如果没有前期的经验是无法在评审中发现问题的，如某种设计方案的性能或可能的风险。如果企业内部没有人有这方面的经验，可能只有通过实践后才会了解。这是需求与设计文档评审的局限性，需要具备必要的经验或结合一定的试验。需求与设计评审与需求与设计本身一样，所需要的知识与经验和其他对象的评审也有所不同。所需要的知识与经验包括行业业务领域知识、软件工程的分析设计技术、建模和文档等表达技术，也不同程度地需要一些代码开发技术（包括开发语言、开发平台、开发环境和运行环境等）。 | 
