GB/T 9385-1988 计算机软件需求说明编制指南 GB/T9385-1988 标准下载解压密码：www.bzxz.net

1引言
中华人民共和国国家标准
计算机软件需求说明编制指南
Gulde to computer softw are requirements speclficationsGB 9385-88
1.1目的和作用
本指南为软件需求实践提供了个规范化的方法。本指南不提倡把软件需求说明（SoftwareRequirementsSpecifications，以下简称SRS）划分成等级，避免把它定义成更小的需求了集。本指南适用对象：
软件客户（Customers）：，以便精确地描述他们想获得什么样的产品。软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。对于任一要实现下列日标的单位和（或）个人：要提出开发规范化的SRS提纲：
定义白己需要的具体的格式和内容；b.
产生附加的局部使用条款，如SRS质量检查消单或者SRS作者手册等。SRS将完成下列目标：
a，在软件产品完成目标方面为客户和开发者之间建立共同协议创立--个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求，
b.提高开发效率。编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏，错误的理解和不一致性，以便及时加以纠正，c。为成本计价和编制计划进度提供基础。SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据！d。为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验证计划。作为开发舍同的一部分，SRS还可以提供一个可以度量和遵循的基准（然而，反之则不成文，即任一有关软件的合同都不能作为SRS。因为这种文件几乎不包括详尽的需求说明，并且通常是不完全的）1e，便下移植。有了SRS就便于移植软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部门，而开发者同样也易于把软件移到新的客户，f．作为不断提高的基础。由于SRS所讨论的是软件产品，而不是斤发这个产品的设计。因此SRS是软件产品继续提离的基研。虽然SRS也可能要改变，但是原来的SRS还是软件产品改进的可靠基础。
1.2范围
本指南适用于编写软件需求规格说明，它播述了一个SRS所必须的内容和质盘，并且在第6章中提供了SRS大纲。
中华人民共和国电子工业部19路－04-26批准1988- 12 - 01实施
2引用标准
GB 名566计算机软件开发规范
GB9885-88
GB8567计算机软件产品开发文件编制指南GB/T11457软件工程术语
3定义
GB/T11457所列术语和下列定义适用丁本指南。合同(contract)
是由客户和开发者共同签署的具有法律约束力的文件。其中包括产品的技术，组织，成本和进度计划要求等内容。
客(customer)
指个人或单位，他们为产品开发提供资金，通带（但有时也不必）还提出各种需求。文件中的客户和开发者也可能是同-个组织的成员。语言（language）
是具有语法和语义的通信工具，包括一组表达式，惯例和传递信息的有关规则。分割(parlitioning)
把一个整体分成若干部分。
开发者(supplier)
指为客户生产某种软件产品的个人或集团。在本指南中，客户和开发者可能是同一个组织的成员。
用户（user)
指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。编写SRS的背景信息
4.1SRS的基本要求
SRS是对要完成-定功能、性能的软件产品、程序或一组程序的说明。对S RS的描述有两项基,本要求
皇：必须描述一定的功能、性能；b。必须用确定的方法叙述这些功能、性能。4.2SRS的环境
必须认识到R$在整个软件开发规范（见GB8566）所规定的有关阶段都起作用。正因为如此，SRS的起草者必须特别注意不要超出这种作用的范图。这意味着要满足下列要求：奥。SRS必须正确地定义所有的软件需求，b．除广设计上有特殊限制之外，SRS中一般不描述任何设计，验证或项H管理细节。4.a SRS的特点
4.3.1无歧义性
当且仅当它对每一个需求只有一种解释时，SRS才是无歧义的。&。要求最终产品的每·个特性用某·术语描述，b若某一术语在某一特殊的行文中使用时具有多种含义，挪么对该术语的每种含义作出解释并指出其适用场合。
带求通常是用然语吉编写的，使用然语言的SR$起草者必须特别注意消除其需求的歧义性。提但使用形式化需求说明语言。4.3.2完整性
CB8385-88
如果一个SRS能满足下列要求，则该SRS就是完整的8。包括全部有意义的需求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的需求，
b。对所有可能出现的输人数据的响应予以定义，要对合法和非合法的输人值的响应做出规定c.要符合SRS要求。如果个别章节不适用，则在SRS中要保留章节号：d，填写SRS中的全部插图，表、图示标记和参照，并且定义全部术语和度量单位。4.3.2.1关于使用“待定”一词的规定狂何一个使用“待定”的SRS都是不完全的。。若厅一遇到使用“待定”一词时，作如下处理，《1）对产生“待定”…词的条件进行描迷述，使得问题能被解决（2）描述必须于什么事，以删除这个“待定”，b：包含有“待定\一词的任何SRS的项目文件应该（1）标识与此特定文件有关的版本号或叙述其专门的发布号；（2）拒绝任何仍标识为“待定”-词的SRS章节的许诺。4.8.3可验证性
当且仅当SRS中描述的每一个需求都是可以验证的，该SRS才是可以验证的，当且仅当在某…性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。
4.8.4—致性
当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的。1.3.5可修改性
如果个SRS的结构和风格在需求有必要收变时是易于实现的、完整的、一致的，那么这个SRS就是可以修的。可修改性要求SRS具备以下条件：具，具有一个有条不素的易十使用的内容组织，具有目录表，索引和明确的交叉引用表b，没有亢余。即同一需求不能在SRS中出现多次。（1）究余本身不是错误，但是容易发生错误。允余可增加SRS的可读性，但是在一个余义件被更新时容易出现问题。例如：假设·个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改个地方，于是SR$就变得不一致了。（2）不管允余是否必须，SRS--定要包含一个详细的交叉引用表，以便SRS具备可修改性。4.a.6可追踪性
如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该SRS就是可追踪的。建议采用如下两种类型的追踪：向后追踪（朗向已开发过的前一阶段追）。根据先前文件或本文件前面的每一个需求进行追踪。
D.向前追踪（即慰尚询SRS派生的所有文件追踪）。根据SRS中具有唯的名字和签照号的每一个需求行追踪，
当SRS中的-…个需求丧达另-一个需求的-一种指派或署是派生时，向前、向后的追踪都要提供。例如，
（1）以总的用户响应时间需求中分配给数据库操作响应时间：（2）识别带有定功能和用户接口的需求的报告格式；（3）支持法律或行政上的某个软件产品（例如，计算税收），在这种情况下，要指出软件所支待的确切的法律或行政文件。GB 9385-88
当软件产品进人运行和维护阶时，SRS的问前可追踪性显得特别重要。当编码和设计文件作修改时，重要的是要查清这些修改所影响的全部需求。4.3.7运行和维护阶段的可使闲性SRS必须满足运行1维护阶段的需要，包括软件最终替换。。维护常常是由与原来开发无联系的人来进行的。局部的改变《修正）可以借助于好的代码注释来实现。对于较大范围的改变。设计和诺求文件是必不可少的，这里隐含了两个作用：（1）如4.3.5条指出，SRS必须是可修改的：（2）SRS打必须包括-个记录，它记录挪些应用厂各个成分的渐有具体条文。例如：它们的危急性（如故障可能危及完全或导致大母财政方面和社会方而的损失）：它们仪与暂时的需要相关（如支持一种可立即恢复原状的显示）：它们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。b，要求在SRS中清楚地亏明功能的来源和目的，因为对功能的来源和引人该功能的目的不清楚的话，通常不可能很好地完成软件的维护。4.4 SRS 的编制者
软件开发的过程是出开发者和客广双方同意开发什么样的软件协议开始的。这种协议要使用SRS 的形式，应该由双方联合起草。这是因：，客户通常对软件设计和开发过程了解较少，而不能写出可用的SRS，b。开发者通常对于客户的问题和意图了解较少，从而不可能写出·-个令人满意的系统需求。4.5 SRS 的改进
软件产品的开发过程中，在项日的始阶段不可能详细说明某些细节，在开发过程中可能发现SRS的缺陷、缺点和错误之类的问题，所以可能要对SRS进行改进。在SRS 的改进中，应注意如下事项：4.5.1尽管可以预见校正版本在开发以后不可避免，而对需求还必须尽可能完全、清楚地描述。4.5.2-且最初识别出项月的变化，应引人、个正式的改变规程来标识、控制、追踪和报告项目的改变。批准了的需求改变，用如下的方法编人SRS之中：a。提供各种改变后的正确的、完全的审查记求；b。允许对SRS当前的和被替代部分的审查。4.6SRS的编制工具
编制SRS最显而易见的方法是用自然语米描述。尽管自然语言是丰富多彩的，但不易精确，用形式化的方法较好。
4.6.1形式化说明方法
在SRS 中是否使用形式化方法要依据下列因素:程序规模和复杂性，
b客户合同中是否要求使用
c.SRS是否是一个合同工具或仪仪是个内部文件d.SRS 文件是否成为设计文件的根据；e.具有支持这种方法的计算机设备。4.6.2生产工具
软件产品生产中有多种生产工具。比如，计算机的字处理器就是非常有用的生产辅助1具。一个SRS 通常有若干作者。可能经历十版本，并且要进行多次重新组织内容。故生-工具是必要的。4.6.3表达工具
在SRS中有许多词汇：，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所认表达SRS 需要若T县、比如：
GB 9385—88
可以验证实体成活动，无论在SRS中什么地方都是同一名字，b.可以标识一个特殊的实体或动作在规格说明中的描述位暨。此外，可以使用若干种形式化方法，以便允许自动处理SRS内容，只要作某些限制就可以做到。用一些表格或图示法来显示需求。用详细分层体系自动检查SRS的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层，或是上，层的一个组成成分。自动检查SRS 具有在4.3 条描述的部分或全部特点。5软件需求
SRS中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。5.1表达软件需求的方法
软件需求可以用若干种方法来表达：。通过输人、输出说明，
b使用代表性的例于；
e.用规范化的模型。
5.1.1输入、输出说明
用输人输出序列来描述一个软件产品所要求的特性是很有效的。5.1.1.1途径
根据被描述的软件的性质，至少有三种不同的逐径：组。有些软件产品（如报表系统）要求着重说明输出。一般情况下，致力于输出的系统主要是在数据文券上操作。用户的输入通常尼致力于提供控制信息和店动数据文卷的处理b，有些软件产品需要着重说明输人，输出特性。关注输人，输出的系统主要是在当前的输人上操作，要求生成与输入相匹配的输出（类似于数据转换例行程序或-个数学函数包），c。 还有一些系统（如过程控制系统）要求记忆它们的状态。可以根据本次输人和上一次输人进行应答。也就是说，它的行为如同一个有限状态机。在此种情况下，既要关注输入／输出对，又要关注这些输入/输出对的次序。
5.1.1.2困难
多数软件产品可能接收无限的序列作为输入，丁是，为了通过输人输出序列完整地说明产品的特性，就要求SRS包括一个无限长的输入和所需的输出序列。然而，用这样的途径不可能完整地描述软件所要求的一切特性。
5.1.2典型例子
一种选择是用典型例子来说明要求的特性。例如，假设个系统中当接收“”时用“1”来回答。显然，要列出全部输入和输出序列是不可能的。然而，用典型的序列可以十分清楚地理解系统的特性。下面是·一组四种对话的典型的例子，用它描述系统特性。0101
010101010101
010101
这些对话仅提供了要求的输入和输出之间的关系，但是不能完全描述系统的特性。5.1.a模型
另·-种表达需求的方法是模型的方式，这是表达复杂需求的精确和有效的方法。至少可以提出三种可供使用的通用模型，数学型、功能型、计时型。应注意区别各种模型的应用场合，参考5.1.3.5。5.1.3.1数学模型
GB9385-86
数学模型是使用数学关系描述软件特性的模型。数学模型对某些特殊应用领域是特别有用的。例如，导航、线性规划、计量经济、信号处理和气象分析等。用数学模型能够对5.1.2中所讨论的典型例子描述如下：(01 ) *c
这里，“，”号表示括号内的字符串可以重复-次或多次。5.1.8.2功能模型
功能模型是提供从输人到输出映象的模型。象有限状态机或Pe1i网，这些功能模型可以有助于标识和定义软件的各种特点，或者可以表示系统所要进行的操作。对前面用数学模型描述的例子。可图1所示的有限状态机形式的功能模型来描述。图中进人的箭头表示启动状态。双线的方框表示接收状态。在各线记号×/的含义是：x代表接受的输人，而是产生的输出。
5.1.8.8计时模型
计时模型是种增加了时间限制的模型。这种模型对于表达软件特性的形式和细节特别有用。尤其是实时系统或考虑人为因素的系统。让时模型可以把下列限制加到图1的模型中去：a。激活因素0将在进入1状态30%之内出现；b. 响应 1 将在进人S 2 状态 29 之内出现。5.1.3.4其他模型
除了上面提及的模型外。对一些特殊的应用还有一些特别有用的模型。例如，编译程序的说明可以使用属性文法，工资单系统可以使用表格。要注意的是，对SRS使用形式需求语言，通常含有用特殊模型的意思。
5.1. 3, 5警告
无论使用哪一类型的模型，都要：GB SSBS—$B
在SRS 中或在 SRS 谢及到的一个文件中对它严格定义。这个定义应该规定：模型中的参数所要求的范围，
使用时的限定值，
结果的精确度中
负载的能力！
要求的执行时间：
f，缺省或失败时的响应。
必须注意，在需求的定义域内要保持个模型定义。每当一个SRS使用一个模型时：它意味着此模型提供一个十分有效和精确的方法说明需求；并不意味软件产品的实现必须基于这个模型。b.
一个模型用于解释文件所写的需求是有效的，但是对于实际软件的实现可能并不是最适宜的。5.2软件需求的注释
有关软件产品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是对于生命做关的应用。而另·-些可能并不那么重要。SRS 中每一个需求必须进行注释，以便区别其重要的程度。用这种方法注释需求，可以：
a，帮助客户对每一个需求给予史周密的考虑，通常可以在需求中澄清隐藏的假设，b．帮助开发者做出正确的设计决定，并对软件产品不同部分作出相应的势力。5.2.1稳定性
注释需求的一种方法是使用稳定性量纲。当-一个需求在软件预期的生存期间内描述不改变的话,可以认为该需求是稳定的，否则可以认为是易变的。5.2.2必要性等级
注释的另一·种方祛是把需求分成必须保证级、期塑级和任选级。必须保证是指软件必须和这些需求相·-致，否则该软件不可能被接受中8.
b．期望是指这些需求将提高软件产品的功能，但是如果缺省的话也是可接受的，c. 仟选是给斤发者-个机会，可以提供某些超出 SR S 规定的目标。5.2.3注意事项
在注释需求之前，必须彻底理解这种注释的实质性含义。5.3在表达需求时遇到的共同弊病SRS 的基本点尼它必须说明由软件获得的结果，而不是获得这些结果的手段。编写需求的人必须描述的基本题是：。．功能——所设计的软件要做付么，b．性能一是指软件功能在执行过程中的速度、可使用性，响应时间、各种软件功能的恢复时间、吞叶能力、精度、频率等等，c．强加于支现的设计限制一一在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标谁！
d．属性一-可移植性、正确性、可维护性及安全性等方面的考虑因素；e：外部接口一与人、硬件、其他软件和其他硬件的相互关系。编写需求的人应当避免把设计或项目需求写人SRS之中，应当对说明需求设计约束与规划设计两者有清晰的区别。
5.3.1在SRS 中嵌人了设计
在SRSI1嵌人设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需求放人SRSGE 9885-88
5.8.1.1SRS必须描述在什么数据上、为谁完成什么功能、在什么地方、产生什么结果。SRS应把注意力集中在要完成的服务月标上。通常不指定如下的设计项目：把软件划分成若干模块
b。给每一个模块分配功能l
c，描述模块间的信息流程或者控制流程选择数据结构。
5.3.1.2把设计完全同SRS隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求。例如：。
在一些分散的模块中保持某些功能；允许在程序的某些区域之间进行有限的通讯，b.
c． 计算临界值的检查和。
5.3,1.通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可能占整个产品开发成本的10%一20%以上）。有两种选择：围。不顾本指南的警告，在 SRS 中描述了设计。这意味善，戴者将一个潜在不适当的设计作为个需求进行描述（因为，若要得到好的设计，所花费的时间是不够的），或者在需求阶段花费了过多的时间（因为在SRS完成之前整个设计分析都要完成）b.采用本指南中5.1.3条中的建议，用模型设计描述带求，这种模型设计只用于辅助描述需求，而不使之成为实际的设计。
5.3.2在SRS 中嵌人了—些项目要求SRS 应当是描写一个软件产品，而不描述生产软件产品的过程。项目要求表达客户和开发者之间对于软件生产方面合尚性事宜的理解（因此不应当包括在SRS中）例如：
成本，
交货进度，
报表处理：
软件开发方法，
质量保证：
确认和验证的标准！
验收过程。
项目需求在另外的文件中描述。在SRS 中提供的只是关于软件产品本身的需求。 SRS大纲
本章若重讨论SRS的每一个基本部分，可以作为一个SRS的大纲。表1给出该大纲自录，表2至表5给出大纲中第3章的具体需求内容。各开发者和客户应当根据所描的实际情况，按本指南有关规定编写自己的SRS。
1.1目的
1.2范用
1,3定义、缩写词、略语
1.4参考资料
2项目慢述
2.1产品描述
2.2产品功能
2.3用户特点
2.4一般约束
2.5假设和依据
。具体霉求
GB 98858B
表 1 SRS大纲
(参阅本指南6.3.2 条中具体需求的组织形式)附录
6.1前言（SRS 第1章）
本竞提供整个 S R S 综述,
6,1.1 目的 (SRS 的1.1条)
在这一条包括下列内容！
描述实际SRS 的目的
说明SRS所预期的读者。
6.1.2范围（SRS 的1.2条）
用一个名字标识被生产的软件产品。比如：×××数据库系统，报表生成程序等等，a
说明软件产品将干什么，如果需要的话，还要说明软件产品不干什么，b.
描述所说明的软件的应用。应当：（1》尽可能精确地描述所有相关的利益、目的、以及最终目标。（2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。
6.1.3定义、缩码词、略语（SRS的1.3条）本条中必须提供全部需求的术语、缩写词及略语的定义，以便对SRS进行适当的解释。这些信息可以由SRS的附录提供。也可以参考其他的文件。6.1.4 参考资料（SRS 的1.4条）本条应包括：
在SRS中各处参照的文件的全部清单，如经核准的计划任务书，上级机关批文、合同等，鼠
列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。每一一个文件。文献要有b.
标题，索引号或文件号，发布或发表日期以及出版单位，详细说明可以得到该参考文件的来源。这个信息可以通过引用附录或其他文件提供。c
6.2项目概述（SRS第2章）
GB 9386--88
本章描述影响产品和其需求的一般因素，本章不说明具体的需求，而仅使需求更易于理解。6.2.1产品描述（SRS的2.1条）
这一条是把一个产品用其他有关的产品或项目来描述。。如果这个产品是独立的，而且全部内容自含，应在此说明；b。如果SRS定义的产品是一个较大的系统或项目中的一个组成部分，那么本条应包括如下内容：
（1）要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口：（2）指出该软件产品主要的外部接口。在这里，不婴求对接口详细地描述，详细描述放在SRS其他章条中#
（3）描述所使用的计算机硬件、外设备。这里仅仅是一个综述性描述。在本条的描述巾，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有韬助的。
本条既不用来强追进行设计方案的描述，也不是描述在解决问题时的设计约束。本条应对在以后具体需求一童中说明的设计约束提供理由。6.2.2产品功能（SRS的2.2条）
本条是为将要完成的软件功能提供一个摘要。例如，对于个记帐程序来说，SRS可以用这部分来描述；客户帐目维护、客户财务报表和发票制作，而不必把功能所要求的大盘的细节描写出来。有时，如果存在较高层次的规格说明时，则功能摘要可直接从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意8：编制功能的-一种方法是制作功能表，以便客户或者第一次读这个文件的人都可以理解，b。用方框图来表达不同的功能和它们的关系也是有帮助的。但要牢记，这样的图不是产品设计时所需求的，面只是一种有效的解释性的工具。这条不用作陈述具体需求，只是对后来SRS中具体需求一章中为什么要描述的某些需求提供理由。
6.2.3用户特点（SRS的2.3条）
本条要描述影响具体需求的产品的最终用户的一般特点。许多人在软件牛存周期的操作和维护阶段与系统相关。而这些人中有用户，操作员，维护人员和系统工作人员。这些人的某些特点，象教育水平、经验、技术、专长等，都是施加于系统操作环境的重要约束。
如果系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。这一条的内容不能用水陈述具体需求或强加若干特殊的设计约束，本条应对在SRS的具体需求一章之中的某些具体需求或设计约束的描述提供理由。6.2.4般约束（SRS的2.4条）
，本条对设计系统时限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括，
管理方针，
b。硬件的限制，
e.与其他应用间的按口，
d．并行操作，
审查功能：
控制功能；
所的高级语育，
h．通信协议；
i、应用的临界点；
」安全和保密方面的考虑。
GB 93B5—88
本条不陈述具体需求或具体设计约束：而对SR$的具体需求一章中为什么要确定某些具体需求和设计约束提供理中。
6.2.5假设和依据（SRS的2.5条）本条列出影响S究S中陈述的需求的每一个因素。这些因素不是软件的设计约束，但是它们的改变可能影响到SRSt的需求。例如，假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，SRS就要进行相应的改变。6.8具体需求(SRS的第3章）
本章应包括软件并发者在建立设计时需要的全部细节。这是SRS中篇幅最大和最重要的部分。：根据本指南第4 章所规定的准则（如可验证性、无歧义性等），对每一个需求细节作具体描述，
b。在SRS的前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景，
c．具体需求分类的方法如下：
（1）功能需求，
（2）性能需求，
（3）设计约束，此内容来自标准下载网
（4）属性；
（5）外部接口需求。
本章中要注意的二点是：
8.按符合逻辑的和可读的方式组织，b．详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。B.3.1具体需求的内容
6.8.1.1功能需求
本条描述软件产品的输入怎样变换成输出。即软件必须完成的基本动作。对丁每一类功能或者有时对于每一个功能，需要具体描述其输人、加工和输出的需求。这通常由四个部分组成：
这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。b.输人
这部分应包括：
（1）详细描述该功能的所有输入数据，如：输人源、数萤、度单位、时间设定、有效输人范圈（包括精度和公差），（2）操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整；（3）指明引用接口说明或接口控制文件的参考资料。，上
定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明（1）输入数据的有效性检查，
（2）操作的顺序，包括事件的时间设定：（3）异常情况的啊应，例如，溢出、通信故障、错误处理等（4）受操作影响的参数：
（5）降级运行的要求;
GB9385—88
（6）用于把系统输人变换成相应输出的任何方祛（方程式、数学算法、逻辑操作等）。（7）输出数据的有效性检查。
d．输出。
这部分应包括：
（1）详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息：（2）有关接口说明或接口控制文件的参考资料。此外，对着重于输人输出行为的系统来说，SRS 应指定所有有意义的输人、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次輪入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。6.8.1.2性能需求
从整体来说，本条应具体说明软件、或人与软件交互的静态或动态数值需求。。静态数值需求可能包括，
（1）支持的终端数；
（2）支持并行操作的用户数：
（3）处理的文卷和记录数；
（4）表和文卷的大小。
b．动态数值需求可能包括：欲处理的事务和任务的数量，以及在正常情况下和峰值上作条件下一定时间周期中处理的数据总量。所有这些需求都必须用可以度量的术语来叙述。例如，95%的事务必须在小于 1s 时间内处理完，不然，操作员将不等待处理的完成。6.3.1.3设计约束
设计约束受其他标准、硬件限制等方面的影响。6.3.1.3.1其他标准的约束
本项将指定由现有的标准或规则派生的要求。例如：罚．报表格式；
b.数据命名：
财务处理；
d．审计追踪，等等。
6.3.1.8.2硬件的限制
本项包括在各种硬件约束下运行的软件要求，例如，应该包括：硬件配置的特点（接口数，指令系统等）B
b。内存储器和辅助存储器的容量。6.8.1.4腻性
在软件的需求之中有若十个属性，下面指出其中的几个（注意：对这些决不应理解为是一个完整的清单）。
6.8.1.4.1可用性
可以指定一些因素，如检查点、恢复和再房动等，以保证整个系统有-个确定的可用性级别。6.8.1.4.2安全性
这里指的是保护软件的要素，以防止各种非法的访问、使用，修改、破坏或者泄密。这个领域的具体需求必须包括：
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。