摘要

　　本文介绍了软件需求评审失败的5个案例，提出对软件需求评审的实践具有指导意义的9个建议。

　　关键词

　　需求评审，需求层次，阶段评审，检查单，评审流程

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

　　案例一

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

　　案例二

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

　　案例三

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

　　案例四

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

　　案例五

　　某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。

　　以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是：

　　◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚；

　　◇ 没有作好前期准备工作，需求评审的效率很低；

　　◇ 需求评审的节奏无法控制；

　　◇ 找不到合格的评审员，与会的评审员无法提出深入的问题；

　　……

　　那么究竟如何做好需求评审呢？

　　建议一：分层次评审

　　我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：

　　目标性需求：定义了整个系统需要达到的目标；

　　功能性需求：定义了整个系统必须完成的任务；

　　操作性需求：定义了完成每个任务的具体的人机交互；

　　目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。

　　建议二：正式评审与非正式评审结合

　　正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这 2种方式。