📚 课程目录第3章需求工程基础

3、需求工程基础：需求类型（系统需求、软件需求、高层/低层需求）、需求属性与质量特征

在DO-178C的适航认证语境下，需求工程并非简单的“写文档”，而是整个软件生命周期中唯一能够将“飞机级功能期望”逐步转化为“可验证的软件行为”的桥梁。如果需求不完整、不精确或不可追溯，后续的设计、编码与验证活动都将建立在流沙之上。本章将深入剖析需求在DO-178C框架下的类型划分、属性定义以及质量评判标准，帮助学员建立一套能够通过局方审查的“需求思维”。

上图展示了DO-178C需求体系的核心分层结构。从系统需求到软件高层需求（HLR），再到软件低层需求（LLR），每一层都承担着不同的抽象级别与验证职责。值得注意的是，这种分层并非简单的文档拆分，而是为了在发生故障时能够精准定位问题源头，并在需求变更时评估影响范围。下面我们将逐一拆解这些需求类型的具体定义、编写要点以及它们之间的边界。

3.1 需求类型的核心原理与边界划分

系统需求（System Requirements）是飞机级或系统级的顶层描述，通常由系统工程师编写，关注“系统做什么”以及“性能达到什么水平”。例如，“当飞机高度低于500英尺时，近地告警系统应在2秒内发出视觉和听觉告警”。这类需求不关心软件如何实现，只描述系统与外部环境（包括飞行员、其他子系统）的交互。

软件高层需求（High-Level Requirements, HLR）是从系统需求中分配给软件的部分，它描述了软件的功能、性能、接口和安全性约束。HLR仍然保持一定的抽象度，不涉及具体的数据结构或算法实现。例如，“软件应监测气压高度信号，并在高度低于500英尺时触发告警输出”。HLR是软件验证（特别是基于需求的测试）的主要依据。

软件低层需求（Low-Level Requirements, LLR）是能够直接用于编写源代码的需求，它描述了软件组件或单元的具体行为。LLR通常包含精确的数学公式、状态转换逻辑、数据流定义或接口协议细节。例如，“当气压高度值小于等于500且持续200ms时，将告警状态寄存器置位为0x01”。在DO-178C中，LLR与源代码之间应建立一一对应的追溯关系。

关键判断标准：如何区分HLR与LLR？最实用的方法是“源代码测试法”——如果不需要查看源代码，仅凭该需求就能编写出黑盒测试用例，那么它是HLR；如果必须了解内部数据结构或算法才能编写测试，那么它是LLR。另一个辅助标准是“分解程度”：HLR通常对应一个软件组件（如“数据采集模块”），而LLR对应一个函数或一个状态机（如“CRC校验函数”）。

3.2 需求属性的定义与管理

需求属性是附加在每条需求上的元数据，用于支持项目跟踪、变更影响分析和适航审查。在DO-178C实践中，以下属性是必填或强烈建议的：

属性名称	说明	示例值	DO-178C关联
唯一标识符	全局唯一的ID，便于追溯	REQ_SW_00123	6.4.2 追溯性
需求来源	父级需求或系统文档编号	SYS_REQ_045	分配与追溯
验证方法	测试、评审、分析或演示	Test (MC/DC)	6.4.4 验证过程
关键性等级	与飞机级功能危害性相关	Level A	2.2 软件等级
状态	草稿、已评审、已批准、已变更	Approved	配置管理
变更历史	记录修订版本与原因	V2.1 增加边界条件	7.2 变更控制

属性管理的最佳实践是使用需求管理工具（如DOORS、Reqtify或Polarion）进行自动化追踪。但工具只是辅助，关键在于团队必须定义清晰的属性填写规范。例如，验证方法属性必须在需求评审前由验证工程师确认，而不是由开发人员单方面决定。在适航审查中，审查代表会随机抽取需求，检查其属性是否完整且与项目计划一致。

3.3 需求质量特征与检查方法

DO-178C虽然没有单独列出“需求质量”章节，但其隐含要求贯穿于“需求标准”和“评审”活动中。以下是经过局方认可的质量特征清单及检查方法：

正确性：需求必须真实反映系统/软件的实际功能。检查方法：与系统需求进行交叉比对，邀请系统工程师参与评审。
无歧义性：每条需求只能有一种解释。检查方法：使用“应/必须/可以”等强动词，避免“可能”“大概”等模糊词汇。例如，“软件应处理异常情况”是典型的歧义需求，应改为“当输入数据校验失败时，软件应丢弃该帧并置位错误标志”。
完整性：需求集合覆盖所有系统分配的功能，包括异常处理、边界条件和性能约束。检查方法：使用基于场景的评审，列出所有可能的输入组合和故障模式。
一致性：需求之间不能相互矛盾。检查方法：使用需求管理工具进行冲突检测，定期召开需求走查会议。
可验证性：每条需求都能通过某种方法（测试、分析、评审）证明其被满足。检查方法：如果无法写出验证步骤，说明需求过于抽象或复杂。
可追踪性：每条需求都能向上追溯到系统需求，向下追溯到设计/代码/测试。检查方法：生成追溯矩阵，检查是否有“孤儿需求”（无来源）或“悬空需求”（无实现）。

常见误区警示：许多项目团队将“需求数量多”等同于“需求完整”。实际上，DO-178C更关注需求的质量密度——即每条需求是否精确、无歧义且可验证。一条冗长但含糊的需求，其危害远大于三条简洁明确的需求。此外，不要将设计约束误写为需求。例如，“软件使用C语言编写”是设计决策，不应出现在需求中，除非有适航或性能的强制要求。

3.4 实战场景：从系统需求到LLR的分解案例

我们以某型飞机的燃油泵控制软件为例，演示需求分解的完整过程。该软件属于Level A等级，因为燃油泵失效可能导致发动机空中停车。

初始系统需求（来自飞机级文档）：
“当左油箱油量低于200千克时，系统应在5秒内关闭左燃油泵，并点亮驾驶舱告警灯。”

分析过程：系统工程师将这条需求分配给软件和硬件。硬件负责执行继电器动作，软件负责逻辑判断和告警输出。软件团队进一步分析：油量信号来自传感器，通过ARINC 429总线传输；告警灯由离散输出通道控制；关闭燃油泵需要向电源管理模块发送控制指令。

生成的HLR（共3条）：

HLR-01：软件应通过ARINC 429接口周期性地采集左油箱油量数据，采集周期不超过100ms。
HLR-02：当连续3次采集到的油量值均低于200千克时，软件应通过离散输出通道发送“关闭左泵”指令，并在同一周期内点亮告警灯。
HLR-03：软件应记录每次告警触发的时间戳和油量值，供维护系统查询。

进一步细化的LLR（以HLR-02为例）：

LLR-02-01：定义全局变量 fuel_level_left（浮点型）。
LLR-02-02：当 ARINC 429 接收中断标志位为1时，读取油量数据并更新 fuel_level_left。
LLR-02-03：若 fuel_level_left < 200.0 且连续计数 counter >= 3，则置位离散输出寄存器 bit3（左泵关闭）和 bit5（告警灯）。
LLR-02-04：若 fuel_level_left >= 200.0，则清零 counter。
LLR-02-05：counter 在每次有效数据更新时递增，在数据无效或超时时清零。

验证与复盘：在代码评审中，发现LLR-02-03未定义“连续3次”的时间窗口。如果3次采集跨越了10秒，是否仍应触发？经过与系统工程师确认，补充了约束“连续3次采集必须在500ms内完成，否则计数器清零”。这一补充避免了在传感器间歇性故障时产生误告警。最终，该需求被追溯至HLR-02，并设计了基于MC/DC覆盖的测试用例，验证了“连续3次低于阈值”和“第3次高于阈值”两种边界情况。

经验总结：需求分解过程中，最容易被忽视的是时序约束和数据有效性。在编写LLR时，务必明确“数据多久算过期”“连续多少次算有效”“故障时采用什么默认值”。这些细节在系统需求中往往不会写明，需要软件工程师主动与系统团队沟通确认。建议在需求评审表中增加“时序/边界检查”一栏，由独立评审员逐条确认。

3.5 常见误区与总结复盘

在多年的适航认证咨询中，我们总结了以下高频问题，供学员对照自查：

误区描述	潜在后果	纠正措施
将HLR写成系统需求的复制品	软件验证无法覆盖真实逻辑	HLR必须体现软件特有的处理逻辑（如滤波、冗余管理）
LLR过于详细，直接描述代码行	需求变更频繁，维护成本高	LLR应描述“做什么”而非“怎么用代码实现”
忽略非功能性需求（性能、内存、时序）	集成测试时发现资源不足	在HLR中明确性能指标，如“最坏情况执行时间不超过2ms”
需求属性填写随意，无专人负责	审查时无法提供有效追溯	指定需求配置管理员，定期审计属性完整性

本章核心要点：需求类型划分的本质是管理复杂度——系统需求解决“为什么做”，HLR解决“做什么”，LLR解决“具体怎么做”。需求属性是支撑追溯和变更管理的骨架，而质量特征则是确保需求本身“健康”的体检指标。在实际项目中，建议团队在项目启动初期就制定《需求编写规范》和《需求评审检查单》，将本章所述的原则固化为流程的一部分。记住：在DO-178C的世界里，没有“完美”的需求，只有“足够清晰且可验证”的需求。