ASPICE双向追溯要解决的是研发过程中“每条需求能否追到实现与验证、每个测试能否追回来源需求”的问题。本文按对象与规则、建链步骤、角色分工、链路示例、闭环检查和工具承载六个部分展开，说明如何把追溯从评审前补录变成过程活动的一部分。ONES可作为承载工作项与文档关系的平台，具体能力以实际使用为准。
要点总览（TL;DR）
- 双向追溯要同时满足两个方向：从每条需求能追到承接设计、实现配置项和验证用例，从每个测试用例能追回来源需求；两个方向共用同一组链接。
- 建链前先定口径：明确追溯对象清单、唯一标识与版本规则、允许的链接类型和追溯粒度，并形成经确认的规则表。
- 建链嵌入过程活动：需求、设计、开发、测试各角色在评审通过或提交时同步建链，质量角色在阶段评审与抽查中核查完整性。
- 闭环以检查结论判断：需求覆盖率、孤儿需求、孤儿测试、链接方向、变更后更新和证据可复核六项通过，或例外项已获批准。
- 工具承载的重点是对象有稳定标识、链接可双向查询、变更可沿链路展开、矩阵与核查记录可留档导出。
双向追溯要追什么：对象、标识与链路规则
双向追溯的第一步是统一口径：哪些对象进入追溯范围、每个对象如何唯一标识、对象之间允许建立哪些链路。口径不统一，后续建链会出现同一类对象多种编号、同一关系多种叫法，追溯矩阵难以汇总，核查时也无法判断链接是否完整。
追溯对象通常覆盖需求、设计、实现与测试四类核心对象，缺陷和变更请求作为关联对象纳入。下表给出一个可调整的起点，项目应结合自身过程裁剪确定范围。
| 对象类别 | 典型对象 | 标识建议 | 版本规则 |
|---|---|---|---|
| 需求 | 系统需求、软件需求、非功能需求 | 前缀+层级+序号，如SRS-SW-001 | 需求变更时保留原编号，以版本号区分修订 |
| 设计 | 架构设计、详细设计、接口描述 | 前缀+模块+序号，如SD-SW-001 | 随需求版本联动更新，记录对应需求版本 |
| 实现 | 代码单元、配置项、构建产物 | 沿用配置管理标识，如CI-SW-001 | 以基线或提交记录标识版本 |
| 测试 | 测试用例、测试结果、测试报告 | 前缀+测试层级+序号，如TC-SW-001 | 用例修订保留编号，结果绑定执行批次 |
| 关联对象 | 缺陷、变更请求、评审记录 | 沿用各自管理流程的编号 | 关联到受影响对象的具体版本 |
正向链路指从需求出发，沿设计、实现追到测试用例与测试结果，回答“这条需求被什么设计承接、被什么代码实现、被哪些用例验证”。反向链路指从测试用例或设计单元出发，追回其来源需求，回答“这个测试为什么存在、这段设计服务于哪条需求”。两个方向共用同一组链接，只是查询起点不同，因此链接类型必须成对定义，避免只建单向关系。
追溯粒度决定工作量与核查强度。常见做法是：需求到设计按需求条目建链，设计到实现按设计单元或配置项建链，实现到测试按测试用例建链。层级过粗会让覆盖检查失去意义，层级过细会带来大量维护成本。建议在项目策划阶段确定粒度并写入过程裁剪说明，后续变更时按同一粒度维护。
本节的可交付物是一份追溯对象与标识规则表，至少包含对象类别、标识格式、版本规则、允许的链接类型和追溯粒度五项内容，经项目负责人与质量角色确认后作为建链依据。
建立双向追溯的操作步骤
建链不是一次性任务，而是嵌入需求、设计、开发和测试活动的持续动作。以下四步给出每步的输入、动作、输出与完成标志，可按项目节奏安排。
步骤一：梳理对象与编号
输入是项目范围说明、需求清单和已有的配置管理规则。动作是盘点进入追溯范围的对象，为每类对象分配标识前缀，清理重复编号和历史遗留编号。输出是对象清单与编号对照表。完成标志是范围内每个对象都有唯一标识，且标识规则与追溯对象与标识规则表一致。
步骤二：定义链接类型与方向
输入是对象清单和过程裁剪说明。动作是列出允许的链接类型，例如“需求被设计实现”“设计被测试验证”“测试验证需求”，并为每种链接明确正向与反向的读法。输出是链接类型定义表。完成标志是每种链接都有唯一名称、明确的两端对象类型和方向说明，团队对同一链接的叫法一致。
步骤三：在过程活动中同步建链
输入是各环节产出的需求条目、设计文档、代码配置项和测试用例。动作是在对象创建或提交评审时同步建立链接，而不是等到阶段评审前集中补录。需求评审通过时链接到承接设计，设计评审通过时链接到实现单元，测试用例编写时链接到被验证需求。输出是带链接的对象集合。完成标志是当期新增对象在评审通过时已具备应有链接，抽查无遗漏。
步骤四：用矩阵或查询生成追溯视图
输入是已建链的对象集合。动作是按需求维度生成需求—设计—实现—测试的追溯矩阵，按测试维度生成反向查询视图，并定期导出留档。输出是追溯矩阵与反向追溯清单。完成标志是矩阵能覆盖范围内全部需求，反向视图能定位每个测试用例的来源需求，导出结果可作为评审证据。
角色分工与各环节交付物
追溯质量取决于建链责任是否落到具体角色和时点。把建链集中到质量角色或评审前补录，会导致链接滞后于实际工作，变更时也难以维护。下表给出一种常见分工，项目可按团队规模调整。
| 角色 | 建链或核查职责 | 时点 | 应产出的追溯证据 |
|---|---|---|---|
| 需求负责人 | 为每条需求分配标识，链接到承接设计与验证需求 | 需求评审通过时 | 需求条目及其下游链接 |
| 设计负责人 | 将设计单元链接到来源需求，并链接到实现配置项 | 设计评审通过时 | 设计文档与需求、实现的链接记录 |
| 开发负责人 | 确认实现单元与设计、需求的对应关系，提交时更新链接 | 代码提交或构建基线时 | 配置项与设计单元的对应清单 |
| 测试负责人 | 为测试用例建立到需求的验证链接，记录测试结果 | 用例评审与测试执行时 | 用例—需求链接、测试结果记录 |
| 评审与质量角色 | 核查链接完整性、方向正确性与变更后更新情况 | 阶段评审与定期抽查 | 追溯核查记录与问题跟踪项 |
变更时的维护责任随变更对象确定：需求变更由需求负责人发起，沿正向链路通知设计与测试角色评估影响；设计变更由设计负责人更新链接并确认需求侧无需调整；测试用例调整由测试负责人同步反向链接。每次变更后应留下影响评估记录，说明受影响的链路范围和处置结论。
示例：一条需求的双向追溯链路
以下为演示情景，用于说明链路形态，不代表真实项目数据。
某软件需求“SRS-SW-012 车速信号超范围时应进入安全状态”，在需求评审通过后拆解为两条设计单元：SD-SW-021 信号校验模块和SD-SW-022 安全状态切换模块。两个设计单元分别链接到实现配置项CI-SW-031与CI-SW-032。测试侧编写用例TC-SW-045验证超范围触发安全状态，TC-SW-046验证正常范围内不误触发，两条用例均链接回SRS-SW-012。
正向查询从SRS-SW-012出发，可以看到两条设计、两个配置项和两条测试用例，以及最近一次测试执行结果。反向查询从TC-SW-045出发，可以追回SRS-SW-012及其设计承接单元，说明该用例的存在理由和验证对象。
当SRS-SW-012发生变更，例如调整超范围判定阈值，需求负责人沿正向链路找到SD-SW-021、CI-SW-031和TC-SW-045，组织设计与测试角色评估影响：设计是否需要修改校验逻辑，实现是否需要重新提交，测试用例的预期结果是否需要更新。评估结论和更新后的链接一并记录，形成变更影响证据。
完成检查：追溯是否闭环的核查项
双向追溯达到可用状态，表现为正向可追、反向可回、变更可查、证据可复核。以下清单可用于阶段评审前逐项核对。
- 需求覆盖率检查：范围内每条需求至少有一条下游设计链接和一条测试用例链接，覆盖率统计口径与项目策划一致。
- 孤儿需求检查：不存在没有任何下游链接的需求；若确有暂不实现的需求，应有明确的状态说明和处置记录。
- 孤儿测试检查：不存在无法追回来源需求的测试用例；补充性测试应说明其验证依据。
- 链接方向与类型检查：抽查链接是否符合链接类型定义表，正向与反向读法一致，无错链和重复链。
- 变更后链路更新检查：近期变更对象的下游链接已同步更新，影响评估记录完整。
- 证据留存与可复核性：追溯矩阵、反向查询结果和核查记录已按基线或阶段留档，第三方可按同一口径复现查询结果。
核查发现的问题应进入问题跟踪，明确责任人和关闭时点。闭环判断以清单全部通过或例外项已获批准为准，不以链接数量多少作为结论。
用工具承载追溯链路的衔接方式
追溯链路需要稳定的载体：对象有唯一标识，链接可查询，变更可沿链路展开，证据可留档。ONES 一站式软件研发平台面向车企研发场景，其 ASPICE 解决方案定位为满足 ASPICE 评估标准要求，并支持跨域协作全过程的可追溯性；方案的功能模块组合包括项目管理、知识库、工单管理、资源管理、测试管理和效能管理。以下按管理动作说明承载方式，具体链接类型与视图配置以实际使用为准。
对象承载方面，需求、设计任务、开发任务和测试用例可作为不同类型的工作项管理，通过编号规则和字段记录标识与版本信息，使每类对象在平台内有稳定入口。链接表达方面，正向与反向追溯通过工作项之间的关联关系体现，同一组关联从需求侧查看是下游承接，从测试侧查看是来源需求，避免维护两套关系。视图生成方面，可按需求维度筛选并汇总其关联对象，形成追溯矩阵的查询结果，按测试维度反查来源需求，导出后作为评审材料。
变更影响评估时，从变更对象出发沿关联关系逐层查看受影响的设计、实现与测试对象，把评估结论记录在变更工作项或评审记录中。评审与证据留存可借助知识库沉淀追溯规则、矩阵导出件和核查记录，使阶段评审能够按同一口径复核。对于跨业务域的协作，ONES 方案的第二阶段定位为以研发管理平台为基础实现流程透明协作，并集成从设计到生产端到端的业务系统；第三阶段涉及研发数据度量体系建设。项目可按自身建设节奏选择承载范围，先保证需求到测试的链路闭环，再扩展集成与度量。
常见问题
需求变更后，双向追溯链路应该由谁负责更新？
更新责任随变更对象确定。需求变更由需求负责人发起，沿正向链路通知设计与测试角色评估影响；设计变更由设计负责人更新链接，并确认需求侧无需调整；测试用例调整由测试负责人同步反向链接。每次变更后留下影响评估记录，写明受影响的链路范围和处置结论，便于阶段评审时复核。
追溯粒度定得多细比较合适？
粒度取决于核查强度和维护成本的平衡。常见做法是需求到设计按需求条目建链，设计到实现按设计单元或配置项建链，实现到测试按测试用例建链。层级过粗会让覆盖率检查失去意义，过细则带来大量维护工作。建议在项目策划阶段确定粒度并写入过程裁剪说明，后续变更按同一粒度维护。
项目已经进入测试阶段，前期没有同步建链，还能补建吗？
可以补建，但需要先做一次基线盘点：以当前需求清单为基准，逐条补齐设计、实现和测试链接，再按完成检查清单核查孤儿项和错链。补建后应把建链动作前移到后续过程活动中，例如需求评审通过时即建立下游链接，避免再次集中补录。补建阶段的链接需要标注建立时点，便于评审时区分过程证据与事后整理。
正向追溯和反向追溯需要维护两套关系吗？
不需要。两个方向共用同一组链接，只是查询起点不同：从需求出发看到的是下游承接对象，从测试用例出发看到的是来源需求。因此链接类型必须成对定义，明确两端对象类型和方向读法，避免同一关系出现多种叫法，导致矩阵汇总和反向查询结果不一致。
用ONES承载追溯链路时，哪些能力有明确依据？
ONES 一站式软件研发平台面向车企研发场景，其 ASPICE 解决方案定位为满足 ASPICE 评估标准要求，第一阶段建设支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性；方案的功能模块组合包括项目管理、知识库、工单管理、资源管理、测试管理和效能管理。具体的链接类型配置、追溯矩阵视图和测试对象关联方式，需以实际使用和产品资料为准。
