飞机需求编写准则探究

2015-07-29郑蓝

科技创新导报 2015年16期

郑蓝

摘要：随着飞机系统工程的广泛应用以及“制造商-供应商”模式的发展，飞机需求成为决定飞机研制成本及进度的重要因素。需求成为各级设计人员要求下级或供应商设计系统的依据，那么需求本身质量的好坏就显得极为关键。该文首先给出了飞机需求用语约定，以帮助快速识别需求。随后对飞机需求进行了分类，从这几方面进行考虑，能够保证需求的完整性。再次提出了飞机需求本身的编写原则。最后根据这些原则，提出可操作的书写注意事项和高质量需求检查单。

关键词：需求类型编写原则书写技巧检查单

中图分类号：G71 文献标识码：A 文章编号：1674-098X（2015）06（a）-0085-02

飞机研制是一项产品极其复杂，技术难度很大，质量要求最高的庞大的系统工程[1]。飞机需求作为飞机研制的设计输入，需求是否正确、完整直接影响设计研发活动的有效性和研发产品的质量，它指明了系统开发所需要和必须完成的每一件事，明确了所有设计应该提供的功能和必然受到的制约[2]。现在随着对SAE ARP4754A的认识程度越来越高，国内飞机制造商对飞机需求管理的工作越重视。较多文献围绕着需求管理的“V”过程以及平台的开发进行研究，而该文将围绕需求编写本身的质量进行介绍，从需求的类型、编写的一般原则和书写的注意事项等方面进行总结，为飞机需求编写的高质量提供参考。

1 用语约定

飞机需求的编写应有严格的用语约定，可以让人清晰的阅读出一份需求文档中哪一句是需求，哪一句是简单的陈述：“应”用于表达一条强制性的需求；“应当”用于定义一个被强烈推荐的行为，此行为并非强制性的，不用于表达需求；“可以”用于定义一个被允许的行为。不用于表达需求；“将”用于表达一个意愿或事实。不用于表达需求。

2 需求的类型

对飞机需求进行分类，实际上是要求设计人员从这几方面进行考虑，这样能够保证所出需求不会被遗忘，在后续的确认中可以将重复的需求删除。

2.1 非功能性需求

非功能性需求是那些与飞机功能分配无关的需求，一般包括过程需求、供应商需求和其他与设备直接相关的需求。

示例：

系统部件不“应”镀镉。

2.2 功能需求[3]

根据ARP 4754A《民用飞机与系统研制指南》，以下的功能需求类别需要在不同的研制阶段活动中考虑。功能需求是以“……应……”句型表达的飞机或系统级功能。

示例：飞机“应”具备减速能力。

安全性需求

安全性需求来自于安全性评估过程，例如飞机级FHA、PASA、系统级FHA和PSSA过程等。安全性需求一般包含独立性需求、概率可用性和完整性要求、无单点失效准则、研制保证等级等。

示例：

刹车系统“应”提供与正常刹车相独立的备用刹车。

在爬升、巡航和下降飞行阶段，高于25000英尺服务门意外打开的概率“应”小于1E-9每飞行小时。

功能性需求

功能性需求是指在具体条件下获得系统预期性能所需要的需求。功能性需求分为以下几种：

客户需求

客户需求随飞机型号、系统特定功能或者系统类型不同而变化。需求包括运营商的预期载荷、航路系统、使用经验、维护概念和所期望的特性。

示例：

飞机“应”有三种客舱布置构型：混合级、全经济级和高密度级。

飞机“应”提供每排4个座位（2座椅+过道+2座椅）的公务舱构型。

使用需求

使用需求定义了飞行机组与功能系统之间、维护人员与飞机系统之间、其它飞机支持人员与相关功能及设备之间的接口。活动、决定、信息需求和时间形成了主要的使用需求。定义使用需求时需要考虑正常和非正常情况。

示例：

飞机“应”具备可以在飞机客舱或驾驶舱内调节客舱温度的能力。

飞机“应”提供手动控制应急灯的能力。

性能需求

性能需求定义了使得功能或系统对飞机和其运行有用的特性。除了定义预期的性能类型外，性能需求还包括功能的一些细节，如：精度、保真度、范围、解析度、速度和响应时间。

示例：

飞机“应”保证在客舱中心线上任意两个位置的温度差不超过4.5°C。

飞机“应”确保在整个飞行包线内，不考虑飞行员或自动驾驶的输入，倾斜角不会超过33度。

物理和安装需求

物理和安装需求与系统的物理特性和飞机环境相关，包括：尺寸、安装要求、动力、冷却、环境限制、可见度、接近方式、调整、搬运和存储。生产限制也在需求中起作用。

示例：

飞机“应”确保客舱空气排放口安装在地板上。

飞机“应”在机翼前缘和前起落架上安装着陆灯。

维修性需求

维修性需求包括计划和非计划维修需求，并且与具体的安全性相关功能有关。失效探测率或者故障隔离率等因素也很重要。需求也需定义外部试验设备的信号和连接。

示例：

飞机“应”具备测试所有阅读灯的能力。

接口需求

接口需求包括：物理系统与项目的互联，以及确定的信息交互的相关特性。接口包括所有输入和输出的定义，应详尽表述信号的特征。接口文件中的接口信息应完整的描述信号特征并能追述到相关的需求。

示例：

飞机电源系统“应”给驾驶舱照明提供正常和应急电源。

空气管理系统“应”向机载维护系统提供其健康和构型状态。

补充审定需求

根据适航规章要求或为了表明对适航规章的符合性，可能需要补充功能、特性或执行要求。此类需求应与适航当局协商确定。endprint

衍生需求

衍生需求来源于设计过程本身，所以衍生需求与上层需求不相关。

3 需求的一般原则

好的需求一般要应满足以下原则[4]。

3.1 具体

需求必须确切地说明需求所要求的内容，需求的具体性应包括以下几方面。

（1）清楚明确。需求表述无歧义，清楚明确地表达需求以保证任何阅读需求的人对需求的理解与解释是唯一的。同时，必须明确应开展哪些工作以满足该条需求、具体由谁或者系统适用于该条需求。

（2）一致性。在用以描述系统或者概念的需求文件中应采用相同的专业术语。

（3）需求层级恰当。需求是对于设计者（或者实施人）的要求。编制需求应注意需求层级是否恰当。客户需求可能来自不同层级，如果用户给出的需求限定了具体的设计工作，就需要判断该条需求是否定义的恰当。当编制需求时，需求应被传递至下一个层级的需求而非更低层级（除非是使用合理的客户需求）。定义恰当层级的需求只将事物作为一个类似“黑盒”的整体，描述该“黑盒”按预期将会以何种形式呈现。需求应定义在该层级需要完成的内容，但不应定义如何需求内容的实现方式。

3.2 可量度

每一条需求必须在一定程度上通过标准的方法来验证（试验，分析，相似性或设计）。客户可以用类似“飞机航程应该尽量长”。这是一条正当的需求，但却是一条无法验证的需求。对于这样的需求，需要通过权衡分析以确定可以验证的最大航程。最理想的情况下，每一条测试需求均可通过一个单独的试验得到验证。如果一条需求需要多个试验方能得到验证，即应该将该条需求分解为多条需求。可以通过单个试验验证多条需求，但是这取决于是否可以将多条需求归类或者合并。当完成系统的架构设计时，系统各个层级的需求在测试阶段均有其对应层级的验证试验。如有必要定义子系统级的需求以描述系统，那么也应开展相应的子系统级需求验证。必须建立明确的标准用以衡量每条需求实现的情况。这些标准常被成为测试准则或者接受准则，如若未明确定义上述准则将无法证明需求的满足情况。

3.3 可实现

有必要请设计人员参与需求定义的工作，参与需求定义的设计人员必须有足够的专业知识以判断需求是否可实现。对于签署了子合同开发部件的情况，则需要要求子合同相关部件的设计人员参加需求定义的工作。同时，邀请生产单位和用户参加需求定义工作也可有效保证需求的可实现性。每一条需求必须和行业标准中的相关内容一致。一般情况下，需求必须满足相关适用的政府、行业和产品标准、规范以及接口等内容。

3.4 现实的

为保证需求的现实性，需求本身必须是代表一个目标。所有的团队愿意并且有能力去实现这个目标。为实现某个需求，我们可以找到很多技术上可行的想法，但是每个解决方案均有不同的成本。因此，关键问题不是我们随意找到一个技术上可行的方案，而是需要找到一个我们能够承受其成本的解决方案。

3.5 可追踪

必须保证每条需求可以追溯至该需求的来源。每一条用户需求必须可以追溯至相应的用户。同样地，每一项功能与特征也需要链接至最初的用户需要。因此，也必须建立每一条需求与后续的设计、实施以及试验之间的链接关系。

4 需求的书写技巧

4.1 需求语句分析

每一条单独的需求语句必须包含一个主语、一个谓语和一个宾语，如果需要，也可增加其他补充语句。

主语是即将满足或执行需求的产品或责任单位。

谓语应以标准的格式出现，“应+动词”。

宾语则是一段什么必须进行的描述。

状语描述的是需求发生需要的条件。

定语是对主语或宾语的补充说明。