基于航空发动机运行场景的需求捕获方法

王向辉，蒋 平

（中国航发商用航空发动机有限责任公司，上海 200241）

0 引言

航空发动机的研制开发是在多种约束下生产出满足用户需求的产品，初始阶段就应正确捕获客户需求，并将其作为项目的重要输入[1]。我国民用航空发动机的研制起步较晚，在运行支持需求管理方面尚属空白。因此在航空发动机型号项目研制过程中，需要一种适用于航空发动机运行支持需求捕获的方法。

传统的需求捕获方法，例如访谈法、调查法，适用于简单且风险低的系统，而对于航空发动机这样的复杂系统，难以覆盖所有客户需求。传统的需求捕获方法在客户需求的可追溯性较差，导致所捕获的运行支持需求缺乏有力的支撑依据。现代使用的方法，如原型法[2]，通过演示系统获取其他方式难以获取的用户需求，但实物演示的成本昂贵，不适用于发动机这样的大型复杂系统。因此，上述方法所捕获的需求在完整性、合理性、可追溯性以及经济性等方面存在不足，需要进一步改进和完善。

1 发动机运行支持需求描述

民用航空发动机的设计和制造需满足相应的适航标准，根据其功能和使用环境，其运行和维修也要满足相应运行规章的要求，以保证持续运行的安全性。民用航空发动机运行支持是指发动机研发与制造厂商面向飞行、机务以及维修保障等发动机运营的需要，立足于发动机产品全寿命周期运行的安全性、可靠性和经济性指标，为发动机运行和维护的计划、组织、实施和控制等环节提供技术、航材、人力、培训、设备等全方位及时、精准的服务。

因此，运行支持需求是在进行航空发动机运行支持活动时各利益攸关方所提出的需求。这些需求主要面向民用航空发动机运行支持服务，目的是提高发动机运行支持过程的效率。发动机产品服务系统分为发动机产品和运行支持服务子系统（图1），如果满足两大子系统的需求，则所研制的发动机在运行支持方面可以获得利益攸关者最大的满意度。

图1 发动机产品服务系统构成

从系统工程理念出发，发动机主制造商主要关注发动机产品服务系统，该系统除了最终交付的实物产品（即民用航空发动机），还有相应的运行支持服务系统。根据发动机服役的阶段特点，航空发动机运行支持服务系统方面的需求主要包含两部分内容：维修保障与飞行运行使用保障。

2 基于发动机运行场景的需求捕获流程

2.1 利益相关者需求初步分类与整理

关于运行支持需求的捕获，首先需要完整地识别利益相关方。通过初步的访谈法、调查法，可以获取利益相关者对发动机产品运行支持服务系统的需要或期望，经分析后形成初步的系统需求。根据这些期望或需求，整理出利益相关者利用发动机产品服务系统的功能设想及期望值，即利益相关者心中的期望与实现产品服务系统的平衡点。

2.2 创建用例图

用例图是由参与者（Actor）、用例（Usecase）以及它们之间关系构成的用于描述系统功能的动态视图，是用例分析的主要办法。用例图显示了系统的用户与用户希望的功能，有利于用户与产品研制人员之间的沟通[3]。根据初步整理结果，结合场景法构建要素，创建系统用例。系统用例的定义应在综合考虑全部已形成的系统需求的基础上，将全部系统需求总结归纳，每一个关键活动就是一个系统用例，完整的系统用例即为所有关键活动的集合。

2.3 创建活动图和场景图

活动图是一种强大的信息沟通媒介，描述用例整体活动流程，显示系统的复杂逻辑。通过活动图可以明确系统的功能和逻辑关系，动态而有交互地展现系统的需求。场景图又称序列图，描述用例通过的一个特定序列路径并定义操作和角色之间的互动（信息或消息）。

2.4 捕获和补充需求

根据创建的场景图，针对每个操作或交互可以捕获并补充需求。这些新捕获的或补充的需求应经过利益相关者评审，然后导出至需求数据库。

上述过程可以在系统的不同层级重复执行，以得出不同层级的需求。

3 案例分析

为说明场景法的有效性和优势，以发动机运行支持活动——航线维修中隔声板检查活动为例，建立航线检查场景进行需求捕获示例说明。

3.1 利益相关者需求初步分类与整理

首先经过前期调研结果，明确发动机隔声板维修类需求的利益相关方，主要内容包括他们的需要是何时何地何种情况下提出的，具体如何进行维修任务（包含维修检查方式、所需工具），初步整理结果如表1 所示。

3.2 创建系统用例图

系统用例的定义应当在综合考虑全部系统需求的基础上，将全部系统需求抽象成若干个关键系统功能，每一个关键系统功能就是一个系统用例，所有的系统用例就构成了完整的系统功能。系统用例定义是在系统建模工具IBM Rational Rhapsody 中通过绘制用例图来完成。用例图包含4 个关键要素：系统边界、用例、外部角色、关系。基于系统用例图识别利益相关方和关键要素。

表1 隔声板维修检查场景要素

3.3 创建用例活动图与场景图

活动图主要说明开展用例时有哪些具体活动，以及各活动之间的交互关系。根据发动机隔声板维修支援活动经验，以及用户确认后的任务执行流程。

在活动图的每个条件判定下有可能产生不同的活动路径，每个活动路径序列就是一个场景。场景分析的主要目的是通过分析系统在所有使用场景下与外部的交互，进而还可识别系统与外部的接口。场景分析使用序列图来完成。

3.4 捕获和补充需求

根据不同的场景可以捕获对应的需求。以本文建立的场景为例，首先，外站维修单位接收到隔声板维修支援的请求，随即启动以下活动：

（1）外站维修单位为更好地接收请求和就近支援，需要建立网络站点（需求Req_1）。

（2）主管经理针对该项活动类型、难易程度指定责任工程师，主管负责该检查的进行，保证检查的效率与质量，因此对于用户而言，需要一套快速的接口对接人员调配机制（需求Req_2），以便选择合适的工程师负责该项工作。

（3）根据该项目维修类型及维修难度确定是否需要手册指导，如果需要手册则手册管理部门提供所需手册，为高效满足该项任务需要一套手册方案（需求Req_3），反之不必该部门进入。

（4）判断该过程是否需要航材，如果需要，航材管理部门提供所需航材，在此航材管理部门需要一套航材管理方案（需求Req_4），以便快速调取所需航材，不需要则直接进行人员的运输。

图2 发动机隔声板维修支援需求

（5）航材和人员的运输。运输部门通过运输目的地确定运输方式（公路或空运），在该步中需要清楚航材属性（大小、材质等）（需求Req_5）、存储方式及注意事项等信息（需求Req_6），以便完好地将所需航材和人员运输至目的地。

（6）责任工程师实施各项验收检查程序（需求Req_24）。

（7）财务部门结算、支付该项目所有费用。为合理计算经费，需要一套综合多种因素的算法（需求Req_25）。

3.5 需求与活动关联分析

需求与用例的关联关系通过在需求条目与系统活动之间创建＜trace＞关系来实现，直观地展示每一个系统需求被分配到了哪几个活动上，每一个活动都与哪几个系统需求有关。

采用需求软件，还可对系统需求进行覆盖性分析。表明需求已被全部分配到了活动，总体质量达到100%；需求与活动的追溯关系可视化地展示了需求到活动的追踪关系，以便后续更新与操作。同时，在软件中可以查看捕获的需求的子集，生成需求图。软件还可以直接输出分析报告，包括可追踪性矩阵报告、分析结果、需求详细视图、规则检查等报告。

4 结论

采用基于场景法的发动机运行支持需求捕获，以用例图、活动图构建发动机隔声板维修支援的场景。根据实施过程的活动序列，建立活动与其需求的关联关系，实现了需求到活动的可追踪性与可视化，能够更完整、准确地捕获系统需求。

在MBSE（Model-Based Systems Engineering，基于模型的系统工程）的指导下，通过建立运行场景模型，多角度分析系统，不仅可以降低风险与成本，还能促进需求管理体系的构建，提高利益攸关者和开发人员的可读性与可操作性。