GB/T 9385-2008 计算机软件需求规格说明规范

　　ICS 35 . 080 L 77

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 9385—2008代替 GB/T 9385—1988

　　计算机软件需求规格说明规范

　　Norm ofcomputersoftwarerequirementsspecification

　　2008-04-1 1 发布 2008-09-01 实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　

　　发

　　

　　布

　　GB/T 9385—2008

　　目 次

　　前言 Ⅲ

　　引言 Ⅳ

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语和定义 1

　　4 SRS 的编制原则 1

　　5 SRS 的组成和内容要求 6

　　附录 A(资料性附录) SRS 提纲模板 15

　　A. 1 按照运行模式组织的 SRS 第 3 章模板(版本 1) 15

　　1 6

　　A(A) .. 3(2) 按照用户类别组织的 SRS(按照运行模式组织的 SRS) 第(第) 3(3) 章模板(章模板)(版本 2) 15

　　1 7

　　A(A) .. 5(4) 按照系统特征组织的(按照对象组织的 SRS) SRS(第) 3 第(章)3(模)章(板)模 16

　　A(A) .. 7(6) 按照功能层次组织的(按照激励组织的 SRS) SRS(第) 3 第(章)3(模)章(板)模 1(1)8(8)

　　参(A).考(8)文献(体)现 多种组织形式RS … …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… …… 2(2)1(0)

　　Ⅰ

　　GB/T 9385—2008

　　前 言

　　本标准是 GB/T 9385《计 算 机 软 件 需 求 说 明 编 制 指 南》的 第 一 次 修 订 。 本 标 准 与 GB/T 9385 — 1988 的主要差别如下：

　　a) 根据 GB/T 1 . 1 的规定，原 GB/T 9385—1988 版中第 1 章引言部分中的内容放在新版的引言部分;

　　b) 新版标准的范围部分重新进行调整改写;

　　c) 第 2 章规范性引用文件删去了 GB/T 8567 ;

　　d) 根据 GB/T 8566 和 GB/T 11457 的规定，术语 “开发者 ”改为 “供方 ”;

　　e) 原 GB/T 9385—1988 版的第 4 章和第 5 章调整为新版的第 4 章，且名称为“SRS”的编制原则 。调整后的第 4 章更加清晰 、完善 。而删去了旧版第 5 章中有关模型的内容;

　　f) 旧版标准的第 6 章的主要内容调整为新版标准的第 5 章，而提纲部分调整为新版标准的附录A ,且附录 A 的内容扩充了一部分 。

　　本标准的附录 A是资料性附录 。

　　本标准自实施之日起代替被废止 GB/T 9385—1988 。

　　本标准由中华人民共和国信息产业部提出 。

　　本标准由全国信息技术标准化技术委员会归 口 。

　　本标准起草单位：信息产业部电子工业标准化研究所 、中国航天科技集团公司软件评测中心 、上海计算机软件开发中心 、上海宝信软件股份有限公司 、东方通科技 、广西软件园 、上海浦东软件园有限责任公司 、上海鲁齐信息科技有限公司 。

　　本标准主要起草人：冯惠 、王宝艾 、窦传义 、石柱 、杨根兴 、李春青 、陈在根 、张旸旸 、张露莹 。

　　本标准于 1988 年首次发布 。

　　Ⅲ

　　GB/T 9385—2008

　　Ⅳ

　　引

　　

　　言

　　本标准描述了软件需求规格说明的编制方法 。它基于以下设想，即软件需求规格说明确定过程的结果是一份明确和完备的规格说明文档 。本标准将有助于：

　　— 软件的顾客准确地描述其希望得到什么;

　　— 软件的供方正确地理解顾客想要什么;

　　— 对于实现以下目标的有关单位和人员：

　　● 为其所在的组织编制一份标准的软件需求规格说明(SRS)提纲;

　　● 定义其具体软件需求规格说明的格式和内容;

　　● 编制其他的本地支持资料，如，SRS 质量检查清单 、或 SRS 编写者手册 。

　　对于顾客 、供方和其他有关人员，一份好的 SRS 可能带来一些具体的益处，例如：

　　— 对于提供什么软件产品，为顾客和供方之间的协议建立基础 。在 SRS 中软件功能的完备描述将协助潜在用户，以便确定指定的软件是否满足其需要，或者为满足其需要应如何修改软件;

　　— 减少开发工作 。SRS 文档的编制迫使顾客组织有关各方或人员在设计之前严格考虑所有的需求，并减少以后的重新设计 、重新编码和重新测试 。对 SRS 中的各项需求进行仔细评审，可以在开发周期的早期揭示某些遗漏 、误解和不一致，此时这些问题更容易纠正;

　　— 为估计成本和进度提供基础 。SRS 中给出的待开发产品的描述是估计项 目成本的现实基础，可用于取得投标认可或得出价格估算;

　　— 为验证和确认提供基线 。通过一份好的 SRS 文档，组织可提出其更加有效的验 证 和 确 认 计划 。作为开发合同的一部分，SRS 提供了可用于测量依从性的基线;

　　— 便于软件产品转移 。SRS 文档使软件产品转移到新的用户或机器更容易 。顾客因此发现软件产品更容易转移到组织的其他部门，供方发现软件产品更容易转移到新的顾客;

　　— 作为进一步增强的基础 。 因为 SRS 文档讨论的是产品，而不是开发它的项 目，因此，SRS 是已开发产品后续增强的基础 。尽管 SRS 文档或许需要修改，但它确实为后续的产品评价提供了基础 。

　　GB/T 9385—2008

　　计算机软件需求规格说明规范

　　1 范围

　　本标准给出了软件需求规格说明(SRS) 的编制要求，描述了一份好的 SRS 的内容和质量，并在附录 A 中给出一些 SRS 提纲示例 。

　　本标准适用于编制 SRS 。

　　本标准并不限定任何编制 SRS 特定的方法 、命名约定和工具 。

　　2 规范性引用文件

　　下列文件中的条款通过本标准的引用而成为本标准的条款 。凡是注 日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本 。凡是不注 日期的引用文件，其最新版本适用于本标准 。

　　GB/T 8566 信息技术 软件生存周期过程(GB/T 8566—2007 , ISO/IEC 12207:1995 , MOD) GB/T 11457 信息技术 软件工程术语

　　3 术语和定义

　　GB/T 11457 中确立的以及下列术语和定义适用于本标准 。

　　3 . 1

　　合同 contract

　　由顾客和供方共同签署的具有法律约束力的文件，其中包括产品的技术 、组织 、成本和进度的需求 。合同同样可包括某些非正式的 、但有用的信息，如，参与各方的承诺或期望 。

　　3 . 2

　　顾客 customer

　　为产品支付费用，并通常(但不必要)确定需求的个人或群体 。在某些情况下，顾客和供方可以是同一组织的成员 。

　　3 . 3

　　供方 supplier

　　为顾客开发产品的个人或群体 。在某些情况下，顾客和供方可以是同一组织的成员 。

　　3 . 4

　　用户 user

　　直接运行产品或与产品进行交互作用的个人或群体 。用户和顾客通常不是同一个人或群体 。

　　4 SRS 的编制原则

　　4 . 1 综述

　　本章给出了编制 SRS 时宜考虑的事项及编制原则：

　　a) SRS 的基本性质;

　　b) SRS 的环境;

　　c) 好的 SRS 的特性;

　　d) SRS 的联合编制;

　　e) SRS 演变;

　　1

　　GB/T 9385—2008

　　f) 原型法;

　　g) SRS 中嵌入设计;

　　h) SRS 中嵌入项目需求 。

　　4 . 2 SRS 的基本性质

　　SRS 是对在具体环境中执行确定功能的特定软件产品 、程序或一组程序的规格说明 。SRS 可由来自供方 、顾客或双方的一个或者多个人员编写，4 . 5 推荐由来自供方和顾客双方的人员联合编写 。

　　SRS 编写人员应关注以下基本点：

　　a) 功能 — 软件将执行什么功能?

　　b) 外部接口 — 软件如何与人 、系统的硬件及其他硬件和其他软件进行交互?

　　c) 性能 — 各种软件功能的速度 、响应时间 、恢复时间等是多少?

　　d) 属性 — 软件的可用性 、可靠性 、可移植性 、正确性 、可维护性 、安全性如何?

　　e) 影响产品实现的设计约束 — 是否有使用标准 、编程语言 、数据库完整性方针 、资源限制 、运行环境等方面的要求?

　　编写人员宜避免把设计或项目需求写入 SRS 中 。

　　SRS 的内容详见第 5 章 。

　　4 . 3 SRS 的环境

　　很重要的一点是应考虑 SRS在整个项目计划中的作用 。项目计划的定义见 GB/T 11457 。软件既可以基本上包括了项 目 的所有功能，也可以是更大系统的一部分 。在后一种情况，典型的 SRS 将指出系统及其软件部分的接 口，并将外部性能和功能需求写入软件部分 。显然，SRS 应当在系统需求上扩展并与其保持一致 。

　　GB/T 8566 描述了软件生存周期的各个步骤，以及每步适用的输入 。 与软件生存周期等有关的其他标准，可对软件需求进行补充 。

　　因为 SRS 在软件开发过程中发挥特定的作用，编写人员宜谨慎对待，不超出其作用的范围 。这意味着 SRS :

　　a) 宜正确地定义所有软件需求 。 由于将要处理的任务的性质或项 目 的具体特性，则软件需求是存在的 。

　　b) 不宜描述任何设计或实现的细节 。这些内容应当在项 目 的设计阶段进行描述 。

　　c) 不宜对软件设置附加的限制条件 。这些内容可在其他文件中规定，如，软件质量保证计划 。因此，编写适当的 SRS 限定了正确设计的范围，但不规定任何具体的设计 。

　　4 . 4 好的 SRS 的特征

　　4 . 4 . 1 综述

　　SRS宜是：

　　a) 正确;

　　b) 无歧义;

　　c) 完备;

　　d) 一致;

　　e) 重要性和/或稳定性分级;

　　f) 可验证;

　　g) 可修改;

　　h) 可追踪 。

　　4 . 4 . 2 正确

　　当且仅当 SRS 中的每一项需求都是软件应满足的需求，SRS 才是正确的 。

　　不存在确保 SRS 正确性的工具或规程 。宜把 SRS 与任何适用的上层规格说明(如，系统需求规

　　2

　　GB/T 9385—2008

　　格说明)、其他项目文件和其他适用的标准进行对比，以确保其相互一致 。作为一种选择，顾客或用户可以确定 SRS 是否正确地反映了实际需要 。可追踪性使相应的规程更加便利并减少缺陷(见 4 . 4 . 8) 。

　　4 . 4 . 3 无歧义

　　当且仅当 SRS 中的每一项需求都只有一种解释，SRS 才是无歧义的 。这要求最终产品的每个特征至少使用唯一的术语来描述 。

　　当在特定背景中使用的某个术语存在多种含义时，宜将该术语包含在术语表中，以便更加具体地说明其含义 。

　　正如在 GB/T 8566 中所描述的那样，SRS 是软件生存周期中需求过程的一个重要部分，并被应用于设计 、实现 、项目监控 、验证和确认，以及培训活动中 。对于编制人员和使用人员，SRS 宜是无歧义的 。但是，这些人员通常并不具备相同的背景，因而对软件需求的描述不会倾向相同的形式 。为开发人员而改进的 SRS 表述，或许会降低用户对 SRS 的理解，反之亦然 。

　　4 . 4 . 3 . 1 到 4 . 4 . 3 . 3 给出了如何避免歧义性的建议 。

　　4 . 4 . 3 . 1 自然语言的缺陷

　　需求通常使用自然语言(如，汉语)来编写 。但自然语言具有固有的不明确性 。使用 自然语言编制的 SRS 宜由独立的一方进行评审，以识别语言的含糊用法并予以纠正 。

　　4 . 4 . 3 . 2 需求规格说明语言

　　避免自然语言固有的歧义的一种方式是，使用特定的需求规格说明语言编写 SRS 。该语言处理器可自动检测出许多词法 、句法和语义错误 。

　　使用这类特定语言的缺点是，学习语言需要较长的时间 。 同时，多数非技术方面的使用者发现它们不易理解 。此外，这类语言倾向于表述某些特定类型的需求和处理某些特定类型的系统 。 因此，这类语言可能以难以捉摸的方式影响这些需求 。

　　4 . 4 . 3 . 3 表述工具

　　一般而言，支持编制需求的方法 、语言和工具分为三种通用类别：对象 、过程和行为 。 面向对象的方法按照现实世界的对象 、它们的属性和这些对象完成的服务来组织需求;基于过程的方法将需求组织成功能的层次结构，而这些功能通过数据流进行通信;基于行为的方法利用一些抽象的符号(如，谓词演算)、数学函数或状态机来描述系统的外部行为 。

　　这些工具和方法对编制 SRS 时的有用程度依赖于项 目 的规模和复杂性 。这里并不试图描述和认可任何特定的工具 。

　　当使用任何这类方法时，最好仍保持自然语言方式的描述，这样，不熟悉这些方法 、符号的顾客仍然能够理解 SRS 。

　　4 . 4 . 4 完备

　　4 . 4 . 4 . 1 当且仅当 SRS 包含以下要素，SRS 才是完备的：

　　a) 所有重要的需求，不论是否与功能 、性能 、设计约束 、属性或者外部接口有关 。尤其是由系统规格说明所施加的任何外部需求都应当得到确认和处理 。

　　b) 软件响应的定义，以说明软件对所有可实现的输入数据类型的响应 。应当注意，对于有效和无效输入数值两种情况，规定软件响应是重要的 。

　　c) SRS 中所有图表的全面标记和索引，以及所有术语和度量单位的定义 。

　　4 . 4 . 4 . 2 任何含有 “待定 ”词语的 SRS 是不完备的 。但是有时使用 “待定 ”是不可避免的，若万一使用“待定 ”时应做如下说明：

　　a) 对导致使用 “待定 ”的情形进行描述(为什么答案未知)，以便问题能得到解决;

　　b) 描述为排除 “待定 ”应采取的措施 、由谁负责排除以及何时必须排除 。

　　4 . 4 . 5 一致

　　4 . 4 . 5 . 1 一致是指内部一致性 。如果 SRS 与某些更高层的文档(如，系统规格说明)不一致，那么它是

　　3

　　GB/T 9385—2008

　　不正确的(见 4 . 4 . 1) 。

　　4 . 4 . 5 . 2 当且仅当 在 SRS 中 描 述 的 任 何 单 个 需 求 的 子 集 之 间 相 互 不 矛 盾，SRS 才 是 内 部 一 致 的 。 SRS 中可能存在下述三种类型的矛盾：

　　a) 现实世界对象的规定特征可能相互矛盾 。如：

　　1) 报告输出的格式在一个需求中是表格形式，而在另一个需求中是文本形式;

　　2) 一个需求指出所有的灯是绿色，而另一个需求规定所有的灯是蓝色 。

　　b) 在两个规定的行为之间可能存在逻辑上的或时间上的冲突 。如：

　　1) 一个需求规定程序将对两个输入相加，另一个需求则规定程序将对这两个输入相乘;

　　2) 一个需求指出“A”必须总是在“B”之后，而同时在另一个需求中要求“A 和 B”同时发生 。

　　c) 可能两个或更多的需求描述现实世界的相同对象，但使用不同的术语 。如，在一个需求中程序对用户输入的请求称为 “提示符 ”，在另一个需求中称为 “提示 ”。使用标准术语和定义可以改善一致性 。

　　4 . 4 . 6 重要性和/或稳定性分级

　　如果 SRS 中每条需求赋有标明其重要性或稳定性的标识，那么该 SRS 便按照重要性和/或稳定性进行了分级 。

　　通常，与软件产品有关的所有需求并不具有相同的重要性 。某些需求可能是基本的，特别是与人身生命有关的关键应用，而其他的可能是所期望的需求 。

　　SRS 中的每个需求宜予 以 标 识，以 使 需 求 在 这 方 面 的 差 异 清 晰 和 明 确 。 按 下 述 方 式 标 识 需 求 有助于：

　　a) 使顾客更仔细地考虑每个需求，这样，常常会澄清顾客可能引入的任何隐藏的假设;

　　b) 使开发人员做出正确的设计决定，并针对软件产品的不同部分做出相应适当工作的投入 。

　　4 . 4 . 6 . 1 稳定性程度

　　可以用需求的期望变更次数来标识需求的稳定程度 。

　　4 . 4 . 6 . 2 重要性程度

　　另一种需求分级的方式是区分如下基本的 、有条件的和可选的需求类别：

　　a) 基本的 — 除非表示同意并满足了这类需求，否则软件将不被接受;

　　b) 有条件的 — 表示这类需求会增强软件产品，但是，如果缺少这类需求，也不会导致软件产品被拒收;

　　c) 可选的 — 表示该类功能需求可有可无，这赋予供方提出超出 SRS 的建议的机会和余地 。

　　4 . 4 . 7 可验证

　　当且仅当 SRS 中的每个需求是可验证的，SRS 才是可验证的 。 当且仅当存在某个有限的成本 、有效的过程，人或机器依照该过程能够检查软件产品满足某个需求，该需求才是可验证的 。一般说来，任何有歧义的需求都是不可验证的 。

　　不可验证的需求包含诸如 “工作良好 ”、“好的人机界面 ”和 “通常应该发生 ”之类的陈述 。 因为不可能定义 “良好 ”、“好的 ”和 “通常 ”，因此，这些需求不可能验证 。 陈述 “程序应绝对不进入无限循环 ”是不可验证的，因为理论上该特性是不可测试的 。

　　可验证陈述示例：

　　程序输出应在事件开始 20s 内达到 60%,在 30s 内达到 100% 。

　　这样的陈述是可验证的，因为它使用了具体的术语和可测量的数值 。

　　如果不能设计出一种方法，以确定软件是否满足某个具体的需求，那么该需求宜被删除或被修改 。

　　4 . 4 . 8 可修改

　　当且仅当 SRS 的结构和形式能够对任何需求进行容易 、全面和一致的修改，同时保持该结构和形式，SRS 才是可修改的 。一般地，可修改性要求 SRS:

　　4

　　GB/T 9385—2008

　　a) 具有连贯 、方便使用的结构，包含目次 、索引及清晰的相互引用;

　　b) 没有冗余(即，相同的需求在 SRS 不应当出现在多处);

　　c) 分别地表述每个需求，而不与其他需求相混淆 。

　　尽管冗余本身不是缺陷，但它容易导致错误 。尽管冗余偶尔可以有助于 SRS 的可读性，但当对存在冗余的文件更新时，可能会引起问题 。例如，可能对出现多处的某个需求仅在一处做了修改，那么使得 SRS 内容不一致 。 当需要冗余时，SRS宜包括一个清晰地交叉索引表，以增加其可修改性 。

　　4 . 4 . 9 可追踪

　　如果 SRS 每个需求的来源是清楚的，并在将来编制或增强文档的过程中便于每个需求的索引，那么该 SRS 是可追踪的 。推荐以下两种类型的可追踪性：

　　a) 逆向可追踪性(即，到以前的开发阶段)。这依赖于每个需求清晰地指向其在早期文件的来源;

　　b) 正向可追踪性(即，到由 SRS 产生的所有文件)。这依赖于 SRS 中每个需求具有唯一的名称或索引号 。

　　当软件产品进入运行和 维 护 阶 段 时，SRS 的 正 向 可 追 踪 性 尤 其 重 要 。 随 着 代 码 和 设 计 文 档 的 修改，最要紧的是能够确定这些修改可能影响的全部的需求集合 。

　　4 . 5 SRS 的联合编制

　　软件开发过程宜从顾客与供方关于完成的软件必须做什么达成的协议开始 。依照 SRS 的形式，该协议宜联合起草 。这一点很重要，因为通常不管是顾客还是供方，单方面都不具备编写一份良好 SRS的资格 。

　　a) 顾客通常对软件设计和开发过程了解的不够，不足以编写实用的 SRS ;

　　b) 供方通常对顾客的问题和从事的领域了解不够，不足以为系统规定满意的需求 。因此，顾客和供方宜一起工作，以编写良好的 、全面的和可理解的 SRS 。

　　当系统及其软件二者同时被定义时，存在一种特殊情况，软件的功能 、接 口 、性能 、及其他的属性和限制条件不是预先定义的，而是联合定义并且需要协商和变更，这使得满足 4 . 4 所述的特征更困难，但更重要 。尤其是，不符合其母系统需求规格说明的软件 SRS 是不正确的 。

　　本标准不具体讨论 SRS 的形式 、语言的使用或良好的编写技巧，但是，编写良好的 SRS 十分重要 。一般的技术写作书籍可用作编写指南 。

　　4 . 6 SRS 的演变

　　随着软件产品开发的进展，SRS 可能需要演变 。在项 目开始时，规定某些细节是不可能的(例如，对于一个交互程序，在需求阶段定义所有屏幕格式是不可能的)。 随着 SRS 中的缺陷 、不足和不准确之处的发现，可能会相继发生对 SRS 的其他变更 。

　　在此过程中，两个重要的考虑事项如下：

　　a) 尽管可以预见对 SRS 的演变修订是不可避免的，但在某个时间对需求的规定应当尽可能完全和细致 。宜注明需求不完备的事实;

　　b) 宜启动正式的变更过程，以识别 、控制 、跟踪和报告指定的变更 。 已批准的需求变更宜按以下方式纳入 SRS 中：

　　1) 提供准确的和全面的变更审核追踪记录;

　　2) 允许对 SRS 的当前版本和先前版本进行评审 。

　　4 . 7 原型法

　　在项 目 的需求阶段常常使用原型法 。一些工具可简单 、快捷地创建体现系统某些特征的原型 。

　　注：可参照 ASTM E 1340:1996《计算机系统快速原型法标准指南》。

　　原型的实用性有以下原因：

　　a) 与阅读 SRS 和提出意见相比，顾客更有可能考察原型并提出建议;

　　b) 原型可演示系统行为不可预见的方面，因此，原型不但提供答案，同时还提出一些新的问题，

　　5

　　GB/T 9385—2008

　　这有助于完善 SRS ;

　　c) 基于原型提出的 SRS 在开发过程中倾向更少的变更，从而减少开发时间 。

　　原型是用于提取软件需求的一种方式 。诸如屏幕或报告格式之类的某些特征可以直接从原型中提取 。其他需求可以通过进行原型试验推导出来 。

　　4 . 8 SRS 中嵌入设计

　　4 . 8 . 1 一般来说，在 SRS 中尽量避免嵌入设计说明，在 SRS 中嵌入设计说明会过多地约束设计，并且人为地把具有潜在危险的需求引入 SRS 。

　　一个需求规定了系统某个外部可见的功能或属性 。设计描述了系统某个具体的子部件和/或它与其他子部件的接 口 。SRS 编写人员应当清楚地区分识别所需要的设计约束和构想具体的设计之间的差异 。应当注意，SRS 的每个需求限制了设计的可选择性 。但这并不意味着每个需求就是设计 。

　　SRS 应当规定对何数据执行何功能以便在何地为何人产生何种结果 。SRS 宜集中于所提供的服务 。SRS 通常不规定设计事项，如：

　　a) 划分软件为各个模块;

　　b) 分配功能到各个模块;

　　c) 描述模块之间的信息流或控制流;

　　d) 选择数据结构 。

　　4 . 8 . 2 把设计和 SRS完全割裂开来也是不现实的 。 在某些特殊情况下，某些需求可能严重地限制了设计 。对安全或保密安全方面的周密考虑可能增加一些直接反映设计约束的需求，例如：

　　a) 用几个分开的模块来实现某些功能;

　　b) 在程序的某些区域之间仅允许有限的通信;

　　c) 对临界的变量检查数据的完整性 。

　　有效的设计约束条件示例如：物理需求 、性能需求 、软件开发标准以及软件质量保证标准 。

　　因此，宜从完全外部的角度规定需求 。 当使用模型阐述需求时，应记住模型仅仅用来表明系统的外部行为，并不规定设计 。

　　4 . 9 SRS 中嵌入项目需求

　　SRS宜关注软件产品，而不是软件产品的生产过程 。

　　项目需求表示了顾客和供方之间有关软件生产合同事宜的理解，因此不宜包括在 SRS 中 。

　　通常这些项目需求包括如下：

　　a) 成本;

　　b) 交付进度;

　　c) 报告规程;

　　d) 软件开发方法;

　　e) 质量保证;

　　f) 验证和确认准则;

　　g) 验收规程 。

　　项目需求在其他文档中规定，通常在软件开发计划 、软件质量保证计划或者工作说明中规定 。

　　5 SRS 的组成和内容要求

　　5 . 1 综述

　　本章讨论组成 SRS 的每个基本组成部分和内容要求 。 图 1 以提纲形式列出这些部分，可作为编写SRS 的示例 。

　　尽管 SRS 不必要按照此提纲或使用这里给出的各章条的名称，但是，一份良好的 SRS 宜包括以下论述的所有信息 。

　　6

　　GB/T 9385—2008

　　目 次

　　1 引言

　　1 . 1 目 的

　　1 . 2 范围

　　1 . 3 定义 、简写和缩略语

　　1 . 4 引用文件

　　1 . 5 综述

　　2 总体描述

　　2 . 1 产品描述

　　2 . 2 产品功能

　　2 . 3 用户特点

　　2 . 4 约束

　　2 . 5 假设和依赖关系

　　2 . 6 需求分配

　　3 具体需求(对可能的具体需求的说明见 5 . 4 . 1 到 5 . 4 . 8 。也可参见附录 A 中关

　　于 SRS几种不同模式 。)附录

　　索引

　　图 1 SRS提纲

　　5 . 2 引言(SRS的第 1 章)

　　SRS 的引言部分应当提供整个 SRS 的概述，包括以下各条：

　　a) 目 的;

　　b) 范围;

　　c) 定义 、简称和缩略语;

　　d) 引用文件;

　　e) 综述 。

　　5 . 2 . 1 目的(SRS 的 1 . 1)

　　本条宜：

　　a) 描述 SRS 的 目 的;

　　b) 说明 SRS 的预期读者 。

　　5 . 2 . 2 范围(SRS 的 1 . 2)

　　本条宜：

　　a) 通过名称识别要生产/开发的软件产品(例如，宿主数据库管理系统(DBMS) 、报告生成器等);

　　b) 必要时，说明软件产品将做或不做什么;

　　c) 描述规定的软件的应用，包括相关的收益 、目标和 目 的;

　　d) 如果上层规格说明(如，系统需求规格说明)存在，与上层规格说明类似的陈述保持一致 。

　　5 . 2 . 3 定义 、简写和缩略语(SRS 的 1 . 3)

　　本条宜提供对正确解释 SRS 所 要 求 的 所 有 术 语 、简 写 和 缩 略 语 的 定 义，这 些 信 息 可 以 通 过 引 用SRS 中的一个或多个附录 、或者引用其他文件的方式来提供 。

　　5 . 2 . 4 引用文件(SRS 的 1 . 4)

　　本条宜：

　　7

　　GB/T 9385—2008

　　a) 提供 SRS 引用的所有文件的完整清单;

　　b) 标识出每个文件的名称 、报告编号(适用时)、日期 、出版组织;

　　c) 标明可以获得引用文件的来源 。

　　这些信息可以通过引用附录或引用其他文档的方式提供 。

　　5 . 2 . 5 综述(SRS的 1 . 5)

　　本条宜：

　　a) 描述 SRS 的其余章条包含的内容;

　　b) 说明 SRS 是如何组织的 。

　　5 . 3 总体描述(SRS的第 2 章)

　　本章宜描述影响产品及其需求的一般因素，而不叙述具体的需求 。相反，它提供需求的背景并使它们更易理解，而在 SRS 的第 3 章将详细定义这些需求 。

　　本章通常由以下 6 条组成：

　　a) 产品描述;

　　b) 产品功能;

　　c) 用户特点;

　　d) 约束;

　　e) 假设和依赖关系;

　　f) 需求分配 。

　　5 . 3 . 1 产品描述(SRS 的 2 . 1)

　　本条宜把产品置于其他有关产品的全景之下 。如果产品是独立的和完全自我包含的，这里宜如实给予陈述 。正如常出现的那样，如果 SRS 定义的产品是较大系统的组成部分，则本章宜将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接 口 。

　　使用框图展示较大系统的主要部分 、相互联系以及外部接口是有帮助的 。

　　本条也宜描述在各种不同的约束下软件如何运行 。如，这些约束可包括：

　　a) 系统接 口;

　　b) 用户界面;

　　c) 硬件接 口;

　　d) 软件接 口;

　　e) 通信接 口;

　　f) 内存;

　　g) 运行;

　　h) 现场适应性需求等 。

　　5 . 3 . 1 . 1 系统接口

　　本条宜列出每个系统接 口，识别完成系统需求的软件功能以及与系统匹配的接口描述 。

　　5 . 3 . 1 . 2 用户界面

　　本条宜规定以下方面：

　　a) 在软件产品与用户之间每个界面的逻辑特征 。 这包括完成软件需求所需要的那些配置特征(例如，要求的屏幕显示格式 、页面或窗口版式布局 、任何报告或菜单的内容 、或者可编程功能键的设置);

　　b) 优化系统用户界面的所有方面 。这可以简单地包括一个针对系统对用户的显示方式系统将做什么和不做什么的清单 。例如，可能是一项选择长或短的错误消息方面的需求 。如同所有其他需求一样，这些需求宜是可验证的，例如，“经过 1 h 培训后，4 级打字员能够在 Z min 内执行功能 X”,而不是 “打字员能够执行功能 X”(这也可以在标题为使用方便性章条的软件系

　　8

　　GB/T 9385—2008

　　统属性中规定)。

　　5 . 3 . 1 . 3 硬件接口

　　本条宜规定系统硬件各部件与软件产品之间每个接 口 的逻辑特征，包括配置特征(端口数量 、指令集等)，同样也覆盖这些事项，如，支持什么设备 、如何支持以及采用什么协议 。例如，相对逐行支持，终端支持可能规定为全屏支持 。

　　5 . 3 . 1 . 4 软件接口

　　本条宜规定对其他软件产品(例如，数据管理系统 、操作系统 、或数学软件包)的使用，以及与其他应用系统(例如，账户 接 收 系 统 和 一 般 的 会 计 记 帐 系 统 的 链 接)的 接 口 。 对 于 每 个 要 求 的 软 件 产 品，宜提供：

　　a) 名称;

　　b) 助记符;

　　c) 规格说明编号;

　　d) 版本号;

　　e) 来源 。

　　对于每个接 口，宜提供：

　　a) 相对此软件产品，接口软件的 目 的的论述;

　　b) 按照消息内容和格式对接 口 的定义，不必要详细描述任何已文件化的接 口，但要求引用定义此接口的文件 。

　　5 . 3 . 1 . 5 通信接口

　　本条宜定义不同的通信接 口，如，局域网协议等 。

　　5 . 3 . 1 . 6 内存约束

　　本条宜规定对主存和辅存的任何适用特征和限制 。

　　5 . 3 . 1 . 7 操作

　　本条宜规定用户要求正常的和特定的操作，如：

　　a) 用户组织的不同操作模式(如，用户引发的操作);

　　b) 交互操作的周期和无人值守操作的周期;

　　c) 数据处理支持功能;

　　d) 备份和恢复操作 。

　　注：有时此条规定作为用户界面的一部分 。

　　5 . 3 . 1 . 8 现场适应性需求本条宜：

　　a) 对于给定的现 场 、任 务 或 运 行 模 式(如，网 格 数 、安 全 限 制 等)，为 任 何 数 据 或 启 动 顺 序 定 义需求;

　　b) 针对软件适应特定的安装现场或任务，规定应当修改的特征 。

　　5 . 3 . 2 产品功能(SRS 的 2 . 2)

　　本条宜给出软件将执行主要功能的概要 。例如，某个会计程序的 SRS 可在此部分关注顾客账户维护 、顾客财务报表及发票准备，而不涉及这些功能要求的大量细节 。

　　有时，本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明(如果存在)中摘录 。为了清晰，应当注意：

　　a) 功能宜以这样的方式组织，以使顾客或第一次阅读该文件的任何读者对功能列表容易理解;

　　b) 可以使用文本或图示的方法，显示不同的功能及其之间的关系 。这样的图示不必显示产品的设计，但简要显示变量之间的逻辑关系 。

　　9

　　GB/T 9385—2008

　　5 . 3 . 3 用户特点(SRS 的 2 . 3)

　　本条宜给出软件产品预期用户的一般特征，包括教育程度 、经验 、专业技术情况 。 它不宜指出具体的需求，但宜给出 SRS第 3 章中为何规定某些具体需求的原因 。

　　5 . 3 . 4 约束(SRS 的 2 . 4)

　　本条宜给出将会限制开发人员选择的任何其他事项的一般描述 。这些包括：

　　a) 法规政策;

　　b) 硬件局限(如，信号时间要求);

　　c) 与其他应用的接 口;

　　d) 并行操作;

　　e) 审核功能;

　　f) 控制功能;

　　g) 高级语言需求;

　　h) 信号握手协议(如，XON-XOFF、ACK-NACK) ;

　　i) 可靠性需求;

　　j) 应用的关键性;

　　k) 安全和保密安全考虑 。

　　5 . 3 . 5 假设和依赖关系(SRS 的 2 . 5)

　　本条宜列出影响 SRS 规定需求的每个因素 。这些因素不是软件设计的限制条件，但是，它们的任何变更可能影响 SRS 中的需求 。例如，某个假设可能是软件产品指定的硬件具有某个特定操作系统，如果事实上该操作系统不能使用，那么 SRS 将做相应的修改 。

　　5 . 3 . 6 需求分配(SRS 的 2 . 6)

　　本条宜识别可能推迟到系统将来版本的需求 。

　　5 . 4 具体需求(SRS的第 3 章)

　　本章宜包括足够详细的所有软件需求，使设计人员能够设计系统以满足这些需求，并且使测试人员能够测试该系统满足这些需求 。贯穿本章，对于用户 、运行人员或其他外部系统，每个规定的需求应当是外部可理解的 。这些需求至少应当包括，每个系统输入(激励)、每个系统输出(响应)以及系统通过响应某个输入或支持某个输出所执行的所有功能 。 由于这通常是 SRS 篇幅最大和最主要部分，以下原则适用：

　　a) 规定的具体需求宜符合 4 . 4 描述的所有特征;

　　b) 具体需求宜引用较早的相关文件;

　　c) 所有的需求宜是唯一可标识的;

　　d) 宜注意需求的组织，使其具有最大的可读性 。

　　在考察组织需求的具体方式之前，了解 5 . 4 . 1 到 5 . 4 . 7 组成需求的各个不同项是有益的 。

　　5 . 4 . 1 外部接口

　　本条宜是软件系统所有输入和输出的详细描述 。它宜是对 5 . 2 的接口描述的补充，不宜重复前面已有的信息 。

　　宜包括以下内容和格式：

　　a) 项的名称;

　　b) 目 的描述;

　　c) 输入源和输出 目 的地;

　　d) 有效范围 、准确度和/或容限;

　　e) 测量单位;

　　f) 定时;

　　10

　　GB/T 9385—2008

　　g) 与其他输入/输出的关系;

　　h) 屏显格式/组织;

　　i) 窗口格式/组织;

　　j) 数据格式;

　　k) 命令格式;

　　l) 结束消息 。

　　5 . 4 . 2 功能

　　功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作 。一般情况下使用 “系统应…… ”的方式来陈述 。

　　这些包括：

　　a) 对输入有效性的核查;

　　b) 操作的准确顺序;

　　c) 异常情况响应，包括：

　　1) 溢出;