1. 航空软件需求到验证闭环管理导论

航空软件与普通商业软件最大的差别，不在于代码规模，而在于它必须对“安全”作出可追溯、可举证、可审查的承诺。一架飞机的飞控、发动机控制、显示告警、通信导航等软件，一旦需求理解偏差或验证遗漏，后果可能是灾难性的。因此，航空软件研制不能停留在“写完代码、测过就行”的层面，而必须建立一条从需求提出到验证确认、再反馈修正的闭环链路。这就是本章要讨论的核心：需求到验证的闭环管理。

什么是闭环管理

闭环管理，指的是把“需求—设计—实现—验证—确认”五个环节当作一个相互约束、相互反馈的整体来管理，而不是彼此割裂的先后工序。它的关键特征有三点：

• 双向可追溯：每一条高层需求都能向下追踪到设计、代码和测试用例；每一个测试结果也能向上回溯到它覆盖的需求。正向追踪保证“需求没有被漏做”，反向追踪保证“做的每件事都有依据”。
• 状态受控：需求、设计、代码、测试用例都有明确的状态（如草稿、评审中、已批准、已变更、已关闭），任何变更都要评估影响范围并同步更新下游产物。
• 反馈修正：验证和确认中发现的问题，不是简单“改代码了事”，而要判断是需求本身有误、设计有缺陷，还是实现有偏差，并把结论回写到相应环节，形成真正的闭环。

可以用一个简单判断来区分“开环”和“闭环”：如果测试失败后，团队只修改代码再重测，而不追问“需求是否写清楚、设计是否合理”，那仍然是开环；只有当问题被定位到需求、设计或实现中的具体环节，并触发对应产物的更新与再验证，才算闭环。

五个环节的衔接关系

航空软件研制通常遵循“需求→设计→实现→验证→确认”的主线，但这条主线不是单向流水线，而是带有反馈回路的链条。

需求环节回答“软件要做什么、做到什么程度”。在航空领域，需求往往来自系统级安全性评估、适航规章、客户接口定义等。需求必须可验证，例如“飞控计算机应在接收到有效传感器数据后 20ms 内完成一次控制律解算”，而不是“飞控计算机应快速响应”。

设计环节回答“软件如何组织来实现需求”。包括架构设计、接口定义、数据流设计、状态机设计等。设计必须能追溯到需求，同时为编码提供足够约束。

实现环节把设计转化为可执行代码。编码规范、静态分析、单元测试在这一环节介入，确保代码与设计一致。

验证环节回答“我们是否正确地构建了产品”。它检查设计、代码、测试是否满足需求，常用方法包括需求评审、代码审查、单元测试、集成测试、覆盖率分析等。

确认环节回答“我们是否构建了正确的产品”。它从最终使用场景和系统级目标出发，确认软件在真实或仿真环境中确实满足用户与适航要求，例如通过系统集成试验、飞行试验、适航符合性验证等。

验证与确认的区别常被混淆：验证偏“对需求符合性”的检查，确认偏“对使用目标符合性”的检查。两者共同构成闭环的出口，也共同把发现的问题反馈回需求、设计或实现。

为什么航空软件必须闭环

第一，适航审查要求证据链。DO-178C 等标准强调需求、设计、代码、测试之间的可追溯性，审查方需要看到“这条需求为什么这样设计、这段代码为什么这样写、这个测试为什么能证明它满足要求”。没有闭环，证据链断裂，审查无法通过。

第二，安全关键软件的缺陷代价极高。航空软件缺陷可能导致飞行事故，而缺陷往往不是编码错误，而是需求遗漏、接口理解偏差、设计假设不成立。闭环管理把问题暴露在早期环节，降低后期返工成本。

第三，变更不可避免。航空软件研制周期长，需求变更、平台升级、适航条款更新都会发生。闭环管理让每次变更都能被评估影响范围，并同步更新设计、代码和测试，避免“改了代码忘了改测试”这类典型问题。

适用场景与边界

闭环管理适用于所有安全相关或适航相关的航空软件，包括飞控软件、发动机控制软件、航电显示软件、通信导航软件等。对于非安全相关的辅助工具软件，可以适当裁剪，但基本的需求—验证追溯仍然建议保留。

需要说明的是，闭环管理不是“多写文档”。它的核心是可追溯、可验证、可反馈。文档只是载体，真正重要的是每条需求都有明确的验证方法，每个验证结果都能回到需求，每个问题都能定位到具体环节并触发修正。

一个简化的追溯示例

假设某飞控软件有一条需求：REQ-FCS-012：当迎角超过 15° 时，飞控软件应在 50ms 内输出失速告警信号。闭环管理要求：

• 设计文档中能找到对应设计项 DES-FCS-045，说明告警判断逻辑与输出接口；
• 代码中能找到实现该逻辑的函数与变量；
• 测试用例 TC-FCS-078 注入迎角 16° 的仿真信号，检查 50ms 内告警输出；
• 若测试失败，需判断是需求阈值写错、设计逻辑有误，还是实现有偏差，并回写到对应环节。

这个例子说明，闭环管理不是抽象口号，而是每条需求背后都有一条可检查的证据链。后续章节将围绕这条链路的每个环节展开，讲解如何编写可验证的需求、如何建立追溯关系、如何设计验证用例、如何管理变更与评审。

本章的核心结论可以概括为一句话：航空软件的质量，不取决于某个环节做得多好，而取决于需求、设计、实现、验证、确认之间是否形成了可追溯、可反馈的闭环。