📄 115.htm
字号:
S 的缺陷、缺点和错误之类的问题，所以可能要对sKs进行改进。 在SR S的改进中，应注意如下事项：<BR>4．5．1尽管可以预见校正版本在开发以后不可避免，而对需求还必须尽可能完全、清楚地描述。<BR>4．5．2一旦最初识别出项目的变化，应引人一个正式的改变规程来标识、控制、追踪和报告项目的
改变。批准了的需求改变，用如下的方法编人SRS之中：<BR>
a．提供各种改变后的正确的、完全的审查记录；<BR>
b．允许对SRS当前的和被替代部分的审查。<BR><STRONG>4．6
SRS的编制工具 <A name=4.6></A><BR></STRONG> 编制SRS最显而易见的方法是用自然语言来描述。尽管自然语言是丰富多彩的，但不易精确，
用形式化的方法较好。<BR><STRONG>4．6．I形式化说明方法 <A
name=4.6.1></A></STRONG><BR> 在SRS中是否使用形式化方法要依据下列因素： <BR>
a．程序规模和复杂性； <BR> b．客户合同中是否要求使用；<BR> c. SRS是否是一个合同工具或仅仅是一个内部文件；<BR> d．SRS文件是否成为设计文件的根据；<BR>
e．具有支持这种方法的计算机设备。 <STRONG><BR></STRONG><STRONG>4．6．2生产工具 <A
name=4.6.2></A><BR></STRONG>
软件产品生产中有多种生产工具。比如，计算机的字处理器就是非常有用的生产辅助工具。一个 SR
S通常有若干作者。可能经历若干版本，并且要进行多次重新组织内容。故生产工具是必要的。<BR><STRONG>4．6．3表达工具<A
name=4.6.3></A><BR></STRONG>
在SRS中有许多词汇，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所以表 达 SR S需要若干工具。比如： <BR> a．可以验证实体或活动，无论在 SR S中什么地方都是同一名字，<BR> b．可以标识一个特殊的实体或动作在规格说明中的描述位置。
此外，可以使用若干种形式化方法，以便允许自动处理SRS内容，只要作某些限制就可以做到： 用一些表格或图示法来显示需求。 用详细分层体系自动检查SR
S的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层，或是上一层的一个组成成分。<BR> 自动检查
SR S具有在 4． 3条描述的部分或全部特点。<BR><STRONG>5
软件需求 <A name=5></A><BR></STRONG>
SRS中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。<BR><STRONG>5．1表达软件需求的方法 <A
name=5.1></A></STRONG><BR> 软件需求可以用若干种方法来表达：<BR> a．通过输人、输出说明； <BR> b．使用代表性的例子; <BR>
c．用规范化的模型。<BR><STRONG>5．1．1输人、</STRONG>输出说明<A name=5.1.1></A><BR> 用输人输出序列来描述一个软件产品所要求的特性是很有效的。 <BR>5．1．1．1途径<BR>
根据被描述的软件的性质，至少有三种不同的途径：<BR>
a．有些软件产品（如报表系统）要求着重说明输出。一般情况下，致力于输出的系统主要是在数据文卷上操作。用户的输人通常是致力于提供控制信息和启动数据文卷的处理；<BR>
b．有些软件产品需要着重说明输人、输出特性。关注输入、输出的系统主要是在当前的输入上操作，要求生成与输人相匹配的输出（类似于数据转换例行程序或一个数学函数包）；<BR>
c．还有一些系统（如过程控制系统）要求记忆它们的状态。可以根据本次输人和上一次输人进行应答。也就是说，它的行为如同一个有限状态机。在此种情况下，既要关注输人／输出对，又要关注这些输人／输出对的次序。
<BR>5．1．1.2困难 <BR>
多数软件产品可能接收无限的序列作为输人，于是，为了通过输入输出序列完整地说明产品的特．性，就要求SR
S包括一个无限长的输人和所需的输出序列。并而，用这样的途径不可能完整地描述软件所要求的一切特性。 <BR><STRONG>5．1．2典型例子 <A
name=5.1.2></A><BR></STRONG>
一种选择是用典型例子来说明要求的特性。例如，假设一个系统中当接收“ 0”时用“
1”来回答。显然，要列出全部输人和输出序列是不可能的。然而，用典型的序列可以十分清楚地理解系统的特性。下面是一组四种对话的典型的例子，用它描述系统特性。<BR> 0101<BR>
010101010101<BR> 01 <BR> 010101<BR>
这些对话仅提供了要求的输人和输出之间的关系，但是不能完全描述系统的特性。<BR><STRONG>5．1．3模型<A
name=5.1.3></A><BR></STRONG>
另一种表达需求的方法是模型的方式，这是表达复杂需求的精确和有效的方法。<BR>
至少可以提出三种可供使用的通用模型：数学型、功能型、计时型。<BR>
应注意区别各种模型的应用场合，参考5．1．3．5。
<BR><STRONG>5. 1．3．I数学模型<A name=5.1.3.1></A><BR></STRONG>
数学模型是使用数学关系描述软件特性的模型。数学模型对某些特殊应用领域是特别有用的。例如，导航、线性规划、计量经济、信号处理和气象分析等。<BR> 用数学模型能够对5．1．2中所讨论的典型例子描述如下：<BR> （ 01）* <BR>
这里，“*”号表示括号内的字符串可以重复一次或多次。<BR><STRONG>5．1．3．2功能模型<A
name=5.1.3.2></A><BR></STRONG>
功能模型是提供从输人到输出映象的模型。象有限状态机或Petri网，这些功能模型可以有助于标识和定义软件的各种特点，或者可以表示系统所要进行的操作。<BR>
对前面用数学模型描述的例子。可用图互所示的有限状态机形式的功能模型来描述。图中进人的箭头表示启动状态。双线的方框表示接收状态。在各线记号x／y的含义是：x代表接受的输人，而
y是产生的输出。<BR>
<IMG alt="" src="120.gif"><BR> <BR>
图1<BR><STRONG>5.1．3．3计时模型<A name=5.1.3.3></A></STRONG><BR>
计时模型是一种增加了时间限制的模型。这种模型对于表达软件特性的形式和细节特别有用。尤其是实时系统或考虑人为因素的系统。<BR> 计时模型可以把下列限制加到图1的模型中去：<BR>
a．激活因素 0将在进人 SI状态 30 s之内出现；<BR>
b．响应1将在进人SZ状态2s之内出现。<BR><STRONG>5．1．3．4其他模型 <A
name=5.1.3.4></A></STRONG><BR>
除了上面提及的模型外。对一些特殊的应用还有一些特别有用的模型。例如，编译程序的说明可。以使用属性文法，工资单系统可以使用表格。要注意的是，对SRS使用形式需求语言，通常含有使。用特殊模型的意思。
<BR><STRONG>5．1．3．5警告<A name=5.1.3.5></A><BR></STRONG>
无论使用哪一类型的模型，都要：<BR>
在SRS中或在SRS涉及到的一个文件中对它严格定义。这个定义应该规定：<BR>
a.模型中的参数所要求的范围；<BR> b．使用时的限定值，<BR> c．结果的精确度； <BR> d．负载的能力；
<BR> e．要求的执行时间。 <BR> f．缺省或失败时的响应。<BR> 必须注意，在需求的定义域内要保持一个模型定义。每当一个SRS使用一个模型时；<BR> a．它意味着此模型提供一个十分有效和精确的方法说明需求；<BR> b．并不意味软件产品的实现必须基于这个模型。 <BR>
一个模型用于解释文件所写的需求是有效的，但是对于实际软件的实现可能并不是最适宜的。<BR><STRONG>5．2软件需求的注释 <A
name=5.2></A></STRONG><BR>
有关软件产品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是对于生命攸关的应用。而另一些可能并不那么重要。<BR> SR S中每一个需求必须进行注释，以便区别其重要的程度。 <BR> 用这种方法注释需求，可以： <BR>
a.帮助客户对每一个需求给予更周密的考虑，通常可以在需求中澄清隐藏的假设；<BR>
b．帮助开发者做出正确的设计决定，并对软件产品不同部分作出相应的努力。<BR><STRONG>5．2．1稳定性<A
name=5.2.1></A><BR></STRONG>
注释需求的一种方法是使用稳定性量纲。当一个需求在软件预期的生存期间内描述不改变的话，可以认为该需求是稳定的，否则可以认为是易变的。<BR><STRONG>5．2．2必要性等级<A
name=5.2.2></A><BR></STRONG>
注释的另一种方法是把需求分成必须保证级、期望级和任选级。 <BR>
a.必须保证是指软件必须和这些需求相一致，否则该软件不可能被接受；<BR>
b．期望是指这些需求将提高软件产品的功能，但是如果缺省的话也是可接受的；<BR>
c．任选是给开发者一个机会，可以提供某些超出SRS规定的目标。<BR><STRONG>5．2．3注意事项 <A
name=5.2.3></A></STRONG><BR> 在注释需求之前，必须彻底理解这种注释的实质性含义。<BR><STRONG>5．3在表达需求时遇到的共同弊病 <A
name=5.3></A></STRONG><BR>
SRS的基本点是它必须说明由软件获得的结果，而不是获得这些结果的手段。 编写需求的人必须描述的基本问题是： <BR> a．功能——所设计的软件要做什么；<BR>
b．性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；
<BR>
c．强加于实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；
<BR> d．属性——可移植性、正确性、可维护性及安全性等方面的考虑因素；<BR> e．外部接口——与人、硬件、其他软件和其他硬件的相互关系。<BR> 编写需求的人应当避免把设计或项目需求写人SRS之中，应当对说明需求设计约束与规划设计
两者有清晰的区别。<BR><STRONG>5．3．1在SRS中嵌人了设计
<A name=5.3.1></A></STRONG><BR> 在 S R S中嵌人设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需求放人SR S 中。 <BR>5.3.1.1 SR S必须描述在什么数据上、为谁完成什么功能、在什么地方、产生什么结果。 S R
S应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目：<BR>
a．把软件划分成若干模块，<BR> b．给每一个模块分配功能；<BR> c．描述模块间的信息流程或者控制流程；<BR>
d．选择数据结构。<BR>5．3．1．2把设计完全同SRS隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求。例如：<BR> a．在一些分散的模块中保持某些功能；<BR> b．允许在程序的某些区域之间进行有限的通讯；<BR>
c．计算临界值的检查和。 <BR>5．3．1．3通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可能占整个产品开发成本的10％一20 ％以上）。有两种选择：<BR> a．不顾本指南的警告，在 SR
S中描述了设计。这意味着，或者将一个潜在不适当的设计作为一个需求进行描述（因为，若要得到好的设计，所花费的时间是不够的），或者在需求阶段花费了过多的时间（因为在SRS完成之前整个设计分析都要完成）；
<BR>
b．采用本指南中5．1．3条中的建议，用模型设计描述需求，这种模型设计只用于辅助描述需求，而不使之成为实际的设计。 <A
name=5.3.2></A><BR><STRONG>5．3．2在SRS中嵌入了一些项目要求 <A
name=5.3.2></A></STRONG><BR> SRS应当是描写一个软件产品，而不是描述生产软件产品的过程。
项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解（因此不应当包括在SR S 中）例如：<BR> a．成本；<BR> b．交货进度； <BR> c．报表处理； <BR>
d．软件开发方法；<BR> e．质量保证； <BR> f．确认和验证的标准；<BR> g．验收过程。 <BR> 项目需求在另外的文件中描述。在SRS中提供的只是关于软件产品本身的需求。<BR><STRONG>6 SRS大纲
<A name=6></A><BR></STRONG>
本章着重讨论SRS的每一个基本部分，可以作为一个SRS的大纲。表1给出该大纲目录，表
2至表5给出大纲中第3章的具体需求内容。各开发者和客户应当根据所描述的实际情况，按本指南有关规定编写自己的SRS。<BR>
<BR> 表1
SRS 大纲
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -