需求追溯矩阵把每条需求与它的来源、设计开发项、测试用例和缺陷逐条关联，方便在评审、变更和验收时快速查证。本文直接给出一张可复制到表格工具的空白矩阵，并说明各列填写对象、必填与选填的取舍、一条需求的完整填写示例，以及矩阵建立后的更新与评审方法。
要点总览（TL;DR）
- 空白矩阵包含需求编号、需求描述、需求来源、来源编号、设计/开发项编号、测试用例编号、缺陷编号、状态、负责人、变更记录十列，可直接复制到表格工具。
- 最小可用矩阵先保证需求编号、需求描述、需求来源、测试用例编号、状态、负责人六项；来源编号、设计/开发项编号、缺陷编号、变更记录随项目复杂度补齐。
- 填写顺序按“来源→需求→实现→验证→缺陷”建立链接，反向通过编号回查；同一单元格多个编号用分号分隔。
- 矩阵建立后按变更联动、定期评审、版本快照三类动作维护，避免追溯关系随需求变更失真。
- 需求、用例、缺陷分散在多个工具时，可把列结构映射为工作项字段与关联关系，让矩阵随状态更新。
可复制空白需求追溯矩阵模板
下面这张表可以直接复制到 Excel、在线表格或需求管理工具的自定义字段中。表头保持一行，每条需求占一行；同一需求对应多个设计项或测试用例时，可以拆成多行，也可以在同一单元格内用分号分隔多个编号。建议先复制表头，再按项目实际情况增删列。
| 需求编号 | 需求描述 | 需求来源 | 来源编号 | 设计/开发项编号 | 测试用例编号 | 缺陷编号 | 状态 | 负责人 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|
如果团队使用需求管理工具，可以把这张表作为字段设计的参照：需求编号、需求描述、来源、状态、负责人对应需求工作项的基础字段；设计/开发项、测试用例、缺陷则通过关联关系挂接到需求上。表格形式适合评审时导出查看，工具内关联适合日常维护，两者可以并存。
矩阵字段说明与追溯关系
矩阵的每一列都对应一个可查证的填写对象。填写时先保证编号唯一，再按“来源→需求→实现→验证→缺陷”的方向建立链接，反向则通过编号回查。
| 字段 | 填写对象 | 填写说明 |
|---|---|---|
| 需求编号 | 需求本身 | 全表唯一，建议采用“项目缩写-模块-序号”，如 REQ-PAY-001；编号一经分配不再复用 |
| 需求描述 | 需求内容 | 一句话写清系统应具备的行为或约束，避免只写标题；详细描述可放在需求文档中，此处保留可识别的摘要 |
| 需求来源 | 上游来源类型 | 填写客户、市场、法规、内部改进、上游系统等来源类别，便于按来源统计和评审 |
| 来源编号 | 上游单据 | 填写客户需求单、法规条款、立项文档或上层需求的编号，形成需求向上的追溯 |
| 设计/开发项编号 | 设计与开发产物 | 填写设计文档章节号、接口定义编号、开发任务或用户故事编号，说明该需求由哪些实现项承载 |
| 测试用例编号 | 验证项 | 填写覆盖该需求的测试用例编号；一条需求可对应多个用例，一个用例也可覆盖多条需求 |
| 缺陷编号 | 验证中发现的问题 | 填写测试或验收阶段发现的缺陷单号，用于回看该需求的验证过程是否闭环 |
| 状态 | 需求当前阶段 | 取值由团队约定，常见为待评审、已批准、开发中、待验证、已验证、已关闭、已变更 |
| 负责人 | 需求责任人 | 填写对需求内容与追溯完整性负责的角色，通常是需求分析师或产品负责人 |
| 变更记录 | 变更留痕 | 记录变更单号、变更日期和影响范围，或指向变更记录文档的位置 |
追溯方向分三段。第一段从来源编号指向需求编号，回答“这条需求为什么存在”；第二段从需求编号指向设计/开发项编号，回答“由什么实现”；第三段从需求编号指向测试用例编号，再由测试用例指向缺陷编号，回答“如何验证、验证中发现过什么问题”。反向追溯依靠编号回查：拿到一个测试用例，能通过用例编号找到它覆盖的需求；拿到一个缺陷，能定位受影响的需求范围。
编号规则建议在项目启动时一次约定：需求、设计项、测试用例、缺陷各自使用独立前缀，避免不同对象编号混淆；跨表引用时只写编号，不复制描述，防止描述修改后两处不一致。若使用表格工具，可用超链接把编号指向对应文档或工作项。
必填与选填字段的取舍
矩阵不必一次建全。项目初期先保证“每条需求有唯一编号、有来源、至少有一个验证项”，这三项决定了矩阵能否支撑基本追溯；其余字段随项目复杂度和评审要求逐步补齐。
| 字段 | 最小可用矩阵 | 完整矩阵 | 裁剪影响 |
|---|---|---|---|
| 需求编号 | 必填 | 必填 | 缺失则无法建立任何关联 |
| 需求描述 | 必填 | 必填 | 缺失则评审时无法判断关联是否合理 |
| 需求来源 | 必填 | 必填 | 缺失则无法按来源统计和做变更影响判断 |
| 来源编号 | 建议填写 | 必填 | 缺失时向上追溯只能到来源类别，无法定位具体单据 |
| 设计/开发项编号 | 建议填写 | 必填 | 缺失时需求与实现脱节，变更影响分析只能靠人工判断 |
| 测试用例编号 | 必填 | 必填 | 缺失则无法证明需求被验证，矩阵失去核心价值 |
| 缺陷编号 | 选填 | 必填 | 缺失时看不到验证过程中的问题闭环，验收追溯不完整 |
| 状态 | 必填 | 必填 | 缺失则无法判断需求处于哪个阶段 |
| 负责人 | 必填 | 必填 | 缺失则追溯缺口无人跟进 |
| 变更记录 | 选填 | 必填 | 缺失时历史变更无法回查，审计场景下追溯链断裂 |
裁剪字段时要注意连带影响：去掉来源编号，向上追溯就停在类别层面；去掉设计/开发项编号，需求变更后难以判断哪些实现需要调整；去掉缺陷编号，验证过程只剩“通过/不通过”的结论，问题处理过程无法回看。对于受监管或需要交付审计材料的项目，建议保留完整列；对于内部迭代快、需求粒度小的项目，可先保留最小集，在版本发布前补齐选填列。
完整填写示例：一条需求从来源到验证
以下示例为演示情景，展示一条支付相关需求在矩阵中的完整记录。示例中的编号、状态取值均为示意，实际使用时按团队规则替换。
| 需求编号 | 需求描述 | 需求来源 | 来源编号 | 设计/开发项编号 | 测试用例编号 | 缺陷编号 | 状态 | 负责人 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|
| REQ-PAY-001 | 支付失败时向用户展示失败原因，并保留重试入口 | 客户反馈 | CR-2024-017 | DES-PAY-003；TASK-PAY-021 | TC-PAY-045；TC-PAY-046 | BUG-PAY-112 | 已验证 | 张敏 | 2024-06-10 补充超时场景，影响 TC-PAY-046 |
这条记录的追溯路径可以这样读：客户反馈单 CR-2024-017 提出支付失败提示不清的问题，形成需求 REQ-PAY-001；设计文档 DES-PAY-003 定义了失败原因分类与重试交互，开发任务 TASK-PAY-021 完成实现；测试用例 TC-PAY-045 覆盖常规失败提示，TC-PAY-046 覆盖超时场景；测试中发现的 BUG-PAY-112 修复后回归通过，需求状态更新为已验证。变更记录显示 6 月 10 日补充了超时场景，并注明受影响的用例编号，后续复查时可以直接定位到需要回归的范围。
填写时有两个细节值得注意。一是同一单元格内多个编号用分号分隔，并在评审时确认每个编号真实存在，避免出现“填了编号但查不到对象”的情况。二是状态更新与验证动作同步：测试用例执行通过、缺陷关闭后再把状态改为已验证，不要提前更新，否则矩阵会显示与实际不符的覆盖情况。
矩阵的调整与日常维护方法
矩阵填完只是起点。需求会新增、拆分、变更和废弃，矩阵需要跟着这些动作联动更新，否则追溯关系会逐渐失真。维护工作可以拆成变更联动、定期评审和版本归档三类动作。
需求变更时的联动更新，按以下顺序执行：
- 在变更记录列登记变更单号和变更日期，写明变更内容与影响范围。
- 检查来源编号是否仍然有效，若上游单据已调整，同步更新来源信息。
- 评估受影响的设计/开发项，补充或替换实现项编号，并通知对应开发负责人。
- 检查测试用例是否仍覆盖变更后的需求，补充新用例或标记失效用例。
- 变更完成后更新状态，并在评审记录中留下确认人。
定期评审建议按迭代或版本节奏进行，每次评审做三件事：抽查需求是否都有至少一个测试用例关联；检查状态为已验证但缺陷未关闭的记录；核对新增需求是否已分配编号和负责人。评审发现的缺口直接记入矩阵，指定跟进人和完成时间，下次评审时复查。
版本与归档方面，建议在每个版本发布时导出一份矩阵快照，文件名包含版本号和日期，与发布记录一并保存。日常维护使用在线表格或工具中的活表，归档使用只读快照，避免历史版本被后续修改覆盖。若项目需要应对外部审计，快照中应保留变更记录列和评审确认信息。
当需求、设计项、测试用例和缺陷分散在多个工具中时，手工维护矩阵容易出现编号对不上、状态不同步的问题。ONES 的 ALM 方案以数字线程贯通需求、开发、测试、变更与发布，把测试用例、缺陷、版本和发布过程关联到需求链路中，需求变更时可以据此分析影响范围并回查交付结果；对于多角色协作的项目，需求分解、任务执行、测试反馈和变更处理可以在同一平台推进。团队可以把本文的列结构映射为需求工作项的字段与关联关系，让矩阵随工作项状态自动更新，减少手工誊抄。是否采用工具承载，取决于项目对追溯实时性和审计留痕的要求；规模较小、节奏较快的项目，用表格加定期评审也能满足基本追溯需要。
常见问题
需求追溯矩阵和需求文档里的需求列表有什么区别？
需求列表回答“有哪些需求”，追溯矩阵回答“每条需求从哪里来、由什么实现、用什么验证、验证中发现过什么问题”。矩阵在需求描述之外增加了来源编号、设计/开发项编号、测试用例编号和缺陷编号等关联列，评审时可以直接沿编号查证，而不必翻找多份文档。两者可以并存：需求文档承载详细描述，矩阵承载关联关系。
一条需求对应多个测试用例或多个缺陷时，矩阵怎么填？
两种方式都可以。拆行方式是一条需求占多行，每行填一个用例或缺陷编号，便于筛选和统计；合并方式是一条需求占一行，单元格内用分号分隔多个编号，表格更紧凑。建议用例数量较少时合并填写，数量多或需要按用例跟踪执行状态时拆行。无论哪种方式，都要保证每个编号在对应工具中真实存在，评审时抽查确认。
项目刚开始，矩阵字段太多填不过来，可以先砍掉哪些列？
先保留需求编号、需求描述、需求来源、测试用例编号、状态、负责人，这六列能支撑基本的来源追溯和验证追溯。来源编号、设计/开发项编号、缺陷编号、变更记录可以先留空或整列去掉，等进入版本发布或审计准备阶段再补齐。裁剪时注意连带影响：去掉设计/开发项编号后，需求变更时判断哪些实现需要调整只能靠人工排查；去掉缺陷编号后，验证过程只剩结论，问题处理过程无法回看。
需求变更后，矩阵里的旧记录应该删除还是保留？
保留旧记录，通过状态和变更记录列体现变化。常见做法是把原需求状态改为已变更，在变更记录列写明变更单号、日期和影响范围，再新增一条变更后的需求记录并关联原编号。这样历史追溯链完整，审计或复盘时能看清需求演进过程。直接覆盖旧内容会让之前的验证记录失去对应关系。
用表格维护矩阵和用需求管理工具维护，应该怎么选？
看项目对追溯实时性和审计留痕的要求。规模较小、迭代节奏快、参与角色少的项目，用表格加定期评审就能满足基本追溯，成本低、上手快。需求、设计、测试、缺陷分散在多个系统、变更频繁或需要交付审计材料的项目，手工誊抄容易出现编号对不上和状态不同步，可以考虑用工具承载关联关系。ONES 的 ALM 方案以数字线程贯通需求、开发、测试、变更与发布，把测试用例、缺陷、版本和发布过程关联到需求链路中，需求变更时可以据此分析影响范围并回查交付结果。团队可以把本文的列结构映射为需求工作项的字段与关联关系，让矩阵随工作项状态更新。
