设计研发过程符合性检查项，核心是把过程要求转成可观察的证据，再按风险确定抽样，最后用统一口径判定。本文按“要求—证据—判定”三要素拆解检查项，给出关键过程域的覆盖清单、抽样与样本量规则、判定等级和证据规则，并用一次迭代的检查示例说明从抽取样本到形成整改建议的完整走法，末尾附设计完成自检清单。
要点总览（TL;DR）
- 检查项按“要求条款—证据载体—判定口径”三要素拆解，每条只验证一条要求，做到可观察、可判定。
- 覆盖立项与需求、设计与评审、编码与配置管理、测试与缺陷、发布与变更、问题与回溯六个过程域，未覆盖方向需说明理由。
- 抽样先固定抽样单元，再按风险与频次分层：高风险和低频关键过程全查，常规过程按比例抽查，并保留可复现的抽样记录。
- 判定统一为符合、部分符合、不符合、不适用四级，证据以原始记录优先，口头说明不作为唯一证据，分歧由复核人裁定。
- 清单定稿前做一次设计验收和至少一次试查，把口径分歧与新型证据回写到检查项中。
检查项从过程要求拆到可观察证据
检查项的作用是让不同检查人面对同一份过程记录时得出相同结论。做到这一点，每条检查项需要包含三个要素：要求条款说明依据哪条过程规定检查；证据载体说明去哪里看什么记录；判定口径说明看到什么算符合、看到什么算不符合。三要素齐全，检查项才具备可执行性。
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 检查项编号 | 过程域缩写加序号，便于引用和追踪 | REQ-03 |
| 要求条款 | 引用过程文件或体系要求的具体条款，注明文件名称与条款号 | 《需求管理规程》4.2：需求变更须经评审并留痕 |
| 证据载体 | 可查看的记录类型、所在系统或文档位置 | 需求变更单、变更评审记录、变更前后需求基线版本 |
| 判定口径 | 符合、部分符合、不符合各自的观察特征 | 有变更单且有评审结论为符合；有变更单无评审记录为不符合 |
| 责任角色 | 该要求的过程责任人，用于整改对接 | 需求负责人 |
| 完成标志 | 检查动作结束的客观标志 | 证据已归档至检查记录并给出判定 |
拆解按以下步骤进行。第一步，收集适用的过程文件、体系要求和项目执行规范，形成要求条款清单，标注条款编号和适用范围。第二步，逐条判断该要求在执行后留下什么记录，把记录类型写入证据载体；一条要求对应多种证据时，注明主证据和辅助证据。第三步，为每条要求写出判定口径，用“看到什么—判为什么”的句式描述，避免使用“规范”“完善”这类无法观察的词。第四步，指定责任角色和完成标志，交由过程负责人确认条款理解无误。第五步，试查一到两个项目，检验证据是否真实存在、判定口径是否产生分歧，据此修订。
粒度控制有三个标准：可观察，即检查人能在系统中或文档里直接看到；可判定，即符合与不符合的界限清晰；单一意图，即一条检查项只验证一条要求。常见错误有两类。一类是把多个要求塞进一项，例如“需求评审和变更管理是否规范”，检查人无法给出单一结论，整改时也难以定位。另一类是写成口号，例如“需求管理是否到位”，缺少证据指向，不同检查人的理解差异很大。遇到这类表述，应回到要求条款重新拆分。
关键过程域检查项覆盖清单
检查项覆盖是否完整，可以按研发过程域逐项对照。下表列出各过程域应覆盖的检查方向，组织可在此基础上结合自身过程文件增补条款，形成正式检查项清单。
| 过程域 | 检查方向 | 主要证据 |
|---|---|---|
| 立项与需求 | 需求来源是否有记录；需求评审是否按规则执行；需求变更是否留痕并更新基线 | 需求来源说明、评审记录、变更单、需求基线版本 |
| 设计与评审 | 设计文档是否按模板产出；评审是否有关键角色参与并形成结论；评审问题是否闭环 | 设计文档、评审签到与结论、问题跟踪记录 |
| 编码与配置管理 | 分支策略是否被执行；提交信息是否符合规范；基线是否建立并可追溯 | 代码库分支记录、提交日志、基线清单、配置项变更记录 |
| 测试与缺陷 | 测试用例是否覆盖需求；用例执行记录是否完整；缺陷是否闭环并有验证结论 | 用例库、执行记录、缺陷单及状态流转记录 |
| 发布与变更 | 发布是否经过审批；回滚预案是否准备；生产变更是否有记录 | 发布审批单、回滚方案、变更记录 |
| 问题与回溯 | 问题是否分级；是否开展根因分析；改进措施是否有跟踪和关闭结论 | 问题清单、根因分析记录、改进跟踪表 |
使用这张清单时，建议做一次覆盖核对：把已有检查项按过程域归类，标出没有检查项覆盖的方向，再判断是遗漏还是确实不适用。对于外包或联合开发的项目，还需确认供方过程记录是否纳入证据范围，并在检查项中注明证据获取方式。
抽样方式与样本量怎么定
符合性检查通常无法逐条核查全部记录，抽样方案决定了结论的代表性和检查成本。抽样设计先确定抽样单元，再按风险分层，最后确定样本量并留下可复现的记录。
抽样单元是抽取和判定的基本对象，常见选择包括项目、迭代、工作项、文档和变更单。选择哪种单元取决于检查项的证据形态：验证需求评审执行情况，以需求文档或评审记录为单元；验证缺陷闭环，以缺陷单为单元；验证发布审批，以发布单为单元。同一检查项应固定抽样单元，避免混用导致样本无法比较。
分层依据是风险与频次。高风险过程，例如涉及安全相关功能的需求变更、生产发布、对外交付版本，宜全查；低频但影响大的过程，例如架构评审、重大变更审批，也宜全查。常规过程，例如日常提交规范、一般缺陷处理，可按比例抽查。分层结果应写入抽样方案，说明哪些检查项全查、哪些抽查及理由。
样本量的确定没有统一数值，可参考三个依据：过程执行频次，频次高的过程抽取比例可以低一些，但要保证覆盖不同团队和时间段；历史问题分布，过去问题集中的环节应提高样本量；检查目的，用于过程改进的检查可比用于结论确认的检查抽取更少。实际操作中可设定最低样本要求，例如每个受查项目每个过程域至少抽取若干条记录，低于最低量时全查。样本量一旦确定，检查过程中不因初步结果随意增减；确需调整时记录原因。
抽样记录应包含：抽样单元类型、抽样总体数量、分层规则、抽取方法与随机种子或抽取顺序、实际样本清单、抽样人和抽样时间。记录完整，其他检查人才能按同样规则复现抽样过程，复核时也能判断样本是否具有代表性。
判定标准与证据规则
统一判定等级是不同检查人结论一致的前提。建议采用四级判定，并在检查前向被检查方说明各级含义。
| 判定等级 | 定义 | 记录要求 |
|---|---|---|
| 符合 | 要求条款的全部观察点均有证据支持，执行结果满足判定口径 | 记录证据位置与核对结论 |
| 部分符合 | 要求已执行，但存在证据缺失、执行不完整或个别样本不符合 | 记录符合部分、缺失部分及涉及样本 |
| 不符合 | 要求未执行，或关键证据缺失导致无法证明执行 | 记录缺失内容与影响范围 |
| 不适用 | 该要求在本项目或本迭代范围内不涉及 | 记录不适用理由与确认人 |
证据规则解决“什么算数”的问题。原始记录优先：系统内的操作日志、审批记录、版本历史、缺陷状态流转，其证明力高于二次整理的汇总表；汇总表可作为索引，但关键结论应能回溯到原始记录。口头说明不作为唯一证据，访谈内容可以用于解释记录背景，判定仍需落到书面或系统记录上。证据应能体现时间、责任人和内容三要素，缺少任一要素时按证据不足处理，并在记录中说明。
不适用判定需要谨慎。判定前确认该要求是否真的不在范围内，例如项目未涉及硬件交付，则相关硬件评审要求可判不适用；若只是本迭代未发生某类活动，应记录为“本期未发生”，并在后续检查中关注，不轻易归入不适用。不适用结论应经过程负责人确认并留痕。
判定分歧的处理机制包括：检查人之间对同一证据结论不一致时，提交复核人裁定；复核人依据检查项判定口径和证据规则给出结论，并将分歧案例补充进判定口径说明，供后续检查参考。对判定口径本身存在争议的，回到要求条款原文确认，必要时修订检查项。复核记录应保留分歧点、裁定结论和修订内容。
角色分工与交付物
检查项设计到结论确认涉及多个角色，职责清晰可以减少反复沟通。检查项设计者通常由过程管理或质量角色承担，负责把要求条款拆成检查项、维护判定口径、组织试查修订。过程负责人确认检查项与过程文件一致，并对本过程域的整改负责。检查执行人按抽样方案取证并给出初步判定，被检查方负责提供证据、解释执行情况并确认事实。复核人审核判定结论与证据充分性，处理分歧，确认最终报告。
| 环节 | 责任角色 | 主要交付物 |
|---|---|---|
| 检查项设计 | 检查项设计者、过程负责人 | 检查项清单（含三要素字段）、判定口径说明 |
| 抽样 | 检查执行人 | 抽样方案与抽样记录 |
| 取证与初判 | 检查执行人、被检查方 | 证据清单、检查记录表 |
| 复核与结论 | 复核人 | 检查报告、分歧裁定记录 |
| 整改跟踪 | 过程负责人、检查执行人 | 整改跟踪表、关闭验证记录 |
检查记录、抽样清单和整改事项需要在一个可追溯的载体上流转。ONES 的项目管理与知识库模块可用于承载检查项清单和检查报告，工单管理可用于登记不符合项并跟踪整改状态，测试管理与需求管理中的记录可作为测试、需求类检查项的证据来源。对于按 ASPICE 等模型组织研发过程的团队，ONES 研发管理 + ASPICE 解决方案的线上化建设阶段支持研发全生命周期流程活动和跨域协作的可追溯性，便于检查时按过程域调取记录。具体模块配置需结合团队实际流程确认。
示例：一次迭代的符合性检查怎么走
以下为演示情景，用于说明检查流程，数据为示意。
某项目开展一次迭代级符合性检查，范围覆盖需求变更、设计评审、缺陷闭环和发布审批四个过程域，受查对象为迭代 I-24 的全部工作项与相关文档。检查项从清单中选取八条，其中需求变更和发布审批因涉及对外交付列为全查，设计评审和缺陷闭环按 30% 抽查。
抽样结果：需求变更单共 6 条，全查；发布单 1 条，全查；设计评审记录 10 条，抽取 3 条；缺陷单 40 条，抽取 12 条。抽样记录注明抽取顺序和抽样人。
证据核对与判定：需求变更 6 条中 5 条有变更单和评审结论，判符合；1 条有变更单但评审记录缺失，判不符合，涉及需求基线未同步更新。设计评审 3 条样本均有评审结论，其中 1 条的问题跟踪记录未关闭，判部分符合。缺陷样本 12 条中 11 条状态流转完整并有验证结论，1 条关闭时缺少验证记录，判部分符合。发布单有审批记录和回滚方案，判符合。
问题记录与整改建议：评审记录缺失的变更单，建议补做评审并更新基线，由需求负责人两周内完成；未关闭的评审问题，建议明确责任人和关闭时间；缺陷验证记录缺失，建议在缺陷关闭规则中增加验证结论必填项。三项均登记为整改事项，注明责任角色、期限和验证方式，整改完成后由检查执行人复核关闭。
完成检查：检查项设计是否可用
检查项清单定稿前，用以下清单做一次设计验收。每项都应有明确答案，存在否项的应修订后再投入使用。
- 每条检查项是否包含要求条款、证据载体、判定口径三要素，且判定口径可用“看到什么—判为什么”描述。
- 每条检查项是否只验证一条要求，检查人能否给出单一结论。
- 关键过程域是否全覆盖：立项与需求、设计与评审、编码与配置管理、测试与缺陷、发布与变更、问题与回溯，未覆盖的方向是否已说明理由。
- 抽样方案是否明确抽样单元、分层规则、样本量和最低样本要求，抽样记录字段是否足以复现。
- 判定等级定义是否已向检查人和被检查方沟通，证据规则是否明确原始记录优先、口头说明不作为唯一证据。
- 不适用判定和判定分歧的处理机制是否已确定，复核人是否明确。
- 各环节交付物是否落实：检查项清单、抽样记录、检查记录表、检查报告、整改跟踪表，责任角色是否对应到人。
- 是否完成至少一次试查，并根据试查结果修订了检查项和判定口径。
以上各项确认后，检查项清单即可进入正式检查使用；后续每次检查中发现的口径分歧和新型证据，应回写到检查项和判定说明中，保持清单与过程实际同步。
常见问题
检查项设计完成后，第一次正式检查前需要做哪些准备？
建议先完成三件事。第一，组织检查人和被检查方共同过一遍判定等级与证据规则，确认对“符合”“部分符合”的理解一致。第二，选取一到两个项目做试查，重点检验证据是否真实存在、判定口径是否产生分歧，据此修订检查项。第三，确认抽样方案中的抽样单元、分层规则和最低样本要求已写入记录模板，复核人已明确。试查发现的问题应在正式检查前完成修订，避免带着口径分歧进入全面检查。
项目本迭代没有发生某类活动，检查项应判不适用还是记录未发生？
两者含义不同。不适用指该要求在本项目范围内确实不涉及，例如项目不涉及硬件交付，相关硬件评审要求可判不适用，并需经过程负责人确认留痕。若只是本迭代未发生某类活动，例如本期没有生产发布，应记录为“本期未发生”，在后续检查中继续关注，不轻易归入不适用。把未发生误判为不适用，会让后续检查遗漏该要求；把确实不涉及的要求强行判定，则会产生无意义的整改项。
不同检查人对同一证据得出不同结论时怎么处理？
先回到检查项的判定口径和证据规则核对，确认双方看到的是否为同一份证据、是否按同一口径判断。仍不一致时，提交复核人裁定，复核人依据判定口径和证据规则给出结论，并记录分歧点与裁定理由。若分歧源于判定口径本身表述不清，应回到要求条款原文确认，修订检查项和判定说明，并把该案例补充进口径示例，供后续检查参考。分歧记录应保留在检查报告中，作为清单迭代的输入。
检查记录、抽样清单和整改事项放在哪里流转比较合适？
关键是让证据、判定和整改能相互追溯。检查项清单和检查报告适合放在文档或知识库中统一维护版本；抽样记录与检查记录表可按项目或迭代归档；不符合项登记为工单或工作项，注明责任角色、期限和验证方式，整改完成后由检查执行人复核关闭。ONES 的项目管理与知识库模块可用于承载检查项清单和检查报告，工单管理可用于登记不符合项并跟踪整改状态，测试管理与需求管理中的记录可作为测试、需求类检查项的证据来源。具体模块配置需结合团队实际流程确认。
检查项清单投入使用后，多久需要修订一次？
没有固定周期，可按触发条件修订。常见触发包括：过程文件或体系要求发生变更；检查中出现判定口径分歧且无法用现有说明解释；发现新型证据载体，例如系统迁移后记录位置变化；整改中反复出现同类问题，说明检查项粒度或判定口径需要调整。每次修订应记录变更内容、原因和生效时间，并同步通知检查人和被检查方，避免新旧版本混用导致结论不可比。
