GB/T 40473.8-2021 银行业应用系统 非功能需求 第8部分：可维护性

　　ICS 35 . 240 . 40 CCS A 1 1

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 40473 . 8—2021

　　银行业应用系统 非功能需求

　　第 8 部分：可维护性

　　Bankingapplicationsystem—Nonfunctionalrequirement—

　　part8：Maintainability

　　2021-07-20 发布 2022-02-01 实施

　　国家市场监督管理总局国家标准化管理委员会

　　发

　　布

　　GB/T 40473 . 8—202 1

　　GB/T 40473 . 8—202 1

　　前 言

　　本文件按照 GB/T 1 . 1—2020《标准化工作导则 第 1 部分：标准化文件的结构和起草规则》的规定起草。

　　本文件是 GB/T 40473《银行业应用系统 非功能需求》的第 8 部分。 GB/T 40473 已经发布了以下部分：

　　— 第 1 部分：描述框架;

　　— 第 2 部分：功能适宜性;

　　— 第 3 部分：性能效率;

　　— 第 4 部分：兼容性;

　　— 第 5 部分：易用性;

　　— 第 6 部分：可靠性;

　　— 第 7 部分：安全性;

　　— 第 8 部分：可维护性;

　　— 第 9 部分：可移植性。

　　请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别专利的责任。

　　本文件由中国人民银行提出。

　　本文件由全国金融标准化技术委员会(SAC/TC 180)归口 。

　　本文件起草单位：中国人民银行科技司、中国农业银行股份有限公司、中国外汇交易中心暨全国银行间同业拆借中心、中国人民银行清算总中心、中国建设银行股份有限公司、交通银行股份有限公司、农信银资金清算中心有限责任公司、中国金融电子化公司。

　　本文件主要起草人：李伟、杨富玉、曲维民、李宽、王鹏、马骏、王锋、杨明英、葛洪慧、崔婉昱、赵刘韬、叶昱、梁军、景芸、王灿雍、陆原鹏、杨倩、谢彦丽、刘书元、王思源。

　　GB/T 40473 . 8—202 1

　　引 言

　　GB/T 40473 给出了银行业应用系统非功能需求的描述框架和各类银行业应用系统非功能需求的模板，旨在提高银行业应用系统非功能需求的编制质量和效率，降低编制银行业应用系统非功能需求的门槛和成本，由九个部分组成。

　　— 第 1 部分：描述框架。 目的在于明确银行业应用系统的范畴，确立银行业应用系统非功能需求的描述框架，阐明银行业应用系统非功能需求的标识和描述，给出银行业应用系统非功能需求的定制包与定制轮廓，提出对银行业应用系统非功能需求的技术管理与评价，并给出银行业应用系统非功能需求的 XML描述的方法，是其余各部分阅读和应用的基础。

　　— 第 2 部分：功能适宜性。 目的在于给出包括功能完整性、功能正确性和功能适合性的功能适宜性需求，这些需求从严谨的需求分类看，可以看作是功能需求，但在银行业应用系统的研发中，往往被视作非功能需求。

　　— 第 3 部分：性能效率。 目的在于给出包括时间特性、资源利用和容量的性能效率需求。

　　— 第 4 部分：兼容性。 目的在于给出包括共存性和互操作性的兼容性。

　　— 第 5 部分：易用性。 目的在于给出包括可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性和易访问性的易用性。

　　— 第 6 部分：可靠性。 目的在于给出包括成熟性、可用性、容错性和易恢复性的可靠性。

　　— 第 7 部分：安全性。 目 的在于给出包括保密性、完整性、抗抵赖性、可核查性和真实性的安全性。

　　— 第 8 部分：可维护性。 目的在于给出包括模块性、可重用性、易分析性、易修改性和易测试性的可维护性。

　　— 第 9 部分：可移植性。 目的在于给出包括适应性、易安装性和易替换性的可移植性。

　　当不考虑缩写和编号含义时，本领域的技术人员基于本领域的专业知识，可基本正确地理解本文件的实质性内容。 但在如下典型的情况下，本文件的应用者宜先阅读并理解 GB/T 40473 . 1—2021 :

　　— 编制应用系统的非功能需求;

　　— 评审应用系统的非功能需求;

　　— 对应用系统按照非功能需求开发的系统进行验证和确认;

　　— 对应用系统按照非功能需求开发的系统进行静态和动态测试。

　　对按照本文件编制的非功能需求，若以 GB/T 40473 . 1—2021 给出的 XML 形式描述，会对非功能需求带来传输和处理上更大便利。

　　GB/T 40473 . 8—202 1

　　银行业应用系统 非功能需求

　　第 8 部分：可维护性

　　1 范围

　　本文件界定了银行业应用系统可维护性的概念，规定了可维护性元素与组件的层次及描述方式、可维护性类模块性族、可重用性族、易分析性族、易修改性族和易测试性族非功能需求模板。

　　本文件适用于银行业各类应用系统对可维护性类非功能需求的描述。 与银行业应用系统进行信息交换的应用系统，根据需要可参照使用。

　　2 规范性引用文件

　　下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。 其中，注 日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 15532—2008 计算机软件测试规范

　　GB/T 38634 . 2—2020 系统与软件工程 软件测试 第 2 部分：测试过程

　　GB/T 40473 . 1—2021 银行业应用系统 非功能需求 第 1 部分：描述框架

　　3 术语和定义

　　GB/T 40473 . 1—2021 界定的以及下列术语和定义适用于本文件。

　　3.1

　　维护性 maintainability

　　可维护性 maintainability

　　产品或系统能够被预期的维护人员修改的有效性和效率的程度。

　　注 1 ：修改包括纠正、改进或软件对环境、需求和功能规格说明变化的适应。 修改包括那些由专业支持人员实施的，以及那些由业务或操作人员、最终用户实施的。

　　注 2：维护性包括安全更新和安装升级。

　　注 3：维护性可以被解释为便于维护活动的一种产品或系统固有能力，或者为了产品或系统维护的 目标维护人员所经历的使用质量。

　　注 4：“可维护性”和“维护性”均为 maintainability 一词的中文翻译，考虑到业界惯例，在本文件中多使用可维护性一词。

　　[来源：GB/T 25000 . 10—2016,4 . 3 . 2 . 7]

　　3.2

　　模块性 modularity

　　由多个独立组件组成的系统或计算机程序，其中一个组件的变更对其他组件的影响最小的程度。 [来源：GB/T 25000 . 10—2016,4 . 3 . 2 . 7 . 1,有修改]

　　3.3

　　可重用性 reusability

　　资产能够被用于多个系统，或其他资产建设的程度。

　　GB/T 40473 . 8—202 1

　　[来源：GB/T 25000 . 10—2016,4 . 3 . 2 . 7 . 2]

　　3.4

　　易分析性 analysability

　　可以评估预期变更(变更产品或系统的一个或多个部分)对产品或系统的影响、诊断产品的缺陷或失效原因、识别待修改部分的有效性和效率的程度。

　　注：实现包括为产品或系统提供机制，以分析其自身故障以及在失效或其他事件前提供报告。

　　[来源：GB/T 25000 . 10—2016,4 . 3 . 2 . 7 . 3]

　　3.5

　　易修改性 modifiability

　　产品或系统可以被有效地、有效率地修改，且不会引入缺陷或降低现有产品质量的程度。

　　注 1 ：实现包括编码、设计、文档和验证的变更。

　　注 2：模块性(见 3 . 2)和易分析性(见 3 . 4)会影响到易修改性。

　　注 3：易修改性是易改变性和稳定性的组合。

　　[来源：GB/T 25000 . 10—2016,4 . 3 . 2 . 7 . 44]

　　3.6

　　易测试性 testability

　　能够为系统、产品或组件建立测试准则，并通过测试执行来确定测试准则是否被满足的有效性和效率的程度。

　　[来源：GB/T 25000 . 10—2016,4 . 3 . 2 . 7 . 5]

　　4 可维护性元素与组件的层次及描述方式

　　4 . 1 层次

　　可维护性各族元素与组件层次按照 GB/T 40473 . 1—2021 中 5 . 1 规定的方式，在图 1~图 3 中给出。其中，类和族的概念在本文件的术语中给出。

　　图 1 可维护性的族

　　GB/T 40473 . 8—202 1

　　图 2 可维护性的模块性族和可重用性族元素与组件层次

　　GB/T 40473 . 8—202 1

　　图 3 可维护性的易分析族、易修改族和易测试族元素与组件层次

　　4 . 2 描述方式

　　非功能需求的描述按 GB/T 40473 . 1—2021 中第 7 章给出的方式组织。

　　GB/T 40473 . 8—202 1

　　5 模块性族(MN_MDL)

　　5 . 1 内部的非功能需求(NFIR)

　　5. 1 . 1 入口检查(IMN_MDL.1)

　　IMN_MDL. 1 . 1 应用系统的模块入口对【多选：数据类型，数据长度，数据格式，【描述赋值：其他可检查的内容/* 如有多个应对本赋值执行重复操作 */】】进行检查。

　　IMN_MDL.1.2 / * 仅当 IMN_MDL.1.1 给出时适用 */【重复：应用系统对【枚举项：IMN_MDL.

　　1 . 1 中的每一个确定的选择】进行检查的方式是【描述赋值：进行检查的方式/* 在同一个内容有多种检查方法且不同时使用时，应执行细化操作，对每种检查方法的应用场景进行说明 */】。】

　　5. 1 .2 信息交换方式(IMN_MDL.2)

　　IMN_MDL. 2 . 1 【重复：【枚举项：应用系统的模块间，应用系统和其他应用系统间，应用系统和【描述赋值：其他可能的交换对象】间】通过【单选：函数，类，共享内存，共享数据库表，共享文件，管道，TCP, UDP,【描述赋值：其他交换数据的方式/* 如有多种方式本赋值执行重复操作 */】/* 如两个对象间采用了多种方式交换数据，则应采用重复操作分别说明 */】交换数据。】

　　IMN_MDL.2.2 / * 仅当 IMN_MDL.2.1 给出时适用 */【重复：【枚举项：IMN_MDL.2.1 中确定

　　的每个元素取值】作为交换数据的方式【单选：无条件，在【描述赋值：应用的条件和限制】情况下】应用。】

　　5. 1 .3 总控模块(IMN_MDL.3)

　　IMN_MDL. 3 . 1 应用系统【单选：使用自身的，使用【描述赋值：系统名称】的，不使用】总控模块进行应用逻辑的控制。

　　IMN_MDL.3.2 / * 仅当 IMN_MDL.3.1 给出时适用 */应用系统可能影响总控模块运行的模块包括【单选：无，【描述赋值：模块名称】】，影响的效果为【单选：无，导致总控模块完全停止工作，导致总控模块不能【描述赋值：其他影响效果】】。

　　IMN_MDL.3.3 / * 仅当 IMN_MDL.3. 1 给出时适用 */【重复：应用系统的总控模块【单选：采

　　用，未采用】冗余设计。 在采用冗余设计时，当【枚举项：运行总控模块的硬件故障，支撑总控模块的支撑软件故障，总控模块进程故障，总控模块线程故障，总控模块的数据库故障】时，总控模块【单选：能够正常工作，能够工作但只能承担较低的负荷，不能正常工作】。】

　　IMN_MDL. 3 . 4 应用系统内确定所处理的信息唯一性的标识，【单选：由总控模块产生，由【描述赋值：系统名称】提供，无需使用】。

　　5. 1 .4 应用系统架构(IMN_MDL.4)

　　IMN_MDL. 4 . 1 应用系统的部署架构为【单选：B/S且不需控件和插件，B/S需控件但无插件，B/S需插件但无控件，B/S且有控件和插件，C/S,服务器/哑终端，服务器/无界面，【描述赋值：其他架构】/

　　* 如有多种方式执行重复操作并分别说明应用的条件 */】。

　　IMN_MDL. 4 . 2 应用系统的数据架构为【单选：全部数据存在一个数据库中，数据存在服务器端的数据库和文件中，数据分布于多个服务器中，数据分布于服务器和客户端中，数据集中在服务器中但在外部存在需要同步的数据拷贝，部分功能需要其他应用系统的数据，全部功能需要其他应用系统的数据，【描述赋值：其他架构】/* 如有多种方式执行重复操作并分别说明应用的条件 */】。

　　5. 1 .5 系统内模块耦合(IMN_MDL.5)

　　IMN_MDL.5.1 应用系统内部的模块间存在【多选：非直接耦合/* 两模块间没有直接关系，之间

　　GB/T 40473 . 8—202 1

　　的联系完全是通过主模块的控制和调用来实现 */，数据耦合/* 一个模块访问另一模块，彼此间通过简单数据参数来交换输入、输出信息，而这里的简单数据参数不同于控制参数、公共数据结构或外部变量 */，标记耦合/* 如一组模块通过参数表传递记录信息，就是标记耦合。 这个记录是某一数据结构的子结构，不是简单变量 */，控制耦合/* 一个模块通过传递开关、标志、名字等控制信息，明显的控制选择另一模块的功能 */，外部耦合/* 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数传递该全局变量的信息 */，公共耦合/* 一组模块都访问同一个公共数据环境 。该公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等 */，内容耦合/* 一个模块直接修改另一个模块的数据，或直接转入另一个模块 */，【描述赋值：其他耦合模式】/* 如果耦合是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的耦合方法，应对执行重复操作进行说明 */】。

　　IMN_MDL.5.2 / * 仅当 IMN_MDL.5.1 给出时适用 */【重复：应用系统的【枚举项：IMN_MDL.

　　5 . 1 的每个元素取值】的模块包括【描述赋值：该类耦合的模块名称】。】

　　5. 1 .6 系统内实例耦合(IMN_MDL.6)

　　IMN_MDL. 6 . 1 应用系统在运行多个实例时，各实例间的【多选：内存数据，IP 地址，网络端口，文件，数据库记录，【描述赋值：其他相互依赖的内容】，无/* 如果依赖是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的依赖，应执行重复操作进行说明 */】存在依赖关系。

　　5 . 2 外部的非功能需求(NFOR)

　　本文件未提供模块性族外部的非功能需求模板。

　　在新识别出模块性族外部的非功能需求时，应按照 GB/T 40473 . 1—2021 中第 7 章的要求扩展和编制。

　　6 可重用性族(MN_RUS)

　　6 . 1 内部的非功能需求(NFIR)

　　6. 1 . 1 应用可重用组件(IMN_RUS.1)

　　IMN_RUS. 1 . 1 应用系统使用了企业内其他系统开发的【多选：程序动态库，程序静态库，控件， Java Bean,头文件，Jar,对象，类，接 口，函数，【描述赋值：其他可重用的可执行组件】/* 如果重用是有条件的，应对执 行 细 化 操 作 进 行 说 明;如 果 是 不 同 的 情 况 有 不 同 的 重 用，应 执 行 重 复 操 作 进 行 说明 */】，该系统的维护者包括【描述赋值：系统的维护者/* 对不同的组件有不同的维护者和同一组件有多个维护者的情况，应采用重复操作分别进行描述 */】。

　　IMN_RUS. 1 . 2 应用系统使用了企业内其他系统定义的【多选：编码，代码，数据框架，数据分布方式，【描述赋值：其他可重用的数据架构组件】/* 如果重用是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的重用，应执行重复操作进行说明 */】，该系统的维护者分别是【描述赋值：系统的维护者/* 对不同的组件有不同的维护者和同一组件有多个维护者的情况，应采用重复操作分别进行描述 */】。

　　IMN_RUS. 1 . 3 应用系统使用了企业内其他系统构建的【多选：【描述赋值：分析支撑平台名称】， 【描述赋值：开发支撑平台名称】，【描述赋值：测试支撑平台名称】，【描述赋值：运行支撑平台名称】/*如果重用是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的重用，应执行重复操作进行说明 */】，该平台的维护者分别是【描述赋值：系统的维护者/* 对不同的组件有不同的维护者和 同一组件有多个维护者的情况，应采用重复操作分别进行描述 */】。

　　GB/T 40473 . 8—202 1

　　6 . 1 . 2 提供可重用组件(IMN_RUS.2 )

　　IMN_RUS. 2 . 1 应用系统可提供企业内其他系统开发所用的【多选：程序动态库，程序静态库，控件，Java Bean,头文件，Jar,对象，类，接 口，函数，【描述赋值：其他可重用的可执行组件】，无/* 如果重用是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的重用，应执行重复操作进行说明 */】，这些可重用的开发组件的使用方式【单选：已经形成企业标准，已经形成条线技术规范，有经过评审的项目正式文档，无文档，【描述赋值：其他可确认方式】/* 如果不同的可重用组件使用情况不 一样，应对执行细化操作进行说明;如果是不同的情况进行不同的重用，应执行重复操作进行说明 */】。

　　IMN_RUS. 2 . 2 应用系统可提供企业内其他系统数据所用的【多选：编码，代码，数据框架，数据分布方式，【描述赋值：其他可重用的数据架构组件】，无/* 如果重用是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的重用，应执行重复操作进行说明 */】，这些可重用的数据架构【单选：已经形成企业标准，已经形成非标准形式技术规范，有经过评审的项目正式文档，无文档，【描述赋值：其他可确认方式】/* 如果不同的可重用组件使用情况不一样，应对执行细化操作进行说明;如果是不同的情况进行不同的重用，应执行重复操作进行说明 */】。

　　IMN_RUS. 2 . 3 应用系统可提供企业内其他系统所用的运行支撑平台是【单选：【描述赋值：运行支撑平台名称】，无。/* 如果重用是有条件的，应对执行细化操作进行说明;如果是不同的情况有不同的重用，应执行重复操作进行说明 */】，这些可重用的运行支撑平台【单选：已经形成企业标准，已经形成非标准形式技术规范，有经过评审的项 目正式文档，【描述赋值：其他可确认数据架构方式】，无文档/* 如果不同的可重用组件使用情况不一样，应对执行细化操作进行说明;如果是不同的情况进行不同的重用，应执行重复操作进行说明 */】。

　　6 . 2 外部的非功能需求(NFOR)

　　本文件未提供可重用性族外部的非功能需求模板。

　　在新识别出可重用性族外部的非功能需求时，应按照 GB/T 40473 . 1—2021 中第 7 章的要求扩展和编制。

　　7 易分析性族(MN_ANA)

　　7 . 1 内部的非功能需求(NFIR)

　　7 . 1 . 1 错误信息(IMN_ANA.1 )

　　IMN_ANA. 1 . 1 应用系统在执行中遇到错误时，返回的信息包括【多选：错误码，错误模块标识，错误语句标识，导致错误的变量，错误相关参数，【描述赋值：其他错误相关信息】】，这些信息【单选：能，不能】定位到出错的语句。

　　IMN_ANA. 1 . 2 应用系统的错误码在【单选：企业内部，本应用系统内部，应用系统的模块内部，在所有层次均不】唯一 。

　　IMN_ANA. 1 . 3 应用系统在运行中发生错误时，可能由【多选：操作系统，数据库，中间件，内部应用平台，应用系统，【描述赋值：其他可能报错的主体】】向直接用户报错。

　　IMN_ANA.1.4 / * 仅当 IMN_ANA.1.3 给出时适用 */【重复：对【枚举项：IMN_ANA.1.3 中每

　　个选中的元素取值】，报错的主体是【单选：可直接，可经分析，不能】辨别的，每一种错误引起的原因都【单选：有明确的，有轮廓的，无】文档描述，且文档的版本与程序版本【单选：一致，部分内容一致且一致的内容有标记，部分内容一致但一致的内容无标记，无对应关系】。】

　　GB/T 40473 . 8—202 1

　　7. 1 .2 现场保护(IMN_ANA.2)

　　IMN_ANA. 2 . 1 应用系统在执行中遇到错误时，保存的现场信息包括【多选：输入信息，变量值，试图操作，错误原始信息，全局变量值，环境变量值，【描述赋值：其他错误相关信息】】。

　　7 . 2 外部的非功能需求(NFOR)

　　7.2. 1 研发生命周期(OMN_ANA.1)

　　OMN_ANA. 1. 1 应用系统的【单选：人员，场地，资金，【描述赋值：其他资源】/* 各类研发资源 */】是按照【单选：瀑布，V模型，W 模型，RUP模型，Scrum模型，极限编程模型，【描述赋值：自定义模型/* 对模型进行预先定义，明确每个步骤的前导步骤、输入，明确输出和准出条件 */】，【描述赋值：随机模型/* 对模型无预定定义，根据项 目发展状况决定下一工作步骤，在相关干系人认可后形成阶段性产出 */】】。

　　OMN_ANA.1.2【重复：应用系统的【枚举项：项 目管理/* 包括在给定的资源后，通过对这些资 源的调度以达到在既定的时间产生项目干系人所期望的输出的各类活动，这些活动可能由中层管理人员主导实施 */，开发实施/* 按照项目管理要求，完成需求、设计、编码、测试、投产的各类活动，这些 活动可能由具体的业务和技术人员实施，在开发实施的各个阶段采用的模型不一样时，应采用细化操作分别说明 */】是按照【单选：瀑布，V 模型，W 模型，RUP 模型，Scrum 模型，极限编程模型，【描述赋值：自定义模型/* 对模型进行预先定义，明确每个步骤的前导步骤、输入，明确输出和准出条件 */】， 【描述赋值：随机模型/* 对模型无预定定义，根据项目发展状况决定下一工作步骤，在相关干系人认可后形成阶段性产出 */】】】。

　　7.2.2 数据建模方式(OMN_ANA.2)

　　OMN_ANA. 2 . 1 应用系统数据模型按照【单选：E/R, OO, IDEF1X,直接建表，【描述赋值：其他的数据模型构建方式】】建立，采用【单选：信息工程，IDEF1X, UML,直接建表，【描述赋值：其他的数据模型构建方式】/* 如果同时选用多种方式，应对执行细化操作说明应用的条件，并执行重复操作对每个选择进行说明 */】管理和展示。

　　OMN_ANA. 2 . 2 应用系统数据模型的【单选：实体，对象，【描述赋值：其他表示数据的基本单元】】之间的关系【单选：显式，隐式，【描述赋值：其他表示关系的方式】，未考虑】在【单选：信息工程 E/R 图， IDEF1X 图，UML 图，手工建立，【描述赋值：其他的数据间关系构建方式】】展示，在应用系统中【单选：采用，未采用】措施进行控制。/* 在采用控制措施时描述，否则以下省略 */采用的措施为【单选：数据库引擎，应用逻辑，业务报表，【描述赋值：其他表示控制数据关系的方式】/* 如果同时选用多种方式，应执行重复操作对每个选择进行说明，并对执行细化操作说明应用的条件 */】。

　　7.2.3 文档(OMN_ANA.3)

　　OMN_ANA. 3 . 1 应用系统提供【多选：需求分析规格，概要设计规格，详细设计规则，数据库设计规格，报文规格，数据字典，系统安装手册，系统运行手册，系统维护手册，投产建议书，系统应急预案， 【描述赋值：其他系统文档】】。

　　OMN_ANA.3.2 / * 仅当 OMN_ANA. 3. 1 给出时适用 */【重复：应用系统对【枚举项：OMN_

　　ANA. 3 . 1 中选定的每个元素取值/* 如果同一文档有几种不同的描述方式，应对执行细化操作进行说明，并在必要时执行重复操作描述 */】的版本控制方法为【单选：采用配置管理软件【描述赋值：配置管理软件名称】，按照标准【描述赋值：标准编号与名称】标注，【描述赋值：其他文档的版本控制方法】】，文档之间版本关系的控制方法为【单选：专家评审，专人控制，【描述赋值：其他文档的关系控制方法】】，文

　　GB/T 40473 . 8—202 1

　　档的分发方法为【单选：配置管理软件下载，文档服务器发放，电子邮件发放，移动介质发放，【描述赋值：其他的文档分发方法】】。】

　　8 易修改性族(MN_MDF)

　　8 . 1 内部的非功能需求(NFIR)

　　8. 1 . 1 系统调试(IMN_MDF.1)

　　IMN_MDF. 1 . 1 应用系统内部的调试语句在生成生产版本时【单选：通过编译开关删除，手工修改程序删除，通过单一参数控制，通过一个参数组有选择地控制，【描述赋值：其他控制方法】】，在后继应用程序发现问题需要跟踪程序时，要通过【单选：变更编译开关重新编译应用系统，手工修改程序加入调试内容，通过单一参数打开所有调试开关，通过选择参数内参数有选择地打开开关，【描述赋值：其他控制方法】】进行跟踪。

　　8. 1 .2 应用版本变更(IMN_MDF.2)

　　IMN_MDF. 2 . 1 应用系统自身进行变更时，支持【多选：自动变更平台，变更执行脚本，手工输入命令，【描述赋值：其他变更的模式】/* 如应用系统的不同组件(例如服务器端/客户端)等支持不同的变更方式，应对执行细化操作进行说明 */】。

　　IMN_MDF.2.2 / * 仅当 IMN_MDF.2.1 给出时适用 */【重复：【枚举项：IMN_MDF.2.1 中提及

　　的每一种变更模式】实施【多选：过程中，完成后，【描述赋值：可能的其他状态】】，【单选：支持，不支持】回退。】

　　8 . 2 外部的非功能需求(NFOR)

　　8.2. 1 交付构成(OMN_MDF.1)

　　OMN_MDF. 1 . 1 应用系统提供【多选：安装配置程序，可执行代码，源代码，程序中间代码，编译基础库，基础支持软件，编译脚本，压力测试数据，【描述赋值：其他系统交付构成】】。

　　OMN_MDF.1.2 / * 仅当 OMN_MDF. 1. 1 给出时适用 */【重复：应用系统对【枚举项：OMN_

　　MDF. 1 . 1 中选定的每个元素取值】的版本控制方法为【单选：采用配置管理软件【描述赋值：配置管理软件名称】，按照标准【描述赋值：标准编号与名称】标注，【描述赋值：其他文档的版本控制方法】】，分发方法为【单选：配置管理软件下载，文档服务器发放，电子邮件发放，移动介质发放，【描述赋值：其他分发方法】】。】

　　8.2.2 运行环境升级(OMN_MDF.2)

　　OMN_MDF. 2 . 1 【重复：在应用系统运行的【枚举项：计算机微码，操作系统，数据库，中间件，【描述赋值：其他支撑基础软件】】升级后，应用系统能通过【单选：直接使用原可执行代码，重新编译源代码，通过工具自动定位并自动修改源代码内容，通过工具自动定位应源代码修改的内容，【描述赋值：其他技术手段】】迁移到新的目标环境。】

　　9 易测试性族(MN_TST)

　　9 . 1 内部的非功能需求(NFIR)

　　IMN_TST. 1 . 1 应用系统【单选：已设计，未设计】测试状态交易，可以通过执行交易确定【多选：系

　　GB/T 40473 . 8—202 1

　　统接入服务器，系统应用逻辑服务器，系统数据服务器/* 在有不同的交易测试的深度不同或测试的方面有差异时，应细化操作说明情况且执行重复操作对每种情况分别进行描述 */】工作是否正常。

　　注：本条中的元素属于易测试性族中内部非功能需求的心跳检测(IMN_TST. 1)组件。

　　9 . 2 外部的非功能需求(NFOR)

　　9 . 2 . 1 测试依据(OMN_TST.1 )

　　OMN_TST.1.1 应用系统的【单选：需求定义，需求分析，概要设计，详细设计/* 对多个方面需说明的情况，应执行重复操作分别进行说明 */】交付物【单选：经过，未经】可测性分析，【单选：能，不能】作为应用系统相应阶段测试的依据。

　　OMN_TST. 1 . 2 应用系统在进行测试过程中的测试依据是【单选：测试文档，测试人员的体验，开发人员的体验，直接用户的体验，【描述赋值：其他软件测试依据】，无】/* 当不同的功能、单元的测试依据不同时，应对执行细化操作说明什么情况下是哪些依据发挥作用 */。

　　9 . 2 . 2 测试种类(OMN_TST.2 )

　　OMN_TST. 2 . 1 应用系统测试阶段按照【单选：GB/T 15532—2008, GB/T 38634 . 2—2020,【描述赋值：其他依据文献】】划分，应用系统执行【多选：单元测试，集成测试，配置项测试，系统测试，验收测试】。

　　OMN_TST. 2. 2 / * 仅当 OMN_TST. 2. 1 给出时适用 */【重复：应用系统的【枚举项：OMN_

　　TST. 2 . 1 描述的每个测试】由【多选：开发人员，专业测试人员，业务人员，直接用户，外包人员，专业第三方，【描述赋值：特定的测试人员】/* 当不同的测试人员的目的、对象等不同时，应对执行细化操作说明在哪些人执行了哪些测试 */】实施。】

　　OMN_TST. 2. 3 / * 仅当 OMN_TST. 2. 2 给出时适用 */【重复：应用系统的【枚举项：OMN_

　　TST. 2 . 2 描述的每个测试】在【多选：开发环境，测试环境，准生产环境，生产环境，【描述赋值：特定的测试环境】/* 当不同的环境测试的目的、对象等不同时，应对执行细化操作说明在哪个环境执行了哪些测试 */】中实施。】

　　OMN_TST. 2. 4 / * 仅当 OMN_TST. 2. 3 给出时适用 */【重复：应用系统的【枚举项：OMN_

　　TST. 2 . 3 描述的每个测试】包括【多选：功能测试，性能测试，安全测试，用户体验测试，【描述赋值：特定的测试类型】/* 当不同的测试类型的目的、对象等不同时，应对执行细化操作说明在哪个类型下对哪些被测试项执行了测试 */】。】

　　OMN_TST. 2. 5 / * 仅当 OMN_TST. 2. 4 给出时适用 */【重复：应用系统的【枚举项：OMN_

　　TST. 2 . 4 描述的每个测试】的目的在于【多选：试验性测试，确认与验证测试，投产测试，调优测试，【描述赋值：特定的测试目的】/* 当不同测试的目的、对象等不同时，应对执行细化操作说明为了达到不同的目的实施了哪些测试 */】。】

　　9 . 2 . 3 测试文档(OMN_TST.3 )

　　OMN_TST. 3 . 1 应用系统有【多选：测试计划，测试设计，测试用例，测试规程，测试规格，测试预案，测试日志，测试总结报告，测试综合报告，【描述赋值：其他软件测试文档】，无测试】文档，且【单选：经过，未经】评审和批准。

　　注：上述测试文档所包括的内容在 JR/ T 0101—2013 中均有详细描述，且与 GB/T 38634 . 3—2020 的技术性内容一致。

　　OMN_TST. 3 . 2 应用系统在执行测试过程中【单选：已记录，未记录】输入数据、输出结果和预期结果，故【单选：能，不能】执行精确的回归测试。

　　GB/T 40473 . 8—202 1

　　参 考 文 献

　　[1] GB/T 25000.10—2016 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第 10部分：系统与软件质量模型

　　[2] GB/T 38634 . 3—2020 系统与软件工程 软件测试 第 3 部分：测试文档

　　[3] JR/T 0101—2013 银行业软件测试文档规范