『定义』：
　    需求评审已测试并接受了单项需求，它们被允许进入规格说明，现在需要评估规格说明是否完整。这种复查可以迭代，最好每次针对一个产品用例（PUC）的需求。

『关于需求完整性审查』:
    一种相当有效的规格说明复查方式，它是一个正式的过程： 　
    1、指派一名协调人（可能是业务分析师），负责安排审查和分发资料。
　 2、建立最容易犯的错误的检查清单，你会在后续的审查中扩充这份清单。
　 3、给审查者一些时间来阅读文档，准备审查。
　 4、将审查限制在2小时以内，审查一天不超过2次。
　 5、审查人数为3～8人

『需求完整性复查包含以下几个方面』：
    1、确定是否遗漏了需求  　
    2、排列需求优先级，这样构建者能理解需求的重要性和紧急性。
    3、检查需求之间的冲突，这会阻碍一项或多项其他需求的实现。
    4、预估构建的成本（管理层执行的任务）
    5、评估项目所面临的风险（管理层执行的任务）

『确定是否遗漏了需求』：
    1、定义上下文范围 　
    2、识别业务事件和‘无事件’，无事件指如果基本事件没有发生所引起的事件。如：基本事件‘卡车处理了一条道路’，但如果卡车没有处理那条道路，会发生什么情况？工作必须做些事情，它就是无事件（它发生是因为另一个事件没有发生），如‘到了监控道路除冰的时间’。工作对这个无事件进行响应，将检查道路是否按照指令进行了处理，如果没有处理，将‘对未处理的道路进行提醒’。
    3、为BUC建模，利用你的模型展示BUC的功能，通过这些信息，你可以决定功能要用到的存储数据。 　
    4、定义业务数据，构建正研究的工作所需要的存储数据的模型（类图、实体关系模型、关系模型或其他）。
    5、CRUD检查（每个数据类都必须被创建Ｃreated并被引用Referenced），有些也被更新Update或被删除Delete。创建一个CRUD表，以显示是否每个类都有相应的动作。这些动作是业务用例（BUC）执行的，所以这一步能揭示遗漏的事件。 　　
 注意：如果发现了遗漏事件，你必须重新访问利益相关者，找到关于这些事件的更多知识。如果你确定了这些事件，更新上下文范围图，将它们加入事件列表，更新CRUD表，继续该过程。
    6、保管人过程检查，分为基本过程和保管人过程 　　
        1）基本过程是指那些与系统存在的理由有联系的过程，如：你递上信用卡来完成支付，信用卡公司将记录支持的金额和其他细节。
        2）保管人过程是为了维护（保管）存储数据，这些过程对数据进行更改，原因只是为了保持数据最新，它们不属于基本过程。如：你搬了新家、通知信用卡公司变更地址，公司相应地更新记录。
        3）检查保管人过程，就要查看类模型和CRUD表，确保有足够的业务事件和相应的过程来维护工作存储的所有数据。如果类包含可更改的属性，那就可能有一个保管人业务事件来修改这些属性。 　
    7、重复直到完成，将第1～6步骤做迭代（确定业务事件、对业务用例建模、加入类模型、检查类被创建、引用、更新和删除）。

『排列需求优先级』：
    1、影响优先级的因素
        1）实现的成本
        2）对顾客或客户的价值
        3）实现产品所需的时间
        4）技术实现的容易程度
        5）业务或组织机构实现的容易程度
        6）对业务的好处
        7）遵守法律的要求
    2、何时确定优先级 　　       
        1）让需求知识变得越可视，就越有机会不盲目的选择。
        2）强烈建议在启动会议上对每个BUC指定优先级附上顾客满意度和不满意度评分。
        3）编写原子需求时，应该不断考虑是否排列它们的优先级。原因是期望值管理，如果你一直在不断的排列优先级，人们就能够接受这种这种，而不会感觉被欺骗。让利益相关者准备好接受一个事实，即你不能实现所有的需求。
    3、需求优先等级
        1）必须有Must　
        2）应该有Should
        3）可以有Could
        4）不会有Won't
    4、优先级电子表格 　
        1）把影响因子的个数限制在4个以内（如：1.对顾客的价值、2.对业务的价值、3.煎炒实现成本、4.易于实现）
        2）每个因子分配适用权重百分比
        3）累加需求的权重评分，得到该项需求的优先级评分。

『检查需求之间的冲突』：
    1、需求冲突的情况
        1）使用相同数据的需求（按照使用的术语进行匹配查找）
        2）相同类型的需求（按照需求类型匹配查找）
        3）使用相同度量尺度的需求（查找那些验收标准使用相同度量尺度的需求）
    2、需求分析师的冲突解决责任： 　　　
        1）在解决冲突的过程中扮演领导的角色
        2）将冲突的需求隔离出来，单独与每个利益相关者接触，重新对满意度和不满意度评分。
        3）如果作为调节人不能获得满意的解决方案，建议你确定现有冲突需求的成本、评估风险，召集当事人会议达成折中。

『评估项目的风险』：
    1、业务分析师在风险评估中的角色，是考虑需求是否包含某种风险，可能影响项目成功。
    2、不必进行风险分析，这项任务更有可能是由项目经理执行。
　 3、风险评估不是真正的需求问题，是项目问题。
　 4、具体要素：
        1）项目驱动
　　　  1.项目的目标
　　　  2.客户、顾客和其他利益相关者
　　　  3.产品的用户
        2）项目限制条件
　　　  1.强制的限制条件
　　　  2.相关事实和假定
        3）功能需求
　　　  1.工作的范围
　　　  2.业务数据模型和数据字典
　　　  3.产品的范围

『度量所需的工作量』：
    1、我们建议在完整性复查中包括某种规模度量活动
    2、常识告诉你，不能不清楚要构建的产品的规模以及所需的工作量就继续开发。
    3、在需求收集过程中完成的工作，为度量过程提供了输入信息。
    4、你的上下文模型是工作规模的权威指南，你可以简单数一下写下的需求数目，所有的这些都是度量，都比猜测工作量和盲目接受最后期限要强得多。