软件需求评审之五个案例和九条建议[1]

来源:百度文库 编辑:神马文学网 时间:2024/03/29 00:02:13
软件需求评审之五个案例和九条建议[1]
http://www.csai.cn  作者:不详  来源:网络  2007年2月13日
软件需求是软件开发的最重要的一个输入,需求风险也常常是软件开发过程中最大的一个风险,降低需求风险的一个重要手段就是需求评审,但是需求评审是所有的评审活动中最难的一个,也是最容易被忽视的一个评审。笔者曾经历过以下的几种失败的需求评审:
案例一
某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作,在评审会开始时间不长,就被在场的某企业的一位副总B先生打断,认为A先生提出的方案不适合本企业,A先生提出的管理改进方案在企业中无法实施。该副总提完意见后,与会的用户方人员纷纷跟随B先生的提出了他们的反对意见,致使评审会无法再进行下去,最终该报告被用户否决。
案例二
某软件公司内部举行产品的需求评审会,主要是公司内部的相关领域的专家参加,在评审会开始后不久,某领域专家就对需求报告中的某个具体问题提出了自己的不同意见,于是,与会人员纷纷就该问题发表自己的意见,大家争执不下,结果,致使会议出现了混乱状况,主持人无法控制局面,会议大大超出了计划评审时间。
案例三
某软件公司为某公司A做业务流程管理系统的需求评审会,当项目组人员在会议上宣读多达上百页的需求报告时,用户明确提出听不懂,致使会议不得不改日进行。
案例四
某软件公司在用户处开完物资管理系统的需求评审会后,与会人员在离开会议室时纷纷摇头,认为本次会议没有多少实际效果,完全是在走过场。
案例五
某软件公司在公司内部举行产品的需求评审会时,需求报告的执笔人与产品策划的主要策划人员的想法差别很大,致使需求评审会没有必要继续进行下去。
以上的现象可以在很多项目中都可以看到。概括起来,在需求评审中常见的问题是:
◇ 需求报告很长,短时间内评审者根本就不能把需求报告读懂、想清楚;
◇ 没有作好前期准备工作,需求评审的效率很低;
◇ 需求评审的节奏无法控制;
◇ 找不到合格的评审员,与会的评审员无法提出深入的问题;
……
那么究竟如何做好需求评审呢?