4. MERLIC项目需求追溯与验收映射
在MERLIC项目里，需求追溯不是一张“给客户看的漂亮表格”，而是把客户原始需求逐条落到MERLIC工具链、流程配置和测试用例上的工程约束。它的核心产物是需求-验收双向追溯矩阵：正向从需求找到实现与验证，反向从某个MERLIC工具或测试用例找到它服务的需求。缺少任何一侧，验收时都会出现“功能做了但没人能证明它对应哪条需求”或“测试跑了但不知道覆盖了哪条需求”的断裂。
MERLIC的工程结构天然适合做追溯。一个典型项目由流程（Recipe）组织，流程内是工具（Tool）串联的数据流：图像源（Image Source）→ 预处理（如Filter、Align）→ 定位/分割（如Locate、Segment）→ 测量/判定（如Measure、Check）→ 结果输出（如结果聚合、通信工具）。每个工具都有可配置参数和输出结果，这些正是需求落地的“最小可追溯单元”。因此追溯矩阵的粒度不应停在“流程级”，而应细到工具实例 + 关键参数 + 输出结果，否则无法支撑验收判据。
建立矩阵的第一步是需求条目化。把客户文档中的自然语言拆成可验证的原子需求，每条给唯一编号，并明确三要素：对象（检测什么）、条件（在什么工况/光照/节拍下）、判据（合格/不合格的量化边界）。例如“检测金属件表面划痕”不是原子需求，应拆为：REQ-001 在工件表面ROI内检测长度≥0.5 mm的划痕；REQ-002 单件检测节拍≤300 ms；REQ-003 误检率≤1%、漏检率≤0.5%。只有带数值边界的条目，才能在MERLIC里找到对应参数，也才能写出可判定的测试用例。
第二步是正向映射：为每条需求指定MERLIC实现载体。以REQ-001为例，可用“Image Source → Align（定位工件）→ Segment/Blob或Filter提取暗线 → Measure测量长度 → Check按0.5 mm阈值判定”。映射时要记录工具类型、实例名、关键参数（如阈值、ROI坐标、最小长度）和输出结果名。REQ-002对应流程整体执行时间，需在MERLIC的流程执行统计或外部计时中采集；REQ-003对应测试集上的混淆统计。这样每条需求都有“实现位置”和“验证位置”两个锚点。
第三步是反向映射与覆盖检查：从每个MERLIC工具和每条测试用例反查它服务哪些需求。反向检查能暴露两类问题：一是“孤儿工具”——流程里存在但不对应任何需求，通常是调试残留，应在交付前清理或说明；二是“孤儿需求”——有需求但没有工具或测试覆盖，属于验收风险，必须补实现或补用例。双向矩阵的价值正在于让这两类缺口显式化。
矩阵落地时建议用一张可维护的表，字段不必多，但必须能双向查询。下面给出一个可直接套用的示例结构，其中参数与结果均为教学示例，实际项目需按真实标定填写。
| 需求编号 | 需求描述（含判据） | MERLIC实现载体 | 关键参数/输出 | 测试用例 | 验收判据 | 状态 |
|---|---|---|---|---|---|---|
| REQ-001 | ROI内划痕长度≥0.5 mm判NG | Align → Segment/Blob → Measure → Check | 阈值、最小长度0.5 mm、长度值 | TC-001 | 0.5/0.8 mm样本全部NG | 已覆盖 |
| REQ-002 | 单件节拍≤300 ms | 流程整体执行时间统计 | 单件耗时、P95 | TC-002 | 连续100件P95≤300 ms | 已覆盖 |
| REQ-003 | 误检≤1%、漏检≤0.5% | Check判定 + 结果记录 | 混淆矩阵、误检率、漏检率 | TC-003 | OK/NG各200件达标 | 已覆盖 |
| REQ-004 | 输出OK/NG与长度值至PLC/文件 | 通信/输出工具 | 信号地址、CSV字段 | TC-004 | 字段完整、时序正确 | 已覆盖 |
| REQ-005 | （示例）多工位切换需求 | — | — | — | — | 缺口 |
维护矩阵时有几个容易踩的坑。第一，需求编号必须稳定，一旦发布就不要复用或重排，否则历史测试记录会失去对应关系。第二，参数变更要回写矩阵：如果现场把最小长度从0.5 mm调到0.6 mm，REQ-001的判据和TC-001的样本边界都要同步更新，否则验收时会出现“配置与需求不一致”。第三，区分“已实现”和“已验证”：工具链里配好了只代表实现，只有测试用例通过并留下记录才算验证，矩阵状态应能区分这两态。第四，反向覆盖要定期跑：每次流程改动后，检查是否新增了不对应需求的工具，或是否有需求失去了测试覆盖。
最后要强调，追溯矩阵不是一次性文档。MERLIC流程在调试、优化、换型过程中会不断调整工具和参数，矩阵必须跟着走。验收前做一次完整的双向核对：从需求逐条确认有实现、有用例、有记录；从每个工具和每条用例反查它服务哪条需求。两侧都闭合，验收才有可辩护的依据，交付也才具备可维护性。