一个 EVCS 项目的 ASPICE 文档体系是怎么建立的

背景

某国内充电桩控制器供应商（EVCS，Electric Vehicle Charging Station），接到一家合资主机厂的定点通知，同时收到一份要求：项目团队需在 12 个月内通过 ASPICE Level 2 评估。

团队 20 人，此前用 Excel 管需求、企业微信传文件、没有统一的文档平台。

这篇文章记录他们如何从零搭建 ASPICE 文档体系。

第一步：理清要交付什么

几个容易搞错的点：

• SWE.6 ≠ 系统验证
  
  ：SWE.6 是软件合格测试，验证软件满足 SWE.1 的软件需求；系统层面的验证是 SYS.5
• SWE.4 验证的是 SWE.3
  
  （单元实现），不是软件需求
• SWE.5 验证的是 SWE.2
  
  （软件架构/集成接口）
• SYS.3 不可缺
  
  ：系统架构设计是 SYS.4 系统集成测试的依据，若评估范围含系统层必须提供

关键不只是”有这些文档”，而是 V 模型两侧之间要有双向追溯关系。

第二步：在 Lamadar 中建立项目结构

EVCS-充电控制器项目/│├── 00-项目管理/│   ├── 项目管理计划（MAN.3）│   └── 质量保证计划（SUP.1）│├── 01-利益相关方需求（StRS）          ← SYS.1 输出├── 02-系统需求规格（SRS）             ← SYS.2 输出├── 03-系统架构设计（SAD）             ← SYS.3 输出│├── 04-软件需求规格（SwRS）            ← SWE.1 输出├── 05-软件架构设计（SwAD）            ← SWE.2 输出├── 06-软件详细设计（SwDD）            ← SWE.3 输出│├── 07-软件单元验证/                   ← SWE.4│   ├── 单元测试规程（UTP）│   └── 单元测试报告（UTR）│├── 08-软件集成测试/                   ← SWE.5│   ├── 软件集成测试规程（SITP）│   └── 软件集成测试报告（SITR）│├── 09-软件合格测试/                   ← SWE.6│   ├── 软件合格测试规程（SQTP）│   └── 软件合格测试报告（SQTR）│├── 10-系统集成测试/                   ← SYS.4│   ├── 系统集成测试规程（SYSITP）│   └── 系统集成测试报告（SYSITR）│├── 11-系统合格测试/                   ← SYS.5│   ├── 系统合格测试规程（SVTP）│   └── 系统合格测试报告（SVTR）│└── 12-支持过程/    ├── 配置管理计划（SUP.8）    ├── 问题管理记录（SUP.9）          ← 通常由 Issue/Defect 工作项承载    ├── 变更请求记录（SUP.10）         ← 通常由 Change Request 工作项承载    └── 联合评审记录（SUP.4）          ← 由文档审批流程中的批注和签名承载

几点说明：

• 测试规程 ≠ 测试报告
  
  规程是”怎么测”，报告是”测了什么、结果如何”，评估员会分别查验，两者缺一不可
• SUP.9/SUP.10 不需要单独文档
  
  Lamadar 的 Defect 和 Change 工作项天然就是这两个过程的执行证据
• SUP.4 评审记录
  
  Lamadar 文档工作流中的批注、评审意见工作项、电子签名日志即是 SUP.4 所需证据，无需额外整理
• SYS.3 不可省
  
  若评估范围含系统层，SAD 是 SYS.4 集成测试的设计依据，缺失会直接导致 SYS.4 无法满足

每个规格/设计文档都是 LiveDoc，有版本控制和审批流程。工作项（需求条目、测试用例）直接内嵌在文档章节中，天然建立了文档与工作项的关联。

第三步：建立追溯链

最耗时的是把客户需求一条条拆解，关联到下游的软件需求、测试用例。

传统做法是维护一张 Excel 追溯矩阵，需求一变，所有关联行都要手动更新。

在 Lamadar 中，追溯关系在工作项创建时就建立，系统自动维护：

• 客户需求 → 系统需求（source/target 关联）
• 系统需求 → 软件需求
• 软件需求 → 测试用例
• 需求变更时，下游关联条目自动标记为”疑似影响”（Suspect Link）

审计前不需要额外整理，直接导出追溯矩阵报告。

第四步：文档审批与签字

ASPICE 要求评审活动有记录，包括谁参与了、发现了什么问题、如何关闭。

团队使用 Lamadar 的文档工作流：

1. 作者完成文档 → 提交审查
2. 文档冻结，评审人在线批注
3. 评审意见作为工作项跟踪关闭
4. 所有评审人电子签名 → 文档转为 APPROVED 状态

每一步操作都有时间戳和操作人记录，形成完整的审计证据链。

结果

12 个月后，该团队通过了 ASPICE Level 2 评估。评估员的评语是：

“工作产物齐全，追溯关系清晰，评审证据完整。”

团队负责人的感受是：

“不是临时冲刺，是把 ASPICE 要求的动作变成了日常工作的一部分。”

💬 你们团队在建立 ASPICE 文档体系时，遇到过哪些坑？ 欢迎留言，我们一起探讨。

— Lamadar 团队

了解更多，访问官网： www.lamadar.com