怎样的需求文档才是合格的需求文档

　　软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。

　　构造并编写软件需求规格说明，并使用户和其它读者能理解它牢记以下可读性的建议：

　　● 对节、小节和单个需求的号码编排必须一致。

　　● 在右边部分留下文本注释区。

　　● 允许不加限制地使用空格。

　　● 正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。

　　● 创建目录表和索引表有助于读者寻找所需的信息。

　　● 对所有图和表指定号码和标识号，并且可按号码进行查阅。

　　● 使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。

　　优秀需求具有的特性

　　怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？下面讨论单个需求陈述说明的几个特点（ Davis 1993；IEEE 1998）。让风险承担者从不同角度对S R S需求说明进行认真评审，能很好地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的（尽管并不十分完美）需求文档，同时也会开发出更好的产品。

　　1、需求说明的特征

　　1）完整性

　　每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

　　2）正确性

　　每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

　　3）可行性

　　每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

　　4）必要性

　　每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。