陈 鑫，王 辉，牟 明

（中国航空计算技术研究所，陕西 西安710068）

0 引 言

民用航空电子系统的开发在提高生产力和保证安全性这两方面有着非常严格的要求［1］。越来越多的国家将适航标准 DO－178B 《Software Consideration in Airborne Systems and Equipment Certification》（《机载系统和设备合格审定中的软件考虑》）［2］作为机载软件必须的资格认证。我国把DO－178B标准作为机载软件开发规范已是大势所趋。

实际工作中发现，虽然与机载软件需求相关的内容在GJB2786A－2009 《军用软件开发通用要求》［3］、GJB141－2004《军用软件测试指南》［4］、GJB438B－2009 《军用软件开发文档通用要求》［5］和 GB/T9385－2008 《计算机软件需求规格说明规范》［6］等众多标准中均有提及，但是它们大多是策略、过程、准则、要求、标准和模板，没有明确提出可以满足DO－178B的要求，对具体的操作步骤更是少有论述，这使得开发出一份满足DO－178B要求的机载软件需求规格说明书非常困难。本文将通过基于结构化激励响应（structured stimulus response，SSR）方法的6个具体步骤解决这个难题。

1 DO－178B对机载软件需求的要求

适航是对载人航空器飞行最低的安全性要求［7］。适航标准DO－178B认为需求是软件质量的源头［8］。DO－178B第6.3.1节和6.3.2节指明了软件高级需求和低级需求应该满足准确性和一致性、可验证性，以及其他特性［2］。

按照DO－178B标准要求进行软件测试的策略是由上到下，即依照软硬件集成测试、软件集成测试和软件单元测试的顺序进行。如果上一级测试能够满足特定级别（A、B、C或D级）软件的需求和代码结构覆盖率要求，就不再执行下一级测试。因此，软件需求应该在尽可能高的层次上为测试人员提供软件输入输出信息。

总之，DO－178B要求机载软件需求应该是准确的和一致的，可验证的，并在尽可能高的层次上描述软件行为。

2 机载软件需求存在的问题

大型机载软件通常都具有规模大、数据关联复杂、安全级别要求高等特点。它们的需求存在下列问题，达不到DO－178B的要求：

（1）可维护性差：机载软件的激励和响应数量众多，关系复杂，现有需求中经常把每个激励和每个响应，连同处理方式单独描述一遍，这使得软件需求可维护性差。

（2）相同操作描述不一致：软件需求开发人员用自然语言描述相同或相近的操作、状态、条件等内容时差异较大，彼此不一致，软件设计编码人员和测试人员理解困难。

（3）含有较多不可验证的信息：开发出来的软件需求含有较多设计、编码、测试、工程管理信息，甚至是硬件信息，这些内容从软件角度无可验证性。

（4）低层次需求多，高层次需求少：需求大部分篇幅直接描述软件中函数、过程、对象等细节；高层次需求仅寥寥数语，这样的软件需求并不适用于集成测试。

导致这些问题的主要原因是软件需求开发人员还没有一种满足DO－178B要求的，适用于大型机载软件的需求开发方法。下面先简要介绍结构化激励响应（SSR）方法，然后通过需求开发的6个步骤，解决这些问题。

3 SSR方法及具体步骤

3.1 上述问题的解决途径

SSR方法最早用于描述Hughes Aircraft of Canada Limited公司开发的加拿大空中交通自动化系统的软件需求。后来该方法被逐渐用于安全级别要求高的复杂系统当中，尤其是航空航天领域当中的嵌入式软件［9］。针对上面提到的机载软件需求中存在的问题，SSR方法有相应的解决途径，见表1。

表1 SSR方法对软件需求存在问题的解决途径

3.2 具体步骤

从系统需求演进到软件需求规格说明书，共分6个步骤，共生成5份文档，如图1所示。软件需求开发人员通过采用表1所列的解决途径，执行这些步骤，就可以解决软件需求存在的问题，从而符合DO－178B的要求。

3.2.1 第一步：分解系统需求

系统需求并不具体区分软件和硬件各自需要完成的任务［10］，对系统需求直接使用SSR方法明显不可行。SSR方法的第一步就是把系统需求由外向内分解成多个软件需求单元。与传统意义的软件单元（计算机软件配置项设计中的一个元素［3］）不同，这里的软件需求单元是软件需求开发过程中相对独立的一个开发对象和开发结果。需求开发人员对每一个软件需求单元单独执行随后步骤。

图1 SSR方法开发软件需求的步骤

由外向内分解系统需求是随后各个步骤的基础。它应该基于传给软件的激励和软件传出的响应。分解后得到的软件需求单元粒度应适中。不同类型的机载软件，软件需求单元粒度不同，包括的内容也不同。例如：

（1）对于一些基础软件，一个软件需求单元可以包括向用户提供的一个或几个应用程序接口，比如嵌入式操作系统中，任务的创建、删除；数学库的正弦函数等。

（2）对于没有显示界面的软件，一个软件需求单元可以包括对用户而言相对独立的一个功能，比如AFDX交换机软件中的上电自检功能；飞行管理系统软件中的进近模式设置等。

（3）对于有显示界面的软件，一个软件需求单元可以包括显示界面上的一个功能点，比如飞行显示器软件中的空速值、高度值等。

（4）对于有人机交互界面的软件，一个软件需求单元可以包括操作者一次操作，比如信息管理系统中修改货品目录等。

3.2.2 第二步：激励和响应分组

本步骤按照软件需求单元的处理方式，把若干激励分为一组，若干响应分为一组，使用命名规范为各组抽象出一个唯一名称。在随后的需求分析和编写需求规格说明的工作中，可以直接通过组名索引这些激励和响应，而不必把组中每个激励，每个响应，连同处理方式单独描述一遍，从而使得最终的软件需求精简，维护方便。

本步骤将生成命名规范和接口描述文档。命名规范包括对激励组名、响应组名、源头、目的地和数据类型等数据的命名要求。

本步骤中，软件需求开发人员主要执行下列4项活动：

（1）分析软件需求单元的各种接口，包括：人机接口、硬件接口、通讯接口、与其他软件的接口等，对每一个接口还应该分析接口中的数据名称及其称号、数据元素组成、数据的来源、数据的去处、取值范围和取值含义等。

（2）根据接口中数据的流向，把接口分成激励（输入）和响应（输出）两大类。

（3）对激励类和响应类各自包含的众多接口分组，根据命名规范对各个组进行命名。

（4）综合每个软件需求单元接口的分析结果，形成项目的接口描述文档。

激励类接口分组的首要依据是软件对它们的转换过程相同，而不必考虑它们各自的消息源是否相同，因此，同一个激励组中不同激励的消息源可以不同，与之类似，同一个响应组中不同响应的消息目的地可以不同。

激励组名的形式一般是一个二元组（消息源，消息）或一个三元组（消息源，消息，消息）；其中，“消息源”指明激励的源头，“消息”指明激励的数据类型。每个激励组名在项目中都是唯一的，在对软件的功能进行分析时可以通过它索引激励组中的激励。与之类似，响应组名的形式一般也是一个二元组（目的地，消息）或一个三元组（目的地，消息，消息）；其中，“目的地”指明响应的去向，“消息”指明响应的内容。在对软件的功能进行分析时也可以通过它索引响应组中的响应。

3.2.3 第三步：确定软件功能域

本步骤采用黑盒风格分析软件的功能性需求。黑盒风格基于激励和响应，考虑系统或软件在设计和实现上受到的各种限制，分析激励和响应之间的转换过程，但不考虑转换过程的内部设计、编码、测试、工程管理、以及硬件等细节。这样的做法既与用户角度相同，得到的软件需求层次较高，便于软件测试阶段能够从产品的角度最大限度地满足用户的需求［11］；又把软件需求中含有内部细节的可能性降到了最低，避免了给软件设计造成过多限制。

在分析转换过程并描述软件需求时，需求开发人员应注意下列三点：①一个软件需求单元可能含有一个或多个转换过程；一个转换过程可以形成一条或多条软件需求。②不仅要分析正常的转换过程，还要分析异常的转换过程，及其产生原因，尤其是在需要对输入进行有效性检查的软件中。③必要时应使用实体关系图、数据流图、状态转换图、判定树和判定表等方法作为需求分析的辅助工具。

本步骤也分析软件的性能、安全性、可靠性、可测试性、可维护性和可扩展性等非功能性需求［12］，并部分生成需求描述规范和软件需求规格说明书，参见第五步。

3.2.4 第四步：确定软件数据域

本步骤主要是创建数据字典。在需求开发阶段，数据字典至少应定义用户数据项以确保用户与需求开发人员使用统一的定义和术语［13］。

数据字典里的“类型名”和“子类型名”，不仅包括软件开发所用计算机语言中含有的“类型名”和“子类型名”，还应该包括本软件项目自己定义的“类型名”和“子类型名”。通常情况下，“激励组名”和“响应组名”都是“类型名”。

如果多个激励和响应的类型或子类型各不相同，它们的名字是可以相同的。这样，数据字典即简洁，又不失明确性。比如：“操作者：＜激励＞”和“操作者：＜响应＞”两个声明就清楚地表明了“操作者”既是激励（消息源），又是响应（目的地）。

3.2.5 第五步：编写需求规格说明

本步骤使用受限的自然语言，综合第三步和第四步的分析结果，根据项目软件需求的描述规范，依次编写各个软件需求单元的功能性需求和非功能性需求。本步骤通过对自然语言施加限制，避免了需求内容的二义性，降低了编写活动的随意性，增加了对相同或相近的操作、状态、条件等内容描述的准确性和一致性，提高了需求的易理解性。

本步骤将生成需求描述规范和软件需求规格说明书。需求描述规范的内容至少应该包括：缩减的可用词汇，约束自然语言使用时的语法和风格，提供标准方法描述重复出现的语句结构和段落结构等。

本步骤中，需求开发人员应注意下列两点：

①必须严格按照需求描述规范描述软件需求。②在尽可能不包含设计信息的情况下，软件需求描述应该尽可能详细。不仅包括软件需求本身，还可以包括激励和响应的实现途径。当测试人员读到这样的需求后，可以直接通过实现途径创建激励，获取响应，从而方便软件测试。

3.2.6 第六步：评审软件需求

软件需求评审应邀请领域专家、用户代表、系统设计师、软件需求分析师和软件开发工程师等人员参与，还应邀请软件测试人员和质量保证人员［14］，主要评审第二步到第五步产生的各个文档是否明确、正确、完整、一致、可验证和可追踪。这些评审内容与DO－178B对软件需求的要求完全一致。

3.3 软件需求单元组成和实例

根据3.2节的讨论和需求管理的要求，用SSR方法开发出来的软件需求单元至少应该包括7个组成部分：标题、概述、激励、响应、转换过程、声明和性能［15］。本节以飞行显示器软件中的“航向读数”功能点为例进行说明。这些部分还可以组合成其他形式，本文不再赘述。

3.3.1 标题

标题部分应该为本软件需求单元提供一个在整个软件需求说明书中唯一的标识符，它应该是有特定含义的，能够代表本软件需求单元的。此外，它还可以加上表示特定级别和顺序的编号。“航向读数”的例子是：“8.1.1.1航向读数”。

3.3.2 概述

概述部分应该对本软件需求单元执行的异常和正常处理活动提供一个概要描述。本部分的内容是为了给使用者提供一些背景知识，不是可验证的需求。

“航向读数”的例子是：当前飞机航向的数字读数显示在主显示器（PFD）和多功能显示器（MFD）的方框符号内，参见图8.1.1.1－1。

3.3.3 激励

激励部分包括所有能够触发本软件需求单元的激励，由多个激励组名声明构成的列表组成。“航向读数”的例子如下。例子中有“航向显示条件”和“航向显示数值”两个激励组，其格式是：消息源 ＜消息＞。

（1）当从下列源头接收一个［航向显示条件］时，飞行显示系统会执行转换过程：

AHS总线313号字段 ＜航行指示器标线显示＞；

（2）当从下列源头接收一个［航向显示数值］时，飞行显示系统会执行转换过程：

AHS总线314号字段 ＜飞机航向数值＞；

3.3.4 响应

响应部分包括所有本软件需求单元产生的响应，由多个响应组名声明构成的列表组成。“航向读数”的例子如下。例子中有“航向显示”一个响应组，其格式是：目的地 ＜消息＞。

经过执行转换过程，飞行显示系统会发送一个［航向显示］到下列目的地：

PFD＜飞机航向数值＞；

MFD＜飞机航向数值＞；

3.3.5 转换过程

转换过程部分描述如何把一个激励转换成一个或多个响应，由一条或多条需求语句组成。“航向读数”的例子如下。例子中有一条需求语句。

当接收一个［航向显示条件］和一个［航向显示数值］时，飞行显示系统会发送一个［航向显示］；

3.3.6 声明

声明部分包括本软件需求单元涉及到的所有数据的声明，包括：类型名、子类型名、数据间的静态关联、常量、系统参数变量、系统状态变量、激励响应变量、本地声明本地使用的函数、本地声明外地使用的函数、外地声明本地使用的函数等。

“航向读数”的例子如下。例子中声明了一个变量，其格式是：变量名：类型名（激励组名）。

激励响应变量：飞机航向：＜航向显示数值＞；

3.3.7 性能

性能部分描述本软件需求单元的性能需求，包括时间、空间、颜色、范围和精度等内容，应根据具体项目来确定。

“航向读数”的例子是：航向读数是绿色的，不闪烁，占用3个字符的位置，显示范围从001到360，显示精度是1°。

4 结束语

从上面的讨论可以看出，通过采用结构化激励响应（SSR）方法的激励和响应分组、使用受限的自然语言和黑盒风格分析需求等途径，执行分解系统需求、激励和响应分组、确定软件功能域、确定软件数据域、编写需求规格说明和评审软件需求等6个步骤，就可以开发出具有7个组成部分的软件需求。这个需求具有可维护性好、内容一致、不含不可测试信息、高层次需求多、便于随后软件开发和软件测试等特点。总之，SSR方法适用于规模大、数据关联复杂、安全级别要求高的机载软件的需求开发活动，是一种满足DO－178B要求的软件需求开发方法。

［1］CHEN Xin.Comparison and analysis research between DO－178Band GJB2786A［J］.Engine Control，2010，16（4）37－41（in Chinese）.［陈鑫.DO－178B与GJB2786A比较分析研究［J］.动力控制，2010，16（4）37－41.］

［2］RTCA/DO－178B，1992，Software consideration in airborne systems and equipment certification［S］.

［3］GJB2786A－2009，军用软件开发通用要求［S］.General Requirements for Military Software Development.

［4］GJB141－2004军用软件测试指南［S］.Military Software Testing Guide.

［5］GJB438B－2009军用软件开发文档通用要求［S］.General Requirements for Military Software Development Documentation.

［6］GB/T9385－2008计算机软件需求规格说明规范［S］.Norm of Computer Software Requirements Specification.

［7］CHEN Xin.Airborne software verification research for airworthiness requirements［J］.Engine Control，2010，16（4）：23－27（in Chinese）.［陈鑫.符合适航要求的机载软件验证研究［J］.动力控制，2010，16（4）：23－27.］

［8］MU Ming.Research on airworthiness dominated avionics software engineering［J］.Engine Control，2010，16（4）：42－45（in Chinese）.［牟明.适航在软件工程化推进中的应用研究［J］.动力控制，2010，16（4）：42－45.］

［9］ZHANG Tao.Symbol test command language in embedded software simulation test bed［M］.Xi’anNorthwestern Polytechnical University，2005（in Chinese）.［张涛.嵌入式软件模拟测试平台中符号测试命令语言［D］.西安：西北工业大学，2005.］

［10］KENDRA M L COOPER.Training material for the stimulus response requirement specification notation［R］.The University of British Columbia，1999.

［11］LI Long.Practical technology and commonly used template of software testing［M］.Beijing：China Machine Press，2010：203（in Chinese）.［李龙.软件测试实用技术与常用模板［M］.北京：机械工业出版社，2010：203.］

［12］YANG Ruo－song.How to acquire and analyze non－functional requirements［EB/OL ］.http：//www.csairk.com/rjsp/201101170857541969.htm（in Chinese）.［杨若松.如何获取和分析非功能性需求［EB/OL］.http：//www.csairk.com/rjsp/201101170857541969.htm.］

［13］ZHAO Xi－chao.Requirement analysis of software engineering［EB/OL］.http：//www.yesky.com/114/205614.shtml（in Chinese） .［赵 熙朝.软件工程之需求分析［EB/OL］.http：//www.yesky.com/114/205614.shtml.］

［14］REN Jia－lin.Method of software requirements review［EB/OL ］.http：//www.jdzj.com/gongcheng/article/2006－8－3/3265－1.htm（in Chinese）.［任甲林.软 件 需 求评审 之 道［EB/OL］.http：//www.jdzj.com/gongcheng/article/2006－8－3/3265－1.htm.］

［15］KENDRA M L COOPER.Stimulus response requirements specification notation：An empirically evaluated requirements specification notation［D］.The University of British Columbia，2001.