3. 航空软件需求工程基础

航空软件与普通商业软件最大的区别在于：它通常处于适航审定链条之中，需求本身既是设计输入，也是后续验证的依据。因此，需求工程的第一步不是“写需求”，而是把需求放进一个可分类、可追溯、可验证的框架里。本节围绕四个问题展开：需求分几类、需求从哪里来、谁提出需求、用什么方法把需求捕获出来。

一、需求分类：功能、性能、接口、安全

在航空软件语境下，需求分类不是学术上的标签，而是直接决定后续验证方式。功能需求描述系统“做什么”，例如“当迎角超过阈值时，飞控软件应在 50 ms 内输出失速告警标志”。性能需求描述“做到什么程度”，包括时间、精度、吞吐、资源占用等，例如“姿态解算周期不大于 20 ms，俯仰角误差不超过 0.5°”。接口需求描述“与谁交换什么”，包括总线协议、数据格式、采样率、离散量定义，例如“通过 ARINC 429 以 100 Hz 接收大气数据计算机的高度字”。安全需求描述“失效时如何保持安全”，包括失效检测、降级、隔离、冗余管理，例如“当双通道比较结果不一致超过 3 个周期时，软件应进入安全模式并置位故障标志”。

四类需求并非彼此独立。一条性能指标往往由安全等级推导而来，一条接口定义又可能成为安全监控的输入。实际工作中建议为每条需求标注类别、来源、安全等级（如 DAL A~E）和验证方法，形成需求属性表，而不是只写一句自然语言描述。

二、需求来源：从规章到运行经验

航空软件需求主要有五个来源。第一是适航规章与行业标准，如 CCAR-25 部、DO-178C、DO-254、ARP4754A，它们不直接给出软件功能，但规定了安全等级、过程目标和验证要求，是安全需求的顶层来源。第二是系统级分配，飞机级功能经过系统架构分解后，落到软件上的功能、性能和接口指标，这是软件需求最直接的来源。第三是利益相关者诉求，包括飞行员、维修人员、地面操作员、适航审查方等。第四是运行与维护经验，例如某型飞机在高原机场出现告警延迟，由此产生新的性能需求。第五是相似机型与历史数据，包括故障报告、使用困难报告和既有需求库。

需要强调的是，来源不同，需求的“硬度”也不同。规章和系统分配通常是强制性的，利益相关者诉求需要经过工程权衡，运行经验则要转化为可测量的指标才能进入需求库。实际项目中，每条需求都应记录来源编号，以便在审查时回答“这条需求为什么存在”。

三、利益相关者识别：谁真正影响需求

利益相关者识别不是列一张人名表，而是找出对需求有实质影响、且其诉求可能相互冲突的角色。航空软件项目中常见的角色包括：飞行员（关注告警清晰度、操作负荷）、系统工程师（关注功能分配与接口边界）、软件架构师（关注可实现性与资源约束）、适航审查方（关注安全目标与追溯完整性）、维修与地勤（关注故障隔离与复位操作）、以及客户与运营方（关注成本、航线适应性）。

识别方法可以采用“角色—关注点—影响需求类别”的矩阵。例如飞行员关注告警及时性，主要影响功能与性能需求；适航审查方关注失效概率与验证证据，主要影响安全需求；系统工程师关注接口定义，主要影响接口需求。通过矩阵可以快速发现哪些角色尚未被覆盖，避免需求评审时突然出现“遗漏的甲方”。

四、需求捕获方法：从访谈、场景到原型

需求捕获不是一次会议，而是多种方法组合。常用方法包括：结构化访谈、运行场景走查、文档分析、原型演示、观察与任务分析、以及基于模型的捕获。以“失速告警软件”为例，可以这样组合使用：

• 结构化访谈：与飞行员确认告警触发条件、告警方式（视觉/听觉/触觉）和抑制逻辑，形成初始功能需求。
• 运行场景走查：模拟起飞、巡航、进近、复飞四个阶段，记录每个阶段对告警的期望响应，识别性能需求（如进近阶段告警延迟不超过 100 ms）。
• 文档分析：查阅系统安全评估报告，提取失效模式与安全需求，例如“迎角传感器双通道不一致时禁止告警”。
• 原型演示：用座舱显示原型让飞行员评估告警颜色、闪烁频率和文字措辞，捕获人因相关需求。
• 基于模型的捕获：用状态机描述告警状态（正常、预警、告警、抑制、故障），从状态迁移中导出接口与安全需求。

捕获过程中要同步记录“需求—来源—利益相关者—验证方法”四元组。例如一条需求可以记录为：需求编号 REQ-ALT-012，内容“当迎角超过失速阈值且空速低于 180 kt 时，在 80 ms 内输出失速告警”，类别为功能+性能，来源为系统分配与飞行员访谈，利益相关者为飞行员与适航审查方，验证方法为功能测试与时序测量。这样在后续验证阶段，可以直接从需求追溯到测试用例，形成闭环。

总结来看，航空软件需求工程的基础工作可以概括为：用分类框架把需求分清楚，用来源追溯把需求立住，用利益相关者矩阵把角色找全，用多种捕获方法把需求挖深。这四件事做扎实，后续的需求分析、验证用例设计和适航审查才有稳定的起点。