2. 航电系统需求来源与捕获

航电系统的需求不是凭空写出来的，它来自多个具有不同约束力和不同抽象层级的来源。需求捕获的核心任务，是把这些来源中分散、口语化、甚至相互冲突的期望，转化为可追踪、可验证、可分解的工程需求。理解需求来源的层次与关系，是后续需求分解和接口管理的前提。

一、需求来源的四个层次

航电系统需求通常来自四个层次，它们对需求的约束方式各不相同。

适航规章是最高层次的强制性来源。以运输类飞机为例，CCAR/FAR/CS-25 中的 25.1301（设备功能与安装）、25.1309（设备、系统与安装）、25.1322（告警）、25.1353（电气设备与安装）等条款，直接规定了航电系统必须满足的安全目标。适航规章一般不直接给出“显示器刷新率应大于多少赫兹”这类具体指标，而是给出目标与可接受的符合性方法，例如 25.1309 要求系统发生失效的概率与后果严重程度相匹配。工程上需要把“概率—严重度”目标转化为具体的可靠性指标，例如某关键功能失效概率小于 1×10⁻⁹/飞行小时，再分配到具体 LRU 和接口。

客户需求来自飞机采购方或运营方，通常以客户需求文件、技术规范或选型清单形式给出。客户需求往往带有运营场景特征，例如“在 40℃ 地面停机条件下，座舱显示器启动时间不超过 90 秒”“支持 RNP AR 0.3 进近能力”。这类需求比适航规章更具体，但可能超出适航最低要求，属于商业与运行层面的约束。

系统级需求来自飞机级或系统级的功能分析与分配结果。飞机级功能（如“提供飞行引导”）经过功能分解后，分配给航电系统，形成航电系统级需求，例如“飞行管理功能应支持 200 条航路点的存储与激活”。系统级需求是需求分解的直接输入，也是接口定义的主要依据。

利益相关方需求来自飞行员、维修人员、适航审定人员、系统集成商等。飞行员关注人机界面与操作负荷，维修人员关注 BIT 覆盖率与故障隔离时间，审定人员关注符合性证据的可追溯性。这些需求常以使用场景、操作反馈或审定问题单的形式出现，容易被忽略，却直接影响系统可用性。

二、需求捕获的方法与工具

需求捕获不是简单收集文档，而是通过结构化活动把隐性期望显性化。常用方法包括：

• 利益相关方访谈与工作坊：针对飞行员、维修、审定等角色分别组织，围绕典型任务场景提问，例如“在单发失效场景下，你希望 PFD 上优先显示什么信息”。
• 场景与用例分析：用正常、降级、应急三类场景驱动需求识别，避免只覆盖正常工况。
• 规章条款映射：逐条梳理适用适航条款，建立“条款—目标—系统需求—验证方法”的映射表。
• 原型与仿真验证：对显示格式、告警逻辑等难以用文字描述的需求，用快速原型或座舱仿真获取反馈。
• 需求管理工具：DOORS、Polarion、Jama 等工具用于需求条目化、属性标注和追踪关系建立。

捕获过程中，每条需求应至少记录来源、理由、优先级、验证方法和追踪关系。来源标注尤其重要，它决定了后续变更影响分析的范围。

三、从来源到需求的转化示例

以“座舱显示器启动时间”为例，说明需求如何从不同来源汇聚并转化为可验证指标。

适航侧：25.1301 要求设备功能正常，25.1309 要求失效概率可接受，未直接规定启动时间。客户侧：某运营方要求地面 40℃ 条件下启动时间不超过 90 秒。系统级：显示系统作为航电核心功能，需在通电后尽快可用。利益相关方：飞行员希望启动过程有明确状态提示，避免误判为故障。

综合后形成需求条目示例：

需求编号：AVN-DISP-0217
需求描述：在环境温度 40℃、电源正常条件下，座舱显示器从通电到显示可用画面时间应 ≤ 90 s。
来源：客户需求 CR-045；系统级需求 SYS-DISP-003
理由：满足运营方地面快速出动要求，并保证飞行员可及时获取飞行信息。
验证方法：地面高温启动试验，记录通电至画面稳定的时间。
追踪：向上追踪至 SYS-DISP-003，向下分配至显示器 LRU 启动时序需求。

这条需求同时携带了来源、理由、验证方法和追踪关系，后续若客户要求改为 60 秒，可以快速定位到受影响的 LRU 和接口时序。

四、需求来源与捕获关系图

下图展示四类需求来源如何汇聚到需求捕获活动，并输出为可追踪的需求条目。图中同时标出各来源的典型约束方式和输出物。

五、捕获过程中的常见问题与处理

需求捕获阶段最常见的问题是来源冲突和需求不可验证。例如客户要求“显示器启动时间尽量短”，适航要求“启动过程不得产生误导性告警”，系统级要求“启动时序需与电源切换逻辑兼容”。处理方式不是简单取舍，而是把模糊表述转化为带条件和判据的条目：明确温度、电源状态、时间阈值和可观察现象。

另一个常见问题是遗漏利益相关方。维修人员对 BIT 覆盖率的要求、审定人员对追踪关系的要求，如果在捕获阶段没有记录，往往在验证阶段才暴露，导致返工。建议在捕获阶段就建立来源清单，逐项确认是否已覆盖，并对每条需求标注来源编号。

完成捕获后，需求条目应进入需求管理工具，建立与上层来源和下层分解的双向追踪。此时的需求仍然是“待分解”状态，下一步才是按功能、性能和接口维度进行系统化分解。