| ·验收测试： | a) 确定一系统是否符合其验收准则且能使客户确定是否接收此系统的正式测试。
b) 使用户、客户或其他授权实体确定是否接受系统或部件的正式测试。 |
| ·部件测试： | 为验证一个软件元素(例如单元、模块)或软件元素集的设计的准确实现和对程序要求的符合性而进
行的测试。 |
| ·关键性分析： | 针对系统失效、系统老化或未能满足软件要求或系统目标所造成影响的严重性而进行的软件特性
(例如，安全性、安全保密性、复杂性和性能)的结构化评估。 |
| ·危险分析： | 对由系统开发或运行导致的软件的不良后果进行的系统定性或定量的评价。这些后果可能包括损
害、疾病、死亡、任务失败、经济损失、财产损失、环境破坏或负面社会影响。本评价可包括分类、消
除、减少或缓解危险的审查或分析方法。 |
| ·危险标识： | 认识到危险存在并定义其特性的过程。 |
| ·独立验证和确认： | 由在技术、管理和财务上与开发组织具有规定程度独立性的组织执行的验证和确认过程 |
| ·集成测试： | 有关软件程序的一种有序的、递增的测试过程，在该过程中，对软件元素、硬件元素或软硬件元素
进行组合并测试，直到整个系统集成起来以表明其是否符合程序设计及系统的能力和需求。 |
| ·完整性级别： | 项的某个特性的取值范围的一种表示，该特性取值范围对将系统风险保持在可接受的限度内是必需
的。对于执行缓解功能的项，此特性是指项必须执行缓解功能的可靠性。对于因其失效能导致威胁的项，
此特性是指对该失效的频率的限制。 |
| ·接口设计文档： | 描述系统与众多部件之间接口的体系结构和设计的文档集。这些描述包括控制算法、协议、数据内
容与格式、性能。 |
| ·接口需求规格说明： | 规定系统间或部件间接口的需求的文档集。这些需求包括对格式和计时的约束条件 |
| ·最低限度任务： | 针对所指定的软件完整性级别而要求的那些验证和确认任务 |
| ·可选任务： | 针对特定应用需求可附加到最低限度验证和确认任务的那些验证和确认任务 |
| ·要求的输入： | 执行任一生存周期活动中要求的最低限度验证和确认任务时必需的一些项 |
| ·要求的输出： | 执行任一生存周期活动中要求的最低限度验证和确认任务而产生的一些项 |
| ·风险： | 特定危险事件的频率或概率与后果的综合 |
| ·风险分析： | 系统地使用可用信息来标识危险并估计对于个人或人群、财产或环境的风险 |
| ·软件设计描述： | 为便于分析、策划、实现和决策而产生的软件的一种表示。软件设计描述可用作交流软件设计信息
的媒体，也可以认为是系统的蓝图或模型。 |
| ·软件验证和确认计划： | 描述进行软件验证和确认的计划。 |
| ·软件验证和确认报告： | 验证和确认结果和软件质量评估的文档集。 |
| ·系统测试： | 为验证和确认系统是否达到其原始目标而对集成的硬件和软件系统进行测试的活动 |
| ·确认： | 通过检查和提供客观证据，证实特定预期用途的需求是否得到满足。
注 1：在设计和开发中，确认关系到检查产品是否符合用户要求的过程。
注 2：一般是在规定的操作条件下对最终产品进行确认。在早期阶段，这样做可能也是必要的。
注 3：“已确认的”一词用来表示相应的状态。
注 4：如果有几种不同的预期用途，可进行多种确认。
注 5：特定预期用途的需求通常是指需求规格说明或合同中规定的需求。 |
| ·验证： | 通过检查和提供客观证据，证实规定的需求已经得到满足。
注 1：在设计和开发中，验证是指对某项指定活动的结果进行检查的过程，以确定该活动是否符合该活动声明的需
求。
注 2：“已验证的”一词用来表示相应的状态。 |