系统验证是一组操作，用于检查任何元素(系统元素、系统、文档、服务、任务、系统需求等)与其目的和功能的合规性。在系统的整个生命周期中计划并执行这些行动。验证是一个通用术语，需要在它发生的上下文中进行实例化。如果将验证理解为一个过程，则验证是对系统的每个生命周期阶段的横向活动。特别是在系统的开发周期中，验证过程与系统定义和系统实现过程并行执行，并适用于由该活动产生的任何活动和产品。验证过程并不局限于系统开发结束时的一个阶段，而是通常发生在一组生命周期任务或活动的结束时，并且总是发生在开发项目的每个里程碑的结束时。它可以在开发期间的每一个产生的工程元素的迭代基础上执行，并且可以从对表达的涉众需求的确认开始。当验证过程应用于完全集成的系统时，它通常被称为最终验证。重要的是要记住，虽然系统验证与验证是分开的，但活动是互补的，并打算一起执行。

定义和目的

验证是通过提供客观证据确认特定预期用途或应用的需求已得到满足。 在 ISO 9000:2005 中添加了一条注释： 验证是一组活动，可确保并提供系统能够在预期的操作环境 （ISO 2005）。

作为一项通用操作，验证的目的是确定任何活动输出与活动输入相比的合规性。 它用于提供信息和证据，证明输入的转换产生了预期的和 正确 的结果。 验证基于有形证据； 即，它基于信息，其真实性可以通过检查、测量、测试、分析、计算等技术或方法获得的事实结果来证明。因此，验证系统（产品、 服务 或企业） ) 包括证明它满足其系统需求以及最终取决于合同实践的利益相关者的需求。 从全球的角度来看，验证系统的目的是获得对系统在特定操作条件下实现其预期任务或使用的能力的信心。

原理和概念

验证操作的概念

为什么要验证？

系统工程(SE)的主要目标 是开发满足利益相关者需求和需求的解决方案。 验证是工程师确保系统满足这些需求和需求的过程。

定义并执行验证操作（参见下面的图 1 ） 。

图 1. 验证操作的定义和使用。 （SEBoK 原创）

应用于工程元素的验证操作包括以下内容：

• 将对其执行验证操作的元素的标识。
• 定义验证操作的预期结果的参考标识。

执行验证操作包括以下内容：

• 通过对提交的元素执行验证操作来获得结果。
• 将获得的结果与预期结果进行比较。
• 推导出元素的符合程度。
• 决定这种合规性的可接受性，因为有时比较的结果可能需要一个价值判断来决定是否接受与使用上下文的相关性相比获得的结果。

注意：如果对合规性存在不确定性，原因可能是需求不明确。

验证什么？

任何工程元素都可以使用特定的参考来进行比较验证，例如利益相关者需求、系统需求、功能、系统元素、文档等。示例如下表 1 所示：

表 1. 验证项目示例 （SEBoK 原创）

确认与验证

系统验证文章的 确认与验证 部分 给出了这两个概念和相关过程之间的根本区别。 表 2 提供了有助于理解这些差异的信息。

表 2. 验证和确认差异（可能因上下文而异）。 （SEBoK 原创）

验证、最终验证和操作验证

系统验证涉及作为一个整体的全局系统，它基于需求的整体（系统需求、利益相关者的需求等），但它是在整个开发阶段以三种非排他性的方式逐渐获得的：

• 对每个工程要素应用相应过程所提供的验证动作和确认动作的结果进行累积；
• 在工业环境中对完整的集成系统执行最终验证操作（尽可能接近操作环境）； 和
• 在其操作环境（使用环境）中对整个系统执行操作验证操作。

每个级别的验证和确认级别

对一个完整的、集成的复杂系统只进行一次全局验证是不可能的。 故障/缺陷的来源可能很重要，并且不可能确定在此全局检查期间出现的不合格的原因。 通常， 感兴趣的系统 (SoI) 在设计期间已分解为一组系统层。 因此，在集成到更高级别的父系统之前，每个系统和系统元素都经过验证、验证和可能的纠正，如图 2 所示。

图 2. 每个级别的验证和确认级别。 （SEBoK 原创）

必要时，系统和系统元素被部分集成到子集中，以限制在单个步骤中要验证的属性数量。 对于每个级别，都需要执行一组最终验证操作，以确保前面级别所述的功能不被损坏。 此外，如果环境发生变化，在给定环境中获得的合规结果可能会变成不合规结果。 因此，只要系统未完全集成和/或未在实际操作环境中运行，就不应将任何结果视为确定的。

级别内部和横向的验证操作和确认操作

在系统分解的每一层内，在系统定义和系统实现期间执行验证动作和确认动作 。 图 3 表示上层，图 4 表示下层。 利益相关者需求定义和操作验证在系统分解的两个层次之间建立了联系。

图 3. 系统分解上层的验证和确认操作。 （SEBoK 原创）

系统元素需求和产品的操作验证使得分解的两个较低级别之间的联系。 请参见下面的图 4。

图 4. 较低级别的系统分解中的验证和确认操作。 （SEBoK 原创）

注意：系统分解的最后一层专门用于系统元素的实现，活动的词汇和数量可能与图 4 中的不同。

验证和确认策略

验证和确认之间的区别对于详细说明集成策略、验证策略和验证策略特别有用。 实际上，系统实现的效率是通过将三种策略优化在一起形成通常所说的验证和确认策略来获得的。 这种优化包括定义和执行最少数量的验证和确认操作，但检测最大数量的错误/故障/缺陷并实现对系统的最大置信度。 优化考虑了如果排除某些验证操作或验证操作可能产生的风险。

过程方法

该方法的目的和原则

验证过程的目的是提供客观证据，证明正在使用的系统提供的服务符合利益相关者的需求并在其预期的操作环境中实现其预期用途（ISO/IEC/IEEE 15288 2015）。 验证过程执行比较评估并确认正确定义了利益相关者的需求。 在发现差异的地方，将其记录下来以指导未来的纠正措施。 系统验证由利益相关者批准（ISO/IEC/IEEE 15288 2015）。

验证过程表明实现的最终产品在预期的操作环境中满足其利益相关者（客户或其他相关方）的期望，并由预期的操作员和/或用户执行验证（NASA 2007, 1-360）。 将每个系统元素、系统和完整的 SoI 与它们自己的适用需求（系统需求和利益相关者需求）进行比较。 这意味着在系统的全球开发过程中，验证过程会根据需要多次实例化。

为了确保验证是可行的，需求的实现必须在定义的元素上是可验证的。 确保需求被正确编写是至关重要的，即，可量化、可测量、明确等。此外，验证/确认需求通常与利益相关者和系统需求一起编写，并提供一种方法来演示每个系统需求的实现或利益相关者的需求。

通用输入 是适用于提交元素的需求的参考。 如果元素是系统，则输入是系统需求和利益相关者需求。

通用输出 是验证计划，包括验证策略、选定的验证操作、验证程序、验证工具、验证的元素或系统、验证报告、问题/故障报告以及对需求或系统的更改请求。

进程的活动

在此过程中执行的主要活动和任务包括：

• 建立验证策略（通常在验证计划中起草）。 此活动与系统定义活动同时进行：
  • 确定由（系统和/或利益相关者）需求代表的验证范围； 通常，应检查每个需求，因为验证操作的数量可能很高。
  • 根据限制或增加潜在验证行动的来源（技术可行性、管理限制，如成本、时间、验证手段或合格人员的可用性以及对任务至关重要的合同限制）识别限制。
  • 根据项目的最佳步骤，定义要应用的适当验证/确认技术，例如检查、分析、模拟、审查、测试等，以根据约束执行每个验证操作。
  • 在考虑所有约束或限制的同时考虑权衡应验证的内容（范围），并推断出可以客观验证的内容； 将根据系统类型、项目目标、可接受的风险和约束来选择验证措施。
  • 优化验证策略，为每个验证操作定义最合适的验证技术，根据所选验证技术定义必要的验证手段（工具、测试台、人员、位置和设施），安排项目中验证操作的执行步骤或里程碑，并定义提交给验证操作的元素的配置（这主要是关于物理元素的测试）。
• 执行验证操作，包括以下任务：
  • 详细说明每个验证操作。 特别要注意预期结果、要应用的验证技术和相应的必要手段（设备、资源和合格人员）。
  • 获取在系统定义步骤（合格人员、建模工具、模型、模拟器和设施）中使用的验证手段，然后是在集成、最终和操作步骤中使用的那些手段（合格人员、验证工具、测量设备、设施、验证程序等）。
  • 在正确的时间，在预期的环境中，使用预期的手段、工具和技术执行验证程序。
  • 捕获并记录使用验证程序和方法执行验证操作时获得的结果。
• 分析获得的结果并将其与预期结果进行比较。 确定他们是否可以接受。 记录决策和状态是否合规，并根据需要生成验证报告和潜在问题/故障报告，以及对（系统或利益相关者）需求的变更请求。
• 使用以下任务控制流程：
  • 根据项目进度更新验证计划； 特别是，计划的验证操作可能会因为意外事件而重新定义。
  • 与项目经理协调有关进度、手段、人员和资源的获取的验证活动。 与设计人员协调问题/故障/不合格报告。 与配置经理协调物理元素的版本、设计基线等。

工件和本体元素

此过程可能会创建多个工件，例如：

• 验证计划（包含验证策略）
• 验证矩阵（包含每个验证操作、提交的元素、应用技术、执行步骤、相关系统块、预期结果、获得的结果等）
• 验证程序（描述要执行的验证操作、所需的验证工具、验证配置、资源、人员、进度等）
• 验证报告
• 验证工具
• 已验证的元素
• 问题、不符合项和故障报告
• 对需求、产品、服务和企业的变更请求

这个过程利用了表 3 的本体元素。

表 3. 验证中处理的主要本体元素。 （SEBoK 原创）

方法和技术

验证技术与验证技术相同，但目的不同； 验证用于检测故障/缺陷，而验证用于证明（系统和/或利益相关者）需求的满足。

利益相关者需求定义主题中介绍了 验证 可追溯性矩阵。 它还可以扩展并用于记录数据，例如验证操作列表、用于验证每个工程元素（特别是利益相关者和系统需求）实施的选定验证技术、预期结果以及执行验证操作时获得的结果。 使用这样的矩阵使开发团队能够确保已检查选定的利益相关者和系统需求，或评估已完成验证操作的百分比。

实际考虑

与系统验证相关的关键缺陷和良好实践将在接下来的两节中描述。

缺陷

表 4 提供了在规划和执行系统验证过程中遇到的一些关键缺陷。

表 4. 系统验证的主要缺陷。 （SEBoK 原创）

成熟的实践

表 5 提供了从参考文献中收集的一些良好实践。

表 5. 经过验证的系统验证实践。 （SEBoK 原创）

以下是在实践作为系统实现的一部分讨论的任何活动时应考虑的要素：

• 混淆验证和确认是一个常见问题。 验证表明所提供的产品、服务和/或企业满足其预期用途，而验证则解决本地工作产品是否正确反映其指定需求。 验证操作使用与验证操作相同的技术（例如，测试、分析、检查、演示或模拟）。
• 说明证人将是谁（为了收集成功的证据），将遵循哪些一般步骤，以及需要哪些特殊资源，例如仪器、特殊测试设备或设施、模拟器、特定数据收集或严格论证结果分析。
• 确定测试设施、测试设备、任何独特的资源需求和环境条件、所需的资格和测试人员、将遵循的一般步骤、要收集的特定数据、收集数据的可重复性标准以及分析结果的方法。