识别需求间依赖，先建立统一的分类和字段口径，再从需求拆分、接口与数据、排期与发布等活动中发现依赖，把每条依赖记录成带方向的可查询关系。变更发生时，沿依赖方向同时做下游影响排查和上游可行性核对，并更新受影响的需求、验证项与交付节点。下面给出一套可直接套用的方法、记录模板和检查清单。
要点总览（TL;DR）
- 先统一依赖分类：实现依赖、验证依赖、数据依赖、交付时序依赖，判定标准是“去掉对方能否独立完成或独立验收”。
- 每条依赖记录源需求、目标需求、方向、类型、强度、触发条件、责任人、验证方式和状态，一条依赖只描述一对需求。
- 依赖从需求拆分与验收标准、接口与数据模型、排期与发布计划、历史缺陷回溯四个动作中识别，每个动作都要有输入、参与角色和输出物。
- 变更时正向排查下游受影响需求与验证项，反向核对上游是否仍成立，影响结论在变更评审中确认后才进入开发。
- 依赖清单作为唯一数据源，关系图和需求条目内双向链接从清单派生，发布基线时对清单做快照归档。
先定依赖分类与记录字段
依赖管理失效，常见原因不是遗漏了某条依赖，而是团队对“什么算依赖”理解不一致：有人把“两个需求由同一人开发”记为依赖，有人只记录接口调用关系。开始识别之前，先用一张判定表统一口径，再用一组最小字段保证记录可查询、可追踪。
四类依赖的定义与判定问题
建议把需求间依赖分为实现依赖、验证依赖、数据依赖、交付时序依赖四类。分类的作用是让识别时有明确的提问方向，而不是把一条依赖强行归入唯一类别——一条依赖可以同时属于两类，此时记录主类型，并在备注中说明。
| 依赖类型 | 定义 | 判定问题 | 典型例子 |
|---|---|---|---|
| 实现依赖 | 一个需求的实现需要另一个需求的产出物（接口、组件、配置、规则）先具备或同步具备 | 如果目标需求不交付，源需求还能独立完成吗？ | 订单查询需求依赖订单创建需求提供的接口 |
| 验证依赖 | 一个需求的验收需要借助另一个需求的产物、环境或测试数据才能完成验证 | 没有目标需求的产出，源需求的验收标准能否被验证？ | 报表导出需求的验收依赖权限需求提供的角色配置 |
| 数据依赖 | 一个需求的处理逻辑或展示结果依赖另一个需求定义、采集或迁移的数据 | 源需求使用的数据由谁定义、由谁生产、口径是否一致？ | 客户画像需求依赖客户主数据清洗需求输出的字段口径 |
| 交付时序依赖 | 两个需求在发布、上线或交付顺序上有先后约束，与实现是否耦合无关 | 两者能否在同一批次发布？顺序颠倒会造成什么后果？ | 数据库结构变更需求必须先于新功能需求上线 |
判定时优先问“去掉对方，我能否独立完成或独立验收”。能独立完成但需要按顺序上线，属于交付时序依赖；无法独立完成，再看缺的是实现物、验证条件还是数据，分别归入前三类。
每条依赖的必填字段
依赖记录的最小字段集如下。字段数量控制在十个左右，既能支撑查询和影响分析，又不至于让填写成为负担。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 依赖编号 | 全局唯一，建议“DEP-项目缩写-序号” | DEP-ORD-012 |
| 源需求 | 依赖方，填写需求编号与标题 | REQ-105 订单列表查询 |
| 目标需求 | 被依赖方，填写需求编号与标题 | REQ-098 订单创建接口 |
| 方向 | 前置/后置，明确谁先谁后 | REQ-105 后置，REQ-098 前置 |
| 类型 | 四类之一，可加次要类型 | 实现依赖 |
| 强度 | 强/弱：强依赖缺失则无法交付，弱依赖缺失可降级或替代 | 强 |
| 触发条件 | 依赖在什么条件下生效，避免把所有潜在关联都记为依赖 | 订单列表需展示创建时间字段时生效 |
| 责任人 | 负责跟进该依赖闭环的人，通常是源需求负责人 | 需求负责人 A |
| 验证方式 | 如何确认依赖已满足 | 接口联调通过并留存记录 |
| 状态 | 待确认/已确认/已满足/已失效 | 已确认 |
填写的最小规则与歧义处理
- 一条依赖只描述一对需求之间的关系。一个需求依赖三个需求，就记三条，便于分别跟踪状态。
- 方向以“谁需要谁”为准，不按开发先后填写。开发顺序与依赖方向不一致时，在触发条件中说明。
- 强度默认填“强”，只有确认存在降级方案时才填“弱”，并写明降级方式。
- 两个需求互相需要对方产出时，记为两条方向相反的依赖，不合并成一条“相互依赖”。
- 需求拆分后产生的子需求依赖父需求范围时，记录在子需求条目上，避免父需求条目堆积大量隐性关联。
识别依赖的四个动作与输入输出
依赖不会自动浮现，需要在几个固定节点主动排查。以下四个动作分别对应不同的材料来源，每个动作都应有明确的输入、参与角色和输出物，完成标志是输出物经过确认而非“大家知道了”。
从需求拆分与验收标准中识别实现与验证依赖
输入是需求文档、拆分后的需求条目和验收标准。做法是逐条阅读验收标准，对每个验收条件追问“满足这个条件需要哪些其他需求的产出”，把答案登记为候选依赖。参与角色为需求负责人和测试角色，输出为候选依赖清单。完成标志是每条验收标准都经过一次依赖提问，且候选依赖已标注类型。
从接口、数据模型与上下游系统中识别数据依赖
输入是接口清单、数据模型或字段字典、上下游系统说明。做法是以需求涉及的数据对象为线索，确认字段由哪个需求定义、由哪个系统生产、口径是否一致，重点排查同一字段在不同需求中被重复定义的情况。参与角色为系统或架构角色、数据负责人，输出为数据依赖条目及字段口径说明。完成标志是需求涉及的每个关键字段都能追溯到定义方。
从迭代排期与发布计划中识别交付时序依赖
输入是迭代计划、发布批次安排和上线检查项。做法是检查同一批次内的需求是否存在结构变更、配置切换、开关顺序等先后约束，以及跨批次交付时下游需求是否会被阻塞。参与角色为项目经理和需求负责人，输出为交付时序依赖条目及建议顺序。完成标志是发布批次内的顺序约束已写入依赖记录，并在排期评审中确认。
识别动作的汇总清单
| 动作 | 输入 | 参与角色 | 输出 | 完成标志 |
|---|---|---|---|---|
| 验收标准排查 | 需求条目、验收标准 | 需求负责人、测试 | 候选依赖清单 | 每条验收标准完成依赖提问 |
| 接口与数据排查 | 接口清单、字段字典、系统说明 | 架构角色、数据负责人 | 数据依赖条目与口径说明 | 关键字段可追溯到定义方 |
| 排期与发布排查 | 迭代计划、发布批次 | 项目经理、需求负责人 | 时序依赖条目与建议顺序 | 顺序约束进入依赖记录并评审 |
| 历史需求回溯 | 已交付需求清单、缺陷记录 | 需求负责人 | 补充依赖条目 | 高频关联需求已建立记录 |
第四个动作容易被忽略：从历史缺陷和返工记录中回溯，常能发现此前未记录的隐性依赖。建议在每个迭代回顾时抽半小时做一次补充。
把依赖记录成可查询的关系
依赖记录的价值在于能被查询和沿方向追踪。建议同时使用依赖清单、关系图和需求条目内链接三种载体：清单用于统计和状态跟踪，关系图用于评审时快速理解链路，条目内链接保证查看单个需求时不会遗漏关联。
依赖清单的列结构与编号规则
清单列与前述字段一一对应，另加“创建时间”“最后更新”“关联变更单”三列，便于追溯。编号规则建议“DEP-项目缩写-三位序号”，序号只增不复用；依赖失效时状态改为“已失效”，保留记录而不是删除，避免历史影响分析断链。
关系图的节点、边与方向标注
节点为需求条目，节点上标注需求编号和状态；边为依赖关系，箭头从源需求指向目标需求，即“谁依赖谁”。边上标注依赖类型缩写和强度，例如“实现·强”。评审时以关系图为主视图，能直观看出哪些需求是链路中的关键节点——被多条边指向的需求一旦延期，影响面最大。
需求条目内双向链接的写法与更新时机
在源需求条目中写“依赖：REQ-098（实现依赖，强）”，同时在目标需求条目中写“被依赖：REQ-105（实现依赖，强）”。双向写法保证从任一端都能看到关系。更新时机包括：依赖状态变化、需求范围调整、需求关闭或拆分。需求关闭前应检查其作为目标需求的依赖是否都已满足或失效。
记录载体之间的同步与版本管理
三种载体容易出现不一致，建议指定清单为唯一数据源，关系图和条目链接从清单派生。每次依赖状态变更先更新清单，再同步条目链接，关系图在评审前统一刷新。发布基线时对依赖清单做一次快照，与需求基线一同归档，后续变更影响分析以基线为参照。
当团队在平台上管理需求时，依赖记录可以依附于需求条目本身。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，其数字线程用于连接需求、开发、测试、变更和发布等环节；依赖关系在平台中建立关联后，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据。具体以何种关联类型记录依赖方向，需按实际配置确认。
角色分工与各环节交付物
依赖管理需要四类角色配合，各自交付不同的产物。分工的核心是：识别由最了解需求内容的人负责，确认由能判断技术可行性的人把关，维护由项目经理保证节奏。
| 角色 | 职责 | 交付物 | 交接方式 |
|---|---|---|---|
| 需求负责人 | 在需求拆分和验收标准编写时识别依赖，填写依赖条目，跟踪状态 | 依赖条目、状态更新记录 | 提交至依赖清单，在需求评审中说明 |
| 系统/架构角色 | 确认实现依赖与数据依赖的技术可行性，核对接口与字段口径 | 技术确认意见、口径说明 | 在依赖确认评审中给出结论 |
| 测试角色 | 识别验证依赖，确认依赖满足后的验证方式 | 验证依赖条目、验证方案 | 纳入测试计划，联调后反馈状态 |
| 项目经理 | 组织依赖确认评审，维护清单与关系图，在排期和发布时检查时序依赖 | 评审记录、依赖清单快照、排期调整建议 | 发布前同步给相关角色 |
依赖确认的时点建议固定在两个位置：需求评审时确认新增依赖的类型与方向，迭代排期前确认依赖状态是否满足交付条件。跨团队依赖还需在双方的项目例会上同步一次，避免单方面记录。
变更时如何沿依赖方向评估影响
需求变更发生后，影响评估要沿两个方向进行：正向找出依赖当前需求的下游，反向核对当前需求依赖的上游是否仍然成立。只做一个方向，容易漏掉下游返工或上游失效。
正向排查：找出下游需求与验证项
以变更需求为目标节点，在依赖清单中筛选“目标需求=当前需求”的所有条目，得到直接下游；再以下游为新的目标节点继续查找，直到没有新的下游为止。对每个下游需求，检查其验收标准、测试用例和交付节点是否受影响，把结论记入影响记录。强依赖的下游默认标记为“受影响”，弱依赖的下游标记为“需评估”。
反向核对：确认上游是否仍成立
筛选“源需求=当前需求”的条目，逐条确认上游需求的产出是否因本次变更而不再满足需要。例如变更调整了字段口径，上游数据清洗需求的输出可能不再匹配，需要同步提出变更或调整触发条件。反向核对还要检查当前需求是否新增了对其他需求的依赖，若有则补充记录。
影响结论的记录与评审确认
影响记录建议包含：变更单号、变更需求、排查方向、受影响需求清单、影响类型（范围/验证/排期）、处理结论（同步变更/调整排期/无需处理）、确认人。影响结论需在变更评审中确认，未确认的条目保持“待确认”状态，不进入开发。
依赖状态与关闭规则
- 依赖满足后状态改为“已满足”，并记录验证方式与验证时间。
- 需求范围调整导致依赖不再成立时，状态改为“已失效”，注明原因，保留记录。
- 需求关闭前，其作为目标需求的依赖必须全部为“已满足”或“已失效”。
- 变更评审后新增的依赖，需在下一个排期节点前完成确认。
在平台上，这一过程可以借助需求与任务、测试、发布之间的关联关系完成。ONES 方案中的数字线程贯通需求、开发、测试、变更与发布，需求变化时可沿关联关系分析受影响的任务、测试和交付内容；测试用例、缺陷、版本和发布过程关联到需求链路后，出现问题时便于定位影响范围。影响分析的具体操作路径与输出形式，以实际项目配置为准。
一个完整示例：从识别到变更影响
以下为演示情景，用于说明方法如何落地，不代表真实项目数据。
某团队规划“会员积分”功能，拆分为三个需求：REQ-201 积分规则配置、REQ-202 积分明细查询、REQ-203 积分兑换下单。验收标准编写阶段，需求负责人发现 REQ-202 的明细展示需要 REQ-201 定义的积分类型字段，REQ-203 下单时需要读取 REQ-202 的可用积分余额，于是登记两条实现依赖。测试角色补充：REQ-203 的兑换失败场景验证需要 REQ-201 的规则配置环境，登记一条验证依赖。项目经理在排期时确认 REQ-201 必须先于 REQ-202 上线，登记一条交付时序依赖。
| 依赖编号 | 源需求 | 目标需求 | 类型 | 强度 | 验证方式 | 状态 |
|---|---|---|---|---|---|---|
| DEP-MB-001 | REQ-202 | REQ-201 | 实现依赖 | 强 | 字段口径核对通过 | 已确认 |
| DEP-MB-002 | REQ-203 | REQ-202 | 实现依赖 | 强 | 余额接口联调通过 | 已确认 |
| DEP-MB-003 | REQ-203 | REQ-201 | 验证依赖 | 弱 | 规则配置环境可用 | 已确认 |
| DEP-MB-004 | REQ-202 | REQ-201 | 交付时序依赖 | 强 | 发布批次顺序核对 | 已确认 |
迭代中期，REQ-201 变更：积分类型由固定枚举改为可配置字典。正向排查发现 REQ-202 的明细展示和 REQ-203 的兑换校验都依赖该字段，标记为受影响；反向核对确认 REQ-201 本身无上游依赖。影响记录中登记两条受影响需求，处理结论为同步调整字段映射并补充测试用例，在变更评审中确认。更新后 DEP-MB-001 的验证方式改为“字典映射核对通过”，DEP-MB-002 增加一条兑换校验用例，DEP-MB-004 的发布顺序保持不变。变更完成后，三条依赖状态重新确认，影响记录归档到该变更单下。
完成检查：依赖记录是否可用
依赖记录是否做到位，可以用以下清单逐项核对。建议在需求评审和发布前各执行一次。
- 分类与字段完整性：每条依赖都有类型、方向、强度、触发条件、责任人、验证方式和状态，无空字段；类型判定能回答“去掉对方能否独立完成或验收”。
- 方向与双向一致性：源需求与目标需求的条目内链接互相指向；清单中的方向与关系图箭头一致；不存在只在一端记录的依赖。
- 覆盖检查：每条验收标准都经过依赖提问；需求涉及的关键字段都能追溯到定义方；发布批次内的顺序约束已记录。
- 变更后更新及时性：变更评审后一个工作日内完成影响记录更新；受影响需求的状态、验证方式和排期已同步调整。
- 关闭规则执行：已关闭需求不存在“待确认”状态的依赖；失效依赖保留记录并注明原因。
阻断项包括：强依赖未确认即进入开发、变更后下游需求未评估、依赖记录与需求条目不一致。出现任一阻断项时，应在排期或发布前解决，再进入下一环节。团队规模较大或跨团队协作较多时，可适当增加依赖确认评审的频次；小团队可将确认合并到需求评审中完成，关键是保持记录与需求状态同步。
常见问题
两个需求由同一个人开发，或者排在同一个迭代里，算不算依赖？
这类关联通常不构成依赖。判断标准是“去掉对方，当前需求能否独立完成或独立验收”。同一负责人、同一迭代属于资源或排期上的关联，可以在排期中协调，不必登记为依赖条目。只有当一方缺少另一方的产出物、验证条件、数据口径或上线顺序就无法推进时，才记为依赖。把资源关联也记成依赖，会让清单膨胀，真正需要跟踪的强依赖反而被淹没。
依赖关系记录在需求条目里就够了，还需要单独维护依赖清单吗？
两者承担不同用途。需求条目内的双向链接方便查看单个需求时了解上下游，但无法快速回答“本迭代有哪些依赖未满足”“哪个需求被最多需求依赖”这类跨需求问题。依赖清单支持筛选、统计和状态跟踪，关系图适合评审时看链路。建议指定清单为唯一数据源，条目链接和关系图从清单派生，避免三处各记一套导致不一致。
跨团队的需求依赖，双方记录不一致怎么办？
先约定由源需求方（依赖方）负责登记条目，目标需求方确认后在己方条目中补充“被依赖”链接。跨团队依赖建议在双方项目例会上同步一次状态，确认人写进依赖记录。出现一方已标记“已满足”、另一方仍显示“待确认”时，以验证方式和验证时间为准核对，确认后统一更新。依赖编号全局唯一，可以避免同一关系被重复登记成两条。
需求变更后，影响排查要做到什么程度才算完成？
正向排查要沿依赖链一直找到没有新下游为止，每个直接下游标注“受影响”或“需评估”；反向核对要确认当前需求依赖的上游是否仍满足需要，并检查是否新增了依赖。影响记录需包含变更单号、受影响需求清单、影响类型和处理结论，并在变更评审中确认。未确认的条目保持“待确认”状态，不进入开发。变更评审后一个工作日内完成记录更新，是较常见的节奏要求。
依赖已经失效或需求已关闭，记录要不要删掉？
建议保留记录，把状态改为“已失效”并注明原因。删除会让历史影响分析断链，后续回溯变更时无法还原当时的依赖关系。需求关闭前应检查其作为目标需求的依赖是否全部为“已满足”或“已失效”，存在“待确认”条目的需求不宜直接关闭。发布基线时对依赖清单做快照归档，后续变更影响分析以基线为参照。
