需求复用规则要解决的问题很具体：一条新需求和历史需求高度相似时，团队该不该复用、复用哪些内容、复用后怎么留下记录。本文用一条演示需求走完判定、改写、登记的全过程，并从中提炼可迁移到团队的规则清单。文中情景为示例设定，用于说明填写方式，非真实客户案例。
要点总览（TL;DR）
- 需求复用规则要回答三件事：什么内容值得复用、复用时保留哪些字段、复用后如何登记来源与差异。
- 示例以“订单批量导入失败提示”为原型，演示从原始需求、复用判定、字段改写，到来源登记与差异说明的完整填写过程。
- 判定复用看三个维度：业务目标与核心交互的相似度、内容可抽象程度、场景差异带来的改写成本；任一维度明显不成立时，转为新写需求。
- 标题、范围、验收要点必须逐字段核对并改写，背景与业务动机可沿用；差异说明按“变化点 + 影响范围”书写。
- 来源需求、差异说明、复用标记三类信息建议保留，它们是复用记录可追溯、可评审的基础。
示例目标：这份需求复用范例要演示什么
示例设定如下：某团队的需求库中已有一条两年前交付的历史需求“订单批量导入失败提示”，当时只覆盖网页端、单一批量上限和固定错误文案。现在业务方提出一条新需求“批量导入失败提示优化”，要求覆盖网页端与移动端、支持更大的批量上限，并允许按错误类型分组展示。两条需求在业务目标、触发场景和核心交互上高度相似，差异集中在终端范围、容量约束和提示呈现方式。
这份范例要演示三件事：
- 复用判定：依据什么判断新需求可以复用历史需求，而不是重新写一条。
- 字段改写：复用后哪些字段原样保留、哪些必须按新场景改写，改写后的条目长什么样。
- 登记关联：复用条目如何记录来源需求、差异说明和责任人，使后续追溯有据可查。
需要说明的是，示例中的团队、需求编号、字段取值均为演示设定，用于展示一份完整复用记录应包含的内容，读者可对照自己团队的需求模板调整字段名称与颗粒度。
完整示例：一条需求从判定到复用的填写全过程
原始需求条目（历史需求，编号 REQ-0412）
| 字段 | 内容 |
|---|---|
| 需求标题 | 订单批量导入失败提示 |
| 背景 | 运营人员通过 Excel 批量导入订单时，导入失败仅返回“导入失败”提示，无法定位具体行与原因，需人工逐行排查。 |
| 目标 | 导入失败时向用户展示失败行号与失败原因，减少人工排查时间。 |
| 范围 | 网页端；单次导入不超过 500 行；错误提示以列表形式展示。 |
| 验收要点 | 1. 导入失败后展示失败行号；2. 每行给出失败原因分类；3. 提示区域可复制；4. 全部成功时不展示失败提示。 |
| 来源 | 运营团队反馈 |
| 状态 | 已交付 |
复用判定记录
| 判定项 | 记录内容 |
|---|---|
| 相似度判断 | 业务目标一致（帮助用户定位导入失败原因），触发场景一致（批量导入失败），核心交互一致（失败后展示明细）。判定为高相似。 |
| 可抽象程度 | “失败行号 + 失败原因分类 + 可复制提示”属于可抽象为通用导入反馈模式的内容，适合复用。 |
| 场景差异 | 新增移动端；批量上限提升；提示需按错误类型分组。差异影响范围字段、验收要点和部分交互细节。 |
| 判定结论 | 准予复用，以 REQ-0412 为来源需求，改写范围、验收要点与提示呈现方式，其余字段沿用。 |
| 判定人 / 日期 | 需求负责人 / 示例日期 |
复用后的需求条目（新需求，编号 REQ-0785）
| 字段 | 复用后内容 | 处理方式 |
|---|---|---|
| 需求标题 | 批量导入失败提示优化（网页端与移动端） | 改写，补充终端范围 |
| 背景 | 沿用历史背景，补充移动端导入场景与更大批量下的排查压力。 | 沿用并补充 |
| 目标 | 导入失败时展示失败行号与按类型分组的失败原因，覆盖网页端与移动端。 | 改写，增加分组与终端要求 |
| 范围 | 网页端与移动端；单次导入上限按新容量要求执行；提示按错误类型分组展示。 | 改写 |
| 验收要点 | 1. 两端均展示失败行号；2. 失败原因按类型分组；3. 提示区域可复制；4. 全部成功时不展示失败提示；5. 移动端提示布局适配小屏。 | 沿用并新增 |
| 来源需求 | REQ-0412 | 新增登记 |
| 差异说明 | 新增移动端适配、批量上限调整、错误原因分组展示；核心交互与历史需求一致。 | 新增登记 |
| 复用标记 | 是 | 新增登记 |
| 责任人 | 需求负责人（示例） | 新增登记 |
来源登记与差异说明
复用条目在“来源需求”字段指向 REQ-0412，并在“差异说明”中列出三项变化：终端范围扩展、容量约束调整、提示呈现方式变化。这样做的目的是让后续评审、开发和测试人员能快速判断哪些内容可以直接参考历史实现，哪些需要重新设计。差异说明按“变化点 + 影响范围”的格式书写，避免只写“有调整”这类无法核对的描述。
逐项解释：每个字段为什么这样填
复用判定依据：相似度、可抽象程度、场景差异
判定复用需要同时看三个维度。相似度回答“两条需求是不是在解决同一类问题”，本例中业务目标、触发场景、核心交互三项一致，构成复用的基础。可抽象程度回答“历史需求中有多少内容能脱离原场景继续成立”，失败行号、原因分类、可复制提示属于通用反馈模式，可以迁移；而“单次不超过 500 行”这类具体约束则依附于原场景。场景差异回答“复用后需要改多少”，差异越大，改写成本越高，复用的收益越需要重新评估。三个维度中任一维度明显不成立时，应转为新写需求而非勉强复用。
哪些字段原样保留、哪些必须改写
判断标准是字段内容是否依赖原需求的特定条件。背景与目标中的业务动机可以沿用，因为它们描述的是同一类用户问题；标题、范围、验收要点必须改写，因为它们直接承载终端、容量和交互差异。一个实用的检查方法是逐字段问一句：“这个字段的表述在新场景下是否仍然准确？”答案是否定的字段就进入改写清单。本例中范围字段从“网页端、500 行”改为“网页端与移动端、按新容量要求执行”，验收要点在原有四条后新增移动端布局一条，都属于这一原则的应用。
来源与差异登记的作用
来源登记解决“这条需求从哪来”的追溯问题，差异说明解决“改了什么”的核对问题。两者结合，评审时可以对照历史需求判断改写是否充分，开发时可以定位可参考的实现，测试时可以复用历史用例并补充差异部分。缺少登记时，复用条目会逐渐与来源脱节，后续维护者无法判断哪些内容是继承的、哪些是新加的，复用反而增加理解成本。
验收要点复用时如何调整
验收要点的调整遵循“保留仍然成立的、删除已失效的、新增差异对应的”三步。本例保留了失败行号、原因分类、可复制、成功不提示四条，新增移动端布局一条；如果原需求中有依赖旧容量上限的验收项，则应删除或改写。每条验收要点应保持可验证，写明观察对象和预期结果，避免写成“体验良好”这类无法判定的表述。
当复用条目数量增多，来源关联、差异说明和状态流转需要有承载的地方。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯，复用条目与来源需求的关联可以放在这条链路上管理；ONES 方案也将标准流程、评审节点、交付物模板和研发过程数据沉淀为可复用资产，使复用规则不只停留在文档里，而能进入实际项目的执行流程。具体字段配置与操作方式以团队实际方案为准。
可迁移规律：把这份示例变成团队规则
从上面的示例可以提炼出一组规则条目，团队可直接改写后纳入需求管理规范：
| 规则类别 | 规则条目 |
|---|---|
| 复用准入条件 | 业务目标、触发场景、核心交互三项一致方可进入复用评估；可抽象内容占比明显偏低，或场景差异导致大部分字段需改写时，转为新写需求。 |
| 必填字段与改写要求 | 复用条目必须填写来源需求、差异说明、复用标记；标题、范围、验收要点逐字段核对是否仍准确，不准确的必须改写；差异说明按“变化点 + 影响范围”书写。 |
| 登记与关联动作 | 复用条目创建时即关联来源需求，差异说明与条目同步提交评审，不做事后补录。 |
| 评审与维护责任 | 需求负责人负责判定与登记，评审人对相似度判断和差异完整性负责；来源需求发生变更时，检查关联的复用条目是否需要同步调整。 |
规则落地时建议先在小范围试用：选取一批已交付的历史需求作为复用来源池，按上述条目试填若干条新需求，观察判定分歧集中在哪个维度，再调整规则表述。规则条目宜少而明确，每条都能对应到具体字段或动作，便于评审时逐条核对。
适用边界：哪些情况不该套用这份示例
这份示例适用于需求内容层面的复用，即新需求与历史需求在业务目标和核心交互上高度相似、差异集中在范围与呈现细节的情形。以下情况不宜直接套用：
- 需求内容差异过大：业务目标或核心交互已经改变时，历史需求只能作为参考背景，按新需求完整编写，避免用复用标记掩盖实质差异。
- 待处理需求集合的归口：需求池的收集、优先级排序与准入管理属于需求池管理范畴，本文不展开；复用规则只处理“已确定要做的需求如何复用历史内容”。
- 产品线能力布局：跨产品线的能力规划与布局属于产品线管理范畴，不在本文范围；复用判定不替代能力规划决策。
- 规则需要随业务变化维护：终端形态、容量约束、交互规范变化后，复用准入条件和改写要求应同步修订，建议设定固定的复查周期，避免规则与实际脱节。
把示例当作填写模板使用时，字段名称和颗粒度可按团队现有需求模板调整，但来源登记、差异说明、复用标记这三类信息建议保留，它们是复用记录能够被追溯和评审的基础。
常见问题
复用判定时，相似度、可抽象程度、场景差异三个维度出现分歧怎么办？
分歧通常集中在“可抽象程度”上：有人认为失败行号、原因分类这类内容可以通用，有人认为它们依附于原导入场景。处理办法是把分歧落到字段上——逐字段判断“这条表述在新场景下是否仍然准确”，能沿用的字段越多，可抽象程度越高。若大部分字段需要改写，说明复用收益有限，转为新写需求更稳妥。判定结论和分歧点一并记入判定记录，便于后续复盘规则是否过严或过松。
复用条目创建后，来源需求发生变更，关联的复用条目要跟着改吗？
需要检查，但不一定全部改写。来源需求变更后，先判断变更是否影响复用条目已沿用的内容：如果改的是原场景特有的约束（如旧的批量上限），复用条目通常不受影响；如果改的是核心交互或验收口径，则要同步核对复用条目的对应字段。建议在规则中写明由需求负责人触发检查，并在差异说明中补充本次同步调整的记录，避免复用条目与来源需求逐渐脱节。
团队刚开始推行复用规则，怎样判断规则是否合适？
可以先小范围试用：选一批已交付的历史需求作为复用来源池，按规则试填若干条新需求，观察判定分歧集中在哪个维度、差异说明是否写得出来、评审时能否逐条核对。试用一轮后，把反复出现分歧的条目改得更具体，把从未用到的条目删掉。规则条目宜少而明确，每条都能对应到具体字段或动作，比写一份大而全的规范更容易执行。
复用条目在工具中登记时，哪些信息必须结构化保存？
至少三类：来源需求（指向哪条历史需求）、差异说明（改了什么、影响哪些范围）、复用标记（是否为复用条目）。这三类信息决定了后续能否追溯和评审。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析与交付结果回溯，复用条目与来源需求的关联可以放在这条链路上管理；具体字段配置以团队实际方案为准。
需求内容差异较大时，能否保留复用标记作为参考？
可以保留参考关系，但不宜标记为复用。复用标记意味着条目主体内容继承自历史需求，若业务目标或核心交互已经改变，标记为复用会误导评审和开发人员，让他们以为可以直接参考历史实现。更合适的做法是按新需求完整编写，在背景或关联信息中注明参考了哪条历史需求，把参考关系与复用关系区分开。
