《GB-9385-1988.pdf》由会员分享,可在线阅读,更多相关《GB-9385-1988.pdf(19页珍藏版)》请在三一文库上搜索。
1、中华人民共和国国家标准 计算机软件需求说明编制指南 GB . 吕 . . 一 口 . Gu i d e t o c o mp u t e r s o f t wa r e r e q u i r e me n t s s p e c i f i c a t i o n s 1 引言 1 . 1 目的和作用 本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明 ( S o f t wa r e R e q u i r e m e n t s S p e c i f i c a t i o n s , 以 下 简称S R S ) 划分 成等 级, 避免 把它 定义 成 更 小 的
2、需求 子 集。 本指南适用对象: 软件客户 ( C u s t o m e r s ),以便精确地描述他们想获得什么样的产品。 软件开发者 ( S u p p l i e r s ),以便准确地理解客户需要什么样的产品。 对于任一要实现下列目标的单位和 ( 或)个人: 二要提出开发规范化的S R S 提纲。 b . 定义自己需要的具体的格式和内容。 c . 产生附加的局部使用条款,如S R S 质量检查清单或者S R S 作者手册等。 SR S 将完成下列目标: 二在软件产品完成目 标方面为客户和开发者之间建立共同协议创立一个基础。对要实现的软件 功能做全面描述,帮助客户判断所规定的软件是否符
3、合他们的要求,或者怎样修改这种软件才能适合 他们的要求, b . 提高开发效率。编制S R S 的过程将使客户在设计开始之前周密地思考全部需求, 从而减少事 后重新设计、 重新编码和重新测试的返工活动, 在S R S 中对各种需求仔细地进行复查, 还可以在开发早 期发现若干遗漏、错误的理解和不一致性,以便及时加以纠正。 c . 为成本计价和编制计划进度提供基础。S R S 提供的对被开发软件产品的描述,是计算机软 件产品成本核算的基础,并且可以为各方的要价和付费提供依据。S R S 对软件的清晰描述, 有助于估 计所必须的资源,并用作编制进度的依据; d . 为确认和验证提供一个基准。任何组织
4、将更有效地编制他们的确认和验证计划。 作为开发合 同的一部分,S R S 还可以提供一个可以度量和遵循的基准 ( 然而,反之则不成立, 即任一有关软件的 合同都不能作为SR S o因为这种文件几乎不包括详尽的需求说明,并且通常是不完全的), e . 便于移植。有了S R S 就便于移植软件产品,以适应新的用户或新的机种。 客户也易于移植其 软件到其他部门,而开发者同样也易于把软件移植到新的客户, f . 作为不断提高的基础。由于S R S 所讨论的是软件产品,而不是开发这个产品的设计。因此 S R S 是软件产品继续提高的基础。虽然S R S 也可能要改变,但是原来的S R S 还是软件产品改
5、进的 可靠基础。 1 . 2 范围 本指南适用于编写软件需求规格说明,它描述了一个S R S 所必须的内容和质量, 并且在第6 章中 提供了SR S 大纲。 中 华人民共和 国电 子工业部拍.二 。 月 一 ,批准1 9 .一 1 2 一 0 1 实施 GB 9 2 8 . 一 二 ! 引用标准 GB 8 5 6 6 计算机软件开发规范 G B 8 5 6 7 计算机软件产品开发文件编制指南 G B / T 1 1 4 5 7 软件工程术语 翻 定义 GB / T 1 1 4 5 7 所列术语和下列定义适用于本指南。 合同 ( c o n t r a c t ) 是由客户和开发者共同签署的具有
6、法律约束力的文件。其中包括产品的技术、 组织、成本和进度 计划要求等内容。 客户 ( c u s t o me r ) 指个人或单位,他们为产品开发提供资金,通常 ( 但有时也不必)还提出各种需求。文件中的客 户和开发者也可能是同一个组织的成员。 语言 ( l a n g u a g e ) 是具有语法和语义的通信工具,包括一组表达式、惯例和传递信息的有关规则。 分割 ( p a r t i t i o n i n g ) 把一个整体分成若干部分。 开发者 ( s u p p l i e r ) 指为客户生产某种软件产品的个人或集团。在本指南中,客户和开发者可能是同一个组织的成 员。 用户 (
7、 u s e r ) 指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。 编写S RS 的背.信息 S R S 的基本要求 S R S 是对要完成一定功能、性能的软件产品、程序或一组程序的说明。 对S R S 的描述有两项基本要求: 必须描述一定的功能、性能, 必须用确定的方法叙述这些功能、 性能。 乐卜 s R S 的环境 必须认识到S R S 在整个软件开发规范 ( 见G B 8 5 6 6 )所规定的有关阶段都 起作用。正因为如此, ,. : 4月月 S R S 的起草者必须特别注意不要超出这种作用的范围。这意味着要满足下列要求: 二S R S 必须正确地定义
8、所有的软件需求, b . 除了设计上有特殊限制之外,S R S 中一般不描述任何设计、验证或项目管理细节。 4 . 3 S R S 的特点 4 . 匀 . , 无歧义性 当且仅当 它对每一个需求只有一种解释时,S R S 才是无歧义的。 二要求最终产品的每一个特性用某一术语描述; b .若某一术语在某一特殊的行文中使用时具有多种含义,那么对该术语的每种含义作出解释并 指出其适用场合。 需求通常是用自然语言编写的,使用自然语言的S R S 起草者必须特别注意消除其需求的歧义性。 提倡使用形式化需求说明语言。 GB 9 8 8 5 一 r ; 4 . 3 . 2完整性 如果一个SR S 能满足下列
9、要求,则该SR S 就是完整的: a . 包括全部有意义的需求,无论是关系到功能的、性能的、设计约束的,还是关系到属性或外 部接口方面的需求, 卜 . 对所有可能出现的输人数据的响应予以定义,要对合法和非合法的输人值的响应做出规定, c . 要符合S R S 要求。如果个别章节不适用,则在S R S 中要保留章节号, d . 填写S R S 中的全部插图、表、图示标记和参照,并且定义全部术语和度量单位。 4 . 8 . 2 . 1 关于使用 “ 待定”一词的规定 任何一个使用 “ 待定”的S R S 都是不完全的。 二若万一遇到使用 “ 待定”一词时,作如下处理: ( 1 )对产生 “ 待定”
10、一词的条件进行描述,使得问题能被解决; ( 2 )描述必须千什么事,以 删除这个 “ 待定”; b . 包含有 “ 待定”一词的任何S R S 的项目文件应该: ( 1 )标识与此特定文件有关的版本号或叙述其专门的发布号; ( 2 )拒绝任何仍标识为 “ 待定”一词的S R S 章节的许诺。 4 . a . 3 可验证性 当且仅当S R S 中描述的每 一 个需求都是可以脸证的,该S R S 才是可以验证的;当且仅当在某一 性能价格比可取的有限处理过程,人或机器能通过该过程检查软件产品能否满足需求时,才称这个需 求是可以验证的。 4 . 3 . 4 一致性 当且仅当S R S 中各个 需求的描
11、述是不矛盾时S R S 才是一致的。 4 . 3 . 5 可修改性 如果一个S R S 的结构和风格在需求有必要改变时是易于实现的、完整的、一致的,那么这个S R S 就是可以修改的。可修改性要求SR S 具备以下条件: 二具有一个有条不紊的易于使用的内容组织,具有目录表,索引和明确的交叉引用表, b . 没有冗余。即同一需求不能在S R S 中出现多 次。 ( 1 )冗余本身不是错误,但是容易发生错误。冗余可增加SR S 的可读性, 但是在一个冗余文件 被更新时容易出现间题。例如:假设一个明确的需求在两个地方详细列出,后来发现这个需求需要改 变,若只修改了一个地方,于是S R S 就变得不
12、一 致了。 ( 2)不管冗余是否必须,SR S 一定要包含一个详细的交叉引用表,以便S R S 具备可修改性。 4 . a . 布 可追踪性 如果每一个需求的源流是清晰的,在进一步产生和改变文件编制时,可以方便地引证每一个需求, 则该S R S 就是可追踪的。建议采用如下两种类型的追踪: 二向后追踪 ( 即向已开发过的前一阶段追踪)。根据先前文件或本文件前面的每一个需求进行 追踪。 b . 向前追踪 ( 即是向由S R S 派生的所有文件追踪)。 根据S R S 中具有唯一的名字和参照号的 每一个需求进行追踪。 当S R S 中的一个需求表达另一个需求的一种指派或者是派生时,向前、向后的追踪都
13、要提供。 例 如: ( 1 )从总的用户响应时间需求中分配给数据库操作响应时间。 ( 2 )识别带有 一 定功能和用户接口的需求的报告格式, ( 3 )支 持法津或行政 上 需要的某个软 件 产品 ( 例如 , 计算税 收) 。在 这种情况下 , 要指出软件 所支恃的确切的法律或行政文件。 GB 9 8 8 5 一 8 8 当软件产品进人运行和维护阶段时,S R S 的向前可追踪性显得特别重要。 当编码和设计文件作修 改时,重要的是要查清这些修改所影响的全部需求。 二吕 . 了 运行和维护阶段的可使用性 S R S 必须满足运行和维护阶段的需要,包括软件最终替换。 a . 维护常常是由与原来开
14、发无联系的人来进行的。局部的改变 ( 修正)可以借助于好的代码注 释来实现。对于 较大范围的改变。设计和需求文件是必不可少的,这里隐含了两个作用: ( 1 )如4 . 3 . 5 条指出,S R S 必须是可修改的; ( 2 ) S R S 中必须包括一个记录,它记录那些应用于各个成分的所有具体条文。例如: 它们的危急性 如故障可能危及完全或导致大量财政方面和社会方面的损失), 它们仅与暂时的需要相关 ( 如支持一种可立即恢复原状的显示), 它们的来源 ( 如某功能是由巳 存在的软件产品的全部拷贝复制而成)。 b . 要求在S R S中清楚地写明功能的来源 和目 的,因为对功能的来源和引人该功
15、能的目 的不清 楚的话,通常不可能很好地完成软件的维护。 4 . 4 S R S的编制者 软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用 s R S的形式,应该由双方联合起草。这是因为: 客户通常对软件设计和开发过程了 解较少,而不能写出可用的S RS, 开发者通常对于客户的问题和意图了解较少,从而不可能写出一个令人满意的系统需求。 a.阮 4 . 5 S R S的改进 软件产品的开发过程中, 在项目的开始阶段不可能详细说明某些细节,在开发过程中可能发现 S R S 的缺陷、缺点和错误之类的问题,所以可能要对S RS进行改进。 在S R S的改进中,应注意如下
16、事项: 4 . 5 . 1 尽管可以预 见 校正版 本在开发以 后不可 避免, 而对 需求 还必须 尽可能完全、 清楚 地描述。 月 . 石 、 2 一旦 最初识别出项目 的变化,应弓 I 人一个正式的改变 规程来标识、 控制、剧踪 和 报告项目 的 改变。批准了的需求改变,用如下的方法编人S R S之中: a . 提供各种改变后的正确的、完全的审查记录; b . 允许对S R S当 前的和被替代部分的审查。 4 . 6 S R S的编制工具 编制S R S最显而易见的方法是用自 然语言来描述。 尽管自然语言 是丰富多 彩的, 但不易精确, 用形式化的方法较好。 4 . 6 . 1 形式化说明
17、方法 在S R S中是否使用形式化方法要依据下列因素: . 。 程序规模和复杂性, . 客户合同中是否要求使用, c . S R S是否是一个合同工具或仅仅是一个内部文件, d . S R S文件是否成为设计文件的根据, e . 具有支持这种方法的计算机设备。 4 . 6 . 2 生产工具 软件产品 生产中 有多种生产工具。比如, 计算 机的字处理器就是非常有用的生产辅 助工具。一个 S R S通常有若干作者。 可能经历若干版 本,并且要进行多次重新组织内容。故生产工具是必要的。 4 . 6 . 3 表达工具 在S R S中有许多词汇, 特别是许多名词和动词,专门 涉及到系统的实体和许多活动,
18、所以表 达S RS需要若干工具。比如: GB 一二 可以脸证实体或活动,无论在S R S中什么地方都是同一名字. 可以标识一个特殊的实体或动作在规格说明中的描述位te 阮 此外,可以使用若干种形式化方法,以便允许自动处理S R S内容,只要作某些限制就可以傲到: 用一些表格或图示法来显示播求。 用详细分层体系自 动检查S R S的需求,这里每一个分层自身是完全的,但是也可以扩展为下一 层,或是上一层的一个组成成分。 自 动检查S R S具有在4 . 3 条描述的部分或全部特点。 马 软件份求 S R S中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。 5 . 1表达软 件需求
19、的方法 软件浦求可以用若干种方法来表达: 二通过抽人、翰出说明, b . 使用代表性的例子. c . 用规范化的模型。 5 . 1 . 1 翰 人、 翰 出 说 明 用输人轴出序列来描述一个软件产品所要求的特性是很有效的。 5 . 1 . 1 . 1 途径 根据被描述的软 件的性质,至少有三 种不同 的途 径: 二有些软件产品 ( 如报表系统)要求着重说明翰出。一般情况下,致力于输出的系统主要是在 数据文卷 上 操作。用户的输人通常是致力 于提供 控制信息 和启动数据文卷 的处理, b . 有些软件产品需要着重说明输人、翰出 特性。关注翰人、翰出的系统主要是在当 前的输人上 操作,要求生成与翰
20、人相匹配的输出 ( 类似 于数据转 换例行程序或一个数学函数包)。 c . 还有一 些系 统 ( 如过程控制系 统) 要求记忆 它们的 状态。可以 根据本次输 人和上一 次输 人进 行应答。也就是说,它的行为如同一个有限状态机。在此种情况下,既要关注输人/ 输出对,又要关 注这些输人/ 输出对的次序。 5 . 1 . 1 . 2 困难 多数软件产品可能接收无限的序列作为输人,于是,为了通过输人输出序列完整地说明产品的特 性,就要求S R S包 括一个无限 长的输 人和 所需的轴出序 列。然而,用 这样的途径 不可能完整 地描述 软件所要求的一切特性。 二1 . 2 典型例子 一种选择是用典型例
21、子来说明要求的特性。例如,假设一个系统中当接收 “ 0 ”时用 “ 1 ”来回 答。显然,要列出全部翰人和输出序列是不可能的。然而,用典型的序列可以十分清楚地理解系统的 特性。下面是一组四种对话的典型的例子,用它描述系统特性。 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 这些对话仅提供了要求的输人和翰出之间的关系,但是不能完全描述系统的特性。 5 . 1 . E 模型 另一种表达需求的方法是模型的方式,这是表达复杂需求的精确和有效的方法。 至少可以提出三种可供使用的通用模型:数学型、功能型、计时型。 应注意区别各种模型的应用场合,参考5 .
22、1 . 3 . 5 。 1 8 2 GB 二 8 5一 s s 二1 . 8 . 1 数学模型 数学模型是使用 数学关系描述软件特性的模型。数学模型对某些特殊应用领域是特别有用的。例 如,导航、 线性规划、计f经济、信 号处理和气象分析等。 用 数学模型能够对5 . 1 . 2 中 所讨论 的典型例子描述 如下: ( 0 1) 这里,“ 。 ”号表示括号内的字符串可以重复一次或多次。 5 . 1 . 3 . 2 功能模型 功能模型是 提供从愉人到翰出映象的 模型。 象有限 状态机或P e t r i 网,这些功能 模型可以有助于 标识和定义软件的各种特点,或者可以表示系统所要进行的操作。 对
23、前面用数学模型描述的例子。可用图1 所示的 有限 状态机形式的功能 模型来描述。图中 进人的 箭 头表示启动状态。 双线的方框表示接收状态。在各线记 号x / Y的含义是: x 代表接受的轴人, 而 Y是产生的输出。 口 S aS 1 一/1 图 1 . t . 8 . 8 计时模型 计时模型是一种增加了时间限制的模型。这种模型对于表达软件特性的形式和细节特别有用。尤 其是实时系统或考虑人为因素的系统。 计时模型可以把下列限制加到图1 的模型中去: 二激活因素。 将在进人S1 状态3 0 8 之内出现。 b . 响应1 将在进人S2 状态2 : 之内出现。 5 . 1 . 8 . 4 其他模型
24、 除了 上面提及的摸型外。对一些特殊的应用还有一些特别有用的模型。例如,编译 程序的说明可 以 使用属 性文法,工资单系统可以使用表格。要注意的是,对S R S使用形式需求语言, 通常含有使 用特殊模型的意思。 5 . 1 . 吕 . 肠 警告 无论使用哪一类型的模型,都要: GB 9 3 3 .一 二 5 . 1 . 3 . 1 数学模型 数学模型是使用 数学关系描述软件特性的模型。 数学模型对某些特 殊应用领城是特别有用的。例 如,导航、线性规划、计f经济、信号处理和气象分析等。 用 数学模型能够对5 . 1 . 2 中 所讨论的典型例子描述 如下: c 0 1 ) .。 这里, “ 。
25、”号表示括号内的字符串可以重复一次或多次。 5 . 1 . 3 . 2 功能模型 功能模型是 提供从翰 人到翰出 映象的 模型。象有限 状态机或P e t r i 网,这些功能模 型可以 有助于 标识和定义软件的各种特点,或者可以表示系统所要进行的操作。 对 前面用 数学模型描 述的例子。可用图1 所示的有限 状态机形式的功能模型来描述。 图中 进人的 箭 头 表示启 动状态。 双线的方框表 示接收状态。 在各线记 号x / Y的含义是: x 代表接受的翰人, 而 Y是产生的输出。 口 S 2s t 一 / 1 图 1 二1 . 3 . 3 计时模型 计时模型是一种增加了时间限制的模型。这种模
26、型对于表达软件特性的形式和细节特别有用。尤 其是实时系统或考虑人为因素的系统。 计时模型可以把下列限制加到图1 的模型中去: a . 激活因素。 将在进入S1 状态3 0 S 之内出现。 b . 响应1 将在进人S2 状态2 s 之内出现。 5 . 1 . 3 . 4 其他模型 除了上面提及的模型外。对一些特殊的应用还有一些特别有用的模型。例如,编译程序的说明可 以使用属性文法,工资单系统可以使用表格。要注意的是,对S RS使用形式需求语言,通常含有使 用特殊模型的意思。 5 . 1 . 3 . 5 警告 无论使用哪一类型的模型,都要: GB 9 88 5一 8 8 5 . 8 . 1 . 1
27、 S R S必须描述 在什么 数据上、为谁完成什么 功能、 在什么地方、 产生什么 结果。S R S应 把注意力集中在要完成的服务目 标上。通常不指定如下的设计项目: a . 把软件划分成若干模块. b . 给每一个模块分配功能. c . 描 述 模块 间的信 息流程或者 控制流 程, 二选择数据结构。 5 . 8 . 1 . 2把 设 计 完 全同 S R S 隔 离 开 来 始 终 是 不 现 实 的 。 安 全 和 保 密 方 面 的 周 密考 虑 可 能 增 加 一 些 直 接反映设计约束的需求。例如: a . 在一些分散的模块中保持某些功能, b . 允 许在程序 的某些区域 之间进
28、行有限 的 通讯, 。 . 计算临界值的检查和。 5 . 8 . 1 . : 通常应考虑到, 若要为软 件选 择高层次的 设计, 就可 能需要大量的 资源( 可 能占 整个产品 开 发成本的1 0 % -2 0 % 以上)。有两种选择: a . 不顾本指南 的警告,在S R S中描述了 设计。 这意 味着,或者 将一个潜 在不适当的设计作为 一个需求 进行描述( 因为, 若要 得到好的 设计, 所花费 的时间是不够的), 或者 在需求阶段花费了 过 多的时间 ( 因为在S R S完成之前整个设计分析都要完成). b . 采用本指南中5 . 1 . 3 条中的建议,用 模型设计描 述 需求,这种
29、模型设计只用于辅 助描 述 需求, 而不使之成为实际的设计。 5 . 3 . 2 在S R S中嵌人了一些项目 要求 S R S应当是描写一个软件产品,而不是描 述生产软 件产品的过程。 项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解 ( 因此不应当 包括在S RS 中)例如: a . 成本。 . 交货 进度, c . 报表处理, d . 软件开发方法. 二质量保证, f . 确认和验证的标准, 二验收过程。 项目需求在另外的文件中描述。在S R S中提供的只是关于软件产品本身的豁求。 B S RS大纲 本章 着重 讨论S R S的每一个基本部分,可 以 作为 一个S R S的大
30、纲。 表1 给出 该大纲目录, 表 2 至表5 给出 大 纲中第3 章的具体需求内 容。各 开发者 和客户 应当根据所描述的 实际 情况, 按本指南 有关规定编写自己的S RS o GB 9 3 8 5一 书. 表 1 S RS大纲 t 前官 1 . 1 目的 1 . 2 范围 1 . 3 定义、编写词、略语 1 . 4 参考资料 2 项目.迷 2 . 1 产品描述 2 . 2 产品功能 2 . 3 用户 特点 2 . 4 一般约束 2 . 5 假设和依据 . 典体.求 ( 参阅本指南6 . 3 . 2 条中兵体需求的组织形式) 附录 素引 二1 前言 ( S R S第1 章) 本章提供整个S
31、 R S综述。 5 . 1 . 1 目的 ( S R S的1 . 1 条) 在这一条包括下列内容: 二描述实际S R S的目的. b . 说明S R S所预期的读者。 二1 . 2 范围 ( S R S的1 . 2 条) 。 . 用 一个名 字 标识 被生产的软 件产品。比如:x x x 数据库 系统, 报表生成 程序 等等, b . 说明软件产品将干什么,如果需要的话,还要说明软件产品不干什么, c . 描述所说明的软 件的应用。应当: ( 1 )尽可能精确地描述所有相关的利益、目的、以及最终目标。 ( 2 )如果有一个较高层次的说明存在,则应该使其和高层次说明中的类似的陈述相一致 ( 例如
32、, 系统的播求规格说明)。 二, . 3 定义、 缩写词、 略语 ( S R S的1 . 3 条) 本条中 必须提供 全部 需求的术语、 缩写词 及 略语 的 定义,以便对S R S进行适当 的 解释。这些信 息可以由S R S的附录 提供 。也可以 参考其他的文件。 6 . 1 . 4参考 资料 ( S R S的1 . 4 条) 本条应包括: 。 . 在S R S 中 各 处参 照 的 文件 的 全 部清 单, 如 经核 准 的 计 划任务书 , 上 级机 关 批文、 合 同 等. b . 列出其他参考资料,如属本项目 的其他已发表的文件和主要文献等。每一个文件、 文献要有 标题,索 引号或
33、文件号, 发布或发表日 期以及出版单位, c . 详细 说明可以 得到该参考文件的来源。这个信息可以通过引用附录或其他文件提供。 二2 项目概述 ( S RS第2 章) GB 9 8 8 5一 二 本章应描述影响产品和其需求的一般因素,本章不说明具体的需求,而仅使需求更易于理解。 6 . 2 . 1 产品描述 ( S R S的2 . 1 条) 这一条是把一个产品用其他有关的产品或项目来描述 。 如 果这个产品 是 独立的, 而且 全部内 容自 含,应 在此说明, b . 如果S R S定义的产品是一个较大的系统或项目中的一个组成部分,那么本条应包括如下内 容: ( 1 )要概述这个较大的系 统
34、或项目 的每一个 组成 部分的功能,并 说明其 接口; ( 2 ) 指出 该软 件产品主要的外部接口 。在这里, 不要求对 接口详细 地描述, 详细描 述放在S R S 其他章条中; ( 3 )描述所使用的计算 机硬 件、 外围 设备。 这里仅 仅是一个综 述 性描 述。 在 本条的描述中,用一个方框 图来表达一个 较大 的系 统或项目 的主 要 组成部分、 相互 联系 和外部 接口是非常有帮助的。 本 条 既 不用 来 强 迫 进 行 设 计 方案 的 描述 , 也 不 是 描 述 在 解 决 问 题 时 的 设 计 约 束 。 本 条 应 对 在以 后 具体需求一章中 说明的设计约束提供理
35、由。 6 . 2 . 2产品 功能 ( S R S的2 . 2 条) 本条 是为 将要完成的软 件功能 提供 一个摘要。 例如,对 于一个记帐程序来 说, S R S可以用这部 分来描述: 客户帐目 维 护、 客户财 务 报表和发票 制作,而 不必 把功能所要求的大曼的细 节描写出来。 有时, 如果存在 较高层次的规 格说明时,则 功能摘 要可直接从中 取得, 这个 较高层次的规 格说明 为软件产品分配了特殊的功能,为了清晰 起见,请注意: 二 编 制功能的一种方法是制作功能表,以便客户或者第一次读 这个文件的人都可以理解. b . 用 方框 图来表达不同 的功能和它们的关系也 是有帮助的。
36、但要牢 记, 这样的图不是产品 设 计 时所需求的,而只是一种有效的解释性的工具。 这一 条不用 作陈 述 具 体需求 , 只 是 对 后来S R S中 具 体需求一章 中为 什么 要描 述 的某 些需 求 提供 理由。 6 . 2 . 8 用户 特点 ( S R S的2 . 3 条) 本条要描述影响具体需求的产品的最终用户的一般特点。 许多人在软 件生存周期的操作和维护阶段与系统相关。而这些人中有用户、操作员、 维护人员和 系 统工作人员。 这些人的 某些 特点,象 教育水平、 经验、 技术、专长等,都是施加于系统 操作环境的 重要约束。 如果系统的大多 数用户是一 些临时的用户,那么就要求
37、系 统包含如何完成基本功能的 提示,而不 是假设用户已 经从 过去的 会议或从阅读用户 指南 中了 解到 这些细节。 这一条的内 容不能用 来陈述 具体需求或强加若干 特殊的设计约束,本条应对在S R S的具体籍求 一章之中的某些具体需求或设计约束的描述 提供 理由。 6 . 2 . 4 一般约束 ( S R S的2 . 4 条) 本条对设计系 统时限 制开发者选择的其他一些项 作一般性描述。而 这些项 将限 定开发者在设计系 统时的任选项。这些包括: a . 管理方针, b . 硬件的限制, c . 与其他应用间的接口, d . 并 行操作, e . 审查功能; f . 控制功能, 皿 .
38、所需的高级语言; GB 9 3 8 5一 . 8 h . 通信协议 i . 应用的临界点, 1 . 安全和保密方面的考虑。 本 条 不 陈 述 具 体 需 求 或 具 体 设 计 约 束 : 而 对S R S 的 具 体 需 求 一 章 中 为 什 么 婪 确 定 某 些 具 休 需 求 和设计约束提供理由。 6 . 2 . 5 假设和依 据 ( S R S的2 . 5 条) 本条列出 影响S R S中陈述的需求的每一个因素 。 这些因素 不是软 件的设计约束, 但是它们的 改 变可能影响到S R S中 的需求。 例如:假 定一个特定的 操作系统是在被软 件产品 指定的硬 件上使用 的, 然而
39、, 事实上这个操作系统是不可能使用的,于是,S R S就要进行相应的改变。 8 . 3 具体需求 ( S RS的第3 章) 本章应 包括软件开发者在建立设计时需要的全部细节。这是S R S中篇幅最大和最重要的部分。 a . 根据本指南第4 章所规定的准则 ( 如可验证性、 无歧义性等) ,对每一个需求细 节作具体描 述; b . 在S R S的前言、项目 概述、附录部分的有关 讨论中,要 提供 对任何一个具体需求交 叉引用 的背景. c . 具体需求分类的方法如下: ( 1 )功能需求; ( 2 ) 性能需求; ( 3 )设计约束, ( 4)属性, ( 5 )外部接口需求。 本章中要注意的二点
40、是: a , 按符合逻辑的和可读的方式组织, b , 详细描述每一个需求,使得该需求应达到的目 标能够用指定的方法进行客观的验证。 8 . 3 . 1 具体需求的内容 8 . 3 . 1 . 1 功能需求 本条描述软 件产品 的输 人怎样变 换成输出 。即软 件必须 完成的基本 动作。 对于每一类功能或者 有时对于 每一 个 功能, 需要 具体描述其输 人、 加丁 和输出的 需求。这 通常由 四个部分组成: 二引言 这部分描述的是功能要达到的目 标、 所采用的方法和 技术,还应清楚 说明功能意图 的由来和背景 。 b . 输人 这部分应包括: ( 1 ) 详 细 描 述 该 功 能 的 所 有
41、 输 人 数 据, 如 : 输人源 、 数量、 度量 单位、时间 设 定、 有效输 人范围 ( 包 括精度和公 差), ( 2 ) 操作员 控制细 节的 需求。其中有名字、 操作员 活动的描述 、 控制台 或 操作员的 位置。 例如: 当 打印 检查时,要求 操作员进行格式调整。 ( 3 )指明引用接口说明或接口控制文件的参考资料。 c . 加工 定义输 人 数据、 中间参数,以获 得预 期输出 结果的全部 操作。 它包 括如 下的 说明: ( 1 )输人 数据的有效 性检查; ( 2 )操作的顺序,包括事件的时间设定; ( 3 )异常情况的响应,例如,淦日 、通信故障、错误处理等; GB 9
42、 3 8 5一 . 9 ( 4 )受操作影响的参数; ( 5 )降级运行的要求, ( 6 )用于把系 统输 人变换成相应输出的任何方法 ( 方程式、 数学算 法、逻辑 操作等)。 ( 7 )输出数据的有效性检查。 d . 输出。 这部分应包括: ( 1 )详细描述该功能所有输出 数据,例如:翰出目 的地、数量、度量单位、时间关系、有效抬 出 的范围 ( 包括精度和公 差)、非法值 的处理、出错信息, ( 2 )有关接口 说明或接口控制文件的参考 资料。 此外,对着重于输人输出行为的系 统来说, S R S应指定所有有意义的输人、输出对及其序列。 当 一个系统要求记忆它的 状态时,需要这个序列,
43、使得它可以根据本次输人和以前的状态作出响应。 也就是说,这种情况犹如有限 状态机。 二3 . 1 . 之 性能需求 从整体来说, 本条应具体说明软件、或人与软 件交互的静 态或 动态数值 需求。 二静 态数值 需求可能包括: ( 1 )支持的终端数。 ( 2 )支持并行操作的用户 数。 ( 3 )处理的文卷和记录数, ( 4 )表和文卷的大小。 b . 动态数值 需求可能包 括:欲 处理的事务和任务的 数量,以 及在正常情况下和峰值 工作条件下 一定时间周期中处理的数据总量。 所有这些需求都必须用可以 度量的术语 来叙述。 例如,9 5 % 的事务必须在小于1 : 时间内处理完, 不然, 操作
44、员 将不等 待处 理的完成。 二3 . 1 . 3 设计约束 设计约束受其他标准、硬件限制等方面的影响。 5 . 3 . 1 . 3 . 1 其他标准的约束 本项将指定由现有的标准或规则派生的要求。例如: a . 报表格式; b . 数据命名, c . 财务处理; d . 审计追味 等等。 二3 . 1 . 3 . 2 硬件的限 制 本项包括在各种硬件约束下运行的软件要求,例如,应该包括: , . 硬件配置的特点 ( 接口数,指令系统等), b . 内 存储器 和辅 助存储器的容量。 二3 . 1 . 4 属性 在软件的需求之中有若干个属性,下面指出其中的几个 ( 注意:对这些决不应理解为是一
45、个完整 的清单)。 二3 . 1 . 4 . 1 可用性 可以指定一些因素 ,如检查点、 恢复和再启动等,以保证整个系统有一个确定的可用 性级别。 6 . 3 . 1 . 4 . 2 安全性 这里 指的是 保护软 件的要素 ,以 防止各种非 法的 访问、 使用, 修改、 破坏或者泄 密。 这个 领域 的 具体需求必须包括: GB 二 8 5一 二 a . 利用可靠的密码 技术; b . 掌握特定的记录或历史数据集, c . 给不同的模块分配不同的功能, d . 限 定一个程序中某些区域的通信, e . 计算临界值的检查和。 6 . 3 . 1 . 4 . 3可维护性 这里规定若干需求以确保软件
46、是可维护的。例如: 二 软件模块所需要的特殊的祸 合矩阵, . 为微 型装置指定特殊的 数据/ 程序分割要求。 6 . 8 . 1 . 4 . 4 可转移/ 转换性 这里规 定把软 件从 一种环境移植到另 一种环 境所要求的用户 程序,用户 接口 兼容方面 的约束等等。 6 . 8 . 1 . 4 . , 警告 指定所需属 性十分重要,它使得人们能用规定的方法去进行客观的验证。 6 . 3 . 1 . 5 外部接口需求 6 . 3 . 1 . 5 . 1用户 接口 提供用户 使用软件产品时的接口 需求。例如,如果系统的用户 通过显示终端进行操作,就必须指 定如下要求: 二对屏幕格式的要求; b
47、 . 报表或菜 单的页 面打印格式和内容, c . 输人输出的相对时间, d . 程序功能键的可用性。 6 . 8 . 1 . 5 . 2 硬件接口 要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜:支撑什么样的 设备,如何支撑这些设备,有何约定。 6 . 3 . 1 . 5 . 3 软件接口 在这里应指定需使用的其他软件产品 ( 例如,数据管理系统,操作系统,或者数学软件包),以 及同其他应用系统之间的接口。 对每一个所需的软件产品,要提供如下内容: a . 名字, b . 助记符, c .规 格说 明号, d . 版本号, e . 来源。 对于每一个接口,这部分应说明
48、与软件产品相关的接口软件的目 的,并根据信息的内容和格式定 义接口,这里不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。 二8 . 1 . 与 二 通信接口 这里指定各种通信接口,例如,局部网络的协议等等。 6 . 3 . 1 二其他需求 根 据软 件和用户 组 织的特 性等,某些需求放在下面各项中描述。 6 . 8 . 1 . 6 . 1 数据库 本项对作为产品的一部分进行开发的数据库规定一些需求,它们可能包括: r b. 在6 . 3 . 1 . 1 条中标识的信息类别; 使用的频率, GB 8 8 8 8- 8 8 c . 存取能力; d . 数据元素 和文卷描述符。
49、e . 数据元素、记录和文卷的关系。 f . 静 态和 动态的组 织, 妞 . 数据保存要求。 注: 如 果使用一个现 有的 数据库 包,这个包应在“ 软 件接口 ”中 命名,并在那里详细 说明其用 法。 二8 . 1 . 8 . 2 操作 这里说明用户要求的常规的和特殊的操作。 二在用户 组织之中各种方式的操作。例如,用户 初始化操作, b . 交互 作用 操作的周期和无人 操作的周期。 c . 数据处理支持功能, d . 后援和恢复操作。 注:这里的内容有时是用户接口的一部分。 二8 . 1 . 8 . 8 场合适应性需求 这里包括: 二 对给定场合、 任务或操作方式的任何数据或初始化顺序的需求进行定义。例如,栅值,安全 界限等等。 卜 . 指出 场合或相关任务为特点,这里可以被修改以使软件适合特殊配制的要求。 二3 . 2 具体需求的组织 本条通常是S RS所有部分中最大并且最复杂的部分。 二 可以根据软件实现功能的基本类型,将本条分成若干段。 例如:考虑一个大的交互记帐系 统, 在里层可以分为操作软 件 ( 它支持近乎 实时的事务处理)、支撑软 件 ( 联机功能、磁盘 备份、装人磁 带等 等)以 及诊 断软 件 ( 诊 断硬 件、 通信 等), 外一 层 是应 收款帐 以及应付款 帐 等 等; b . 结构细分的目 的是提高S R S的可读
链接地址:https://www.31doc.com/p-3759411.html