| 由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。
|
|
|
| 因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。
|
|
|
| 什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。
|
|
|
|
|
| 1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。
|
|
|
| 原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
|
|
|
| 原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
|
|
|
| 原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。
|
|
|
|
|
| 原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
|
|
|
| 原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
|
|
|
|
|
| 原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。
|
|
|
| 尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。
|
|
|
|
|
| 需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。
|
|
|
|
|
|
|
|
|
| 需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：
|
|
|
|
|
|
|
| ③文档中的所有描述是否完整、清晰，准确地反映用户要求；
|
|
|
|
|
|
|
|
|
| ⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
|
|
|
| ⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；
|
|
|
|
|
|
|
|
|
|
|
| ?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
|
|
|
|
|
|
|
|
|
| 为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。
|
|
|
| 填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
|
|
|
|
|
|
|
|
|
| 在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。
|
|
|
