软件需求分析评审之道.pdfVIP

软件需求评审之道 任甲林 j lren@c( ) 希赛网原创 摘要 本文介绍了软件需求评审失败的 5 个案例，提出对软件需求评审的实践具有指导意义的 9 个建议。 关键词 需求评审，需求层次，阶段评审，检查单，评审流程 软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一 个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最 难的一个，也是最容易被忽视的一个评审。笔者曾经历过以下的几种失败的需求评审： 案例一： 某领域专家 A 先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始 时间不长，就被在场的企业的一位副总B 先生打断，认为 A 先生提出的方案不适合本企业， A 先生提出的管理改进方案在企业中无法实施。该副厂长提完意见后，与会的用户方人员纷 纷跟随 B 先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否 决。 案例二： 某软件公司内部举行产品的需求评审会，主要是公司内部的领域专家参加，在评审会开 始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会 人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持 人无法控制局面，会议大大超出了计划评审时间。 案例三： 某软件公司为某公司 A 做业务流程管理系统的需求评审会，当项目组人员在会议上宣读 多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。 案例四： 某软件公司在用户处开完物资管理系统的需求评审会后，与会人员离开会议室时，纷纷 摇头，认为本次会议没有多少实际效果，完全是在走过场。 案例五： 某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策 划人员的想法差别很大，致使需求评审会没有必要继续进行下去。 以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是： 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚； 没有作好前期准备工作，需求评审的效率很低； 需求评审的节奏无法控制； 找不到合格的评审员，与会的评审员无法提出深入的问题； …… 那么究竟如何做好需求评审呢？ 建议一：分层次评审 我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次： 目标性需求：定义了整个系统需要达到的目标； 功能性需求：定义了整个系统必须完成的任务； 操作性需求：定义了完成每个任务的具体的人机交互； 目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注 的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别 的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易 地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求， 无疑是一种资源的浪费或者就会出现案例三的情形。 建议二：正式评审与非正式评审结合 正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起， 并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有 这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签 甚至是网络聊天等多种形式对需求进行评审。2 种形式各有利弊，但往往非正式的评审比正 式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这 2 种方式。 建议三：分阶段评审 应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分 阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风 险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概 要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再 对整体的需求进行评审。 建议四