例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。
附录A ：词汇表
定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。
附录B ：分析模型
这个可选部分包括或涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体-关系图。
附录C ：待确定问题的列表
编辑一张在软件需求规格说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。
2）指明需求来源：指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
3）为每项需求注上标号：为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。需求标识方法有序列号;层次化编码;使用"待确定"（to be determined, TBD ）符号等。
4）记录业务规范：是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。
5）创建需求跟踪能力矩阵：建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。
这里我们还要介绍需求规格说明书中设计阶段，用到的图形模型--数据字典、数据流图、数据流图、状态转换图、对话图和类图。
数据字典：一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。数据字典的维护独立于软件需求规格说明，并且在产品的开发和维护的任何阶段，各个风险承担者都可以访问数据字典。它定义了原数据元素、组成结构体的复杂数据元素、重复的数据项、一个数据项的枚举值以及可选的数据项。
数据流图：是结构化系统分析的基本工具。一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集（存储），还有过程、存储、外部世界之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上，这种方法很适用于事务处理系统和其它功能密集型应用程序。
数据流图：描绘了系统的数据关系。分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。相反，当你在系统设计阶段建立实体联系图时，通常要定义系统数据库的物理结构。
状态转换图：实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时，状态就会发生改变，例如在特定条件下，接收到一个特定的输入激励。这样的系统是有限状态机的例子。大多数软件系统需要一些状态建模或分析，就像大多数系统涉及到转换过程、数据实体和业务对象。
对话图：在许多应用程序中，用户界面可以看作是一个有限状态机。在任何情况下仅有一个对话元素（例如一个菜单，工作区，行提示符或对话框）对用户输