需求复用规则的核心，是把“什么算可复用需求、谁来判断、以什么字段沉淀、在什么节点被检索和引用”写成可执行的判定与流转约定。本文按定义复用单元、设计分类字段、设定准入条件、明确角色交付物、建立登记追溯、完成检查与修订的顺序展开，需求条目和引用关系可以放在需求管理工具中承载，例如ONES的需求管理能力。规则聚焦需求内容复用，待处理需求集合的排序归需求池管理，产品线能力布局归产品线管理。
要点总览（TL;DR）
- 需求复用规则要写清四类判定：复用单元与颗粒度、复用条件、判定角色、引用方式，规则文本按这四块组织，评审时逐项核对。
- 沉淀侧先定复用单元，再设计需求类别、适用场景、约束条件、来源、版本、状态六个必备字段，并用受控标签清单约束命名。
- 判定侧设四项准入条件——场景匹配、约束兼容、版本有效、责任方确认，全部满足才直接复用；不满足时走改造复用、新建需求或退回需求池。
- 复用发生后登记来源需求、复用类型、差异点和责任人，源需求变更由源需求责任人按登记名单通知复用方确认。
- 上线一个月做首次检查，按季度复查字段完整率、判定记录覆盖率、登记完整性和通知及时性，半年复审一次规则。
需求复用规则要解决哪几个判定问题
一份能落地的需求复用规则，需要把四类判定写清楚，否则规则容易停留在原则层面，执行时仍靠个人经验。这四类判定构成规则的总纲，后续章节分别展开具体做法。
- 复用单元与颗粒度：明确复用发生在哪一层。按需求条目复用，适合边界清晰、可独立交付的需求；按需求族复用，适合同一业务目标下的一组相关需求；按能力点复用，适合跨产品线共享的通用能力描述。颗粒度越细，复用机会越多，维护成本也越高，规则要选定一种主口径并说明例外。
- 复用条件：说明什么情况下允许复用、什么情况下必须重新评估。条件通常围绕场景匹配、约束兼容、版本有效和责任方确认展开，具体标准在第三步细化。
- 判定角色：区分谁提出复用候选、谁做领域审核、谁批准复用。提出人通常是需求提出人或需求管理角色，审核人来自需求所属领域，批准人对复用结论负责。
- 引用方式：复用发生后如何记录来源与差异。规则要规定引用字段、差异说明的写法，以及源需求变更时的通知责任，避免同一内容在多处重复维护、彼此不一致。
这四类判定之间是递进关系：先有复用单元，字段设计才有对象；有了字段，判定条件才有比对依据；有了判定，角色分工才有明确动作；有了引用记录，规则才能被检查和修订。规则文本建议按这四块组织，每块给出判定标准和记录格式，便于评审时逐项核对。
第一步：定义复用单元与分类字段
复用单元决定需求以什么形态被沉淀和检索。选择依据主要有三条：需求本身的边界是否清晰、复用方能否独立理解和使用、维护责任是否可落到具体角色。常见做法是以需求条目为主口径，对跨产品线共享的内容再抽象为能力点，需求族作为组织维度而非复用单位。
确定单元后，需要设计一套必备字段，让需求在沉淀时就具备可检索、可比对的属性。字段不宜过多，但要覆盖判定所需的信息。
| 字段名 | 含义 | 填写人 | 填写时点 |
|---|---|---|---|
| 需求类别 | 业务需求、功能需求、合规需求等分类 | 需求提出人 | 需求创建时 |
| 适用场景 | 该需求适用的业务场景或用户群体 | 需求提出人 | 需求创建时 |
| 约束条件 | 依赖的系统、数据、合规或时间前提 | 需求提出人，领域评审人补充 | 评审通过前 |
| 来源 | 原始提出方、关联项目或上游需求 | 需求管理角色 | 需求创建时 |
| 版本 | 需求内容的当前有效版本 | 需求管理角色 | 每次内容变更后 |
| 状态 | 草稿、待评审、可复用、已废弃等 | 需求管理角色 | 状态流转时 |
标签与分类需要命名约定。建议维护一份受控标签清单，规定同义标签只保留一个标准写法，新增标签需经需求管理角色确认；标签层级控制在两层以内，避免出现“支付”“支付相关”“支付类”并存的局面。字段补齐节点要写进流程：创建时填基础字段，评审通过前补齐约束条件，标记为可复用前确认版本和状态有效。
第二步：设定复用判定条件与准入标准
把“能不能复用”从主观判断变成可核对的准入条件，是规则能否执行的关键。建议设定四项准入条件，全部满足才允许直接复用：场景匹配，即复用方的业务场景落在源需求的适用场景范围内；约束兼容，即依赖的系统、数据和合规前提在复用方同样成立；版本有效，即源需求处于可复用状态且版本为当前有效版本；责任方确认，即源需求所属领域的评审人确认复用不会引入冲突。
不满足条件时要有明确处理路径，避免判定卡住后无人推进：
- 改造复用：场景基本匹配但约束存在差异，由复用方提出改造点，经领域评审人确认后按改造复用登记。
- 新建需求：场景或约束差异较大，改造代价高于重新描述，转为新建需求，并在新需求中注明参考的源需求。
- 退回需求池：当前不具备复用条件但未来可能适用，退回待处理集合，由需求池管理流程决定后续排序。
复用等级建议分为直接复用、改造复用、参考复用三档。直接复用指内容原样引用；改造复用指在源需求基础上调整部分内容；参考复用指仅借鉴思路、不引用具体条款。等级不同，登记要求和变更通知范围也不同。每次判定都要留痕，记录判定人、判定日期、结论和依据，判定记录与需求条目关联保存，作为后续检查和争议处理的依据。
第三步：明确角色分工与各环节交付物
规则落地依赖角色与交付物的对应关系。每个关键动作都要有输入、做法和输出，避免职责悬空。
| 角色 | 主要动作 | 输入 | 交付物 |
|---|---|---|---|
| 需求提出人 | 提出复用候选，填写基础字段 | 业务场景与约束信息 | 候选需求条目 |
| 需求管理角色 | 组织候选清单，维护字段与状态 | 候选需求条目 | 复用候选清单、字段完整的需求记录 |
| 领域评审人 | 审核场景匹配与约束兼容 | 候选清单、判定条件表 | 判定记录 |
| 复用批准人 | 批准复用结论，处理争议 | 判定记录 | 复用批准结论、复用登记 |
评审时点建议与需求评审节奏对齐：新需求进入评审时同步检查是否存在可复用来源，季度或月度集中评审一次复用候选清单。频次过高会增加评审负担，过低则候选积压。出现判定分歧时，升级路径要写清楚：先由领域评审人与需求管理角色协商，协商不成提交复用批准人裁定，裁定结论记录在判定记录中，作为后续类似情形的参考。
在工具层面，需求条目、字段、状态流转和引用关系需要有承载位置。ONES 的需求管理支持为需求设置自定义字段、维护状态流转，并通过关联关系记录需求之间的引用，便于把判定记录和复用登记挂在同一条需求上，减少规则执行时的线下表格维护。
第四步：建立复用登记与引用追溯机制
复用发生后必须登记，否则复用无法查证，源需求变更时也无法找到受影响的复用方。复用登记应记录以下信息：来源需求标识、复用类型（直接、改造、参考）、差异点说明、复用方责任人、登记日期。
| 登记项 | 填写要求 |
|---|---|
| 来源需求 | 填写源需求标识与版本号 |
| 复用类型 | 直接复用、改造复用或参考复用 |
| 差异点 | 逐条列出与源需求不同的内容，直接复用填“无” |
| 复用方责任人 | 对复用内容后续维护负责的角色 |
| 登记日期 | 复用批准当日 |
引用关系的维护原则是：源需求内容变更时，由源需求责任人发起变更通知，通知范围覆盖所有登记在册的复用方；复用方在收到通知后确认差异是否仍然成立，需要调整的在差异点中更新。差异管理的处理原则是差异只增不隐，改造复用产生的差异要持续记录，不能因为后续趋同而删除历史差异，否则追溯链会断裂。登记信息的查阅权限建议对需求管理角色、领域评审人和复用方责任人开放，其他人员按项目权限只读。
示例：一条需求从沉淀到被复用的完整过程
以下为演示情景，用于说明规则如何被执行。某业务系统提出一条需求：“订单导出支持按时间范围筛选，单次导出不超过五万条。”沉淀时填写字段：需求类别为功能需求，适用场景为订单查询与对账，约束条件为依赖订单库只读副本、导出文件格式为 CSV，来源为财务对账项目，版本 V1.0，状态标记为可复用。
三个月后，另一产品线的报表项目提出类似需求。需求管理角色将其列入复用候选清单，领域评审人核对四项准入条件：场景匹配（对账场景一致）、约束兼容（同样具备只读副本，但文件格式要求为 Excel）、版本有效（源需求 V1.0 为当前版本）、责任方确认（源需求责任人确认无冲突）。由于文件格式存在差异，判定为改造复用，判定记录中写明差异点为“导出格式改为 Excel”。
复用批准人批准后完成登记：来源需求为上述订单导出需求 V1.0，复用类型为改造复用，差异点为导出格式，复用方责任人为报表项目需求负责人。两个月后源需求升级到 V1.1，增加导出字段配置项，源需求责任人按登记名单发出变更通知，报表项目确认该变更不影响其 Excel 导出逻辑，在差异点中补充说明后关闭通知。整个过程从候选提出到登记完成约一周，变更通知在源需求发布当日发出。
规则上线后的完成检查与修订节奏
规则是否真正运转，可以用一组可核对的检查项来判断。建议在规则上线一个月后做首次检查，之后按季度复查。
- 字段完整率：抽查标记为可复用的需求，检查必备字段是否齐全，目标可设为不低于九成。
- 判定记录覆盖率：统计发生复用的需求中带有判定记录的比例，未记录的要补录并分析原因。
- 复用登记完整性：核对登记表中的来源需求、复用类型、差异点是否填写完整。
- 变更通知及时性：抽取源需求变更记录，检查通知是否在约定时限内发出、复用方是否确认。
验证指标可以从需求管理工具中取数：可复用需求数量、复用登记数量、复用类型分布、变更通知响应时长。规则复审周期建议为半年一次，出现以下情况时触发临时修订：复用判定争议频繁、字段完整率持续偏低、复用方反馈追溯困难、业务场景发生较大变化。常见失效信号包括标签体系失控、判定记录流于形式、变更通知无人响应，对应的纠偏动作分别是收紧标签准入、把判定记录纳入评审检查项、明确通知责任人与响应时限。规则修订后要同步更新字段表和登记模板，并对相关角色做一次简短说明。
常见问题
复用单元按需求条目、需求族还是能力点定，怎么选？
选择依据是需求边界是否清晰、复用方能否独立理解使用、维护责任能否落到具体角色。多数团队以需求条目为主口径，把需求族作为组织维度而非复用单位；跨产品线共享的通用内容再抽象为能力点。规则里要写明主口径和例外情形，避免同一份需求在不同场景下被按不同颗粒度复用，导致登记和追溯对不上。
源需求变更后，复用方不确认通知怎么办？
把确认动作写进流程并设定时限：源需求责任人发出通知后，复用方需在约定时限内回复差异是否仍然成立，超时未回复的由需求管理角色代为跟进并记录。变更通知的及时性和复用方响应情况都应纳入季度检查项，长期无人响应的登记记录要清理或重新确认责任人，避免登记表变成失效名单。
改造复用产生的差异，后续趋同了可以删掉吗？
建议保留历史差异记录。差异只增不隐，改造复用产生的差异要持续记录，后续内容趋同可以在差异点中补充说明，但不宜删除历史条目，否则追溯链会断裂，后续排查问题时无法还原当时的判定依据。差异记录的价值在于说明“为什么当时这样处理”，而不只是描述当前状态。
规则刚上线，判定记录覆盖率低是正常现象吗？
上线初期偏低可以理解，但要有明确的纠偏动作。首次检查安排在上线一个月后，抽查发生复用的需求是否带有判定记录，未记录的要求补录并分析原因：是流程节点没设检查项，还是角色不清楚自己该记录。把判定记录纳入需求评审的检查项，通常比事后补录更有效。若连续两个季度覆盖率仍偏低，需要修订规则本身，简化记录格式或减少必填项。
小团队也需要这么完整的复用规则吗？
可以按规模裁剪，但四类判定不能省。小团队可先只保留需求条目一种复用单元、直接复用和改造复用两档等级，字段保留需求类别、适用场景、约束条件、版本和状态，角色上由需求管理角色兼任领域评审和批准。裁剪的是表单长度和评审频次，判定条件、登记和变更通知这几项仍要保留，否则复用无法追溯。
