【国家标准(GB)】 计算机软件需求规格说明规范

ICS35.080
中华人民共和国国家标准
GB/T9385--2008
代替GB/T9385-1988
计算机软件需求规格说明规范
Norm of computer software requirements specification2008-04-11发布
中华人民共和国国家质量监督检验检疫总局效码防伪
中国国家标准化管理委员会
2008-09-01实施
1范围
2规范性引用文件
3术语和定义
4SRS的编制原则
5SRS的组成和内容要求
附录A（资料性附录）SRS提纲模板目
A.1按照运行模式组织的SRS第3章模板（版本1）A.2按照运行模式组织的SRS第3章模板（版本2）A.3按照用户类别组织的SRS第3章模板A.4按照对象组织的SRS第3章模板A.5按照系统特征组织的SRS第3章模板A.6按照激励组织的SRS第3章模板A.7按照功能层次组织的SRS第3章模板A.8体现多种组织形式的SRS
第3章模板
参考文献
GB/T9385—2008
GB/T9385—2008
本标准是GB/T9385《计算机软件需求说明编制指南》的第一次修订。本标准与GB/T9385一1988的主要差别如下：
a）根据GB/T1.1的规定，原GB/T9385—1988版中第1章引言部分中的内容放在新版的引言部分；
b）新版标准的范围部分重新进行调整改写；第2章规范性引用文件删去了GB/T8567；c
根据GB/T8566和GB/T11457的规定，术语“开发者”改为“供方”；d)
原GB/T9385-1988版的第4章和第5章调整为新版的第4章，且名称为\SRS”的编制原则。e)
调整后的第4章更加清晰、完善。而删去了旧版第5章中有关模型的内容；f）旧版标准的第6章的主要内容调整为新版标准的第5章，而提纲部分调整为新版标准的附录A，且附录A的内容扩充了一部分。本标准的附录A是资料性附录。
本标准自实施之日起代替被废止GB/T9385-1988。本标准由中华人民共和国信息产业部提出。本标准由全国信息技术标准化技术委员会归口本标准起草单位：信息产业部电子工业标准化研究所、中国航天科技集团公司软件评测中心、上海计算机软件开发中心、上海宝信软件股份有限公司、东方通科技、广西软件园、上海浦东软件园有限责任公司、上海鲁齐信息科技有限公司。本标准主要起草人：冯惠、王宝艾、窦传义、石柱、杨根兴、李春青、陈在根、张旸旸、张露莹。本标推于1988年首次发布。
GB/T9385—2008
本标准描述了软件需求规格说明的编制方法。它基于以下设想，即软件需求规格说明确定过程的结果是一份明确和完备的规格说明文档。本标准将有助于：一软件的顾客准确地描述其希望得到什么；一软件的供方正确地理解顾客想要什么；一对于实现以下目标的有关单位和人员：·为其所在的组织编制份标准的软件需求规格说明(SRS)提纲；·定义其具体软件需求规格说明的格式和内容；·编制其他的本地支持资料，如，SRS质量检查清单、或SRS编写者手册。对于顾客、供方和其他有关人员，一份好的SRS可能带来一些具体的益处，例如：对于提供什么软件产品，为顾客和供方之间的协议建立基础。在SRS中软件功能的完备措述将协助潜在用户，以便确定指定的软件是否满足其需要，或者为满足其需要应如何修改软件；减少开发工作。SRS文档的编制迫使顾客组织有关各方或人员在设计之前严格考虑所有的需求，并减少以后的新设计、重新编码和重新测试。对SRS中的各项需求进行存细评审，可以在开发周期的早期揭示某些遗漏、误解和不一致，此时这些问题更容易纠正；为估计成本和进度提供基础。SRS中给出的待开发产品的描述是估计项目成本的现实基础，可用于取得投标认可或得出价格估算；一一为验证和确认提供基线。通过一份好的SRS文，组织可提出其更加有效的验证和确认计划。作为开发合同的一部分，SRS提供了可用于测量依从性的基线；一便于软件产品转移。SRS文档使软件产品转移到新的用户或机器更容易。顾客因此发现软件产品更容易转移到组织的其他部门，供方发现软件产品更容易转移到新的顾客；作为进一步增强的基础。因为SRS文档讨论的是产品，而不是开发它的项目，因此，SRS是已开发产品后续增强的基础。尽管SRS文档或许需要修改，但它确实为后续的产品评价提供了基础。
1范围
计算机软件需求规格说明规范
GB/T9385—2008
本标准给出了软件需求规格说明（SRS）的编制要求，描述了一份好的SRS的内容和质量，并在附录A中给出一些SRS提纲示例。
本标准适用于编制SRS。
本标准并不限定任何编制SRS特定的方法、命名约定和工具。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T8566信息技术软件生存周期过程（GB/T8566—2007，ISO/IEC12207：1995，MOD）GB/T11457信息技术软件工程术语3术语和定义
GB/T11457中确立的以及下列术语和定义适用于本标准，3.1
合同contract
由顾客和供方共同签署的具有法律约束力的文件，其中包括产品的技术、组织、成本和进度的需求。合周同样可包括某些非正式的、但有用的信息，如，参与各方的承诺或期望。3.2
顾客customer
为产品支付费用，并通常（但不必要）确定需求的个人或群体。在某些情况下，顾客和供方可以是同一组织的成员。
供方supplier
为顾客开发产品的个人或群体。在某些情况下，顾客和供方可以是同一组织的成员。3.4
用户user
直接运行产品或与产品进行交互作用的个人或群体。用户和顾客通常不是同一个人或群体。4SRS的编制原则
4.1综述
本章给出了编制SRS时宜考虑的事项及编制原则：a）SRS的基本性质；
b）SRS的环境；
好的SRS的特性；
SRS的联合编制；
SRS演变；
GB/T9385-—2008
f）原型法；
SRS中嵌人设计；
h）SRS中嵌人项目需求。
4.2SRS的基本性质
SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。SRS可由来白供方、顾客或双方的一个或者多个人员编写，4.5推荐由来自供方和顾客双方的人员联合编写。SRS编写人员应关注以下基本点：a）功能一一软件将执行什么功能？b)
外部接口一软件如何与人、系统的硬件及其他硬件和其他软件进行交互？性能一各种软件功能的速度、响应时间、恢复时间等是多少？c
d）属性一一软件的可用性、可靠性、可移植性、正确性、可维护性、安全性如何？e）影响产品实现的设计约束—一是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？
编写人员宜避免把设计或项目需求写入SRS中。SRS的内容详见第5章。
4.3SRS的环境
很重要的一点是应考虑SRS在整个项目计划中的作用。项目计划的定义见GB/T11457。软件既可以基本上包括了项目的所有功能，也可以是更大系统的一部分。在后一种情况，典型的SRS将指出系统及其软件部分的接口，并将外部性能和功能需求写入软件部分。显然，SRS应当在系统需求上扩展并与其保持一致。
GB/T8566描述了软件生存周期的各个步骤，以及每步适用的输入。与软件生存周期等有关的其他标准，可对软件需求进行补充。因为SRS在软件开发过程中发挥特定的作用，编写人员宜谨慎对待，不超出其作用的范围。这意味着SRS：
a）宜正确地定义所有软件需求。由于将要处理的任务的性质或项目的具体特性，则软件需求是存在的。
b）不宜描述任何设计或实现的细节。这些内容应当在项目的设计阶段进行描述。c）不宜对软件设置附加的限制条件。这些内容可在其他文件中规定，如，软件质量保证计划。因此，编写适当的SRS限定了正确设计的范围，但不规定任何具体的设计。4.4好的SRS的特征
4.4.1综述
SRS宜是：
a）正确；
b）无歧义；
c）完备；
一致；
e）重要性和/或稳定性分级；
f）可验证；
g）可修改；
h）可追踪。
4.4.2正确
当且仅当SRS中的每一项需求都是软件应满足的需求，SRS才是正确的。不存在确保SRS正确性的工具或规程。宜把SRS与任何适用的上层规格说明（如，系统需求规2
GB/T9385--2008
格说明）、其他项目文件和其他适用的标准进行对比，以确保其相互一致。作为一种选择，顾客或用户可以确定SRS是否正确地反映了实际需要。可追踪性使相应的规程更加便利并减少缺陷（见4.4.8）。4.4.3无歧义
当且仅当SRS中的每一项需求都只有一种解释，SRS才是无歧义的。这要求最终产品的每个特征至少使用唯一的术语来描述。
当在特定背景中使用的某个术语存在多种含义时，宜将该术语包含在术语表中，以便更加具体地说明其含义。
正如在GB/T8566中所描述的那样，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/T9385—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中的每个需求宜予以标识，以使需求在这方面的差异清晰和明确。按下述方式标识需求有助于：
使顾客更仔细地考虑每个需求，这样，常常会澄清顾客可能引人的任何隐藏的假设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
a）具有连贯、方便使用的结构，包含目次、索引及清晰的相互引用；b）没有余（即，相同的需求在SRS不应当出现在多处）c）分别地表述每个需求，而不与其他需求相混淆。GB/T9385-2008
尽管穴余本身不是缺陷，但它容易导致错误。尽管亢余偶尔可以有助于SRS的可读性，但当对存在几余的文件更新时，可能会引起问题。例如，可能对出现多处的某个需求仪在一处做了修改，那么使得SRS内容不一致。当需要亢余时，SRS宜包括一个清晰地交叉索引表，以增加其可修改性。4.4.9可追踪
如果SRS每个需求的来源是清楚的，并在将来编制或增强文档的过程中便于每个需求的索引，那么该SRS是可追踪的。推荐以下两种类型的可追踪性：a）逆问可追踪性（即，到以前的开发阶段）。这依赖于每个需求清晰地指间其在早期文件的来源：b）正向可追踪性（即，到由SRS产生的所有文件）。这依赖于SRS中每个需求具有唯一的名称或索引号。免费标准下载网bzxz
当软件产品进人运行和维护阶段时，SRS的正向可道追踪性尤其重要。随着代码和设计文档的修改，最要紧的是能够确定这些修改可能影响的全部的需求集合。4.5SRS的联合编制
软件开发过程宜从顾客与供方关于完成的软件必须做什么达成的协议开始。依照SRS的形式，该协议宜联合起草。这一点很重要，因为通常不管是顾客还是供方，单方面都不具备编写一份良好SRS的资格。
a）顾客通常对软件设计和开发过程了解的不够，不足以编写实用的SRS；b）供方通常对顾客的问题和从事的领域了解不够，不足以为系统规定满意的需求。因此，顾客和供方宜一起工作，以编写良好的、全面的和可理解的SRS。当系统及其软件二者同时被定义时，存在一种特殊情况，软件的功能、接口、性能、及其他的属性和限制条件不是预先定义的，而是联合定义并且需要协商和变更，这使得满足4.4所述的特征更困难，但更重要。尤其是，不符合其母系统需求规格说明的软件SRS是不正确的。本标准不具体讨论SRS的形式、语言的使用或良好的编写技巧，但是，编写良好的SRS十分重要。一般的技术写作书籍可用作编写指南。4.6SRS的演变
随着软件产品开发的进展，SRS可能需要演变。在项目开始时，规定某些细节是不可能的（例如，对于一个交互程序，在需求阶段定义所有屏幕格式是不可能的）。随着SRS中的缺陷、不足和不准确之处的发现，可能会相继发生对SRS的其他变更。在此过程中，两个重要的考虑事项如下：a）尽管可以预见对SRS的演变修订是不可避免的，但在某个时间对需求的规定应当尽可能完全和细致。宜注明需求不完备的事实；b）宜启动正式的变更过程，以识别、控制、跟踪和报告指定的变更。已批准的需求变更宜按以下方式纳人SRS中：
1）提供准确的和全面的变更审核追踪记录；2）充许对SRS的当前版本和先前版本进行评审。4.7原型法
在项目的需求阶段常常使用原型法。一些工具可简单、快捷地创建体现系统某些特征的原型。注：可参照ASTME1340：1996《计算机系统快速原型法标准指南》。原型的实用性有以下原因：
a）与阅读SRS和提出意见相比，顾客更有可能考察原型并提出建议；b）原型可演示系统行为不可预见的方面，因此，原型不但提供答案，同时还提出一些新的问题，5
GB/T9385—2008
这有助于完善SRS；
c）基于原型提出的SRS在开发过程中倾向更少的变更，从而减少开发时间。原型是用于提取软件需求的一种方式。诸如屏幕或报告格式之类的某些特征可以直接从原型中提取。其他需求可以通过进行原型试验推导出来。4.8SRS中嵌入设计
4.8.1一般来说，在SRS中尽量避免嵌入设计说明，在SRS中嵌人设计说明会过多地约束设计，并且人为地把具有潜在危险的需求引入SRS。一个箫求规定了系统某个外部可见的功能或属性。设计描述了系统某个具体的子部件和/或它与其他子部件的接口。SRS编写人员应当清楚地区分识别所需要的设计约束和构想具体的设计之间的差异。应当注意，SRS的每个需求限制了设计的可选择性。但这并不意味着每个需求就是设计。SRS应当规定对何数据执行何功能以便在何地为何人产生何种结果，SRS宜集中于所提供的服务。SRS通常不规定设计事项，如：a）划分软件为各个模块；
b）分配功能到各个模块；
c）描述模块之间的信息流或控制流；d）选择数据结构。
4.8.2把设计和SRS完全割裂开来也是不现实的。在某些特殊情况下，某些需求可能严重地限制了设计。对安全或保密安全方面的周密考虑可能增加一些直接反映设计约束的需求，例如：a）用几个分开的模块来实现某些功能；b）在程序的某些区域之间仅允许有限的通信；c）对临界的变量检查数据的完整性有效的设计药束条件示例如：物理需求、性能需求、软件开发标准以及软件质量保证标准，因此，宜从完全外部的角度规定需求，当使用模型阐述需求时，应记住模型仅仅用来表明系统的外部行为，并不规定设计。
4.9SRS中嵌入项目需求
SRS宜关注软件产品，而不是软件产品的生产过程。项目需求表示了顾客和供方之间有关软件生产合同事宜的理解，因此不宜包括在SRS中，通常这些项目需求包括如下：
a）成本；
b）交付进度；
c）报告规程；
d）软件开发方法；
e）质量保证；
验证和确认准则；
g）验收规程。
项目需求在其他文档中规定，通常在软件开发计划、软件质量保证计划或者工作说明中规定。5SRS的组成和内容要求
5.1综述
本章讨论组成SRS的每个基本组成部分和内容要求。图1以提纲形式列出这些部分，可作为编写SRS的示例。
尽管SRS不必要按照此提纲或使用这里给出的各章条的名称，但是，一份良好的SRS宜包括以下论述的所有信息。
1引言
1.1目的
1.2范围
1.3定义、简写和缩略语
1.4引用文件
1.5综述
总体描述
2.1产品描述
2.2产品功能
2.3用户特点
2.4约束
假设和依赖关系
2.6需求分配
GB/T9385--2008
3具体需求（对可能的具体需求的说明见5.4.1到5.4.8。也可参见附录A中关于SRS几种不同模式。）
图1SRS提纲
5.2引言（SRS的第1章）
SRS的引言部分应当提供整个SRS的概述，包括以下各条：目的；
范围；
定义、简称和缩略语；
引用文件；
综述。
目的(SRS的1.1)
本条宜：
a）描述SRS的目的；
说明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）
本条宜：
GB/T9385—2008
a）提供SRS引用的所有文件的完整清单；b）标识出每个文件的名称、报告编号（适用时）、日期、出版组织；c）标明可以获得引用文件的来源。这些信息可以通过引用附录或引用其他文档的方式提供。5.2.5综述（SRS的1.5)
本条宜：
a）描述SRS的其余章条包含的内容：b）说明SRS是如何组织的。
5.3总体描述（SRS的第2章）
本章宜描述影响产品及其需求的一般因素，而不叙述具体的需求。相反，它提供需求的背景并使它们更易理解，而在SRS的第3章将详细定义这些需求。本章通常由以下6条组成：
a）产品描述；
b）产品功能；
用户特点；
d）约束；
假设和依赖关系；
需求分配。
5.3.1产品描述（SRS的2.1)
本条宜把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，这里宜如实给予陈述。正如常出现的那样，如果SRS定义的产品是较大系统的组成部分，则本章宜将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接口。使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的。本条也宜描述在各种不同的约束下软件如何运行。如，这些约束可包括：a）系统接口；
用户界面；
硬件接口；
d）软件接口；
通信接口；
内存；
g）运行；
h）现场适应性需求等。
5.3.1.1系统接口
本条宜列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。5.3.1.2用户界面
本条宜规定以下方面：
a）在软件产品与用户之间每个界面的逻辑特征。这包括完成软件需求所需要的那些配置特征（例如，要求的屏幕显示格式、页面或窗口版式布局、任何报告或单的内容、或者可编程功能键的设置）；
b）优化系统用户界面的所有方面。这可以简单地包括一个针对系统对用户的显示方式系统将做什么和不做什么的清单。例如，可能是一项选择长或短的错误消息方面的需求。如同所有其他需求一样，这些需求宜是可验证的，例如，“经过1h培训后，4级打字员能够在Zmin内执行功能X”，而不是“打字员能够执行功能X”（这也可以在标题为使用方便性章条的软件系8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。