需求描述，就是将需求捕获，分析的结果进行文档化的过程。在软件开发时，将分析结果文档化是比克或缺的任务。本章将重点从需求描述的风格与格式，写作策略与技巧两个方面做强调和补充。

7.1 需求描述的风格与格式

7.1.1 常见的描述风格与选用标准

7.1.1.1 自然语言

优点：易于编写，易于阅读，不要求掌握特定的技能。

缺点：不够严谨，歧义性强，表述力差(对于复杂问题往往需要大量篇幅来解释)。

因此，当我们使用自然语言时，需要尽可能采用结构化文本来组织。

7.1.1.2 图形化模型

优点：可视性，聚焦性；

缺点：要求编写和阅读的人能正确地理解，并不是所有信息都可以用模型表示。

因此，对于一个软件需求规格说明书，不可能只有图形化模型，而没有文字表述的。

7.1.1.3 形式化规格描述

对于逻辑性强，精度要求高的场合，形式化规格表述就是一种不错的选择。

优点：严谨，精确。

缺点：编写和阅读都有困难，容易产生理解歧义。

形式化规格描述有很多种：决策图，决策表，伪代码等。

7.1.1.4 选择建议

根据不同项目，不同团队的特点，我们可以选择不同的风格组合。最常见的组合形式包括：

》自然语言为主，图形化模型为辅，需要的地方少量使用形式化规格描述。大部分系统都适合用这种组合。

》图形化模型为主，自然语言为辅，需要的地方少量使用形式化规格描述。当项目团队对模型标准有统一的较高的认识时，可以考虑使用这种组合。它在需求管理方面会更加方便一些，但也会带来一些沟通障碍，特别是在团队和客户之间。

》以形式化规格语言为主，图形化模型为辅，自然语言作为补充。适用于质量要求很高的领域。例如航天，军工中的重要项目。

7.1.2 典型软件需求规格说明书模型解析

除了确定风格之外，选择一个合适的需求模板也是很重要的任务。模板通常可以分成3类：

7.1.2.1 国际/ISO版本：由于制定时间比较早，总体显得比较陈旧。

》引言部分

    × 编写目的

        第一：区别读者背景。如果能在此说明不同背景的读者应该重点阅读哪些内容，将是不错的做法。

        第二：区别用户层次。高层用户关心业务需求(目标与范围)，也就是偏重于阅读任务概述，目标这些小结；中层用户关心业务事件，也就偏重于阅读每个子系统中的分解，流程图以及一些利益点分析；操作层用户关心业务活动，也就偏重于阅读用例的描述。

        第三：区别用户所属的业务区域。如果需求规格说明书中的内容能体现这种区域划分，就能让读者更好的评审。

    × 定义

        在这个小结经常会做“术语表”，但实际上项目中的术语表经常需要增补，所以术语表是适合单独管理的，例如使用wiki这种知识管理工具。

》任务概述

    任务概述实际上就是用来框定系统的目标与范围，说明一些诸如用户特点，相关事实与假设之类的总体信息。

    × 目标，在此指出系统开发的业务目标。表述方法可以参考“第四章 需求定义最佳实践”

    × 用户特点，这个部分信息主要用来保证系统的易用性。

    × 假定，在“第四章 需求定义最佳实践”中介绍，就是需求阶段对技术能力所做的假设。

    × 约束，在“第三章 需求与需求工程”中总结过，就是非技术因素决定的技术选型，预期的软硬件环境，预期的使用环境三种。

》需求规定部分

这是需求规格说明书的主题。

    × 对功能的规定

        在这份标准模板中，只是定义了这个小结，至于这个小结里面该如何组织并没有明确，那么如何保证每个人写出来的东西具有相近的风格呢？

    × 对性能的规定

        常常会在这里写出非功能性需求，需要注意的是，需要区分全局非功能需求和局部非功能需求。

    × 输入输出需求 这部分作为历史遗留，可以考虑去除

    × 数据管理能力要求 这部分作为历史遗留，也可以考虑去除

    × 故障处理要求

》运行环境规定

    这部分信息，现在绝大部分软甲也会遇到，可以使用UML中的部署图对其进行建模。

    × 设备：硬件资源

    × 软件：预期的操作系统，中间件，数据库，第三方软件等软件环境。

    × 接口：所需的外部系统接口。

    × 控制：这个部分比较过时。

7.1.2.2 RUP版本：由于采用模型为主的思路，因此文字部分显得过于简单。

作为软件工程的百科全书，Rational统一过程中也定义了一个“软件需求规约”的模板。当该模本的文字部分比较简单，主要内容都在rational工程中，所以在此不再详述。

7.1.2.3 咨询商版本：其中Volere就是一个典型版本，他们有一个共同点，就是比较追求通用性，难免出现“大而全”的弊端。

7.1.3 定义模板的技巧

如果只是简单的选择一个现有的模板，很可能不会恰好适合公司项目和团队的情况，在大部分情况下是需要自己定义一个模板的。

7.1.3.1 模板

7.3.1.2 模板以外的内容

》模板

》指南

当模板确定之后，还需要编写相应的写作指南，如果缺乏有效的指南，就会导致在实际应用过程中出现理解，使用偏差。一个好的写作指南，重点在于让使用模板的人清楚什么时候该写，写什么，怎么写。

    × 理由：说明该小结为什么要写，什么时机写。

    × 内容：明确应该写什么内容。

    × 工具：一些帮助需求规格说明书更好更快完成的模板，工具，分类，提示等信息。

》示例

包括完整版示例和局部示例。局部示例是个不错的做法。

7.1.4 用户需求说明与软件需求说明

在CMMI中，针对3级定义了名为需求开发的kpa，其中提出了客户需求和产品需求的概念。

7.1.4.1 用户需求说明书

》什么是用户需求说明书，顾名思义就是用户对需求的说明与介绍，特点是更加面向业务，存在零散，可能相互矛盾等问题。

》何时需要用户需求说明书，通常在以下几种情况才需要编写用户需求说明书：

    × 用户方有专门的需求团队，此时通常让用户方需求团队先整理需求，提交产物就是用户需求说明书。

    × 开发方拥有自有的产品体系，此时通常会先按用户的视角整理需求，然后再根据自有产品体系分析需求。

    × 直接与用户交流的需求团队更偏向业务能力，这时可以由需求团队整理用户需求说明书，然后交由有一定技术能力的团队进行分析，建模，形成软件需求说明书。

7.1.4.2 从用户需求到软件需求规格

7.2 写作策略与技巧

7.2.1 文字表达的先天不足

7.2.1.1 非文字信息的缺乏导致信息丢失

7.2.1.2 说者无心，听者有意

7.2.2 需求描述的两大原则

7.2.2.1 简洁，段落文字少

7.2.2.2 列表，图标相结合

7.2.3 不要忽视陈述需求理由的重要性

需求讲的是做什么(what)，和为什么做(why)，而不应该写大量的细节(how)

7.2.4 注意措辞

7.2.4.1 减少使用定性词语

例如：系统应该对数据验证提供有效的支持。有效是什么，具体表现在哪里？

7.2.4.2 避免使用描述数据的词语

例如：在。。。之间，但不包括，大于但不等于