直升机需求管理系统应用方案研究

曾加刚　江卓逞　黄玮

摘 要 本文以需求管理系统在某直升机型号中的具体应用为基准而展开论述，从需求管理问题与现状、需求管理系统总架构及需求管理具体应用，详细阐述需求开发、需求变更、需求发布、需求建模等4个独立又能统一系统的实际操作内容与步骤，实现基于模型的系统工程在具体型号中的应用，真正意义上实现由“文档驱动”到“需求驱动”，再到“模型”驱动的转变。

关键词 系统工程；需求管理；需求变更；需求发布；需求建模；需求管理系统

中图分类号 V2 文献标识码 A 文章编号 2095-6363（2017）17-0028-03

隨着科技的发展，复杂系统的工程将会遇到越来越多的挑战，对于非人为因素加入的机械系统其复杂度将远远少于有人为因素加入的机械系统，如果是智能系统，其复杂度将指数级别上升。但要追究其需求的根源，难度相当大。另外，由于航空装备工程开发复杂度高，需求变更频繁且持续演变，技术风险日益增加，管理难度空前加大等等，都需要建立需求管理系统来管控所有的需求。本文主要以需求管理系统在某型号中的具体应用为基准而开展论述。

1 需求管理问题与现状

需求工程是系统工程的一部分，是产品研发活动和管理的源头，总输入[1]，是我国高端装备“正向设计”的必经之路，也是我国民机型号研发的核心问题之一，不管是否参与国际竞争，都得遵循民航当局的相关适航条例。例如：FAA/EASA要求民机型号设计保证体系满足ARP4754A要求。因此，无论是从市场需求，还是从型号复杂程度的管控，或是从国际竞争的环境，以及自身的研发模式提升等方面，都急需需求工程，需要需求管理系统来落地需求工程。某直升机型号现阶段的需求管理问题主要存在于以下几方面。

1）在需求开发过程中，一方面由于系统越来越复杂，专业越来越多，质量要求越来越高，交付周期越来越短；另一方面，需求来源多，需求的正确性、完整性、可追溯性和可验证性，无法保证需求的同源性。

2）需求管理过程中，存在重方案、轻需求，没有形成需求牵引的研发流程，造成产品不符合需求；以文档形式传递的需求难以共同理解，大段的文本描述，容易造成理解歧义，达成共识的工作量巨大（即使有图形，也是静态的，无法运行）；需求变更的影响率和覆盖率分析困难，也就是说采用基于文件的系统工程存在需求开发的可控性不高、基线不明确、版本较混乱。

3）需求变更对项目成本、进度影响分析困难，在方案阶段难以对系统架构、功能、接口进行验证和确认，加大了后期设计、开发和集成的成本和风险。

因此，迫切需要有一套方法和工具来建立和维护需求与设计、测试验证之间的跟踪关系，以保持型号研制从用户需求、系统需求到产品设计和开发等各阶段需求的一致性。基于模型的需求工程[2]应运而生，其所采用的模型化表达，比文档更精确、严谨，并且可以执行和验证。

2 需求管理系统总架构

需求管理系统主要包括需求开发、需求发布变更、需求管理以及需求建模，以满足利益攸关者需要，从而实现从需求获取、定义、分析到需求确认与验证的需求生命周期管理及需求数据的统一、集中、迭代管理。也就是说，需要构建上述系统来更好地定义和管理需求，管控需求状态及其变更，提供需求关联和需求跟踪的能力，以保持型号项目从用户需求、系统需求到产品设计和开发等各阶段需求的一致性。其内容如下。

1）需求开发管理。主要是定义需求文件体系、模板、条目、属性、视图等需求信息架构内容，明确各专业的权限角色标准等，通过建立需求基线，确保需求版本清晰受控，为各业务专业提供统一的平台，从而实现各层次各业务专业需求的管理、追踪、验证等，提供技术手段，主要在需求管理软件DOORS[3]系统中实现。

2）需求变更管理。需求变更在产品研制实践过程中会频繁使用，特别是在需求分析、建模、验证、设计等过程中，需求的追踪性和完整性，其意义非同一般，会随着时间、成本、技术、利益攸关者想法变化等因素而发生改变故，应用成熟的技术，基于DOORS系统，提高需求条目的精细化程度，实现其精细化管控；基于需求变更管理工具（例如：Change[4]），实现需求更改的数字化定义与集成；组织变更控制委员会进行需求更改的规范化控制，从而实现型号研发应用各阶段需求更改的通用化。

3）需求发布。需求发布输出分三种方式，一种是通过RIF直接导出，输出为RIF标准文件；另一种是通过文档自动生成发布软件RPE[5]，先期定义好样式模板，配置好数据源及输出样式，再自动输出想要的Word文档或PDF文档；第三种是DOORS系统软件中直接输出相应的文档。

4）需求建模。初步建立需求与功能开发和设计分析的对应关系，同时，通过SysML建模语言[6]，初步建立总体/系统级功能、接口和架构模型，并通过模型执行对系统功能逻辑（功能活动、时序、接口、状态）进行验证和确认。

3 需求管理系统应用方案

依据需求管理系统总架构，全生命周期的管理需求，构建需求管理体系（含流程、标准、规程与模板），形成需求驱动的研制流程，并支撑适航取证和安全性分析工作。其中，需求管理系统主要包含需求开发管理、需求变更管理、需求发布、需求建模等四大块，即独立又能统一的系统。下面是各系统在某直升机型号中的具体应用。

3.1 需求开发管理

基于DOORS系统，可以轻松捕获、跟踪、分析和管理对需求的更改，需求控制是减少成本、提高效率和改进产品质量的关键，可以优化整个组织和供应链中的需求沟通、协作和确认。凭借其拥有的内置数据库，能提供丰富的功能集来捕获和管理需求。方便每个人参与并服务于需求开发管理，在某直升机型号概念设计阶段主要开展以下工作。

1）命名规则定义。在DOORS系统中初始化前，型号工作者需要定义DOORS系统中的文件夹名或项目名的命名规则，在多型号项目管理中，将起到很重要的作用，因为在同一DOORS服务器系统中，项目名是不允许相同，但是，文件夹名是可以相同。这就要求，在多型号的DOORS系统管理中，必须定义命名规则。否则，只有通过新建服务器才能应用。例如：以具体的某特征型号代号作为前缀或后缀命名。endprint

2）信息架构定义与配置。信息架构定义与配置是需求管理的核心内容。其中，信息架构定义是型号业务管理上的要求，而信息架构配置是信息架构定义在DOORS系统中的实现。信息架构是指信息之间的结构，包含信息和信息之间的关系两部分，主要体现在信息架构类型和信息架构关系，在某直升机型号具体应用中定义并配置了四种信息架构类型。（1）需求规范：用于存储规范化的需求；（2）设计：用于存储设计相关的信息；（3）V&V：用于存储验证和确认相关的信息；（4）ICD：用于存储接口，包括EICD、MICD、FICD相关的信息。

同时，也有5种信息架构关系应用在某直升机型号的需求中。（1）满足：用于表明本层需求与上层需求之间的关系；（2）分配：用于表明本层设计与本层输入需求之间的关系；（3）验证：用于表明验证程序与本层输入需求之间的关系；（4）衍生自：用于表明本层输出需求与本层设计之间的关系；（5）参考：用于存放需求与参考引用的信息之间的关系。

同时，需要定义了具体的属性、类型和视图，供型号管理应用。例如：需求编号、版本、变体、历史、作者、来源、工作流、关键字、状态、约束、优先级、关联、影响、工作量、验收标准等组成。

3）角色权限管理与配置。依据业务信息架构管理要求，配置角色权限。首先通过DOORS系统权限定义标准表，预先定义好与业务相关的各业务组，在系统中定义，并把个人的角色与权限赋予各业务组。

角色是承接业务的受动者，角色与业务组匹配，形成角色矩阵，与后面的权限匹配。在DOORS系统中包含4种角色：（1）标准：标准用户没有任何权限；（2）项目经理：具有归档数据、分区数据、创建组的权限；（3）数据库管理员：具有创建项目、归档数据、分区数据、创建组、创建用户、管理数据库的权限；（4）定制：可在创建项目、归档数据、分区数据、创建组、创建用户、管理数据库这几种权限中任意选择组合。

角色一般通过角色组与业务组合进行管理。在某直升机型号应用中分两组，一是信息化用户组（主要包括是数据库管理员）；二是业务用户组，主要包括工程师组（该角色类别又根据业务不同分为不同类别）；需求管理组；需求评审组。

权限是角色操作的能力，由两类权限构成，一是针对DOORS自身的角色权限，在新建用户时会为其分配一个角色，包括标准、项目经理、数据库管理员、定制；二是针对项目、文件夹、模块等特定对象本身的实际访问权限，包括R（读取）、M（修改）、C（创建）、D（删除）、A（管理）。最终，将角色组与权限，组合成矩阵，就形成角色权限表，赋权给不同的操作人员。其中，不同的人员可以属于不同的角色组。

3.2 需求变更管理

需求变更管理，用于提交和跟踪变更请求，Change通过与DOORS系统一起使用，可以跟踪任何需求内容的变更。它主要通过需求变更管理流程来完成变更，子流程：需求变更申请流程、需求变更流程来实现控制。在某直升机型号应用中主要开展以下工作。

1）业务变更流程梳理与确定。依据业务管理要求，特别是标准化部门，应出台相应的需求变更管理业务流程，来规范变更的控制模型。对于直升机研制过程来说，需求变更在型号研发过程中，可随时发生：（1）当需求基线冻结之后即启动需求更改管理流程；（2）在需求分析阶段，冻结需求基线，作为各专业内部设计与各专业之间协调接口的输入，当发生需求更改时，通过更改流程控制需求变更，变更频繁；（3）在需求建模与架构仿真设计时，需求变更比较频繁；（4）在设计阶段，当发生设计问题时，发起需求更改，作为再设计的输入；（5）在研制和试验阶段，发生更改时，发起需求更改流程，更改设计，作为研制和试验的输入。

依据变更控制模型设定合适的流程，主要由需求变更管理流程和其两个二级流程，即：需求变更申请流程、需求变更流程组成。

另外，需要组建需求变更控制委员会，它是需求变更的审定和决策机构，通过流程形式评估、审查、协调和批准各类更改，其成员为参与项目的各单位负责人，承担不同的角色。

2）需求变更状态设置与定义。主要依据需求变更管理流程及其两个二级流程，定义好不同的状态，满足变更业务流程需求，从而在系统中部署实施。

在需求变更申请流程设置了八种状态：（1）创建：表明流程开始创建；（2）已创建：变更表单已经创建；（3）已退回发起人：变更表单由其它状态退回至发起人；（4）已提交审批：变更表单已经提交给本专业CCB成员，等待其进行审批；（5）本专业已审批：本专业CCB委员已经审批完变更单，等待其它受影响专业进行会签；（6）已会签：所有受影响专业的CCB委员已经会签完成，等待项目主任/副主任进行审批；（7）已通过：项目主任/副主任已经审批完变更单，进入实际的需求变更流程；（8）已拒绝：需求变更申请单被拒绝，流程结束。

在需求变更流程中设置六种状态：（1）创建：表明流程开始触发；（2）已创建：子流程从此处开始，已经创建；（3）已分配：各专业CCB委员已经分配了实际的需求修改人；（4）评审中：需求修改人修改完需求后，提交复审人进行复审；（5）已批准：需求复审人已批准需求更改后的内容；（6）已应用：需求更改已应用在需求管理工具中，需求变更流程结束。

3）表单设计与配置模板。根据业务管理部门要求，提供的变更表单，在Change系统中进行设置。整个需求变更表单，可根据不同的用户权限，对字段具有不同的访问权限。

当需求编写到一定成熟度后，需打基线，并将需求变更进行管理。在需求变更之前，需要为DOORS模块配置需求变更模版，项目负责人必须具有与项目经理（用户类型）相同的权限才可配置变更请求模板。

3.3 需求發布

需求发布，是一个自动执行的文档生成解决方案，使文档生成流程化、便捷化，达到轻量级的效果。通过抽取多种数据源的数据，如DOORS、XML、REST等；定义文档模板、定义文档规范，便于达到以下明显效果：严格控制需求源头，动态的标准化、自动化生成文件；有利于建立标准的文件体系。在某直升机型号应用中主要开展以下工作。endprint

1）文件自动生成（RPE）前提条件。首先要制定文档标准，主要依据标准化部门提供的标准样式，匹配并处理宏代码，保存形成模板文件（.dot）；其次，制定内容标准，一般由业务部门提出，在输出的文档中内容表现；最后，输出属性规则定义，为何更好地通过RPE软件，将DOORS内的数据自动生成符合业务和标准化部门要求的规范化的文档，需要在DOORS内编写对象时符合一定的要求，并维护相应的属性，主要包括标识属性建立和DOORS模块对象编写规则两方面，主要是预先定义好每条属性输出后的表现形式。

2）主要功能与步骤。某直升机型号通过具体的定义与设置，控制需求版本，建立文件标准体系，定义相关模板，其主要功能和步骤有以下几点。

（1）新建文档模版：文档模版是RPE生成文档的基础。在文档模版中，定义了抽取的数据源类型及数据的展现形式；（2）抽取数据源：RPE可根据不同的数据源（如DOORS、RQM、XML）抽取出相应的数据源模式，定义目标数据源的数据结构；（3）定义文档模版：文档模版支持丰富的控件进行输出形式的定义；（4）定义文档规范：在文档规范中，定义了输出格式、采用的样式文件、使用的文档模版、需要配置的变量信息等；（5）保持文档模版与文档规范同步：当启用模版与规范同步功能后，当文档模版发生变化时，会将对应变化反映在规范中；（6）预览文档生成及实际文档生成：当目标数据量较大时，建议在实际文档生成之前进行结果预览。预览同样也会生成文档，只是将数据量限定在一个小范圍内（如10条，可在RPE选项中配置）；文档发布完成后，可能还要手工进行少量的处理。因为不同的部门发布不同的文档，对文档特有的信息还要根据实际情况进行适当更改。

3.4 需求建模

需求建模是应用Rhapsody[6]建模工具，为某直升机型号的起飞、悬停、降落建立模型。Harmony SE的一种基于模型的系统工程（MBSE）[2]方法的实现，在系统工程应用领域一方面用于系统体系结构设计的多用途建模，另一方面用于对由软硬件、数据和人综合而成的复杂系统的集成体系结构进行可视化的说明、分析、设计及校验。同时，通过对各种不同的系统工程问题进行建模，能够完成用例图、活动图、顺序图、块定义图、内部快图、状态机图等功能。某型号在需求分析、功能分析、设计综合过程中使用了以下功能。

1）需求分析。需求分析的目的是分析原始的利益攸关者需求，从中捕获系统需求，即确定系统必须做什么，并针对系统需求建立系统用例，即确定系统应具备哪些功能。主要活动内容：创建项目，导入需求，创建用例，分析需求覆盖范围，做影响性分析，形成需求图、需求表格、用例图、矩阵视图等。

2）功能分析。功能分析是在黑盒状态下分析每一个系统用例的功能流程，进而识别系统与外界的交互，最终完整描述系统的状态行为（这一过程也称为黑盒分析），一个用例执行一遍功能分析过程。这一阶段的焦点是将功能性的、表现的、接口的以及其他的需求翻译成系统功能的清晰描述，并用来指导后续的设计集成。主要活动内容：创建模型上下文，创建活动图，生成场景图，生成端口和接口，生成状态机，模型执行，重新组织状态机，添加中断状态机，添加块追踪，需求变更分析。形成活动视图、顺序视图、结构视图、状态视图、内部块图、接口控制文档等。

3）设计综合。设计综合是在综合考虑所有系统功能的基础上进行系统的架构分析与设计，将系统拆分成子系统，然后基于统一架构对每一个用例按子系统进行功能分解与分配，子系统成为分析的焦点，这一过程也称为白盒分析。主要活动内容：创建架构模型，为Block分配操作、事件、属性，场景图、端口、接口，分配非功能性需求，集成用例模型。

4 结论

按照上述需求管理系统应用方案，一方面有利于基于模型的系统工程方法（MBSE）实施应用，对应于具体的业务流程阶段划分，建立全生命周期的研制流程体系；另一方面便于借鉴最佳实践，形成可操作的文件体系，如：运营环境体系文件，系统需求文件体系等，更重要的是实现真正意义上的由“文档驱动”到“需求驱动”，再到“模型”驱动的转变。

参考文献

[1]张新国.系统工程手册[M].北京：机械工业出版社，2014.

[2]张新国.基于模型的系统工程（MBSE）方法论综述[M].北京：机械工业出版社，2014.

[3]IBM Rational DOORS 9.5.2，http：//www.ibm.com/software/rational/

[4]IBM Rational Change 5.3.0，http：//www.ibm.com/software/rational/

[5]Rational Publishing Engine 1.3.0， https：//www.ibm.com/support/knowledgecenter/SS6RHZ_1.3.0/

[6]IBM Rational Rhapsody Model Based Systems Engineering Workflow v7.6（Rational Harmony）.endprint