（7）注意对需求包含的用例文档进行评审。用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。

　　需求评审确认的重点是对关键用户的常用和重要的用例进行深入和细致的评审，首先要通过测试用例的主干过程。而是否撰写有效的用例则要从以下方面着手评审：用例的目标或价值度量是否明确？用例是否是独立的分散任务？

　　是否明确说明可用用例会给哪些参与者带来用处？编写用例的详细程度是否恰当？是否有不必要的设计和实现细节？所有预期的分支过程是否都编写了文档说明？所有预估的异常过程是否都编写了文档说明？是否存在一些普通的动作序列可以分解成独立的用例？

　　每个路径的步骤是否都清晰明了，无歧义而且完整？用例中的每个参与者和步骤是否都与所执行的任务有关？用例中定义的每个可选路径是否都可行和可验证？用例的前置条件和后置条件是否合理？分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围，区分了用例和用例之间的界限。

　　2.9 建立评审流程

　　对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。

　　2.10 建立评审制度

　　有效的需求评审，相关的评审制度必不可少，主要有以下方面：

　　① 限制项目内评审员提交有效异常的数量，并纳入考核，必须达到一定数量才算合格；

　　② 制定评审的准入准出条件，限制随意通过评审；③质量保证人员参与评审，监督评审进行；④质量保证人员对评审流程进行全程监控。

　　2.11 跟踪工作

　　在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。

　　当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。