场景一 · 端到端追溯审计

业务背景

ASPICE 评估中最耗时的工作之一，是验证从利益相关方需求到验证结果的整条追溯链是否完整。

手工核对一个中等规模项目的追溯关系通常需要 5–10 个工程日
且容易遗漏
评估方在审计阶段发现断链时，项目往往已经接近交付，返工成本高

演示能力

Rendering diagram…

平台读取项目的需求规格、架构设计、详细设计、测试规格四类文档：

自动抽取每一条工程对象（需求、设计元素、测试用例）
按 ASPICE 6 层模型重建追溯链
与项目自带的"基准追溯矩阵"做精度 / 召回率对比
给出可量化的审计结论

实际发给 Agent 的提示词

以下是演示账号 testcasegenerator 在 Session DEMO-A ASPICE追溯审计 里真实发出的第一句指令（完整不删节）。客户复用时只需把"ABZ 灯控"替换成自己的项目名、把 9 份 docx 文件名替换成自己的基线，其余结构可以原样套用：

请你扮演 ASPICE 评审员，对 ABZ 灯控项目 v1.17 基线做端到端追溯审计。

## 可用 skill
- automotive-process-analyzer（ASPICE 规范专家）
- html-report（生成交互式 HTML 看板）
- 通用文件能力（write_file + python-docx 输出 .docx）
具体用 skill 的哪个 action / 看哪个 reference / 套哪个模板，自己读各 skill 的 SKILL.md 决定。

## 数据（KB = ABZ）
本任务只用 v1.17 这 9 份 + 1 份 GT：
- 01-Stakeholder-Requirements-Specification-v1.17.docx
- 02-Software-Requirements-Specification-v1.17.docx
- 03-Software-Architecture-Design-v1.17.docx
- 04-Software-Detailed-Design-v1.17.docx
- 05-Safety-Analysis-v1.17.docx (+ .xlsx)
- 06-Cybersecurity-Analysis-v1.17.docx
- 07-Verification-and-Validation-Plan-v1.17.docx
- 08-Traceability-Matrix-v1.17.xlsx ← Ground Truth，前几步不要先看

## 业务步骤
1. 让 automotive-process-analyzer 帮你定下要覆盖的 ASPICE process area
   （重点：SYS.2 / SWE.1 / SWE.2 / SWE.3 / SWE.4 / SWE.6）和追溯模型。
2. 逐份读取 1-7 号 docx，识别每份文档里的需求 / 设计 / 测试条目 ID
   （ABZ 用的是哪种 ID 体系自己识别，不要照搬其他项目的前缀）
   以及它们之间的追溯关系（自然语言、表格列、显式 ID 引用三种都收）。
3. 构建端到端追溯链：StRS → SwRS → SwAD → SwDD → SwTest → ValidationResult
   每条链记录 source_id / target_id / relation / source_doc / target_doc。
4. 读 08-Traceability-Matrix-v1.17.xlsx 作 Ground Truth，与你建出的链对照，
   算 P / R / F1（数值不藏）。
5. 找出至少 3 类问题：
   (a) 完全断链（上层有需求、下层没设计/没测试）
   (b) 反向孤儿（下层凭空冒出来、上面没出处）
   (c) 命名不一致（同一能力上下层用了不同 ID 体系）

## 产出
1. outputs/A-aspice-traceability-report.docx
   §1 项目概况  §2 PA 评估表（每个 PA：节点数 / 链数 / P/R/F1 / 结论）
   §3 端到端追溯链明细  §4 问题清单（按 a/b/c 分类）  §5 整体合规结论
2. outputs/A-aspice-traceability-dashboard.html
   - 桑基图：各层之间的追溯流量
   - 热力图：PA × PA 链密度
   - 表格：Top-N 断链清单（含文档名 + 章节定位）
   - 顶部 KPI：覆盖率 / P / R / F1

## 通过标准
- 端到端 6 层都被覆盖、每层 ≥ 1 条节点
- P / R / F1 三个数都给出（与 GT 对照的真实值）
- 至少识别 1 条断链
- docx + html 都生成成功，文件大小 > 50KB

这条提示词的 6 段结构（扮演 / 可用 skill / 数据 / 业务步骤 / 产出 / 通过标准）是平台跑出稳定结果的最小集合。把客户自己的 ASPICE 项目套进去最多需要替换 4 处：项目名、KB 文件清单、过程域选择、Ground Truth 文件。完整模板见手把手教程：第一个 ASPICE 评审 Agent。

实测数据

维度	数值
覆盖的 Process Area	SYS.2、SWE.1、SWE.2、SWE.3、SWE.4、SWE.6
6 层节点总数	303 个
平台自动重建的追溯链	396 条
项目原有基准追溯链	314 条
与基准对比	精确率 79.29%，召回率 100%，F1 88.45%
识别出的追溯问题	156 条

156 条问题按类型分布：

完全断链 140 条（上层有需求但下层无对应设计或测试）
反向孤儿 14 条（下层条目找不到上层出处）
命名不一致 2 条（上下层 ID 编码规则不统一）

Agent 产出的自包含 HTML 看板（A-aspice-traceability-dashboard.html）：顶部 KPI、桑基图（6 层追溯链流向）、层级交叉热力图，把 303 节点 / 396 链压成一张可以交付给评估方的单页看板。

ASPICE 追溯审计看板 - KPI + 桑基图 + 热力图

同一看板的下半部分：各 PA 追溯链统计、PA F1 评分仪表盘、156 条问题按「类型 / 严重度」的双饼图分布。

156 条追溯问题按类型 / 严重度分布

客户价值

时间收益：从原本 5–10 人天的人工核对，缩短到一次自动审计可在小时级完成
定位能力：输出包含可视化看板，让评估方和项目经理可以直接定位每一条断链所在的文档位置
前移能力：配合场景二可以做「变更后立即重新审计」，把追溯审计从"评估前突击"前移为"日常守门"

看板里的"全部问题清单"支持按严重度筛选：每条问题记录包含 ID / 类型 / 严重度 / 来源文档 / 层级 / 节点 ID / 缺失层级 / 描述，评估方可以直接点到文档里的章节位置。下面是按 High 筛出来的 13 条头部断链：每条都能精准告诉你「哪份 SwRS 文档、哪个需求 ID、下层 SwAD / SwDD 为空」。

问题清单：断链在文档与节点维度的精准定位

交付物

类别	文件
报告文档	`A-aspice-traceability-report.docx`
可视化看板	`A-aspice-traceability-dashboard.html`（离线自包含）
结构化数据	`metrics.json` / `pa_stats.json` / `issues.json`

平台执行视图

以下是本场景在平台上真实跑出来的过程截图（testcasegenerator 演示账号，Session DEMO-A ASPICE追溯审计）：

执行摘要（OUTPUT_JSON，含 P/R/F1 量化指标）

场景一平台执行摘要 - OUTPUT_JSON

最终答案（英文任务小结）

Agent 给出了任务的英文总结，明确说明「从 7 份项目文档抽取 ID，跨 6 层重建追溯链，与 Ground Truth 比对计算 P/R/F1，识别 3 类问题」。

场景一平台最终答案

产出文件面板（50 个文件，含 docx 报告、html 看板、分析 json）

会话右侧「文件」面板列出了整个 Session 的全部产出物，包括 A-aspice-traceability-dashboard.html、A-aspice-traceability-report.docx、analysis-results.json 以及中间态的 exec_*.py、runner.py 等。

场景一平台产出文件

下一步

用场景二继续：版本变更时如何快速重算追溯
用场景四做覆盖审计交叉验证（通过 Graft 引用本场景结果）

场景一 · 端到端追溯审计

On this page