软件需求规格说明书(SRS)
本款规定了软件需求规范(SRS)的规范内容。 项目应根据项目关于软件需求规范文档的政策生成以下信息项内容 1。 文档中信息项的组织方式（例如顺序和章节结构）可根据项目的文档政策选择。
1 目的
描述要指定的软件的用途。
2 范围
描述所考虑的软件的范围
- 通过名称识别要生产的软件产品（例如，主机 DBMS、报告生成器等）；
- 解释软件产品的作用；
- 描述所指定软件的应用，包括相关好处、目标和目标；
- 与更高级别规范中的类似表述保持一致（例如系统要求规范），如果存在的话。
3 产品视角
定义系统与其他相关产品的关系。 如果产品是更大系统的一个元素，则将该更大系统的要求与 SRS 涵盖的产品功能联系起来。 如果产品是更大系统的一个元素，则确定 SRS 涵盖的产品与该产品所属的更大系统之间的接口。 显示大型系统的主要元素、互连和外部接口的框图可能会有所帮助。 描述软件在以下约束条件下如何运行：
- 系统接口；
- 用户界面；
- 硬件接口；
- 软件接口；
- 通信接口；
- 记忆；
- 运营；
- 场地适应要求。
3.1 系统接口
列出每个系统接口并确定软件的功能以实现系统要求以及与系统匹配的接口描述。
3.2 用户界面
指定以下内容：
- 软件产品与其用户之间每个界面的逻辑特性。这包括实现软件要求所必需的配置特性（例如，所需的屏幕格式、页面或窗口布局、任何报告或菜单的内容，或可编程功能键的可用性）。
- 优化与使用、维护或为系统提供其他支持的人员的界面的所有方面。这可能只是包含系统如何呈现给用户的注意事项列表。一个例子可能是要求选择长或短错误消息。这也可以在“软件系统属性”中“易用性”部分下指定。
注：用户界面的风格指南可以为组织、编码以及用户与系统的交互提供一致的规则。
3.3 硬件接口
指定软件产品与系统硬件元素之间每个接口的逻辑特性。这包括配置特性（端口数量、指令集等）。它还涵盖要支持哪些设备、如何支持这些设备以及协议等事项。例如，终端支持可能指定全屏支持，而不是逐行支持。
3.4 软件接口
指定所需其他软件产品的使用（例如，数据管理系统、操作系统或数学软件包），以及与其他应用系统的接口（例如，应收账款系统与总账系统之间的链接）。对于每个必需的软件产品，指定：
- 姓名；
- 助记词；
- 规格编号；
- 版本号；
- 来源。
- 对于每个接口指定：
- 讨论与该软件产品相关的接口软件的用途。
- 接口在消息内容和格式方面的定义。没有必要详细描述任何有据可查的接口，但需要参考定义接口的文档。
3.5 通讯接口
指定各种通信接口，例如本地网络协议。
3.6 内存限制
指定主存储器和辅助存储器的任何适用特性和限制。
3.7 操作
指定用户所需的正常和特殊操作，例如
- 用户组织中的各种操作模式（例如，用户发起的操作）；
- 交互操作时间和无人值守操作时间；
- 数据处理支持功能；
- 备份和恢复操作。
注意：有时这被指定为用户界面部分的一部分。
3.8 场地适应要求
场地适应要求包括
- 定义针对特定站点、任务或操作模式的任何数据或初始化序列的要求（例如，网格值、安全限制等）；
- 为使软件适应特定环境而需要修改的站点或任务相关特征的规范特定安装。
4 产品功能
提供软件将执行的主要功能的摘要。例如，会计程序的 SRS 可以使用此部分来处理客户帐户维护、客户报表和发票准备，而无需提及每个功能所需的大量细节。有时，此部分所需的功能摘要可以直接从为软件产品分配特定功能的高级规范部分（如果存在）中获取。请注意，为了清晰起见
- 产品功能的组织方式应使功能列表易于理解收单方或任何第一次阅读该文件的人。
- 可以用文字或图形的方式展示不同的功能及其关系。这种图表并非为了展示产品的设计，而只是展示变量之间的逻辑关系。
5 用户特征
描述产品目标用户群的一般特征，包括可能影响可用性的特征，例如教育水平、经验、残疾和技术专长。此描述不应陈述具体要求，而应说明为什么某些具体要求随后在子条款 9 中的具体要求中指定。注：适当时，SyRS 和 SRS 的用户特性应该一致。
6 限制
提供限制供应商 2选择的任何其他项目的一般描述，包括
- 监管政策；
- 硬件限制（例如信号时序要求）；
- 与其他应用程序的接口；
- 并联运行；
- 审计职能；
- 控制功能；
- 高阶语言要求；
- 信号握手协议（例如 XON‐XOFF、ACK‐NACK）；
- 质量要求（例如可靠性）；
- 应用的关键性；
- 安全和保障考虑；
- 身体/精神方面的考虑。
7 假设和依赖关系
列出影响 SRS 中所述要求的每个因素。这些因素不是软件的设计约束，但这些因素的任何变化都会影响 SRS 中的需求。例如，假设软件产品指定的硬件上将有特定的操作系统。如果实际上没有该操作系统，则 SRS 必须进行相应更改。
8 需求分配
将软件需求分配到软件元素。对于需要在多个软件元素上实施的需求，或者最初未定义对某个软件元素的分配，应如此说明。应使用按功能和软件元素交叉引用的表格来汇总分配情况。确定可能会延迟到系统未来版本的需求（例如，块和/或增量）。
9 具体要求
将所有软件需求指定到足够的详细程度，以使设计人员能够设计出满足这些需求的软件系统。将所有软件需求指定到足够的详细程度，以使测试人员能够测试软件系统是否满足这些需求。至少，描述软件系统的每个输入（刺激）、软件系统的每个输出（响应）以及软件系统响应输入或支持输出而执行的所有功能。具体要求应：
- 符合本国际公约第 5.2 条所述的所有特征标准。
- 交叉引用相关的早期文件。
- 具有唯一性。
10 外部接口
定义软件系统的所有输入和输出。该描述应补充 3.3.1 至 3.3.5 中的接口描述，并且不应重复那里的信息。每个接口定义应该包含如下内容：
- 产品名称；
- 目的描述；
- 输入的来源或输出的目的地；
- 有效范围、准确度和/或公差；
- 计量单位；
- 时间安排；
- 与其他输入/输出的关系；
- 屏幕格式/组织；
- 窗口格式/组织；
- 数据格式；
- 命令格式；
- 结束信息。
11 函数
定义软件在接受和处理输入以及处理和生成输出时必须采取的基本操作，包括
- 输入的有效性检查
- 确切的操作顺序
- 对异常情况的响应，包括
- 溢出
- 通讯设施
- 错误处理和恢复
- 参数的影响
- 输出与输入的关系，包括
- 输入/输出序列
- 输入到输出转换公式
将功能需求划分为子功能或子流程可能是合适的。但这并不意味着软件设计也要按此方式划分。
12 可用性要求
定义可用性（使用质量）要求。软件系统的可用性要求和目标包括特定使用环境中可衡量的有效性、效率和满意度标准。
13 性能要求
指定对软件或人机与软件整体交互的静态和动态数值要求。静态数值要求可能包括以下内容：
- 支持的终端数量；
- 所支持的同时用户数量；
- 需要处理的信息的数量和类型。
静态数值要求有时会在名为“容量”的单独部分中列出。动态数值要求可能包括交易和任务的数量以及在正常和峰值工作负载条件下在特定时间段内需要处理的数据量。性能要求应该以可衡量的术语来表述。例如，95%的交易将在 1 秒内处理。而不是，操作员不必等待交易完成。
注：应用于某一特定功能的数值限制通常作为该功能处理子段描述的一部分来指定。
14 逻辑数据库要求
指定要放入数据库的任何信息的逻辑要求，包括：
- 各种功能所使用的信息类型；
- 使用频率；
- 访问能力；
- 数据实体及其关系；
- 完整性约束；
- 数据保留要求。
15 设计约束
指定外部标准、监管要求或项目限制对系统设计施加的约束。
16 标准合规性
指定来自现有标准或法规的要求，包括：
- 报告格式
- 数据命名
- 会计程序
- 审计追踪
例如，这可以指定软件跟踪处理活动的要求。某些应用程序需要此类跟踪才能满足最低监管或财务标准。例如，审计跟踪要求可能规定，工资数据库的所有更改都应记录在跟踪文件中，其中包含前后值。
17 软件系统属性
指定软件产品所需的属性。以下是部分示例列表：
- 可靠性：指定在特定时间建立软件系统所需可靠性所需的因素交付。
- 可用性：指定保证整个系统定义的可用性级别所需的因素，例如检查点、恢复和重启。
- 安全性 3：指定保护软件免遭意外或恶意访问、使用修改、破坏或泄露的要求。此领域的具体要求可能包括：
- 利用某些加密技术；
- 保存特定的日志或历史数据集；
- 将某些功能分配给不同的模块；
- 限制程序某些区域之间的通信；
- 检查关键变量的数据完整性；
- 确保数据隐私。
- 可维护性：指定与软件本身的易维护性相关的软件属性。这些可能包括对某些模块化、接口或复杂性限制的要求。不应仅仅因为它们被认为是良好的设计实践而将要求放在此处。
- 可移植性：指定与将软件移植到其他主机和/或操作系统的难易程度相关的软件属性，包括：
- 具有宿主依赖代码的元素的百分比；
- 依赖于主机的代码百分比；
- 使用经过验证的可移植语言；
- 使用特定的编译器或语言子集；
- 使用特定的操作系统。
18 验证
提供计划用于确认软件的验证途径和方法。建议将验证的信息项与 10 至 17 中的信息项并行给出。
19 支持信息
SRS 应包含其他支持信息，包括：
- 样本输入/输出格式、成本分析研究描述或用户调查结果；
- 可以帮助 SRS 读者的支持或背景信息；
- 该软件所要解决的问题的描述；
- 为满足安全、出口、初次装载或其他要求，对代码和介质进行特殊包装说明要求。
SRS 应该明确说明这些信息项是否被视为要求的一部分。