2.3 正式评审与非正式评审结合

　　正式评审时指通过开评审会的方式，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。很多时候，因为需求内容太多，正式的评审会议中不可能将每一个细节都涉及到，评审员也有一个理解需求的过程，在短短的会议中不可能发现太多问题。因此，需要与非正式评审相结合，在评审会之前可以先开会对大家进行需求讲解，然后把需求通过邮件等方式发送给相关人员，留几天时间，以便相关人员仔细研究，记录异常，在正式的评审会上讨论。

　　2.4 分阶段评审

　　需求评审应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。可以根据需求人员进行需求分析的进度，将一个整体的软件需求分为不同的阶段，组织小规模的评审。在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。这样降低了需求返工的风险，提高了评审的质量。

　　2.5 评审人员选择

　　需求评审涉及到各层次人员，在进行评审员选择时，一定要将各层次人员都囊括进来，他们可能有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人员、编码人员、测试人员、质量保证人员等等。

　　用户在进行需求评审时，关注点更多在于他们所要求的功能是否在软件需求说明书中都囊括进来了；架构师及概要设计人员更多关注的是在现有的技术条件下，是否能够实现需求中的要求，如果无法实现需求或者代价太大，可能就要需求人员与用户沟通更改需求；编码人员可能更多关注于某些细节，例如界面元素等；测试人员主要关注是否所有的需求都是可测试的；质量保证人员关注点在于输出物是否符合规范。各层次人员充分参与，便于他们理解需求，通过需求评审，达成一致意见，不至于需求在不同环节因理解不同而出现偏差。

　　因为各层次人员的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。如果漏掉某一层次的人员，可能会漏掉很重要的需求。

　　2.6 对评审人员进行培训

　　常常见到有的项目的需求评审会议在主持人进行需求讲解时，与会人员似懂非懂，没有提出有价值的问题，致使会议没有取得预期的效果，不得不改日重新进行。有的项目的需求评审会议针对某一个细节问题与会人纷纷提出自己的意见，大家争执不下，结果，会议出现了混乱状况，主持人无法控制局面，致使会议大大超出了计划评审时间。因为各层次评审人员关注点不同，评审也需要技巧、把握关键点，因此，应该对各层次评审人员进行有针对性的培训。以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率。

　　2.7 给予评审员充足的评审时间

　　实践证明，需求的异常往往存在于细节方面，评审员理解软件需求又需要一个过程，要想找到这些异常，必须有充足的时间，以便充分理解需求、找出其中的缺陷，提出可行性建议。因此，从需求讲解到非正式评审再到正式评审，需要预留足够的时间。

　　如果评审员是项目中的成员，项目负责人需要给项目成员专门下达需求评审的时间，如果评审员只能额外抽时间来研究需求，恐怕只能简单提几条质量不高的异常了事。评审自然也就达不到预期的目的。实践证明，在需求评审上多花一些实践是值得的，所谓“磨刀不误砍柴工”。

　　2.8 把握需求评审的关键点

　　（1）注意对软件需求说明书的正确性进行评审。需求规格说明的正确性通常可以从如下方面得以体现：

　　① 是否有需求与其他需求相互冲突或者重复？

　　② 是否清晰、简洁、无二义地表达了每个需求（“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定“读”的效果，是让大家对需求描述的理解能够达成一致）？

　　③ 是否每个需求都通过了演示、测试、评审，分析是否得到了验证？

　　④ 是否每个需求都在项目的范围内？