📄 115.htm
字号:
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<P><STRONG>
中华人民共和国国家标准
<BR>
GB 9385-88
<BR>
计算机软件需求说明编制指南
<BR>
Guide to computer software requirements Specifications<BR></P>
<HR>
<BR></STRONG><STRONG><A name=1><STRONG>1引言
</STRONG></A></STRONG><BR><BR><STRONG>1．1目的和作用<A
name=1.1></A><BR></STRONG> 本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明 Software Requirements
Specifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。<BR>
本指南适用对象：<BR> 软件客户（Customers），以便精确地描述他们想获得什么样的产品。<BR> 软件开发者（ SuPPliers），以便准确地理解客户需要什么样的产品。<BR> 对于任一要实现下列目标的单位和（或）个人： <BR>
a．要提出开发规范化的S RS提纲；<BR> b．定义自己需要的具体的格式和内容； <BR> c．产生附加的局部使用条款，如 S RS质量检查清单或者 S RS作者手册等。 <BR> S RS将完成下列目标： <BR>
a．在软件产品完成目标方面为客户和开发者之间建‘立共同协议创立一个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否S符合他们的要求，或者怎样修改这种软件才能适合他们的要求；
<BR>
b．提高开发效率。编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；<BR> c．为成本计价和编制计划进度提供基础。
SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；<BR> d．为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验证计划。作为开发合同的一部分， S
RS还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为S
RS。因为这种文件几乎不包括详尽的需求说明，并且、通常是不完全的）；<BR>
e．便于移植。有了SRS就便于移植软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部问，而开发者同样也易于把软件移植到新的客户，
<BR> f．作为不断提高的基础。由于SRS所讨论的是软件产品，而不是开发这个产品的设计。因此 S
RS是软件产品继续提高的基础。虽然S RS也可能要改变，但是原来的S RS还是软件产品改进的可靠基础。<BR><STRONG>1．2范围 <A
name=1.2></A></STRONG><BR> 本指南适用于编写软件需求规格说明，它描述了一个S
RS所必须的内容和质量，并且在第 6章中提供了SRS大纲。 <BR><STRONG>2 引用标准 <A
name=2></A><BR></STRONG> G B 8566计算机软件开发规范<BR> G B 8
567计算机软件产品开发文件编制指南<BR> G B／ TI 1457软件工程术语 <BR><STRONG>3 定义<A
name=3></A><BR></STRONG> G B／ TI 1457所列术语和下列定义适用于本指南。 <BR> 合同（ c o n t ra ct） <BR> 是由客户和开发者共同签署的具有法律约柬力的文件。其中包括产品的技术、组织、成本和进度 计划要求等内容。
<BR> 客户（ c us t o mer）<BR>
指个人或单位，他们为产品开发提供资金，通常（但有时也不必）还提出各种需求。文件中的客 户和开发者也可能是同一个组织的成员。<BR> 语言（ language）<BR>
是具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。<BR>
分割（Partitioning） <BR> 把一个整体分成若干部分。<BR> 开发者（ su PPIier）<BR>
指为客户生产某种软件产品的个人或集团。在本指南中，客户和开发者可能是同一个组织的成 员。<BR> 用户（
user) <BR> 指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。<BR><STRONG>4 编写 SR S的背景信息 <A
name=4></A><BR></STRONG><STRONG>4．I SRS的基本要求 <A
name=4.1></A></STRONG><BR> S RS是对要完成一定功能、性能的软件产品、程序或一组程序的说明。<BR> 对SRS的描述有两项基本要求：<BR> a．必须描述一定的功能、性能； <BR>
b．必须用确定的方法叙述这些功能、性能。<BR><STRONG>4． 2 S
RS的环境 <A
name=4.2></A></STRONG><BR> 必须认识到 S R S在整个软件开发规范（见 G B 85 66）所规定的有关阶段都起作用。正因为如此， S
RS的起草者必须特别注意不要超出这种作用的范围。这意味着要满足下列要求：<BR>
a．SRS必须正确地定义所有的软件需求；<BR> b．除了设计上有特殊限制之外， S
RS中一般不描述任何设计、验证或项目管理细节。<BR><STRONG>4．3
SRS的特点<A
name=4.3></A></STRONG><BR><STRONG>4．3．1无歧义性<A name=4.3.1><STRONG></STRONG></A>
</STRONG><BR> 当且仅当它对每一个需求只有一种解释时， S RS才是无歧义的。<BR>
a．要求最终产品的每一个特性用某一术语描述；<BR>
b．若某一术语在某一特殊的行文中使用时具有多种含义，那么对该术语的每种含义作出解释并 指出其适用场合。
需求通常是用自然语言编写的，使用自然语言的SRS起草者必须特别注意消除其需求的歧义性。 提倡使用形式化需求说明语言。<BR><STRONG>4．3．2完整性<A name=4.3.2></A><BR></STRONG> 如果一个S RS能满足下列要求，则该S
RS就是完整的：<BR>
a．包括全部有意义的需求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的需求；<BR> b．对所有可能出现的输人数据的响应予以定义，要对合法和非合法的输人值的响应做出规定；<BR> c．要符合SRS要求。如果个别章节不适用，则在SRS中要保留章节号， <BR>
d．填写S RS中的全部插图、表、图示标记和参照，并且定义全部术语和度量单位。<BR>4．3．2．1关于使用“待定”一词的规定 任何一个使用“待定”的S RS都是不完全的。<BR> a．若万一遇到使用“待定”一词时，作如下处理：<BR> （1）对产生“待定”一词的条件进行描述，使得问题能被解决；<BR> （2）描述必须干什么事，以删除这个“待定”；<BR>
b．包含有“待定”一词的任何 S R S的项目文件应该：<BR>
（1）标识与此特定文件有关的版本号或叙述其专问的发布号； <BR>
（2）拒绝任何仍标识为“待定”一词的S RS章节的许诺。<BR><STRONG>4．3．3可验证性<A
name=4.3.3><STRONG></STRONG></A> <BR></STRONG> 当且仅当
SR S中描述的每一个需求都是可以验证的，该 S R
S才是可以验证的；当且仅当在某一性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。<STRONG><BR></STRONG><STRONG>4．3．4一致性<A
name=4.3.4></A><BR></STRONG> 当且仅当 S RS中各个需求的描述是不矛盾时S RS才是一致的。<BR><STRONG>4．3.5可修改性 <A name=4.3.5></A><BR></STRONG>
如果一个SRS的结构和风格在需求有必要改变时是易于实现的、完整的、一致的，那么这个SRS 就是可以修改的。可修改性要求S RS具备以下条件：
<BR> a．具有一个有条不紊的易于使用的内容组织，具有目录表，索引和明确的交叉5！用表； <BR> b．没有冗余。即同一需求不能在S RS中出现多次。 <BR>
（1）冗余本身不是错误，但是容易发生错误。冗余可增加SRS的可读性，但是在一个冗余文件被更新时容易出现问题。例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改
变，若只修改了一个地方，于是S RS就变得不一致了。 <BR> （ 2）不管冗余是否必须， S
RS一定要包含一个详细的交叉引用表，以便S RS具备可修改性。<BR><STRONG>4．3．6可追踪性 <A name=4.3.6></A><BR></STRONG> 如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，
则该SRS就是可追踪的。建议采用如下两种类型的追踪：
<BR>
a．向后追踪（即向已开发过的前一阶段追(踪）。根据先前文件或本文件前面的每一个需求进行 追踪。
<BR> b．向前追踪（即是向由 S RS派生的所有文件追踪）。根据S RS中具有唯一的名字和参照号的 每一个需求进行追踪。 当 SR
S中的一个需求表达另一个需求的一种指派或者是派生时，向前．．向后的追踪都要提供。例 如: <BR>
（1）从总的用户响应时间需求中分配给数据库操作响应时间；<BR>
（2）识别带有一定功能和用户接口的需求的报告格式； <BR>
（3）支持法津或行政上需要的某个软件产品（例如，计算税收）。在这种情况下，要指出软件 所支恃的确切的法律或行政文件。 <BR> 当软件产品进人运行和维护阶段时， S RS的向前可追踪性显得特别重要。当编码和设计文件作修
改时，重要的是要查清这些修改所影响的全部需求。<BR><STRONG>4．3．7运行和维护阶段的可使用性 <A
name=4.3.7></A><BR></STRONG> S RS必须满足运行和维护阶段的需要，包括软件最终替换。
<BR> a．维护常常是主与原来开发无联系的人来进行的。局部的改变（修正）可以借助于好的代码注
释来实现。对于较大范围的改变。设计和需求文件是必不可少的，这里隐含了两个作用： <BR> （
1）如4．3．5条指出， SRS必须是可修改的；<BR> （ 2） S
RS中必须包括一个回录，它记录那些应用于各个成分的所有具体条文。例如： 它们的危急性（如故障可能危及完全或导致大量财政方面和社会方面的损失）；
它们仅与暂时的需要相关（如支持一种可立即恢复原状的显示）； 它们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。<BR> b．要求在 SR S中清楚地写u功能的来源和目的，因为对功能的来源和引入该功能的目的不清
楚的话，通常不可能很好地完成软件的维护。<BR><STRONG>4． 4
SRS的编制者
<A name=4.4></A></STRONG><BR> 软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用 SR
S的形式，应该由双方联合起草。这是因为：<BR>
a.客户通常对软件设计和开发过程了解较少，而不能写出可用的 SR S；<BR>
b．开发者通常对于客户的问题和意图了解较少，从而不可能写出一个令人满意的系统需求。<BR><STRONG>4．5 SRS的改进<A
name=4.5></A><BR></STRONG> 软件产品的开发过程中，在项目的开始阶段不可能详细说明某些细节，在开发过程中可能发现SR
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -