飞机研制过程中需求分析的方法

张粉婷 赵新宇

（中国民航飞行学院，四川 广汉 618307）

1 需求分析方法

1.1 需求分析概念

需求分析（如SE 过程集）是一个迭代活动，其中随着概念的发展和更多细节的了解，确定并不断完善新的需求。对这些进行分析，并找出缺陷和成本动因，并与客户一起检查，以建立项目的需求基准。 需求分析的第二个目的是提供对各种功能之间相互作用的理解，并根据用户目标获得一组平衡的需求。 需求不是凭空开发的。 需求开发过程的重要组成部分是ConOps，它所伴随的隐式设计概念以及相关技术的相关需求。需求来自多种来源，包括：客户/用户，法规/代码和公司实体，如图1 所示。

这个复杂的过程采用绩效分析，贸易研究，约束评估和成本/收益分析。 如果不确定它们对较低级别元素的影响（可实现性），则无法建立系统需求。因此，需求定义和分析是一个迭代。

1.2 良好要求的特征

在定义需求时， 应注意确保适当地制定了需求。对于每个需求，应考虑以下属性：

必要——每个需求都会以处理，维护和验证的形式付出额外的努力。 仅应写下必要的要求。 不必要的需求有两种：（1）不必要的设计规范，应由设计者自行决定；（2）多余的要求包括在某些其他要求组合中。

图1 需求来源

独立于实施——客户要求可以按他们希望的任何级别强加。 但是，当客户需求指定设计时，应该提出质疑。 适当的要求应通过描述“框”将执行的转换来处理被指定为“黑框”的实体。 需求应指定在该级别上将要执行的操作，而不是在该级别上将要执行的操作方式。

简洁明了——需求必须传达将要进行的工作到下一个开发阶段。

完整——要求是对设计者（或实施者）的下一个要求。

一致——在许多情况下，存在适用的政府，行业和产品标准，规范和接口，需要遵守这些标准。

可实现的——实施设计师必须参与需求定义。

可验证——必须通过4 种标准方法（检查、分析、演示或测试）之一对每个需求进行某种程度的验证。

2 功能和目标

2.1 定义系统功能和性能目标

生产、部署、操作和支持的概念是一个很好的基础，系统工程师可以从中识别感兴趣的系统所需的功能以及系统的相关性能目标。作为此功能定义活动的结果，将确定许多性能要求。

2.2 派生和完善功能/性能要求

在项目开始时，SE 主要关注用户需求分析，导致将用户需求转换为基本功能和一组可量化的性能需求，这些需求可以转化为设计需求。

建立一套完整的系统要求是一项复杂，耗时的任务，几乎涉及所有项目领域，都是一项交互式工作。它必须尽早完成，因为它构成了所有设计，制造，验证，操作、维护和处置工作的基础，因此决定了项目的成本和进度。 该活动在每个阶段都是迭代的，随着设计详细程度的提高， 持续不断地反馈， 并且来自SRD，SOW，公司政策和程序，ConOps 文档（或运营概念文档），设计概念，系统层次结构和数据项描述（标识规范的预期内容）。 总体需求分析过程如图2 所示。

质量功能部署（QFD）是一种有用的技术，尤其是在“客户的声音”不清楚的情况下。它提供了一种快速的方法来将客户需求转换为规格，并系统地将需求降低到较低的设计、零件、制造和生产水平。阴影的关系矩阵显示了功能和需求之间的相关性。 两个同心圆（双圆）用于指示特征和需求之间的强相关性。单个圆圈表示适度的贡献。空白列表示相对于列出的要求而言不必要的功能。同样，空白行表示未解决的要求。其他有用的方法包括：使用系统层次结构，FFBD，时间表，控制/数据流程图，贸易研究和需求分配表进行功能分解。

图2 需求派生，分配和流动

如上所述，较大的系统可能需要从系统体系结构演变而来的高级系统仿真。该仿真将用于快速检查各种尺寸和参数，而不仅仅是“点设计”，以确保获得“最佳”解决方案——系统始终是合适的尺寸，没有阻塞点。 检查推导和合并要求所带来的任何不利后果。 在无法确认现有用户需求的地方，请进行贸易研究以确定更合适的需求，并以最小的成本获得最佳平衡的性能。 在必须分配关键资源（例如重量、功率、内存和吞吐量）的地方，可能需要进行贸易研究以确定适当的分配。将需求分析过程中产生的修订和衍生的需求和参数纳入需求数据库， 并保持对源需求的可追溯性。准备规范文件并提交给所有组织，以供审核。批准后，将文档输入正式发布系统，并在配置管理控制下进行维护。 任何进一步的更改都将需要配置控制委员会（CCB）的批准[1]。 需求分析过程的结果应该是一组完整，准确，无歧义的系统需求的基线，记录在需求数据库中，所有各方均可访问，并记录在已批准的已发布系统规范中。通常使用以下措施来评估此需求分析活动的进度和完成情况。

2.3 定义其他非功能性要求

概念文档还将提出与感兴趣的系统提供的主要功能不直接相关的需求，例如可用性、可支持性、安全性和培训。 例如，0resund 桥案例说明了通过对施工实践建立约束来避免负面的环境影响。尽早解决非功能性需求是确保它们不会被遗忘和满足的一种好方法。

图3 质量功能部署（QFD）：质量屋

2.4 开发规格树和规格

在实践中， 需求工程不仅是系统开发过程的前端，而且是一个复杂的通信和协商过程，涉及将使用系统的各方（即客户），将提供部分或全部系统的各方（即开发人员和供应商）以及将验证系统的各方（即验证组）。

对于复杂的系统， 定义/设计过程是通过多次分层迭代依次应用到硬件和软件CI 定义级别的。 目的是在系统设计的特定级别（例如，硬件、软件和操作）为每个配置项创建规范基线，并将这些规范放置在向下的层次结构中。这将使每个配置项的进一步定义可以与其他所有配置项并行地独立进行，同时保持需求的可追溯性和设计工程为衍生的需求提供技术定义数据，并记录设计决策。 支持学科监视每个专业领域中需求的执行情况，识别需求并查看需求定义过程的结果。 这项工作的结果是一组要求声明，这些要求声明放置在系统和CI 规范中。 规范草案由需求数据库生成，并分发给审阅者。 然后将副本连同适当的评论一起退还给作者。解决所有注释后，文档正式发布。需求数据库工具应直接从数据库生成规范，而无须人工干预，从而保持数据库的完整性[2]。 注意：一个级别的规格表示对它以下级别的要求。

2.5 生成系统规范

系统规范是一组完整、准确、无歧义的系统需求的基准，记录在需求数据库中，所有各方均可访问。在需求分析过程中，通常有必要生成明确的系统需求的“快照”报告。 为了帮助该过程，可能需要在需求数据库中创建一组明确的需求对象，并提供从其对应的原始需求中提供可追溯性的信息。明确的要求可以分为功能性、性能、约束性和非功能性。

3 结论

需求管理指明了系统开发所要做和必须做的每一件事， 指明了所有设计应该提供的功能和必然受到的制约[3]。 需求管理的过程，从需求获取开始贯于整个项目生命周期， 力图实现最终产品同需求的最佳结合[4]。因此， 需要以贯彻基于系统工程的系统研制流程、加强过程管控为契机，开展本标准研究，推动系统工程在国产民机研制过程中的深入应用。