4. 需求追溯的核心概念

在 AUTOSAR 项目的交付体系中，需求追溯并不是“把需求编号填进表格”这么简单。它本质上是在整个 V 模型开发链路上，建立并维护一组可验证、可查询、可审计的关联关系。ETAS 工具链（如 DOORS、RTA、ISOLAR、INCA 等）之所以强调追溯，是因为一旦某个安全目标或功能需求发生变更，团队必须能在有限时间内回答三个问题：它影响了哪些设计、代码、测试？它由哪些上游需求派生而来？当前实现是否仍然满足它？ 本节围绕追溯链、追溯粒度、前向追溯、后向追溯、双向追溯与影响分析六个核心概念展开，帮助读者建立可落地的追溯思维。

追溯链：从需求到验证的完整路径

追溯链（Traceability Chain）是指从需求源头出发，经过设计、实现、集成、测试，最终到达验证证据的一条可导航路径。在 AUTOSAR 语境下，一条典型的追溯链可能表现为：

安全目标 → 技术安全需求 → 软件安全需求 → SWC 端口/接口定义 → Runnable 实现 → 单元测试用例 → 集成测试用例 → 整车验证报告

这条链上的每个节点都是一个“可追溯项”（Traceable Item），节点之间的连线就是追溯关系。追溯链的价值在于：当链上任意一个节点发生变化时，可以沿着连线快速定位受影响的下游节点。例如，某个软件安全需求的 ASIL 等级从 B 提升到 D，那么所有下游的测试用例都必须重新评估覆盖率和独立性要求。

需要注意的是，追溯链不是一条直线，而是一张有向图。一个上游需求可能派生多个下游需求，一个测试用例也可能覆盖多个需求。因此，追溯链的管理必须依赖工具中的链接关系，而不是手工维护的电子表格。

追溯粒度：决定追溯成本与有效性的关键参数

追溯粒度（Traceability Granularity）指的是追溯关系建立在哪一层级的对象上。粒度太粗，追溯失去意义；粒度太细，维护成本急剧上升。常见的粒度层级包括：

• 需求级：以单条需求为最小追溯单元，适合功能需求和安全需求。
• 架构级：以 SWC、端口、接口、Runnable 为追溯单元，适合设计阶段。
• 代码级：以函数、代码行或代码段为追溯单元，适合安全关键代码。
• 测试级：以测试用例、测试步骤或断言为追溯单元，适合验证阶段。

在 ETAS 项目实践中，推荐采用“需求级 + 架构级”为主、“代码级”为辅的混合粒度策略。对于 ASIL D 的安全需求，可以细化到函数级；对于 QM 级别的舒适性功能，保持需求级即可。粒度选择应在项目追溯计划中明确，并保持全项目一致。

前向追溯与后向追溯：方向决定用途

前向追溯（Forward Traceability）是指从上游需求指向下游实现与验证的追溯方向，回答“这个需求被谁实现了、被谁验证了”。后向追溯（Backward Traceability）则是从下游对象指向上游需求的追溯方向，回答“这个代码/测试为什么存在、它服务于哪条需求”。

两者的用途截然不同：

• 前向追溯用于变更影响分析和覆盖度检查。例如，检查每条安全需求是否都有对应的测试用例，是否存在“孤儿需求”。
• 后向追溯用于范围确认和审计举证。例如，在功能安全审计中，审核员会随机抽取一段代码，要求你证明它对应哪条需求、哪条安全目标。

在工具中，前向追溯通常表现为“需求 → 链接 → 下游对象”的查询视图，后向追溯则表现为“下游对象 → 链接 → 上游需求”的反向查询。两者必须同时存在，才能构成完整的追溯能力。

双向追溯：不是两个单向的简单相加

双向追溯（Bidirectional Traceability）要求任意两个相关联的追溯项之间，都能从任一方向导航到对方。它不仅仅是“前向 + 后向”的机械叠加，而是要求链接关系具有一致性和完整性：

• 如果需求 A 链接到测试用例 T，那么从 T 也必须能导航回 A。
• 如果链接被删除或修改，两个方向必须同步更新，不能出现“单向残留”。
• 链接本身应携带属性，如链接类型（派生、满足、验证、依赖）、创建时间、责任人、状态。

在 ETAS 工具链中，双向追溯通常通过统一的链接数据库实现，而不是在两个文档中分别维护。这样做的目的是保证追溯关系的单一数据源，避免版本不一致导致的审计风险。

影响分析：追溯体系的最终价值出口

影响分析（Impact Analysis）是追溯体系最核心的工程价值。当一条需求发生变更时，影响分析要回答：哪些设计、代码、测试、文档、标定数据需要同步修改？修改的工作量和风险有多大？

一个可落地的影响分析流程通常包括以下步骤：

1. 变更识别：确定变更的需求对象及其变更类型（新增、修改、删除）。
2. 前向遍历：沿前向追溯链，找出所有直接和间接下游对象。
3. 影响分类：将下游对象按类型分类（设计、代码、测试、标定、文档），并评估每类的影响程度。
4. 风险评级：结合 ASIL 等级、变更范围、接口耦合度，给出高/中/低风险评级。
5. 行动项生成：为每个受影响对象生成具体的修改任务和验证任务。
6. 闭环确认：修改完成后，通过后向追溯确认所有下游对象已更新，且追溯链完整。

下面这张图展示了从需求变更触发，到前向追溯、影响分类、后向确认的完整影响分析路径，同时也体现了追溯链、追溯粒度和双向追溯在其中的作用。

追溯粒度与影响分析的联动关系

追溯粒度直接决定了影响分析的精度。如果粒度只到需求级，那么当需求变更时，你只能知道“某个 SWC 受影响”，但无法定位到具体是哪个 Runnable 或哪段代码。如果粒度细化到函数级，影响分析可以精确到代码行，但维护成本会显著增加。

在实际项目中，建议采用分层粒度策略：安全目标到技术安全需求保持需求级；技术安全需求到软件架构保持架构级；软件安全需求到代码保持函数级；代码到测试用例保持测试用例级。这样既保证了安全关键路径的精度，又避免了全项目过度细化带来的维护负担。

追溯关系的属性设计

一条追溯链接不仅仅是“A 指向 B”，它应该携带足够的属性来支持影响分析和审计。建议至少包含以下字段：

这些属性在 ETAS 工具链中通常由链接模块统一管理，并支持导出为追溯矩阵（Traceability Matrix）供审计使用。追溯矩阵的每一行代表一条链接，列则对应上述属性字段。

影响分析的实际操作示例

假设某项目在 ETAS ISOLAR 中管理需求与架构，某条软件安全需求 SW-Safety-Req-042 的 ASIL 等级从 B 提升到 D。影响分析的操作过程如下：

1. 在需求管理工具中打开 SW-Safety-Req-042，查看其前向链接，找到关联的 3 个 Runnable 和 5 个测试用例。
2. 对每个 Runnable，检查其代码实现是否满足 ASIL D 的独立性要求（如是否存在共因失效）。
3. 对每个测试用例，检查其覆盖率指标是否达到 ASIL D 要求的 MC/DC 覆盖。
4. 生成影响分析报告，列出需要修改的代码文件、需要补充的测试用例、需要更新的标定数据。
5. 修改完成后，通过后向追溯逐一确认每个下游对象已更新，且链接状态为“已确认”。
6. 最后导出追溯矩阵，作为功能安全审计的举证材料。

这个过程的核心逻辑是：前向追溯定位影响范围，后向追溯确认闭环，双向追溯保证一致性，追溯粒度决定分析精度。四者缺一不可。

总结来说，追溯链是骨架，追溯粒度是精度调节器，前向追溯和后向追溯是两种导航方向，双向追溯是一致性保障，影响分析则是整个追溯体系的价值出口。在 AUTOSAR 项目中，只有把这六个概念落实到工具配置、流程定义和日常操作中，追溯体系才能真正支撑功能安全交付和变更管理。