计算机软件需求说明编制指南

计算机软件需求说明编制指南1引言1.1目的和作用本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明（SoftwareRequirementsSpecifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。本指南适用对象：软件客户（Customers），以便精确地描述他们想获得什么样的产品。软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。对于任一要实现下列目标的单位和（或）个人：a.要提出开发规范化的SRS提纲；b.定义自己需要的具体的格式和内容；c.产生附加的局部使用条款，如SRS质量检查清单或者SRS作者手册等。SRS将完成下列目标：a.在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求；b.提高开发效率。编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；c.为成本计价和编制计划进度提供基础。SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；d.为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验证计划。作为开发合同的一部分，SRS还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为SRS。因为这种文件几乎不包括详尽的需求说明，并且通常不完全的）；e.便于移植。有了SRS就便于移值软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部门，而开发者同样也易于把软件移植到新的客户；f.作为不断提高的基础。由于SRS所讨论的是软件产品，而不是开发这个产品的设计。因此SRS是软件产品继续提高的基础。虽然SRS也可能要改变，但是原来的SRS还是软件产品改进的可靠基础。1.2范围本指南适用于编写软件需求规格说明，它描述了一个SRS所必须的内容和质量，并且在第6章中提供了SRS大纲。2引用标准GB8566计算机软件开发规范GB8567计算机软件产品开发文件编制指南GB/T11457软件工程术语3定义GB/T11457所列术语和下列定义适用于本指南。合同（contract）是由客户和开发者共同签署的具有法律约束力的文件。其中包括产品的技术、组织、成本和进度计划要求等内容。客户（customer）指个人或单位，他们为产品开发提供资金，通常（但有时也不必）还提出各种需求。文件中的客户和开发者也可能是同一个组织的成员。语言（language）是具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。分割（partitioning）把一个整体分成若干部分。开发者（supplier）指为客户生产某种软件产品的个人或集团。在本指南中，客户和开发者可能是同一个组织的成员。用户（user）指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。4编写SRS的背景信息4.1SRS的基本要求SRS是对要完成一定功能、性能的软件产品、程序或一组程序的说明。对SRS的描述有两项基本要求：a.必须描述一定的功能、性能；b.必须用确定的方法叙述这些功能、性能。4.2SRS的环境必须认识到SRS在整个软件开发规范（见GB8566）所规定的有关阶段都起作用。正因为如此，SRS的起草者必须特别注意不要超出这种作用的范围。这意味着要满足下列要求：a.SRS必须正确地定义所有的软件需求；b.除了设计上的特殊限制之外，SRS中一般不描述任何设计、验证或项目管理细节。4.3SRS的特点4.3.1无歧义性当且仅当它对每一个需求只有一种解释时，SRS者是无歧义的。a.要求最终产品的每一个特性用某一术语描述；b.若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场合。需求通常是用自然语言编写的，使用自然语言的SRS起草者必须特别注意消除其需求的歧义性。提倡使用形式化需求说明语言。4.3.2完整性如果一个SRS能满足下列要求，则该SRS就是完整的：a.包括全部有意义的要求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的需求；b.对所有可能出现的输入数据的响应予以定义，要对合法和非合法的输入值的响应做出规定；c.要符合SRS要求。如果个别章节不适用，则在SRS中要保留章节号；d.填写SRS中的全部插图、表、图示标记和参照，并且定义全部术语和度量单位。4.3.2.1关于使用“待定”一词的规定任何一个使用“待定”的SRS都是不完全的。a.若万一遇到使用“待定”一词时，作如下处理：（1）对产生“待定”一词的条件进行描述，使得问题能被解决；（2）描述必须干什么事，以删除这个“待定”；b.包含有“待定”一词的任何SRS的项目文件应该：（1）标识与此特定文件有关的版本号或叙述其专门的发布号；（2）拒绝任何仍标识为“待定”一词的SRS章节的许诺。4.3.3可验证性当且仅当SRS中描述的每一个需求都是可以验证的，该SRS才是可以验证的；当且仅当在某一性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。4.3.4一致性当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的。4.3.5可修改性如果一个SRS的结构和风格在需求有必要改变时是易于实现的、完整性的、一致的，那么这个SRS就是可以修改的。可修改性要求SRS具备以下条件：a.具有一个有条不紊的易于使用的内容组织，具有目录表，索引和明确的交叉引用表；b.没有冗余。即同一需求不能在SRS中出现多次。（1）冗余本身不是错误，但是容易发生错误。冗余可增加SRS的可读性，但是在一个冗余文件被更新时容易出现问题。例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改一个地方，于是SRS就变得不一致了。（2）不管冗余是否必须，SRS一定要包含一个详细的交叉引用表，以便SRS具备可修改性。4.3.6可追踪性如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该SRS就是可追踪的。建议采用如下两种类型的追踪：a.向后追踪（即向已开发过的前一阶段追踪）。根据先前文件或本文件前面的每一个需求进行追踪。b.向前追踪（即是向由SRS派生的所有文件追踪）。根据SRS中具有唯一的名字和参照号的每一个需求进行追踪。当SRS中的一个需求表达另一个需求的一种指派或者是派生的，向前、向后的追踪都要提供。例如：（1）从总的用户响应时间需求中分配给数据库操作响应时间；（2）识别带有一定功能和用户接口的需求的报告格式；（3）支持法律或行政上需要的某个软件产品（例如，计算税收）。在这种情况下，要指出软件所支持的确切的法律或行政文件。当软件产品进入运行和维护阶段时，SRS的向前可追踪性显得特别重要。当编码和设计文件作修改时，重要的是要查清这些修改所影响的全部需求。4.3.7运行和维护阶段的可使用性SRS必须满足运行和维护阶段的需要，包括软件最终替换。a.维护常常是由与原来开发无联系的人来进行的。局部的改变（修正）可以借助于好的代码注释来实现。对于较大范围的改变。设计和需求文件是必不可少的，这里隐含了两个作用：（1）如4.3.5条指出，SRS必须是可修改的；（2）SRS中必须包括一个记录，它记录那些应用于各个成分的所有具体条文。例如：它们的危急性（如故障可能危及完全或导致大量财政方面和社会方面的损失）；它们仅与暂时的需要相关（如支持一种可立即恢复原状的显示）；它们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。b.要求在SRS中清楚地写明功能的来源和目的，因为对功能的来源和引入该功能的目的不清楚的话，通常不可能很好地完成软件的维护。4.4SRS的编制者软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用SRS的形式，应该由双方联合起草。这是因为：a.客户通常对软件设计和开发过程了解较少，而不能写出可用的SRS；b.开发者通常对于客户的问题和意图了解较少，从而不可能写出一个令人满意的系统需求。4.5SRS的改进软件产品的开发过程中，在项目的开始阶段不可能详细说明某些细节，在开发过程中可能发现SRS的缺陷、缺点和错误之类的问题，所以可能要对SRS进行改进。在SRS的改进中，应注意如下事项：4.5.1尽管可以预见校正版本的开发以后不可避免，而对需求还必须尽可能完全、清楚地描述。4.5.2一旦最初识别出项目的变化，应引入一个正式的改变规程来标识、控制、追踪和报告项目的改变。批准了的需求改变，用如下的方法编入SRS之中：a.提供各种改变后的正确的、完全的审查记录；b.允许对SRS当前的和被替代部分的审查。4.6SRS的编制工具编制SRS最显而易见的方法是用自然语言来描述。尽管自然语言是丰富多彩的，但不易精确，用形式化的方法较好。4.6.1形式化说明方法在SRS中是否使用形式化方法要依据下列因素：a.程序规模和复杂性；b.客户合同中是否要求使用；c.SRS是否是一个合同工具或仅仅是一个内部文件；d.SRS文件是否成为设计文件的根据；e.具有支持这种方法的计算机设备。4.6.2生产工具软件产品生产中有多种生产工具。比如，计算机的字处理器就是非常有用的生产辅助工具。一个SRS通常有若干作者。可能经历若干版本，并且要进行多次重新组织内容。故生产工具是必要的。4.6.3表达工具在SRS中有许多词汇，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所以表达SRS需要若干工具。比如：a.可以验证实体或活动，无论在SRS中什么地方都是同一名字。；b.可以标识一个特殊的实体或动作在规格说明中的描述位置。此外，可以使用若干种形式化方法，以便允许自动处理SRS内容，只要作某些限制就可以做到；用一些表格或图示法来显示需求。用详细分层体系自动检查SRS的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层，或是上一层的一个组成成分。自动检查SRS具有在4.3条描述的部分或全部特点。5软件需求SRS中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。5.1表达软件需求的方法软件需求可以用若干种方法来表达：a.通过输入、输出说明；b.使用代表性的例子；c.用规范化的模型。5.1.1输入、输出说明用输入输出序列来描述一个软件产品所要求的特性是很有效的。5.1.1.1途径根据被描述的软件的性质，至少有三种不同的途径：a.有些软件产品（如报表系统）要求着重说明输出。一般情况下，致力于输出的系统主要是在数据文卷上操作。用户的输入通常是致力于提供控制信息和启动数据文卷的处理；b.有些软件产品需要着重说明输入、输出特性。关注输入、输出的系统主要是在当前的输入上操作，要求生成与输入相匹配的输出（类似于数据转换例行程序或一个数学函数包）；c.还有一些系统（如过程控制系统）要求记忆它们的状态。可以根据本次输入和上一次输入进行应答。也就是说，它的行为如同一个有限状态机。在此种情况下，既要关注输入/输出对，又要关注这些输入/输出对的次序。5.1.1.2困难多数软件产品可能接收无限的序列作为输入，于是，为了通过输入输出序列完整地说明产品的特性，就要求SRS包括一个无限长的输入和所需的输出充列。然而，用这样的途径不可能完整地描述软件所要求的一切特性。5.1.2典型例子一种选择是用典型例子来说明要求的特性。例如，假设一个系统中当接收“0”时用“1”来回答。显然，要列出全部输入和输出序列是不可能的。然而，用典型的序列可以十分清楚地理解系统的特性。下面是一组四种对话的典型的例子，用它描述系统特性。010101010101010101010101这些对话仅提供了