3. 需求分解的基本原则与层次结构

需求分解不是把一句话拆成几句话，而是把飞机级运行目标逐层转化为可设计、可验证、可追溯的工程约束。以“飞机应具备在能见度 200 m 条件下完成自动着陆”为例，飞机级需求描述的是运行能力；到了系统级，它必须被翻译为自动飞行系统、导航系统、显示系统等各自承担的功能与性能；再往下，分系统级要回答“由哪些部件协同实现”，设备级则要落到具体 LRU 的接口、精度、时序和故障响应。分解的本质，是让每一层都只回答本层能回答的问题，同时把上层意图完整传递下去。

一、分解的基本原则

第一，功能完整性原则。上层需求中的每一项功能、性能、约束和安全性目标，都必须在下一层找到承接者，不能出现“无人认领”的需求。例如飞机级要求“自动着陆过程中单次故障不得导致航向偏差超过 3°”，系统级需将其分解为余度管理、监控表决和告警逻辑，分系统级再落到舵机通道、传感器表决和总线传输。

第二，层次适配原则。不同层级使用不同的语言和粒度。飞机级用运行场景和任务剖面描述；系统级用功能、性能和接口描述；分系统级用架构、冗余和资源分配描述；设备级用信号、协议、精度、功耗和安装约束描述。若在飞机级直接写“ARINC 429 标签 203 更新率 50 ms”，就是层次错位；反之，在设备级只写“保证飞行安全”，则无法验证。

第三，可验证原则。每条需求都应能对应一种验证方法：分析、检查、演示或测试。分解到设备级时，需求应具备明确的判据，例如“在 -40 ℃ 至 +70 ℃ 范围内，高度信号输出误差不超过 ±15 ft”，而不是“高度信号应准确”。

第四，单一责任与无歧义原则。一条需求只表达一个可判定的约束，避免“并且/或者”造成验证边界模糊。若确实包含多个约束，应拆成多条并分别建立追溯关系。

第五，追溯性原则。分解过程必须建立双向追溯：向下可查“这条飞机级需求由哪些系统、分系统、设备需求实现”，向上可查“这条设备需求为什么存在”。追溯关系通常以需求标识为锚点，例如 AC-ALT-001 → SYS-AFCS-014 → SUB-COM-007 → LRU-ACE-032。没有追溯链的需求，在更改影响分析和适航审查中都会成为风险点。

二、四层分解逻辑与粒度控制

飞机级需求来自市场、适航和运行要求，关注“飞机能做什么”。系统级需求把飞机能力分配给功能系统，关注“哪个系统负责什么、达到什么性能”。分系统级需求关注“系统内部如何组织”，例如余度通道、供电分区、总线拓扑。设备级需求关注“具体 LRU 如何工作”，包括接口定义、信号范围、刷新率、BIT 覆盖率和故障隔离时间。

粒度控制可用“可分配、可验证、可独立更改”三条准则判断。若一条需求无法分配给单一责任主体，说明粒度过粗；若一条需求更改后必然牵动大量无关设备，说明粒度过细或耦合过强。实践中，设备级需求常以“一个接口信号一组参数”为粒度，例如高度来源选择、有效性位、刷新周期和失效默认值应分别成条。

三、分解粒度与追溯性的工程落地

在实际项目中，分解粒度往往通过“需求属性”来固化。每条需求至少应携带：唯一标识、层级、来源、验证方法、验证判据、责任主体和追溯链接。以设备级高度输入需求为例，可写成如下结构化条目：

需求标识：LRU-ACE-032
需求描述：ACE 应从 ARINC 429 高度源接收高度数据，刷新周期 50 ms，
          高度范围 -1000 ft 至 +50000 ft，输出误差不超过 ±15 ft。
来源追溯：SUB-COM-007 / SYS-AFCS-014 / AC-ALT-001
验证方法：测试（台架注入 + 飞行试验）
验证判据：连续 10 min 注入，误差超限次数为 0；失效时输出默认值 0 ft 并置有效性位为无效。
责任主体：航电设备供应商 A / 系统集成组 B

追溯性不仅用于审查，更用于更改影响分析。当飞机级需求从“航向偏差 ≤ 3°”收紧到“≤ 2°”时，沿追溯链向下可快速定位到受影响的系统性能指标、分系统表决阈值和设备精度要求，避免遗漏。反之，当某设备因元器件停产需要更换时，沿向上追溯可判断该更改是否影响上层安全目标，从而决定是否需要重新验证。

最后需要强调，层次结构不是越深越好。层级过深会导致需求数量膨胀、追溯链冗长、更改传播缓慢；层级过浅则无法把飞机级目标落到可采购、可测试的设备约束。通常以“飞机—系统—分系统—设备”四层为主，若设备内部还有复杂软件，可在设备级下再设软件配置项层，但应保持每层都有明确的验证责任和接口边界。分解的质量，最终体现在：设计人员能按需求做设计，验证人员能按需求判合格，审查人员能沿追溯链看清每一条需求的来龙去脉。