2. 验收与交付的合同与需求基线
在HBK测试项目中，验收争议往往不是发生在测试执行阶段，而是发生在合同签订阶段——技术协议、SOW（工作说明书）和验收标准中埋下的模糊表述，会在交付时被放大成"你说达标、我说不达标"的僵局。因此，验收与交付工作的第一道工序，不是等测试做完再对照合同，而是在项目启动时就把合同语言翻译成可验证条目，并建立需求追溯矩阵（RTM），让每一条需求从来源到验证证据都有唯一、可查的路径。
一、三类合同文件的角色分工
技术协议、SOW和验收标准在项目中承担不同职能，提取可验证条目时必须先分清来源，否则会出现"用验收标准的粒度去要求技术协议"或"把SOW的管理条款当成技术指标"的错位。
- 技术协议：定义被测对象的技术规格与接口边界，例如通道数、采样率、量程、带宽、供电、通信协议、环境条件。它是"被测对象是什么"的权威来源，条目通常可直接量化。
- SOW：定义乙方要交付的工作范围、交付物形态、里程碑、现场条件、双方责任。它回答"做什么、交什么、谁配合"，其中一部分会转化为验收活动，一部分属于项目管理约束。
- 验收标准：定义"怎样算通过"，包括判定准则、测试方法、抽样规则、允差、复测条件和不合格处理。它是验收执行的直接依据，也是RTM中"验证方法"字段的主要来源。
三者的关系可以理解为：技术协议给出指标，SOW给出范围与交付物，验收标准给出判定规则。同一条需求可能同时出现在三份文件中，此时应以最严格且可执行的口径为准，并在RTM中记录多来源，避免后续出现"按哪份文件判"的争议。
二、从合同语言到可验证条目的提取方法
可验证条目的核心特征是：有明确的验证对象、可测量的参数、判定阈值、验证方法和证据形式。提取时可按"找主语—找参数—找阈值—找方法—找证据"五步推进。
以某HBK数据采集系统验收项目为例，技术协议中写有"系统应具备良好的动态响应能力"。这句话无法直接验证。经过提取，可转化为：
- 验证对象：数据采集通道（CH1–CH16）
- 可测参数：幅频响应平坦度
- 判定阈值：在0.1 Hz～10 kHz范围内，幅值偏差≤±0.5 dB
- 验证方法：正弦扫频法，使用标准信号源逐点激励，记录各频点幅值
- 证据形式：扫频测试记录表、原始数据文件、偏差曲线图
再如SOW中"乙方应在现场完成系统联调并提交报告"，可提取为：验证对象为联调后的系统；判定条件为所有通道通信正常、无丢包、报警功能触发正确；验证方法为现场联调记录与功能抽查；证据为联调报告、通信日志、报警触发记录。而验收标准中"抽样10%通道进行复测，不合格则加倍抽样"则应作为判定规则字段，而不是独立需求条目。
三、需求追溯矩阵的字段设计与建立流程
RTM不是简单的需求清单，而是一张"需求—验证—证据"的映射表。建议字段包括：需求编号、需求描述、来源文件及条款号、需求类型（功能/性能/接口/环境/管理）、验证方法（测试/检查/分析/演示）、判定准则、验证阶段、责任方、证据编号、状态。其中"来源条款号"和"证据编号"是追溯的关键，前者保证可回溯到合同原文，后者保证验收时可出示证据。
建立流程建议按以下顺序执行：
- 收集技术协议、SOW、验收标准三份文件的受控版本，记录版本号与日期。
- 逐条拆解，给每条可验证条目分配唯一编号，如RTM-PERF-001、RTM-IF-003。
- 对每条需求填写验证方法、判定准则和验证阶段，明确是出厂验收（FAT）还是现场验收（SAT）。
- 建立需求与测试用例的双向链接：一条需求至少对应一个测试用例，一个测试用例可覆盖多条需求。
- 评审确认：由甲乙双方对RTM逐条确认，特别是阈值、方法和抽样规则，确认后作为验收基线冻结。
下面这张图展示了从三类合同文件到可验证条目、再到RTM与验收证据的追溯链路，以及双向追溯关系。
四、RTM的评审、冻结与变更控制
RTM初稿完成后，必须组织甲乙双方联合评审。评审重点不是格式，而是三件事：阈值是否双方认可、验证方法是否可执行、证据形式是否可留存。例如"幅值偏差≤±0.5 dB"需要确认是在什么负载、什么温度、什么线缆条件下测得；"抽样10%通道"需要确认抽样是否随机、不合格后加倍抽样的具体规则。这些细节若不在评审阶段锁定，现场验收时极易产生分歧。
评审通过后，RTM应作为验收基线冻结，记录版本号与冻结日期。此后任何需求变更——无论是甲方新增功能、乙方调整实现方式，还是现场条件变化导致验证方法不可行——都必须走变更流程：提出变更单、评估对测试用例和证据的影响、更新RTM对应条目、重新确认阈值与方法。变更后要保证需求编号不重复、不复用，已作废条目保留并标注"作废"，以维持追溯链的完整性。
五、可执行成果：RTM条目示例表
下表给出一份可直接参考填写的RTM条目示例，字段和取值均来自HBK测试项目常见场景，实际使用时按项目合同替换具体条款号和阈值。
| 需求编号 | 需求描述 | 来源文件/条款 | 类型 | 验证方法 | 判定准则 | 阶段 | 证据编号 | 状态 |
|---|---|---|---|---|---|---|---|---|
| PERF-001 | CH1–CH16幅频响应平坦度 | 技术协议 4.2 | 性能 | 正弦扫频测试 | 0.1 Hz～10 kHz内偏差≤±0.5 dB | FAT | E-001 | 已覆盖 |
| IF-003 | 采集系统与上位机通信正常 | 技术协议 5.1 | 接口 | 通信检查+丢包统计 | 连续1 h无丢包、无断连 | SAT | E-004 | 已覆盖 |
| FUNC-007 | 超限报警功能触发正确 | SOW 3.2 | 功能 | 功能演示 | 设定阈值后3 s内报警，记录可查 | SAT | E-009 | 待验证 |
| ACC-002 | 通道抽样复测合格率 | 验收标准 2.4 | 验收规则 | 抽样复测 | 抽10%通道，不合格则加倍抽样 | SAT | E-012 | 待验证 |
这张表的价值在于：每一条需求都能回答"从哪来、怎么验、判什么、留什么证据、现在什么状态"。当验收会议出现争议时，双方只需打开RTM，按需求编号定位到来源条款和证据编号，就能把讨论从"感觉"拉回到"合同与数据"。这也是需求追溯矩阵在HBK测试项目验收与交付中最实际的作用——它不是一份文档，而是一条从合同签订到验收签字的可审计链路。