4. 航空软件需求规格说明编写

需求规格说明（SRS）是航空软件研制链条中承上启下的核心文档：向上承接系统级分配与适航审定要求，向下驱动设计、编码与验证。一份可用的航空软件 SRS，不是把系统需求“翻译”成软件语言，而是把每条需求写成可判定、可追溯、可验证的工程契约。本节围绕四个关键问题展开：用什么结构承载需求、用什么语言描述需求、用什么属性管理需求、用什么准则判断需求可验证。

一、结构化需求模板：让每条需求有固定“骨架”

航空软件需求通常采用“需求条目 + 属性字段”的结构化模板，而不是连续段落。推荐的最小骨架包含：需求标识（如 SRS-FCS-0123）、需求标题、需求正文、需求类型（功能/性能/接口/安全/约束）、来源（系统需求或适航条款编号）、验证方法、验证准则、优先级、状态、版本与变更记录。其中验证方法与验证准则是模板的灵魂——没有它们，需求在评审阶段就无法判定是否可验证。

以某飞控软件“俯仰角速率限制”需求为例，可写成：

需求标识：SRS-FCS-0123
需求标题：俯仰角速率指令限幅
需求正文：当俯仰角速率指令绝对值超过 15 °/s 时，
          软件应将输出指令限幅至 ±15 °/s，并在 20 ms 内生效。
类型：功能 + 性能
来源：SYSR-FCS-0045；CCAR-25.1329
验证方法：测试（T）
验证准则：输入 20 °/s 阶跃指令，输出稳定在 15 °/s ±0.5 °/s，
          响应时间 ≤ 20 ms，超调 ≤ 5%。
优先级：高    状态：已评审    版本：V1.2

这种模板的价值在于：评审时逐字段检查，任何字段缺失或含糊都直接暴露为缺陷，而不是留到测试阶段才发现“需求没法测”。

二、自然语言与形式化描述：两种表达，各司其职

自然语言描述可读性强、便于与系统工程师和审定方沟通，但天然存在歧义。航空软件中常见的歧义源包括：范围词（“快速”“适当”“尽可能”）、逻辑连接词（“与/或”混用）、隐含时序（“同时”“之后”未量化）、被动语态导致责任主体不清。因此自然语言需求必须遵守若干书写规则：使用主动语态、一句一需求、量化所有阈值与时间、避免否定嵌套、统一术语表。

形式化描述则用于安全关键、逻辑复杂或状态密集的需求，常见形式包括：状态机/状态表、时序逻辑表达式、表格化判定（如决策表）、以及基于模型的形式化规约（如 SCR、RSML、LTL 片段）。形式化描述的优势是可被工具检查一致性与完备性，例如用状态表穷举“俯仰角速率限制”的使能/禁止条件，可发现自然语言中遗漏的边界组合。

实践中推荐“双轨制”：自然语言作为主描述，形式化片段作为补充附件，两者通过需求标识绑定。形式化描述不追求全量覆盖，而聚焦于模式切换、余度管理、故障隔离等高风险逻辑。

三、需求属性定义：让需求“可管理”

属性不是装饰，而是需求全生命周期管理的抓手。航空软件 SRS 中，以下属性必须逐条填写且保持一致：

• 标识：全局唯一、稳定不变，变更时只升版本不改标识，便于追溯矩阵对齐。
• 类型：功能、性能、接口、安全、约束、环境等，决定后续验证策略。
• 来源：系统需求编号或适航条款（如 CCAR-25.1329、DO-178C 相关目标），保证双向追溯。
• 验证方法：测试（T）、分析（A）、检查（I）、演示（D）四类，必须与验证准则匹配。
• 验证准则：可判定的通过/不通过条件，包含输入、观测点、阈值与容差。
• 优先级与状态：支撑评审排期与变更影响分析。

属性之间要相互约束：若验证方法选“分析”，则验证准则必须给出分析模型、假设与判据；若选“测试”，则必须给出可构造的输入与可观测的输出。属性填写不一致，是需求评审中最常见的退回原因。

四、可验证性准则：五条硬标准

一条需求是否可验证，可用五条标准快速判定：

1. 可判定：验证结果只有“通过”或“不通过”，不存在“基本满足”。
2. 可观测：存在明确的观测点（接口输出、总线报文、状态字、日志），且观测手段在验证环境中可用。
3. 可量化：所有阈值、时间、精度、容差均给出数值与单位，如“≤ 20 ms”“±0.5 °/s”。
4. 可复现：输入条件、初始状态、环境假设可被独立重建，不同人员执行结果一致。
5. 可追溯：需求绑定来源与验证用例，形成“系统需求—软件需求—验证用例—验证结果”的闭环链路。

五、编写流程与评审要点

实际编写时，建议按“来源梳理 → 条目拆分 → 正文书写 → 属性填写 → 形式化补充 → 可验证性自检 → 同行评审 → 基线入库”推进。拆分条目时坚持一句一需求，避免“与/或”导致验证用例爆炸；填写属性时同步建立追溯矩阵；形式化片段只覆盖高风险逻辑，避免过度形式化拖慢进度。

评审时重点检查四类问题：一是歧义词与未量化词；二是验证方法与验证准则不匹配；三是属性缺失或前后矛盾；四是需求之间冲突或重复。评审记录应回写到需求属性中的状态与变更记录，形成可审计的编写闭环。

综上，结构化模板提供承载骨架，自然语言与形式化描述形成互补表达，需求属性支撑全生命周期管理，可验证性准则作为质量闸门。四者协同，才能让航空软件 SRS 真正成为设计、编码与验证共同依赖的工程基线。