第四章 需求管理工具配置：需求追溯矩阵建立与变更管理流程

好，咱们接着聊需求管理工具配置。这一章，我重点讲两个核心模块：需求追溯矩阵和需求变更管理流程。这两个东西，说白了就是功能安全开发的“生命线”。

我在多个项目里都见过，因为追溯矩阵没建好，或者变更流程乱套，最后导致评审过不了，甚至要返工重来。嗯，咱们今天就把这块彻底讲透。

4.1 需求追溯矩阵（RTM）的建立

需求追溯矩阵，英文叫 Requirements Traceability Matrix，简称 RTM。它的作用是什么？一句话：确保每个安全需求都有来源，都有归宿。

你想想看，ISO 26262 里明确要求，从安全目标到功能需求，再到技术需求，最后到测试用例，必须能双向追溯。没有 RTM，你怎么证明你的开发是完整的？

4.1.1 追溯矩阵的结构

我个人习惯用表格来管理 RTM。结构其实不复杂，但字段一定要全。下面是我常用的模板：

需求ID	需求类型	需求描述	来源	实现模块	测试用例ID	状态
REQ-001	安全目标	制动系统响应时间 < 200ms	ISO 26262-3	BrakeCtrl	TC-001, TC-002	已实现
REQ-002	功能需求	制动踏板位置传感器故障时，进入降级模式	REQ-001	BrakeCtrl, Diag	TC-003	已验证
REQ-003	技术需求	ADC采样周期 ≤ 10ms	REQ-002	HAL_ADC	TC-004	已实现

你看，每一行就是一个需求。从安全目标一直追溯到技术实现和测试。这样评审的时候，拿着这个表，一目了然。

4.1.2 工具中的配置方法

我常用的是 DOORS 和 Polarion。不过不管用什么工具，配置思路是一样的。以 Polarion 为例：

1. 创建工作项类型：分别创建“安全目标”、“功能需求”、“技术需求”、“测试用例”等工作项。
2. 建立链接关系：在需求之间建立“派生自”、“实现为”、“验证于”等链接。
3. 生成追溯视图：利用工具自带的追溯矩阵视图，一键生成双向追溯表。

4.2 需求变更管理流程配置

需求变更是功能安全开发里最头疼的事。为什么？因为一个需求的变更，可能会引发一连串的连锁反应。安全分析要重做，测试用例要更新，甚至架构都要调整。

所以，变更管理流程必须严格，但也不能僵化。我总结了一套“三步走”的流程：

4.2.1 变更请求的提出

任何变更，都必须通过正式的变更请求（Change Request, CR）来发起。不能口头说改就改。

在工具里，我通常会配置一个“变更请求”工作项，包含以下字段：

• 变更描述：具体要改什么？
• 变更原因：为什么改？是客户要求，还是发现了缺陷？
• 影响分析：这个变更会影响哪些模块？哪些需求？
• 优先级：紧急、高、中、低。

4.2.2 变更评审与批准

CR 提交后，必须经过变更控制委员会（CCB）评审。CCB 通常由项目经理、系统工程师、功能安全工程师、测试负责人组成。

评审的核心是影响分析。我记得有一次，一个看似简单的“修改报警阈值”的变更，经过影响分析后发现，它会影响三个安全机制，需要重新做 FMEA。所以，千万别小看任何变更。

4.2.3 变更实施与验证

变更批准后，进入实施阶段。实施完成后，必须进行回归测试，确保变更没有引入新的问题。

在工具里，我会配置一个状态机：

状态流转：
新建 → 待评审 → 已批准 → 实施中 → 已验证 → 已关闭
                ↓
             已拒绝

每个状态变更，都要记录操作人和时间。这样审计的时候，有据可查。

4.3 工具链中的自动化配置

手动维护 RTM 和变更流程，效率太低。我建议你利用工具链的自动化能力。

比如，在 Polarion 里，我可以配置：

• 自动链接：当创建一个新的技术需求时，自动与父级功能需求建立链接。
• 变更通知：当某个需求发生变更时，自动通知所有关联的测试人员。
• 状态校验：当需求状态变为“已验证”时，自动检查是否所有子需求都已实现。

这些自动化配置，说白了就是减少人为失误。你想想看，人总有疏忽的时候，但工具不会。

好，这一章就到这里。下一章，咱们聊聊配置管理工具，看看怎么用 Git 和 SVN 来管理功能安全相关的代码和文档。