典型情境是指软件开发的常见情境，本文选择如下来进行分析：

1. 传统瀑布模型开发下的需求评审

2. 使用IEEE Std. 1028的需求评审

3. 敏捷开发下的需求评审

传统瀑布模型下的需求评审

对传统瀑布模型现有需求评审的分析

传统瀑布模型在需求阶段末期安排有关键的需求里程碑评审，其特征参见2.8节情况1。在业界实际操作中，往往出现如下情况：

1，召集包括领导在内的各方代表，历经1～2小时会议，评审30页以上需求规格说明书，走过场式各方签字通过评审；

2，各方对需求规格书有各种各样意见，历经3～n次评审会，眼看工期已经有明显拖延，后续开发已经跟进，甚至开发快完成了，总算获得通过；

3，经过多方运筹协调，前后费时4周多，召集各方到某度假村，历经三天讨论修改评审，总算通过评审。

以上情况就体现了前文所言的“官僚繁琐、繁文缛节”，其弊端明显。在[26]文同样也识别到：需求评审往往流于形式。

受CMM/CMMI要求和启发，为了让需求阶段最后的里程碑评审能够顺利通过，需求同级评审得到了使用[12][13]。常见有如下情况：

1，在需求完稿时，计划一次同级评审会议，关注于技术方面，形成同级评审发现和记录。这对胜利通过里程碑评审有很大帮助，但往往是更为了应付CMM/CMMI的评估；

2，分阶段安排多次会议或非即时的需求同级评审，关注技术方面，记录评审发现并解决。这是CMM/CMMI比较推荐的做法，能大大缓解瀑布型需求阶段里程碑评审的弊端。

综合以上分析，为便于整体理解，得下表。

表8 瀑布模型下需求评审情况

新需求评审框架对传统瀑布模型的启示

启示1：值得开展定期的双人即时评审，每次时间约15～30分钟，适合位置坐在一起的团队同伴。好处：尽早交流，彼此学习。

启示2：值得把技术方面评审与管理方面评审分开，先进行各种类型的技术方面评审，然后召开里程碑管理方面评审。好处：技术方面评审问题解决后，需求阶段里程碑评审着重于管理方面，比如需求规模、进度、工作量等等，更加关注项目整体成功，也能大大节约会议时间。

使用IEEE Std. 1028的需求评审

对照到需求评审，IEEE Std. 1028中的管理评审、技术评审、审查和走查可以适用于需求评审，而其中的审计不属于本文所讨论的需求评审范畴。

管理评审

IEEE Std. 1028说明管理评审（Management Reviews)用于监测进展情况，判断计划和进度表的状态，或评估为了达成合适目标的管理方法的有效性；管理评审支持关于纠正措施、资源分配变更或者项目范围变更的决策；管理评审识别与计划的一致性和差异，或者识别管理流程的完善度和不足度。在需求管理评审的实践中，最焦点问题是需求范围和规模是否与计划相匹配。有些组织在需求之前制定了计划，那么需求实际的结果是否需要重新计划；有些组织把项目整体计划的制定安排在需求之后，那么需要判断前期进展如何，对后面制定计划有什么影响。

管理评审有详尽的规范，从角色、会前、会中、会后、到输入和输出等等。它成为IEEE Std.1028首先阐述的评审类型绝非徒有虚名，虽然它有沉重繁琐的嫌疑，但对于谨慎多干系人场合，仍然是关键里程碑评审的首选甚至是必须的评审类型。在本五维需求评审框架中，管理评审在绝大多数情况下属于有预审的会议形式里程碑性质的管理方面非同级需求文档评审，它提供了管理方面评审的最系统性的“极点”。

技术评审

技术评审的目的是由合格人员组成的团队来评价一个软件产物，以判断是否适合其预期用途，并识别对比于规范和标准的差异。它为管理层提供证实该项目技术状态的证据，也可能提供替代方案建议，可能需要一个以上的会议。

同管理评审一样，技术评审有详尽的规范。技术评审是最广为人知的一个评审类型，早在1996年出版的《实用软件工程》（第2版）[9]对此也有详细的阐述。在实践中技术评审常常担当里程碑评审的重任，而至于管理评审，其关注内容成为技术评审的一小部分，而不再有专门的管理评审。在本五维需求评审框架中，技术评审在绝大多数情况下属于有预审的会议形式里程碑性质的技术方面非同级需求文档评审，它提供了技术方面评审的最系统性的“极点”。

启示3：理解管理评审和技术评审在五维需求评审框架中的位置，在实际工作中灵活应用这两项评审，更加有把握的对其进行适应性的剪裁，使其发挥更高效率，尽量规避为人诟病的沉重繁琐的弊端。

审查

审查对应的英文是Inspection，其目的是检测和识别软件产品的异常情况。审查是一个系统性的同级检查。审查定义了5个角色，分别是审查领导者、记录员、阅读者、作者、审查员。任何审查组成员（包括以上5个角色）的上级都不能参加审查活动。审查应当得到计划并记录在恰当的项目计划文档中，审查开始前需要确认被审查产物是完整的并且符合格式要求，审查后需要记录评审产物的规模、会中会前时间、返工时间等等。

点评：审查在IEEE Std. 1028得到了严格定义，给出了详尽的规范指导。在本五维需求评审框架中，审查属于有预审的会议形式完稿技术方面同级评审，同样是同级评审最系统性的“极点”。 审查要求完整产物，并不能尽早发现问题。

启示4：值得探索和使用更轻量更高效更及时的需求同级评审。

走查

系统性的走查目的是为了评估一个软件产品。走查可能也会有让培训软件产品受众的目的。走查的作用还有交流技术、交流不同风格变化。 走查不仅可以发现异常，也可以指出不足之处（例如，软件产品的效率和可读性问题，设计或代码的模块化问题，或无法验证的规格）。参与走查有4个角色，分别是走查组长、记录者、作者、走查成员，走查至少需要2人。任何走查组成员的行政上级都不能参加走查。走查的最主要活动是作者或走查组长详细的展现所评审产物的每个部分，走查组识别并提出发现的异常和问题。走查的标准最少输出物总计有9项。走查不要求产物已经全部完成，可以按需高频开展。

在本五维需求评审框架中，走查属于有预审的双人即时或者会议形式、技术方面的定期或高频的同级需求文档评审。双人走查是标准允许的最少人数。双人走查与会议形式走查其实存在较大的差异：双人走查可以使用一台普通显示器，利用普通能够坐下两人的工作位置即可，这样就能够高频按需开展，会议形式往往需要会议室，而会议室在多数组织是稀缺资源，如果所有项目团队都开展需求和代码会议走查，那么每二周一次的会议室预订都未必能够保证，所以难以按需开展。代码走查是常听到的词汇，但是需求走查在中文世界很少提到，而在敏捷软件开发中已经显示了其有效性。

启示5：值得探索和使用双人高频按需的需求走查或者简化的需求走查。

IEEE评审小计

综合以上分析，为便于整体理解，得下表。

表9 IEEE标准需求评审情况

敏捷开发下的需求评审

首先要说明，在敏捷开发语境中，几乎不使用“评审”这词，常用“验证”、“验收”、“反馈”等。本文将基于文档阅读或者观察软件运行的时效性人工检查工作定义为评审，符合此定义的敏捷实践也被视为评审。下文将选取敏捷中典型的需求评审对应实践来分析。由于Scrum是目前采纳最多的敏捷流派，选择了多个来自于Scrum的实践来分析，也兼顾了其它敏捷流派。

产品待办列表的优化

Scrum中，产品负责人（英文：Product Owner，缩写PO)是管理产品待办列表的唯一责任人[28]。虽然理论上产品负责人可以一个人单独创建维护产品待办列表的全部内容，但多数情况下产品负责人是吸收他人贡献的，产品负责人然后进行整理排序调整优化等等[21]。Scrum中的产品待办列表优化（Scrum Guide 2011版中其英文名是Grooming，Scrum Guide2013版中其英文名是refinement）指的是为列表项补充细节、估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品待办列表项的细节，并对列表项进行评审和修改。对照到本五维需求评审框架，这是定期会议的、技术方面的同级需求文档评审。因为这个过程中就算产品负责人是团队的行政上级，也是评审对象的主要作者，而不是评审者。

一般的，产品待办列表细化的结果用于未来的迭代（Scrum中称为冲刺），其起到的作用相当于瀑布模型中需求阶段的技术方面评审，但耐人寻味的是Scrum Guide说“细化的工作通常占用开发团队不超过10%的时间。然而，产品负责人可以根据自己的判断随时更新产品待办列表。”，而对于只有1～2次需求评审的传统瀑布模型而言，需求讨论评审会议所占比例恐怕不超过5%。

Scrum计划会议第一部分

Scrum中的计划会议第一部分的问题是：接下来的冲刺（等同于迭代）交付的增量中要包含什么内容?开发团队预计这个冲刺中要开发的功能。产品负责人讲解冲刺的目标以及达成该目标所需要完成的产品待办列表项。整个Scrum 团队为了更好地了解冲刺的工作进行讨论。对照到新需求评审框架，这是定期会议侧重于管理方面的同级需求文档评审，与上述产品待办列表细化同样是同级评审。

负责需求的产品负责人与团队一起交流，听取处理各种各样意见建议，在管理评审中反而是被评审的对象，这确实是对传统做法的大突破，而Scrum的流行也说明了这新做法的有效性。对比到瀑布模型，Scrum中的计划会议第一部分起到的作用相当于瀑布模型中需求阶段的里程碑管理方面评审。值得注意的是，Scrum建议1个月的迭代情况下，计划会议第一部分约需要4小时，占比约2.3%，整个计划会议需要8小时。

Scrum每日站会和燃尽图绘制

每日 Scrum 站会是以 15 分钟为限的事件，开发团队成员在这里分享各自的工作情况，并为接下来的 24小时制定计划。这需要检视上个每日站会以来的工作和预测下个每日站会之前所能完成的工作[28]。一般的，Scrum团队每天绘制冲刺燃尽图，在冲刺中每日绘制本冲刺未来剩余的工作量，而此工作量是根据用户故事或者用例来预测估计的，用户故事和用例都是需求表达的形式。所以这也相当于需求管理评审，具体对应到新五维需求评审框架，这是会议形式高频管理方面同级需求文档评审。

敏捷开发过程中需求的澄清和确认

在敏捷开发环境下，由于不要求在开始时就有一份完整详细的需求说明，所以在开发过程中就需要诸如现场客户或客户代表来澄清和确认需求。这是各敏捷流派共有的实践。敏捷方法鼓励面对面的交流，所以开发过程中对需求的澄清和确认往往采用桌查，这其实也是一种需求评审的形态，对照到新需求评审框架，这是双人结对即时高频技术方面同级评审，而且不再仅仅基于需求文档，还可以基于软件运行来判断需求是否得到满足，虽然也许不能完全运行，但能够部分运行，能够展现界面或接口。在Scrum中，产品负责人承担响应此类评审（澄清解释并按需要修改补充）的责任，这个过程中，就算产品负责人是团队成员的行政上级，也是按同级的身份参与。

这同样是最高效率的需求评审类型之一，最高效特征有交流反馈快，颗粒度小，针对性强，甚至可结合半成品或者成品来核对。

启示6：需求分析人员和开发人员值得在开发过程中，结合半成品或者成品进行需求桌查，能够更早更快的避免需求理解偏差带来的缺陷。

迭代展示

迭代展示是各敏捷流派共有的实践，常见的做法是在迭代末期向各方干系人展示迭代的成果，甚至直接交付给用户试用或使用。Scrum对此环节有清晰的定义，即是其冲刺（等同于迭代）评审会议：冲刺评审会议在冲刺结束时举行，用以检视所交付的产品增量并按需调整产品待办列表；在冲刺评审会议中，Scrum 团队和相关干系人讨论冲刺中完成的工作；然后，根据完成情况和冲刺期间产品待办列表的变化，与参会人员讨论接下来可能要做的事情来优化价值[28]。值得说明的是对于典型一个月的冲刺，其冲刺评审会议的时间箱是4小时。冲刺评审会议可以算作为需求评审和给客户展示演化的原型[21]。对照到新五维需求评审框架，这是无预审的会议形式、定期的、侧重于管理方面也兼顾技术方面、基于软件运行的非同级评审。

这样的评审也是最高效率的需求评审类型之一，其高效特征有需求以直观运行方式展现，客户或者客户代表参加，当场收集反馈，当场根据反馈来计划未来。

启示7：让客户或者客户代表定期结合软件运行来进行评审，更加直观更能发现改进，可以让客户更加满意。

敏捷需求评审小结

综合以上分析，为便于整体理解，得下表。

表10 敏捷开发下常见需求评审相关实践情况

可以看到，敏捷软件开发常见的需求评审竟然没有采纳任何一种标准评审，顶多可以说对审查和走查有所借鉴。

启示8：为了更高效且更高质量的开发软件，敢于突破原有需求评审标准和权威指南，敢于寻求更高效率的需求评审方式方法。

启示9：根据启示8，结合此新五维需求评审框架，结对定期需求文档或软件运行管理评审是值得推荐的新评审方式。具体是指管理者每几天或每周或每双周与开发人员结对来评审需求相应的状态、进度、困难和风险，具体形式可以采用师徒制、主程序员制[29]、一对一会议等等。

启示10：根据启示8，结合此新五维需求评审框架，非即时按需高频需求文档技术方面同级评审也是值得推荐的新评审方式。结合需求条目化管理工具，可以实现逐个需求的同级评审。下文第4章有更详尽分析。

启示11：根据启示8，突破此五维需求评审框架，值得寻求其它更高效更人性化的需求评审方式，比如将游戏做法、积分升级等等引入到评审中。

新需求评审框架对敏捷方法的启示

启示12：Scrum对于管理评审的应用是关注于当前和下个迭代，缺失对整体更长过程的关注。虽然已经有在Scrum中补充了发布计划和发布燃尽图，但并没有明确定义如何评审或校验，因此值得开展关注整体产品更长时间范围发展的定期管理评审会议。