需求关联规则要解决的问题，是让每条需求都能沿着一条可核对的链路走到实现与验证。本文用一个假设的“订单超时自动取消”需求作为示例情景，完整演示需求条目、关联类型、关联对象和必填字段的填写结果，再逐项解释每条规则的设置依据，最后提炼可迁移到其他团队的规律与适用边界。示例为演示情景，不代表任何真实客户案例或实施效果。
要点总览（TL;DR）
- 需求关联规则的目标是让每条需求都能沿链路走到实现与验证，判定标准是来源可查、实现可定位、验证可核对。
- 示例需求“订单超时自动取消”向上关联业务需求文档，向下关联两条开发任务、两条代码提交和四条测试用例，另有一条依赖关系。
- 关联类型区分来源、实现、验证、依赖四类，方向统一从需求指向对象，必填项围绕核对目的设置，代码提交可设为建议填写。
- 迁移时先定关联类型再定必填字段，按需求层级决定关联粒度，在评审、开发启动、提测三个节点核对关联完整性。
- 示例只覆盖从需求看实现与验证链路，测试充分性评估和跨生命周期治理不在其中，规则需按团队流程调整。
示例要解决什么问题：需求关联规则的目标
需求关联规则的目标可以归纳为三项：来源可查、实现可定位、验证可核对。来源可查，指需求条目能向上追溯到提出方、业务目标或上游文档；实现可定位，指从需求能向下找到承接它的任务与代码提交；验证可核对，指从需求能向下找到验证它的测试用例，并确认验收要点被覆盖。三项合起来，构成一条从需求出发、双向可走的追溯链。
本示例的判定标准很直接：任取一条需求，都能沿关联链走到至少一个实现对象和一个验证对象，且链路上的关联类型、方向清晰，不依赖口头说明也能读懂。达到这个状态，就说明关联规则填写合格；如果某条需求只能看到实现任务却找不到验证用例，或者关联方向混乱、无法判断谁依赖谁，则视为链路不完整，需要补齐或修正。
需要说明的是，本文关注的是“关联关系怎么填、为什么这样填”，不评估测试是否充分、覆盖率是否达标，也不讨论跨生命周期的治理问题。这些内容属于相邻主题，后文适用边界部分会进一步说明。
完整示例：一条需求的关联规则填写结果
示例需求为“订单超时自动取消”：订单创建后超过设定时长未支付，系统自动取消订单并释放库存。下面先给出需求条目的字段填写，再给出向下关联的实现与验证结果。
需求条目字段填写
| 字段 | 填写结果 | 说明 |
|---|---|---|
| 需求编号 | REQ-ORDER-012 | 唯一标识，便于在关联对象中引用 |
| 需求名称 | 订单超时自动取消 | 一句话说明需求做什么 |
| 来源 | 业务需求文档 BRD-ORDER-03；提出方：交易产品组 | 向上关联来源，保证可追溯 |
| 优先级 | 高 | 影响交易履约，优先排期 |
| 验收要点 | 1. 超时阈值可配置；2. 取消后订单状态变为“已取消”；3. 库存同步释放；4. 取消动作记录操作日志 | 每条要点后续对应验证用例 |
向下关联实现与验证
| 关联类型 | 方向 | 关联对象 | 是否必填 |
|---|---|---|---|
| 来源 | 需求 → 上游文档 | BRD-ORDER-03 | 是 |
| 实现 | 需求 → 开发任务 | TASK-ORDER-045（超时判定与取消逻辑）、TASK-ORDER-046（库存释放） | 是，至少一条 |
| 实现 | 需求 → 代码提交 | commit a1b2c3（取消逻辑）、commit d4e5f6（库存释放） | 建议填写 |
| 验证 | 需求 → 测试用例 | TC-ORDER-101（阈值配置生效）、TC-ORDER-102（状态变更正确）、TC-ORDER-103（库存释放）、TC-ORDER-104（日志记录） | 是，至少一条 |
| 依赖 | 需求 → 关联需求 | REQ-ORDER-008（库存扣减规则） | 按需填写 |
这张表就是一条需求填写完成后的样子：向上有来源，向下有两条实现任务、两条代码提交、四条验证用例，另有一条依赖关系指向库存扣减规则。四条验收要点分别对应四条测试用例，链路闭合，可以逐项核对。
逐项解释：每条关联规则为什么这样填
关联类型区分来源、实现、验证、依赖四类，原因是它们回答的问题不同。来源回答“这条需求为什么存在”，实现回答“谁在做、做到哪一步”，验证回答“怎么证明做对了”，依赖回答“它还受谁影响”。四类混在一起，追溯时就无法快速判断某条关联是证明还是约束。分开设置后，核对链路时按类型逐段检查即可。
关联方向统一从需求指向对象，是为了让追溯链有稳定的起点。需求是链路的锚点，任务、提交、用例都挂在需求之下；如果允许反向随意挂接，同一对象可能被多条需求重复引用而难以判断归属。方向固定后，从需求出发能一次看全下游，从对象反查也能回到唯一需求。
必填字段的约束作用在于保证链路不断。示例中“来源”必填，避免需求凭空出现；“实现”至少一条，避免需求无人承接；“验证”至少一条，避免需求做完没有核对依据。代码提交设为建议填写而非强制，是因为部分团队在任务层面已能定位改动，强制到提交粒度会增加录入负担。必填项应服务于核对目的，字段越多不等于规则越好。
验收要点与验证用例的对应关系，是这条链路能否核对的关键。示例中四条验收要点各自对应一条用例，编号一一对应，评审时可以直接检查“每条要点是否都有用例承接”。如果某条要点找不到对应用例，说明验证关联缺失，应在提测前补齐，而不是等到发布后再补记录。
关联缺失时的处理方式需要事先约定。常见做法是：需求进入开发前检查来源与实现关联是否齐全，进入测试前检查验证关联是否齐全，缺失时由需求负责人补齐后再流转。示例规则只约定检查时点和责任人，具体由系统提示还是人工核对，取决于团队所用工具的支持情况。
在工具承载层面，ONES 以数字线程贯通需求、开发、测试、变更与发布，支撑影响分析、过程追溯和合规审计；其需求基线场景围绕需求、基线、版本和变更建立统一管理对象，测试发布场景把测试用例、缺陷、版本和发布过程关联到需求链路中。示例中的需求条目、任务、用例与依赖关系，可以在这样的关联结构里承载；具体字段名称与关联类型配置，需按团队实际使用的工具调整。
可迁移规律：把示例规则用到自己的需求上
示例中的规则可以按以下步骤迁移，每一步都有明确的产物，便于团队落地时对照检查。
- 先定关联类型，再定必填字段。列出团队需要回答的追溯问题，据此确定关联类型（如来源、实现、验证、依赖），再为每类决定是否必填。产物是一张“关联类型—必填—责任人”对照表。
- 按需求层级决定关联粒度。顶层业务需求可以只关联到子需求与验收要点，交付级需求则关联到任务、提交与用例。粒度随层级递减，避免高层需求被大量细粒度对象淹没。
- 用检查点核对关联完整性。在需求评审、开发启动、提测三个节点设置检查，分别核对来源、实现、验证关联是否齐全。产物是检查清单，每项写明检查对象与补齐责任人。
- 规则随团队规模调整取舍。小团队可以只强制来源与验证两类关联，实现关联靠任务看板保证；团队扩大、协作方增多后，再逐步增加实现与依赖的强制项。调整时保留旧数据的关联记录，避免历史链路断裂。
迁移过程中有一个常见取舍：强制项越多，链路越完整，但录入成本也越高。建议先用最小必填集运行一个迭代，观察核对时是否真的用得上这些关联，再决定增补。规则的价值体现在核对时能查到东西，而不是字段填得满。
适用边界：这些规则覆盖到哪里为止
本文示例覆盖的范围是从需求出发查看实现与验证链路：需求条目如何填写、关联哪些对象、关联类型与方向如何设置、链路如何核对。超出这个范围的内容不在示例规则之内。
测试充分性与覆盖率评估属于测试覆盖与需求验证主题。示例只保证每条验收要点有对应用例，不判断用例设计是否充分、覆盖是否达标。跨生命周期的治理，包括基线策略、版本规划、变更审批流程等，属于 ALM 应用生命周期管理主题，本文不展开。
示例规则是演示性的填写参考，不作为标准强制。不同团队的需求层级、交付节奏和工具配置差异较大，关联类型名称、必填项数量和检查时点都应结合自身流程调整。规则调整后，建议同步更新检查清单，并在下一次需求评审时验证新规则是否可执行。
常见问题
需求关联规则里，代码提交这一级关联一定要强制填写吗？
不一定。示例中把代码提交设为建议填写，原因是部分团队在任务层面已经能定位改动范围，强制到提交粒度会增加录入负担。是否强制取决于核对时是否真的需要查到提交这一层：如果评审或审计要求逐条改动可查，就设为必填；如果任务与用例已能支撑核对，保留为建议填写即可。
需求进入测试前发现验证关联缺失，应该怎么处理？
示例约定的做法是在提测检查点核对验证关联，缺失时由需求负责人补齐后再流转，而不是等到发布后补记录。补齐时先对照验收要点逐条检查是否有用例承接，找不到承接的要点要么补用例，要么确认该要点是否仍属于本次范围。检查由系统提示还是人工核对，取决于团队所用工具的支持情况。
小团队直接套用这套示例规则，会不会录入负担太重？
可以按规模取舍。示例建议小团队先只强制来源与验证两类关联，实现关联靠任务看板保证；团队扩大、协作方增多后，再逐步增加实现与依赖的强制项。调整时保留旧数据的关联记录，避免历史链路断裂。建议先用最小必填集运行一个迭代，观察核对时是否真的用得上这些关联，再决定增补。
需求层级不同，关联粒度应该怎么区分？
示例给出的规律是粒度随层级递减：顶层业务需求关联到子需求与验收要点即可，交付级需求则关联到任务、提交与用例。这样高层需求不会被大量细粒度对象淹没，交付级需求又能支撑逐项核对。具体分几层、每层关联到哪一级，需要结合团队的需求拆分习惯确定。
这套关联规则能用来判断测试做得够不够吗？
不能。示例只保证每条验收要点有对应用例承接，属于链路是否闭合的核对，不评估用例设计是否充分、覆盖率是否达标。测试充分性与覆盖率评估属于测试覆盖与需求验证主题，需要另外的方法和指标来判断。同理，基线策略、版本规划、变更审批等跨生命周期治理内容也不在示例规则范围内。
