ASPICE过程责任写不清，常见结果是活动有人做、评审没人认、证据找不到。这份示例以系统需求分析过程为演示情景，给出一张按“过程域—活动—责任角色—输入—输出—评审与证据”填写的分工表，并逐项解释字段填法，帮助你把同样的结构迁移到需求管理、配置管理、问题管理等其他过程域。示例中的角色与工作产品均为示意，不代表任何企业的实际做法或评估结论。
要点总览（TL;DR）
- ASPICE过程责任示例的核心结构是“过程域—活动—责任角色—输入—输出—评审与证据”，让每项活动都能追溯到角色、工作产品和评审动作。
- 责任写不清的典型表现是只写部门不写角色、只写负责不写评审、只写活动不写证据；合格标准是角色唯一、动作可执行、产出可核查。
- 示例按RACI思路区分负责、审批、参与、知会四类责任，一个活动只设一个负责角色，审批角色与负责角色分离。
- 迁移到其他过程域时，先定工作产品和状态，再拆活动，最后分配角色，并保证评审方式与证据成对出现。
- 示例为演示情景，不能直接当作评估证据；评估证据需来自真实项目的评审记录、审批意见和基线记录。
这份示例要解决什么：责任写不清的三种表现
ASPICE过程责任文档的目标只有一个：让每个过程域中的每项活动，都能追溯到明确的角色、明确的工作产品和明确的评审动作。做到这一点，责任表才能在日常项目中执行，也才能在评估时作为线索指向真实记录。合格的标准可以归纳为三条：角色唯一、动作可执行、产出可核查。
责任写不清通常有三种表现。第一种是只写部门不写角色，例如“由研发部负责需求分析”，部门是组织单元，无法承担具体动作，出了问题也找不到责任人。第二种是只写负责不写评审，活动做完了，但没有说明谁审批、以什么方式确认结果，过程缺少把关环节。第三种是只写活动不写证据，表格里列了“完成需求评审”，却没有指明评审记录、问题清单或签署结果存放在哪里，评估时无法证明活动真实发生。
对应的合格标准是：每项活动对应一个负责角色，写到岗位或职责名称；每项需要确认的产出配一个审批角色和评审方式；每个输出工作产品写明名称与完成状态，并指明可核查的证据形式。下文示例即按这三条标准填写。
完整示例：系统需求分析过程的责任分工表
以下表格为演示用示例，过程域选取系统需求分析，角色名称与工作产品名称均为示意，用于说明填写结构，不对应任何真实企业、项目或评估结果。
| 过程域 | 活动 | 责任角色（R） | 审批角色（A） | 参与角色（C） | 知会角色（I） | 输入工作产品 | 输出工作产品 | 评审方式 | 证据 |
|---|---|---|---|---|---|---|---|---|---|
| 系统需求分析 | 收集并整理利益相关方需求 | 系统需求工程师 | 系统需求负责人 | 产品经理、测试工程师 | 项目经理 | 利益相关方需求清单（已基线） | 系统需求草案（草稿状态） | 需求评审会 | 评审会议记录、意见处理清单 |
| 系统需求分析 | 编写系统需求规格 | 系统需求工程师 | 系统需求负责人 | 架构师、测试工程师 | 项目经理 | 系统需求草案（草稿状态） | 系统需求规格（待评审状态） | 同行评审 | 评审检查单、缺陷记录 |
| 系统需求分析 | 建立需求双向追溯 | 系统需求工程师 | 系统需求负责人 | 测试工程师 | 项目经理 | 系统需求规格（待评审状态）、上游需求清单 | 追溯矩阵（已更新状态） | 追溯完整性检查 | 追溯矩阵版本记录、检查结论 |
| 系统需求分析 | 需求变更影响分析 | 系统需求工程师 | 变更控制负责人 | 架构师、测试工程师、项目经理 | 配置管理员 | 变更请求（已登记状态）、系统需求规格（已基线） | 变更影响分析报告（待审批状态） | 变更评审会 | 变更评审记录、审批意见 |
| 系统需求分析 | 需求基线发布 | 配置管理员 | 系统需求负责人 | 系统需求工程师 | 项目经理、测试工程师 | 系统需求规格（已评审通过状态） | 系统需求基线（已发布状态） | 基线审核 | 基线记录、发布通知 |
表中四类责任按RACI思路区分：R为负责执行的角色，每项活动只设一个；A为审批角色，对产出是否可接受作出决定；C为需要在活动过程中被咨询、提供输入的角色；I为需要知会结果的角色。可以看到，编写需求规格与审批规格由不同角色承担，变更影响分析由变更控制负责人审批，基线发布则由配置管理员执行、系统需求负责人审批，责任在活动之间发生了合理转移。
双向追溯单独列为一项活动，是因为追溯关系需要持续维护，而不是在编写规格时顺带完成。变更场景下，输入工作产品写明“已基线”状态，输出写明“待审批”状态，评审方式与证据成对出现，评估时可以顺着证据字段找到对应的评审记录与审批意见。
逐项解释：每个字段为什么这样填
责任角色写到岗位而非部门，是因为岗位对应具体的人所承担的职责，可以落实到任务分配和评审签字；部门只能说明归属，无法回答“这件事谁做、谁批”。示例中的“系统需求工程师”“系统需求负责人”都是职责名称，组织可以按自己的岗位体系替换，但应保持一岗一责的粒度。
审批与负责分离，是为了让产出经过独立确认。编写者自己审批自己的产出，评审就失去把关作用。示例中每项活动都设置了与责任角色不同的审批角色，变更影响分析甚至交由变更控制负责人审批，体现变更决策权与执行权的分开。
输入输出工作产品写明名称与状态，是因为同名文档在不同阶段含义不同。草案、待评审、已基线、已发布这些状态，决定了活动可以从什么起点开始、产出达到什么条件才算完成。只写“需求文档”而不写状态，责任表就无法判断活动是否真正闭环。
评审方式与证据字段需要一一对应。评审会对应会议记录与意见处理清单，同行评审对应检查单与缺陷记录，追溯检查对应矩阵版本记录与检查结论。评估关注的是活动有没有按策划执行、结果有没有被记录，证据字段就是指向这些记录的入口。
变更场景下责任转移要写清楚。变更请求登记后，影响分析由系统需求工程师执行，审批权转到变更控制负责人，配置管理员被知会；变更通过后，基线更新由配置管理员执行。责任随活动阶段变化而转移，表格按活动分行，正是为了让这种转移可见。
| 字段 | 常见填错 | 建议填法 |
|---|---|---|
| 责任角色 | 写部门或团队名称 | 写岗位或职责名称，一活动一角色 |
| 审批角色 | 与责任角色相同或留空 | 指定独立审批人，明确审批对象 |
| 输入/输出 | 只写文档类型，不写状态 | 名称加状态，如“待评审”“已基线” |
| 评审方式 | 笼统写“评审” | 写明评审会、同行评审、检查等具体形式 |
| 证据 | 留空或写“相关记录” | 写明记录名称与存放位置 |
可迁移规律：换一个过程域怎么套
把示例迁移到其他过程域，可以按固定顺序推进：先定工作产品，再定活动，最后定角色。先明确这个过程的输入和输出分别是什么、各自有哪些状态，活动自然围绕“把输入变成输出”展开；活动确定后，再为每项活动分配一个负责角色和必要的审批、参与、知会角色。这个顺序能避免先分人再凑活动的常见问题。
填写时守住几条规律：一个活动只设一个负责角色，责任分散等于无人负责；评审动作与证据成对出现，没有证据的评审在责任表里没有意义；按过程域拆分表格，一张大表难以维护，也不利于按过程域分工；每张表只覆盖一个过程域的完整活动链，表与表之间通过工作产品衔接。
迁移时还要注意与其他管理活动的衔接点。责任表中的输出工作产品，往往同时是项目计划中的交付物、配置管理中的配置项、问题管理中的处理对象。例如系统需求基线既是需求过程的输出，也是配置管理需要纳入控制的配置项；变更请求既触发需求变更，也进入问题与变更管理流程。把这些衔接点在表中标注出来，责任表才能与项目实际运行的管理体系对齐。
换到配置管理、问题管理或测试过程时，方法不变：先列出该过程的输入输出与状态，再拆出活动，最后按一活动一负责角色的原则分配责任，并为每项需要确认的产出配上评审方式与证据。完成后可用三条标准自查：角色是否唯一、动作是否可执行、产出是否可核查。
责任表落到日常执行时，需要工作项、评审记录和追溯关系有统一的承载位置。ONES 一站式软件研发平台面向车企研发场景，其研发管理加 ASPICE 解决方案在线上化建设阶段支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性；方案的功能模块组合包括项目管理、知识库、工单管理、资源管理、测试管理、效能管理。责任表中的活动可以对应到工作项，评审意见与审批结论随工作项留存，追溯关系在平台内维护，使表格中的“证据”字段有实际落点。具体模块与过程域的对应配置需结合组织实际情况确定。
适用边界：示例不能直接当评估证据
本文表格是演示情景，角色名称、工作产品名称和评审安排均为说明结构而设，不代表任何企业的实际做法，也不构成任何评估结果。直接把它当作本组织的责任文件使用，会出现角色与实际岗位不符、活动与项目裁剪不一致的问题。
责任表需要结合组织实际角色体系和项目裁剪情况调整。不同项目的规模、生命周期阶段和客户要求不同，过程域的活动集合与评审强度可以裁剪，但裁剪决定应有记录。表格填写完成后，还应与项目计划、配置管理计划中的安排核对一致。
评估证据来自真实项目的记录，包括实际发生的评审记录、审批意见、追溯矩阵版本和基线记录。责任表本身说明的是“应该谁做、做什么、留下什么”，它能支撑证据的查找，不能替代证据。本文不涉及认证承诺，也不对具体评估等级作出判断；涉及评估范围与等级的问题，应以评估方的要求和组织实际过程为准。
常见问题
一个活动能不能设两个负责角色，比如由两位工程师共同负责？
建议每项活动只设一个负责角色。两人共同负责时，任务分配、进度跟催和结果确认都容易出现互相等待，出问题也难以界定谁该说明情况。如果工作量确实需要多人承担，可以设一个主责角色，其他人在参与角色（C）中列明，并写清各自提供的输入，例如一人负责需求条目编写、另一人负责追溯关系维护，拆成两项活动分别设负责角色。
小团队岗位少，审批角色和负责角色由同一人兼任，责任表该怎么写？
岗位少时兼任难以避免，但责任表仍应把两个角色分开写，并在备注中说明兼任情况。更稳妥的做法是调整评审方式：负责角色完成产出后，由团队内另一位成员或上级按检查单做同行评审，审批结论记录在评审记录中。关键是让确认动作真实发生并留下记录，兼任本身不构成问题，把审批栏留空或直接填成与负责角色相同、却没有独立确认过程，才会让责任表失去把关作用。
过程裁剪后活动减少了，责任表要不要同步删行？
需要同步调整，并保留裁剪决定的记录。项目按规模或生命周期阶段裁剪活动时，责任表应删除不执行的活动行，或标注“本项目不适用”及裁剪依据，避免表格与实际执行不一致。裁剪决定本身也应有审批和记录，否则评估时无法说明为什么某些活动没有发生。裁剪后的责任表还要与项目计划核对，确保计划中的交付物与表中的输出工作产品一致。
责任表里的证据字段，写到什么程度才算可核查？
证据字段应写明记录的名称和存放位置，让人能按表找到对应记录。例如“评审会议记录、意见处理清单”比“相关记录”可核查，“追溯矩阵版本记录”比“追溯结果”可核查。如果组织使用研发管理平台承载工作项与评审，可以进一步写明记录所在的项目空间或工作项类型。证据字段的作用是指向真实记录，表格本身不能替代记录。
责任分工表落地到工具里，重点要打通哪些环节？
重点是把表中的三类内容找到承载位置：活动对应到工作项并分配责任人，评审方式对应到评审流程并留存意见与审批结论，输出工作产品对应到基线或配置项并保留版本记录。追溯关系也需要在工具内持续维护，而不是只在文档中画一张矩阵。ONES 研发管理加 ASPICE 解决方案在线上化建设阶段支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性，可作为责任分工落地的承接方式之一；具体模块与过程域的对应配置需结合组织实际情况确定。
