《计算机科学丛书·需求工程：实践者之路（原书第4版）》：
这可以减少或消除矛盾和冗余。这是手工劳动，必须通过评审来检查。现在市场上已慢慢有一些可用的工具，可以自动检查需求的各种质量参数，如它们是否是可以理解的，它们的可读性如何，以及是否描述了必要的属性。戴姆勒公司用工具帮助检查规格说明书。它帮助提高了质量，减少厂误解和项目实施过程中的咨询。需求规格说明书是所有利益相关方和项目参与者关于要做什么的参考。它定义了通用的术语，描述了所有与项目相关的内容和约束。它不是描述一个新发布的产品目录。需求规格说明书始终是面向项目的（并因此涉及发布），并由此形成了一个与前一版本有差别的文档。
4）需求描述得可测试和可判定。写下来的需求可以作为后续开发步骤的基础。如果需求规格说明书已被检查应该如何进行测试，就可以有效改善可读性和一致性。一个测试专家不会接受模糊的描述，因为几乎不可能从中推导出可靠的测试案例。需求的可判定性意味着可以刘产品是否满足需求做出“是”或“否”的判断。这尤其对验收很重要。将验收标准嵌入到需求中并检验它们的可判定性，将有效提高客户满意度。规定“室温必须保持在设定值±0.5摄氏度”，这听起来已经足够精确，但还不够。如果你是测试人员，你就会问：怎么判断过渡阶段是否满足这一需求？显然，必须添加额外的属性，如在多长时间后达到此温度。在需求获取阶段可判定性和可测试性在很大程度上是比较模糊的，准确描述它们会对项目成功起非常重要的作用。
5）有控制的配置基础。需求规格说明书是每一个项目的第一个配置基础。在此基础上，建立许多其他的文件和工作成果。因此必须对需求规格说明书进行版本管理，而不只是归档。只有这样才能清楚地知道具体实施了哪个配置基础。从这个基本配置可以链接到其他文档，以确保一致性和连续性（例如，从需求到测试用例）。需求规格说明书是所有变更的起点。
6）明确区分需求和方案描述。我们已经在2.1节中描述了需求和解决方案之间的差异。我们往往模糊了这种区别。尤其是在建模技术上，无法明确区分需求，以及它们的模型和方案域的另一个模型。面向对象的分析技术也同样力求避免问题域和解决域之间的结构性差异。这种模糊的结果是：以后再也分不清楚哪些基础（从项目角度）是客户期望的，从而是不能改变的，哪些是方案的一部分，可以改变。因此，我们在《计算机科学丛书·需求工程：实践者之路（原书第4版）》中建议明确区分不同视角。要结构化地编写需求并为其建模。规格说明书用来控制和管理需求。模型用来分析和进一步开发。这样就可以克服结构性差异，还建立了一个坚实的需求基础。
我们区分规格说明书的两个基本的视角如下：
需求规格说明书。它描述要做什么和为什么做。它涵盖了市场需求（参见2.1节）。它属于客户方，因此与合同相关。
方案规格说明书。它描述怎么做。它涵盖了产品需求及部分组件需求（参见2.1节）。
它属于供应商，并作为进一步开发的基础。
二者内容可能会有重叠，这取决于是谁写的。对于一个需求是客户视角还是方案视角，还没有明确定义。因此，在电梯的例子中，选择楼层的按钮可以是一个硬件按钮或在触摸屏的软件按钮。客户可以指定是用硬件或软件方案，或只想要一个选择楼层的按钮。供应商可以决定用硬件或软件实现。这样，内容相同的需求又是一个方案了。
……
展开
