规格说明中寻找错误的系统行为。
在编写软件需求规格说明，希望读者牢记以下的建议：
对节、小节和单个需求的号码编排必须一致。
在右边部分留下文本注释区。
允许不加限制地使用空格。
正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。
创建目录表和索引表有助于读者寻找所需的信息。
对所有图和表指定号码和标识号，并且可按号码进行查阅。
使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。
为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以使你在变更请求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。由于要达到这一目的，用单一的项目列表是不够的，因此，我将描述几个不同的需求标识方法，并阐明它们的优点与缺点。可以选择最适合你的方法。
(1) 序列号最简单的方法是赋予每个需求一个唯一的序列号，例如SRS-13。当一个新的需求加入到商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号（许多这样的工具也支持层次化编号）。序列号的前缀代表了需求类型，例如SRS代表“软件需求说明”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供任何相关需求在逻辑上或层次上的区别，而且需求的标识不能提供任何有关每个需求内容的信息。
(2) 层次化编码这也许是最常用的方法。如果功能需求出现在软件需求规格说明中第3 . 2部分，那么它们将具有诸如3.2.4.3这样的标识号。标识号中的数字越多则表示该需求越详细，属于较低层次上的需求。即使在一个中型的软件需求规格说明中，这些标识号也会扩展到许多位数字，并且这些标识也不提供任何有关每个需求目的的信息。如果你要插入一个新的需求，那么该需求所在部分其后所有需求的序号将要增加。删除或移去一个需求，那么该需求所在部分其后所有需求的序号将要减少。但其他地方的引用将混乱，对于这种简单的层次化编号的一种改进方法是对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。例如，软件需求规格说明可能包含“第3.2.5部分—编辑功能”，并将此部分编写成子模块文档，然后配置管理。
有时，你觉得缺少特定需求的某些信息。在解决这个不确定性之前，可能必须与客户商议、检查与另一个系统的接口或者定义另一个需求。使用“待确定”（to be determined, TBD或采用汉语拼音略写DQD）符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷。通过这种方法，你可以在软件需求规格说明中查找所要澄清需求的部分。记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。
在继续进行构造需求集合之前，必须解决所有的TBD问题，因为任何遗留下来的不确定问题将会增加出错的风险和需求返工。当开发人员遇到一个TBD问题或其它模糊之处时，他可能不会返回到原始需求来解决问题。多半开发者对它进行猜测，但并不总是正确的。如果有TBD问题尚未解决，而你又要继续进行开发工作，那么尽可能推迟实现这些需求，或者解决这些需求的开放式问题，把产品的这部分设计得易于更改。
编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。从过去所遇到的问题中可使你受益匪浅。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。
你在编写优秀的需求文档时，希望读者还需牢记以下几点建议：
保持语
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
