软件需求说明书，又称软件需求规格说明书，英文名为Software Requirements Specification（SRS），是需求人员在需求分析阶段需要完成的产物。它的作用是作为用户和软件开发者达成的技术协议书，作为设计工作的基础和依据，作为测试和验收的依据。

软件需求说明书应该完整、一致、精确、无二义性，同时又要简明、易懂、易修改。在一个团队中，须用统一格式的文档进行描述，为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和开发团队的特点对标准模板进行适当的改动，形成自己的模板。

下面介绍几种常用的软件需求说明书模板：

1、RUP版本

RUP（Rational Unified Process），统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。RUP是由Rational软件公司（Rational公司被IBM并购）创造的软件工程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程，适用于大型软件团队开发大型项目。

以下是一个标准的RUP文档模板：

模板说明：

在RUP中指出“用例视图是由活动图、用例图、类图组成的”。但上面的文档模板缺失活动图和类图。换句话说，这份需求模板最主要缺少的内容就是串起用例之间的行为逻辑的“流程”信息（用活动图表示），以及描述领域数据之间的关系、它们构成的信息（用类图表示）。

建议要么在这个需求规约的基础上补充这两类信息，要么就用一个UML模型来补充它（可以使用Rose、Together之类的建模工具）。

实际的应用中该模板中的信息不够完整，因为在RUP中所采用的需求描述策略是“模型为主、文档为辅”，也就是说，“需求模型”推荐使用Rose创建“用例规约”才是完整的。

2、Volere版本

Atlantic System Guild公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术，是一个十分实用、完善的SRS模板。

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）

4、国标ISO版本（2006）

新模板的第1和第2小节实际上起到的作用还是“引言”的作用，不过在具体的内容上还是做出了不小的调整。

首先是做了一些扩展，包括将“编写目的”扩充为“文档概述”，将“背景”扩展为“系统概述”，同时也更明确地指出了它应该包含的内容。

然后是做了一些剪裁和调整，包括将“定义”小节去掉了（放在最后的“注释”部分中），这和我们前面的分析比较类似，该信息更适合单独来管理；另外还将“参考资料”更精确地定义为“引用文件”，并将其作为单独的章节。

另外还做了一些补充，增加了“标识”和“基线”，它们是近代软件工程理论的产物，用来实现需求的跟踪和需求基线管理。

新版本相对老版本做了以下两点的更新：

①对“需求规定”进行了详细的分拆。

新模板一改上一版本中简单的风格，对“需求规定”小节提供了更加完整、全面的分解，并且将原先的“运行环境规定”部分也整合进来了。但是从最终的效果上来看，通用性被强化了，适用性被减弱了，因此在实际应用中应根据需要对其进行必要的剪裁。

另外，为了帮助大家能够更好地理解新模板中对“需求规定”小节所分出的24个子部分，我们再对其做一些简要的说明，如下表所示：

②增加了一些提升文档功能性的内容

新模板的第4〜7小节实际上是为了提高整个软件需求规格说明书的功能性；合格性规定是针对测试团队、验收团队的信息；需求可追踪性是针对项目管理人员的信息；尚未解决问题、注释则是为了帮助读者更好地理解、使用文档。

5、SERU版本

SERU是一套系统全面的需求方法论，适合中国国情，尤其对ToB类软件的需求文档编写有较好的指导作用。

以上部分和第4部分（具体需求部分)，实际上是对老版本的国标模板中“3.1对功能的规定”小节的分解，以便让软件需求规格说明书的作者更加有的放矢地组织所需的信息。

需求概述部分的主要内容是针对中层用户代表的，其核心内容在于对业务知识的梳理，目标在于导出系统的用例模型和领域模型，是需求分析第一阶段（理清框架和脉络）的工作任务。简单地说，就是：

•首先将系统按业务的特点分成不同的子问题域（主题域)，并且通过构件图整理出它们之间的接口。

•对每个子问题域（主题域）进行分解，标识出与系统相关的业务流程（业务事件是流程的起点）、报表类型。

•然后绘制每个业务流程的流程图，将流程中涉及的业务实体之间的关系、结构规则用领域类图片段表示出来，并根据“是否在系统边界之内”的原则从流程图中派生出用例图。

•同时对于每类报表而言，用领域类图片段表示出其涉及的业务实体，用用例图表示具体的报表项。

因此这个部分实际上就是采用一个业务驱动的树型结构（主题域、业务流程、报表类型）贯穿的业务知识，它框出了系统所需完成的行为需求，以及它涉及的结构需求。

这部分内容在老版本的国标模板中并没有涉及，但在新版本的国标模板中就增加了这方面的信息，即“3.3需求规格”小节，但具体的组织方法未定义。而在RUP版本的模板中也没有明确地指出，但这部分信息实际上是从属于需求模型的。

以上部分是针对具体的开发人员和操作层的用户代表的，它将描述最为细节的需求信息；由于该模板是针对“用例分析技术”的，因此选择“用例”作为行为需求的最小单元，“领域类”作为结构需求的最小单元；换句话说，就是填充用例和领域类的细节。

在这个部分中，参考了RUP版本的模板，并对用例模板进行了适当的扩展，将每个具体的报表项定义为一个报表类（R)用例，每个具体的接口定义为一个接口类（I)用例，同时为它们分别定义了不同的格式模板。另外，也对领域类应该填充什么方面的内容进行了约定。

而在国标版本（包括老版本和新版本）、Volere版本的模板中，由于它们并不限定某种需求分析技术，因此采用了更通用的表示方法；因此在使用之前，建议还是应该对其做进一步的定义与约定。

除了结构需求、行为需求之外的其他需求都应放在“补充规约”这一部分中，在RUP版本的模板中采用了相同的组织方法；而在国标模板（包括新、老版本）、Volere模板中则是将它们打开，每个部分一个小节，区别仅在于展开的程度各有不同。

我们根据在业务系统中经常涉及的内容对补充规约分成了三类：一是设计约束；二是质量属性；三是其他内容。

对于设计约束而言应该包括技术选择的限制条件（也就是非技术因素决定的技术选型）、运行环境（也就是预期的软、硬件环境，通常可以使用部署图表示）以及预期的使用环境。这些内容在新版本的国标模板中也有详细的划分。

而对于质量属性而言，建议直接分解到要开发什么功能上，并根据对开发的影响提供了一个树形结构。

此外还可以涉及培训、后勤、包装、升级等其他方面的需求，这在新国标版本的模板、Volere模板中都归纳了一些，大家可以参考。