案例一

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

 案例二

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

 案例三

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

 案例四

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

【问题】

    请提出一些建设性的意见，如何能够召开成功的需求评审会议？
1，分层次评审
用户需求一般可以分为目标性需求、功能性需求和操作性需求。目标性需求定义了整个系统需要达到的目标，功能性需求定义了整个系统必须完成的任务，操作性需求定义了完成每个任务的具体的人机交互。目标性需求是企业高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。
2，正式评审与非正式评审相结合
正式评审是指开评审会的形式，组织多个专家，将需求涉及到的人员组织在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式评审没有这种严格的组织形式，一般也不会将人员集合在一起评审。而是通过电子邮件、文件会签，甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式评审比正式评审的效率高，更容易发现问题。因此，在评审时应灵活的运用这两种评审方式。
3，分阶段评审
应该在需求形成的过程中分阶段评审，而不是在需求完成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。
4，精心挑选评审员
需求评审可能评审的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一问题的看法不同。有些观点是和系统的目标有关系，有些是关系不大的，不同的观点可能形成互补的的关系。为了保证评审的效率和质量，需要精心挑选评审人员。首先要保证使不同类型的人员都参与进来，否则会漏掉很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则可能会使评审的效率降低或者最终不切实际的修改了系统的范围。
5，对评审员进行培训
培训可以分为简单培训和详细培训。需要注意的是被评审的人员也需要进行培训。
6，充分利用需求评审检查单
需求检查单可以分为两种：需求形式的检查单和需求内容的检查单。需求形式的检查单可以由QA人员负责，主要针对需求文档的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等，是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。
7，建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程。按照流程中定义的活动进行规范的评审过程。在流程中可定义评审的进入条件、需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等。
8，做好评审后的跟踪工作
在需求评审后，需要对评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些是可以不纠正的，并给出充分的客观理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更管理流程，并确保变更的执行，变更完成后要进行复审。切忌评审完成后对问题没有跟踪，而无法保证评审结果的落实，使前期评审的努力付之东流。
9，充分准备评审
评审质量的好坏很大程度上取决于评审会议前的准备工作。常出现的问题是需求文档在评审前并没有提前下发给参与评审人员，并没有留出更多更充分的时间让参与评审的人员阅读评审文档。更有甚者没有执行评审的输入条件，在评审文档中存在大量的低级错误或者没有在评审前进行沟通。文档中存在方向中的错误，从而导致评审的效率很低、质量很差。对评审的准备工作，也应当定义一个检查单，在评审前对照检查单落实每项工作。