基于DO-178标准的机载软件需求开发过程研究

刘 文，解文涛，王 明， 刘 媛

（中国航空工业集团公司 西安航空计算技术研究所，陕西 西安 710065）

随着机载软件复杂程度不断提高，软件在民用飞机及机载系统承担功能不断增多，机载软件的关键程度和安全性可靠性要求不断提升，机载软件开发过程的重要程度日益显现。一方面，软件需求作为机载软件生命周期中重要的数据桥梁，承接了系统需求与软件实现，是机载软件开发和软件验证的基础。另一方面，RTCA DO-178[1]作为机载软件在适航过程中的符合性验证方法，定义了明确的软件需求开发目标，强调了基于需求的验证，因此软件需求开发活动对适航符合性验证工作的充分性和完备性至关重要。综上所述，软件需求应被作为机载软件开发过程中的核心要素进行开发和管理，软件需求开发过程也应该遵循相应的要求开展。

1 机载软件需求定义

RTCA DO-178对软件需求的定义是：“对于软件在给定输入和约束条件下，将要生成什么的一个描述。软件需求包含高级别需求（High-Level Requirements，HLR）和低级别需求（Low-Level Requirements，LLR）。”[1]需要注意的是，软件需求定义了软件需要做什么，只描述结果，不应描述设计或实现细节，也不应描述管理细节。在实际项目软件开发过程中，涉及的需求有3种：系统分配给软件的需求、软件高级别需求和软件低级别需求，其中软件高级别需求和软件低级别需求都是作为软件需求开发过程的输出物而需要开发方关注的。

软件高级别需求是对系统分配给软件的系统需求、系统架构设计中分配给软件的功能、硬件接口及安全性相关需求进行分析和细化后形成的，用于指导软件设计人员开发低级别需求。软件高级别需求在软件需求过程中被开发，传递至软件设计过程。与软件高级别需求对应，软件低级别需求是根据软件高级别需求、衍生需求和设计约束，结合软件架构设计而开发的，用于指导软件设计人员开展软件实现。软件低级别需求在软件设计过程中被开发，传递至软件实现过程。是否需要将软件需求划分为高级别需求和低级别需求，应根据软件开发保证等级（Design Assurance Level，DAL）、软件规模等方面综合考虑。

在软件需求开发过程中，由于架构设计、安全性设计等因素，可能会产生一些无法追溯至上一级需求的软件高级别需求或软件低级别需求，这些需求通常被称为衍生需求或派生需求（Derived Requirements）。由于上一级需求已经经过了系统安全性评估，可以确认其对系统安全性的影响，但由于衍生需求无法连接至上一级需求，即无法证明衍生需求对系统安全性无影响，因此，DO-178B中提出衍生软件需求应反馈至系统安全性评估过程，来评估衍生软件需求是否对系统安全性造成影响[2]，在此基础上DO-178C[1]进一步明确，衍生软件需求应反馈至系统开发过程，确认是否对系统需求造成影响。在软件需求开发过程中，衍生需求将专门标识出来，例如增加衍生需求的属性，在需求评审过程中，衍生需求应提交至系统工程师和安全性工程师进行评审。

综上所述，无论高级别或低级别的软件需求，都是软件开发过程的关键生命周期数据。机载软件研制方需要在软件策划阶段对软件需求的开发活动进行识别，定义需求开发和需求验证策略，确定需求管理要求。

2 机载软件需求过程目标

美国航空无线电技术委员会（RTCA）于2011年发布了RTCA DO-178C《机载系统合格审定过程中的软件考虑》[1]，这一标准是工业界和适航局方针对机载软件开发过程达成的共识，目前已被美国联邦航空局（FAA）、欧洲航空安全局（EASA）和中国民用航空局（CAAC）作为机载软件适航可接受的符合性方法之一。

RTCA DO-178C针对不同等级机载软件定义了不同的目标，不同的目标对应了不同的软件开发活动。机载软件研制方在软件开发过程前期清晰地识别需求相关目标，定义相关需求开发活动和需求管理活动，制订详细的开发计划，在软件生命周期中严格按照计划开展相应活动，从而表明对RTCA DO-178C相应等级目标的符合性。

RTCA DO-178C附录A共定义了71个目标，涉及软件高级别需求的目标共计9个（见表1），涉及软件低级别需求的目标共计9个（见表2），覆盖衍生需求、需求正确性和完整性、需求追溯性、算法精确性等方面，目的是保证软件需求开发的有效性。

表1 RTCA DO-178C软件高级别需求相关目标

表2 RTCA DO-178C软件低级别需求相关目标

表1和表2中的目标分别针对软件需求过程、软件设计过程和软件验证过程，一般被分解为需求分析、需求定义、需求验证、需求实现、需求测试和需求变更6个方面过程活动。

机载软件适航过程中，软件研制方需要根据DAL（Design Assurance Level，软件开发保证等级）来表明对相应的目标的符合性。例如，对于DAL A级软件，需要满足表1和表2中全部目标，而对于DAL D级软件，仅需要满足表1中第1、2、3、4、8项。开发方会在软件合格审定计划中描述需要符合的目标和用于表明对目标符合性的证据材料，在软件开发初期与审查局方沟通，并达成一致。

3 软件高级别需求与低级别需求合并的影响

在部分软件开发过程中，软件开发方有可能未严格区分软件高级别需求和软件低级别需求，而是将软件高级别需求进行细化后与低级别需求合并，将两个层级的软件需求作为一个数据项来管理，这种开发方式在机载软件适航中存在一定风险。FAA发布的CAST-15报告[3]中提到FAA不建议将高级别和低级别的需求合并入一个数据项中。如果软件等级达到DAL C级以上，则不建议采用这种方式管理软件需求，原因是这将增加DO-178相关目标表明符合性的困难程度[3]。主要原因如下。

（1）无法表明软件高级别需求和低级别需求之间的追溯性。从表2中可以看出，RTCA DO-178C中目标A-4，#6“低级别需求可追踪到高级别需求”，通常对该条的符合性是通过低级别需求向高级别需求的追溯来进行，如果不区分高级别需求和低级别需求，则两层需求之间的追溯关系将无法清晰地呈现，也无法表明对RTCA DO-178C中目标A-4，#6的符合性。

（2）可能会遗漏衍生需求，因为合并后两个层级需求之间的追溯关系变得不明显，容易忽视部分未追溯到上层需求的衍生需求，导致这部分衍生需求未反馈至系统安全性评估过程，进而产生安全性相关风险。

（3）软件变更影响分析更加复杂。完整的变更影响分析依靠软件各层数据之间的追溯性，这样在变更分析过程中能够明确受影响的组件和数据。如果软件高级别需求和软件低级别需求合并之后，缺少两者之间的追溯信息，软件更改影响分析和验证策划中无法清晰地识别出受影响的软件需求、软件测试用例及结果，最终将影响软件符合性表明。

基于上述原因，在DAL C级以上机载软件开发过程中，需要充分考虑需求层次的划分，尽可能划分清晰的层次结构，保证需求数据能够发挥其最大作用。

4 软件需求开发过程中的关注点

软件需求开发过程将在软件生命周期过程中迭代进行，软件需求的分析、定义及变更等活动会根据软件成熟度反复开展。软件研制方应通过组织内部流程保证各层级开发的需求质量保持一致性，确保需求实现和需求验证活动是基于需求开展的。基于笔者工程经验，软件工程团队在软件需求开发过程中应关注以下内容。

4.1 软件需求标准

在RTCA DO-178C的软件策划过程中，对于DAL为A、B、C的机载软件应具有软件需求标准（见RTCA DO-178C目标A-1，#5），同时软件高级别需求和软件低级别需求应满足定义的软件需求标准（分别见RTCA DO-178C目标A-3，#5和目标A-4，#5）。为了保证软件需求内部及软件需求之间的协调一致，软件需求标准为软件需求开发定义了方法、规则、约束及管理工具，并对需求风格、需求质量、需求属性、需求颗粒度、需求管理工具等方面的内容进行约束，保证各层级软件需求的规范性和质量一致性，便于软件需求管理和需求质量的可控[4]。例如，在项目级需求标准中统一定义软件高层级需求和低层级需求的编号规则，防止各软件组件需求编号不协调，不利于理解和使用。软件需求标准可以在软件开发方组织层级定义，也可以根据项目实际情况在项目层级定义，无论哪种形式都需要保证软件需求标准能够被所有软件需求开发人员正确理解和掌握。

软件质量保证工程师在审计软件需求产品时，应关注需求数据对需求标准的符合情况，例如需求属性的完整性、规则的符合性等，软件质量保证工程师可以参加软件需求评审，也可以对软件需求数据进行抽查。此外，软件质量保证工程师需要关注需求开发过程对需求标准和软件开发计划的符合性，例如需求管理工具的使用情况、需求变更的规范性等。

4.2 软件需求管理

虽然RTCA DO-178未明确区分软件需求开发和软件需求管理，但是在需求工程领域，对需求开发和需求管理分别进行了定义，需求管理能够保持需求数据的完整性、准确性和可追溯性。实际上相关需求管理要求也隐含在RTCA DO-178目标活动中，因此软件生命周期应将软件需求管理作为一项技术管理活动开展。软件需求管理的核心是管理需求变更，通常包括需求管理策略制定、需求变更管理、需求基线管理、需求追踪管理、需求发布管理等内容，而软件需求捕获、分析、定义和验证等开发类活动，在RTCA DO-178中被定义在软件开发过程和软件验证过程中，不在软件需求管理过程中进行讨论。

建议在系统级需求、软件高级别需求、软件低级别需求等层级开展需求管理，从而保证各层级需求的完整性、活动的协调性和一致性，有效实现各层级需求数据之间的追溯性。重视并严格管理需求基线，控制进入基线的需求数据变更，保证需求变更的合理性、充分性和证据链的正确性。需求基线管理和需求变更管理是相互关联的两个活动，建立基线的时机和变更需求的条件应该在需求管理流程中进行定义。

软件研制方应形成完整的需求管理流程，作为软件开发流程或软件工程化管理的组成部分，在项目中按照流程进行需求管理。研制方可以在项目软件开发计划或项目需求管理计划中明确项目适用的需求管理活动、人员角色和职责、采用的需求管理工具、需求管理输出物等。

4.3 软件需求验证

软件验证是基于软件需求的验证，包含软件高级别需求和软件低级别需求。表1和表2中列出的目标中包含了对软件高级别需求的验证目标和软件低级别需求的验证目标，通常满足目标使用的验证方法包括分析、评审和测试。在实际软件验证过程中，软件研制方需要根据软件的开发等级、软件特征、软件验证工具及系统级验证策略等因素，综合考虑软件验证方法的使用，并在软件验证计划中描述验证目标、验证方法和验证活动。

采用评审的需求验证方法是进行一个或多个同行评审，采用软件需求评审检查单覆盖关注的需求，保证传递至设计过程的软件需求是正确的和完整的。评审流程应保证发现的问题及时进行记录并确认问题反馈及关闭情况。需要注意的是，同行评审参与人员应考虑软件同行专家、项目系统工程师、项目安全性工程师等角色。

另一种常见的需求验证方式是软件测试[5]。软件测试有时会划分为软件测试运行和软件正式测试。考虑到多数情况下，软件开发过程中设计和测试等活动是并行开展的，大部分集成和测试活动不能保证在同一基线上开展，因此前期的测试工作可以被视为非正式的软件测试。待全部独立的活动完成后，为了确认各软件组件之间不存在互相影响等问题，表明对RTCA DO-178相应验证目标的符合性，需要在非正式软件测试基础上开展正式的软件测试，由软件质量保证人员参加目击并记录结果。

5 结语

在机载软件开发过程中，软件研制方应重视整个软件生命周期中的需求各项工作，在软件策划阶段针对需求开发和需求管理的策略进行充分定义，在软件开发阶段开展需求开发和需求管理过程活动，确保定义的软件需求在功能、性能及安全性等方面正确、完整，在软件验证阶段进行充分的软件评审、分析和测试工作。本文以RTCA DO-178需求相关目标为研究对象，分析了软件高级别需求和低级别需求的差异，总结了软件需求开发过程中需要关注的内容，旨在为机载软件开发人员定义软件需求开发过程、提升软件需求质量提供参考。