第四章 需求捕获与编写：从系统需求到软件需求分解、需求编写规范（清晰、无歧义、可验证）
在DO-178C的体系框架中，需求不仅是开发活动的起点，更是验证活动、配置管理和质量保证的共同基准。需求工程的质量直接决定了适航取证的成本与周期。本章聚焦于两个核心命题：一是如何从系统需求中正确分解出软件需求，二是如何编写出符合“清晰、无歧义、可验证”标准的软件需求条目。我们将从系统需求与软件需求的层级关系出发，深入探讨需求分解的方法论、编写规范、验证属性定义，并结合实际案例剖析常见误区。
4.1 系统需求与软件需求的层级关系
在DO-178C的语境下，需求并非单一层次的概念，而是由飞机级需求、系统需求、软件高层需求和软件低层需求构成的层级体系。系统需求（System Requirements, SR）来源于飞机级功能需求与安全评估过程（如ARP4754A、ARP4761），描述了系统应实现的功能、性能、接口以及安全性约束。软件需求（Software Requirements, SRS）则是从系统需求中分配给软件部分的需求子集，加上软件自身派生出的需求（如资源占用、时序约束、容错策略等）。
软件需求进一步细分为高层需求（High-Level Requirements, HLR）和低层需求（Low-Level Requirements, LLR）。高层需求描述软件的功能行为、性能指标和接口特征，是软件架构设计的输入；低层需求则细化到软件单元级别，能够直接指导源代码实现，并且必须能够被验证（如通过单元测试、静态分析或评审）。DO-178C表A-3明确要求：系统需求到软件需求之间必须建立双向可追溯性，且软件需求必须满足完整性、一致性和可验证性。
4.2 需求分解的操作流程与方法
从系统需求到软件需求的分解不是简单的文字改写，而是一个系统化的工程决策过程。推荐采用以下五步法：
- 需求分类与筛选：将系统需求按功能、性能、接口、安全、维护性等类别进行归类，识别出与软件相关的部分。例如，系统需求中的“当检测到发动机超温时，应在2秒内触发告警”属于软件功能需求；而“告警音压不低于85dB”则属于硬件需求，不应纳入软件需求。
- 需求分配与追溯：将软件相关的系统需求逐条映射到软件需求条目，建立SR→SRS的追溯关系。对于无法直接分配的派生需求（如软件自监控、内存管理策略），需记录派生理由，并确保其不违背系统级约束。
- 高层需求定义：基于软件架构视角，将SRS组织为功能模块、数据流、状态机等高层描述。高层需求应覆盖所有系统需求，且不引入未经验证的额外功能。
- 低层需求细化：将高层需求分解到软件单元级别，明确输入/输出、处理逻辑、异常处理、时序约束、资源使用等细节。低层需求必须达到“程序员无需猜测即可编码”的详细程度。
- 验证属性标注：为每条低层需求标注验证方法（测试、分析、评审或组合），并确保验证方法可行。例如，对于“系统在50ms内响应”的需求，应标注“通过定时测试验证”。
| 需求层级 | 典型内容 | 验证方式 | 追溯关系 |
|---|---|---|---|
| 系统需求（SR） | “当燃油压力低于阈值时，系统应在1秒内切换至备用泵” | 系统集成测试 | ← 飞机级需求 |
| 软件高层需求（HLR） | “软件应监控燃油压力传感器数据，并在压力低于阈值时输出切换指令” | 软件集成测试 | ← SR-0123 |
| 软件低层需求（LLR） | “当压力值< 5.0 psi持续50ms时，将输出端口P3置为高电平” | 单元测试/静态分析 | ← HLR-0045 |
4.3 需求编写规范：清晰、无歧义、可验证
需求编写的质量直接决定了后续设计、编码和验证的效率。DO-178C虽然没有规定具体的编写格式，但适航审查中普遍遵循以下规范：
- 单一性：每条需求只描述一个功能或约束，避免“并且”“同时”等连接词。例如，“系统应检测超温并触发告警”应拆分为“系统应检测超温”和“系统应在超温时触发告警”两条需求。
- 无歧义：使用量化术语和标准定义，避免“大约”“快速”“正常”等模糊词汇。例如，“快速响应”应改为“在100ms内完成响应”。
- 可验证：每条需求必须能够通过测试、分析、评审或组合方式进行验证。如果无法设计验证方法，则需求本身不完整。
- 完整性：需求应覆盖正常功能、异常处理、边界条件、性能指标和接口协议。例如，对于通信接口需求，应明确数据格式、波特率、校验方式、超时重传机制等。
- 一致性：需求之间不得相互冲突，术语定义应统一。建议建立项目术语表，确保“故障”“失效”“错误”等词汇含义唯一。
4.4 案例拆解：燃油压力监控模块的需求分解
以下通过一个实际案例展示从系统需求到低层需求的完整分解过程。该案例基于某型飞机燃油系统的压力监控功能，涉及传感器数据采集、阈值判断、告警输出和故障容错。
背景与约束：系统需求SR-0123规定：“当燃油压力低于5.0 psi持续超过50ms时，系统应在1秒内切换至备用泵，并触发驾驶舱告警。”该功能由软件和硬件共同实现。硬件负责传感器信号调理和A/D转换，软件负责数据处理和逻辑判断。适航审查要求该功能达到DAL-B等级，即需要满足DO-178C表A-3的全部目标。
初始现象与目标：在项目初期，软件团队直接将SR-0123复制为软件需求，导致后续设计时无法确定“压力值”是原始ADC值还是滤波后的物理值，也无法确定“1秒内”的计时起点。这造成了编码阶段的返工和验证用例的模糊。
分析判断过程：需求工程师与系统工程师、硬件工程师共同评审后，将SR-0123分解为以下软件需求：
- HLR-0045：软件应以10Hz频率采集燃油压力传感器数据，并转换为物理压力值（单位：psi）。
- HLR-0046：软件应对压力值进行滑动平均滤波，窗口大小为5个采样点。
- HLR-0047：当滤波后的压力值低于5.0 psi且持续时间超过50ms时，软件应输出备用泵切换指令。
- HLR-0048：软件应在输出切换指令的同时，向显示系统发送告警消息。
进一步细化低层需求：
LLR-0101: 当采样计数器达到5时，计算最近5次压力值的算术平均值。
LLR-0102: 若平均值 < 5.0 psi，则启动50ms定时器；若平均值 ≥ 5.0 psi，则重置定时器。
LLR-0103: 当定时器达到50ms时，将输出端口P3置为高电平（切换指令）。
LLR-0104: 在P3置高电平的同时，调用Send_Alert_Message()函数，参数为ALERT_LOW_PRESSURE。实际操作步骤：需求工程师使用需求管理工具（如DOORS或Reqtify）建立了SR-0123→HLR-0045~0048→LLR-0101~0104的追溯矩阵。同时，为每条低层需求标注了验证方法：LLR-0101通过单元测试验证，LLR-0102通过边界值测试验证，LLR-0103通过时序分析验证，LLR-0104通过接口测试验证。
结果对比：分解后的需求使开发团队明确了滤波算法、阈值判断逻辑和输出时序，编码阶段未出现歧义。验证阶段，测试团队基于低层需求设计了12个测试用例，覆盖了正常、边界和异常场景，需求覆盖率达到了100%。相比之前直接复制系统需求的做法，返工成本降低了约40%。
风险与代价：需求分解过程中，发现系统需求未明确“压力值”的物理单位，导致软件团队与硬件团队在接口定义上产生分歧。最终通过增加一条接口需求（SRS-IF-001：压力数据以psi为单位，16位无符号整数，分辨率0.1psi）解决了问题。这提醒我们，需求分解时必须同步定义接口需求。
4.5 需求评审与质量检查清单
需求评审是确保需求质量的关键环节。建议在需求分解完成后，组织系统工程师、软件架构师、测试工程师和适航代表进行联合评审。评审应重点关注以下方面：
| 检查项 | 通过标准 | 常见问题 |
|---|---|---|
| 可追溯性 | 每条软件需求都能追溯到系统需求，且无遗漏 | 派生需求未记录来源，或系统需求未完全分配 |
| 无歧义性 | 术语定义唯一，数值量化，无模糊词汇 | 使用“尽可能”“必要时”等模糊表述 |
| 可验证性 | 每条需求至少有一种可行的验证方法 | 需求描述过于笼统，无法设计测试用例 |
| 完整性 | 覆盖正常、异常、边界、性能、接口场景 | 缺少异常处理需求或时序约束 |
| 一致性 | 需求之间无冲突，术语使用统一 | 不同需求对同一参数定义不同 |
评审结束后，应形成需求评审报告，记录发现的问题和整改措施。对于DAL-A/B等级的项目，需求评审记录将作为适航取证证据的一部分，需纳入配置管理。
总结而言，需求捕获与编写是DO-178C适航认证中最具杠杆效应的活动。一个清晰、无歧义、可验证的需求体系，能够显著降低后续设计、编码、测试和审查的成本。团队应建立需求编写规范、分解流程和评审机制，并通过工具链实现需求追溯的自动化管理。在实际项目中，建议每两周进行一次需求质量抽查，及时发现并纠正偏差，确保需求基线的健康度。