典型方案是指软件开发的一般方案，本文选择分析如下。
1 .传统瀑布模型开发中的需求回顾
使用IEEE Std. 1028进行需求审查
3 .敏捷开发中的需求评审
传统瀑布模型下的需求评审传统瀑布模型现有需求评审分析传统瀑布模型在需求阶段末期安排了重要需求里程碑的评审，其特点见2.8节情况1。 在行业实际运行中，经常会出现以下情况。
1 )召集包括领导在内的各方代表，经过1~2小时的会议，审核30页以上的需求规格书，由不同场合的各方签字后审核通过；
2、各方对需求规格书意见不一，经过3~n次发审会，工期明显滞后，后续开发跟进，开发快完成，总算通过了
3 )经过多方规划和协调，前后花了四个多星期，把各个方面召集到一个度假村，经过三天的讨论和审视，终于通过了审查。
以上内容，体现了前文的“zxdyz繁杂、繁文缛节”，其弊端显而易见。 [26]文中也同样认识到，需求审查往往倾向于形式。
受CMM/CMMI的要求和启发，需求同行评审使用了[12][13]，以确保需求阶段最后一个里程碑的评审顺利通过。 一般情况如下。
1 )需要完稿时，安排同行评审会议，关注技术层面，形成同行评审的发现和记录。 这有助于战胜里程碑审查，但往往是为了应对CMM/CMMI的评估
2 )分阶段安排多次会议或非即时需求同行评审，关注技术层面，记录并解决评审发现。 这是CMM/CMMI推荐的做法，可以大大缓解瀑布型需求阶段里程碑评审的弊端。
综合以上分析，为了便于整体理解，必须得到下表。
表8瀑布模型下的需求审核情况
对标准评审需求评审框架的分析表明，需求里程碑评审包括预审会议形式、里程碑、技术和管理方面，非同行文件评审需求同行评审包括预审会议形式、完稿、 技术层面对同行文献评审的阶段性需求同行评审包括事前评审的会议形式、阶段性、技术层面对同行文献评审新需求评审框架传统瀑布模式的启示启示1：值得开展定期的双人即时评审，每次时间约1530分钟，适合位置坐在一起的团队同伴。好处：尽早交流，彼此学习。
启示2：值得把技术方面评审与管理方面评审分开，先进行各种类型的技术方面评审，然后召开里程碑管理方面评审。好处：技术方面评审问题解决后，需求阶段里程碑评审着重于管理方面，比如需求规模、进度、工作量等等，更加关注项目整体成功，也能大大节约会议时间。
将IEEE Std. 1028的需求审查与需求审查进行比较，可以将IEEE Std. 1028的管理审查、技术审查、审查和浏览应用于需求审查，但其中的审计不在本文讨论的需求审查范围之内
管理评审IEEE Std. 1028说明管理评审(Management Reviews )用于监控进度、确定计划和时间安排的状态，以及评估实现相应目标的管理方法的有效性管理评审支持有关纠正措施、资源分配变更或项目范围变更的决定； 识别管理审查和计划的一致性和差异，或者识别管理流程的完善程度和不足程度。 在需求管理评审实践中，最关注的问题是需求范围和规模是否与计划相符。 一些组织在需求前制定了计划，但需求的实际结果是否需要重新计划； 有些组织将项目总体计划的制定放在需求之后。 那么，有必要判断前期的进展如何，对之后制定计划有什么影响。
审核管理有详细的规范，包括角色、会议前、会议期间、会议后、输入和输出。 虽然IEEE Std.1028中首先提到的审核类型绝不是虚名，而是沉重而繁琐的问题，但对于谨慎的多方利益相关者来说，这仍然是重要里程碑审核的首选，也是必需的审核类型。 在这一五维需求评审的框架内，管理评审往往在具有预先审核的会议形式里程碑性质的管理方面提供了最系统的“极”，而不是同级需求文档评审。
技术评审的技术评审目的是由合格人员组成的团队评估软件产品，以确定其是否适合预期用途，并识别规范和标准之间的差异。 向管理层提供证据证实该项目的技术状态，或提供备选方案建议。 此外，可能需要多次会议。
和管理评审一样，技术评审有详细的规范。 技术评审是最广为人知的评审类型，1996年出版的《实用软件工程》 (第2版) )也有详细论述。 实践中技术审查是里程碑审查的重中之重，而对于管理审查，其关注的内容只是技术审查的一小部分，专业管理审查已经消失。 在这一五维需求评审框架中，技术评审往往是一种具有预审会议里程碑性质的技术非同行需求文档评审，提供了技术评审最系统的“极”。
启示3：理解管理评审和技术评审在五维需求评审框架中的位置，在实际工作中灵活应用这两项评审，更加有把握的对其进行适应性的剪裁，使其发挥更高效率，尽量规避为人诟病的沉重繁琐的弊端。
应对审查的英语是Inspection，其目的是检测和识别软件产品的异常。 审查是有系统的同行检查。 审查定义了五个角色，分别是审查指导者、记录员、观众、作者、审查员。 包括上述五个角色在内的审查组成员高级人员不能参加审查活动。 审查应得到计划并记录在适当的项目计划文件中。 审核开始前需确认被审核产物完整且符合格式要求，审核后需记录审核产物规模、会议期间会议情况
前时间、返工时间等等。点评：审查在IEEE Std. 1028得到了严格定义，给出了详尽的规范指导。在本五维需求评审框架中，审查属于有预审的会议形式完稿技术方面同级评审，同样是同级评审最系统性的“极点”。 审查要求完整产物，并不能尽早发现问题。
启示4：值得探索和使用更轻量更高效更及时的需求同级评审。 走查
系统性的走查目的是为了评估一个软件产品。走查可能也会有让培训软件产品受众的目的。走查的作用还有交流技术、交流不同风格变化。 走查不仅可以发现异常，也可以指出不足之处（例如，软件产品的效率和可读性问题，设计或代码的模块化问题，或无法验证的规格）。参与走查有4个角色，分别是走查组长、记录者、作者、走查成员，走查至少需要2人。任何走查组成员的行政上级都不能参加走查。走查的最主要活动是作者或走查组长详细的展现所评审产物的每个部分，走查组识别并提出发现的异常和问题。走查的标准最少输出物总计有9项。走查不要求产物已经全部完成，可以按需高频开展。
在本五维需求评审框架中，走查属于有预审的双人即时或者会议形式、技术方面的定期或高频的同级需求文档评审。双人走查是标准允许的最少人数。双人走查与会议形式走查其实存在较大的差异：双人走查可以使用一台普通显示器，利用普通能够坐下两人的工作位置即可，这样就能够高频按需开展，会议形式往往需要会议室，而会议室在多数组织是稀缺资源，如果所有项目团队都开展需求和代码会议走查，那么每二周一次的会议室预订都未必能够保证，所以难以按需开展。代码走查是常听到的词汇，但是需求走查在中文世界很少提到，而在敏捷软件开发中已经显示了其有效性。
启示5：值得探索和使用双人高频按需的需求走查或者简化的需求走查。
综合以上分析，为便于整体理解，得下表。
表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建议1个月的迭代情况下，计划会议第一部分约需要4小时，占比约2.3%，整个计划会议需要8小时。
每日 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中补充了发布计划和发布燃尽图，但并没有明确定义如何评审或校验，因此值得开展关注整体产品更长时间范围发展的定期管理评审会议。