三、 注意对需求规格说明的完整性进行评审 

    我们经常由下面的问题清单来评审需求说明书是否”完整” 。 

    1 编写的所有需求，其详细程度是否一致和合适? 

    2 需求是否能为设计提供足够的基础? 

    3 所有对其他需求的内部引用是否正确? 

    4 是否包含了每个需求的实现优先级? 

    5 是否定义了功能说明的内在算法? 

    6 是否包含了所有已知的客户需求或系统需求? 

    7 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ? 

    8 是否对所有预期的错误条件所产生的系统行为都编制了文档? 


    需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。 

    让我们看一个功能需求例子,“FR1: 销售出货要考虑到信用额度”。 

    乍看显得过于简单和含糊,我们把它修改成”FR1: 1 销售出货的前提是该客户拥有超过出货价值的信用额度, 否则,系统提示‘该客户信用额度不足,不予出货!’ 2 正式出货后系统将扣减其信用额度” 。 

    很显然,修改后的需求把出货和信用额度的来由去向和系统的具体反应都说明清楚了。 

    当然传统的需求描述也能够与用例中的参与者和系统响应等内容映射的。