需求验证是需求开发的最后一个环节，它也是一个质量控制点，其目标是发现尽可能多的错误，减少因为需求错误而带来的返工。而需求验证最主要的手段就是Review，但是许多需求团队都觉得需求验证比较容易变成形式，收效很少。本章的目的就是帮助大家缓解这个问题。
8.1 需求验证的主要手段
8.1.1 不同正式化程度的评审
8.1.1.1 前三种相对正式的评审方式。
8.1.1.2 后三种相对不正式的评审
》结对编程/结对分析
》同级桌查/轮查
桌查：两位需求人员之间交换文档产物，相互提出意见。
轮查：多位需求人员之间交叉交换文档产物，相互提出意见。
这些活动通常都是私下进行的，企业应该鼓励这种行为。
》临时评审
临时评审通常是个人的工作习惯，最常见最简单的临时评审就是在沟通过程中，由信息接收者进行简要的概括性的回顾，以达成共识。
8.1.2 审查过程概述
对于最正式最规范的审查而言，它有一个完整的过程，包括：规划，总体会议，做准备，审查会议，返工，追踪6个阶段。
8.1.2.1 规划
简单来说，就是规划内容，规划人员。
对于需求相关的评审而言，参加的人员包括：
》需求规格说明书的作者，同级伙伴。
》提供规格说明信息的人员：分析员，客户。
》要根据规格书展开工作的人，开发人员，测试人员等。
》负责相关接口工作的人。
对于需求相关的评审而言，主要的角色有：主持人，作者，评审员，记录员。一般来说，评审员不宜超过6个，否则容易使评审会过于发散。
规划内容，通常不建议一次性对整个需求规格说明进行评审，应该做适当的分解。将在8.2.1 需求验证的5大要点中进一步说明。
8.1.2.2 总体会议
在召开正式评审会议之前，召集参加会议的所有成员开一个简短的会议，讨论，明确要评审的内容，评审的要点，评审所需要的资料，缺陷检查表。
8.1.2.3 准备
评审会效果好不好，关键在于评审者是否提前做了阅读，准备。想让大家在现场提出有价值，完整的建议是很难的。因此，我们应该为评审者提供完整的资料，时间，给大家预先阅读，查找错误。
同时要求所有评审者将阅读时发现的文字，版面错误直接发给作者，不要让这些东西浪费评审会议的时间。
8.1.2.4 审查会议
准备阶段的目标是发现问题，审查会议的目标就是暴露问题，讨论问题，大家对预先找到的问题逐一讨论，得出结论。
8.1.2.5 返工
只有审查没有返工，那么必然将评审变成形式主义，这是对评审活动最具破坏力的因素。建议在每次评审会后，由作者对每个意见汇总，发给所有评审员，并感谢每一位评审员做出的贡献。
8.1.2.6 跟踪
这一步是评审活动中最容易忽略的。
8.2 需求验证的主要误区与解决方案
8.2.1 5大要点
8.2.1.1 思想
Review被翻译成评审，导致存在着评价的意味，实际上Review更多是指复查，是发现问题。
8.2.1.2 方法
在企业中推行即时评审，桌查/轮查等正式化不高的评审手段，是创建企业评审文化的有效手段。
8.2.1.3 语言
在需求评审会中，应该以建议者，协作者的身份与作者对话，而不是评价者。
8.2.1.4 人员
选择合适的参与人员也很重要，要点在于合适，而不是越多越好。
8.2.1.5 内容
》压缩缺陷检查表
对于标准来说，该检查的东西是很多的，但是对于具体的项目，团队而言，不同检查项的意义是不同的。因此缺陷检查表应该进行裁剪，尽量控制在9条以内。
》压缩需求文档
可以通过分多次评审会，可以通过将需求文档按层次或问题与拆分等方式。
8.2.2 需求验证常见的5大问题
8.2.2.1 评审会时，上面开大会，下面开小会
》现象描述，评审会时，常常交头接耳，讨论一些与评审无关的内容。
》解决建议，按照评审关注的内容进行拆分，与其大家一起讨论，不如分主题，分场次，分人员进行周期更短的评审会。
8.2.2.2 评审会成了审判会
》现象描述，在评审会上大家对作者提出过多批评，做出一些负面评价。
》出现原因，作者可能资历较浅，评审者将自己作为评价者的身份，而不是协作者。
》解决建议，评审者需要转换为协作者的角色。
8.2.2.3 评审会成了吵架会
》现象描述，各个干系人之间可能就批评，负面评价等，产生争执。
》出现原因，干系人之间沟通语气教生硬，作者可能资历较浅。
》解决建议，评审者需要转换为协作者的角色，大家要改进语气。
8.2.2.4 评审会成了语法纠错会
》现象描述，在评审会中，很多错误都是这个字写错了，这个词用的不好，这个段落没有缩进，这里有版面错误等。最终暴露的都是琐碎，无价值的细节。
》出现原因，原因有两方面，一是好人主义，评审者心想如果提出一些真的问题，可能作者面子上过不去，所以不谈大问题，只说小问题。二是准备不足，评审者之前没有阅读，轮到他提出建议时，只能现场寻找一些表面上的问题。
》解决建议，好人主义我们通过避免管理者参加，创建企业评审文化两个方面的努力可以缓解。而准备不足，则需要一些策略来解决。可以要求评审者提前提交评审意见文档，如果没有提交则不允许参与评审会议。
8.2.2.5 评审会成了翻书会
》现象描述，在评审会中，提出的问题根本不按页码顺序，一会翻到20页，一会翻到10页。
》出现原因，出现这种现象的原因显然是主持人准备不足，临时让大家的思路随意展开，导致组织不利，影响评审结果。
》解决建议，会议前主持人需要汇总评审意见，按页码顺序进行排列，然后在会议上逐一解决，每过一页还可以停下，让大家现场补充一些意见。