软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。笔者曾经历过以下的几种失败的需求评审：

　　案例一
　　某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副厂长提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。

　　案例二
　　某软件公司内部举行产品的需求评审会，主要是公司内部的领域专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。

　　案例三
　　某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。

　　案例四
　　某软件公司在用户处开完物资管理系统的需求评审会后，与会人员离开会议室时，纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。

　　案例五
　　某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。
　　以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是：
　　◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚；
　　◇ 没有作好前期准备工作，需求评审的效率很低；
　　◇ 需求评审的节奏无法控制；
　　◇ 找不到合格的评审员，与会的评审员无法提出深入的问题；
　　那么究竟如何做好需求评审呢？