正式技术复审（FTR，Formal Technical Review）是一种由软件开发人员进行的软件质量保证活动，其目的是：
　　（1） 在软件的任何一种表示形式中发现功能、逻辑或实现的错误；
　　（2） 验证经过复审的软件确实满足需求；
　　（3） 保证软件符合预定义的标准；
　　（4） 使软件按照一致的方式开发；
　　（5） 使项目更易于管理。
　　此外，FTR还起到了提高项目的连续性和培训后备人员的作用。FTR包括走查（Walkthrough）、审查（Inspection）、循环评审（Round-robin Review）以及其他软件小组的技术评估。每次FTR都以会议形式进行，只有经过适当的计划、控制和参与，FTR才能获得成功。

评审会议
　　不论FTR是何种形式，每次评审会议应该遵守以下规定：
　　（1） 会议应该在3~5人之间进行；
　　（2） 会前应做好准备，但是每人准备时间应少于2小时；
　　（3） 会议时间不应超过2小时。
　　因此，FTR应该关注的是整个软件中的某个特定的较小部分。评审会议由评审负责人主持，所有评审人员和开发人员参加，其中有一个记录员负责记录评审过程中发现的所有重要问题。FTR会议从介绍日程开始，由开发人员进行简单介绍，然后开发人员将遍历其工作产品，进行解释，评审人员根据各自的准备提出问题。在发现问题或错误时，记录员逐一加以记录。评审结束时，所有参会人员必须作出决定：
　　（1） 工作产品可以不经修改而被接受；
　　（2） 由于严重错误而否决工作产品，改正错误后必须再次进行评审；
　　（3） 暂时接受工作产品，即发现必须改正的微小错误，但不再需要进一步评审。
　　作出决定后，所有FTR参会者需要签字，表明参加了此次评审会议并同意评审小组所做的决定。

评审指南
　　进行正式技术复审之前必须建立评审指南，分发给所有评审人员，并得到大家的认可，然后依照它进行评审。以下列出最基本的正式技术复审指南：

　　（1） 评审产品，而不是评审开发人员；
　　FTR涉及到别人和自我。如果进行得合适，FTR可以使所有参会人员体会到成就感，否则可能陷入一种审问的气氛之中。评审负责人应该引导评审会议，会议的气氛应该是轻松的和建设性的，不要试图贬低或羞辱别人。

　　（2） 制定日程，并且遵守日程；
　　各种类型的会议都有"放任自流"的缺点，FTR必须保证不要离题并按照计划进行。评审负责人应该维持会议程序，在讨论失去控制时应进行提醒。

　　（3） 限制争论和辩驳；
　　在评审人员提出问题时，未必所有人都认同该问题的严重性。不要花时间争论这一个问题，这时应该记录下这个问题，会后再进一步讨论。

　　（4） 对各个问题都发表见解，但是不要试图解决所有记录的问题；
　　评审不是问题解决会议，问题的解决应该放在评审会议之后进行，通常由开发人员自己或在别人的帮助下完成。

　　（5） 作书面笔记；
　　有时候将记录员在黑板上做笔记是一个好主意，这样其他参会人员可以推敲措辞，并确定问题的优先次序。

　　（6） 限制参会人数，并坚持事先准备；
　　两个人的脑袋比一个强，但14个脑袋未必强过4个。将评审人员的数量保持在最小的必需值上，并且所有的评审组成员都必须事先作好准备。

　　（7） 为每个可能要评审的工作产品建立一个检查表；
　　检查表能够帮助评审负责人组织会议，并帮助每个评审人员将注意力集中在重要问题上，应该对分析、设计、编码、甚至测试文档都建立检查表。

　　（8） 为FTR分配资源和时间；
　　为了让评审有效，应该将评审作为软件工程过程中的任务加以调度，而且要为由评审结果带来的修改分配时间。

　　（9） 对所有评审人员进行有意义的培训；
　　为了提高效率，所有评审人员都应该接受某种正式培训，培训要强调的不仅有与过程相关的问题，而且应该涉及评审的心理学因素。

　　（10） 评审以前所有的评审。
　　听取汇报对发现评审过程本身的问题十分有益，最早被评审的工作产品本身可能就会成为评审的指南。