需求追踪矩阵怎么做？把需求、设计、测试与验收串成一条线

需求追踪矩阵（RTM）不是把需求表和测试表并排放在一起，而是用稳定编号把“为什么要做、准备怎样实现、用什么检查、当前证据在哪里”连接起来。它最直接的用途，是发现有需求却没覆盖、有实现却找不到依据，以及需求变化后仍沿用旧测试的情况。

小型项目可以先在Boardmix 共享画布中整理这些关系，再链接到团队正式使用的需求、设计和测试记录。矩阵保存关联与状态，详细文档继续由各自负责人维护，避免同一规则在多个地方出现不同版本。

先追一条需求，看链路究竟断在哪里

以公司设备借还功能为例，业务方提出：“员工归还设备后，要检查是否完好，再让下一位同事借用。”这句话至少包含两个不同判断：归还登记是否成功，以及设备是否重新可借。如果只关联一条“归还按钮可以点击”的测试，需求看似有覆盖，关键规则却没有被验证。

可以先把这句话拆成四项，并为它们分配不会随排序变化的编号：

• R01 归还权限：仅当前借用人或设备管理员可登记归还。
• R02 待检查状态：登记归还后进入待检查，检查完成前不能再次借出。
• R03 检查通过：管理员确认检查通过后，设备恢复可借。
• R04 检查不通过：管理员填写问题说明后，设备转入维修中，不能借出。

“设备管理优化”适合做项目标题，不适合直接作为一条可追踪需求。反过来，也不必把每个按钮颜色都升级成需求编号。拆分标准是：能否独立说明业务目的、独立判断满足与否，并在变更时知道影响了什么。

一张够用的矩阵，需要哪些字段

第一版不追求几十列。保留需求编号、规则与来源、设计位置、验证方式或用例、当前证据，再加负责人和适用版本，就能开始检查链路。NASA 的需求验证矩阵说明同样强调唯一标识、需求来源及如何验证；日常产品团队可根据自己的风险和交付方式选择字段，不必照搬大型工程的全部文档。

设备归还功能：从规则找到设计和待执行验证

需求与来源	设计位置	验证关联	当前缺口
R01 归还权限；借还规则V1第2条	D01 归还入口与权限判断	TC01 借用人可操作；TC02 无关员工被拒绝	用例已列，执行结果待填
R02 待检查不可借；规则V1第3条	D02 归还后的状态转换	TC03 登记后检查可借列表及借出入口	需补接口侧的重复借出检查
R03 检查通过恢复可借；规则V1第4条	D03 检查通过分支	TC04 管理员通过后再次借出	尚未执行，不能标为已验收
R04 不通过转维修；规则V1第5条	D04 维修分支与问题说明	TC05 转维修不可借；TC06 缺少说明时阻止提交	需确认问题说明是否为必填要求

表里的“待填”和“需确认”是有用信息，不是为了整洁而清空的缺陷。R04最后一格揭示了一个具体问题：如果业务规则从未明确说明必填，就不能让测试自行宣布“缺少说明必须失败”。先让规则负责人确认，再更新需求与用例。

在实际项目中，D01、TC01等编号应链接到可访问的具体记录或段落，而不是都链接到一个文件夹。若测试材料只有一份大文档，至少记录章节或用例编号。链接能够打开，也不等于关联正确；仍要读到它实际验证了哪条规则。

正向查漏项，反向查无依据的实现

正向追踪从R02出发：先找到D02“归还后待检查”，再找到TC03，最后找到某个版本的执行记录。若TC03只检查页面上出现了“待检查”，却没有验证设备不能再借出，这条关系只能算部分覆盖，需要补足检查内容。

反向追踪从一个实现或测试出发。例如研发加了“登记归还后立即通知下一位预约人”，就要问它来自哪条已确认需求，通知时机是否和“待检查不可借”冲突。找不到来源不等于一律删除：它可能是必要的设计约束，也可能是未经确认的额外功能，应补充依据并由相应负责人决定。

一条需求对应多个用例很常见；同一个用例也可能同时验证多项需求。记录这种多对多关系时，使用原编号关联，不要复制出三条内容相同、编号不同的“新需求”。否则以后只改了其中一份，矩阵反而制造了冲突。

“已有用例”与“已经通过”必须分开看

四条需求都写上了用例编号，只能说明建立了验证关联，不能说明四条都实现，也不能说明四条都通过。尤其是需求表、用例表各自写了“完成”时，需要追问完成指的是设计、开发、执行还是验收。

可以将状态分为两组：一组记录关系是否完整，例如“缺设计、缺用例、关联待复核、关联完整”；另一组记录当前版本验证结果，例如“未执行、通过、失败、阻塞、不适用”。不适用也要说明理由和批准人，不能成为把红格改绿的捷径。

若要统计覆盖率，先写清分母。例如本版本纳入四条有效需求，其中三条已有经审查的验证关联，则需求关联覆盖是3/4。它不等于测试通过率，更不等于产品质量达到75%。历史版本、已取消需求和还未纳入范围的想法，不能混在同一个分母里。

验证也不只靠界面测试。某些文档要求可通过检查确认，某些性能或容量要求需要专门测量。本案例主要使用功能测试，只是因为这些设备状态和权限规则可以通过行为观察验证，不能据此把所有项目都压缩成一列测试用例。

规则一改，沿关联查影响，不重写整个矩阵

假设业务把R02改为：“普通配件归还后可直接恢复可借，贵重设备仍需管理员检查。”这不是把“待检查”三个字删掉就结束。至少需要重新确认设备分类来源、D02的分支、TC03的检查条件，以及R03和R04适用于哪类设备。

1. 保留变更前的规则版本。记录R02由V1改为V2的理由和确认人，不让旧测试结果看起来像验证了新规则。
2. 列出直接关联。R02→D02→TC03，标记需要更新；再查看与它共享设计的R03、R04。
3. 补入新条件。普通配件与贵重设备各有明确路径；未分类设备如何处理也要有结论。
4. 重新验证并回填证据。执行记录注明构建或版本、日期、结果及问题链接。尚未重测的部分保留待验证。

矩阵告诉团队要查哪些对象，却不能替代业务审批。新增规则是否进入当前版本、是否影响交付时间，仍应进入既有的需求变更管理流程。不要因为图上已经连了一条线，就把它当作获得了实施授权。

在画布里保留总表，再展开最值得讨论的一条链

在Boardmix中把矩阵放在画布一侧，另一侧只展开当前争议最大的R02：左边是规则卡，中间是D02状态分支，右边是TC03及缺失的接口检查。用文本写清连线表示“落实”还是“验证”，不要用无说明的箭头混合先后关系和引用关系。

创建这些内容时，可用文本或便签保存编号与短句，用表格整理总表，再用连接线指出需要共同检查的关系。产品补规则，研发补设计位置，测试补验证材料；每个人负责自己熟悉的部分。详细记录由各业务系统维护，白板用于共同审查关联缺口。

会后只保留有用的高亮：未确认规则、缺失关联、验证失败及其负责人。下次检查先看这些项是否解决，再抽查一条已经标绿的链能否真的读到证据。能顺着需求走到当前版本结果，也能从一个测试回到业务理由，才是一张可维护的需求追踪矩阵。