22.2.5需求说明书评审

    由于信息应用系统建设针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求很复杂的情况。在这种情况下，如果不在监理单位的协调下进行业主单位与承建单位充分的沟通，往往造成承建单位按照自己的理解进行开发的情况出现，如果在测试阶段没有发现此类问题则会给系统造成重大隐患，如果发现问题则会造成工程建设返工与延期。

    因此，在此阶段监理单位的工作重点是监督承建单位的分析人员、设计人员和测试人员对需求说明书的审查，并协调业主单位与承建单位需求说明书的评审确认。需求分析阶段工作落实的情况，直接决定了后续开发工作的质量、进度、投资与变更的情况，因此必须在监理过程中给予足够的重视。

    1.编制良好的需求说明书八条原则

    1979年由Baize:和Goldman提出了做出良好规格说明的八条原则。

    原则1:功能与实现分离，即描述要“做什么”而不是“怎样实现”。

    原则2:要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，以此定义一个行为模型，从而得到“做什么”的规格说明。

    原则3:如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。

    原则4:规格说明必须包括系统运行的环境。

    原则5:系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

    原则6:规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例、已提出的实现方案是否都能满足规格说明。

    原则7:规格说明必须容许不完备性并允许扩充。

    原则8:规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落(理想情况)。同时，规格说明应被松散地构造(即耦合)，以便能够很容易地加入和删去一些段落。

    尽管Balzer和Goldman提出的这八条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

    2.需求说明书的框架

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

需求说明书的框架见表22-1。

    3.需求说明书评审内容

    作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是:

    (1)系统定义的目标是否与用户的要求一致;

    (2)系统需求分析阶段提供的文档资料是否齐全;

    (3)文档中的所有描述是否完整、清晰、准确反映用户要求:

    (4)与所有其他系统成分的重要接口是否都已经描述:

    (5)被开发项目的数据流与数据结构是否足够、确定;

    (6)所有图表是否清楚，在不补充说明时能否理解;

    (7)主要功能是否己包括在规定的软件范围之内，是否都已充分说明;

    (8)软件的行为和它必须处理的信息、必须完成的功能是否一致;

    (9)设计的约束条件或限制条件是否符合实际;

    (10)是否考虑了开发的技术风险;

    (11)是否考虑过软件需求的其他方案_;

    (12)是否考虑过将来可能会提出的软件需求;

    (13)是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;

    (14)有没有遗漏、重复或不一致的地方;

    (15)用户是否审查了初步的用户手册或原型;

    (16)项目开发计划中的估算是否受到了影响。

为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和监理单位都应当参加评审工作。需求说明书要经过严格评审，一般，评审的结果都包含了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。

    4.需求说明书检查表

需求说明书检查表见表22-2。

5.需求说明书评审报告

    在需求说明书评审结束后，监理单位应将评审意见以专题监理报告形式提交业主

单位。