需求资产失效清理的核心，是建立一套可重复执行的定期评审机制：先定义失效判定标准，再按固定周期筛选候选、分级评审、执行处置并留痕，最后用复用率和误删率验证机制是否有效。本文按“判定标准—评审组织—分级处置—示例—完成检查”的顺序展开，适合正在维护需求资产库、希望把清理从临时动作变成固定流程的团队参考。在状态标记、关联关系保留和评审记录留存这些环节，ONES的需求管理与文档协作能力可以承接流程中的管理动作。
要点总览（TL;DR）
- 失效清理先统一判定口径：把长期无引用、来源终止、被新需求覆盖、业务下线四类信号写成字段或筛选规则，并同步写明合规留存、路线图内、被依赖三类保留例外。
- 评审采用固定季度加重大变更触发的双节奏，资产负责人、需求提出方、业务代表、评审主持人各司其职，流程按候选清单、初审、评审会、处置执行、留痕五步推进。
- 处置按归档、合并、降级、删除分级执行，合并与降级保留原需求编号、关联关系和理由，删除前完成依赖检查与备份并记录操作人、时间和原因。
- 机制是否跑通看四项检查是否齐备，并用复用率变化、误删误归档率、评审耗时三项指标连续观察两到三个季度。
- 误删要有恢复路径，争议资产暂缓处理并标注争议状态，每轮把误判案例和耗时瓶颈整理成下一轮调整阈值与保留条件的输入。
失效判定标准怎么定
清理的第一件事是把“什么算失效”写成统一口径。如果每次评审都靠参会人临场判断，不同人给出的结论会不一致，清理结果也难以复核。可行的做法是把失效信号、阈值、保留例外和判定人整理成一张判定标准表，让候选筛选和评审讨论都引用同一套规则。
常见的失效信号有四类。第一类是长期无引用：需求资产在约定时间内没有被任何在用需求、设计文档或测试用例引用。第二类是需求来源已终止：提出该需求的业务方、项目或合同已经结束，需求失去继续维护的依据。第三类是被新需求完全覆盖：新需求在范围和验收条件上完整替代了旧需求，旧需求只剩历史价值。第四类是对应业务已下线：需求所服务的功能或业务场景已经停止运营。
与失效信号对应，还要明确保留条件。合规留存要求是最硬的一条，涉及审计、合同或监管留存期的资产，即使业务上已无引用，也应保留并标注留存期限。仍在路线图内的需求，即使当前没有引用，也应保留。被其他需求依赖的需求，包括作为前置条件、父需求或接口约定被引用的，需要先解除依赖再判断是否失效。
| 失效信号 | 建议阈值示例 | 保留例外 | 判定人 |
|---|---|---|---|
| 长期无引用 | 连续12个月无任何引用记录 | 在路线图内、处于合规留存期 | 资产负责人初审，评审会确认 |
| 需求来源已终止 | 来源项目结项或合同到期 | 存在后续维护承诺 | 需求提出方确认 |
| 被新需求完全覆盖 | 新需求范围与验收条件完整包含旧需求 | 旧需求含未被覆盖的约束条件 | 业务代表与资产负责人共同确认 |
| 对应业务已下线 | 业务下线公告生效 | 合规留存要求 | 业务代表确认，评审会记录 |
阈值需要结合团队实际设定，上表仅为示例口径。判定标准落地时，建议把信号做成资产字段或筛选规则，例如“最后引用时间”“来源状态”“替代需求编号”，让候选清单可以由规则自动生成，评审会只处理规则筛出后仍有争议的部分。判定人一栏也要写清楚，避免出现无人认领的资产长期悬置。
定期评审怎么组织：周期、角色与流程
判定标准确定后，需要一套固定的组织方式让清理持续发生。推荐采用“固定季度评审加重大变更触发”的双节奏：每季度执行一次全量候选筛选和评审；当出现业务下线、重大项目结项或需求体系大规模重构时，额外触发一次专项评审，避免过期资产在季度间隙持续堆积。
角色分工建议覆盖四类人。资产负责人负责维护判定规则、生成候选清单并执行处置动作；需求提出方负责确认来源是否终止、需求是否仍有业务价值；业务代表从使用视角判断资产是否还被依赖；评审主持人负责组织会议、控制节奏并记录结论。角色可以由同一人兼任，但职责要在流程说明中写清楚。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 资产负责人 | 维护判定规则，生成候选清单，执行处置并更新状态 | 候选清单、处置记录 |
| 需求提出方 | 确认需求来源状态与业务价值 | 来源确认意见 |
| 业务代表 | 判断资产是否仍被业务依赖 | 保留或处置建议 |
| 评审主持人 | 组织评审会，汇总结论，跟踪执行 | 评审纪要、待办清单 |
流程可以拆成五步，每步都有明确的输入、动作、输出和完成标志。第一步生成候选清单：输入是判定规则和资产库数据，动作是按信号筛选，输出是带信号标签的候选清单，完成标志是清单经资产负责人确认无遗漏。第二步初审：输入是候选清单，动作是资产负责人逐条核对保留条件，输出是初审意见，完成标志是每条候选都有初步结论。第三步评审会：输入是初审意见，动作是需求提出方和业务代表逐条确认，输出是处置决定，完成标志是争议项有明确归属。第四步处置执行：输入是处置决定，动作是按分级动作操作并更新状态，输出是处置记录，完成标志是候选清单全部关闭。第五步留痕：输入是评审纪要与处置记录，动作是归档到统一位置，输出是可追溯的清理档案，完成标志是下一次评审可以调阅。
在工具层面，这套流程需要资产状态、关联关系和评审记录能够被持续追踪。ONES 的需求管理支持为需求设置状态与字段，评审结论和处置记录可以随需求条目留存，关联关系也能在合并或降级时保留，便于下一轮评审直接调阅历史结论。
分级处置：归档、合并、降级与删除
确认失效后，处置动作不宜只有“删除”一种。按失效程度和资产价值分为归档、合并、降级、删除四类，既能控制资产库规模，也能保留必要的历史信息。
| 处置动作 | 适用情形 | 操作要求 |
|---|---|---|
| 归档 | 业务已结束但需保留历史记录，或处于合规留存期 | 移出活跃视图，标注归档原因与留存期限，保留原始内容 |
| 合并 | 被新需求完全覆盖，且旧需求无独立约束条件 | 将旧需求关联到新需求，保留来源链接与合并说明 |
| 降级 | 需求仍有参考价值但不再作为独立需求维护 | 转为背景资料或备注，保留与原需求的关联 |
| 删除 | 确认无引用、无留存要求、无依赖关系 | 删除前完成依赖检查与备份，记录删除原因与操作人 |
合并和降级最容易丢失信息，操作时要保留三类内容：原需求的编号与标题、与新需求或新载体的关联关系、合并或降级的理由。这样后续追溯“某个约束条件从哪来”时仍有据可查。删除是风险最高的动作，执行前要完成依赖检查，确认没有其他需求引用该资产，并按团队规定做备份或导出；删除记录中写明操作人、时间和原因，便于出现争议时回退。
所有处置结果都要有状态标记，例如“已归档”“已合并至某需求”“已降级”“已删除”，并保留对应的评审记录编号。状态标记让资产库的当前视图保持干净，评审记录则保证清理过程可追溯，两者缺一不可。
示例：一次季度失效清理的完整过程
以下为演示情景，用于说明流程如何落地，数据为示例设定。
某团队在季度初启动清理，资产库中共有约300条需求资产，候选范围是全部处于“活跃”状态且超过12个月未更新的条目。资产负责人按判定规则筛出42条候选，其中“长期无引用”28条、“来源已终止”9条、“被新需求覆盖”5条。
初审阶段，资产负责人逐条核对保留条件，发现6条处于合规留存期、3条仍在路线图内，予以保留并标注原因；剩余33条进入评审会。评审会上，需求提出方确认了9条来源终止的需求，业务代表对5条被覆盖需求逐一比对范围，确认其中4条可合并、1条含未被覆盖的约束条件需保留。对28条长期无引用的资产，评审会按业务价值分为归档18条、降级7条、删除3条，删除项在会前已完成依赖检查。
处置执行阶段，资产负责人按决定更新状态：18条标记“已归档”并注明留存期限，4条标记“已合并”并关联到新需求，7条标记“已降级”并转为背景资料，3条完成备份后删除。评审纪要与处置记录统一归档，候选清单全部关闭。清理后，活跃视图中的需求资产从300条降至约270条，被保留的9条资产在记录中写明了保留依据，下一季度评审可直接复核。
完成检查：机制是否跑通
一次清理完成不代表机制有效，需要用检查项和指标验证流程是否真正跑通。流程完整性检查可以先做：判定标准是否成文并可被规则筛选、评审周期是否已排入日程、四类角色是否都有明确人选、处置记录是否可追溯。四项齐备，机制才具备重复执行的基础。
| 检查维度 | 检查项 | 通过标志 |
|---|---|---|
| 标准 | 失效信号、阈值、保留例外、判定人是否成文 | 候选清单可由规则生成 |
| 周期 | 季度评审与重大变更触发是否已排期 | 下一次评审日期已确定 |
| 角色 | 资产负责人、提出方、业务代表、主持人是否到位 | 每条候选都有确认人 |
| 留痕 | 评审纪要与处置记录是否统一归档 | 可调阅上一轮完整记录 |
效果指标建议关注三项：复用率变化，观察清理后活跃资产被引用的比例是否上升；误删或误归档率，通过抽查已处置资产中被重新启用的比例来衡量；评审耗时，记录从生成候选到关闭清单的实际工时，判断节奏是否可持续。指标不必追求单次好看，连续两到三个季度的趋势更能说明机制是否稳定。
异常与回退同样要提前约定。误删的恢复路径应写清楚：从备份或归档记录中恢复，并记录恢复原因；对评审会上无法达成一致的争议资产，采取暂缓处理并标注争议状态，留到下一轮评审再议，避免为了关闭清单而仓促删除。每轮评审结束后，把误判案例、耗时瓶颈和争议原因整理成下一轮改进的输入，例如调整阈值、补充保留条件或优化候选清单的字段，让机制在迭代中逐步贴合团队实际。
常见问题
需求资产长期没人引用，是不是就可以直接删除？
长期无引用只是失效信号之一，不能直接作为删除依据。进入处置前要先核对保留条件：是否处于合规留存期、是否仍在路线图内、是否被其他需求作为前置条件或接口约定引用。三项都排除后，还要看资产是否仍有参考价值，有参考价值的优先归档或降级，删除只用于确认无引用、无留存要求、无依赖关系的条目。删除前完成依赖检查与备份，并记录操作人、时间和原因。
季度评审期间业务发生重大变更，清理节奏怎么调整？
在固定季度评审之外增加一次专项触发评审即可，不必打乱原有季度安排。业务下线、重大项目结项或需求体系大规模重构发生时，由资产负责人按判定规则重新生成候选清单，针对受影响范围组织一次小范围评审，处置结论并入当季清理档案。这样既避免过期资产在季度间隙堆积，也保持评审记录按季度归集，便于后续复核。
评审会上对某条资产是否失效有分歧，应该怎么处理？
分歧项不强行表决，采取暂缓处理并标注争议状态，留到下一轮评审再议。暂缓期间该资产保持原状态，不进入归档或删除流程。主持人把争议原因记入评审纪要，例如引用数据不完整、业务归属不清或保留条件存在解释空间，并指定补充材料的责任人和期限。下一轮评审先处理上一轮遗留的争议项，避免争议资产长期悬置。
合并和降级之后，原来的需求信息还能追溯吗？
可以，前提是操作时保留三类内容：原需求的编号与标题、与新需求或新载体的关联关系、合并或降级的理由。合并时把旧需求关联到新需求并写明合并说明；降级时转为背景资料或备注，同时保留与原需求的关联。这样后续追溯某个约束条件的来源时仍有据可查。处置完成后同步更新状态标记，例如“已合并至某需求”“已降级”，并记录对应的评审记录编号。
清理机制运行多久才能判断是否有效？
建议连续观察两到三个季度的趋势，单次清理的数据容易受候选范围和业务波动影响。重点看三项指标：活跃资产被引用的比例是否上升、已处置资产中被重新启用的比例是否下降、从生成候选到关闭清单的实际工时是否稳定。同时每轮结束后整理误判案例和耗时瓶颈，作为调整阈值、补充保留条件或优化候选清单字段的依据，让机制逐步贴合团队实际。
