4、需求可追溯性：从高层需求到低层需求的分解，覆盖矩阵的建立
好，咱们今天聊一个在DO-178C认证中特别容易被忽视、但恰恰又是审查员盯得最紧的环节——需求可追溯性。
说白了，就是你的高层需求（HLR）是怎么一步步变成低层需求（LLR）的，中间有没有断档？有没有遗漏？有没有“凭空冒出来”的代码？
我个人习惯把这件事比作“家谱”。你想想看，爷爷（高层需求）生了爸爸（低层需求），爸爸生了儿子（代码）。如果家谱对不上，那这个家族肯定有问题。适航审查也是一样，审查员最怕的就是“代码不知道从哪来的”。
4.1 为什么可追溯性这么重要？
我在项目中遇到过好几次这样的情况：开发团队把代码写完了，功能也跑通了，结果审查员一问“你这个功能对应哪个需求？”——答不上来。嗯，这就很尴尬了。
DO-178C里明确要求：
- 每个高层需求必须分解到低层需求
- 每个低层需求必须对应到代码
- 每个代码片段必须能追溯到需求
说白了，就是不能有“孤儿代码”，也不能有“幽灵需求”。
4.2 高层需求到低层需求的分解
高层需求通常描述的是“系统要做什么”，比如“飞机在高度低于100英尺时，必须发出近地告警”。
低层需求则更具体，比如“当无线电高度表读数小于100英尺且起落架未放下时，触发告警信号，驱动音频输出”。
分解的时候，我建议遵循几个原则：
- 单一职责：一个低层需求只做一件事。别把多个逻辑揉在一起。
- 可测试：低层需求必须能写测试用例。如果写不出来，说明分解得还不够细。
- 无歧义：用词要精确。“大约”、“可能”、“适当”这类词尽量别用。
4.3 覆盖矩阵的建立
覆盖矩阵，也叫追溯矩阵。它就是一个表格，把高层需求、低层需求、测试用例、代码模块全部串起来。
我见过很多团队用Excel做这件事，说实话，小项目还行，大项目就有点吃力了。我个人习惯用专门的工具，比如DOORS或者Reqtify，但不管用什么工具，核心逻辑是一样的。
一个典型的覆盖矩阵长这样：
| 高层需求ID | 低层需求ID | 测试用例ID | 代码模块 | 状态 |
|---|---|---|---|---|
| HLR-001 | LLR-001.1 | TC-001 | gpws_alert.c | 已覆盖 |
| HLR-001 | LLR-001.2 | TC-002 | gpws_audio.c | 已覆盖 |
| HLR-002 | LLR-002.1 | TC-003 | altitude_check.c | 未覆盖 |
看到那个“未覆盖”了吗？这就是审查员最喜欢盯着的地方。我曾经有一个项目，就是因为矩阵里漏了一行，被审查员打回来重新补测试，整整拖了两周。
4.4 分解过程中的常见问题
这里我总结几个我在项目中踩过的坑：
- 过度分解：把需求拆得太碎，导致管理成本暴增。比如一个“打开阀门”的需求，非要拆成“接收指令”、“解析指令”、“驱动电机”、“反馈状态”四个低层需求。其实有些东西在代码层面合并一下完全没问题。
- 分解不足：高层需求直接变成代码，中间没有低层需求。这会导致测试用例写不出来，因为高层需求太抽象了。
- 单向追溯：只做了从需求到代码的追溯，没做反向。审查员问“这段代码对应哪个需求？”——答不上来。
嗯，这里要注意一点：分解不是越细越好。适航审查讲究的是“合理”，不是“极致”。你只要能让审查员看清楚逻辑链条，就够了。
4.5 知识体系结构图
下面这张图是我自己画的，把需求可追溯性的核心逻辑串起来了。你可以把它当作一个参考框架：
这张图其实就讲了三件事：从上往下是分解和实现，从右往左是验证，中间用矩阵把所有关系串起来。你写文档的时候，也可以照着这个逻辑来组织。
4.6 实操建议
最后，给几个实操层面的建议：
- 尽早建立矩阵：不要等到开发后期。我建议在需求评审阶段就把矩阵框架搭好，后面只是往里填内容。
- 定期审查：每周花15分钟过一遍矩阵，看看有没有新增的需求没被覆盖，有没有代码没被追溯。
- 工具辅助：如果项目规模大，别用Excel硬扛。用专业的追溯工具，能省很多时间。
- 保留变更记录：需求变了，矩阵也要跟着变。而且变更记录要保留，审查员可能会看。
好了，需求可追溯性这块就聊到这儿。说白了，它就是一张“关系网”，把需求、代码、测试全部绑在一起。网织得越密，审查员越挑不出毛病。