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

1、2022-6-61GB-T9385-1988计算机软件需求说明编制指南主讲主讲: : 朱朱 贵贵 良良 软件工程第软件工程第5 5讲讲2022-6-62善意的提示!n需求分析是软件开发的第需求分析是软件开发的第1 1步步n软件错位的软件错位的60%60%源于需求分析源于需求分析n需求分析解决干什么需求分析解决干什么, ,不解决怎么干的问题不解决怎么干的问题nGBGB是技术立法是技术立法, ,人人必须遵守人人必须遵守n需求分析阶段的最终成果是形成需求分析报告需求分析阶段的最终成果是形成需求分析报告! !2022-6-631 引言引言1.1 1.1 目的和作用目的和作用 本指南为软件需求实践提供了

2、一个规范化的方法。本指南不提倡本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明（把软件需求说明（Software Requirements Specifications，以下简，以下简称称SRS）划分成等级，避免把它定义成更小的需求子集。）划分成等级，避免把它定义成更小的需求子集。 本指南适用对象：本指南适用对象： 软件客户（软件客户（Customers），以便精确地描述他们想获得什么样的产品。），以便精确地描述他们想获得什么样的产品。 软件开发者（软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。），以便准确地理解客户需要什么样的产品。 对于任一要实

3、现下列目标的单位和（或）个人：对于任一要实现下列目标的单位和（或）个人： a. 要提出开发规范化的要提出开发规范化的SRS提纲；提纲； b. 定义自己需要的具体的格式和内容；定义自己需要的具体的格式和内容； c. 产生附加的局部使用条款，如产生附加的局部使用条款，如SRS质量检查清单或者质量检查清单或者SRS作者手册作者手册 等。等。 2022-6-641 引言引言 SRS将完成下列目标：将完成下列目标： a. 在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是

4、否础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求；符合他们的要求，或者怎样修改这种软件才能适合他们的要求； b. 提高开发效率。编制提高开发效率。编制SRS的过程将使客户在设计开始之前周密地思考全的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；错误的理

5、解和不一致性，以便及时加以纠正； c. 为成本计价和编制计划进度提供基础。为成本计价和编制计划进度提供基础。SRS提供的对被开发软件产品的提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。费提供依据。SRS对软件的清晰描述，有助于估计所必须的资源，并用对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；作编制进度的依据； 2022-6-651 引言引言 d. 为确认和验证提供一个基准。任何组织将更有效地编制他们的为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验

6、证计划。作为开发合同的一部分，确认和验证计划。作为开发合同的一部分，SRS还可以提供一还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为软件的合同都不能作为SRS。因为这种文件几乎不包括详尽的。因为这种文件几乎不包括详尽的需求说明，并且通常不完全的）；需求说明，并且通常不完全的）； e. 便于移植。有了便于移植。有了SRS就便于移值软件产品，以适应新的用户或就便于移值软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部门，而开发者同样新的机种。客户也易于移植其软件到其他部门，而开发者同样也易于

7、把软件移植到新的客户；也易于把软件移植到新的客户； f. 作为不断提高的基础。由于作为不断提高的基础。由于SRS所讨论的是软件产品，而不是所讨论的是软件产品，而不是开发这个产品的设计。因此开发这个产品的设计。因此SRS是软件产品继续提高的基础。是软件产品继续提高的基础。虽然虽然SRS也可能要改变，但是原来的也可能要改变，但是原来的SRS还是软件产品改进的还是软件产品改进的可靠基础。可靠基础。 2022-6-661 引言引言 1.2 范围范围 本指南适用于编写软件需求规格说明，它本指南适用于编写软件需求规格说明，它描述了一个描述了一个SRS所必须的内容和质量，所必须的内容和质量，并且在第并且在第

8、6章中提供了章中提供了SRS大纲。大纲。 2022-6-672 引用标准引用标准 GB 8566 计算机软件开发规范计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南计算机软件产品开发文件编制指南GB/T 11457 软件工程术语软件工程术语 2022-6-683 定义定义 GB/T 11457所列术语和下列定义适用于本指南。所列术语和下列定义适用于本指南。 合同（合同（contract） 是由客户和开发者共同签署的具有法律约束力的文件。是由客户和开发者共同签署的具有法律约束力的文件。其中包括产品的技术、组织、成本和进度计划要求等其中包括产品的技术、组织、成本和进度计划要求等内

9、容。内容。 客户（客户（customer） 指个人或单位，他们为产品开发提供资金，通常（但指个人或单位，他们为产品开发提供资金，通常（但有时也不必）还提出各种需求。文件中的客户和开发有时也不必）还提出各种需求。文件中的客户和开发者也可能是同一个组织的成员。者也可能是同一个组织的成员。 语言（语言（language） 是具有语法和语义的通信工具，包括一组表达式、惯是具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。例和传递信息的有关规则。 2022-6-693 定义定义 分割（分割（partitioning） 把一个整体分成若干部分。把一个整体分成若干部分。开发者（开发者（su

10、pplier） 指为客户生产某种软件产品的个人或集团。在指为客户生产某种软件产品的个人或集团。在本指南中，客户和开发者可能是同一个组织的本指南中，客户和开发者可能是同一个组织的成员。成员。 用户（用户（user） 指运行系统或者直接与系统发生交互作用的个指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。人或集团。用户和客户通常不是同一些人。 2022-6-6104 编写编写SRS的背景信息的背景信息 4.1 SRS的基本要求的基本要求 SRS是对要完成一定功能、性能的软件产品、是对要完成一定功能、性能的软件产品、程序或一组程序的说明。程序或一组程序的说明。 对对SR

11、S的描述有两项基本要求：的描述有两项基本要求： a. 必须描述一定的功能、性能；必须描述一定的功能、性能； b. 必须用确定的方法叙述这些功能、性能。必须用确定的方法叙述这些功能、性能。 2022-6-6114 编写编写SRS的背景信息的背景信息 4.2 SRS的环境的环境 必须认识到必须认识到SRS在整个软件开发规范（见在整个软件开发规范（见GB 8566）所规定的有关阶段都起作用。正因为）所规定的有关阶段都起作用。正因为如此，如此，SRS的起草者必须特别注意不要超出这的起草者必须特别注意不要超出这种作用的范围。这意味着要满足下列要求：种作用的范围。这意味着要满足下列要求： a. SRS必须

12、正确地定义所有的软件需求；必须正确地定义所有的软件需求； b. 除了设计上的特殊限制之外，除了设计上的特殊限制之外，SRS中一般不描中一般不描述任何设计、验证或项目管理细节。述任何设计、验证或项目管理细节。 2022-6-6124 编写编写SRS的背景信息的背景信息4.3 SRS的特点的特点 4.3.1 无歧义性无歧义性 当且仅当它对每一个需求只有一种解释时，当且仅当它对每一个需求只有一种解释时，SRSSRS者是无者是无歧义的。歧义的。 a.a.要求最终产品的每一个特性用某一术语描述；要求最终产品的每一个特性用某一术语描述； b.b.若某一术语在某一特殊的行文中使用时具有多种歧若某一术语在某一

13、特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场义，那么对该术语的每种含义作出解释并指出其适用场合。合。 需求通常是用自然语言编写的，使用自然语言的需求通常是用自然语言编写的，使用自然语言的SRSSRS起草者必须特别注意消除其需求的歧义性。提倡使用形起草者必须特别注意消除其需求的歧义性。提倡使用形式化需求说明语言式化需求说明语言。 2022-6-6134 编写编写SRS的背景信息的背景信息4.3.2 完整性完整性 如果一个如果一个SRS能满足下列要求，则该能满足下列要求，则该SRS就是完整的：就是完整的： a. 包括全部有意义的要求，无论是关系到功能的、性能包括全部

14、有意义的要求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的的、设计约束的，还是关系到属性或外部接口方面的需求；需求； b. 对所有可能出现的输入数据的响应予以定义，要对合对所有可能出现的输入数据的响应予以定义，要对合法和非合法的输入值的响应做出规定；法和非合法的输入值的响应做出规定； c. 要符合要符合SRS要求。如果个别章节不适用，则在要求。如果个别章节不适用，则在SRS中中要保留章节号；要保留章节号； d. 填写填写SRS中的全部插图、表、图示标记和参照，并且中的全部插图、表、图示标记和参照，并且定义全部术语和度量单位。定义全部术语和度量单位。 2022-6-61

15、44 编写编写SRS的背景信息的背景信息注意：关于使用注意：关于使用“待定待定”一词的规定一词的规定 任何一个使用任何一个使用“待定待定”的的SRS都是不完全的。都是不完全的。 a. 若万一遇到使用若万一遇到使用“待定待定”一词时，作如下处理：一词时，作如下处理： （1） 对产生对产生“待定待定”一词的条件进行描述，使得一词的条件进行描述，使得问题能被解决；问题能被解决； （2） 描述必须干什么事，以删除这个描述必须干什么事，以删除这个“待定待定”； b. 包含有包含有“待定待定”一词的任何一词的任何SRS的项目文件应该：的项目文件应该： （1） 标识与此特定文件有关的版本号或叙述其专标识与此

16、特定文件有关的版本号或叙述其专门的发布号；门的发布号； （2） 拒绝任何仍标识为拒绝任何仍标识为“待定待定”一词的一词的SRS章节章节的许诺。的许诺。 2022-6-6154 编写编写SRS的背景信息的背景信息4.3.3 可验证性可验证性 当且仅当当且仅当SRS中描述的每一个需求都是可以验中描述的每一个需求都是可以验证的，该证的，该SRS才是可以验证的；当且仅当在某才是可以验证的；当且仅当在某一性能价格比可取的有限处理过程，人或机器一性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。才称这个需求是可以

17、验证的。 4.3.4 一致性一致性 当且仅当当且仅当SRS中各个需求的描述是不矛盾时中各个需求的描述是不矛盾时SRS才是一致的。才是一致的。 2022-6-6164 编写编写SRS的背景信息的背景信息4.3.5 可修改性可修改性 如果一个如果一个SRS的结构和风格在需求有必要改变时是易于实现的、完的结构和风格在需求有必要改变时是易于实现的、完整性的、一致的，那么这个整性的、一致的，那么这个SRS就是可以修改的。可修改性要求就是可以修改的。可修改性要求SRS具备以下条件：具备以下条件： a. 具有一个有条不紊的易于使用的内容组织，具有目录表，索引和具有一个有条不紊的易于使用的内容组织，具有目录表

18、，索引和明确的交叉引用表；明确的交叉引用表； b. 没有冗余。即同一需求不能在没有冗余。即同一需求不能在SRS中出现多次。中出现多次。 （1）冗余本身不是错误，但是容易发生错误。冗余可增加）冗余本身不是错误，但是容易发生错误。冗余可增加SRS的可的可读性，但是在一个冗余文件被更新时容易出现问题。例如：假设读性，但是在一个冗余文件被更新时容易出现问题。例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改一个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改一个地方，于是变，若只修改一个地方，于是SRS就变得不一致了。就变得不一致了。 （2）不管冗余是否必须，）不管冗余

19、是否必须，SRS一定要包含一个详细的交叉引用表，一定要包含一个详细的交叉引用表，以便以便SRS具备可修改性。具备可修改性。 2022-6-6174 编写编写SRS的背景信息的背景信息4.3.6 可追踪性可追踪性 如果每一个需求的源流是清晰的，在进一步产生和改如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该变文件编制时，可以方便地引证每一个需求，则该SRS就是可追踪的。建议采用如下两种类型的追踪：就是可追踪的。建议采用如下两种类型的追踪： a. 向后追踪（即向已开发过的前一阶段追踪）。根据先向后追踪（即向已开发过的前一阶段追踪）。根据先前文件或本文件前面

20、的每一个需求进行追踪。前文件或本文件前面的每一个需求进行追踪。 b. 向前追踪（即是向由向前追踪（即是向由SRS派生的所有文件追踪）。根派生的所有文件追踪）。根据据SRS中具有唯一的名字和参照号的每一个需求进行中具有唯一的名字和参照号的每一个需求进行踪。踪。 当当SRS中的一个需求表达另一个需求的一种指派中的一个需求表达另一个需求的一种指派或者是派生的，向前、向后的追踪都要提供。例如：或者是派生的，向前、向后的追踪都要提供。例如： 2022-6-6184 编写编写SRS的背景信息的背景信息（1）从总的用户响应时间需求中分配给数据）从总的用户响应时间需求中分配给数据库操作响应时间；库操作响应时间

21、； （2）识别带有一定功能和用户接口的需求的）识别带有一定功能和用户接口的需求的报告格式；报告格式； （3）支持法律或行政上需要的某个软件产品）支持法律或行政上需要的某个软件产品（例如，计算税收）。在这种情况下，要指出（例如，计算税收）。在这种情况下，要指出软件所支持的确切的法律或行政文件。软件所支持的确切的法律或行政文件。 当软件产品进入运行和维护阶段时，当软件产品进入运行和维护阶段时，SRS的向的向前可追踪性显得特别重要。当编码和设计文件前可追踪性显得特别重要。当编码和设计文件作修改时，重要的是要查清这些修改所影响的作修改时，重要的是要查清这些修改所影响的全部需求。全部需求。 2022-6

22、-6194 编写编写SRS的背景信息的背景信息4.3.7 运行和维护阶段的可使用性运行和维护阶段的可使用性 SRS必须满足运行和维护阶段的需要，包括软件最终替换。必须满足运行和维护阶段的需要，包括软件最终替换。 a. 维护常常是由与原来开发无联系的人来进行的。局部的改变（修正）可以借维护常常是由与原来开发无联系的人来进行的。局部的改变（修正）可以借助于好的代码注释来实现。对于较大范围的改变。设计和需求文件是必不可少助于好的代码注释来实现。对于较大范围的改变。设计和需求文件是必不可少的，这里隐含了两个作用：的，这里隐含了两个作用： （1）如）如4.3.5 条指出，条指出，SRS必须是可修改的；必

23、须是可修改的； （2）SRS中必须包括一个记录，它记录那些应用于各个成分的所有具体条文。中必须包括一个记录，它记录那些应用于各个成分的所有具体条文。 例如：例如： 它们的危急性（如故障可能危及完全或导致大量财政方面和社会方面的损它们的危急性（如故障可能危及完全或导致大量财政方面和社会方面的损失）；失）；它们仅与暂时的需要相关（如支持一种可立即恢复原状的显示）；它们仅与暂时的需要相关（如支持一种可立即恢复原状的显示）； 它们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。它们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。 b. 要求在要求在SRS中清楚地写明功能的来源和目的

24、，因为对功能的来源和引入该功中清楚地写明功能的来源和目的，因为对功能的来源和引入该功能的目的不清楚的话，通常不可能很好地完成软件的维护。能的目的不清楚的话，通常不可能很好地完成软件的维护。 2022-6-6204 编写编写SRS的背景信息的背景信息4.4 SRS的编制者的编制者 软件开发的过程是由开发者和客户双方同意开发什么样的软件协软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用议开始的。这种协议要使用SRS的形式，应该由双方联合起草。的形式，应该由双方联合起草。这是因为：这是因为： a. 客户通常对软件设计和开发过程了解较少，而不能写出可用的客户通常对软件设

25、计和开发过程了解较少，而不能写出可用的SRS； b. 开发者通常对于客户的问题和意图了解较少，从而不可能写出一开发者通常对于客户的问题和意图了解较少，从而不可能写出一个令人满意的系统需求。个令人满意的系统需求。 4.5 SRS的改进的改进 软件产品的开发过程中，在项目的开始阶段不可能详细说明某些软件产品的开发过程中，在项目的开始阶段不可能详细说明某些细节，在开发过程中可能发现细节，在开发过程中可能发现SRS的缺陷、缺点和错误之类的问的缺陷、缺点和错误之类的问题，所以可能要对题，所以可能要对SRS进行改进。进行改进。 在在SRS的改进中，应注意如下事项：的改进中，应注意如下事项： 2022-6-

26、6214 编写编写SRS的背景信息的背景信息4.5.1 尽管可以预见校正版本的开发以后不可避免，尽管可以预见校正版本的开发以后不可避免，而对需求还必须尽可能完全、清楚地描述。而对需求还必须尽可能完全、清楚地描述。 4.5.2 一旦最初识别出项目的变化，应引入一个正一旦最初识别出项目的变化，应引入一个正式的改变规程来标识、控制、追踪和报告项目的式的改变规程来标识、控制、追踪和报告项目的改变。批准了的需求改变，用如下的方法编入改变。批准了的需求改变，用如下的方法编入SRS之中：之中： a. 提供各种改变后的正确的、完全的审查记录；提供各种改变后的正确的、完全的审查记录； b. 允许对允许对SRS当

27、前的和被替代部分的审查。当前的和被替代部分的审查。 2022-6-6224 编写编写SRS的背景信息的背景信息4.6 SRS的编制工具的编制工具 编制编制SRS最显而易见的方法是用自然语言来描述。尽管自然语言是最显而易见的方法是用自然语言来描述。尽管自然语言是丰富多彩的，但不易精确，用形式化的方法较好。丰富多彩的，但不易精确，用形式化的方法较好。 4.6.1 形式化说明方法形式化说明方法 在在SRS中是否使用形式化方法要依据下列因素：中是否使用形式化方法要依据下列因素： a. 程序规模和复杂性；程序规模和复杂性； b. 客户合同中是否要求使用；客户合同中是否要求使用； c. SRS是否是一个合

28、同工具或仅仅是一个内部文件；是否是一个合同工具或仅仅是一个内部文件； d. SRS文件是否成为设计文件的根据；文件是否成为设计文件的根据； e. 具有支持这种方法的计算机设备。具有支持这种方法的计算机设备。 4.6.2 生产工具生产工具 软件产品生产中有多种生产工具。比如，计算机的字处理器就是非软件产品生产中有多种生产工具。比如，计算机的字处理器就是非常有用的生产辅助工具。一个常有用的生产辅助工具。一个SRS通常有若干作者。可能经历若干通常有若干作者。可能经历若干版本，并且要进行多次重新组织内容。故生产工具是必要的。版本，并且要进行多次重新组织内容。故生产工具是必要的。 2022-6-6234

29、 编写编写SRS的背景信息的背景信息4.6.3 表达工具表达工具 在在SRS中有许多词汇，特别是许多名词和动词，专门涉及到系统中有许多词汇，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所以表达的实体和许多活动，所以表达SRS需要若干工具。比如：需要若干工具。比如： a. 可以验证实体或活动，无论在可以验证实体或活动，无论在SRS中什么地方都是同一名字。；中什么地方都是同一名字。； b. 可以标识一个特殊的实体或动作在规格说明中的描述位置。可以标识一个特殊的实体或动作在规格说明中的描述位置。 此外，可以使用若干种形式化方法，以便允许自动处理此外，可以使用若干种形式化方法，以便允许自动处

30、理SRS内容，内容，只要作某些限制就可以做到；只要作某些限制就可以做到； 用一些表格或图示法来显示需求。用一些表格或图示法来显示需求。 用详细分层体系自动检查用详细分层体系自动检查SRS的需求，这里每一个分层自身是完的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层，或是上一层的一个组成成分。全的，但是也可以扩展为下一层，或是上一层的一个组成成分。 自动检查自动检查SRS具有在具有在4.3条描述的部分或全部特点。条描述的部分或全部特点。2022-6-6245 软件需求软件需求 SRS中每一个软件需求是要求开中每一个软件需求是要求开 发软件产品的某些基本功能和性发软件产品的某些基本功能和

31、性 能的一个陈述。能的一个陈述。 2022-6-6255 软件需求软件需求5.1 表达软件需求的方法表达软件需求的方法 软件需求可以用若干种方法来表达：软件需求可以用若干种方法来表达： a. 通过输入、输出说明；通过输入、输出说明； b. 使用代表性的例子；使用代表性的例子； c. 用规范化的模型。用规范化的模型。 2022-6-6265 软件需求软件需求5.1.1 输入、输出说明输入、输出说明 用输入输出序列来描述一个软件产品所要求的特性是很有效的。用输入输出序列来描述一个软件产品所要求的特性是很有效的。 1、途径、途径 根据被描述的软件的性质，至少有三种不同的途径：根据被描述的软件的性质，

32、至少有三种不同的途径： a. 有些软件产品（如报表系统）要求着重说明输出。有些软件产品（如报表系统）要求着重说明输出。 一般情况下，致力于输出的系统主要是在数据文卷上操一般情况下，致力于输出的系统主要是在数据文卷上操 作。用户的输入通常是致力于提供控制信息和启动数据作。用户的输入通常是致力于提供控制信息和启动数据 文卷的处理。文卷的处理。b. 有些软件产品需要着重说明输入、输出特性。关注有些软件产品需要着重说明输入、输出特性。关注 输入、输出的系统主要是在当前的输入上操作，要求生输入、输出的系统主要是在当前的输入上操作，要求生 成与输入相匹配的输出（类似于数据转换例行程序或一成与输入相匹配的输

33、出（类似于数据转换例行程序或一 个数学函数包）；个数学函数包）； 2022-6-6275 软件需求软件需求c. 还有一些系统（如过程控制系统）要求记忆它还有一些系统（如过程控制系统）要求记忆它们的状态。可以根据本次输入和上一次输入进们的状态。可以根据本次输入和上一次输入进行应答。也就是说，它的行为如同一个有限状行应答。也就是说，它的行为如同一个有限状态机。在此种情况下，既要关注输入态机。在此种情况下，既要关注输入/输出对，输出对，又要关注这些输入又要关注这些输入/输出对的次序。输出对的次序。 2、 困难困难 多数软件产品可能接收无限的序列作为输入，多数软件产品可能接收无限的序列作为输入，于是，

34、为了通过输入输出序列完整地说明产品于是，为了通过输入输出序列完整地说明产品的特性，就要求的特性，就要求SRS包括一个无限长的输入和包括一个无限长的输入和所需的输出充列。然而，用这样的途径不可能所需的输出充列。然而，用这样的途径不可能完整地描述软件所要求的一切特性。完整地描述软件所要求的一切特性。 2022-6-6285 软件需求软件需求5.1.2 典型例子典型例子 一种选择是用典型例子来说明要求的特性。例如，假一种选择是用典型例子来说明要求的特性。例如，假设一个系统中当接收设一个系统中当接收“0”时用时用“1”来回答。显然，要来回答。显然，要列出全部输入和输出序列是不可能的。然而，用典型列出全

35、部输入和输出序列是不可能的。然而，用典型的序列可以十分清楚地理解系统的特性。下面是一组的序列可以十分清楚地理解系统的特性。下面是一组四种对话的典型的例子，用它描述系统特性。四种对话的典型的例子，用它描述系统特性。 0101 010101010101 01 010101 这些对话仅提供了要求的输入和输出之间的关系，但这些对话仅提供了要求的输入和输出之间的关系，但是不能完全描述系统的特性。是不能完全描述系统的特性。 2022-6-6295 软件需求软件需求5.1.3 模型模型 另一种表达需求的方法是模型的方式，另一种表达需求的方法是模型的方式，这是表达复杂需求的精确和有效方法。这是表达复杂需求的精

36、确和有效方法。 至少可以提出三种可供使用的通用模型：至少可以提出三种可供使用的通用模型：数学型、功能型、计时型。数学型、功能型、计时型。 应注意区别各种模型的应用场合，参应注意区别各种模型的应用场合，参 考考5.1.3.5。 2022-6-6305 软件需求软件需求5.1.3.1 数学模型数学模型 数学模型是使用数学关系描述软件特性的模型。数学模型是使用数学关系描述软件特性的模型。数学模型对某些特殊应用领域是特别有用的。数学模型对某些特殊应用领域是特别有用的。例如，导航、线性规划、计量经济、信号处理例如，导航、线性规划、计量经济、信号处理和气象分析等。和气象分析等。 用数学模型能够对用数学模型

37、能够对5.1.2中所讨论的典型例子中所讨论的典型例子描述如下：描述如下： （01）*。 这里，这里，“*”号表示括号内的字符串可以重复号表示括号内的字符串可以重复一次或多次。一次或多次。 2022-6-6315 软件需求软件需求5.1.3.2 功能模型功能模型 功能模型是提供从略语以输出映象的模型。象功能模型是提供从略语以输出映象的模型。象有限状态机或有限状态机或Petri网，这些功能模型可以有网，这些功能模型可以有助于标识和定义软件的各种特点，或者可以表助于标识和定义软件的各种特点，或者可以表示系统所要进行的操作。示系统所要进行的操作。 对前面用数学模型描述的例子。可用图对前面用数学模型描述

38、的例子。可用图1所示所示的有限状态机形式的功能模型来描述。图中进的有限状态机形式的功能模型来描述。图中进入的箭头表示启动状态。双线的方框表示接收入的箭头表示启动状态。双线的方框表示接收状态。在各线记号状态。在各线记号x/y的含义是：的含义是：x代表接受代表接受的输入，而的输入，而y是产生的输出。是产生的输出。 2022-6-6325 软件需求软件需求5.1.3.3 计时模型计时模型 计时模型是一种增加了时间限制的模型。这种计时模型是一种增加了时间限制的模型。这种模型对于表达软件特性的形式和细节特别有用。模型对于表达软件特性的形式和细节特别有用。尤其是实时系统或考虑人为因素的系统。尤其是实时系统

39、或考虑人为因素的系统。 计时模型可以把下列限制加到图计时模型可以把下列限制加到图1的模型中去：的模型中去： a. 激活因素激活因素0将在进入将在进入S1状态状态30S之内出现；之内出现； b. 响应响应1将在进入将在进入S2状态状态2S之内出现。之内出现。 2022-6-6335 软件需求软件需求5.1.3.4 其他模型其他模型 队了上面提及的模型外。对一些特殊的队了上面提及的模型外。对一些特殊的应用还有一些特别有用的模型。例如，应用还有一些特别有用的模型。例如，编译程序的说明可以使用属性文法，工编译程序的说明可以使用属性文法，工资单系统可以使用表格。要注意的是，资单系统可以使用表格。要注意的

40、是，对对SRS使用形式需求语言，通常含有使使用形式需求语言，通常含有使用特殊模型的意思。用特殊模型的意思。 2022-6-6345 软件需求软件需求5.1.3.5 警告警告 无论使用哪一类型的模型，都要：无论使用哪一类型的模型，都要： 在在SRS中或在中或在SRS涉及到的一个文件中对它严格定义。涉及到的一个文件中对它严格定义。这个定义应该规定：这个定义应该规定： a. 模型中的参数所要求的范围；模型中的参数所要求的范围； b. 使用时的限定值；使用时的限定值； c. 结果的精确度；结果的精确度； d. 负载的能力；负载的能力； e. 要求的执行时间；要求的执行时间； f. 缺省或失败时的响应。

41、缺省或失败时的响应。 2022-6-6355 软件需求软件需求 必须注意，在需求的定义域内要保持一个模型定义。必须注意，在需求的定义域内要保持一个模型定义。每当一个每当一个SRS使用一个模型时：使用一个模型时： a. 它意味着此模型提供一个十分有效和精确的方法它意味着此模型提供一个十分有效和精确的方法说明需求；说明需求； b. 并不意味着软件产品的实现必须基于这个模型。并不意味着软件产品的实现必须基于这个模型。 一个模型用于解释文件所写的需求是有效的，但是一个模型用于解释文件所写的需求是有效的，但是对于实际软件的实现可能并不是最适宜的。对于实际软件的实现可能并不是最适宜的。 2022-6-63

42、65 软件需求软件需求5.2 软件需求的注释软件需求的注释 有关软件产品的所有需求，并不是同等重要的。某些有关软件产品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是对于生命攸关的应用。而需求可能是基本的，例如是对于生命攸关的应用。而另一些可能并不那么重要。另一些可能并不那么重要。 SRS中每一个需求必须进行注释，以便区别其重要的中每一个需求必须进行注释，以便区别其重要的程度。程度。 有这种方法注释需求，可以：有这种方法注释需求，可以： a. 帮助客户对每一个需求给予更周密的考虑，通常可以帮助客户对每一个需求给予更周密的考虑，通常可以在需求中澄清隐藏的假设；在需求中澄清隐藏的假设；

43、b. 帮助开发者做出正确的设计决定，并对软件产品不同帮助开发者做出正确的设计决定，并对软件产品不同部分作出相应的努力。部分作出相应的努力。 2022-6-6375 软件需求软件需求5.2.1 稳定性稳定性 注释需求的一种方法是使用稳定性量纲。当一个需求在软件预期注释需求的一种方法是使用稳定性量纲。当一个需求在软件预期的生存期间内描述不改变的话，可以认为该需求是稳定的，否则的生存期间内描述不改变的话，可以认为该需求是稳定的，否则可以认为是易变的。可以认为是易变的。 5.2.2 必要性等级必要性等级 注释的另一种方法是把需求分成必须保证级、期望级和任选级。注释的另一种方法是把需求分成必须保证级、期

44、望级和任选级。 a. 必须保证是指软件必须和这些需求相一致，否则该软件不可能被必须保证是指软件必须和这些需求相一致，否则该软件不可能被接受；接受； b. 期望是指这些需求将提高软件产品的功能，但是如果缺省的话也期望是指这些需求将提高软件产品的功能，但是如果缺省的话也是可接受的；是可接受的； c. 任选是给开发者一个机会，可以提供某些超出任选是给开发者一个机会，可以提供某些超出SRS规定的目标。规定的目标。 5.2.3 注意事项注意事项 在注释需求之前，必须彻底理解这种注释的实质性含义。在注释需求之前，必须彻底理解这种注释的实质性含义。 2022-6-6385 软件需求软件需求5.3 在表达需求

45、时遇到的共同弊病在表达需求时遇到的共同弊病 SRS的基本点是它必须说明由软件获得的结果，而不是获得这些结果的基本点是它必须说明由软件获得的结果，而不是获得这些结果的手段。的手段。 编写需求的人必须描述的基本问题是：编写需求的人必须描述的基本问题是： a. 功能功能所设计的软件要做什么；所设计的软件要做什么； b. 性能性能是指软件功能在执行过程中的速度、可使用性、响应时间、是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；各种软件功能的恢复时间、吞吐能力、精度、频率等等； c. 强加于实现的设计限制强加于实现的设计限制在效果、实现的语言、数据

46、库完整性、资在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；源限制、操作环境等等方面所要求的标准； d. 属性属性可移植性、正确性、可维护性及安全性等方面的考虑因素；可移植性、正确性、可维护性及安全性等方面的考虑因素； e. 外部接口外部接口与人、硬件、其他软件和其他硬件的相互关系。与人、硬件、其他软件和其他硬件的相互关系。 编写需求的人应当避免把设计或项目需求写入编写需求的人应当避免把设计或项目需求写入SRS之中，应当对说明之中，应当对说明需求设计约束与规划设计两者有清晰的区别。需求设计约束与规划设计两者有清晰的区别。 2022-6-6395 软件需求软件需求5.3

47、.1 在在SRS中嵌入了设计中嵌入了设计 在在SRS中嵌入设计说明，会过多地约束软件设计，并且人为地把具有潜在危中嵌入设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需求放入险的需求放入SRS中。中。 5.3.1.1 SRS必须描述在干什么数据上、为谁完成什么功能、在什么地方、必须描述在干什么数据上、为谁完成什么功能、在什么地方、产生什么结果。产生什么结果。SRS应把注意力集中在要完成的服务目标上。通常不指应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目：定如下的设计项目： a. 把软件划分成若干模块；把软件划分成若干模块； b. 给每一个模块分配功能；给每一个模块分配功

48、能； c. 描述模块间的信息流程或者控制流程；描述模块间的信息流程或者控制流程； d. 选择数据结构。选择数据结构。 5.3.1.2 把设计完全同把设计完全同SRS隔离开来始终是不现实的。安全和保密方面的周隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求。例如：密考虑可能增加一些直接反映设计约束的需求。例如： a. 在一些分散的模块中保持某些功能；在一些分散的模块中保持某些功能； b. 允许在程序的某些区域之间进行有限的通讯；允许在程序的某些区域之间进行有限的通讯； c. 计算临界值的检查和。计算临界值的检查和。 2022-6-6405 软件需求软件需求5.3

49、.1.3 通常应考虑到，若要为软件选择高层次的设计，通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可能占整个产品开发成本的就可能需要大量的资源（可能占整个产品开发成本的10%-20%以上）。有两种选择：以上）。有两种选择： a. 不顾本指南的警告，在不顾本指南的警告，在SRS中描述了设计。这意味着，中描述了设计。这意味着，或者将一个潜在不适当的设计作为一个需求进行描述或者将一个潜在不适当的设计作为一个需求进行描述（因为，若要得到好的设计，所花费的时间是不够（因为，若要得到好的设计，所花费的时间是不够的），或者在需求阶段花费了过多的时间（因为在的），或者在需求阶段花费了过多的时

50、间（因为在SRS完成之前整个设计分析都要完成）；完成之前整个设计分析都要完成）； b. 采用本指南中采用本指南中5.1.3条中的建议，用模型设计描述需求，条中的建议，用模型设计描述需求，这种模型设计只用于辅助描述需求，而不使之成为实这种模型设计只用于辅助描述需求，而不使之成为实际的设计。际的设计。 2022-6-6415 软件需求软件需求5.3.2 在在SRS中嵌入了一些项目要求中嵌入了一些项目要求 SRS应当是描写一个软件产品，而不是描述生产软件产品的过程。应当是描写一个软件产品，而不是描述生产软件产品的过程。 项目要求表达客户和开发者之间对于软件生产方面合同性事宜的项目要求表达客户和开发者