3. 需求追踪的核心概念与价值

在航空机载软件研制中，需求追踪并不是一张“事后补出来的表格”，而是贯穿需求、设计、代码、测试与适航证据之间的可核查链路。它的本质是：对每一个需求项，能够回答“它从哪里来、被谁实现、被什么验证、变更后会影响谁”这四个问题。只要这四个问题中有一个无法回答，追踪链就存在断点，而断点在适航审定中往往直接对应“证据不充分”的发现项。

追踪的定义与追踪粒度

需求追踪（Requirements Traceability）是指在需求生命周期内，建立并维护需求与其他研制工件之间双向、可核查的关联关系。这里的“可核查”意味着每条关联都应能指向具体工件标识，而不是笼统的“已实现”“已测试”。例如，DO-178C 中要求对高层需求与低层需求、低层需求与源代码、需求与测试用例之间建立追踪关系，其目的不是管理方便，而是证明“每条需求都被实现且被验证，且没有未经需求授权的代码或功能”。

追踪粒度决定了追踪的实用价值。粒度过粗（如“整个飞控软件对应整份需求规格”）无法支撑影响分析；粒度过细（如把每条语句都挂到需求上）则维护成本极高且容易失真。工程上通常采用“可独立验证的最小需求单元”作为追踪粒度基准。以某型大气数据计算机的示例需求为例：

需求标识: ADC-HLR-021
需求描述: 当静压有效且空速 > 60 kt 时，应在 200 ms 内输出
          修正后的气压高度，分辨率不低于 1 ft。
追踪粒度判定: 该条包含“触发条件 + 输出 + 时间约束 + 精度约束”，
              可独立设计测试用例，故作为一条追踪单元。

如果把它拆成“静压有效判断”“空速门限判断”“高度计算”“输出刷新”四条，虽然更细，但每条都无法单独构成可验证的需求，反而会让追踪矩阵膨胀。因此，粒度选择应遵循“可独立验证、可独立变更、可独立分配”的原则。

前向追踪与后向追踪

前向追踪（Forward Traceability）从需求出发，向下游查找其实现与验证工件，回答“这条需求被谁实现、被什么测试覆盖”。后向追踪（Backward Traceability）从代码、测试或设计工件反向查找其来源需求，回答“这段代码、这个测试用例为什么存在”。两者方向相反，但必须同时成立，才能形成闭环。

在实操中，前向追踪常用于覆盖性检查：遍历需求基线，确认每条需求至少有一条设计项和一条测试用例。后向追踪常用于“孤儿工件”排查：遍历源代码函数或测试用例，确认它们都能回溯到某条需求。若某函数无后向追踪，则可能是未经需求授权的多余功能；若某测试用例无后向追踪，则可能是无效测试或需求已删除但测试未清理。

追踪在适航审定中的作用

适航审定关注的是“研制过程是否可信、产品是否满足审定基础”。追踪矩阵是审定方核查“需求—实现—验证”一致性的主要入口。以 DO-178C 的软件生命周期数据为例，审定方通常会抽查若干条需求，沿前向追踪检查其设计、代码与测试证据，再沿后向追踪确认没有未覆盖的代码或测试。若发现某条需求没有对应测试用例，或某段代码无法回溯到需求，就会被记录为“追踪性不足”，进而要求申请人补充证据或重新开展验证活动。

追踪在适航中的另一个关键作用是支撑“需求变更后的再验证范围界定”。当需求基线发生变更时，申请人必须证明变更没有破坏原有验证结论。此时追踪矩阵就是影响分析的依据：通过前向追踪找到受影响的低层需求、代码与测试用例，通过后向追踪确认是否有其他需求间接依赖该变更。没有追踪矩阵，变更影响只能靠人工回忆，既不可靠也无法向审定方证明完整性。

追踪与变更影响分析

变更影响分析是追踪最直接的价值出口。其基本过程是：从变更的需求项出发，沿前向追踪逐层向下，标记所有受影响的低层需求、设计项、代码单元和测试用例；再沿后向追踪检查是否有其他需求通过共享代码或共享接口间接受影响。最终输出一份“变更影响清单”，明确哪些工件需要修改、哪些测试需要重跑、哪些证据需要更新。

以本节示例为例，若 ADC-HLR-021 的时间约束由 200 ms 收紧为 150 ms，前向追踪会命中 LLR-045（调度周期分配）和 LLR-046（输出刷新逻辑），进而命中 calc_pressure_alt() 函数与调度配置表；后向追踪则需检查是否有其他需求也调用该函数或共享同一调度时隙。若存在共享，则这些需求对应的测试用例也应纳入回归范围。这样，变更影响分析就从“凭经验判断”变成了“沿追踪链推导”，既完整又可审计。

总结来看，追踪的定义给出了“可核查关联”这一底线，追踪粒度决定了这条底线是否可操作，前向与后向追踪构成了闭环的两个方向，适航审定把追踪从工程实践提升为合规要求，而变更影响分析则是追踪在日常研制中最频繁、最有价值的使用场景。理解这五者之间的关系，是后续建立追踪矩阵、编写追踪工具脚本和开展影响分析的基础。