需求追溯矩阵把需求、实现和验证三端放在同一张表里对照，用来回答“这条需求由什么实现、用什么验证、现在覆盖到什么程度”。本文直接给出一份可复制的空白矩阵和配套的测试用例对照表，逐列说明填写口径，区分必填与选填，并用一条完整需求演示从录入到验证的填写过程，最后给出随需求变更更新矩阵、识别覆盖缺口的方法。
要点总览（TL;DR）
- 需求追溯矩阵以需求为行，横向记录需求来源、实现载体（设计文档、代码模块或配置项）和验证载体（测试用例、验证结论），用覆盖状态列判断每条需求是否走完追溯链路。
- 空白模板包含主表和测试用例对照小表：主表看覆盖全貌，小表按“一条需求—一个用例”拆行，两者通过需求编号关联。
- 需求编号、名称、来源、状态、覆盖状态为必填；实现载体、负责人、用例编号在进入对应阶段后转为必填；缺口说明在覆盖状态非“已覆盖”时必填。
- 填写示例演示了一条需求从需求侧、实现侧到验证侧的完整记录，并给出“部分覆盖”时缺口说明的具体写法。
- 维护动作挂在需求评审、提测、验收三个节点上，按列划分责任人，并通过正反两个方向比对识别未覆盖需求和孤立用例。
可复制空白需求追溯矩阵模板
下面的主表以需求为行，横向展开实现与验证信息。将表头复制到 Excel、在线表格或需求管理工具的自定义字段中即可开始填写。示例行中的“待填写”仅用于标示位置，正式使用时替换为实际内容或删除该行。
| 需求编号 | 需求名称 | 需求来源 | 优先级 | 需求状态 | 设计文档 | 代码模块/配置项 | 实现负责人 | 测试用例编号 | 验证方式 | 验证结论 | 覆盖状态 | 缺口说明 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
当一条需求对应多个测试用例时，主表的一格会容纳多个编号，阅读和统计都不方便。此时用下面的对照小表按“一条需求—一个用例”拆行，主表的测试用例编号列填写该需求下的用例数量或范围，明细放在小表中。
| 需求编号 | 测试用例编号 | 用例标题 | 验证方式 | 执行结果 | 执行人 | 执行日期 |
|---|---|---|---|---|---|---|
| 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
两张表通过“需求编号”关联。主表回答覆盖全貌，小表回答每条需求具体被哪些用例验证过。规模较小的项目可以只保留主表，把用例编号直接列在同一格内并用逗号分隔；需求数量超过几十条、或一条需求对应五个以上用例时，建议启用对照小表。
矩阵字段说明：每一列记录什么
字段说明与上面的表头逐列对应。填写时保持同一口径，矩阵才能在评审和审计中被直接引用。
需求侧字段
- 需求编号：需求在需求库中的唯一标识，建议沿用系统自动生成的编号，不要手工另编一套，避免与需求库对不上。
- 需求名称：一句话描述需求要达成的结果，与需求库标题保持一致，便于人工核对。
- 需求来源：记录需求提出方或依据，例如客户反馈、合同条款、内部规划、法规要求。来源决定后续变更时找谁确认。
- 优先级：使用团队既有的分级，如高、中、低或 P0–P3。优先级影响覆盖缺口的处理顺序。
- 需求状态：草稿、已评审、开发中、已实现、已验证、已废弃。状态是判断矩阵是否需要继续跟进的依据。
实现侧字段
- 设计文档：承载该需求设计说明的文档名称或编号，可以是需求规格、接口文档或方案说明。
- 代码模块/配置项：需求落地位置。软件项目填模块、服务或代码仓库路径；配置类项目填配置项名称。一个需求涉及多处时全部列出。
- 实现负责人：对该需求实现结果负责的人，用于变更时通知和缺口跟进。
验证侧字段
- 测试用例编号：验证该需求的用例标识，与测试用例库一致。多个用例时填写编号范围或数量，明细放对照小表。
- 验证方式：测试、评审、演示、验收、检查等。不同需求适用的验证方式不同，写清楚便于判断验证是否充分。
- 验证结论：通过、不通过、待验证、部分通过。结论要与最近一次执行结果一致，不能停留在历史状态。
追溯字段
- 覆盖状态：已覆盖、部分覆盖、未覆盖。判断依据是实现载体和验证载体是否都已落实且验证通过。
- 缺口说明：覆盖状态非“已覆盖”时必填，写明缺的是实现、用例还是执行结果，以及计划补齐的时间。
- 变更记录：记录该行最近一次实质性变更的日期与内容摘要，例如“需求拆分，原 REQ-012 拆为两条”。
必填与选填：哪些列不能空
矩阵失效最常见的原因是关键列留空后无人察觉。必填列的作用是保证每一行都能被追溯到两端，选填列则按项目需要裁剪。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 需求编号 | 必填 | 行的唯一标识，缺失则整行无法被引用 |
| 需求名称 | 必填 | 评审时的主要阅读对象 |
| 需求来源 | 必填 | 变更确认和验收对账的依据 |
| 需求状态 | 必填 | 决定该行是否仍需跟进 |
| 优先级 | 选填 | 需求量大、需要排缺口处理顺序时填写 |
| 设计文档 | 选填 | 需求简单、实现方式无歧义时可不填 |
| 代码模块/配置项 | 必填（进入开发后） | 需求评审通过前可暂空，进入开发即须补齐 |
| 实现负责人 | 必填（进入开发后） | 缺口跟进需要明确到人 |
| 测试用例编号 | 必填（进入验证前） | 没有用例的需求应标为未覆盖 |
| 验证方式 | 选填 | 验证方式单一的项目可省略 |
| 验证结论 | 必填（已验证后） | 结论为空不能视为通过 |
| 覆盖状态 | 必填 | 矩阵的核心判断列 |
| 缺口说明 | 条件必填 | 覆盖状态非“已覆盖”时必填 |
| 变更记录 | 选填 | 需求变更频繁的项目建议保留 |
允许暂时空缺的字段需要用统一标记区分“还没到填写时点”和“漏填”。建议用“待补”表示尚未到阶段，用“缺失”表示已到阶段但未落实，后者应进入缺口清单。两种标记混用会让矩阵失去判断价值。
裁剪列时遵循一个原则：删掉后仍能回答“这条需求由谁实现、被什么验证、覆盖到什么程度”的列可以删，影响这三个回答的列保留。十人以内的项目通常保留需求编号、名称、来源、状态、实现载体、负责人、用例编号、覆盖状态八列即可；涉及外部验收或合规审查的项目，应保留验证方式和验证结论，便于提供证据。
填写示例：一条需求走完追溯链路
以下示例为演示情景，用于说明填写口径，不代表真实项目数据。假设某系统需要支持“登录失败五次锁定账号”这一需求。
| 需求编号 | 需求名称 | 需求来源 | 优先级 | 需求状态 | 设计文档 | 代码模块/配置项 | 实现负责人 | 测试用例编号 | 验证方式 | 验证结论 | 覆盖状态 | 缺口说明 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REQ-021 | 登录失败五次锁定账号 | 客户安全评估反馈 | 高 | 已验证 | 《账号安全设计说明》v1.2 | auth-service / 登录校验模块 | 张明 | TC-105、TC-106 | 功能测试 | 通过 | 已覆盖 | — | 2024-06-12 补充锁定阈值配置项 |
对应的测试用例对照小表如下：
| 需求编号 | 测试用例编号 | 用例标题 | 验证方式 | 执行结果 | 执行人 | 执行日期 |
|---|---|---|---|---|---|---|
| REQ-021 | TC-105 | 连续五次密码错误后账号锁定 | 功能测试 | 通过 | 李婷 | 2024-06-18 |
| REQ-021 | TC-106 | 锁定期间正确密码仍被拒绝 | 功能测试 | 通过 | 李婷 | 2024-06-18 |
这条示例与字段说明的对应关系是：需求侧四列来自需求库；实现侧三列说明需求落在哪个设计文档和代码模块、由谁负责；验证侧三列说明用哪两个用例、以什么方式验证、结论如何；追溯三列给出覆盖判断和变更痕迹。缺口说明填“—”表示无缺口，覆盖状态为“已覆盖”的前提是实现载体和验证载体都已落实且结论为通过。
再看一个未覆盖的写法：若 REQ-021 只有 TC-105 执行通过，TC-106 尚未编写，则覆盖状态应填“部分覆盖”，缺口说明写“缺少锁定期间拒绝正确密码的用例，计划 6 月 25 日前补充”，验证结论填“部分通过”。这样的记录在评审时能直接转化为待办，而不是一句笼统的“测试中”。
矩阵的调整与维护方法
矩阵建好后如果只在项目初期填一次，很快就会与需求库和用例库脱节。维护的重点是把更新动作挂到已有的需求流程节点上，而不是另设一套台账。
需求新增、变更、废弃时的更新动作
- 新增需求：需求评审通过当天在矩阵中新增一行，填写需求侧字段，实现和验证列标“待补”，覆盖状态填“未覆盖”。
- 需求变更：修改需求名称或验收口径时，同步检查实现载体和用例是否仍适用；不适用的用例标为待更新，覆盖状态回退为“部分覆盖”，并在变更记录写明变更日期与内容。
- 需求废弃：需求状态改为“已废弃”，覆盖状态改为“不适用”，保留该行不删除，避免历史追溯断链；对应用例标记停用。
- 需求拆分或合并：新编号单独成行，原编号行标注去向，变更记录写清拆分或合并关系。
评审时点与责任人
建议在三个节点检查矩阵：需求评审后核对新增行是否齐全；提测前核对每条开发中需求的实现载体和用例是否已补齐；验收前核对验证结论与覆盖状态是否一致。责任人按列划分：需求侧由需求负责人维护，实现侧由开发负责人维护，验证侧由测试负责人维护，覆盖状态由项目负责人或质量负责人在评审时统一确认。责任到列比责任到整张表更容易执行。
用矩阵识别未覆盖需求与孤立用例
筛选覆盖状态为“未覆盖”或“部分覆盖”的行，按优先级排序，即得到待补齐清单。反向检查同样重要：把测试用例库中的用例与矩阵的用例编号列比对，找出没有对应需求的用例，这些孤立用例可能来自已废弃需求，也可能是需求遗漏，需要回到需求库确认。两个方向都查一遍，矩阵才真正起到对照作用。
矩阵与需求库、测试用例库的同步方式
手工维护三份数据容易产生偏差。可行的做法是以需求库和用例库为数据源，矩阵只保留关联关系和覆盖判断：需求编号、名称、状态从需求库同步，用例编号和执行结果从用例库同步，矩阵中人工维护的是实现载体、负责人和缺口说明。同步频率与评审节点一致即可，不必追求实时。
当需求和用例已经在同一工具中管理时，可以把这种关联直接建在工作项上。以 ONES 为例，需求工作项可以关联对应的测试用例，用例执行结果回写到需求侧，团队据此查看哪些需求已有通过验证的用例、哪些仍处于未覆盖状态，矩阵中的覆盖状态列由此获得可核对的数据来源，减少手工比对。工具承载的是关联与状态同步，字段口径和评审节奏仍按本文的规则执行。
维护检查可以固化为一张短清单：新增需求是否已入表；开发中需求的实现载体和负责人是否齐全；提测需求的用例编号是否齐全；验证结论是否与最近一次执行一致；覆盖状态非“已覆盖”的行是否都有缺口说明和补齐时间；废弃需求是否保留行并标注去向。每次评审按清单过一遍，矩阵就能持续可用。
常见问题
需求追溯矩阵和测试用例清单有什么区别，能不能只留一份？
两者回答的问题不同。测试用例清单以用例为中心，说明每个用例验证什么、执行结果如何；追溯矩阵以需求为中心，说明每条需求由什么实现、被哪些用例验证、覆盖到什么程度。只保留用例清单时，难以快速判断某条需求是否完全没有对应用例；只保留矩阵时，用例的执行明细又放不下。
实际做法是矩阵主表保留覆盖判断，用例明细放在对照小表或用例库中，两者通过需求编号和用例编号关联。需求数量少、一条需求只对应一两个用例时，可以合并为一张表，把用例编号直接写在矩阵行内。
需求还没进入开发，实现载体和用例编号这些列怎么填？
按阶段填写，未到填写时点用统一标记“待补”，不要留空，也不要用“缺失”。需求评审通过时先补齐需求侧字段，实现载体、负责人、用例编号标“待补”，覆盖状态填“未覆盖”。进入开发后补齐实现载体和负责人；提测前补齐用例编号；验证完成后填写验证结论并更新覆盖状态。
“待补”和“缺失”要分开用：前者表示尚未到阶段，后者表示已到阶段但未落实，后者应进入缺口清单并在评审时跟进。
一条需求对应很多测试用例，主表一格放不下怎么办？
启用对照小表，按“一条需求—一个用例”拆行，主表的测试用例编号列填写编号范围或用例数量，明细放在小表中。这样主表保持一行一条需求，便于统计覆盖状态；小表承担执行明细，便于查看每个用例的结果和执行人。
判断是否启用小表可以参考两个条件：需求数量超过几十条，或单条需求对应五个以上用例。规模较小的项目可以只保留主表，用例编号用逗号分隔写在同一格内。
矩阵建好后由谁负责更新，多久检查一次？
建议按列划分责任：需求侧字段由需求负责人维护，实现载体和实现负责人由开发负责人维护，用例编号和验证结论由测试负责人维护，覆盖状态由项目负责人或质量负责人在评审时统一确认。责任到列比指定一个人维护整张表更容易落实。
检查频率跟随需求流程节点即可，不必追求实时同步：需求评审后核对新增行是否齐全，提测前核对实现载体和用例是否补齐，验收前核对验证结论与覆盖状态是否一致。需求变更频繁的项目可以在每次迭代评审时增加一次检查。
怎么用矩阵发现没有被覆盖的需求？
正向检查：筛选覆盖状态为“未覆盖”或“部分覆盖”的行，按优先级排序，得到待补齐清单，逐条确认缺的是实现、用例还是执行结果。反向检查：把测试用例库中的用例与矩阵的用例编号列比对，找出没有对应需求的孤立用例，回到需求库确认是需求遗漏还是用例已失效。
两个方向都查一遍，矩阵才能同时发现“有需求没验证”和“有用例没需求”两类问题。孤立用例如果来自已废弃需求，应在用例库中标记停用，避免后续重复排查。
