GB/T 9385 计算机软件需求说明编制指南
前 言
本标准是 GB/T 9385《计算机软件需求说明编制指南》的第一次修订。本标准与 GB/T 9385-1988的主要差别如下：
- 根据 GB/T 1.1的规定，原 GB/T 9385—1988 版中第1章引言部分中的内容放在新版的引言部分；
- 新版标准的范围部分重新进行调整改写；
- 第2章规范性引用文件删去了 GB/T 8567；
- 根据 GB/T 8566和 GB/T 11457的规定，术语“开发者”改为“供方”；
- 原 GB/T 9385一1988版的第4章和第5章调整为新版的第4章，且名称为“SRS”的编制原则。调整后的第4章更加清晰、完善。而删去了旧版第5章中有关模型的内容；
- 旧版标准的第6章的主要内容调整为新版标准的第5章，而提纲部分调整为新版标准的附录A，且附录A的内容扩充了一部分。
本标准自实施之日起代替被废止 GB/T 9385-1988。 本标准由中华人民共和国信息产业部提出。 本标准由全国信息技术 1标准化技术委员会归口。
本标准起草单位：信息产业部电子工业标准化研究所、中国航天科技集团公司软件评测中心、上海计算机软件开发中心、上海宝信软件股份有限公司、东方通科技、广西软件园、上海浦东软件园有限责任公司、上海鲁齐信息科技有限公司。
本标准主要起草人：冯惠、王宝艾、窦传义、石柱、杨根兴、李春青、陈在根、张旸旸、张露莹。
本标准于1988年首次发布。
引 言
本标准描述了软件需求规格说明的编制方法。它基于以下设想，即软件需求规格说明确定过程的结果是一份明确和完备的规格说明文档。本标准将有助于：
软件的顾客准确地描述其希望得到什么；
软件的供方正确地理解顾客想要什么；
对于实现以下目标的有关单位和人员：
- 为其所在的组织编制一份标准的软件需求规格说明(SRS)提纲；
- 定义其具体软件需求规格说明的格式和内容；
- 编制其他的本地支持资料，如，SRS 质量检查清单、或 SRS编写 2者手册。
对于顾客、供方和其他有关人员，一份好的 SRS 可能带来一些具体的益处，例如：
- 对于提供什么软件产品，为顾客和供方之间的协议建立基础。在 SRS 中软件功能的完备描述将协助潜在用户，以便确定指定的软件是否满足其需要，或者为满足其需要应如何修改软件；
- 减少开发工作。SRS文档的编制迫使顾客组织有关各方或人员在设计之前严格考虑所有的需求，并减少以后的重新设计、重新编码和重新测试。对 SRS 中的各项需求进行仔细评审 3，可以在开发周期的早期揭示某些遗漏、误解和不一致，此时这些问题更容易纠正；
- 为估计成本和进度提供基础。SRS 中给出的待开发产品的描述是估计项目成本的现实基础，可用于取得投标认可或得出价格估算 4；
- 为验证和确认提供基线。通过一份好的 SRS文档，组织可提出其更加有效的验证和确认计划。作为开发合同的一部分，SRS 提供了可用于测量依从性的基线；
- -便于软件产品转移。SRS 文档使软件产品转移到新的用户或机器更容易。顾客因此发现软件产品更容易转移到组织的其他部门，供方发现软件产品更容易转移到新的顾客；
- 作为进一步增强的基础。因为 SRS 文档讨论的是产品，而不是开发它的项目，因此，SRS是已开发产品后续增强的基础。尽管 SRS 文档或许需要修改，但它确实为后续的产品评价提供了基础。
计算机软件需求规格说明规范
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 4 SRS 的编制原则
4.1 综述
本章给出了编制 SRS 时宜考虑的事项及编制原则：
- SSRS的基本性质；
- SSRS 的环境；
- 好的 SRS 的特性；
- SSRS的联合编制；
- SRS 演变；
- 原型法；
- SRS 中嵌入设计；
- SRS 中嵌人项目需求。
4.2 2 SRS 的基本性质
SRS 是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。SRS可由来自供方、顾客或双方的一个或者多个人员编写，4.5推荐由来自供方和顾客双方的人员联合编写。
SRS 编写人员应关注以下基本点：
- 功能- 软件将执行什么功能?
- 外部接口- 软件如何与人、系统的硬件及其他硬件和其他软件进行交互?
- 性能- 各种软件功能的速度、响应时间、恢复时间等是多少?
- 属性—-软件的可用性、可靠性、可移植性、正确性、可维护性、安全性 5如何?
- 影响产品实现的设计约束- 是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求?
编写人员宜避免把设计或项目需求写入 SRS 中。
SRS 的内容详见第5章。
4.3 SRS 的环境
很重要的一点是应考虑 SRS 在整个项目计划中的作用。项目计划的定义见 GB/T 11457。软件既可以基本上包括了项目的所有功能，也可以是更大系统的一部分。在后一种情况，典型的 SRS 将指出系统及其软件部分的接口，并将外部性能和功能需求写人软件部分。显然，SRS 应当在系统需求上扩展并与其保持一致。
GB/T 8566 描述了软件生存周期的各个步骤，以及每步适用的输入。与软件生存周期等有关的其他标准，可对软件需求进行补充。
因为 SRS 在软件开发过程中发挥特定的作用，编写人员宜谨慎对待，不超出其作用的范围。这意味着 SRS ：
- 宜正确地定义所有软件需求。由于将要处理的任务的性质或项目的具体特性，则软件需求是存在的。
- 不宜描述任何设计或实现的细节。这些内容应当在项目的设计阶段进行描述。
- 不宜对软件设置附加的限制条件。这些内容可在其他文件中规定，如，软件质量保证计划。
因此，编写适当的 SRS 限定了正确设计的范围，但不规定任何具体的设计。
4.4 好的 SRS 的特征
4.4.1 综述
SRS宜是：
- 正确；
- 无歧义；
- 完备；
- 一致；
- 重要性和/或稳定性分级；
- 可验证；
- 可修改；
- 可追踪。
4.4.2 正确
当且仅当 SRS 中的每一项需求都是软件应满足的需求，SRS 才是正确的。
不存在确保 SRS 正确性的工具或规程。宜把 SRS 与任何适用的上层规格说明(如，系统需求规格说明)、其他项目文件和其他适用的标准进行对比，以确保其相互一致。作为一种选择，顾客或用户可以确定 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 1自然语言的缺陷
需求通常使用自然语言(如，汉语)来编写。但自然语言具有固有的不明确性。使用自然语言编制的 SRS 宜由独立的一方进行评审，以识别语言的含糊用法并予以纠正。
4.4.3.2 需求规格说明语言
避免自然语言固有的歧义的一种方式是，使用特定的需求规格说明语言编写 SRS。该语言处理器可自动检测出许多词法、句法和语义错误。
使用这类特定语言的缺点是，学习语言需要较长的时间。同时，多数非技术方面的使用者发现它们不易理解。此外，这类语言倾向于表述某些特定类型的需求和处理某些特定类型的系统。因此，这类语言可能以难以捉摸的方式影响这些需求。
4.4.3.3 表述工具
一般而言，支持编制需求的方法、语言和工具分为三种通用类别：对象、过程和行为。面向对象的方法按照现实世界的对象、它们的属性和这些对象完成的服务来组织需求；基于过程的方法将需求组织成功能的层次结构，而这些功能通过数据流 6进行通信；基于行为的方法利用一些抽象的符号(如，谓词演算)、数学函数或状态机来描述系统的外部行为。
这些工具和方法对编制 SRS 时的有用程度依赖于项目的规模和复杂性。这里并不试图描述和认可任何特定的工具。
当使用任何这类方法时，最好仍保持自然语言方式的描述，这样，不熟悉这些方法、符号的顾客仍然能够理解 SRS。
4.4.4 完备
4.4.4.1 当且仅当 SRS 包含以下要素，SRS才是完备的：
- 所有重要的需求，不论是否与功能、性能、设计约束、属性或者外部接口有关。尤其是由系统规格说明所施加的任何外部需求都应当得到确认和处理。
- 软件响应的定义，以说明软件对所有可实现的输入数据类型的响应。应当注意，对于有效和无效输入数值两种情况，规定软件响应是重要的。
- SRS 中所有图表的全面标记和索引，以及所有术语和度量单位的定义。
4.4.4.2 任何含有“待定”词语的 SRS 是不完备的。但是有时使用“待定”是不可避免的，若万一使用“待定”时应做如下说明：
- 对导致使用“待定”的情形进行描述(为什么答案未知)，以便问题能得到解决；
- 描述为排除“待定”应采取的措施、由谁负责排除以及何时必须排除。
4.4.5 一致
4.4.5.1 一致是指内部一致性。如果 SRS 与某些更高层的文档(如，系统规格说明)不一致，那么它是不正确的(见4.4.1)。
4.4.5.2 当且仅当在 SRS中描述的任何单个需求的子集之间相互不矛盾， SRS 才是内部一致的。 SRS 中可能存在下述三种类型的矛盾：
- 现实世界对象的规定特征可能相互矛盾。如：
- 报告输出的格式在一个需求中是表格形式，而在另一个需求中是文本形式；
- 一个需求指出所有的灯是绿色，而另一个需求规定所有的灯是蓝色。
- 在两个规定的行为之间可能存在逻辑上的或时间上的冲突。如：
- 一个需求规定程序将对两个输入相加，另一个需求则规定程序将对这两个输入相乘；
- 一个需求指出“A”必须总是在“B”之后，面同时在另一个需求中要求“A和B”同时发生。
- 可能两个或更多的需求描述现实世界的相同对象，但使用不同的术语。如，在一个需求中程序对用户输入的请求称为“提示符”，在另一个需求中称为“提示”。使用标准术语和定义可以改善一致性。
4.4.6 重要性和/或稳定性分级
如果 SRS 中每条需求赋有标明其重要性或稳定性的标识，那么该 SRS 便按照重要性和/或稳定性进行了分级。
通常，与软件产品有关的所有需求并不具有相同的重要性。某些需求可能是基本的，特别是与人身生命有关的关键应用，而其他的可能是所期望的需求。
SRS 中的每个需求宜予以标识，以使需求在这方面的差异清晰和明确。按下述方式标识需求有助于：
- 使顾客更仔细地考虑每个需求，这样，常常会澄清顾客可能引入的任何隐藏的假设；
- 使开发人员做出正确的设计决定，并针对软件产品的不同部分做出相应适当工作的投入。
4.4.6.1 稳定性程度
可以用需求的期望变更次数来标识需求的稳定程度。
4.4.6.2 重要性程度
另一种需求分级的方式是区分如下基本的、有条件的和可选的需求类别：
- 基本的- 除非表示同意并满足了这类需求，否则软件将不被接受；
- 有条件的- 表示这类需求会增强软件产品，但是，如果缺少这类需求，也不会导致软件产品被拒收；
- 可选的T_-表示该类功能需求可有可无，这赋予供方提出超出 SRS 的建议的机会和余地。
4.4.7 可验证
当且仅当 SRS 中的每个需求是可验证的，SRS 才是可验证的。当且仅当存在某个有限的成本、有效的过程，人或机器依照该过程能够检查软件产品满足某个需求，该需求才是可验证的。一般说来，任何有歧义的需求都是不可验证的。
不可验证的需求包含诸如“工作良好”、好的人机界面”和“通常应该发生”之类的陈述。因为不可能定义“良好”“好的”和“通常”，因此，这些需求不可能验证。陈述“程序应绝对不进入无限循环”是不可验证的，因为理论上该特性是不可测试的。
可验证陈述示例： 程序输出应在事件开始20s内达到 60%，在 30s内达到100%。 这样的陈述是可验证的，因为它使用了具体的术语和可测量的数值。
如果不能设计出一种方法，以确定软件是否满足某个具体的需求，那么该需求宜被删除或被修改。
4.4.8 可修改
当且仅当 SRS 的结构和形式能够对任何需求进行容易、全面和一致的修改，同时保持该结构和形式，SRS才是可修改的。一般地，可修改性要求 SRS：
- 具有连贯、方便使用的结构，包含目次、索引及清晰的相互引用；
- 没有冗余(即，相同的需求在 SRS 不应当出现在多处)；
- 分别地表述每个需求，而不与其他需求相混淆。
尽管冗余本身不是缺陷，但它容易导致错误。尽管冗余偶尔可以有助于 SRS 的可读性，但当对存在冗余的文件更新时，可能会引起问题。例如，可能对出现多处的某个需求仅在一处做了修改，那么使得 SRS 内容不一致。当需要冗余时，SRS宜包括一个清晰地交叉索引表，以增加其可修改性。
4.4.9 可追踪
如果 SRS 每个需求的来源是清楚的，并在将来编制或增强文档的过程中便于每个需求的索引，那么该 SRS 是可追踪的。推荐以下两种类型的可追踪性：
- 逆向可追踪性(即，到以前的开发阶段)。这依赖于每个需求清晰地指向其在早期文件的来源；
- 正向可追踪性(即，到由 SRS 产生的所有文件)。这依赖于 SRS 中每个需求具有唯一的名称或索引号。
当软件产品进入运行和维护阶段时，SRS的正向可追踪性尤其重要。随着代码和设计文档的修改，最要紧的是能够确定这些修改可能影响的全部的需求集合。
4.5 SRS 的联合编制
软件开发过程宜从顾客与供方关于完成的软件必须做什么达成的协议开始。依照 SRS 的形式，该协议宜联合起草。这一点很重要，因为通常不管是顾客还是供方，单方面都不具备编写一份良好 SRS的资格。
- 顾客通常对软件设计和开发过程了解的不够，不足以编写实用的 SRS；
- 供方通常对顾客的问题和从事的领域了解不够，不足以为系统规定满意的需求。
因此，顾客和供方宜一起工作，以编写良好的、全面的和可理解的 SRS。
当系统及其软件二者同时被定义时，存在一种特殊情况，软件的功能、接口、性能、及其他的属性和限制条件不是预先定义的，而是联合定义并且需要协商和变更，这使得满足4.4所述的特征更困难，但更重要。尤其是，不符合其母系统需求规格说明的软件 SRS 是不正确的。
本标准不具体讨论 SRS 的形式、语言的使用或良好的编写技巧，但是，编写良好的 SRS十分重要。一般的技术写作书籍可用作编写指南。
4.6 SRS 的演变
随着软件产品开发的进展， SRS 可能需要演变。在项目开始时，规定某些细节是不可能的(例如，对于一个交互程序，在需求阶段定义所有屏幕格式是不可能的)。随着 SRS 中的缺陷、不足和不准确之处的发现，可能会相继发生对 SRS的其他变更。
在此过程中，两个重要的考虑事项如下：
- 尽管可以预见对 SRS 的演变修订是不可避免的，但在某个时间对需求的规定应当尽可能完全和细致。宜注明需求不完备的事实；
- 宜启动正式的变更过程，以识别、控制、跟踪和报告指定的变更。已批准的需求变更宜按以下方式纳入 SRS 中：
- 提供准确的和全面的变更审核追踪记录；
- 允许对 SRS 的当前版本和先前版本进行评审。
4.7 原型法
在项目的需求阶段常常使用原型法。一些工具可简单、快捷地创建体现系统某些特征的原型。注：可参照 ASTM E 1340：1996《计算机系统快速原型法标准指南》。
原型的实用性有以下原因：
- 与阅读 SRS 和提出意见相比，顾客更有可能考察原型并提出建议；
- 原型可演示系统行为不可预见的方面，因此，原型不但提供答案，同时还提出一些新的问题，这有助于完善 SRS；
- 基于原型提出的 SRS 在开发过程中倾向更少的变更，从而减少开发时间。
原型是用于提取软件需求的一种方式。诸如屏幕或报告格式之类的某些特征可以直接从原型中提取。其他需求可以通过进行原型试验推导出来。
4.8 SRS 中嵌入设计
4.8.1 一般来说，在 SRS 中尽量避免嵌入设计说明，在 SRS 中嵌入设计说明会过多地约束设计，并且人为地把具有潜在危险的需求引人SRS。
一个需求规定了系统某个外部可见的功能或属性。设计描述了系统某个具体的子部件和/或它与其他子部件的接口。 SRS 编写人员应当清楚地区分识别所需要的设计约束和构想具体的设计之间的差异。应当注意，SRS的每个需求限制了设计的可选择性。但这并不意味着每个需求就是设计。
SRS 应当规定对何数据执行何功能以便在何地为何人产生何种结果。SRS 宜集中于所提供的服务。 SRS 通常不规定设计事项，如：
- 划分软件为各个模块；
- 分配功能到各个模块；
- 描述模块之间的信息流或控制流；
- 选择数据结构。
4.8.2 把设计和 SRS完全割裂开来也是不现实的。在某些特殊情况下，某些需求可能严重地限制了设计。对安全或保密安全方面的周密考虑可能增加一些直接反映设计约束的需求，例如：
- 用几个分开的模块来实现某些功能；
- 在程序的某些区域之间仅允许有限的通信；
- 对临界的变量检查数据的完整性。
有效的设计约束条件示例如：物理需求、性能需求、软件开发标准以及软件质量保证标准。
因此，宜从完全外部的角度规定需求。当使用模型阐述需求时，应记住模型仅仅用来表明系统的外部行为，并不规定设计。
4.9 SRS 中嵌入项目需求
SRS 宜关注软件产品，而不是软件产品的生产过程。
项目需求表示了顾客和供方之间有关软件生产合同事宜的理解，因此不宜包括在 SRS 中。
通常这些项目需求包括如下：
- 成本；
- 交付进度；
- 报告规程；
- 软件开发方法；
- 质量保证；
- 验证和确认准则；
- 验收规程。
项目需求在其他文档中规定，通常在软件开发计划、软件质量保证计划或者工作说明中规定。
5 5 SRS 的组成和内容要求
5.1 综述
本章讨论组成 SRS 的每个基本组成部分和内容要求。图1以提纲形式列出这些部分，可作为编写SRS 的示例。
尽管 SRS 不必要按照此提纲或使用这里给出的各章条的名称，但是，一份良好的 SRS 宜包括以下论述的所有信息。
目 次
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 几种不同模式。)
附录
索引
5.2 引言 (SRS的第1章)
SRS 的引言部分应当提供整个 SRS的概述，包括以下各条：
- 目的；
- 范围；
- 定义、简称和缩略语；
- 引用文件；
- 综述。
5.2.1 目的(SRS 的 1.1)
本条宜：
- 描述 SRS 的目的；
- 说明 SRS 的预期读者。
5.2.2 范围(SRS 的 1.2)
本条宜：
- 通过名称识别要生产/开发的软件产品(例如，宿主数据库管理系统(DBMS)、报告生成器等)；
- 必要时，说明软件产品将做或不做什么；
- 描述规定的软件的应用，包括相关的收益、目标和目的；
- 如果上层规格说明(如，系统需求规格说明)存在，与上层规格说明类似的陈述保持一致。
5.2.3 定义、简写和缩略语(SRS 的1.3)
本条宜提供对正确解释 SRS 所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS 中的一个或多个附录、或者引用其他文件的方式来提供。
5.2.4 引用文件 (SRS 的1.4)
本条宜：
- 提供 SRS 引用的所有文件的完整清单；
- 标识出每个文件的名称、报告编号(适用时)、日期、出版组织；
- 标明可以获得引用文件的来源。
这些信息可以通过引用附录或引用其他文档的方式提供。
5.2.5 综述 (SRS 的 1.5)
本条宜： - 描述 SRS 的其余章条包含的内容； - 说明 SRS 是如何组织的。
5.3 总体描述 (SRS 的第2章)
本章宜描述影响产品及其需求的一般因素，而不叙述具体的需求。相反，它提供需求的背景并使它们更易理解，面在 SRS的第3章将详细定义这些需求。
本章通常由以下6条组成：
- 产品描述；
- 产品功能；
- 用户特点；
- 约束；
- 假设和依赖关系；
- 需求分配。
5.3.1 产品描述(SRS的 2.1)
本条宜把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，这里宜如实给予陈述。正如常出现的那样，如果 SRS 定义的产品是较大系统的组成部分，则本章宜将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接口。
使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的。
本条也宜描述在各种不同的约束下软件如何运行。如，这些约束可包括：
- 系统接口；
- 用户界面；
- 硬件接口；
- 软件接口；
- 通信接口；
- 内存；
- 运行；
- 现场适应性需求等。
5.3.1.1 系统接口
本条宜列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。
5.3.1.2 用户界面
本条宜规定以下方面：
- 在软件产品与用户之间每个界面的逻辑特征。这包括完成软件需求所需要的那些配置特征(例如，要求的屏幕显示格式、页面或窗口版式布局、任何报告或菜单的内容、或者可编程功能键的设置)；
- 优化系统用户界面的所有方面。这可以简单地包括一个针对系统对用户的显示方式系统将做什么和不做什么的清单。例如，可能是一项选择长或短的错误消息方面的需求。如同所有其他需求一样，这些需求宜是可验证的，例如，“经过1h培训后，4级打字员能够在 Z min 内执行功能X”，而不是“打字员能够执行功能 X”(这也可以在标题为使用方便性章条的软件系统属性中规定)。
5.3.1.3 硬件接口
本条宜规定系统硬件各部件与软件产品之间每个接口的逻辑特征，包括配置特征(端口数量、指令集等)，同样也覆盖这些事项，如，支持什么设备、如何支持以及采用什么协议。例如，相对逐行支持，终端支持可能规定为全屏支持。
5.3.1.4 软件接口
本条宜规定对其他软件产品(例如，数据管理系统、操作系统、或数学软件包)的使用，以及与其他应用系统(例如，账户接收系统和一般的会计记帐系统的链接)的接口。对于每个要求的软件产品，宜提供：
- 名称；
- 助记符；
- 规格说明编号；
- 版本号；
- 来源。
对于每个接口，宜提供：
- 相对此软件产品，接口软件的目的的论述；
- 按照消息内容和格式风接口的定义，不必要详细描述任何已文件化的接口，但要求引用定义此接口的文件。
5.3.1.5 通信接口
本条宜定义不同的通信接口，如，局域网协议等。
5.3.1.6 5.3.1.6 内存约束
本条宜规定对主存和辅存的任何适用特征和限制。
5.3.1.7 操作
本条宜规定用户要求正常的和特定的操作，如：
- 用户组织的不同操作模式(如，用户引发的操作)；
- 交互操作的周期和无人值守操作的周期；
- 数据处理支持功能；
- 备份和恢复操作。
注：有时此条规定作为用户界面的一部分。
5.3.1.8 现场适应性需求
本条宜：
- 对于给定的现场、任务或运行模式(如，网格数、安全限制等)，为任何数据或启动顺序定义需求；
- 针对软件适应特定的安装现场或任务，规定应当修改的特征。
5.3.2 产品功能(SRS的 2.2)
本条宜给出软件将执行主要功能的概要。例如，某个会计程序的 SRS 可在此部分关注顾客账户维护、顾客财务报表及发票准备，而不涉及这些功能要求的大量细节。
有时，本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明(如果存在)中摘录。为了清晰，应当注意：
- 功能宜以这样的方式组织，以使顾客或第一次阅读该文件的任何读者对功能列表容易理解；
- 可以使用文本或图示的方法，显示不同的功能及其之间的关系。这样的图示不必显示产品的设计，但简要显示变量之间的逻辑关系。
5.3.3 用户特点 (SRS 的2.3)
本条宜给出软件产品预期用户的一般特征，包括教育程度、经验、专业技术情况。它不宜指出具体的需求，但宜给出 SRS第3章中为何规定某些具体需求的原因。
5.3.4 约束 (SRS 的 2.4)
本条宜给出将会限制开发人员选择的任何其他事项的一般描述。这些包括：
- 法规政策；
- 硬件局限(如，信号时间要求)；
- 与其他应用的接口；
- 并行操作；
- 审核功能；
- 控制功能；
- 高级语言需求；
- 信号握手协议(如，XON-XOFF、ACK-NACK)；
- 可靠性需求；
- 应用的关键性；
- 安全和保密安全考虑。
5.3.5 假设和依赖关系 (SRS的2.5)
本条宜列出影响 SRS 规定需求的每个因素。这些因素不是软件设计的限制条件，但是，它们的任何变更可能影响 SRS 中的需求。例如，某个假设可能是软件产品指定的硬件具有某个特定操作系统，如果事实上该操作系统不能使用，那么 SRS 将做相应的修改。
5.3.6 需求分配 (SRS 的2.6)
本条宜识别可能推迟到系统将来版本的需求。
5.4 具体需求 (SRS 的第3章)
本章宜包括足够详细的所有软件需求，使设计人员能够设计系统以满足这些需求，并且使测试人员能够测试该系统满足这些需求。贯穿本章，对于用户、运行人员或其他外部系统，每个规定的需求应当是外部可理解的。这些需求至少应当包括，每个系统输入(激励)、每个系统输出(响应)以及系统通过响应某个输入或支持某个输出所执行的所有功能。由于这通常是 SRS 篇幅最大和最主要部分，以下原则适用：
- 规定的具体需求宜符合4.4描述的所有特征；
- 具体需求宜引用较早的相关文件；
- 所有的需求宜是唯一可标识的；
- 宜注意需求的组织，使其具有最大的可读性。
在考察组织需求的具体方式之前，了解5.4.1到5.4.7组成需求的各个不同项是有益的。
5.4.1 外部接口
本条宜是软件系统所有输入和输出的详细描述。它宜是对5.2的接口描述的补充，不宜重复前面已有的信息。
宜包括以下内容和格式：
- 项的名称；
- 目的描述；
- 输入源和输出目的地；
- 有效范围、准确度和/或容限；
- 测量单位；
- 定时；
- 与其他输入/输出的关系；
- 屏显格式/组织；
- 窗口格式/组织；
- 数据格式；
- 命令格式；
- 结束消息。
5.4.2 功能
功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作。一般情况下使用“系统应…….”的方式来陈述。
这些包括：
- 对输人有效性的核渣；
- 操作的准确顺序；
- 异常情况响应，包括：
- 溢出；
- 通信设施；
- 错误处理和恢复；
- 参数影响；
- 输入与输出的关系，包括：
- 输入/输出顺序；
- 从输入到输出转换的公式。
尽管将功能需求划分为子功能或子过程可能是适当的，但这并不意味着软件设计同样以这样的方式划分。
5.4.3 性能需求
本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求。静态数量化需求可能包括：
- 支持的终端数量；
- 支持同时运行的用户数量；
- 要处理的信息量和类型。
有时，静态数量需求包含在命名为“能力”的独立部分。
动态数量化需求可能包括，如，在正常和高峰工作负载条件，在某时段内处理的事务处理数、任务数和数据量。
所有这些需求宜以可测量的方式规定。如：
应在小于1s内处理95%的交易量。 而不是：
操作方不需等待事务处理结束。 注：适用于某个具体功能的数量化限制，通常作为该功能处理描述部分予以规定。
5.4.4 数据库逻辑需求
宜规定将置于数据库的任何信息的逻辑需求。这可包括：
- 不同功能使用的信息类型；
- 使用频度；
- 访问能力；
- 数据实体及其之间的关系；
- 完整性约束；
- 数据保存需求。
5.4.5 设计约束
宜规定可能由其他标准、硬件局限等引发的设计约束。
5.4.5.1 标准依从性
本条宜规定来自现存标准或法规的需求。它们可能包括：
- 报告格式；
- 数据命名；
- 会计规程；
- 审核追踪。
例如，可以规定追踪处理活动的软件需求。为了最低满足法规或财务标准，对于某些应用这样的追踪是需要的。例如，审核追踪需求可能规定，对于支付薪金数据库的所有变更，必须在一个追踪文档中记录支付前后的数额。
5.4.6 软件系统属性
有一些软件属性可以作为需求。规定所要求的软件属性是重要的，这样才能客观地验证属性的实现情况。5.4.6.1到5.4.6.5给出了部分示例。
5.4.6.1 可靠性
本条宜规定要求的因素，以便建立在交付时软件系统所要求的可靠性。
5.4.6.2 可用性
为了确保整个系统已定义的可用性程度，宜规定所要求的因素，如，检查点、恢复以及重启动。
5.4.6.3 安全保密性
由于事故、恶意访问、使用、修改、破坏或泄露，本条宜规定需要保护软件的因素。这方面可能的具体需求包括：
- 使用某些密码技术；
- 保留某些特定数据组的历史或记录；
- 分配某些功能到不同的模块；
- 在程序的某些域间限制通信；
- 对于关键变量检查数据的完整性。
5.4.6.4 可维护性
本条宜规定与软件本身维护简易性有关的软件属性。可以对模块化、接口和复杂性等有一定的要求。但不宜仅因为是良好设计实践就将其作为需求。
5.4.6.5 可移植性
本条宜规定与软件移植到其他主机和/或操作系统简易性相关的软件属性。这可能包括：
- 依赖主机代码模块的百分比；
- 依赖主机代码的百分比；
- 已证明可移植语言的使用；
- 特定编译器或语言子集的使用；
- 特定操作系统的使用。
5.4.7 具体需求的组织
除了微小的系统之外，任何系统倾向有大量的详细的需求。由此，宜仔细考虑这些需求的组织方式，以最优化可理解性。对于所有的系统不存在单一的最优化组织方式。不同类型的系统 SRS 的第3章有不同的需求组织方式。5.4.7.1到5.4.7.7描述了一些组织方式。
5.4.7.1 系统模式
依赖于运行模式，某些系统的行为显著不同。例如，根据其运行模式：培训、正常运行或者应急，某个控制系统可能具有不同的功能集合。当按照运行模式组织该部分时，宜采用第A.1章或第A.2章的提纲。需求组织方式的选择取决于系统接口和性能是否依赖于运行模式。
5.4.7.2 用户类型
有些系统对不同的用户提供不同的功能集合。例如，对于一般乘客、维护人员和消防人员，电梯控制系统显示不同的能力。当按照用户类别组织该部分时，宜采用第A.3章的提纲。
5.4.7.3 对象
对象是现实世界中的实体，系统具有与其对应的部分。例如，在病人监控系统中，对象包括病人、传感器、护士、房间、医师、医药等。与每个对象相联系的是一组属性(对象具有的)和功能(对象执行的)，这些功能也称之为服务、方法或过程。当按照对象组织该部分时，宜采用第 A.4章的提纲。应注意，对象组可能共有某些属性和服务，要按照类别把这些组织在一起。
5.4.7.4 特征
系统特征是从外部希望得到的服务，可能要求一系列的输入以产生希望的结果。例如，在电话系统中，系统特征包括本地话务、话务转接、以及会议话务。一般的，系统每个特征按照一系列激励-响应对的方式描述，当按照系统特征组织该部分时，宜采用第A.5章的提纲。
5.4.7.5 激励
某些系统可以根据激励描述其功能的方式最佳地组织其需求。例如，飞机自动着陆系统的功能，可依照动力降低、风向切变、机身摇摆突变、垂直速度限值等，组织到相应的部分。当按照激励方式组织该部分时，宜采用第A.6章的提纲。
5.4.7.6 响应
有些系统可以通过描述其支持产生某个响应的所有功能，最佳地组织其需求。例如，某个人员管理系统的功能，可按照与产生薪金支付有关的所有功能、与产生当前职员清单有关的所有功能，等等，予以组织到相应的部分。宜采用第 A.6章的提纲(所有的激励之处由响应替代)。
5.4.7.7 功能层次
当上述组织方式证明没有益处时，可按照共同的输入、共同的输出或者共同的内部数据访问，将系统总体功能性组织成为一个功能层次。数据流图和数据词典可以用来表示功能和数据之间的相互关系。当按照功能层次组织该部分时，宜采用第A.7章的提纲。
5.4.8 附加说明
在编制新的 SRS 时，在5.4.7.7给出的多种组织技术可能都是适用的。在这种情况下，宜依据该系统的特定要求所剪裁出的若干层次来组织特定的需求。例如，第A.8章组织形式结合了用户类别和系统特征。任何附加的需求，可以在 SRS 的结尾处放在一个独立的部分。
有许多现行可用于帮助需求文档 7化的符号、方法和自动化支持工具。就大部分而言，它们的有效性是组织的职能。例如，当按照运行模式组织时，限定的状态机或状态图表可能证明是有益的；当按照对象组织时，面向对象的分析可能是有益的；当按照系统特征组织时，激励-响应序列可能证明是有益的；当按照功能结构组织时，数据流图和数据词典可能证明是有益的。
5.5 支持信息
支持信息以使 SRS更容易使用，包括：
- 目次；
- 索引；
- 附录。
5.5.1 目次和索引
目次和索引十分重要，宜按照一般的文档编写惯例。
5.5.2 附录
附录并不总是实际的 SRS 的一部分或总是需要的。附录可以包括：
- 输入/输出格式示例，成本分析研究，或者用户调查的结果；
- 有助于读者理解 SRS 的支持或背景信息；
- 软件所解决的问题描述；
- 对代码和媒体的特殊包装说明，以满足安全、出口、初始装人、或其他需求。
当包括附录时， SRS 宜明确地规定附录是否作为需求的部分。