ASPICE工作产品模板可以按“主表字段 + 版本信息 + 评审记录”三段式组织：主表承载工作产品标识、内容与追溯关系，版本信息记录变更轨迹，评审记录保存评审结论与关闭状态。下文提供可直接复制的空白表格、逐字段填写口径、必填与选填规则、一份完整填写示例，以及版本升级和评审归档的维护方法，适用于需要按过程定义提交工作产品的汽车软件研发项目。
要点总览（TL;DR）
- 模板按“主表字段 + 版本信息 + 评审记录”三段式组织，主表承载标识、内容与追溯，版本信息记录变更轨迹，评审记录保存结论与关闭状态。
- 主表必填字段包括工作产品名称、编号、所属过程域与过程、版本号、状态、责任人、创建与更新日期、上游输入；下游输出、备注等可按项目裁剪。
- 评审记录至少包含评审编号、类型、评审人、日期、评审版本、发现项、处置结论、关闭状态与关闭日期，评审版本须能在版本信息区找到对应行。
- 版本号采用主版本.次版本格式，每次变更新增一行不覆盖历史；基线后变更需审批人确认，评审记录随工作产品归档保留。
- 模板字段增删走变更流程，建议每阶段复核必填空缺率与评审记录完整性，维护责任落到过程负责人或质量角色。
可复制空白模板：工作产品主表与评审记录表
模板分为两张表。主表用于描述工作产品本身，表头固定标识与版本信息，正文按工作产品类型设置内容字段和追溯字段；评审记录表附在主表之后，一份工作产品可以对应多条评审记录。复制时保留表头，删除示例行即可使用。
工作产品主表（空白）
| 字段 | 填写内容 |
|---|---|
| 工作产品名称 | |
| 工作产品编号 | |
| 所属过程域 | |
| 所属过程 | |
| 版本号 | |
| 状态 | |
| 责任人 | |
| 创建日期 | |
| 最近更新日期 | |
| 上游输入（来源工作产品编号） | |
| 下游输出（引用本工作产品编号） | |
| 内容字段一（按类型自定义） | |
| 内容字段二（按类型自定义） | |
| 内容字段三（按类型自定义） | |
| 备注 |
版本信息区（空白）
| 版本号 | 变更日期 | 变更人 | 变更内容摘要 | 变更原因 | 审批人 |
|---|---|---|---|---|---|
评审记录表（空白）
| 评审编号 | 评审类型 | 评审人 | 评审日期 | 评审版本 | 发现项 | 处置结论 | 关闭状态 | 关闭日期 |
|---|---|---|---|---|---|---|---|---|
使用位置建议：主表放在工作产品文档首页或独立封面页，版本信息区紧随主表，评审记录表放在文档末尾或作为独立附表。若工作产品以表格形式存在（如需求清单、测试用例表），主表可作为表头说明页，评审记录单独成页，避免与业务数据混排。
字段说明：每个字段填什么、按什么口径填
字段口径统一的关键是让同一字段在所有工作产品中含义一致。下表按标识类、内容类、追溯类、版本信息类和评审记录类分别说明，示例值仅示意格式。
| 字段名 | 定义 | 填写口径 | 示例值 |
|---|---|---|---|
| 工作产品名称 | 工作产品的正式名称 | 使用过程定义中的标准名称，与配置管理清单一致，不写简称 | 软件需求规格说明 |
| 工作产品编号 | 唯一标识 | 按项目约定的编码规则生成，全项目唯一，发布后不修改 | SRS-PRJ01-001 |
| 所属过程域 | 工作产品归属的ASPICE过程域 | 填写过程域简称，与过程定义文件一致 | SWE.1 |
| 所属过程 | 过程域下的具体过程 | 填写过程名称，细化到活动层级 | 软件需求分析 |
| 版本号 | 当前有效版本 | 采用主版本.次版本格式，内容结构变化升主版本，文字修订升次版本 | V1.2 |
| 状态 | 工作产品当前生命周期状态 | 从“草稿、评审中、已批准、已变更、已归档”中选一，状态变化需有对应记录 | 已批准 |
| 责任人 | 对该工作产品内容和维护负责的人 | 填写具体姓名或工号，不填部门名称 | 张工（工号1023） |
| 创建日期 | 首次建立日期 | 格式统一为YYYY-MM-DD | 2024-03-11 |
| 最近更新日期 | 最近一次内容变更日期 | 与版本信息区最后一条变更日期一致 | 2024-05-20 |
| 上游输入 | 本工作产品所依据的来源工作产品 | 填写来源工作产品编号，多个用分号分隔，可追溯到具体条目时注明条目号 | SYS-RS-004；SYS-RS-007 |
| 下游输出 | 引用或派生自本工作产品的工作产品 | 填写被引用方编号，随下游建立及时补充 | SWE.4-UT-012 |
| 内容字段 | 工作产品正文的结构化信息 | 按类型设定，如需求类设“需求描述、优先级、验收准则”，测试类设“测试目的、前置条件、预期结果” | 需求描述：制动信号采样周期不大于10ms |
| 备注 | 补充说明 | 只写与工作产品管理相关的信息，不写讨论过程 | 依赖供应商接口文档V2 |
| 评审编号 | 评审活动唯一标识 | 按“工作产品编号-评审序号”生成 | SRS-PRJ01-001-R02 |
| 评审类型 | 评审的组织形式 | 填写“同行评审、走查、正式评审、联合评审”等过程定义中的类型 | 同行评审 |
| 评审人 | 参与评审的人员 | 列出全部评审人姓名，注明角色 | 李工（需求）、王工（测试） |
| 评审日期 | 评审活动完成日期 | 格式YYYY-MM-DD，与会议记录一致 | 2024-05-16 |
| 评审版本 | 被评审的工作产品版本 | 填写评审时的版本号，便于区分后续修订 | V1.1 |
| 发现项 | 评审中提出的问题 | 逐条编号描述，注明严重程度 | F01：缺少异常工况需求（中） |
| 处置结论 | 对发现项的处理决定 | 填写“接受并修改、拒绝并说明理由、转下版处理”等结论 | 接受并修改 |
| 关闭状态 | 发现项是否已处理完毕 | 填写“打开、处理中、已关闭”，关闭需有验证人 | 已关闭 |
| 关闭日期 | 发现项关闭日期 | 全部发现项关闭后填写，与状态字段对应 | 2024-05-20 |
标识类字段强调唯一和稳定，编号一旦发布不随内容修订改变；内容类字段强调可验证，描述应能对应到具体条目；追溯类字段强调双向，上游和下游都要有记录，单侧追溯在评审时容易被判为不完整。版本信息与评审记录中的版本号必须能对应到主表当前版本或历史版本，避免出现无法定位的版本引用。
必填与选填：哪些字段不能空
必填字段是保证工作产品可识别、可追溯、可评审的最小集合。以下清单可作为项目过程定义的默认基线，再按工作产品类型裁剪。
| 类别 | 字段 | 要求 | 说明 |
|---|---|---|---|
| 必填 | 工作产品名称、编号、所属过程域、所属过程 | 不能为空 | 构成工作产品的基本身份 |
| 必填 | 版本号、状态、责任人 | 不能为空 | 保证版本可识别、责任可落实 |
| 必填 | 创建日期、最近更新日期 | 不能为空 | 支撑配置管理与审计 |
| 必填 | 上游输入 | 不能为空，顶层工作产品填“无”并说明依据 | 追溯链起点 |
| 必填 | 评审编号、评审类型、评审人、评审日期、评审版本、发现项、处置结论、关闭状态 | 发生评审即必填 | 未评审的工作产品在状态中体现 |
| 必填 | 版本信息区的版本号、变更日期、变更人、变更内容摘要 | 每次变更必填 | 与主表版本号对应 |
| 选填 | 下游输出 | 可后补 | 下游尚未建立时可暂空，建立后补充 |
| 选填 | 备注 | 可空 | 无补充信息时不填 |
| 选填 | 变更原因、审批人 | 按项目要求 | 涉及基线变更时建议必填 |
| 选填 | 关闭日期 | 关闭后填写 | 与关闭状态同步 |
按工作产品类型裁剪时，可遵循三条规则：一是内容字段随类型变化，需求类保留优先级和验收准则，设计类保留接口和约束，测试类保留前置条件和预期结果；二是追溯字段按过程链保留，位于追溯链末端的工作产品可以只保留上游输入；三是评审字段按评审制度保留，若项目规定某类工作产品只做走查，评审类型和发现项仍要记录，评审人可只列组织者与主要检查人。
出现空缺时的处理方式要写进填写说明：必填字段暂时无法确定，填写“待定”并注明责任人和计划完成日期，不能留空白；选填字段不适用时填“不适用”并简述原因，避免读者误以为遗漏；评审发现项未关闭时，关闭状态保持“打开”或“处理中”，工作产品状态不宜标为“已批准”。
填写示例：一份填好的工作产品记录
以下为演示情景，用于说明各字段如何对应，不代表真实项目记录。示例选择软件需求规格说明，覆盖主表、版本信息和评审记录三部分。
示例背景
某车载控制器项目处于软件需求分析阶段，需求规格说明经过两轮同行评审后进入基线。工作产品编号按项目规则生成，评审记录与版本变更一一对应。
主表填写示例
| 字段 | 填写内容 |
|---|---|
| 工作产品名称 | 软件需求规格说明 |
| 工作产品编号 | SRS-PRJ01-001 |
| 所属过程域 | SWE.1 |
| 所属过程 | 软件需求分析 |
| 版本号 | V1.2 |
| 状态 | 已批准 |
| 责任人 | 张工（工号1023） |
| 创建日期 | 2024-03-11 |
| 最近更新日期 | 2024-05-20 |
| 上游输入 | SYS-RS-004；SYS-RS-007 |
| 下游输出 | SWE.4-UT-012 |
| 内容字段一：需求描述 | 制动信号采样周期不大于10ms |
| 内容字段二：优先级 | 高 |
| 内容字段三：验收准则 | 台架测试连续采样1000次，超时次数为0 |
| 备注 | 依赖供应商接口文档V2 |
版本信息填写示例
| 版本号 | 变更日期 | 变更人 | 变更内容摘要 | 变更原因 | 审批人 |
|---|---|---|---|---|---|
| V1.0 | 2024-03-11 | 张工 | 初版建立，覆盖12条软件需求 | 需求分析启动 | 赵工 |
| V1.1 | 2024-04-18 | 张工 | 补充异常工况需求3条，修订2条验收准则 | 第一轮评审发现项处理 | 赵工 |
| V1.2 | 2024-05-20 | 张工 | 按第二轮评审意见调整需求编号与追溯关系 | 第二轮评审发现项关闭 | 赵工 |
评审记录填写示例
| 评审编号 | 评审类型 | 评审人 | 评审日期 | 评审版本 | 发现项 | 处置结论 | 关闭状态 | 关闭日期 |
|---|---|---|---|---|---|---|---|---|
| SRS-PRJ01-001-R01 | 同行评审 | 李工（需求）、王工（测试） | 2024-04-12 | V1.0 | F01：缺少异常工况需求（中）；F02：验收准则不可测量（低） | F01接受并修改；F02接受并修改 | 已关闭 | 2024-04-18 |
| SRS-PRJ01-001-R02 | 同行评审 | 李工（需求）、王工（测试）、赵工（质量） | 2024-05-16 | V1.1 | F03：需求编号与系统需求追溯不一致（中） | 接受并修改 | 已关闭 | 2024-05-20 |
示例与字段说明的对应关系体现在三处：主表版本号V1.2与版本信息最后一条记录一致；评审记录中的评审版本V1.0、V1.1分别对应历史版本，说明评审针对的是当时版本；发现项关闭日期与最近更新日期衔接，表明修改完成后才更新主表状态。按同样方式填写其他工作产品时，只需替换内容字段和追溯编号，表头与口径保持不变。
调整与维护：版本升级、评审归档与模板演进
模板能否长期使用，取决于版本规则、归档方式和修订流程是否明确。以下规则可作为项目配置管理计划的一部分，按项目规模裁剪。
版本号与变更记录规则
- 版本号采用“主版本.次版本”格式。工作产品范围、结构或关键结论变化时升主版本；文字修订、追溯关系补充、发现项处理升次版本。
- 每次变更在版本信息区新增一行，不覆盖历史行。变更内容摘要写清改了哪些条目，避免只写“修改若干问题”。
- 进入基线后，版本变更需经审批人确认，审批人姓名记入版本信息区。
- 主表“最近更新日期”与版本信息最后一条变更日期保持一致，评审记录中的评审版本必须能在版本信息区找到对应行。
评审记录的归档与保留
- 评审记录随工作产品一同归档，评审编号与工作产品编号建立固定关联，便于按工作产品反查全部评审活动。
- 发现项关闭后保留原始描述和处置结论，不删除已关闭条目；后续版本再次涉及同一问题时新增评审编号，不修改历史记录。
- 归档保留期限按项目过程定义和客户合同要求确定，基线版本及其评审记录在项目结束后仍需可查。
- 评审记录中的评审人、日期与会议记录或评审工具中的记录保持一致，出现差异时以正式评审记录为准并注明更正原因。
模板字段的增删流程
模板字段调整应走变更流程：提出人说明新增或删除字段的理由和影响范围，过程负责人评估对已有工作产品和追溯关系的影响，经评审后发布新版本模板。新增字段对存量工作产品可采取“新项目启用、在研项目按阶段切换”的方式，避免一次性返工。删除字段前确认没有评审或审计要求依赖该字段。
定期复核与责任人
建议每个项目阶段结束时复核一次模板使用情况，检查必填字段空缺率、评审记录完整性和版本信息与实际变更是否一致。模板维护责任落到过程负责人或质量角色，填写责任落到各工作产品责任人。复核发现的问题记入过程改进清单，作为下一版模板修订的输入。
当工作产品数量较多、评审轮次频繁时，模板的版本信息和评审记录容易分散在多个文档中。ONES Wiki 支持页面模板库，可一键创建制式化文档模板，把主表和填写说明固化为统一页面；页面版本记录支持查看与回滚，评审记录可作为页面内容随工作产品一起留存。ONES 研发管理 + ASPICE 解决方案的线上化建设阶段支持研发全生命周期流程活动和跨域协作的可追溯性，适合将工作产品编号、追溯关系与评审状态放在同一平台维护。具体模板内容和字段口径仍需团队按自身过程定义设计，工具承载的是版本、权限与关联关系。
常见问题
工作产品还没有完成评审，主表状态应该怎么填？
按实际进展填写，不要提前标为“已批准”。尚未提交评审时填“草稿”；已提交但结论未出时填“评审中”；评审通过并完成发现项处理后才能填“已批准”。如果评审中仍有未关闭的发现项，状态保持“评审中”，关闭状态对应填“打开”或“处理中”，待全部关闭后再更新状态和关闭日期。
上游输入暂时拿不到编号，必填字段能先空着吗？
不建议留空白。填写说明中应约定：暂时无法确定的上游输入填“待定”，同时注明责任人和计划补齐日期，便于复核时追踪。若该工作产品本身就是追溯链起点，填“无”并简要说明依据，例如依据项目立项文件或客户合同。留空白会让评审和审计无法判断是遗漏还是确实不适用。
评审记录和版本信息能否合并成一张表？
可以合并，但需要保留两类信息各自的字段。合并后每行同时记录版本变更和对应评审，适合评审轮次少、变更不频繁的工作产品。若一份工作产品存在多次变更但只评审其中部分版本，合并表容易出现版本行与评审行对不齐的情况，此时分开两张表更清晰。无论是否合并，评审版本都必须能在版本信息中找到对应行。
不同过程域的工作产品，内容字段差异很大，模板怎么统一？
统一表头和标识、追溯、版本、评审字段，内容字段按工作产品类型分别定义。需求类可设需求描述、优先级、验收准则；设计类可设接口、约束、设计决策；测试类可设测试目的、前置条件、预期结果。填写说明中为每类工作产品列一组推荐内容字段，项目可按过程定义增删，但同一类型内保持口径一致，便于横向比较和评审检查。
评审记录归档后，后续版本又改了同一处内容，历史记录要更新吗？
历史记录保留原样，不修改已关闭条目。后续版本再次涉及同一问题时，新增评审编号和新的发现项记录，在描述中注明与此前发现项的关联。这样既能看出问题反复出现的情况，也能保持每次评审记录的独立性。归档保留期限按项目过程定义和客户合同要求确定，基线版本及其评审记录在项目结束后仍需可查。
