计算机软件需求规格说明规范
[TOC]
0 来源
国家标准 GB/T 9385-2008 《计算机软件需求规格说明规范》
1 SRS的编制原则
SRS：软件需求规格说明，Software Requirements Specification。
1.1 综述
本章给出了编制SRS时宜考虑的事项及编制原则：
- SRS的基本性质；
- SRS的环境；
- 好的SRS的特性；
- SRS的联合编制；
- SRS演变；
- 原型法；
- SRS中嵌入设计；
- SRS中嵌入项目需求。
1.2 SRS的基本性质
SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。SRS可由来自供方、顾客或双方的一个或多个人员编写，推荐由来自供方和顾客双方的人员联合编写。SRS编写人员应关注一下基本点：
- 功能：软件将执行什么功能？
- 外部接口：软件如何与人、系统的硬件及其他硬件和其他软件进行交互？
- 性能：软件各种功能的速度、响应时间、回复时间等是多少？
- 属性：软件的可用性、可靠性、可移植性、正确性、可维护性、安全性如何？
- 影响产品实现的设计约束：是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？
SRS编写人员宜<font color=red>避免把设计或项目需求写入SRS中</font>。
1.3 SRS的环境
很重要的一点是应考虑SRS在整个项目计划中的作用。项目计划的定义见《GB/T 11457 信息技术 软件工程术语》。软件既可以基本上包括了项目的所有功能，也可以是更大系统的一部分。在后一种情况，典型的SRS将指出系统及其软件部分的接口，并将外部性能和功能需求写入软件部分。显然，SRS应当在系统需求上扩展并与其保持一致。
《GB/T 8566 信息技术 软件生存周期过程》描述了软件生存周期的各个步骤，以及每步适用的输入。与软件生存周期等有关的其他标准，可对软件需求进行补充。
因为SRS在软件开发过程中发挥特定的作用，编写人员宜谨慎对待，不超出其作用的范围。这意味着SRS：
- <font color=red>宜</font>正确地定义所有软件需求。由于将要处理的任务的性质或项目的具体特性，软件需求是存在的。
- <font color=red>不宜</font>描述任何设计或实现的细节。这些内容应当在项目的设计阶段进行描述。
- <font color=red>不宜</font>对软件设置附加的限制条件。这些内容可在其他文件中规定，如软件质量保证计划。
因此，编写适当的SRS<font color=green>仅限定了正确设计的范围，但不规定任何具体的设计</font>。
1.4 好的SRS的特征
好的SRS宜是：
正确：当且仅当SRS中的每一项需求都是软件应满足的需求，SRS才是正确的。注意，不存在确保SRS正确性的工具或规程，正确性应通过充分的沟通、审核和迭代来保证。
无歧义：当且仅当SRS中的每一项需求都只有一种解释，SRS才是无歧义的。这要求最终产品的每个特征至少使用唯一的术语来描述。使用自然语言编制的SRS宜由独立的一方进行评审，以识别语言的含糊用法并予以纠正。或使用特定的需求规格说明语言来编写SRS。
完备：当且仅当SRS包含以下要素，SRS才是完备的：
所有重要的需求，不论是否与功能、性能、设计约束、属性或者外部接口有关，尤其是由系统规格说明所施加的任何外部需求都应当得到确认和处理。
软件响应的定义，以说明软件对所有可实现的输入数据类型的响应。应当注意，对于有效和无效输入数据两种情况，规定软件响应是重要的。
SRS中所有图表的全面标记和索引，以及所有术语和度量单位的定义。
任何含有“待定”词语的SRS是不完备的，万一不得不使用“待定”时应做如下说明：
对导致“待定”的情形进行描述（为什么答案未知），以便问题能够解决；
描述为后续排除“待定”应采取的措施、由谁负责排除以及何时必须排除。
一致：一致是指内部一致性。当且仅当SRS中描述的任何单个需求的子集之间互不矛盾，SRS才是内部一致的。
重要性和/或稳定性分级：SRS中每条需求附有标明其重要性或稳定性的标识，使顾客更仔细的考虑每个需求，使开发人员做出正确的设计决定并针对软件产品的不同部分做出相应适当工作的投入。可以用需求的期望变更次数来标识需求的稳定程度，用“基本的”、“有条件的”、“可选的”等类别来进行需求重要性分级。
可验证：当且仅当SRS中每个需求都是可验证的情况下，SRS才是可验证的。当且仅当存在某个有限的成本、有效的过程，人或机器依照该过程能够检查软件产品满足某个需求，该需求才是可验证的。一般来说，任何有歧义的需求都是不可验证的，即需求应该使用明确的可验证的指标来阐述具体要求。如果不能设计出一种方法，以确定软件是否满足某个具体的需求，那么该需求宜被删除或修改。
可修改：SRS的结构和形式能够对任何需求进行容易、全面和一致的修改，同时保持该结构和形式。可修改性要求SRS：
- 具有连贯、方便使用的结构，包含目次、索引及清晰的相互引用；
- 没有冗余，即相同的需求不应当多次出现；当确实需要冗余时，SRS宜包含一个清晰的交叉索引表，以增加其可修改性；
- 分别的表述每个需求，不与其他需求相混淆。
可追踪：SRS中每个需求的来源都应当是清楚的，并在将来编制或增强文档的过程总便于每个需求的索引。
1.5 SRS联合编制
通常不管是顾客还是供方，单方面都不具备编写一份良好SRS的资格。顾客通常对软件设计和开发过程了解不够，供方常对顾客的问题和从事的领域了解不够不足以为系统规定满意的需求。因此，顾客与供方宜一起工作以编写良好的、全面的和可理解的SRS。
1.6 SRS的演变
随着产品开发的进展，SRS可能需要演变，因为在项目开始时规定某些细节是不可能的。随着SRS中的缺陷、不足和不准确支持的发现，可能会相继发生对SRS的其他变更。在此过程中需要考虑的两个重要事项如下：
- 尽管SRS的演变修订不可避免，但在某个时刻对需求的规定应当尽可能完全和细致，宜注明需求不完备的事实。
- 宜启动正式的变更过程，以识别、控制、跟踪和报告指定的变更。已批准的需求变更宜按照以下方式纳入SRS中：
- 提供准确的和全面的变更审核追踪记录；
- 允许对SRS当前版本和先前版本进行评审。
1.7 原型法
在项目的需求阶段常常使用原型法，简单快捷并直观的体现某些系统特征。原型的实用性有以下原因：
- 对比SRS报告，顾客更有可能考察原型并提出有价值的建议；
- 原型不但提供答案，同时还提出一些新的问题，有助于完善SRS；
- 基于原型提出的SRS在开发过程中倾向更少的变更，从而减少开发时间。
1.8 在SRS中嵌入设计
一般来说，在SRS中尽量避免嵌入设计说明。
<font color=green>一个需求规定了系统某个外部可见的功能或属性，而设计描述了系统某个具体的子部件和/或它与其他子部件的接口。</font>
SRS的每个需求限制了设计的可选择性，但并不意味着每个需求就是设计。
<font color= red> SRS应当规定对何时执行何功能以便在何地为何人产生何种结果，SRS集中于所提供的服务，通常不规定设计事项</font>，如：
- 划分软件为各个模块
- 分配功能到各个模块
- 描述模块之间的信息流或控制流
- 选择数据结构
把SRS和设计完全割裂开也是不现实的，在某些特殊情况下，某些需求可能严重限制设计。对安全或保密安全方面的周密考虑可能增加一些直接反应设计约束的需求，例如：
- 用几个分开的模块实现某些功能
- 在程序的某些区域之间仅允许有限的通信
- 对临界的变量检查数据的完整性
有效的设计约束条件示例如：物理需求、性能需求、软件开发标准以及软件质量保证标准。因此，宜从完全外部的角度规定需求；当使用模型阐述需求时，应记住模型仅仅用来表面系统的外部行为，并不规定设计。
1.9 在SRS中嵌入项目需求
SRS宜关注软件产品，而不关注其生产过程。
项目需求表示了顾客与供方之间有关软件生产合同事宜的理解，不宜包含在SRS中。通常项目需求包括如下：
成本
交付进度
报告规程
软件开发方法
质量保证
验证和确认准则
验收规程
2 SRS的组成和内容要求
一份良好的SRS提纲示例如下。
1. 引言
引言部分应当提供整个SRS的概述。
1.1 目的
本条宜：
1.2 范围
本条宜：
- 通过名称识别要开发的软件产品
- 必要时说明软件产品将做或不做说明
- 描述规定的软件的应用，包括相关受益、目标和目的
- 如存在上层规格说明，则需与上层说明保持一致
1.3 定义、简写和缩略语
本条可通过附录或引用其他文件提供。
1.4 引用文件
按照标准格式提供引用的所有文件完整清单，标明可以获得引用文件的来源。可以通过附录或引用其他文件的方式提供。
1.5 综述
本条宜：
- 描述SRS的其余章节包含的内容
- SRS是如何组织的
2. 总体描述
本章描述影响产品及其需求的一般因素，而不叙述具体的需求；相反，它提供需求的背景并使它们更易被理解。
2.1 产品描述
本条宜把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，则应如实给予陈述。
本条也宜描述在各种不同的约束下软件如何运行，这些约束可包含：
- 系统接口：列出每个系统接口，以及系统需求的软件功能和接口描述。
- 用户界面：规定每个界面的逻辑特征和配置特征，以及优化系统用户界面的所有方面（可以简单的包括一个针对界面显示方式系统将做什么和不做说明的清单）。
- 硬件接口：软件与硬件接口的逻辑特征。
- 软件接口：规定对其他软件产品的使用以及与其他应用系统的接口。
- 通信接口：定义通信接口。
- 内存：包含主存和辅存，最小内存和硬盘空间等。
- 运行操作：规定用户要求正常的和特定的操作。
- 现场适应性要求：本条宜
- 对于给定的现场、任务或运行模式，为任何数据或启动顺序定义需求；
- 针对软件适应特定的安装现场或人物，规定应当修改的特征。
2.2 产品功能
本条给出软件将执行主要功能的概要，而不涉及这些功能要求的具体细节。
2.3 用户特点
本条给出软件产品预期用户的一般特征，例如技术背景、经验、教育经历等。
2.4 约束
本条给出研制开发人员原则其他任何实现的一般描述，包括
- 政策法规
- 硬件局限
- 与其他应用的接口
- 并行操作
- 审核功能
- 控制功能
- 高级语言需求
- 信号握手协议
- 可靠性需求
- 应用的关键性
- 安全和保密安全考虑
2.5 假设和依赖关系
本条列出影响SRS规定需求的每个因素，这些因素不是软件设计的限制条件，但是其任何改变都可能影响SRS中的需求。
2.6 需求分配
本条识别可能推迟到软件系统将来版本的需求。
3 具体需求
本章包含足够详细的所有软件需求，以供设计人员进行设计。每个规定的需求应当是外部可以理解的。这些需求至少应当包括，每个系统输入（激励）、每个系统输出（响应）以及系统通过响应某个输入或支持某个输出所执行的所有功能。这通常是SRS篇幅最大和最主要的部分，以下原则适用：
- 规定的具体需求符合1.4描述的所有特征
- 具体需求宜引用较早的相关文件
- 所有的需求都具是唯一可标识的
- 注意需求的组织，使其具有最大的可读性
3.1 外部接口需求
3.2 功能需求
3.3 性能需求
3.4 设计约束
3.5 软件系统属性
3.6 其他需求
附录
索引