4、需求管理：需求追溯矩阵、需求变更流程、需求版本冻结

说到安全气囊系统的需求管理，我脑子里立刻浮现出几年前的一个项目。那时候我们团队刚接手一个平台化项目，需求文档乱得像一锅粥。嗯，后来花了整整两周才把需求理清楚。今天我就把这块的经验掰开了揉碎了讲给你听。

4.1 需求追溯矩阵——别让需求「失联」

需求追溯矩阵，说白了就是一张「需求地图」。它告诉你每个需求从哪来，到哪去。我个人习惯叫它 RTM（Requirements Traceability Matrix）。

为什么要做这个？你想想看，安全气囊系统涉及的功能安全等级是 ASIL-D，最高等级。一个需求如果「失联」了，后果可能是致命的。

我在项目中遇到过一件事：一个关于「点火回路诊断时间」的需求，在系统需求文档里写的是「≤5ms」，但到了软件需求文档里变成了「≤10ms」。如果没有 RTM，这种差异可能直到系统集成测试才发现。你想想看，那得多被动？

RTM 的格式其实很简单，我一般用表格来管理：

需求ID	需求描述	来源	软件需求ID	测试用例ID	状态
REQ-001	点火回路诊断时间 ≤5ms	客户需求 V1.2	SW-REQ-015	TC-023	已实现
REQ-002	碰撞检测阈值 20g±2g	系统需求 V2.0	SW-REQ-032	TC-047	已验证
REQ-003	故障自检周期 100ms	功能安全需求	SW-REQ-078	TC-112	待评审

4.2 需求变更流程——别让变更「失控」

需求变更是家常便饭。但安全气囊系统的变更，必须走严格的流程。为什么？因为一个看似微小的变更，可能影响整个系统的功能安全。

我记得有一次，客户提出要修改碰撞检测的阈值。看起来只是改一个参数，对吧？但实际上，这个变更涉及了传感器选型、算法逻辑、标定参数、测试用例……整整影响了 12 个模块。

我建议的变更流程是这样的：

1. 变更申请：提交变更请求，说明变更原因和预期影响
2. 影响分析：评估变更对功能安全、性能、成本、进度的影响
3. 变更评审：由 CCB（变更控制委员会）评审，决定是否批准
4. 变更实施：在受控环境下修改需求、设计、代码、测试
5. 变更验证：执行回归测试，确保变更没有引入新问题
6. 变更关闭：更新所有相关文档，关闭变更请求

变更流程中，我最看重的是「影响分析」这个环节。它需要回答几个问题：

• 这个变更会影响哪些模块？
• 会影响功能安全等级吗？
• 需要重新做哪些测试？
• 会影响已经冻结的版本吗？

说白了，影响分析做得好，变更就成功了一半。

4.3 需求版本冻结——别让需求「漂移」

需求版本冻结，是项目开发中的一个里程碑。它意味着需求不再变动，开发团队可以安心地基于这个版本进行设计和编码。

但冻结不是随便说说的。我一般会分几个阶段来冻结：

冻结阶段	时间点	冻结范围	允许的变更
初步冻结	系统需求评审后	系统需求	仅限缺陷修复
基线冻结	软件需求评审后	系统需求 + 软件需求	需 CCB 批准
发布冻结	集成测试前	所有需求	原则上不允许变更

你可能会问：为什么不能一次性冻结？原因很简单——需求是逐步细化的。系统需求冻结了，软件需求可能还在迭代。分阶段冻结，既保证了稳定性，又保留了灵活性。

冻结之后，如果还有变更怎么办？嗯，那就走变更流程。但这时候的变更门槛会很高，需要 CCB 批准，而且必须评估对已冻结版本的影响。

我记得有一个项目，在发布冻结后客户突然要求增加一个诊断功能。我们评估后发现，这个变更会影响 5 个模块的代码，还需要重新做一轮功能安全测试。最后 CCB 决定把这个功能放到下一个版本。虽然客户不太高兴，但保证了当前版本的质量。

说白了，需求版本冻结不是不让变更，而是让变更变得「可控」。你想想看，如果需求一直在漂移，开发团队就像在流沙上盖房子，永远盖不起来。

嗯，今天就先聊到这里。下一章我会讲需求评审和确认，到时候再分享一些我在评审会上踩过的坑。