2. 验收交付的合同与需求基线
在Teamcenter企业PLM项目中，验收争议往往不是发生在系统功能本身，而是发生在“当初到底承诺了什么”这一层。合同条款、SOW（工作说明书）、需求规格说明书（SRS）、URS（用户需求说明）、功能清单与验收标准，这六类文件通常由不同角色在不同阶段编写，彼此之间存在天然的粒度差异和语义漂移。如果不在验收前把它们拉通成一条可追溯的基线，验收就会退化为“各说各话”。本节的核心任务，就是把这六类文件组织成一条从商务承诺到可执行验证的追溯链。
六类文件的定位与粒度差异
先明确每类文件在验收基线中的角色，避免混用：
- 合同条款：法律与商务层承诺，规定交付范围、里程碑、付款条件、验收前提、违约责任。它通常不描述具体功能，但决定“验收不通过会怎样”。
- SOW：把合同范围拆解为可执行的工作包，说明交付物、假设条件、双方责任、排除项。它是范围边界的第一道防线。
- URS：由业务用户提出，用业务语言描述“我需要系统帮我完成什么”，粒度偏业务场景，常包含“应支持”“应能导出”等表述。
- 需求规格说明书（SRS）：由实施方或需求分析师编写，把URS转化为系统可实现、可测试的需求条目，包含功能需求、数据需求、接口需求和非功能需求。
- 功能清单：面向配置与开发的任务列表，通常对应Teamcenter中的具体对象、工作流、权限、报表或集成点。
- 验收标准：面向测试的可判定条件，必须包含前置条件、操作步骤、预期结果和判定阈值。
这六类文件不是简单的“越往下越细”，而是存在双向约束：合同和SOW约束范围，URS和SRS约束功能，功能清单和验收标准约束实现与验证。任何一条验收标准，都必须能向上追溯到至少一条SRS条目，再向上追溯到URS或SOW，最终落到合同范围。反过来，合同中的每一项交付承诺，也必须能向下找到对应的验收标准，否则就是“承诺了但无法验证”的悬空条款。
建立可追溯的验收基线：从条款到测试用例
实际操作中，建议用一张“验收追溯矩阵”作为基线载体。矩阵的行是验收标准，列是六类文件的编号，单元格填写对应关系。下面给出一个Teamcenter变更管理场景的示例片段，用于说明追溯关系如何落地。示例中的编号、参数和结果均为教学假设，不代表任何真实项目实测数据。
| 验收标准编号 | 合同/SOW | URS | SRS | 功能清单 | 验收判定 |
|---|---|---|---|---|---|
| AC-EC-001 | SOW-3.2 变更流程 | URS-07 变更申请审批 | SRS-4.1 变更工作流 | TC-WF-ECN-01 | 提交ECN后，按“工程师→主管→质量”三级审批，状态由“新建”变为“已批准” |
| AC-EC-002 | SOW-3.2 变更流程 | URS-08 变更影响分析 | SRS-4.3 影响对象关联 | TC-REL-IMP-02 | ECN关联的物料、BOM、文档在影响分析视图中全部可见，关联数量与手工核对一致 |
| AC-EC-003 | 合同-附件A 数据迁移 | URS-12 历史数据可用 | SRS-6.2 迁移映射 | TC-MIG-ITEM-05 | 抽取1000条历史物料，迁移后关键字段完整率≥99%，抽样20条与源系统一致 |
这张矩阵的价值在于：当验收会上有人质疑“这个功能没做到”时，可以立即定位到具体验收标准、对应SRS条目和合同依据，判断是范围外需求、理解偏差还是真实缺陷。没有矩阵，讨论就会停留在印象层面。
基线冻结与变更控制
验收基线不是一次性文档，而是一个受控状态。建议在项目进入系统测试前完成基线冻结，冻结对象包括：SRS版本、功能清单版本、验收标准版本，以及它们与合同/SOW的追溯关系。冻结后，任何新增或修改需求都必须走变更控制流程，评估对范围、进度和验收的影响，并更新追溯矩阵。否则，验收标准会在项目后期被不断“稀释”或“膨胀”。
追溯关系的可视化
下面的SVG用关系图表达六类文件之间的追溯方向与断链风险。图中实线表示正常追溯路径，虚线表示需要重点核对的弱关联，红色标记表示断链检查点。
图中三个断链检查点分别对应：合同或SOW中的承诺是否都有验收标准覆盖；验收标准是否都能追溯到SRS条目；SRS条目是否都有URS或SOW依据。实际项目中，建议在基线冻结评审会上逐项核对这三个检查点，并把核对结果记录在追溯矩阵的备注列中。
验收标准编写的最小可判定结构
验收标准是整条追溯链的末端，也是最容易写得模糊的一环。一条可判定的验收标准至少包含四个要素：前置条件、操作步骤、预期结果、判定阈值。以Teamcenter权限验收为例，可以写成：
AC-SEC-004
前置条件：已创建用户 U_ENG_01，角色为“设计工程师”；
已创建文件夹 F_Design，权限模板为“设计只读”。
操作步骤：1. 以 U_ENG_01 登录 Teamcenter；
2. 打开 F_Design 下的物料对象 M_001；
3. 尝试执行“修改属性”操作。
预期结果：系统拒绝修改，提示“当前角色无修改权限”。
判定阈值：连续执行 3 次，3 次均拒绝，且无异常日志。
追溯：SRS-5.2 权限控制；URS-15 设计数据只读；SOW-4.1 权限矩阵。这样的验收标准可以直接交给测试人员执行，也可以作为验收会上的判定依据。相反，“权限配置正确”这类表述无法判定，也无法追溯，不应进入基线。
基线维护的实操建议
在Teamcenter项目中，建议把追溯矩阵作为受控文档纳入配置管理，与SRS、功能清单同步版本。每次需求变更后，更新矩阵并重新检查三个断链点。验收前一周，组织一次基线走查，重点确认：所有合同承诺项都有验收标准；所有验收标准都有SRS来源；所有SRS条目都有URS或SOW依据。走查通过后，基线冻结，进入验收执行阶段。这样，验收会上讨论的就不再是“有没有做”，而是“验收标准是否通过”，争议空间会被大幅压缩。