民用飞机需求管理技术研究与应用

民用飞机需求管理技术研究与应用【摘要】民用飞机研制是一个复杂的系统工程，在研制过程中会产生大量的需求信息。

本文以系统工程V字模型为基础，从需求的分解、需求管理流程、需求的信息架构等几方面论述了民用飞机的需求管理技术，并且通过工具来管理需求文档，实现需求的全生命周期管理。

【关键词】需求管理；信息架构；民用飞机引言民用飞机研制是一项产品极其复杂，技术难度很大，质量要求最高的庞大的系统工程。

飞机设计从总体方案论证、初步设计、详细设计，到适航取证，各阶段设计期间，需求文件从顶层飞机设计要求，逐步分解出通用技术规范，系统级、子系统级需求文档和接口控制文件，分解过程会产生巨大的需求数量。

各需求之间本身具有相互依赖的关系，有下层对上层的支持，既要逐步确定适航审定基础，安全性、维修性等要求需逐步落实，又要不断满足客户对飞机研制需求的多样性和易变性。

因此需要采取合理的流程、科学的方法，借助工具平台建立需求信息架构实现需求的全生命周期管理，维护需求与设计、测试之间的跟踪关系，提升需求管理能力，以保持民机从用户需求、系统需求到产品设计和开发等各阶段需求的一致性。

需求开发是项目中首先发生并最为重要的活动。

要根据需求定义潜在的客户、供应商等所需要的内容，定义为了满足这些需要系统所必需完成的工作。

通常客户的需求是多种多样的，甚至有些需求可能相互矛盾，有些需求在项目开始时没有被清楚地定义，有些可能会受其他不能控制的因素制约，有些可能会随时间变化的其他目标的影响，因此，没有相对稳定的需求基础，没有好的需求管理，开发的产品就会陷入困境。

1系统工程V字开发模型系统工程是一种在考虑生命周期、客户需求及设计和工程项目的流程和技术管理的基础上，能实现成功的系统的跨学科的方法和手段。

采用系统工程方法保证了系统能够在充分合规的条件下被开发，从而减少可能影响客户需求和飞机安全的错误。

图1是一个经典的系统工程的V字模型，其中需求产出物的关联关系体现在整个开发活动的进程。

同时反映了开发过程与检验验证过程的关系。

V字模型把系统开发分成若干层次，每个层次都有需求，并只关注与相应开发阶段相关的问题。

从客户需求开始，到系统需求、子系统需求、组件需求，每一个功能上的需求都被逐步细化，才能便于开发实现。

V型模型不仅指导如何分级细化需求，也提出了测试与需求之间的跟踪以及需求之间的跟踪。

所以，采用V型开发模型使产品可以更好的满足客户要求，不仅在横向上涵盖客户的所有需求，而且在纵向上被逐级细化。

另一方面，使用不同类型的测试可验证各个级别的需求，可以更好地测试到产品的实现细节是否满足了用户的要求。

2 需求管理流程需求管理流程是系统工程的核心流程。

采用需求管理流程可确保需求自上而下逐层分解，每层的需求满足上一层次的需求，每一层设计解决方案满足需求，每一层交付的产品满足该层的需求，最后的交付产品满足用户需求。

确保从客户需求、飞机顶层、主要系统，到子系统，直至可制造的设备，每个层次被逐步实现。

同时流程定义输入和输出，以及它们如何被满足。

来自特殊领域的需求在所有层次都需要考虑，各个领域的专家小组对于每个领域的需求及规则被每一个层次的开发团队分别在相应层次满足的基础上，整体需求最终满足总体职责。

其中某一个领域的单一需求可能需要通过好几个不同的需求来满足。

进一步来看，这些需求可能还不是由单一层次或单一团队来处理的。

确保每个来自专业领域的需求或规则都能通过相应的完整的需求集合来满足是各个团队内的领域专家的职责。

图2显示的飞机研发生命周期中的需求管理流程，流程覆盖理解客户需求、转换及把需求传递给相应的开发团队、提出解决方案、证明中间的设计/产品满足相应层次的需求，然后最终证明交付给客户的产品满足他们的需求的全工程生命周期的。

从图2中我们可以看到每一层至少都有一个研发过程，而不同层次的研发过程是相似的。

每一层的开发团队都需要执行以下任务：A.识别并承认上一层的需求是该开发团队需要满足的职责。

这可以当作是给该开发团队的输入需求。

B.执行设计活动并验证设计满足输入的需求。

分析是帮助进一步细化需求，设计当然非常关键。

C.基于设计和输入需求，为下一层创建需求并验证每个需求都已加工完善，需求集都完整及可理解，每一个需求可以被追踪到一个或多个输入需求。

这些需求接着会向下流动及被分配到一个或多个低层团队中去。

D.当低层团队完成他们的工作以后，必须检查交付的项目是否符合分配给他们的需求。

E.装配已交付的组件，形成该层的最终交付项并在有必要的时候装配及验证中间的集成产品。

F.从这一层到更高层逐层验证要交付的整体产品项是否满足作为设计的起点的输入需求。

图2里，“V”形的左边是一个开发过程。

顶层从客户获得的需求，生成飞机顶层需求（TLARS）并基于一个初始的飞机总体设计生成进一步的合同技术文档。

下一层，“第1层的研发活动”从TLARS开始然后基于一个更详细的设计为主要的飞机组件生成特定需求，这层的组件包括机身、尾翼、系统、机翼。

“第2层的研发活动”有三个并行的开发流程，每一个对应一个主要组件。

这三个团队进一步把设计分解成低层组件并为每一个组件生成特定需求，从而形成“第3层的研发活动”开发过程使用的输入需求。

这个分解过程会一直持续下去，直到我们获得了可以由系统的合作方或供应商制造的特定组件的定义。

“V”形的右边是一个检验验证的过程。

通过连续的由一个层次到它的上一级交付和集成产品组成的最终产品。

每一层都必须验证交付物满足该层的相关需求。

3 民用飞机需求信息架构3.1 需求分解过程民用飞机研制是一项复杂的大系统，整个系统分解成多个子系统。

设计人员将定义系统及下层的子系统来保证实现顶层客户要求的功能。

通过对客户需求的分析可获得飞机的合同和飞机顶层需求Top—Level Aircraft Requirements（简称“TLARS”），成为所有飞机需求的来源。

根据已定义的一系列子系统，为每个子系统定义出一个功能需求文件Functional Requirement Document（简称“FRD”），以及一个覆盖总体飞机功能的FRD。

系统被分解为两个区域，结构和系统。

每个结构有一个顶层Structure Requirement Document（简称“StRD”），对应相关的系统。

每个系统都通过一系列FRD来定义，某一个特定系统的顶层System Requirement Document（简称“SRD”）只是那一系列的FRD。

3.2 逻辑信息架构逻辑信息架构提供了需求管理解决方案的描述并且定义了接口。

逻辑架构定义了活动和功能，即那些必须提供所需的能力的流程。

同时描述了系统需要的功能从而提供了客户期待的能力。

图4 所展示的是民用飞机需求的逻辑信息架构。

图4 逻辑信息架构A.飞机级顶层需求：（Top Level Aircraft Requirement Document）：此层作为开发的输入需求。

飞机级需求层里所有的需求被相对应的其它系统所满足，并且用“满足”来体现这种追踪关联。

每个设计团队需要识别必要的飞机级需求来满足他们所负责的需求输入，并且使用“满足”来追踪到原始的需求来源。

所有的不同设计和分析的工作工件应该可以使用“分配”从相应的需求来源追踪到，以及使用“参考”追踪到相应的输出需求。

B.系统级需求（Systems）：他们的输入是飞机级系统需求、其它系统的衍生需求、系统任何适用的规章。

各设计团队除了创建和维护系统需求，同时负责需求和最终产品的验证和确认。

通过创建合适的测试任务来完成这个工作。

每个系统需求都要被测试验证。

所有的测试步骤和报告应该能够从相应的需求通过“测试”链接追踪关联起来。

C.检验和验证：每一层需求（包括飞机级，系统级，子系统级和组件级）和设计都应该有这个对应的检验和验证的信息架构。

正如在图4中看到的，在不同层次的需求，比如飞机级到系统级，对应它们都有相应的V&V的活动，同时会产生相应的测试报告文档。

在需求和测试大纲之间创建的链接模块是“测试”。

4 工具化管理需求文档在需求管理过程中，以前传统的基于文档存储需求的方法，往往造成需求开发的可控性差，很难跟踪每个需求的状态，通知受变更影响的设计人员也是手工过程，也很难从多个角度全面的考虑需求，使得需求开发和管理变成了僵硬的过程，容易在开发过程中出现了需求变更的遗漏，可能会造成较大的设计更改和制造返工。

采用工具化管理可以有效改善需求管理质量，使中心数据库保存与需求相关的信息，可以极大的帮助开发人员管理需求，可以管理版本和变更，存储需求属性、帮助影响分析，跟踪需求状态等等，可以提高需求的重用性。

市场上有多款软件工具可以用于需求管理，如DOORS、Reqtify、Requisitepro。

5结论进行需求管理的最主要目的就是保证产品的质量。

质量大师Phil Crosby的定义很简单——与需求一致（Conformance to requirements）。

通过在飞机研制过程中的每一个阶段对需求进行全生命周期的有效管理，才能确保最终产品真正满足用户的要求；才能确保飞机需求数据的一致性、完整性和可控性要求，才能确保所有需求相关开发活动得到可控的透明的管理，并确保产品设计和测试工作从始至终全面准确针对有效的需求进行，任何需求的变更能够及时准确反馈并实现在设计和测试中，缩短大客机项目研制的周期，同时提高和保证质量。

【参考文献】[1]M.ELIZABETH C.HULL. 需求工程[M].北京：清华大学出版社，2003.[2]彭胜任.需求管理系统研究与开发[D].北京邮电大学，2005，03，31.[3]杨振祥.基于DOORS的软件需求管理过程及改进[D].北京邮电大学，2005，02，23.。