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

1、计算机软件需求说明编制指南计算机软件需求说明编制指南 1 1 引言引言 1.1 1.1 目的和作用目的和作用 本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明（Software Requirements Specifications，以下简称 SRS）划分成等级，避免把它定义成更小的需求子集。本指南适用对象：软件客户（Customers），以便精确地描述他们想获得什么样的产品。软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。对于任一要实现下列目标的单位和（或）个人：a.要提出开发规范化的 SRS 提纲；b.定义自己需要的具体的格式和内容；c.产生附加

2、的局部使用条款，如 SRS 质量检查清单或者 SRS 作者手册等。SRS 将完成下列目标：a.在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求；b.提高开发效率。编制 SRS 的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在 SRS 中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；c.为成本计价和编制计划进度提供基础。SRS 提供的对被开发软件产品的描述，是计算机

3、软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。SRS 对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；d.为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验证计划。作为开发合同的一部分，SRS 还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为 SRS。因为这种文件几乎不包括详尽的需求说明，并且通常不完全的）；e.便于移植。有了 SRS 就便于移值软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部门，而开发者同样也易于把软件移植到新的客户；f.作为不断提高的基础。由于 SRS 所讨论的是软件产品，而不是

4、开发这个产品的设计。因此 SRS 是软件产品继续提高的基础。虽然 SRS 也可能要改变，但是原来的 SRS 还是软件产品改进的可靠基础。1.2 1.2 范围范围 本指南适用于编写软件需求规格说明，它描述了一个 SRS 所必须的内容和质量，并且在第 6 章中提供了 SRS 大纲。2 引用标准 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 11457 软件工程术语 3 3 定义定义 GB/T 11457 所列术语和下列定义适用于本指南。合同（contract）是由客户和开发者共同签署的具有法律约束力的文件。其中包括产品的技术、组织、成本和进度计划要求

5、等内容。客户（customer）指个人或单位，他们为产品开发提供资金，通常（但有时也不必）还提出各种需求。文件中的客户和开发者也可能是同一个组织的成员。语言（language）是具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。分割（partitioning）把一个整体分成若干部分。开发者（supplier）指为客户生产某种软件产品的个人或集团。在本指南中，客户和开发者可能是同一个组织的成员。用户（user）指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。4 4 编写编写 SRSSRS 的背景信息的背景信息 4.1 SRS4.1 SRS 的基本要

6、求的基本要求 SRS 是对要完成一定功能、性能的软件产品、程序或一组程序的说明。对 SRS 的描述有两项基本要求：a.必须描述一定的功能、性能；b.必须用确定的方法叙述这些功能、性能。4.2 SRS4.2 SRS 的环境的环境 必须认识到 SRS 在整个软件开发规范（见 GB 8566）所规定的有关阶段都起作用。正因为如此，SRS 的起草者必须特别注意不要超出这种作用的范围。这意味着要满足下列要求：a.SRS 必须正确地定义所有的软件需求；b.除了设计上的特殊限制之外，SRS 中一般不描述任何设计、验证或项目管理细节。4.3 SRS4.3 SRS 的特点的特点 4.3.1 4.3.1 无歧义性

7、无歧义性 当且仅当它对每一个需求只有一种解释时，SRS 者是无歧义的。a.要求最终产品的每一个特性用某一术语描述；b.若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场合。需求通常是用自然语言编写的，使用自然语言的 SRS 起草者必须特别注意消除其需求的歧义性。提倡使用形式化需求说明语言。4.3.2 4.3.2 完整性完整性 如果一个 SRS 能满足下列要求，则该 SRS 就是完整的：a.包括全部有意义的要求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的需求；b.对所有可能出现的输入数据的响应予以定义，要对合法和非合法的输入值

8、的响应做出规定；c.要符合 SRS 要求。如果个别章节不适用，则在 SRS 中要保留章节号；d.填写 SRS 中的全部插图、表、图示标记和参照，并且定义全部术语和度量单位。4.3.2.1 4.3.2.1 关于使用“待定”一词的规定关于使用“待定”一词的规定 任何一个使用“待定”的 SRS 都是不完全的。a.若万一遇到使用“待定”一词时，作如下处理：（1）对产生“待定”一词的条件进行描述，使得问题能被解决；（2）描述必须干什么事，以删除这个“待定”；b.包含有“待定”一词的任何 SRS 的项目文件应该：（1）标识与此特定文件有关的版本号或叙述其专门的发布号；（2）拒绝任何仍标识为“待定”一词的

9、SRS 章节的许诺。4.3.3 4.3.3 可验证性可验证性 当且仅当 SRS 中描述的每一个需求都是可以验证的，该 SRS 才是可以验证的；当且仅当在某一性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。4.3.4 4.3.4 一致性一致性 当且仅当 SRS 中各个需求的描述是不矛盾时 SRS 才是一致的。4.3.5 4.3.5 可修改性可修改性 如果一个 SRS 的结构和风格在需求有必要改变时是易于实现的、完整性的、一致的，那么这个 SRS 就是可以修改的。可修改性要求 SRS 具备以下条件：a.具有一个有条不紊的易于使用的内容组织，具

10、有目录表，索引和明确的交叉引用表；b.没有冗余。即同一需求不能在 SRS 中出现多次。（1）冗余本身不是错误，但是容易发生错误。冗余可增加 SRS 的可读性，但是在一个冗余文件被更新时容易出现问题。例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改一个地方，于是 SRS 就变得不一致了。（2）不管冗余是否必须，SRS 一定要包含一个详细的交叉引用表，以便 SRS 具备可修改性。4.3.6 4.3.6 可追踪性可追踪性 如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该 SRS 就是可追踪的。建议采用如下两种类型的追踪：a.向后

11、追踪（即向已开发过的前一阶段追踪）。根据先前文件或本文件前面的每一个需求进行追踪。b.向前追踪（即是向由 SRS 派生的所有文件追踪）。根据 SRS 中具有唯一的名字和参照号的每一个需求进行追踪。当 SRS 中的一个需求表达另一个需求的一种指派或者是派生的，向前、向后的追踪都要提供。例如：（1）从总的用户响应时间需求中分配给数据库操作响应时间；（2）识别带有一定功能和用户接口的需求的报告格式；（3）支持法律或行政上需要的某个软件产品（例如，计算税收）。在这种情况下，要指出软件所支持的确切的法律或行政文件。当软件产品进入运行和维护阶段时，SRS 的向前可追踪性显得特别重要。当编码和设计文件作修改

12、时，重要的是要查清这些修改所影响的全部需求。4.3.7 4.3.7 运行和维护阶段的可使用性运行和维护阶段的可使用性 SRS 必须满足运行和维护阶段的需要，包括软件最终替换。a.维护常常是由与原来开发无联系的人来进行的。局部的改变（修正）可以借助于好的代码注释来实现。对于较大范围的改变。设计和需求文件是必不可少的，这里隐含了两个作用：（1）如 4.3.5 条指出，SRS 必须是可修改的；（2）SRS 中必须包括一个记录，它记录那些应用于各个成分的所有具体条文。例如：它们的危急性（如故障可能危及完全或导致大量财政方面和社会方面的损失）；它们仅与暂时的需要相关（如支持一种可立即恢复原状的显示）；它

13、们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。b.要求在 SRS 中清楚地写明功能的来源和目的，因为对功能的来源和引入该功能的目的不清楚的话，通常不可能很好地完成软件的维护。4.4 SRS4.4 SRS 的编制者的编制者 软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用 SRS 的形式，应该由双方联合起草。这是因为：a.客户通常对软件设计和开发过程了解较少，而不能写出可用的 SRS；b.开发者通常对于客户的问题和意图了解较少，从而不可能写出一个令人满意的系统需求。4.5 SRS4.5 SRS 的改进的改进 软件产品的开发过程中，在项目的开始阶段不可

14、能详细说明某些细节，在开发过程中可能发现 SRS 的缺陷、缺点和错误之类的问题，所以可能要对 SRS 进行改进。在 SRS 的改进中，应注意如下事项：4.5.1 4.5.1 尽管可以预见校正版本的开发以后不可避免，而对需求还必须尽可能完全、清尽管可以预见校正版本的开发以后不可避免，而对需求还必须尽可能完全、清楚楚地描述。4.5.2 4.5.2 一旦最初识别出项目的变化，应引入一个正式的改变规程来标识、控制、追踪一旦最初识别出项目的变化，应引入一个正式的改变规程来标识、控制、追踪和和报告项目的改变。批准了的需求改变，用如下的方法编入 SRS 之中：a.提供各种改变后的正确的、完全的审查记录；b.

15、允许对 SRS 当前的和被替代部分的审查。4.6 SRS4.6 SRS 的编制工具的编制工具 编制 SRS 最显而易见的方法是用自然语言来描述。尽管自然语言是丰富多彩的，但不易精确，用形式化的方法较好。4.6.1 4.6.1 形式化说明方法形式化说明方法 在 SRS 中是否使用形式化方法要依据下列因素：a.程序规模和复杂性；b.客户合同中是否要求使用；c.SRS 是否是一个合同工具或仅仅是一个内部文件；d.SRS 文件是否成为设计文件的根据；e.具有支持这种方法的计算机设备。4.6.2 4.6.2 生产工具生产工具 软件产品生产中有多种生产工具。比如，计算机的字处理器就是非常有用的生产辅助工具

16、。一个 SRS 通常有若干作者。可能经历若干版本，并且要进行多次重新组织内容。故生产工具是必要的。4.6.3 4.6.3 表达工具表达工具 在 SRS 中有许多词汇，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所以表达 SRS 需要若干工具。比如：a.可以验证实体或活动，无论在 SRS 中什么地方都是同一名字。；b.可以标识一个特殊的实体或动作在规格说明中的描述位置。此外，可以使用若干种形式化方法，以便允许自动处理 SRS 内容，只要作某些限制就可以做到；用一些表格或图示法来显示需求。用详细分层体系自动检查 SRS 的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层，或是上一层的一个组成成分。自动检查 SRS 具有在 4.3 条描述的部分或全部特点。5 5 软件需求软件需求 SRS 中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。5.1 5.1 表达软件需求的方法表达软件需求的方法 软件需求可以用若干种方法来表达：a.通过输入、输出说明；b.使用代表性的例子；c.用规范化的模型。5.1.1 5.1.1 输入、输出说明输入、输出说明 用输入输出序列来描