软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。笔者曾经历过以下的几种失败的需求评审： 案例一
某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。 案例二
某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。 案例三
某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。 案例四
某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。 案例五
某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。
以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是： ◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚； ◇ 没有作好前期准备工作，需求评审的效率很低； ◇ 需求评审的节奏无法控制；
◇ 找不到合格的评审员，与会的评审员无法提出深入的问题； ……
那么究竟如何做好需求评审呢？ 建议一：分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次： 目标性需求：定义了整个系统需要达到的目标； 功能性需求：定义了整个系统必须完成的任务；
操作性需求：定义了完成每个任务的具体的人机交互； 目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。 建议二：正式评审与非正式评审结合
正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签
1
甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这两种方式。 建议三：分阶段评审
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。
建议四：精心挑选评审员
需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。 建议五：对评审员进行培训 在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。
建议六：充分利用需求评审检查单 需求检查单是很好的评审工具，需求检查单可以分成两类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。 建议七：建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。
建议八：做好评审后的跟踪工作 在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
建议九：充分准备评审
2
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
在实践中细心体会、实施上述的9个建议，相信您定会受益非浅。
3
案例正文：一个项目经理在开发一个为期10个月的项目的三个星期后得到客户通知，项目要在不增加成本，不影响范围和质量的情况下，需要在8个月内完成，项目经理应该怎么做？
分析：一、了解客户计划改变的真实原因
在做项目的很多时候，客户方会要求项目在不增加成本，不影响范围和质量的情况下，提前完成，但是一定有他的理由，也许是你的竞争对手采取的措施，也许是我们在做项目的时候有哪些不对的地方，或者是客户遇到新的其他情况不等，但是在客户提出之后，不能明确的答应也不能以强势的态度拒绝，等了解真正的原因后再做打算。 二、向客户沟通
假如必须提前完成任务，要向客户说明其困难，假如公司真的有实力，那就答应他，并适当的拿出合同进行说明，是否在其他方面给予公司补偿。
如果公司的把握不是很大，那就站在客户的立场为他考虑，本来十天完成的任务现在8天完成，困难时什么，结果会怎么样，是否采取，按照客户的要求完成部分功能，比如为了迎接上级领导检查，那就把系统的表面工作都做好，要是真正的使用的话，那就把不影响工作进行的部分往后推迟等等，一个项目实施后，所有功能在一定的时间都能使用上的几率不是很大，另外也可以采用在主要功能方面做好，次要方面稍往后放等等方法。 三、从公司本身出发
在不影响范围和质量的情况下，提前完成，我们只有在加班或加人中选择，但是一定要谨慎，因为加人是存在一定的风险的，毕竟项目已经进行了3个月。假如公司实在没有办法的话，那就把部分较独立的功能模块外包出去，当然这是下下策了。 四、团队的管理 在这个时候，一定要在团队的管理方面做好工作，无论从人员的到位，还是人员的情绪，或者其他方面等等做到恰到好处。
4
Clearnet公司是国外一家知名的IP电话设备厂商。它在国内拥用许多电信运营商客户。Clearnet主要通过分销的方式发展中国的业务，由国内的合作伙伴和电信公司签约并提供具有增值内容的集成服务。
2000年，国内一家省级电信公司（H公司）打算上某项目， 经过发布RFP（需求建议书）以及谈判和评估，最终选定Clearent公司为其提供IP电话设备。立达公司作为Clearent公司的代理商，成为了该 项目的系统集成商。立达公司是第一次参与此类工程。H公司和立达公司签订了总金额近1000万元的合同。李先生是该项目的项目经理。
该项目的施工周期是三个月。由Clearnet负责提供主要设备，立达公司负责全面的项目管理和系统集成工作，包括提供一些主机的附属设备和支 持设备，并且负责项目的整个运作和管理。Clearnet和立达公司之间的关系是外商通常采用的方式：一次性付账。这就意味着Clearnet不承担任何风险，而立达公司虽然有很大的利润，但是也承担了全部的风险。合同是固定总价的分期付款合同，按照电信业界惯例，10%的尾款要等到系统通过最终验收一年后才能支付。
3个月后，整套系统安装完成。但自系统试运行之日起，不断有问题暴露出来。H公司要求立达公司负责解决，可其中很多问题涉及Clearent的设备问题。因而，立达公司要求Clearent公司予以配合。Clearent也一直积极参与此项目的工作。
然而，李先生发现，立达对H公司的承诺和技术建议书远远超过了系统的实际技术指标，这与Clearent与立达的代理合同有不少出入。立达公司 也承认，为了竞争的需要，做了一些额外的承诺。这是国内公司的常见做法，有的公司甚至干脆将尾款不考虑成利润，而收尾款也成了一种专职的公关工作。这种做 法实质上增加了项目的额外成本，同时对整个的商业行为构成潜在的诚信危机。
对于H公司来说，他们认为，按照RFP的要求，立达公司实施的项目没有达到合同的要求。因此直至2002年，H公司还拖欠立达公司10%的验收款和10%的尾款。立达公司多次召开项目会议，要求Clearent公司给予支持。但由于开发周期的原因，Clearent公司无法马上达到新的技术指标并满足新的功能。于是，项目持续延期。为完成此项目，立达公司只好不断将Clearenet公司的最新升级系统（软件升级）提供给H公司，甚至派人常驻在H公司（外地）。
又经过了3个月，H公司终于通过了最初验收。在立达公司同意承担系统升级工作直到完全满足RFP的基础上，H公司支付了10%的验收款。然 而，2002年底，Clearent公司由于内部原因暂时中断了在中国的业务，其产品的支持力度大幅下降，结果致使该项目的收尾工作至今无法完成。
据了解，立达公司在此项目上原本可以有250万元左右的毛利，可是考虑到增加的项目成本（差旅费、沟通费用、公关费用和贴现率）和尾款，实际上的毛利不到70万元。如果再考虑机会成本，实际利润可能是负值。
导致项目失败，尤其是项目预期的经济指标没有完成，这是非常遗憾的事情。项目失败或没有达到预期的经济指标的因素有很多，其中风险管理是一个极为重要的因素。
5