ASPICE过程文档示例要解决的是“照着能填”的问题。本文以一份需求追溯文档为例，给出已填写的完整样例：从一条系统需求出发，展示需求条目、双向追溯、变更记录、评审与验证证据如何在同一份文档中形成闭环。示例为演示情景，字段结构可迁移到团队模板；文中涉及的追溯与评审记录，也可在ONES这类研发管理平台中承载。具体过程域编号与评估要求以官方模型和评估方要求为准。
要点总览（TL;DR）
- 示例以一条系统需求为起点，把需求条目、双向追溯、变更记录、评审与验证证据放在同一份文档中，形成可顺着走完的追溯链。
- 文档由五部分组成：文档头、需求条目表、追溯表、变更记录、评审与验证记录，其中需求ID、来源、状态、下游链接与变更影响分析是核心字段。
- 改造成本团队模板时，先保证需求到设计、设计到测试、测试到验证证据的闭环字段齐全，再按项目复杂度增减优先级、责任人等可选字段。
- 示例为演示情景，用于理解结构与填写方式，不构成过程域达成度证明或认证结论，过程域编号与评估要求以官方模型和评估方要求为准。
- 追溯与评审记录可在研发管理平台中承载，ONES Wiki 支持文档关联项目任务、页面组关联项目与页面模板库，便于长期维护这类文档。
示例目标：这份ASPICE过程文档要证明什么
这份示例选取的是需求与追溯类过程文档，也就是在ASPICE评估中常被要求提供的那类材料：它要能说明一条需求从哪里来、落到哪个设计、由哪个测试用例覆盖、经过谁评审、变更后影响了什么。读者拿到这份样例，可以直接对照填写，也可以据此调整本团队的模板字段。
示例要展示的闭环由五个环节组成：需求条目作为起点，追溯关系连接设计与测试，变更记录说明影响范围，评审记录留下决策过程，验证证据证明需求已被覆盖。五个环节在同一份文档中互相引用，评估人员顺着任意一条需求都能走完全程，这才构成可核查的追溯链。
需要先说明范围。本文是演示情景，不对应任何真实客户或项目，其中的需求编号、人员角色、日期均为示意。示例不涉及控制算法设计、硬件设计文档，也不构成任何认证承诺或过程域达成度结论。它的用途是帮助读者理解文档结构与填写方式，而不是替代官方模型条文或评估方的具体要求。
完整示例：一份需求追溯文档的填写样例
下面给出这份示例文档的完整内容，按文档头、需求条目表、追溯表、变更记录、评审与验证记录五部分组织。所有内容均为演示情景，读者可将其中的编号规则和字段结构直接套用到自己的项目中。
文档头
| 字段 | 填写内容 |
|---|---|
| 文档编号 | RT-SYS-001 |
| 文档名称 | 整车控制器系统需求追溯文档 |
| 版本 | V1.2 |
| 状态 | 已评审，待验证关闭 |
| 责任人 | 系统需求负责人（示例角色） |
| 关联过程域 | 系统需求分析与需求追溯相关过程（具体编号以官方模型为准） |
| 关联项目 | 示例项目 VCU-2024（演示用） |
| 最近更新日期 | 2024-06-18（示例日期） |
需求条目表
| 需求ID | 需求描述 | 来源 | 优先级 | 状态 |
|---|---|---|---|---|
| SYS-REQ-001 | 系统上电后应在规定时间内完成自检，并向整车网络输出自检结果 | 客户需求 CR-017 | 高 | 已实现，待验证关闭 |
| SYS-REQ-002 | 自检失败时应记录故障码并保持可读取状态 | 内部需求 IR-023 | 高 | 已实现，已验证 |
| SYS-REQ-003 | 自检结果输出应符合整车网络通信规范 | 法规/标准输入 STD-005 | 中 | 评审中 |
追溯表
| 需求ID | 设计条目 | 测试用例 | 验证证据 | 追溯状态 |
|---|---|---|---|---|
| SYS-REQ-001 | DES-001 上电自检流程设计 | TC-001 上电自检时序测试 | 测试报告 TR-001 第3节 | 双向已建立 |
| SYS-REQ-002 | DES-002 故障码记录设计 | TC-002 故障码读取测试 | 测试报告 TR-002 第2节 | 双向已建立 |
| SYS-REQ-003 | DES-003 通信输出设计 | TC-003 通信规范符合性测试 | 待补充 | 下游缺失 |
变更记录
| 变更单号 | 变更内容 | 影响需求条目 | 影响分析 | 评审结论 |
|---|---|---|---|---|
| CR-2024-011 | 自检超时时间由原值调整为更严格取值 | SYS-REQ-001 | 影响DES-001与TC-001，需回归自检时序测试 | 通过，回归范围已确认 |
| CR-2024-014 | 新增故障码可读取状态要求 | SYS-REQ-002 | 影响DES-002与TC-002，新增一条测试步骤 | 通过，测试用例已更新 |
评审与验证记录
| 记录编号 | 类型 | 日期 | 参与角色 | 发现项 | 关闭状态 |
|---|---|---|---|---|---|
| REV-001 | 需求评审 | 2024-05-20 | 系统工程师、测试工程师、质量工程师 | SYS-REQ-003缺少通信规范引用版本 | 已关闭，补充引用 |
| REV-002 | 追溯评审 | 2024-06-10 | 系统工程师、测试负责人 | SYS-REQ-003下游测试用例缺失 | 未关闭，待补充TC-003证据 |
| VER-001 | 验证记录 | 2024-06-15 | 测试工程师 | SYS-REQ-001、SYS-REQ-002测试通过 | 已关闭，证据归档 |
逐项解释：每个字段为什么这样填
示例中的每个字段都对应一个管理意图，理解这些意图比记住字段名更重要。下面挑出几处关键填写选择逐一说明。
需求ID与追溯ID的命名规则。示例采用“类型前缀-序号”的结构，如SYS-REQ-001、DES-001、TC-001。前缀区分对象类型，序号保证唯一。这样命名的好处是：在追溯表中看到DES-001，就能立刻判断它是设计条目而非测试用例；在变更单里引用SYS-REQ-001，检索时不会与测试用例编号混淆。团队规模扩大后，可以在前缀中加入项目或子系统标识，但同一项目内应保持规则稳定，避免中途改号导致历史记录断链。
来源字段的区分。示例把来源分为客户需求、内部需求和法规/标准输入三类。区分的意义在于变更时的处理路径不同：客户需求变更通常需要与客户确认，内部需求可由团队自行决策，法规输入变更则要评估合规影响。来源字段填得含糊，后续影响分析就缺少依据。填写时应引用上游文档或需求单的编号，而不是只写“客户提出”。
状态字段反映进度。示例中的状态从“评审中”到“已实现，待验证关闭”再到“已实现，已验证”，对应需求生命周期的不同节点。状态字段的价值在于让评审者一眼看出哪些条目尚未闭环。建议状态取值控制在有限几个，并与评审、验证记录中的结论保持一致，避免出现状态写“已验证”但验证记录为空的情况。
变更记录体现影响分析与回归范围。示例中每条变更都写明了影响的需求条目、受影响的设计与测试用例，以及回归范围。这一栏是评估时重点查看的内容：变更是否做了影响分析、分析结果是否落到具体的回归动作。只写“已修改需求”而不写影响范围，追溯链在变更处就断了。
评审发现项的关闭证据。示例中REV-002的发现项状态为“未关闭”，并注明待补充的测试证据。发现项记录要能回答三个问题：发现了什么、由谁在什么时间关闭、关闭依据是什么。把未关闭项如实保留在文档中，比全部标为已关闭更可信，也便于跟踪。
可迁移规律：把这份示例改成自己的模板
示例的字段结构可以拆成必备与可选两部分，团队按项目裁剪时先保证必备字段齐全，再根据项目复杂度增加可选字段。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必备 | 需求ID、需求描述、来源、状态 | 构成需求条目的最小信息集 |
| 必备 | 设计条目、测试用例、验证证据 | 构成追溯闭环的下游链接 |
| 必备 | 变更单号、影响条目、评审结论 | 保证变更可追溯 |
| 必备 | 评审记录、发现项、关闭状态 | 留下决策与关闭证据 |
| 可选 | 优先级、责任人、关联项目 | 按团队管理粒度增减 |
| 可选 | 法规/标准引用版本、回归范围明细 | 合规要求高的项目建议保留 |
追溯关系的最小闭环要求是：每条需求至少有一条下游设计或实现条目，每条设计至少被一个测试用例覆盖，每个测试用例对应可查的验证证据。缺少任一环节，追溯链就不完整。示例中SYS-REQ-003的追溯状态标为“下游缺失”，正是为了提示这一环节尚未补齐。
文档与工作项、评审记录的关联方式，决定了追溯能否在日常工作中维护。可行的做法是把需求条目作为工作项管理，追溯表通过链接字段引用设计与测试工作项，评审记录作为独立记录关联到需求。这样变更发生时，影响分析可以直接从链接关系展开，而不必人工翻查文档。ONES Wiki支持文档关联项目任务、页面组关联项目，需求与文档可以互相对应，文档版本也可查看与回滚，适合承载这类需要长期维护的追溯文档；页面模板库可用于统一文档结构。具体配置以实际版本为准。
模板维护的基本做法包括：模板本身纳入版本管理，字段调整时记录变更原因；新项目启动时从模板创建文档，而不是复制旧项目文档；定期检查追溯表中是否存在长期未关闭的缺失项。模板的稳定性和追溯的完整性，比字段数量更能体现过程管理的成熟度。
适用边界：示例不能替代的部分
这份示例能帮助读者理解需求追溯文档的结构和填写方式，但它不能证明任何特定过程域的达成度。ASPICE各过程域有各自的编号、目的和基本实践要求，评估时依据的是官方模型条文和评估方的判定，示例中的字段组织只是通用实践的整理，不对应某个过程域的全部要求。
过程域编号、评估模型版本和具体评估要求，应以官方发布的最新模型和评估方的书面要求为准。不同评估范围对证据的类型和详略程度要求不同，示例中的验证证据只写到测试报告章节，实际项目中可能需要更细的记录。项目裁剪时字段可以增减，但需求到设计、设计到测试、测试到验证证据的追溯闭环建议保留，变更影响分析也不宜省略。
示例不涉及工具实测，也不提供任何量化效果数据。文中提到的工具承载方式，仅说明追溯与评审记录可以在研发管理平台中组织，具体功能表现需以实际使用和版本配置为准。读者在建立本团队模板时，建议先与质量或过程管理部门确认评估方的具体要求，再确定字段清单和证据粒度。
常见问题
示例中的需求条目和追溯关系，一定要放在同一份文档里吗？
不一定。示例把两者放在同一份文档中，是为了让读者一次看清闭环关系。实际项目中，需求条目常作为工作项管理，追溯关系通过链接字段或追溯矩阵维护，文档承担说明与汇总的角色。只要评估时能顺着一条需求查到设计、测试用例和验证证据，拆分存放同样成立；关键是链接关系稳定、编号规则统一，避免文档与工作项各记一套。
项目裁剪时，哪些字段可以删，哪些建议保留？
优先级、责任人、关联项目这类字段可以按团队管理粒度增减。需求ID、需求描述、来源、状态，以及设计条目、测试用例、验证证据、变更影响分析和评审关闭状态建议保留，它们共同支撑追溯闭环。合规要求高的项目还应保留法规/标准引用版本和回归范围明细。裁剪前先与质量或过程管理部门确认评估方的证据要求，再确定字段清单。
变更发生后，追溯文档需要同步更新到什么程度？
变更记录要写明变更单号、影响的需求条目、受影响的设计与测试用例，以及回归范围。文档中对应条目的状态、追溯链接和验证证据应随变更同步调整，使追溯表不出现指向已废弃条目的链接。示例中 CR-2024-011 的处理方式是：确认影响 DES-001 与 TC-001，并把回归自检时序测试列入范围。变更评审结论与文档更新最好在同一次流转中完成，减少后续补记。
评审发现项没有全部关闭，文档还能提交评审吗？
可以提交，但应如实标注未关闭项及其待补证据。示例中 REV-002 的发现项保留为“未关闭”，并注明待补充 TC-003 证据，这比全部标为已关闭更便于跟踪，也更符合评审记录的实际用途。提交前建议确认每个未关闭项都有责任人和计划关闭时间，避免长期挂起。
用研发管理工具承载追溯文档，需要提前确认哪些配置？
先确认三件事：需求、设计、测试用例是否以工作项形式建立并可互相链接；评审记录能否关联到对应需求；文档版本是否可查看与回滚。ONES Wiki 支持文档关联项目任务、页面组关联项目，需求与文档可以互相对应，页面模板库可用于统一文档结构，具体配置以实际版本为准。工具承载不改变追溯闭环的要求，字段和链接规则仍需团队先定义清楚。
