6.3.1.4.4 可转移/转换性
这里规定把软件从一种环境移植到另一种环境所要求的用户程序,用户接口兼容方面的约束等等。
6.3.1.4.5 警告
指定所需属性十分重要,它使得人们能用规定的方法去进行客观的验证。
6.3.1.5 外部接口要求
6.3.1.5.1 用户接口
提供用户使用软件产品是地的接口需求。例如,如果系统的用户通过显示终端进行操作,就必须指定如下要求:
a. 对屏幕格式的要求;
b. 报表或菜单的页面打印格式和内容;
c. 输入输出的相对时间;
d. 程序功能键的或用性。
6.3.1.5.2 硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜:支撑什么样的设备,如何支撑这些设备,有何约定。
6.3.1.5.3 软件接口
在这里应指定需使用的其他软件产品(例如,数据管理系统,操作系统,或者数学软件包),以及同其他应用系统之间的接口。
对每一个所需的软件产品,要提供如下内容:
a. 名字;
b. 助记符;
c. 规格说明号;
d. 版本号;
e. 来源。
对于每一个接口,这部分应说明与软件产品相关的接口软件的目的,并根据信息的内容和格式定义接口,这里不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。
6.3.1.5.4 通信接口
这里指定各种通信接口,例如,局部网络的协议等等。
6.3.1.6 其他需求
根据软件和用户组织的特性等,某些需求放在下面各项中描述。
6.3.1.6.1 数据库
本项对作为产品的一部分进行开发的数据库规定一些需求,它们可能包括:
a. 在6.3.1.1条中标识的信息类别;
b. 使用的频率;
c. 存取能力;
d. 数据元素和文卷描述符;
e. 数据元素、记录和文卷的关系;
f. 静态和动态的组织;
g. 数据保存要求。
注:如果使用一个现有的数据库包,这个包应在“软件接口”中命名,并在那里详细说明其用法。
6.3.1.6.2 操作
这里说明用户要求的常规的和特殊的操作。
a. 在用户组织之中各种方式的操作。例如,用户初始化操作;
b. 交互作用操作的同期和无人操作的周期;
c. 数据处理支持功能;
d. 后援和恢复操作。
注:这里的内容有时是用户接口的一部分。
6.3.1.6.3 场合适应性需求
这里包括:
a. 对给定场合、任务或操作方式的任何数据或初始化顺序的需求进行定义。例如,栅值,安全界限等等。
b. 指出场合或相关任务的特点,这里可以被修改以使软件适合特殊配制的要求。
6.3.2 具体要求的组织
本条通常是SRS所有部分中最大并且最复杂的部分。
a. 可以根据软件实现功能的基本类型,将本条分成若干段。例如:考虑一个大的交互记帐系统,在里层可以分为操作软件(它支持近乎实时的事务处理)、支撑软件(联机功能、磁盘备份、装入磁带等等)以及诊断软件(诊断硬件、通信等),外一层是应收款帐以及应付款帐等等;
b.结构细分的目的是提高SRS的可读性,而不是进行概要设计。
对于SRS中的第3章的具体需求部分的最好的组织方案取决于所说明的软件产品的应用范围和性质。
表2~表5提供了四种可能的组织方案。
a. 大纲1(表2)中首先说明全部功能需求,然后说明四种类型的接口要求,最后是其他需求;
b. 大纲2(表3)中,把对应每个特定功能的四种接口需求和该功能需求放在一起描述,然后说明其他需求;
c. 大纲3(表4)中,与功能需求有关的全部内容放在一起首先说明,然后是其他需求的描述。对每一种外部接口的需求重复上述过程;
d. 大纲4(表5)中,接口需求和其余的需求作为每一个功能需求的附属部分来说明。
SRS的具体需求的组织形式必须选择可读性最好的方法来描述。
6.4 支持信息
支持信息是指目录表,附录和索引。以便使SRS易于使用。
6.4.1 目录表和索引很重要,而且应按照可以接受的好的文件规则来编写。
6.4.2 对一个实际的需求规格说明来说,若有必要应该编写附录。附录中可能包括:
a. 输入输出格式样本,成本分析研究的描述或用户调查结果;
b. 有助于理解SRS的背景信息;
c. 软件所解决问题的描述;
d. 用户历史、背景、经历和操作特点;
e. 交叉访问表。按先后次序进行编排,使一些不完全的软件需求得以完善(参见4.3.2条和4.3.3条);
f. 特殊的装配指令用于编码和媒体,以满足安全、输出、初始装入或其他要求。
6.4.3 当包括附录时,SRS必须明确地说明附录是不是需求要考虑的部分。
6.1 前言(SRS第1章)
本章提供整个SRS综述。
6.1.1 目的(SRS的1.1条)
在这一条包括下列内容:
a. 描述实际SRS的目的;
b. 说明SRS所预期的读者。
6.1.2 范围(SRS的1.2条)
a. 用一个名字标识被生产的软件产品。比如:×××数据库系统,报表生成程序等等;
b. 说明软件产品将干什么,如果需要的话,还要说明软件产品不干什么;
c. 描述所说明的软件的应用。应当:
(1)尽可能精确地描述所有相关的利闪、目的、以及最终目标。
(2)如果有一个较高层次的说明存在,则应该使其和高层次说明中的类似的陈述相一致(例如,系统的需求规格说明)。
6.1.3 定义、缩写词、略语(SRS的1.3条)
本条中必须提供全部需求的术语、缩写词及略语的定义,以便对SRS进行适当的解释。这些信息可以由SRS的附录提供。也可以参考其他的文件。
6.1.4 参考资料(SRS的1.4条)
本条应包括:
a. 在SRS中各处参照的文件的全部清单,如经核准的计划任务书,上级机关批文、合同等;
b. 列出其他参考资料,如属本项目的其他已发表的文件和主要文献等。每一个文件、文献要有标题,索引号或文件号,发布或发表日期以及出版单位;
c. 详细说明可以得到该参考文件的来源。这个信息可以通过引用附录或其他文件提供。
6.2 项目概述(SRS第2章)
本章应描述影响产品和其需求的一般因素,本章不说明具体的需求,而仅使需求更易于理解。
6.2.1 产品描述(SRS的2.1条)
这一条是把一个产品用其他有关的产品或项目来描述。
a. 如果这个产品是独立的,而且全部内容自含,应在此说明;
b. 如果SRS定义的产品是一个较大的系统或项目中的一个组成部分,那么本条应包括如下内容:
(1)要概述这个较大的系统或项目的每一个组成部分的功能,并说明其接口;
(2)指出该软件产品主要的外部接口。在这里,不要求对接口详细地描述,详细描述放在SRS其他章条中;
(3)描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。
在本条的描述中,用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
本条既不用来强迫进行设计方案的描述,也不是描述在解决问题时的设计约束。本条应对在以后具体需求一章中说明的设计约束提供理由。
6.2.2 产品功能(SRS的2.2条)
本条是为将要完成的软件功能提供一个摘要。例如,对于一个记帐程序来说,SRS可以用这部分来描述:客户帐目维护、客户财务报表和发票制作,而不必把功能所要求的大量的细节描写出来。
有时,如果存在较高层次的规格说明时,则功能摘要可直接从中取得,这个较高层次的规格说明为软件产品分配了特殊的功能,为了清晰起见,请注意:
a. 编制功能的一种方法是制作功能表,以便客户或者第一次读这个文件的人都可以理解;
b. 用方框图来表达不同的功能和它们的关系也是有帮助的。但要牢记,这样的图不是产品设计时所需求的,而只是一种有效的解释性的工具。
这一条不用作陈述具体需求,只是对后来SRS中具体需求一章中为什么要描述的某些需求提供理由。
6.2.3 用户特点(SRS的2.3条)
本条要描述影响具体需求的产品的最终用户的一般特点。
许多人在软件生存周期的操作和维护阶段与系统相关。而这些人中有用户、操作员、维护人员和系统工作人员。这些人的某些特点,象教育水平、经验、技术、专长等,都是施加于系统操作环境的重要约束。
如果系统的大多数用户是一些临时用户,那么就要求系统包含如何完成基本功能的提示,而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
这一条的内容不能用来陈述具体需求或强加若干特殊的设计约束,本条应对在SRS的具体需求一章之中的某些具体需求或设计约束的描述提供理由。
6.2.4 一般约束(SRS的2.4条)
本条对设计系统阳限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括:
a. 管理方针;
b. 硬件的限制;
c. 与其他应用间的接口;
d. 并行操作;
e. 审查功能;
f. 控制功能;
g. 所需的高级语言;
h. 通信协议;
i. 应用的临界点;
j. 安全和保密方面的考虑。
本条不陈述具体需求或具体设计约束:而对SRS的具体需求一章中为 什么要确定某些具体需求和设计约束提供理由。
6.2.5 假设和依据(SRS的2.5条)
本条列出影响SRS中陈述的需求的每一个因素。这些因素不是软件的设计约束,但是它们的改变可能影响到SRS中的需求。例如:假定一个特定的操作系统是在被软件产品指定的硬件上使用的,然而,事实上这个操作系统是不可能使用的,于是,SRS就要进行相应的改变。
6.3 具体需求(SRS的第3章)
本章应包括软件开发者在建立设计时需要的全部细节。这是SRS中篇幅最大和最重要的部分。
a. 根据本指南第4章所规定的准则(如可验证性、无歧义性等),对每一个需求细节作具体描述;
b. 在SRS的前言、项目概述、附录部分的有关讨论中,要提供对任何一个具体需求交叉引用的背景;
c. 具体需求分类的方法如下:
(1)功能需求;
(2)性能需求;
(3)设计约束;
(4)属性;
(5)外部接口需求。
本章中要注意的二点是:
a. 按符合逻辑的和可读的方式组织;
b. 详细描述每一个需求,使得该需求应达到目标能够用指定的方法进行客观的验证。
6.3.1 具体需求的内容
6.3.1.1 功能需求
本条描述软件产品的输入怎样变换成输出。即软件必须完成的基本动作。
对于每一类功能或者有时对于每一个功能,需要具体描述其输入、加工和输出的需求。这通常由四个部颁组成:
a. 引言
这部分描述的是功能要达到的目标、所采用的方法和技术,还应清楚说明功能意图的由来和背景。
b. 输入
这部分应包括:
(1)详细描述该功能的所有输入数据,如:
输入源、数量、度量单位、时间设定、有效输入范围(包括精度和公差);
(2)操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如:当打印检查时,要求操作员进行格式调整;
(3)指明引用接口说明或接口控制文件的参考资料。
c. 加工
定义输入数据、中间参数,以获得预期输出结果的全部操作。它包括如下的说明:
(1)输入数据的有效性检查;
(2)操作的顺序,包括事件的时间设定;
(3)异常情况的响应,例如,溢出、通信故障、错误处理等;
(4)受操作影响的参数;
(5)降级运行的要求;
(6)用于把系统输入变换成相应输出的任何方法(方程式、数学算法、逻辑操作等);
(7)输出数据的有效性检查。
d. 输出
这部分应包括:
(1)详细描述该功能所有输出数据,例如:输出目的地、数量、度量单位、时间关系、有效输出的范围(包括精度和公差)、非法值的处理、出错信息;
(2)有关接口说明或接口控制文件的参考资料。
此外,对着重于输入输出行为的系统来说,SRS应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时,需要这个序列,使得它可以根据本次输入和以前的状态作出响应。也就是说,这种情况犹如有限状态机。 6.3.1.3 设计约束
设计约束受其他标准、硬件限制等方面的影响。
6.3.1.3.1 其他标准的约束
本项将指定由现有的标准或规则派生的要求。例如:
a. 报表格式;
b. 数据命名;
c. 财务处理;
d. 审计追踪,等等。
6.3.1.3.2 硬件的限制
本项包括在各种硬件约束下运行的软件要求,例如,应该包括:
a. 硬件配置的特点(接口数,指令系统等);
b. 内存储器和辅助存储器的容量。
6.3.1.4 属性
在软件的需求之中有若干个属性,下面指出其中的几个(注意:对这些决不应理解为是一个完整的清单)。
6.3.1.4.1 可用性
可以指定一些因素,如检查点、恢复和再启动等,以保证整个系统有一个确定的可用性级别。
6.3.1.4.2 安全性
这里指的是保护软件的要素,以防止各种非法的访问、使用,修改、破坏或者泄密。这个领域的具体需求必须包括:
a. 利用可靠的密码技术;
b. 掌握特定的记录或历史数据集;
c. 给不同的模块分配不同的功能;
d. 限定一个程序中某些区域的通信;
e. 计算临界值的检查和。
6.3.1.4.3 可维护性
这里规定若干需求以确保软件是可维护的。例如:
a. 软件模块所需要的特殊的耦合矩阵;
b. 对微型装置指定特殊的数据/程序分割要求。
4.6 SRS的编制工具
编制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”来回答。显然,要列出全部输入和输出序列是不可能的。然而,用典型的序列可以十分清楚地理解系统的特性。下面是一组四种对话的典型的例子,用它描述系统特性。
0101
010101010101
01
010101
这些对话仅提供了要求的输入和输出之间的关系,但是不能完全描述系统的特性。
5.1.3 模型
另一种表达需求的方法是模型的方式,这是表达复杂需求的精确和有效方法。
至少可以提出三种可供使用的通用模型:数学型、功能型、计时型。
应注意区别各种模型的应用场合,参考5.1.3.5。
5.1.3.1 数学模型
数学模型是使用数学关系描述软件特性的模型。数学模型对某些特殊应用领域是特别有用的。例如,导航、线性规划、计量经济、信号处理和气象分析等。
用数学模型能够对5.1.2中所讨论的典型例子描述如下:
(01)*。
这里,“*”号表示括号内的字符串可以重复一次或多次。
5.1.3.2 功能模型
功能模型是提供从略语以输出映象的模型。象有限状态机或Petri网,这些功能模型可以有助于标识和定义软件的各种特点,或者可以表示系统所要进行的操作。
对前面用数学模型描述的例子。可用图1所示的有限状态机形式的功能模型来描述。图中进入的箭头表示启动状态。双线的方框表示接收状态。在各线记号x/y的含义是:x代表接受的输入,而y是产生的输出。
5.1.3.3 计时模型
计时模型是一种增加了时间限制的模型。这种模型对于表达软件特性的形式和细节特别有用。尤其是实时系统或考虑人为因素的系统。
计时模型可以把下列限制加到图1的模型中去:
a. 激活因素0将在进入S1状态30S之内出现;
b. 响应1将在进入S2状态2S之内出现。
5.1.3.4 其他模型
队了上面提及的模型外。对一些特殊的应用还有一些特别有用的模型。例如,编译程序的说明可以使用属性文法,工资单系统可以使用表格。要注意的是,对SRS使用形式需求语言,通常含有使用特殊模型的意思。
5.1.3.5 警告
无论使用哪一类型的模型,都要:
在SRS中或在SRS涉及到的一个文件中对它严格定义。这个定义应该规定:
a. 模型中的参数所要求的范围;
b. 使用时的限定值;
c. 结果的精确度;
d. 负载的能力;
e. 要求的执行时间;
f. 缺省或失败时的响应。
必须注意,在需求的定义域内要保持一个模型定义。每当一个SRS使用一个模型时:
a. 它意味着此模型提供一个十分有效和精确的方法说明需求;
b. 并不意味着软件产品的实现必须基于这个模型。
一个模型用于解释文件所写的需求是有效的,但是对于实际软件的实现可能并不是最适宜的。
5.2 软件需求的注释
有关软件产品的所有需求,并不是同等重要的。某些需求可能是基本的,例如是对于生命攸关的应用。而另一些可能并不那么重要。
SRS中每一个需求必须进行注释,以便区别其重要的程度。
有这种方法注释需求,可以:
a. 帮助客户对每一个需求给予更周密的考虑,通常可以在需求中澄清隐藏的假设;
b. 帮助开发者做出正确的设计决定,并对软件产品不同部分作出相应的努力。
5.2.1 稳定性
注释需求的一种方法是使用稳定性量纲。当一个需求在软件预期的生存期间内描述不改变的话,可以认为该需求是稳定的,否则可以认为是易变的。
5.2.2 必要性等级
注释的另一种方法是把需求分成必须保证级、期望级和任选级。
a. 必须保证是指软件必须和这些需求相一致,否则该软件不可能被接受;
b. 期望是指这些需求将提高软件产品的功能,但是如果缺省的话也是可接受的;
c. 任选是给开发者一个机会,可以提供某些超出SRS规定的目标。
5.2.3 注意事项
在注释需求之前,必须彻底理解这种注释的实质性含义。
5.3 在表达需求时遇到的共同弊病
SRS的基本点是它必须说明由软件获得的结果,而不是获得这些结果的手段。
编写需求的人必须描述的基本问题是:
a. 功能——所设计的软件要做什么;
b. 性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等;
c. 强加于实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准;
d. 属性——可移植性、正确性、可维护性及安全性等方面的考虑因素;
e. 外部接口——与人、硬件、其他软件和其他硬件的相互关系。
编写需求的人应当避免把设计或项目需求写入SRS之中,应当对说明需求设计约束与规划设计两者有清晰的区别。
5.3.1 在SRS中嵌入了设计
在SRS中嵌入设计说明,会过多地约束软件设计,并且人为地把具有潜在危险的需求放入SRS中。
5.3.1.1 SRS必须描述在干什么数据上、为谁完成什么功能、在什么地方、产生什么结果。SRS应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目:
a. 把软件划分成若干模块;
b. 给每一个模块分配功能;
c. 描述模块间的信息流程或者控制流程;
d. 选择数据结构。
5.3.1.2 把设计完全同SRS隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求。例如:
a. 在一些分散的模块中保持某些功能;
b. 允许在程序的某些区域之间进行有限的通讯;
c. 计算临界值的检查和。
5.3.1.3 通常应考虑到,若要为软件选择高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上)。有两种选择:
a. 不顾本指南的警告,在SRS中描述了设计。这意味着,或者将一个潜在不适当的设计作为一个需求进行描述(因为,若要得到好的设计,所花费的时间是不够的),或者在需求阶段花费了过多的时间(因为在SRS完成之前整个设计分析都要完成);
b. 采用本指南中5.1.3条中的建议,用模型设计描述需求,这种模型设计只用于辅助描述需求,而不使之成为实际的设计。
5.3.2 在SRS中嵌入了一些项目要求
SRS应当是描写一个软件产品,而不是描述生产软件产品的过程。
项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解(因此不应当包括在SRS中)例如:
a. 成本;
b. 交货进度;
c. 报表处理;
d. 软件开发方法;
e. 质量保证;
f. 确认和验证的标准;
g. 验收过程。
项目需求在另外的文件中描述。在SRS中提供的只是关于软件产品本身的需求。