需求关联图把一条需求与它的来源、拆分项、实现任务、代码或配置变更、验证用例连成一条可读的链路，让评审者顺着连线就能看清“这条需求从哪来、由谁实现、用什么验证”。本文以虚构的“订单支持部分退款”需求为示例，给出一份填写完整的关联图，逐项说明节点、连线和字段的填写理由，并提炼换一条需求时可直接套用的画法与自查点。示例情景仅作画法演示，不代表任何真实项目数据。
要点总览（TL;DR）
- 需求关联图以一条需求为起点，沿来源、拆分、实现、变更、验证的顺序组织节点，连线统一由上游指向下游，顺读看实现路径，逆查看影响范围。
- 示例以虚构的“订单支持部分退款”需求演示：拆出两条子需求，分别挂接实现任务、变更对象和验证用例，形成两条闭合链路。
- 填写要点是节点字段保留编号、名称、类型、责任人、状态、关联依据六项，用例连到子需求而非实现任务，编号用类型前缀区分。
- 换一条需求时先定来源与验收用例两端，再补拆分与实现节点，最后按“有需求无任务、有任务无用例、有变更未回写”三类断点自查。
- 测试充分性与覆盖率评估、跨生命周期治理不放进关联图，分别归测试覆盖与需求验证、ALM 应用生命周期管理处理。
示例要解决什么：从需求看实现与验证链路
这张示例图要回答一个具体问题：给定“订单支持部分退款”这一条需求，能否沿着图上的连线，找到它的来源依据、拆分出的子需求、承接的实现任务、实际改动的代码或配置对象，以及验证它的测试用例。如果这五类信息都能在图上一一对应，且方向清楚、字段可读，这张图就达到了示例目标。
判断一张需求关联图是否合格，可以用下面四条标准核对：
- 链路完整：从需求出发，向下能走到实现与验证，向上能回到来源；中间不出现断点，即不存在“有需求无任务”“有任务无用例”的孤立节点。
- 方向清晰：所有连线统一为上游指向下游，读图时从左到右、从上到下即可顺读，逆查时沿箭头反向回溯。
- 字段可读：每个节点至少带编号、名称、类型、责任人、状态五项信息，读者不打开其他系统也能判断节点性质与当前进展。
- 关系有依据：每条连线都能说清“为什么连”，例如子需求因拆分规则产生、用例因覆盖某条验收条件而挂接。
需要说明的是，本文示例中的订单系统、需求编号、人员角色和用例均为虚构设定，用于演示节点类型与填写方式。读者迁移到自己项目时，应替换为真实对象，并沿用相同的结构逻辑。
完整示例：订单部分退款需求的关联图
下面给出示例的完整内容，分三部分呈现：节点清单及字段值、连线清单及关系类型、按图读出的一条完整链路。读者可以照此结构在自己的文档或工具中搭建。
节点清单与字段示例值
| 节点编号 | 节点名称 | 节点类型 | 责任人 | 状态 | 关联依据 |
|---|---|---|---|---|---|
| REQ-101 | 订单支持部分退款 | 需求 | 产品经理 李某 | 已评审 | 来源：客服退款工单汇总（示例） |
| REQ-101-1 | 支持按商品行选择退款数量 | 子需求 | 产品经理 李某 | 已评审 | 由 REQ-101 按功能点拆分 |
| REQ-101-2 | 部分退款金额按实付比例计算 | 子需求 | 产品经理 李某 | 已评审 | 由 REQ-101 按计算规则拆分 |
| TASK-201 | 退款选择页开发 | 实现任务 | 开发 王某 | 开发中 | 承接 REQ-101-1 |
| TASK-202 | 退款金额计算服务改造 | 实现任务 | 开发 赵某 | 待开发 | 承接 REQ-101-2 |
| CHG-301 | refund-service 金额计算模块 | 变更对象 | 开发 赵某 | 待提交 | 由 TASK-202 改动 |
| TC-401 | 按商品行部分退款流程用例 | 验证用例 | 测试 陈某 | 待执行 | 覆盖 REQ-101-1 验收条件 |
| TC-402 | 部分退款金额计算用例 | 验证用例 | 测试 陈某 | 待执行 | 覆盖 REQ-101-2 验收条件 |
连线清单与关系类型
| 起点 | 终点 | 关系类型 | 连线含义 |
|---|---|---|---|
| 来源工单汇总 | REQ-101 | 来源于 | 需求由客服反馈归纳而来 |
| REQ-101 | REQ-101-1 | 拆分为 | 按功能点拆分 |
| REQ-101 | REQ-101-2 | 拆分为 | 按计算规则拆分 |
| REQ-101-1 | TASK-201 | 由任务实现 | 开发任务承接子需求 |
| REQ-101-2 | TASK-202 | 由任务实现 | 开发任务承接子需求 |
| TASK-202 | CHG-301 | 改动 | 任务落地为具体代码模块变更 |
| REQ-101-1 | TC-401 | 由用例验证 | 用例覆盖该子需求验收条件 |
| REQ-101-2 | TC-402 | 由用例验证 | 用例覆盖该子需求验收条件 |
按图读出的一条完整链路
从 REQ-101 出发，沿“拆分为”连线到达 REQ-101-2“部分退款金额按实付比例计算”；再沿“由任务实现”到达 TASK-202“退款金额计算服务改造”；继续沿“改动”到达 CHG-301“refund-service 金额计算模块”；最后从 REQ-101-2 沿“由用例验证”到达 TC-402“部分退款金额计算用例”。这条链路说明：该子需求有明确的实现任务、有对应的代码变更对象、有覆盖其验收条件的测试用例，三段信息闭合。同理，REQ-101-1 经 TASK-201 与 TC-401 形成另一条闭合链路。
逐项解释：节点、连线和字段为什么这样填
示例中的每个选择都对应一条填写理由，理解这些理由比记住具体编号更重要。
需求与子需求的拆分依据
REQ-101 被拆成两条子需求，依据是“可独立实现、可独立验证”。REQ-101-1 涉及交互与流程，REQ-101-2 涉及金额计算规则，两者由不同开发承接、由不同用例验证，因此拆开后在图上能各自形成闭合链路。如果一条需求只有一个实现任务和一个用例，就不必强行拆分，直接挂接即可。拆分粒度的判断标准是：拆分后每个子需求都能单独回答“谁实现、怎么验”。
实现任务与变更对象的挂接方式
实现任务挂在子需求之下，表示“这个任务是为了完成这条子需求”。变更对象挂在实现任务之下，表示“这个任务实际改动了哪个代码模块或配置”。示例中 TASK-202 挂 CHG-301，是因为金额计算改造落在 refund-service 的金额计算模块；TASK-201 未挂变更对象，是因为示例设定其改动尚未提交，这正好演示了“有任务暂无变更对象”这一中间状态的读法——它不是错误，而是提示该段链路尚未闭合，需要在提交后补挂。
验证用例与需求的对应关系
示例把用例直接连到子需求，而非连到实现任务。原因是验证的对象是需求所描述的验收条件，实现任务只是达成手段；用例连需求，才能在实现方式调整时保持验证关系稳定。TC-401 对应 REQ-101-1 的“可选择退款数量”验收条件，TC-402 对应 REQ-101-2 的“按实付比例计算”验收条件，一一对应，便于逆查“这条需求被哪些用例验证”。
字段取值与命名约定
示例采用“类型前缀-序号”的编号规则：REQ 表示需求，TASK 表示实现任务，CHG 表示变更对象，TC 表示验证用例。前缀让读者不看类型字段也能识别节点性质；序号在同一项目内连续，便于引用。状态字段使用统一词表（如已评审、开发中、待开发、待提交、待执行），避免“进行中”“处理中”混用导致读图歧义。关联依据字段写清连线原因，是这张图能被他人复核的关键。
当这套关联关系需要在团队日常协作中持续维护时，可以把它承载在统一的工作项与文档体系中。ONES 的 ALM 研发管理方案以数字线程贯通需求、开发、测试、变更与发布，支撑影响分析与过程追溯；在需求基线场景下，围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析与交付结果回溯；测试发布场景则把测试用例、缺陷、版本和发布过程关联到需求链路中，便于在出现问题时定位影响范围。示例中的需求、子需求、任务、变更对象与用例，可以分别作为工作项记录，连线关系以关联字段或关系视图表达，使图上的链路与团队实际执行状态保持同步。
可迁移规律：换一条需求怎么画
把示例抽象成步骤，换任何一条需求都能照着画。核心思路是先确定链路的两端，再补齐中间节点，最后逐段检查缺口。
画图步骤
- 定上游端：写清需求的来源，是客户反馈、业务目标还是合规要求，用一个来源节点或来源字段固定下来。
- 定下游端：先列出这条需求的验收条件，再为每条验收条件找到对应的验证用例，形成链路终点。
- 补拆分节点：按“可独立实现、可独立验证”判断是否需要拆子需求，拆出的每条子需求单独成节点。
- 补实现节点：为每条子需求挂接实现任务，任务下再挂实际改动的代码模块、配置或接口等变更对象。
- 连验证节点：把用例连到它所覆盖的子需求，而不是连到任务，保持验证关系与实现方式解耦。
- 填字段：为每个节点补齐编号、名称、类型、责任人、状态、关联依据，统一编号前缀与状态词表。
关系类型的最小集合
示例只用了四类关系：来源于、拆分为、由任务实现、由用例验证，外加任务到变更对象的“改动”。这五类关系足以表达从需求到实现与验证的主干。关系类型不宜随意扩张，新增类型前先确认现有类型无法表达，否则图会因关系语义混乱而难以阅读。
覆盖缺口的识别方法
沿链路逐段检查三类断点：有需求或子需求但没有实现任务，说明实现尚未安排；有实现任务但没有验证用例，说明验证尚未设计；有变更发生但关联未回写，说明图与实际脱节。示例中 TASK-201 暂无变更对象，就是第三类断点的演示。每次评审前按这三类逐条核对，缺口即可定位。
维护与更新时机
需求关联图在四个时点需要更新：需求评审通过后补全拆分与任务挂接；开发提交变更后补挂变更对象；用例设计完成后建立验证连线；需求变更或范围调整时，同步检查受影响的子需求、任务与用例，避免旧连线残留。把更新动作绑定在这些既有节点上，比定期集中整理更不容易遗漏。
适用边界：哪些内容不放进需求关联图
需求关联图回答的是“这条需求连到了哪些对象”，它是一张关系图，不是评估报告，也不是治理台账。划清边界能让图保持可读，也避免把不同性质的工作塞进同一张图。
测试充分性与覆盖率评估不放进图里。图能显示某条需求挂了几个用例，但“这些用例是否足以覆盖风险”“覆盖率是否达标”属于测试覆盖与需求验证的评估范畴，需要结合风险等级、用例设计方法和执行结果单独分析。把覆盖率指标画进关联图，会让图承担它不擅长的判断任务。
跨生命周期治理不放进图里。需求从提出到退役的阶段划分、基线策略、变更审批流程等属于 ALM 应用生命周期管理的治理内容。关联图可以引用某个基线或版本作为节点属性，但治理规则本身应在流程与制度文档中定义，不在图上展开。
图要与文档、看板配合使用。关联图适合表达对象之间的追溯关系；需求说明、验收条件等细节放在需求文档中，任务进度与排期放在看板或计划视图中。图上的节点通过编号指向这些载体，读者按需跳转查看，而不是把所有信息压缩进一张图。这样分工后，关联图保持结构清晰，文档与看板各自承载其擅长的内容。
常见问题
需求关联图里的用例应该连到需求还是连到实现任务？
建议连到需求或子需求。验证的对象是需求所描述的验收条件，实现任务只是达成手段；用例连需求，实现方式调整时验证关系仍然成立，也便于逆查“这条需求被哪些用例验证”。如果团队习惯把用例挂在任务上，至少要在需求侧保留一条可追溯的关联，避免需求变更后验证关系断掉。
一条需求只对应一个开发任务时，还需要拆子需求吗？
不必强行拆分。拆分的判断标准是“可独立实现、可独立验证”：如果一条需求只有一个实现任务、一组用例，直接挂接即可，多拆一层反而增加维护成本。当需求包含交互流程、计算规则等由不同人承接、用不同用例验证的部分时，再按功能点拆开，让每条子需求都能单独回答“谁实现、怎么验”。
图上有任务但暂时没有变更对象，算不算画错了？
不算错误，属于链路尚未闭合的中间状态。示例中 TASK-201 未挂变更对象，就是演示这种情形：任务已安排、代码尚未提交。读图时把它当作待补项，在开发提交后回写变更对象即可。真正需要警惕的是长期停留在这一状态且无人跟进，那说明图与实际执行已经脱节。
需求关联图和需求文档、看板怎么分工？
关联图只表达对象之间的追溯关系；需求说明、验收条件等细节放在需求文档中，任务进度与排期放在看板或计划视图里。图上的节点通过编号指向这些载体，读者按需跳转。这样分工后，图保持结构清晰，文档承载细节，看板承载执行状态，三者各司其职，不需要把所有信息压缩进一张图。
关联图多久维护一次比较合适？
按节点事件更新比定期集中整理更可靠。需求评审通过后补全拆分与任务挂接；开发提交变更后补挂变更对象；用例设计完成后建立验证连线；需求变更或范围调整时，同步检查受影响的子需求、任务与用例，清理旧连线。把更新动作绑定在这些既有节点上，遗漏会明显减少。
