需求资产审核检查清单围绕“能否被复用、能否被追溯”两条主线组织：先确认资产身份与来源，再核对内容完整性与复用条件，然后检查分类标签与关联关系，最后确认审核结论、责任人与留档证据。清单适用于需求条目入库前、被其他项目引用前以及定期复核三个时点，每项检查都写明通过标准、证据形式和负责人，缺少来源、复用边界或结论记录的项设为阻断项。
要点总览（TL;DR）
- 清单按“能否被复用、能否被追溯”两条主线分四段：资产身份与来源、内容完整性与复用条件、分类标签与关联关系、审核结论与留档。
- 每项检查都要写明检查内容、通过标准、证据形式和负责人，否则无法逐项勾选，也无法在复核时判断是否通过。
- 来源缺失、复用边界未写明、结论无责任人、证据不可查、编号重复应设为阻断项；变更记录不全、术语口径偏差可限期整改。
- 整体完成条件是全部阻断项通过、整改项已登记责任人与复查日期、审核记录可检索，三条同时满足才进入可复用状态。
- 清单在入库前、复用引用前、定期复核三个时点使用，只审内容复用价值与可追溯性，需求池排序与产品线布局不在范围内。
谁在什么时点使用这份审核清单
这份清单的审核对象是准备进入需求资产库的条目，以及已经入库、即将被其他项目引用的需求资产。它判断的是这条需求内容是否值得复用、复用时可追溯到哪里，不负责管理待处理需求集合的优先级排序，也不涉及产品线能力布局的规划决策。前者属于需求池管理的日常工作，后者属于产品线层面的规划职责。
使用角色分为三类。需求提出人负责准备资产内容与来源材料，在提交审核前完成自检；资产管理员负责组织审核、核对标签口径、维护资产库结构；评审人负责判断内容质量与复用边界，给出审核结论。三类角色在清单上各有对应的检查项和签字位置。
审核触发时点有三个。入库前审核确认新条目是否达到资产标准；复用引用前审核确认引用方理解适用范围与约束条件；定期复核按固定周期检查已入库资产是否仍然有效、关联关系是否失效。三个时点的检查重点不同，入库前侧重完整性与来源，复用前侧重边界与依赖，复核侧重时效与关联有效性。
| 角色 | 主要时点 | 审核范围 | 在清单中的职责 |
|---|---|---|---|
| 需求提出人 | 入库前 | 资产内容、来源材料、复用说明 | 提交前自检，补齐来源与边界说明 |
| 资产管理员 | 入库前、定期复核 | 编号规则、标签口径、关联关系、留档位置 | 核对分类与关联，组织复核，维护资产库结构 |
| 评审人 | 入库前、复用引用前 | 内容完整性、复用条件、审核结论 | 判断是否通过，写明理由与整改项 |
| 引用方 | 复用引用前 | 适用范围、前置依赖、定制部分 | 确认自身场景落在适用范围内，登记引用关系 |
资产身份与来源检查项
第一阶段解决“这条资产是什么、从哪里来”。身份不清或来源缺失的条目，后续无法被检索，也无法在出现争议时回溯到原始业务场景，因此这一阶段的检查结果直接决定能否进入下一阶段。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 资产编号与名称 | 编号在资产库内唯一，名称能区分业务场景，不含“需求1”“优化项”这类泛称 | 资产库条目截图或系统记录 | 资产管理员 | 是 |
| 原始需求来源 | 提出方、业务场景、关联单据或原始工单编号均已记录，可顺着记录找到提出时的上下文 | 来源链接、工单编号、会议纪要引用 | 需求提出人 | 是 |
| 版本号与更新时间 | 版本号按团队规则递增，最近更新时间与本次提交时间一致 | 版本记录或变更日志 | 需求提出人 | 是 |
| 历史变更记录 | 此前每次内容调整都有记录，能看出改了什么、为什么改 | 变更记录列表 | 资产管理员 | 否 |
| 可检索性 | 用名称关键词或编号能在资产库中直接搜到，不依赖人工转述 | 检索结果截图 | 资产管理员 | 否 |
来源记录的判断标准是“第三方能独立还原”。例如一条来自客服系统的需求，记录中应包含工单编号和提出客户类型，评审人不需要询问提出人就能理解这条需求为什么存在。版本号与更新时间用于判断资产是否处于有效状态，长期未更新且无变更说明的条目应在复核时重新确认。
内容完整性与复用条件检查项
第二阶段判断内容本身是否达到可复用程度。可复用的需求资产要让引用方在不反复询问原作者的情况下理解需求、判断适用性、估算改造成本，因此检查重点落在描述完整性、边界清晰度和验收可判断性上。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 需求描述、背景与目标 | 描述说明要解决什么问题，背景交代业务场景，目标给出可观察的结果，三者相互对应 | 需求文档正文 | 需求提出人 | 是 |
| 适用范围与不适用条件 | 写明适用于哪些业务场景、哪些角色、哪些产品模块，同时写明明确不适用的情形 | 需求文档中的适用范围章节 | 需求提出人 | 是 |
| 前置依赖与约束条件 | 列出依赖的系统、数据、上游需求或组织条件，以及时间、合规、技术方面的约束 | 依赖清单或关联需求链接 | 需求提出人 | 是 |
| 验收口径或成功判据 | 给出可判断的验收条件，例如具体指标、可演示的操作结果或检查步骤，避免“体验良好”这类无法判定的表述 | 验收标准条目 | 评审人确认 | 是 |
| 可复用部分与定制部分 | 明确哪些内容可直接复用、哪些需要按项目定制，定制部分说明改动点和影响范围 | 复用说明段落 | 需求提出人 | 是 |
| 术语与口径一致 | 文中使用的业务术语与团队既有口径一致，同一概念前后称呼统一 | 文档比对 | 评审人 | 否 |
复用边界是这一阶段最容易出问题的检查项。一条需求如果只写“适用于订单场景”，引用方无法判断自己的订单场景是否在范围内。可操作的写法是把适用条件拆成可核对的条目，例如业务类型、订单来源、结算方式各是什么范围，再单独列出需要定制的部分。阻断判定上，适用范围缺失或复用边界未写明的条目应退回补充，不能以“先入库再完善”的方式放行。
分类标签与关联关系检查项
第三阶段解决“以后能不能被找到、能不能看出与其他资产的关系”。标签和关联决定资产在库中的可发现性，也决定后续变更时能否沿关系分析影响范围。
| 检查项 | 通过标准 | 核对方式 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 业务域、产品模块、需求类型标签 | 三类标签均已填写，取值来自团队约定的标签表，不出现自造标签 | 对照标签表逐项核对 | 资产管理员 | 是 |
| 关联需求与文档 | 与相关需求、设计稿、接口文档、测试用例的关联已建立，链接可打开 | 逐条点击关联链接验证 | 需求提出人 | 是 |
| 重复或相似资产比对 | 入库前检索过相似资产，存在重复或高度相似时说明合并、替代或并存的理由 | 检索记录与比对说明 | 资产管理员 | 是 |
| 标签口径一致性 | 标签含义与团队约定一致，同一业务域在不同资产上使用相同标签 | 抽样比对同类资产 | 资产管理员 | 否 |
| 关联关系有效性 | 关联对象未被关闭或删除，指向的文档为最新版本 | 复核时点抽查 | 资产管理员 | 否 |
重复比对建议在入库前和定期复核时各做一次。入库前比对防止同一需求以不同名称重复入库，稀释资产库的检索质量；复核时比对可以发现业务变化后产生的相似资产，及时合并。比对结论要写成明确处理方式，例如“与资产A合并”“作为资产A的定制版本并存”，仅写“已比对”不构成通过证据。
审核结论、责任人与证据留档检查项
第四阶段确认审核过程本身可追溯。前面三个阶段检查的是资产内容，这一阶段检查的是审核动作有没有留下可查的记录，包括谁审的、什么时候审的、结论是什么、依据在哪里。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 审核结论与理由 | 结论为通过、有条件通过或退回三者之一，并写明判断理由，理由对应到具体检查项 | 审核记录 | 评审人 | 是 |
| 审核人与审核日期 | 审核人实名记录，日期与本次审核实际发生时间一致 | 审核记录签署栏 | 评审人 | 是 |
| 证据清单 | 来源记录、评审记录、关联链接集中列出，第三方可按清单逐项打开验证 | 证据清单附件或链接集合 | 资产管理员 | 是 |
| 有条件通过的整改项 | 逐条列出待整改内容、责任人和复查时点，复查时点具体到日期 | 整改项列表 | 评审人 | 是 |
| 留档位置与可检索性 | 审核记录存放在约定位置，能通过资产编号或名称检索到 | 留档位置说明与检索验证 | 资产管理员 | 是 |
审核记录与资产内容放在同一处管理，追溯成本最低。以 ONES 为例，需求、基线、版本和变更可以作为统一管理对象，需求条目与任务、测试、交付内容建立关联后，变更发生时能沿关联关系分析受影响范围，过程记录也随工作项保留。审核结论、整改项和复查时点可以记录在对应工作项或文档中，与资产条目保持同一入口，避免审核记录散落在邮件和聊天记录里。这一做法适合已经把需求、测试和交付放在同一平台管理的团队；审核流程仍按团队自身的角色分工设计。
阻断项与完成条件
阻断项指不满足就不能入库、不能被引用的检查项。把阻断项与整改项分开，可以避免审核结论模糊：阻断项未通过时结论只能是退回，其余问题可以进入有条件通过并限期整改。
| 类别 | 具体情形 | 处理方式 |
|---|---|---|
| 阻断项 | 来源缺失，无法还原提出方与业务场景 | 退回补充来源，补齐后重新提交 |
| 阻断项 | 复用边界未写明，适用与不适用条件缺失 | 退回补充边界说明 |
| 阻断项 | 审核结论无责任人签署或结论类型不明确 | 退回重新审核并签署 |
| 阻断项 | 证据不可查，链接失效或记录无法打开 | 退回补齐证据后重新提交 |
| 阻断项 | 资产编号重复或名称无法区分场景 | 退回重新编号命名 |
| 整改项 | 历史变更记录不完整、术语口径不一致、标签口径偏差 | 有条件通过，约定整改时限，到期复查 |
| 整改项 | 关联关系指向旧版本文档 | 有条件通过，限期更新关联 |
整体完成条件可以归纳为三条：全部阻断项通过；有条件通过的整改项已登记责任人与复查日期；审核记录与证据已存放在约定位置并可检索。三条同时满足，资产才进入可复用状态。
退回后的处理路径需要固定下来。退回时评审人写明退回原因对应的检查项编号，需求提出人按项补充后重新提交，资产管理员核对补充内容是否覆盖原问题，评审人只对变更部分复查，避免整份重审拖长周期。定期复核发现资产失效时，按同样路径处理：先标记为待复核，暂停新的引用，再决定更新、合并或归档。复查时点到期未整改的条目，应从可复用状态移出，防止过期资产继续被引用。
常见问题
需求资产审核和需求评审是同一件事吗？
两者关注点不同。需求评审通常判断一条需求是否值得做、方案是否可行；需求资产审核判断的是这条需求内容能否作为资产被其他项目复用、复用时可追溯到哪里。一条需求可能通过了评审并已交付，但描述里没有写明适用范围和复用边界，仍然无法通过资产审核。实际操作中可以把资产审核放在需求交付后、入库前进行，复用评审结论作为来源证据之一，减少重复判断。
团队规模小、资产条目不多，还需要设这么多检查项吗？
可以按风险裁剪，但阻断项建议保留。资产条目少时，标签口径核对、重复比对可以合并成一次检索动作，历史变更记录的要求也可以简化。来源记录、复用边界、审核结论与责任人、证据可查这四类阻断项不建议去掉，它们决定资产在半年后是否还能被理解和使用。裁剪后的清单应写明哪些项被合并、由谁执行，避免复核时找不到判断依据。
有条件通过之后，整改项到期没人复查怎么办？
把复查时点写成具体日期并指定复查人，是让整改闭环的前提。到期未整改的条目应从可复用状态移出，暂停新的引用，再由资产管理员决定是继续整改、合并还是归档。复查人可以是原评审人，也可以是资产管理员，但要在审核记录中写明。若团队使用统一平台管理工作项，可以把整改项作为独立工作项指派给责任人并设置截止日期，让到期提醒和状态变化留在同一处，减少靠人工记忆跟踪。
已入库的资产在定期复核时发现关联文档已失效，应该直接归档吗？
先判断失效原因再决定处理方式。如果关联文档只是换了版本或位置，更新关联链接即可恢复；如果关联对象对应的业务已经下线，资产本身可能仍有参考价值，应更新适用范围说明并标注历史状态；只有内容整体过时且无复用场景时，才走归档流程。复核发现问题的条目先标记为待复核、暂停新引用，处理结论和依据记入审核记录，便于后续追溯为什么归档或为什么保留。
审核记录放在哪里，才能既方便追溯又不增加额外维护负担？
优先放在资产条目同一入口下，让审核结论、整改项、证据链接和资产内容一起被检索到。以 ONES 为例，需求、基线、版本和变更可以作为统一管理对象，需求条目与任务、测试、交付内容建立关联后，变更发生时能沿关联关系分析受影响范围，过程记录随工作项保留。这一做法适合已经把需求、测试和交付放在同一平台管理的团队；审核流程本身仍按团队角色分工设计，记录字段按本文清单设置即可。
