3. 软件需求验证实战

在航空嵌入式软件研制中，需求验证不是“读一遍需求文档”，而是对需求集合进行系统性的质量审查。DO-178C 将需求质量视为后续设计、编码和测试能否成立的前提：如果一条需求本身写错了、漏了、前后矛盾或无法判定，那么再严格的测试也只能证明“实现符合了一条错误的需求”。本节围绕四个核心属性——正确性、完整性、一致性、可验证性——展开分析，并给出缺陷分类与案例演练方法。

四个属性的判定标准

正确性（Correctness）关注需求是否真实反映系统意图与上层约束。判定依据不是“读起来合理”，而是能否追溯到系统需求、接口控制文档（ICD）、适航规章或安全性分析结论。例如某飞控软件需求写“当空速超过 250 kn 时点亮超速告警”，若系统需求规定阈值来自大气数据计算机且为 260 kn，则该需求不正确。

完整性（Completeness）关注需求集合是否覆盖了所有输入条件、状态、边界和异常路径。常见缺口包括：只写了正常分支未写故障分支、只写了有效输入未写无效输入、未定义初始化状态、未定义超时行为。完整性审查常用“条件—响应矩阵”检查：把每个输入条件与预期响应交叉列出，空格处即为潜在遗漏。

一致性（Consistency）关注需求之间是否冲突或重复定义。典型问题包括：两条需求对同一参数给出不同阈值；同一状态在不同需求中命名不同；接口数据方向相反；时序约束互相矛盾。一致性缺陷往往在集成阶段才暴露，代价很高，因此必须在需求阶段用交叉引用矩阵主动排查。

可验证性（Verifiability）关注需求能否通过分析、评审或测试给出明确的通过/失败判据。不可验证的典型表述是“系统应快速响应”“应具有良好的人机界面”“应尽可能降低延迟”。可验证的需求必须包含可观测的触发条件、可测量的输出和明确的容差，例如“从接收到有效指令到输出更新，延迟不超过 50 ms”。

缺陷分类：让问题可统计、可追踪

把发现的问题按类型归档，才能判断需求质量趋势并分配修改优先级。建议采用五类划分：错误型（内容与上层依据不符）、遗漏型（条件或响应缺失）、冲突型（需求之间矛盾）、模糊型（不可验证）、冗余型（重复定义）。每条缺陷记录至少包含：缺陷编号、需求条目号、类型、严重度、证据来源、建议修改、责任人、状态。严重度可按“是否影响安全性/是否阻塞下游”分为高、中、低三级。

案例演练：一条超速告警需求

假设某大气数据软件需求原文为：

REQ-AD-021：当空速超过阈值时，系统应快速输出超速告警，
并保证告警的及时性和可靠性。

逐属性审查：正确性——阈值未给出具体数值，无法与系统需求核对，需追溯至系统需求 SYSR-045 确认阈值为 260 kn、来源为 ADC 通道 A；完整性——未定义空速从超阈值恢复到阈值以下时告警如何清除，也未定义 ADC 数据无效时的行为；一致性——需检查是否存在另一条需求 REQ-AD-033 使用 250 kn 阈值，若存在则冲突；可验证性——“快速”“及时性”“可靠性”均无量化判据，无法设计测试用例。

修改后的需求示例：

REQ-AD-021（修订）：当 ADC 通道 A 输出的校正空速 CAS 连续 3 个
采样周期（周期 20 ms）大于 260 kn 且数据有效位为 1 时，软件应在
检测到第 3 个超阈值采样后 60 ms 内将 OVERSPEED_WARN 置为 1。
当 CAS 连续 3 个周期小于 255 kn 时，应在 60 ms 内将
OVERSPEED_WARN 置为 0。当数据有效位为 0 时，
OVERSPEED_WARN 保持前一有效状态并置 DATA_INVALID 标志。

修订后，触发条件（CAS > 260 kn、连续 3 周期、有效位为 1）、输出（OVERSPEED_WARN）、时序（60 ms 内）、迟滞（255 kn 清除）、异常处理（数据无效）均可观测、可测量，测试用例可以直接据此设计：注入 CAS 序列 258→261→262→263，检查第 3 个超阈值采样后 60 ms 内输出翻转；再注入 254→253→252，检查清除；最后将有效位置 0，检查保持与标志置位。

可验证性的量化改写规则

把模糊需求改写为可验证需求，可遵循“触发—响应—判据”三段式：触发条件必须是可观测的输入或状态；响应必须是软件可产生的输出或状态变化；判据必须包含测量点、目标值和容差。例如“应快速响应”改为“从输入事件到输出更新不超过 X ms”；“应具有良好容错”改为“当输入超出 [a,b] 范围时，输出保持上一有效值并置故障标志”。容差和测量点需与验证方法匹配：若用目标机测试，测量点应选在可观测的接口或总线消息上。

审查结果如何闭环

审查结束后，缺陷报告应进入配置管理，每条缺陷关联到具体需求条目和版本。修改后的需求必须重新走查，确认修改未引入新的不一致。对于影响安全性或接口的需求变更，还需评估对下游设计、代码和测试用例的影响范围，并触发相应的回归验证。只有缺陷状态关闭且需求基线更新后，本轮需求验证才算完成。