2. 航空软件需求工程基础
航空软件需求工程的核心任务，是把飞机级、系统级意图转化为可验证、可追踪、可受控的软件需求。与一般软件相比，航空软件需求多了一层“适航约束”：需求不仅要让开发和测试看懂，还要能向审定方证明其完整性、正确性与可追溯性。本节围绕需求分类、需求来源、需求质量准则和需求基线管理四个基础问题展开。
一、需求分类：四类需求各有验证方式
航空软件需求通常分为功能、性能、接口、安全四类。分类不是贴标签，而是决定后续验证手段和追踪路径。
功能需求描述软件“做什么”，例如“当大气数据计算机输出的空速有效时，飞行指引计算机应在 100 ms 内计算并输出俯仰指令”。功能需求必须包含触发条件、输入、处理逻辑和输出，避免只写“软件应支持自动驾驶”这类无法验证的表述。
性能需求描述“做到什么程度”，包括周期、延迟、吞吐量、精度、内存占用等。例如“姿态解算任务周期为 20 ms，最坏执行时间不超过 12 ms，CPU 占用率不超过 40%”。性能需求必须给出可测量指标和测量条件，否则测试无法判定通过与否。
接口需求描述软件与外部环境及其他软件的交互，包括总线类型、数据格式、刷新率、量纲、有效范围、失效默认值。例如 ARINC 429 标签、A664 虚拟链路、离散量高低有效定义。接口需求最容易在集成阶段暴露问题，因此必须与 ICD（接口控制文件）保持一致。
安全需求来自安全性评估结论，用于把失效影响控制在可接受水平。例如“当迎角信号无效时，软件应在 50 ms 内断开失速保护输出并置位故障标志”。安全需求往往与功能、接口需求交叉，需要在追踪矩阵中单独标识，确保每条安全需求都有对应的验证证据。
二、需求来源：三条输入路径
航空软件需求主要来自三个方向。第一是系统需求，由系统级功能分析和分配产生，通常以系统需求文档、功能分配表、ICD 的形式给出。软件团队需要把系统需求分解为软件高层需求，再细化为低层需求。第二是适航规章，包括 CCAR/FAR/CS 25 部相关条款、DO-178C 目标、DO-160 环境要求等。适航规章不直接给出软件功能，但会约束开发过程、验证深度和证据形式。第三是客户需求，来自航空公司、运营商或特定构型要求，例如显示格式、维护接口、选装功能。
三条来源可能产生冲突。例如客户要求增加一个显示页面，但系统资源预算已接近上限。此时不能简单取舍，而应回到系统级进行影响分析，评估对性能、安全、接口和适航证据的影响，再决定是否纳入需求基线。
三、需求质量准则：可验证是第一原则
一条合格的航空软件需求应满足以下准则：
- 必要性：每条需求都能追溯到上层来源，没有来源的需求不应存在。
- 无歧义：使用明确量词和数值，避免“快速”“适当”“尽可能”等模糊词。
- 可验证：能通过分析、评审、测试或演示判定通过与否。
- 一致性：需求之间不矛盾，术语、量纲、有效范围统一。
- 完整性：在给定条件下，需求覆盖所有正常、异常和边界情况。
- 可追踪：每条需求有唯一标识，能向上追踪到系统/适航来源，向下追踪到设计、代码和测试用例。
实际评审中，可用“需求质量检查表”逐条打分。例如一条需求写“当空速大于 VMO 时，软件应发出超速告警”，缺少告警形式、延迟上限和失效处理，应判定为不完整。修改为“当空速大于 VMO 且持续 200 ms 时，软件应在 50 ms 内输出离散量超速告警，并在空速信号无效时抑制告警”，才具备可验证性。
四、需求基线管理：从“写出来”到“控起来”
需求基线是经过评审和批准、纳入配置管理的一组需求。基线一旦建立，任何变更都必须走变更控制流程。基线管理的核心动作包括：
- 标识：为每条需求分配唯一编号，如 SRS-FUN-001、SRS-PERF-012，并记录版本。
- 评审：组织系统、软件、安全、测试、适航代表进行联合评审，记录评审意见和关闭状态。
- 入库：将批准的需求纳入需求管理工具，建立与系统需求、设计、测试用例的追踪链接。
- 变更控制：变更申请需说明原因、影响范围、对安全性和适航证据的影响，经 CCB 批准后更新基线。
- 追溯与审计：定期检查追踪覆盖率，确保没有“孤儿需求”和“无需求测试用例”。
总结来说，航空软件需求工程的基础可以概括为：分类决定验证方式，来源决定追溯路径，质量准则决定需求能否通过评审，基线管理决定需求在全生命周期内是否受控。这四件事做扎实，后续的需求追踪与测试设计才有可靠起点。