每个软件开发组织都会为自己的项目选用一个或多个标准的软件需求规范说明模板。有许多软件需求规范说明模板可以使用(例如ISO/IEC/IEEE2011;Robertson and Robertson2013)。如果你的组织要处理各种类型或规模的项目，例如新的大型系统开发或是对现有系统进行微调，就要针对项目的主要类别来选择一个软件需求规范说明模板。第5章中的“模板策略”小节就涉及如何有效使用文档模板。
图说明SRS模板适合很多类型的项目。附录C包含的一个模板示例遵循的也是这个模板。此模板的每个小节都有使用指导说明，并可以从本书的配套网站下载。有些人在Word中将这些使用说明设置为“隐藏文字”，好让你在文档中留下提示。如果日后还想用，打开这些非打印字符就能看到说明。
有时，某一些信息片断会按逻辑记录在好几个模板部分中。选出其中一部分，然后在项目中前后一致地使用。不要到处复制信息，哪怕在逻辑上适合多个小节(Wiegers2006)。交叉引用和超链接可以帮助读者找到他们需要的信息。
创建需求文档时，最好使用有效的版本控制实践和工具，以确保所有读者都知道自己在阅读哪一个版本。还要在文档中对修改历史做变更记录，包括何人何时因为何种原因做的修改(详见第27章)。下面将描述软件需求规范说明每个小节要包含的信息。
重点提示
不要在软件需求规格说明中简单地复制信息，但可以参考其他现有的项目文档来组织材料。文档之间的超链接就可以实现上述目标，这与需求管理工具定义的可追踪链接是一个道理。但是，
如果文档文件夹层次结构发生变化，超链接就有被打乱的风险。
1.引言
引言提出的是一个整体介绍，有助于读者了解SRS是如何组织的，如何使用它。
1.1 目的
对产品或应用进行定义，在这个文档中说明产品或应用程序的需求，包括修订或者发行版本号。如果这个SRS只与某个复杂系统的一部分有关，就只定义这个部分或子系统。描述文档所针对的不同读者类型，如开发人员、项目经理、营销人员、用户、测试人员和文档作者。
1.2 文本约定
描述所用的标准或排版约定，包括具体的文本风格、高亮或符号的意思。如果是在手动标注需求，也许还要在此说明你采用的格式，以便他人后期再添加内容。
1.3 项目范围
简要描述所制定的软件及其目的。将软件与用户、公司目标及业务目标和策略相关联。如果有一个独立愿景和范围或其他类似文档可用，可以将其作为参考，但不要将内容复制到此处。如果软件需求规范说明规定要对一个演化产品进行增量式发布，那么就要将其自身的范围说明包含进来，并将其作为长期战略产品愿景的一部分。可能还要针对发布所包含的主要特性或者其要完成的重要功能，提供一个概要性的小结摘要。
1.4 参考文献
列举本软件需求规范说明所参考的文件或其他资源。如果参考文献的位置不变，也可以列出其超链接。这可能包括用户界面风格指南、合同、标准、系统需求规范说明、界面规范说明或者相关产品的软件需求规范说明。给出的信息要足够详尽，包括标题、作者、版本号、日期、出处、存储位置或URL, 以便读者查阅每一个参考文献。
2.整体描述
这一部分高度概述产品及其使用的环境、预期的用户和已知约束、假设及依赖。
2.1 产品前景
描述产品的背景和起源。该产品是仍在发展中的产品系列中的下一成员? 成熟系统的下一版本?还是现有应用程序的替代品?或一个全新的产品?如果软件需求规范说明定义了大型系统的一个组成部分,那么就要说明该软件是如何与整个系统相关联的，并且要确定两者之间的主要接口。还要考虑将视觉模型包含进来，如背景图或生态系统图(详见第5章)，展示产品与其他系统之间的关联。
2.2 用户类别和特征
确定你觉得可能使用该产品的不同用户类别并描述其相关特征。(详见第6章)有些需求可能只与特定的用户类别相关。确定出你的优待用户。用户类别代表的只是干系人的一部分，这点在愿景和范围文档中会有所描述。对用户类的描述是一种可再利用的资源。如果你手头上有一份重要用户类别目录，就可以合并对用户类的描述，只需在目录中简单提及，无需在此复制信息。
2.3 运行环境
描述软件运行环境，包括硬件平台;操作系统和版本;用户、服务器和数据库的地理位置;容纳相关数据库、服务器和网站的组织。列出系统必须与之共存的其他软件组件或应用程序。如果还需要做一些额外的技术基础设施工作以便与开发中的新系统相结合,就要考虑创建一个单独的基础设施需求规范说明来细化工作。
2.4 设计和实现约束
有时我们必须使用某种特定的编程语言,以及需要对特定代码库花费时间再次开发以便可以使用等等。描述限制开发人员选择的因素，并说明每个约束的基本原理。如果需求包含或者写入解决方案思路，而不是以需要为前提，就是在施加无意义的设计约束，所以要引起我们的警觉。第14章将对约束进行深入的探讨。
2.5 假设和依赖
假设就是在没有确凿证据或明确知识的情况下假定为真的说明。如果假设是错误的、过时的、不能共享或发生了变化，问题就会随之而来，因此某些假设会给项目带来风险。软件需求规范说明的某一个读者可能假设产品符合一个特殊的用户界面约定，而另一个读者却可能不这样认为;开发人员可能假设某组特定的功能是专门为这个应用程序而写,业务分析师可能假设该功能在以前的项目中使用过，而项目经理可能希望获取一个商业性功能库。这里所包含的假设要与系统功能相关;与业务相关的假设包含在愿景和范围文档中。
确定开发中的项目或者程序对外部因素或者其控制之外的组件存在的所有依赖关系。例如，在程序运行之前，必须安装Microsoft.NET Framework 4.5或更新版本，这就是依赖。
3.系统特性
图中的模板显示的是由系统特性所组织的功能需求，而这只是众多组织方式中的一种。其他组织性选项还包括按照功能领域、工艺流程、用例、操作模式、用户类别、刺激和响应来排列功能需求。我们还可以对这些要素进行层级组合，例如将用例和用户类相结合。条条大路通罗马，只要选择的组织方法便于读者理解产品的预期功能。下面描述的是某个特性方案示例。
3.x 系统特性X
寥寥几个单词就可以说明特性的名称，例如“3.1拼写检查”。针对每种特性，都可以用3.x中的下一小节3.x.1和3.x.2来重述。
3.x.1描述
对系统特性进行简要描述，表明它级别是高、中还是低。优先级是动态的，往往在项目过程中不断变化。如果你使用需求管理工具，则要为需求属性设置优先级。
3.x.2 功能需求
列出与此特性相关的具体功能需求。这些软件性能必须先完成，用户才能执行特性的服务或者完成用例。描述产品如何响应可预知的错误条件以及无效的输入和动作。正如本章前面所描述的那样，每个功能需求都要有独一无二的标识。如果是在使用需求管理工具，可以为每个功能需求创建多个属性，例如基本原理、起源和状态。
4.数据需求
信息系统通过处理数据来提供价值。使用模板中的这一部分来描述各方面的数据，系统会将其作为输入来消耗，将其以某种形式来加工，或者将其作为输入来创建。Stephen Withall(2007)阐述了精确记录数据(也称之为信息)需求的多种模式。
4.1 逻辑数据模型
数据模型从视觉上呈现了系统要处理的数据目标和集合以及它们之间的关系。数据建模中含有大量的符号，包括实体关系图和UML类图。你可能还要为系统所强调的业务运作纳入一个数据模型，或者针对系统要处理的数据展示其逻辑关系。这与纳入一个数据模型不是一回事，这样的模型将会以数据库设计的形式来实现。
4.2 数据字典
数据字典定义数据结构的组成及其意义、数据类型、长度、格式以及组成这些结构的数据元素的允许值。商业数据建模工具通常包括一个数据字典组件。在大多数情况下，都应将数据字典存储为一个独立的工件，而不是将它嵌入在软件需求规范说明之中。这样一来，其他项目也可以重用它。
4.3 报告
不管应用程序形成什么报告，都要将其在此确定出来并描述特征。如果报告必须要与某个具体的预定义的布局相吻合，可以将其定义为一个约束，可能还要有一个示例。否则，就将重点放在报告内容、排列顺序、总体水平等的逻辑描述上，并将详细的报告布局推迟到设计阶段。
4.4 数据获取、整合、保存和处理
如果有涉及，就要描述数据是如何获取和保存的。例如，当开始填入库存数据时，可能首先需要将所有库存数据“导入”接收系统之中，后面无须填入有变化的数据。陈述任何涉及需要系统数据完整性保护方面的需求。确定必要的具体技术，如备份、检查点、镜像或数据准确性验证。陈述系统保持或者销毁数据时必须执行的政策，包括临时数据、元数据、残留数据(如已删除的记
录)、缓存数据、本地副本、归档和临时备份。
5.外部接口需求
这部分所提供信息是为了保证系统与用户、与外部硬件或软件元素之间的正常通信。外部与系统内部接口无缝对接是软件行业公认的最佳实践之一(Brown 1996)。如果一个复杂系统有多个组成部分，则应创建一个独立的接口规范说明或者系统架构规范说明。接口文档可以吸纳其他文档中的材料作为参考。例如，它可以指向硬件设备手册，手册中列有设备发送到软件的错误代码。
接口之争
两个软件团队合作为A.Datum公司开发一款旗舰产品。知识库团队用 C++语言开发了一款复杂的推理引擎，应用程序团队用Java语言实现用户接口。这两个子系统之间通过应用程序编程接口(API)交互。不幸的是，知识库团队定期修改API，导致系统不能完整开发并正确执行。应用程序团队花好几个小时才诊断出他们发现的每一个问题，后来才发现根本原因在于API的变更。两个团队对这些变更没有达成一致意见，所以这些变更没有传达给受到影响的各方，而且没有用Java代码体现相应的修改。接口的变更需要个人、团体或系统在此接口的其他方面进行交的修改。接口的变更需要个人、团体或系统在此接口的其他方面进行交流。接口将系统组件(包括用户)结合在一起，因此，整个项目变更控制过程中，需要记录接口细节并同步必要的修改。
5.1 用户界面
描述系统所需的每个用户界面的逻辑特征。下面是可能涉及的一些内容:
- 参考将要遵循的用户界面标准或是产品线风格指南
- 字体、图标、按钮标签、图像、色彩方案、字段序列、常用控件、品牌图形、版权和隐私声明等标准
- 屏幕大小、布局或分辨率约束显示在每一屏上的标准按钮、功能或导航链接，例如帮助按钮
- 快捷键
- 信息显示和语法规则
- 数据验证准则(如输入值的限制和何时验证字段内容)
- 便于软件本地化的布局标准
- 为视力受损者、色盲或其他受限用户提供的便利方案
5.2 软件接口
描述该产品与其他软件组件(由名称和版本来标识)之间的关联，包括其他应用程序、数据库、操作系统、工具、库、网站和集成的商业组件;陈述目的、格式和信息内容、数据和控件值，这些都要在软件组件之间进行交换;指定系统与任何转换之间的输入和输出数据地图,使数据从一个系统转到其他系统;描述外部软件组件所需或者引申出来的服务以及内部组件间通信的性质;确定在软件组件之间交换或者共享的数据;指出影响接口的非功能需求，例如针对响应时间和频率的服务等级，或安全控制和限制。其中一些信息可能会被归为数据需求或者互通性需求(质量属性)。
5.3 硬件接口
硬件接口描述软件组件和硬件组件之间每个界面(还可能包括系统)的特征。这部分描述可能包括支持的设备类型、软硬件之间的数据和控制交互以及将会用到的通信协议。列出输入和输出、其格式、有效值或范围以及开发人员需要注意的时机问题。如果这节的信息量很大，可以考虑创建一个独立的接口规范说明文档。
5.4 通信接口
陈述与产品通信功能相关的所有需求，包括电子邮件、浏览器、网际协议和电子表单。定义任何相关的信息格式。规定通信安全和加密问题、数据传输率、信号交换和同步机制。陈述对这些接口的任何约束，例如电子邮件中特定的附件类型能否接受。
6.质量属性
本节主要规定非功能需求而非约束和外部界面需求。质量需求必须是确定的、定量的并可验证的。表明各种属性的相对优先级，例如易用程度要优于易学程度，保密性优于性能。相比简单的描述性陈述，诸如planguage这样内涵深刻的规范说明符号更能解释清楚每种质量的需求级别。
6.1 易用性
易用性需求涉及易学程度、易用程度、错误的规避和恢复、交互效率和可理解性。这里所规定的易用性需求将帮助用户界面设计师开发出最佳用户体验。
6.2 性能
陈述针对各种系统操作的具体性能需求。如果不同的功能需求或特性有不的性能需求，最好将性能目标与相应功能需求结合在一起进行规定，而不是在这一部分收集它们。
6.3 保密性
这里规定的需求都关系到限制产品进入或使用的涉及保密或隐私问题的需求。主要包括物理、数据或软件方面的保密性。保密性需求通常起源于业务规则，因此要确定产品必须遵守的保密或隐私政策或法规。如果这些都已记录在业务规则库中，参考它们即可。
6.4 安全性
这里规定的需求涉及产品在使用过程中可能遭受的损失、破坏或伤害。规定必须采取的安全保障措施或行动以及必须预防的有潜在危险的行动。确定产品必须遵守的安全证书、政策或法规。
6.x【其他]
针对每一个额外的产品质量属性，在软件需求规范说明中单独设置一节来描述对客户、开发人员和维护人员都很重要的特征。这些需求可能涉及易用性、效率、可安装性、完整性、互操作性、可修改性、可移植性、可靠性、可重用性、稳健性、可扩展性和可验证性。
7.国际化和本地化需求
国际化和本地化需求确保产品适用于不同国家、文化和地理区域而非产品开发所在地。此类需求注重的是货币的差异;日期格式、数字、地址和电话号码;语言(包括不同国家对同种语言的拼写习惯，例如美式英语与英式英语)、使用的符号和字符设置;姓氏和名字的顺序;时区;国际法律法规;文化和政治问题;所用纸张尺寸;度量衡;电压和插头形状;等等。国际化和本地化需求可以跨项目重复使用。
8.[其他需求]
定义软件需求规范说明中没有涵盖的其他一些需求。例如与法律、法规或财务合规和标准相关的需求;用于产品安装、配置、启动和关闭的需求;用于登陆、监测和审计跟踪的需求。不能简单地把上述这些都划归到“其他”名下，任何与你项目有关的新内容都要添加到模板之中。如果这一节的需求已经出现在其他小节，就将其省略。
附录 A:词汇表
定义所有专用词条，以便读者能够理解软件需求规范说明，包括首字母缩略词和缩写词。将每个首字母缩略词拼写出来并给出定义。可以考虑建立一个可重复利用的企业级词汇表，此表可以跨项目使用，并且吸纳与本项目相关的其他术语。然后，每个软件需求规范说明只定义针对单个项目、不出现在企业级词汇表中的术语。注意:数据定义属于数据字典，而非词汇表。
附录B:分析模型
这一节是可选，包含或涉及相关的分析模型，例如数据流程图、特性树、状态转化图或是实体关系图。如果将相关模型放在规范说明的相关章节之中，而不是将其放在结尾处，对读者的帮助会更大。
