软件需求说明（Software Requirements Specification，SRS）的编制是为了使用户和软件开 发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。根据国标 GB/T93852008 计算机软件需求规格说明规范的要求，软件需求说明包括以下的内容：
1 引言
SRS 的引言部分应当提供整个 SRS 的概述，包括以下各条：目的；范围；定义、简称和 缩略语；引用文件；综述。
1.1 目的
描述 SRS 的目的；说明 SRS 的预期读者。
1.2 范围
通过名称识别要生产/开发的软件产品；必要时说明软件产品将要或不做什么；描述规定 的软件的应用，包括相关的收益、目标和目的；如果上层规格说明（如系统规格说明）存在，
与上层规格说明类似的陈述保持一致。
1.3 定义、简称和缩略语
本条提供对正确解释 SRS 所要求的所有术语、简写和缩略语的定义，这些信息可以通过 引用 SRS 中的一个或多个附录、或者引用其他文件的方式来提供。
1.4 引用文件
提供 SRS 引用的所有文件的完整清单；标识出每个文件的名称、报告编号（适用时）、日 期、出版组织；标明可以获得引用其他文档的方式。
1.5 综述
描述 SRS 的其余章条包含的内容；说明 SRS 是如何组织的。
2 总体描述
描述影响产品及其需求的一般因素，而不叙述具体的需求。相反，它提供需求的背景并 使它们更易理解，在 SRS 的第 3 章将详细定义这些需求。
产品描述；产品功能；用户特点；约束；假设和依赖关系和需求分配等。
2.1 产品描述
把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，这里宜如 实给予陈述。正如平常出现的那样，如果 SRS 定义的产品是较大系统的组成部分，则本章宜 将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接口。
使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的。
更高层规格说明本条也宜描述在各种不同的约束下软件如何运行，如这些约束包括：系 统接口；用户界面；硬件接口；软件接口；通信接口；内存；运行；现场适应性需求。
2.2 产品功能
给出软件将执行主要功能的概要。例如，某个会计程序的 SRS 可在此部分关注客户账户 维护、客户财务报表及发票准备，而不涉及这些功能要求的大量细节。
有时，本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明（如果 存在）中摘录。为了清晰，应当注意：功能宜以这样的方式组织，以使顾客或第一阅读该文件 的任何读者对功能列表容易理解； 可以使用文本或图示的方法， 显示不同的功能及其之间的关 系。这样的图示不比现实产品的设计，但简要显示变量之间的逻辑关系。
2.3 用户特点
给出软件产品预期用户的一般特征，包括教育程度、经验、专业技术情况。它不宜指出 具体的需求，但宜给出 SRS 第 3 章中为何规定某些具体需求的原因。
2.4 约束
给出将会限制开发人员选择的其他事项的一般描述。包括：法规政策；硬件局限（如信 号时间要求）；与其他应用接口；并行操作；审核功能；控制功能；高级语言需求；信号握手 协议（如 XONXOFF、ACKNACK）；可靠性需求；使用的关键性；安全和保密安全考虑。
2.5 假设和依赖关系
列出影响 SRS 规定需求的每个因素。这些因素不是软件设计的限制条件，但是，它们的 任何变更可能影响 SRS 中的需求。例如，某个假设可能是软件产品制定的硬件具有某个特定 操作系统，如果事实上该操作系统不能使用，那么 SRS 将做相应的修改。
2.6 需求分配
识别可能推迟到系统将来版本的需求。
3 具体需求
本章宜包括足够详细的所有软件需求，使设计人员能够设计系统以满足这些需求，并且
使测试人员能够测试该系统满足这些需求。贯穿本章，对于用户、运行人员或其他外部系统，
每个规定的需求应当是外部可理解的。这些需求至少应当包括，每个系统输入（激励）、每个 系统输出（响应） ，以及系统通过响应某个输入或支持某个输出所执行的所有功能。由于这通 常是 SRS 篇幅最大和最主要部分，以下原则适用：规定的具体需求宜符合好的 SRS 的特征；
具体需求宜引用较早的相关文件；所有的需求宜是唯一可标识的；宜注意需求组织，使其具有 最大的可读性。
在考察组织需求的具体方式之前，了解 3.1 到 3.6 组成需求的各个不同项是有益的。
3.1 外部接口需求
本条宜是软件系统所有输入和输出的详细描述。它宜是对前面的接口描述的补充，不宜 重复前面已有的信息。
宜包括以下内容和格式：项的名称；目的描述；输入源和输出目的地；有效范围、准确 度和/或容限；测量单位；定时；与其他输出/输入的关系；屏幕显示/组织；窗口格式/组织；
数据格式；命令格式；结束消息。
3.1.1 用户界面
指出用户使用软件产品时的界面需求。若用户通过显示终端操作，则需指定如下需求：
对屏幕格式的要求；报表或菜单的页面显示格式及内容；用户命令的格式。列出输出错误信息 的格式。尽可能采用开发工具构造界面，使需求定义和设计、编码相衔接，应遵从《界面设计 规范》。
3.1.2 硬件接口
软件产品与系统硬设备之间每一接口的逻辑特点；硬件接口支持的设备；软件与硬件接 口之间以及硬件接口与支持设备之间的约定。
3.1.3 软件接口
描述该软件产品与其他有关软件接口关系，并指出这些软件的名字、助记符及版本号。
3.1.4 通信接口
说明各种通信接口及协议。
3.2 类/对象 3.2.1 类/对象 1
3.2.1.1 属性（直接的或继承的）
3.2.1.1.1 属性 1
……
3.2.1.1.n 属性 n
3.2.1.2 功能（服务、方法、直接的或继承的）
功能需求宜定义软件在接受和处理输入以及处理和产生输出中必须发生的基本动作。一 般情况下使用“系统应…”的方式来陈述。这些包括：对输入有效性的核查；操作的准确顺序；
异常情况，包括：溢出、通信设施、错误处理和恢复；参数影响；输入和输出的关系，包括：
输入/输出顺序、从输入到输出转换的公式。
尽管将功能需求划分为子功能或子过程可能是适当的，但这并不意味着软件设计同样以 这样的方式划分。
3.2.1.2.1 功能需求 1.1
……
3.2.1.2.m 功能需求 1.m
3.2.1.3 消息（接受的或发送的通信）
3.2.2 类/对象 2
…….
3.2.p 类/对象 p 3.3 性能需求
正常情况下和峰值工作条件下，在一定时间内要处理的数据总量；响应时间；输出结果 精度。
本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求。静态数量化需求 可能包括：支持的终端数量；支持同时运行的用户数量；要处理的信息量和类型。
有时，静态数量化需求包含在命名为“能力”的独立部分。
动态数量化需求可能包括，如在正常和高峰工作负载条件下，在某时段内处理的事务处 理数、任务数和数据量。所有这些需求宜以可测量的方式规定。如应在小于 1s 内处理 95%的 交易量，而不是操作方不需等待事务处理结束。
注：适用于某个具体功能的数量化限制，通常作为该功能处理描述部分予以规定。
3.4 设计约束
宜规定可能由其他标准、硬件局限等引发的设计约束。
3.5 软件系统属性
有一些软件属性可以作为需求。规定所需求的软件属性是重要的，这样才能客观地验证 属性的实现情况。
3.6 其他需求