系统验证是用于检查任何元素（如系统元素、系统、文档、服务、任务、需求等）正确性的一组操作。这些类型的操作是在系统的整个生命周期中规划和执行的。验证是一个通用术语，需要在其发生的上下文中实例化。作为一个过程，验证是系统每个生命周期阶段的横向活动。特别是，在系统开发周期内，验证过程与系统定义和系统实现过程并行执行，并适用于任何活动和活动产生的任何产品。每个生命周期过程的活动和验证过程的活动可以协同工作。例如，集成过程经常使用验证过程。重要的是要记住，验证虽然与验证分离，但旨在与验证一起执行。

定义和目的

验证是通过提供客观证据来确认特定需求已得到满足。 随着 ISO/IEC/IEEE 15288 中添加的注释，验证范围包括一组活动，这些活动将系统或系统元素与需求、架构和设计特征以及要验证的其他属性进行比较（ISO/IEC/IEEE 2015 ）。 这可能包括但不限于特定需求、设计描述和系统本身。

作为一项通用操作，验证的目的是识别在输入转换为输出时引入的故障/缺陷。 验证用于提供信息和证据，证明转换是根据选定的和适当的方法、技术、标准或规则进行的。

验证基于有形证据； 即，它基于信息的真实性，可以通过检查、测量、测试、分析、计算等技术获得的事实结果来证明。因此，验证系统（ 产品 、服务、 企业 或 系统）的过程系统 （SoS））包括将产品、服务或企业的已实现特征或属性与其预期的设计属性进行比较。

原理和概念

验证动作的概念

为什么要验证？

在人类实现的背景下，任何人类思想都容易出错。 任何工程活动也是如此。 对人类可靠性的研究表明，受过训练以执行特定操作的人员在最佳情况下每小时会犯大约 1-3 个错误。 在任何活动或活动的结果中，都不应忽视对潜在错误的寻找，无论人们是否认为它们会发生或不应该发生； 错误的后果可能导致极其严重的故障或威胁。

定义并执行 验证操作 ，如图 1 所示。

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

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

• 将对其执行验证操作的元素的标识
• 识别用于定义验证操作的预期结果的参考（参见表 1 中的参考示例）

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

• 通过对提交的元素执行验证操作来获得结果
• 将获得的结果与预期结果进行比较
• 推导元素的正确程度

要验证什么？

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

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

验证与确认

验证 一词 通常与 验证 一词相关联，并被理解为 V&V 的单个概念。 验证用于确保 一个人解决了正确的问题 ，而验证用于确保 一个人正确地解决了问题 （Martin 1997）。 从实际和词源的含义来看，验证一词来自拉丁语 verus ，意思是真理，而 facere ，意思是制造/执行。 因此，验证意味着证明某事是 真实 的或正确的（属性、特征等）。 验证一词来自拉丁文 valere ，意为变强，与 value 同源。 因此，验证意味着证明某物具有产生预期效果的正确特征。 （改编自“简单英语的验证和验证”（Lake INCOSE 1999）。）

验证过程和确认过程之间的主要区别在于用于检查元素正确性的引用以及有效正确性的可接受性。

• 在验证中，预期结果和获得的结果之间的比较通常是二元的，而在验证中，比较的结果可能需要关于是否接受与阈值或限制比较的获得的结果的价值判断。
• 验证更多地与一个元素相关，而验证更多地与一组元素相关，并将这组元素视为一个整体。
• 验证的前提是已经执行了验证操作。
• 用于定义和执行验证操作的技术与用于验证操作的技术非常相似。

系统的集成、验证和确认

有时存在一种误解，即验证发生在集成之后和验证之前。在大多数情况下，在开发或实施 期间开始验证活动并将其继续部署和使用更为合适 。

一旦实现了系统元素，它们就会被集成以形成完整的系统。 集成包括组装和执行集成过程中所述的验证操作。 最终的验证活动通常发生在系统集成时，但一定数量的验证操作也与系统集成并行执行，以减少验证操作和验证操作的数量，同时控制某些检查可能产生的风险被排除在外。 由于优化验证和确认策略以及集成策略的必要性，集成、验证和确认紧密地一起处理。

过程方法

方法的目的和原则

验证过程的目的是确认系统满足指定的设计需求。 该过程提供了实施纠正措施以纠正已实现系统中的不符合项或对其采取行动的过程所需的信息 - 参见ISO/IEC/IEEE 15288(ISO/IEC/IEEE 2015)。

每个系统元素和整个系统本身都应该与其自己的设计参考（指定需求）进行比较。 正如 Dennis Buede 所说， 验证是将 [配置项]、组件、子系统和系统与相应的需求相匹配，以确保每个都已正确构建 （Buede 2009）。 这意味着在系统的全局开发过程中，验证过程会根据需要多次实例化。 由于过程的通用性，验证过程可以应用于对系统元素和系统本身的定义和实现进行的任何工程元素。

面对常规方法可能产生的大量潜在验证动作，有必要优化验证策略。 该策略基于必须验证的内容与测试的时间、成本和可行性等约束之间的平衡，这自然会限制验证操作的数量以及排除某些验证操作时所接受的风险。

存在几种可用于定义验证过程的方法。 国际系统工程委员会 (INCOSE) 规定验证需要两个主要步骤：计划和执行验证操作 (INCOSE 2012)。 NASA 有一个稍微更详细的方法，包括五个主要步骤：准备验证、执行验证、分析结果、生成报告和捕获工作产品（NASA 2007 年 12 月，1-360，第 102 页）。 可以使用任何方法，只要它适合系统范围、项目约束、以某种方式包括下面列出的过程活动，并与其他活动适当协调。

通用输入 是提交元素的基线参考。 如果元素是一个系统，则输入是系统设计文档中描述的逻辑和物理架构元素，系统内部接口的设计描述和系统外部的接口需求，以及系统需求的扩展。 通用输出 定义了验证计划，包括验证策略、选定的验证行动、验证程序、验证工具、验证的元素或系统、验证报告、问题/故障报告和设计变更请求。

进程的活动

要建立在验证计划中起草的验证策略（此活动与系统定义活动同时进行），需要以下步骤：

• 通过列出尽可能多的应检查的特征或属性来确定验证范围。 验证操作的数量可能非常多。
• 根据限制潜在验证行动的来源（技术可行性、管理限制，如成本、时间、验证手段或合格人员的可用性以及对任务至关重要的合同限制）识别限制。
• 根据项目的最佳步骤，定义要应用的适当验证技术，例如检查、分析、模拟、同行评审、测试等，以根据给定的约束执行每个验证操作。
• 在考虑所有约束或限制的情况下，考虑对应验证的内容（范围）进行权衡，并推断出可以验证的内容； 将根据系统类型、项目目标、可接受的风险和约束来选择验证措施。
• 通过为每个验证操作定义最合适的验证技术来优化验证策略，同时根据所选验证技术定义必要的验证手段（工具、测试台、人员、位置和设施）。
• 在项目步骤或里程碑中安排验证操作的执行，并定义提交给验证操作的元素的配置（这主要涉及对物理元素的测试）。

执行验证操作包括以下任务：

• 详细说明每个验证操作； 尤其要注意预期结果、要应用的验证技术以及所需的相应手段（设备、资源和合格人员）。
• 获取系统定义步骤中使用的验证手段（合格人员、建模工具、模型、模拟器和设施），然后是集成步骤中使用的验证手段（合格人员、验证工具、测量设备、设施、验证程序等）。 ）。
• 在正确的时间，在预期的环境中，使用预期的手段、工具和技术执行验证程序。
• 捕获并记录使用验证程序和方法执行验证操作时获得的结果。

必须对获得的结果进行分析并与预期结果进行比较，以便将状态记录为 合规 或 不合规 。 系统工程 (SE) 从业者可能需要生成验证报告、潜在问题/故障报告以及必要时的设计变更请求。

控制过程包括以下任务：

• 根据项目进度更新验证计划； 特别是，计划的验证行动可能会因为意外事件而重新定义。
• 与项目经理协调验证活动：审查进度和手段、人员和资源的获取。 与设计人员协调问题/故障/不合格报告，并与配置经理协调物理元素的版本、设计基线等。

工件和本体元素

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

• 验证计划（包含验证策略）
• 验证矩阵（包含验证动作、提交元素、应用技术、执行步骤、相关系统块、预期结果、获得结果等）
• 验证程序（描述要执行的验证操作、所需的验证工具、验证配置、所需的资源和人员、时间表等）
• 验证报告
• 验证工具
• 验证元素
• 问题/不合格/故障报告
• 对设计的更改请求

此过程利用下表 2 中显示的本体元素。

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

方法和技术

有几种验证技术可以检查元素或系统是否符合其设计参考或指定需求。这些技术与用于验证 的技术几乎相同 ，尽管这些技术的应用可能略有不同。 特别是目的不同； 验证用于检测故障/缺陷，而验证用于提供满足（系统和/或利益相关者）需求的证据。 下面的表 3 提供了一些用于验证的技术的描述。

表 3. 验证技术。 （SEBoK 原创）

实际考虑

与此主题相关的主要缺陷和良好实践将在接下来的两节中描述。

缺陷

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

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

成熟的实践

表 5 提供了从参考文献中收集到的一些经过验证的实践。

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