需求评审五个维度框架分析及其带来的启示-3-典型需求评审

典型情境是指软件开发的常见情境，本文选择如下来进行分析：
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中的管理评审、技术评审、审查和走查可以适用于需求评审，而其中的审计不属于本文所讨论的需求评审范畴。