2. 验收标准与合同解读

在 Windchill 企业 PLM 项目中，验收争议往往不是"系统能不能用"，而是"合同里那句话到底算不算数"。验收标准不是项目末期才整理的材料，而是从合同签署阶段就应当被逐条拆解、逐条映射到可执行测试的工程资产。本节聚焦一个核心动作：把 SOW、技术协议、需求规格说明书中的自然语言条款，翻译成可验证、可判定、可追溯的验收指标，并区分功能、性能、集成、文档四类验收的不同判定逻辑。

一、三类合同文档的分工与解读顺序

Windchill 项目通常同时存在三份约束性文件，它们的法律效力和技术粒度并不相同，解读时必须先建立优先级：

• SOW（工作说明书）：界定项目范围、交付物清单、里程碑与验收节点。它回答"做什么、交什么、什么时候验"，但通常不写具体参数。例如"SOW 第 4.2 条：完成零部件与 BOM 管理模块上线并通过用户验收测试"。
• 技术协议：约定架构、部署方式、性能指标、接口协议、并发规模等可量化要求。它回答"做到什么程度算合格"，是性能与集成验收的主要依据。例如"支持 500 并发用户，常用查询响应时间不超过 3 秒"。
• 需求规格说明书（SRS）：逐条描述功能行为、字段、权限、流程分支与异常处理。它回答"具体怎么表现"，是功能验收的主要依据。

解读顺序建议为：SOW 定范围 → 技术协议定指标 → SRS 定行为。当三者冲突时，以签署时间更晚、约定更具体的文件为准，并在验收方案中显式记录该判定，避免后期扯皮。

二、从条款到可验证指标的翻译方法

合同语言与测试语言之间存在一道鸿沟。翻译的关键是补齐四个要素：触发条件、输入数据、预期结果、判定阈值。缺少任一要素，条款就不可验证。

以技术协议中一句常见表述为例："系统应具备良好的文档检索性能。"这句话无法直接验收。翻译过程如下：

1. 明确对象：Windchill 文档库中的文档检索功能（非全文检索或 CAD 模型检索）。
2. 明确输入：文档总量 50 万条，单文档平均 2MB，元数据字段 15 个。
3. 明确操作：按文档编号精确检索、按名称模糊检索、按创建时间范围检索三类。
4. 明确阈值：在 200 并发用户下，精确检索 P95 响应时间 ≤ 2 秒，模糊检索 P95 ≤ 5 秒。
5. 明确判定：连续执行 3 轮，每轮 1000 次请求，达标轮次 ≥ 2 轮即通过。

经过这一步，"良好的检索性能"就变成了可复现的测试用例。同样的方法适用于所有模糊条款，例如"界面友好"应翻译为"关键操作路径不超过 3 级菜单、常用功能首屏可见"，"数据安全"应翻译为"角色权限矩阵覆盖全部 12 类对象、越权访问返回 403 且记录审计日志"。

三、四类验收的判定逻辑差异

功能、性能、集成、文档四类验收，其证据形式与通过标准完全不同，不能混用同一套判定方式。

功能验收关注"行为是否正确"，允许存在不影响主流程的 P3 缺陷；性能验收关注"指标是否达标"，必须给出统计分布而非单次结果；集成验收关注"数据是否一致"，重点在边界与异常场景；文档验收关注"交付是否完整"，重点在版本与签字。四类验收的通过标准应在验收方案中分别写明，不能笼统写"系统验收合格"。

四、验收指标提取的完整链路

下图展示了从合同文档到验收判定的完整链路，以及四类验收在链路中的分叉位置。左侧为输入文档，中部为指标翻译与分类，右侧为对应的证据与判定方式。

五、验收指标提取的实操要点

在实际项目中，条款翻译最容易出问题的地方有三处。第一是指标缺少边界条件，例如只写"支持 500 并发"却没写并发用户的操作类型分布，导致压测场景与真实场景脱节。第二是集成验收遗漏异常分支，例如只验证 ERP 到 Windchill 的物料主数据同步成功，未验证网络中断后重传是否产生重复数据。第三是文档验收只数数量不看版本，例如交付了 20 份文档但其中 3 份仍是草稿版本。

建议在验收方案中为每条指标补充"边界与异常"一列，明确以下内容：正常路径的输入与预期；边界值（如并发上限、数据量上限、字段长度上限）；异常路径（接口超时、数据格式错误、权限不足）的预期行为；以及判定不通过时的处理方式（整改后复测、降级验收或列入遗留问题）。

把合同条款翻译成可验证指标，本质上是把法律语言转成工程语言。SOW 划定范围边界，技术协议提供量化阈值，SRS 描述功能行为，三者共同构成验收的输入。功能、性能、集成、文档四类验收各有独立的证据形式和通过标准，必须在验收方案中分别定义。只有当每条合同条款都能对应到唯一用例编号和可追溯证据时，Windchill 项目的验收才具备可执行、可复现、可判定的基础。