ASPICE SYS.5 系统验证，主要用来核对系统产出物能不能满足系统需求文档写出来的内容。ASPICE VAL.1 确认的目标，是确认产品在实际预期使用条件下，可以满足利益相关方的真实期望，重点面向用户使用场景、运行设计域 ODD。很多项目做完系统测试就认为确认工作已经完成，没有站在真实使用视角开展活动，等到评估才发现 VAL.1 缺少对应的工作产物。

实际项目开展 VAL.1 确认，经常出现几类问题。直接复用系统测试用例，没有设计真实工况、用户典型使用场景相关的确认项。确认活动没有考虑完整的运行设计域，不去覆盖边界使用条件，只在实验室理想环境开展工作。利益相关方参与不足，确认的结果没有客户、产品、售后这类角色参与评审。确认手段比较单一，只有仿真台架测试，缺少实车路试、用户试用、专家评估这类 VAL.1 允许的多种确认方式。确认发现的问题，没有录入问题台账闭环，确认记录没有和项目基线绑定归档。

要分清楚两者的定位，系统验证回答 “产品是不是符合需求文档”，VAL.1 确认回答 “产品在真实使用场景下能不能满足使用者的期望”，二者不能互相替代。

开展 VAL.1 确认策划阶段，就要区分开系统验证与确认活动。梳理利益相关方的使用期望，整理产品运行设计域 ODD，明确产品允许工作的环境、工况边界。选择适配本产品的确认手段，可以包含实车测试、台架仿真、专家评审、用户试用等多种方式，不局限于自动化测试用例。

确认的重点场景，覆盖典型用户操作、边界工况、多功能并发使用的情况，重点考察需求文档没有完整写明，但实际使用会遇到的情况。确认过程当中发现的偏差，全部录入 SUP.9 问题解决管理，按照流程开展分析、纠正、闭环。确认完成之后，形成确认总结报告，写明确认覆盖的场景、发现问题、结论，由对应的利益相关方参与评审签字，报告和对应的产品基线绑定归档。

如果部分场景无法开展实车确认，需要记录确认方式的取舍理由，经过评审留存，不能直接跳过确认环节。

内部预评估核查 VAL.1 的时候，重点看确认活动是不是面向真实使用期望，检查确认场景清单、确认手段、问题闭环记录，识别直接拿系统测试报告充当确认证据的情况。

VAL.1 确认不是系统测试的重复执行，它的价值是站在最终使用者视角，检验产品实际使用效果。分开策划、分开执行、分开留存证据，才能够落实 VAL.1 的各项实践，满足 ASPICE 评估取证的要求。