软件需求说明书，又称软件需求规格说明书，英文名为Software Requirements Specification（SRS），是需求人员在需求分析阶段需要完成的产物。它的作用是作为用户和软件开发者达成的技术协议书，作为设计工作的基础和依据，作为测试和验收的依据。
软件需求说明书应该完整、一致、精确、无二义性，同时又要简明、易懂、易修改。在一个团队中，须用统一格式的文档进行描述，为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和开发团队的特点对标准模板进行适当的改动，形成自己的模板。
下面介绍几种常用的软件需求说明书模板：
- RUP版本
- Volere版本
- 国标ISO版本
- SERU版本
1、RUP版本
RUP（Rational Unified Process），统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。RUP是由Rational软件公司（Rational公司被IBM并购）创造的软件工程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程，适用于大型软件团队开发大型项目。
以下是一个标准的RUP文档模板：
1.文档概述这个部分是欧美标准文档通用的格式：首先指出文档的目的、目标读者及各类读者的要点（目的小节)；然后说明项目的背景信息（背景小节)；接着是文档中出现的术语和缩略语（定义、首字母缩写词和缩略语小节)；再接着则是该文档所引用的参考资料（参考资料小节)；最后则是概要地表达本文档的内容（概述小节)。 1.1目的1.2背景1.3定义、首字母缩写词和缩略语1.4参考资料1.5概述****2.整体说明 [让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。] 2.1用例模型2.2假设与依赖关系这个部分的内容是用来使读者建立一个框架性认识的。在写作指南中指出，应该写明产品的总体效果、产品功能、用户特征（也就是国标版本中的用户特点）、假设与依赖关系（专门开辟了一个小节)、需求子集（当系统需要多层分解时将使用它）。在RUP的相关示例中，还在本部分中使用了上下文关系图。 另外，这个部分显然最重要的是系统的用例模型！因为在RUP中，用例是需求组织的核心元素。在此应该给出系统的总体用例图以及用例的简述。 3.具体需求3.1用例描述3.2补充需求 [易用性、可靠性、性能、其他] 显然这个部分的主要内容就是对用例模型中列出的每个用例进行详细描述。除此之外，还应该说明外部接口、质量属性、设计约束等补充需求。 4.支持信息根据该文档的写作指南中的信息，这个部分主要是用来提供目录、索引、附录、用户界面原型等信息的，以便令“软件需求规约”更易于使用。
模板说明：
在RUP中指出“用例视图是由活动图、用例图、类图组成的”。但上面的文档模板缺失活动图和类图。换句话说，这份需求模板最主要缺少的内容就是串起用例之间的行为逻辑的“流程”信息（用活动图表示），以及描述领域数据之间的关系、它们构成的信息（用类图表示）。
建议要么在这个需求规约的基础上补充这两类信息，要么就用一个UML模型来补充它（可以使用Rose、Together之类的建模工具）。
实际的应用中该模板中的信息不够完整，因为在RUP中所采用的需求描述策略是“模型为主、文档为辅”，也就是说，“需求模型”推荐使用Rose创建“用例规约”才是完整的。
2、Volere版本
Atlantic System Guild公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术，是一个十分实用、完善的SRS模板。
Part Ⅰ：项目驱动
1.项目的目标
1.1该项目工作的用户业务或背景
1.2项目的目标
2. 客户、顾客和其他风险承担者
2.1客户
2.2顾客
2.3其他风险承担者
3. 产品的用户
3.1产品的直接操作用户
3.2对用户设定的优先级
3.3用户参与程度
3.4维护用户和服务技术人员PartII:产品限制条件
4. 强制的限制条件
4.1解决方案的限制条件
4.2当前系统的实现环境
4.3伙伴应用或协作应用
4.4立即可用的软件
4.5预期的工作地点环境
4.6进度计划限制条件
4.7该产品的财务预算
5. 命名惯例和定义
5.1定义在项目中使用的所有术语，包括同义词
5.2所有包含模型的数据字典
6. 相关事实和假定
6.1事实
6.2假定PartIII:功能性需求
7. 工作的范围
7.1当前的状态
7.2工作的上下文范围
7.3工作切分
8. 产品的范围
8.1产品边界
8.2产品用例清单
8.3单个产品用例
9. 功能性需求与数据需求
9.1功能性需求
9.2数据需求PartIV:非功能需求
10. 观感需求
10.1外观需求
10.2风格需求
11. 易用性和人性化需求
11.1易于使用的需求
11.2个性化和国际化需求
11.3学习的容易程度
11.4可理解性和礼貌需求
11.5可用性需求
12执行需求
12.1速度和延迟需求
12.2安全性至关重要的需求
12.3精度需求
12.4可靠性和可访问性需求
12.5健壮性或容错需求
12.6容量需求
12.7可伸缩性和可扩展需求
12.8寿命需求
13. 操作需求
13.1预期的物理环境
13.2与相邻系统接口的需求
13.3产品化需求
13.4发布需求
14. 可维护性和支持需求
14.1可维护性需求
14.2支持需求
14.3适应能力需求
15. 安全需求
15.1访问控制需求
15.2完整性需求
15.3稳私需求
15.4审计需求
15.5免疫力需求
16. 文化和政策需求
16.1文化需求
16.2政策需求
17. 法律需求
17.1合法需求
17.2标准需求PartV:项目问题
18. 开放式问题
19. 立即可用的解决方案
19.1已经做好的产品
19.2可复用的组件
19.3可以复制的产品
20. 新问题
20.1对当前环境的影响
20.2对已实施系统的影响
20.3潜在的用户问题
20.4预期的实现环境会存在什么限制新产品的因素
20.5后续问题
21. 任务
21.1项目计划
21.2开发阶段计划
22. 迁移到新产品
22.1迁移到新产品的需求
22.2为了新系统，哪些数据必须修改或转换
23. 风险
24. 费用
25. 用户文档和培训
25.1用户文档需求
25.2培训需求
26. 后续版本需求
27. 关于解决方案的设想
3、国标ISO版本（1998）
1. 引言1.1编写的目的我经常会在一些需求规格说明书中看到类似于“为了更好地完成本次软件的开发，经过详细的用户调查……”之类的描述。每当看到的时候，我就会问作者：“这段话有什么用呢？”作者通常会回答“那应该写什么呢？” 其实如果你认真地阅读过相应的指南，就会发现本小节的本意应该是：指出本文档所针对的读者对象，以及每类读者对象应该重点阅读的部分。那么软件需求规格说明书有哪些不同的读者对象呢？它们的阅读重点又应该有什么不同呢？ 第一个方面的区别显然是读者背景，很多软件需求规格说明书对业务背景的读者照顾不足，这样会导致用户评审变得困难。因此如果在此能够说明不同背景的读者应该重点阅读哪些内容是不错的办法。 第二个方面的区别是用户的层次：高层用户关心业务需求（目标与范围），也就是偏重于阅读任务概述、目标这些小节；中层用户关心业务事件、Stakeholder关注点,也就是偏重于阅读每个子系统中的分解、流程图以及一些利益点分析；操作层用户关心业务活动，也就是偏重于阅读用例的描述。 第三个方面的区别是用户所属的业务区域，如果需求规格说明书中的内容能够体现这种区域划分，就能够使读者更好地评审。 1.2背景****1.3定义 [本文件中用到的专门术语的定义和外文首字母组词的原词组。] 1.4参考资料 [列出用得着的参考资料。] 2. 任务概述****2.1目标 [叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。] 2.2用户的特点 [列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。] 2.3假定和约束 [列出进行本系统开发工作的假定和约束。] 3. 需求规定****3.1对功能的规定 [用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。] 这个部分是最为核心的内容，通常会占整份文档的60%〜70%的篇幅；可是模板中只是定义了该小节，里面该如何组织并没有明确地定义出来，那么如何保证每个人写出来的东西具有相近的风格呢？ 这实际上就是通用型模板和企业模板的区别，作为通用型模板是无法定义到更细的程度的，因为不同的软件项目、不同的团队、不同的开发方法必然会采用不同的组织方法。因此我们在使用之前，必须对这个部分做进一步的细化。 另外，在该标准中建议直接用“条目”来定义需求，而这种方法最大的问题是数量大、粒度不统一，因此现代软件需求理论实际上更建议使用用例、用户故事、特性之类的组织单元来代替这种风格的表述。 3.2对性能的规定这个部分经常被理解成非功能需求的全部，同时导致了一种误解：所有非功能需求都应该单独地罗列出来，这样都经常出现“全局性”非功能需求，但实际上有很多是“局部性”的，我们应该让它和相应的功能需求同时出现。 其实，如果我们认真阅读指南就会发现，在针对“对功能的规定”小节的指南中，有一句“说明系统的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标”，这显然是非功能需求。 3.2.1精度3.2.2时间特性要求3.2.3灵活性3.3输入/输出要求这个部分具有很强的历史性，在当时输入、输出设备并不是只有键盘、鼠标、打印机，还有列表机、纸带机等形式多样、功能不同的其他设备。因此在软件开发之前,是有必要做相应描述的。 而在今天的很多软件中，这个部分是比较单一的，因此可以考虑将这个部分内容从模板中去除。 3.4数据管理能力要求（针对软件系统） 在该标准制定时，数据库并不是最流行的或唯一的数据管理机制，开发人员可能会需要直接使用外部文件等方法。而今天的情况完全不同，数据管理基本上是交由数据库管理系统实现的，因此通常也不会需要本小节。 不过也有一些软件系统有例外的情况，例如地理信息系统、实验数据管理平台都可能涉及这一部分。对于地理信息系统而言，有许多数据不是直接存储到数据库中的，它涉及各种图层信息应该以什么格式保存、如何保存、如何组织等；对于实验数据管理平台也是这样，数据量极大，数据库无法解决，需要开发人员另想办法，这也就涉及到了数据管理能力方面的信息。 3.5故障处理要求这个部分在很多信息系统中是相对较弱的，因此可以将其合并到“其他专门要求”中，或者归类为“补充规约”也是不错的做法。 **3.6其他专门要求4. 运行环境规定这个部分的信息，现在的绝大多数软件也都会遇到；在UML中建议用部署图对其进行建模，并纳入“补充规约”中。在这份模板中定义了以下几个方面内容： •设备：用到的硬件资源； •软件：预期的操作系统、中间件、数据库、第三方软件等软件环境资源； •接口：所需的外部系统接口； •控制：这个部分有些过时，在诸如CIMS(计算机集成制造系统）之类的软件中就经常会涉及控制信号方面的规定。 4.1设备 [列出运行该软件所需要的硬设备。说明新型设备及其专门功能。] 4.2支持软件 [列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。] 4.3接口 [说明该系统同其他系统之间的接口、数据通信协议等。] 4.4控制 [说明控制该系统的运行方法和控制信号，并说明这些控制信号的来源。]
4、国标ISO版本（2006）
新模板的第1和第2小节实际上起到的作用还是“引言”的作用，不过在具体的内容上还是做出了不小的调整。
首先是做了一些扩展，包括将“编写目的”扩充为“文档概述”，将“背景”扩展为“系统概述”，同时也更明确地指出了它应该包含的内容。
然后是做了一些剪裁和调整，包括将“定义”小节去掉了（放在最后的“注释”部分中），这和我们前面的分析比较类似，该信息更适合单独来管理；另外还将“参考资料”更精确地定义为“引用文件”，并将其作为单独的章节。
另外还做了一些补充，增加了“标识”和“基线”，它们是近代软件工程理论的产物，用来实现需求的跟踪和需求基线管理。
1.范围****1.1标识 [本文档适用的系统和软件的完整标识] 1.2系统概述 [适用的系统和软件的用途；开发、运行、维护历史] 1.3文档概述 [文档的用途和内容] 1.4基线2.引用文件3.需求****3.1所需的状态和方式 [软件项是否在多种状态和方式下运行] 3.2需求概述****3.2.1目标 [表述系统的目标和范围] 3.2.2运行环境3.2.3用户特点3.2.4关键点 [关键功能、关键算法、关键技术] 3.2.5约束条件3.3需求规格3.3.1软件系统总体功能/对象结构 [对软件系统总体功能/对象结构进行描述，包括结构图、流程图或对象图] 3.3.2软件子系统功能/对象结构 [对每个主要子系统中的基本功能模块/对象结构进行描述，包括结构图、流程图或对象图] 3.3.3描述约定****3.4软件配置项能力要求 [可用功能、性能、目标或类似词代替“能力”] 3.4.X [包括能力的说明、输入、处理、输出] 3.5外部接口需求3.5.1接口标识和接口图3.5.X具体接口 [说明接口优先级、接口类型、数据元素特性、数据元素集合、接口通信方法、必须使用的接口协议等] 3.6内部接口需求3.7内部数据需求3.8适应性需求 [提供的依赖于安装的数据有关的需求] 3.9保密性需求 [诸如防止意外动作和无效动作所必须提供的安全措施] 3.10保密性和私密性需求3.11环境需求3.12计算机资源需求3.12.1计算机硬件需求3.12.2计算机硬件资源利用需求3.12.3计算机软件需求3.12.4计算机通信需求3.13软件质量因素3.14设计和实现的约束3.15数据3.16操作3.17故障处理3.18算法说明3.19有关人员需求3.20有关培训需求3.21有关后勤需求3.22其他需求3.23包装需求3.24需求的优先次序和关键程度****4.合格性规定 [可以独立，也可以直接在前面注明方法，包括演示、测试、分析、审查、其他特殊方法] 5.需求可追踪性6.尚未解决问题7.注释
新版本相对老版本做了以下两点的更新：
①对“需求规定”进行了详细的分拆。
新模板一改上一版本中简单的风格，对“需求规定”小节提供了更加完整、全面的分解，并且将原先的“运行环境规定”部分也整合进来了。但是从最终的效果上来看，通用性被强化了，适用性被减弱了，因此在实际应用中应根据需要对其进行必要的剪裁。
另外，为了帮助大家能够更好地理解新模板中对“需求规定”小节所分出的24个子部分，我们再对其做一些简要的说明，如下表所示：
②增加了一些提升文档功能性的内容
新模板的第4〜7小节实际上是为了提高整个软件需求规格说明书的功能性；合格性规定是针对测试团队、验收团队的信息；需求可追踪性是针对项目管理人员的信息；尚未解决问题、注释则是为了帮助读者更好地理解、使用文档。
5、SERU版本
SERU是一套系统全面的需求方法论，适合中国国情，尤其对ToB类软件的需求文档编写有较好的指导作用。
1.文档概述在本小节中将说明整个文档所针对的不同读者群（编写目的）、整个项目的背景和概况信息（背景)、文档中常用的技术缩略语及相关词条（定义)，以及文档编写时所需引用、参考的资料（参考资料）。 1.1编写的目的1.2背景1.3定义1.4参考资料在老版本的国标模板、RUP提供的模板中都有相似小节，这个部分是规范的文档所应该具有的信息。 2.任务概述2.1业务需求2.2 Stakeholder利益分析2.3用户特点分析2.4相关事实与假定也就是项目目标、Stakeholder关注点、用户特点、相关事实与假定之类的概述性信息，这部分信息通常是需求定义（项目立项）阶段就需要确定的，属于业务需求的范畴，是中高层用户代表所关心的内容。这部分内容单独地放在一个小节中。当然，这个阶段还将产生一个十分重要的内容，也就是项目范围，但为了便于阅读，将其作为第3部分（需求概述）的纲要出现。 3.需求概述****3.1系统概述 [主题域划分，用构件图表述] 3.2主题域1****3.2.1概述 [用上下文关系图表示该主题域的范围] 3.2.2业务事件****3.2.2.1业务事件1 [包括流程分析、领域类分析、用例分析] 3.2.2.n业务事件N3.2.3报表3.2.3.1Report1 [用领域类图片段表示涉及数据，用用例标识具体的报表项] 3.2.3.N Reportn****3.3主题域n
以上部分和第4部分（具体需求部分)，实际上是对老版本的国标模板中“3.1对功能的规定”小节的分解，以便让软件需求规格说明书的作者更加有的放矢地组织所需的信息。
需求概述部分的主要内容是针对中层用户代表的，其核心内容在于对业务知识的梳理，目标在于导出系统的用例模型和领域模型，是需求分析第一阶段（理清框架和脉络）的工作任务。简单地说，就是：
•首先将系统按业务的特点分成不同的子问题域（主题域)，并且通过构件图整理出它们之间的接口。
•对每个子问题域（主题域）进行分解，标识出与系统相关的业务流程（业务事件是流程的起点）、报表类型。
•然后绘制每个业务流程的流程图，将流程中涉及的业务实体之间的关系、结构规则用领域类图片段表示出来，并根据“是否在系统边界之内”的原则从流程图中派生出用例图。
•同时对于每类报表而言，用领域类图片段表示出其涉及的业务实体，用用例图表示具体的报表项。
因此这个部分实际上就是采用一个业务驱动的树型结构（主题域、业务流程、报表类型）贯穿的业务知识，它框出了系统所需完成的行为需求，以及它涉及的结构需求。
这部分内容在老版本的国标模板中并没有涉及，但在新版本的国标模板中就增加了这方面的信息，即“3.3需求规格”小节，但具体的组织方法未定义。而在RUP版本的模板中也没有明确地指出，但这部分信息实际上是从属于需求模型的。
4.具体需求4.1主题域14.1.1用例模型****4.1.1.1UC_B_xx(B类) (1) 概述[编号、名称、概述、相关Stakeholder] (2) 事件流描述[前、后置条件，基本、扩展、子事件流] (3) 相关需求与功能点 (4) 界面原型[交互过程与界面详解] (5) 规约与约束4.1.1.2UC_R_xx(R类) (1) 概述 [名称、用户部门与职位、业务意图、相关场景] (2) 报表内容[领域类图、数据项] (3) 输入/输出格式 (4) 其他4.1.1.3UC_I_xx(I类) (1)使用者[名称、业务目的、时机、频率] (2)内容与格式[交互过程、数据包说明] (3)设计与实现约束[诸如协议格式要求、性能要求等] 4.1.2领域模型****4.1.2.1xx领域类 (1)概述 [类名称、别名] (2)数据窗口分析 [涉及主题域、业务事件，各域数据] (3)数据组成与格式 (4)其他4.N主题域n
以上部分是针对具体的开发人员和操作层的用户代表的，它将描述最为细节的需求信息；由于该模板是针对“用例分析技术”的，因此选择“用例”作为行为需求的最小单元，“领域类”作为结构需求的最小单元；换句话说，就是填充用例和领域类的细节。
在这个部分中，参考了RUP版本的模板，并对用例模板进行了适当的扩展，将每个具体的报表项定义为一个报表类（R)用例，每个具体的接口定义为一个接口类（I)用例，同时为它们分别定义了不同的格式模板。另外，也对领域类应该填充什么方面的内容进行了约定。
而在国标版本（包括老版本和新版本）、Volere版本的模板中，由于它们并不限定某种需求分析技术，因此采用了更通用的表示方法；因此在使用之前，建议还是应该对其做进一步的定义与约定。
5.补充规约5.1设计约束5.1.1技术选择的限制条件****5.1_2运行环境 [建议使用部署图表示] 5.1.3预期的使用环境****5.2质量属性 [本部分建议直接分解成需要开发的技术功能点] 5.2.1安全性要求5.2.1.1访问安全性要求5.2.1.2数据安全性要求5.2.1.3通信安全性要求5.2.1.4其他安全性要求5.2.2可靠性要求5.2.2.1容错性要求5.2.2.2可恢复性要求5.2.2.3其他可靠性要求5.2.3易用性要求5.2.3.1界面友好性要求5.2.3.2易操作性要求5.2.3.3其他易用性要求5.2.4性能要求5.2.4.1数据访问性能要求5.2.4.2数据传输性能要求5.2.4.3其他性能要求5.2.5可维护性要求5.2.5.1公共数据要求5.2.5.2公共框架开发要求5.2.5.3公共程序库开发要求5.2.5.4其他可维护性要求5.2.6可移植性要求5.2.6.1适应性要求5.2.6.2易安装性要求5.2.6.3其他可移植性要求5.2.7其他质量属性要求5.3其他需求5.3.1培训需求5.3.2后勤需求5.3.3包装需求
除了结构需求、行为需求之外的其他需求都应放在“补充规约”这一部分中，在RUP版本的模板中采用了相同的组织方法；而在国标模板（包括新、老版本）、Volere模板中则是将它们打开，每个部分一个小节，区别仅在于展开的程度各有不同。
我们根据在业务系统中经常涉及的内容对补充规约分成了三类：一是设计约束；二是质量属性；三是其他内容。
对于设计约束而言应该包括技术选择的限制条件（也就是非技术因素决定的技术选型）、运行环境（也就是预期的软、硬件环境，通常可以使用部署图表示）以及预期的使用环境。这些内容在新版本的国标模板中也有详细的划分。
而对于质量属性而言，建议直接分解到要开发什么功能上，并根据对开发的影响提供了一个树形结构。
此外还可以涉及培训、后勤、包装、升级等其他方面的需求，这在新国标版本的模板、Volere模板中都归纳了一些，大家可以参考。
