需求可追溯矩阵不是把编号排成表格，而是让团队回答“这条需求在哪里验证、谁负责、改动会影响什么”。从墨刀原型开始建立需求、页面和交互的对应关系，再把开发任务与测试用例补齐，评审时才能快速定位缺口。
一、矩阵至少要有六列
| 字段 | 填写规则 | 示例 |
|---|---|---|
| 需求ID | 一个需求只用一个稳定编号 | PAY-012 |
| 用户与场景 | 说明谁在什么条件下使用 | 已登录用户，提交订单 |
| 原型位置 | 页面、组件或交互节点 | 订单确认页/优惠券弹窗 |
| 实现任务 | 研发可领取的任务或接口 | 支付前校验优惠券 |
| 测试用例 | 覆盖主流程和异常 | 优惠券过期、库存不足 |
| 结论与负责人 | 记录状态、依据和确认人 | 已确认/产品张三 |
如果团队有版本或迭代字段，再增加“目标版本”和“变更原因”。不要把整段需求复制进每一行，保持原文链接，避免改文案后矩阵失效。
二、用登录和下单流程做一次完整追踪
- 把“用户能安全登录”拆成手机号、验证码、错误提示和频控四条可验证需求。
- 在墨刀原型中给每条需求绑定页面节点，补齐加载、失败、重试和返回路径。
- 把每个节点转成开发任务，并在任务描述中保留需求ID和原型链接。
- 为主路径、异常路径和权限边界各写至少一个测试用例，执行后把结果回填矩阵。
三、变更评审要看影响范围
需求改动时先查需求ID的全部关联项，再决定是否需要同步原型、接口和测试。比如“优惠券允许叠加”会同时影响优惠券组件、价格计算接口、订单展示和退款规则，不能只改一张页面。矩阵的价值就在于把影响范围显式列出来。
- 需求状态只用“草稿、评审中、已确认、开发中、已验收、已废弃”等有限值。
- 废弃需求保留原因和替代需求ID，不直接删除历史行。
- 每次评审记录时间、参与人和结论链接，避免状态无人认领。
- 每个已确认需求必须能追到一个原型节点和一个测试结果。
四、交付前的五分钟抽查
- 随机抽三条需求，从需求ID点击到原型、开发任务和测试结果。
- 从一个失败用例反向查回需求，确认没有孤立测试。
- 筛出没有负责人、没有结论或没有版本的行，作为发布阻断项。
- 导出本期矩阵给产品、设计、研发和测试共同确认，保存只读版本。
矩阵应当是项目的导航，而不是额外文档负担。只要每个字段都服务于一次真实决策，需求变更、原型评审和测试回归就能沿同一条链路推进。
五、矩阵模板如何服务迭代
矩阵不必覆盖整个产品，先从本期高风险需求开始。建议按迭代建立视图：产品视图看目标与规则，设计视图看页面和状态，研发视图看任务与接口，测试视图看用例和结果；底层仍使用同一需求ID。这样既不会复制多份内容，也能让每个角色只看到与当前工作有关的列。
六、一个需求变更的处理示例
假设“支付前必须完成实名认证”从可选改为必选。先把需求状态改为评审中，标出影响页面、接口、权限、提示文案和已有测试；设计补充未认证、认证中和认证失败三种状态；研发确认接口错误码与历史订单策略；测试新增回归用例。所有结论回填同一行及关联行，发布前再从需求ID走一遍链路。
- 矩阵中没有关联产物的需求先不进入开发排期。
- 需求废弃时保留替代需求和已发布版本，避免旧链接失效。
- 每次迭代结束导出只读快照，便于追溯当时的范围和结论。
把主流程和异常路径跑通后，再把本页的复现记录与交付结果放在同一份版本记录中，后续评审可以直接追踪。
案例：追踪“会员续费提醒可关闭”
先给需求一个稳定编号，例如 MEM-012，再把业务目标、规则、页面状态、研发任务和测试用例串起来。规则不能只写“支持关闭”，要明确关闭后何时再次出现、不同会员状态是否相同，以及关闭动作是否需要记录。
- 在 PRD 写触发条件、前置条件、成功结果和异常结果。
- 在原型中为默认、已关闭、到期和接口失败状态建立页面锚点。
- 让研发任务、接口字段和测试用例都引用 MEM-012，避免各写一套名字。
- 变更发生时保留旧记录，写清影响范围、负责人和新的验收结论。
- 评审时从目标反向点击到测试证据，找出只能写“已沟通”的断链。
| 链路节点 | 最低证据 | 完成条件 |
|---|---|---|
| 业务目标 | 目标和约束 | 负责人确认 |
| 原型 | 页面、状态和交互 | 任务脚本走通 |
| 开发测试 | 任务、接口和用例 | 结果可回溯 |
用“退款申请”填一行完整追溯矩阵
矩阵只有编号没有证据，仍然无法追责。建议从一条真实需求开始，至少同时记录目标、原型页面、交互状态、开发任务、接口字段、测试用例和负责人。
| 需求编号 | 原型与状态 | 开发/接口 | 测试证据 | 状态 |
|---|---|---|---|---|
| REF-012 退款申请 | 退款表单、资料缺失、审核中、拒绝、成功 | 退款原因、订单号、审批结果；接口：refund.apply | 正常、缺资料、重复提交、超时和失败重试 | 待研发确认 |
从需求到测试的五步
- 给需求分配稳定编号，并写清目标、范围、负责人和完成条件。
- 在墨刀原型中为每个关键状态建立页面或状态标记，链接回需求编号。
- 把页面状态转换成开发任务和接口字段，明确谁负责补充数据和权限。
- 把正常、拒绝、超时和回退路径转换成测试用例，记录执行结果链接。
- 需求变更时只更新受影响的行，并在变更记录写原因、影响范围和确认人。
评审时先从目标反向点击到测试证据，再从失败用例回到原型和规则。出现“已沟通”“见文档”但没有具体页面、字段或结果时，将该行标为缺口，直到补上证据。
矩阵最终应能支持三种查询：这条需求改动会影响哪些页面和接口；这个原型状态由哪个任务实现；这个测试失败需要回到哪条业务规则。能回答这三问，矩阵才有维护价值。
