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

　　ICS 35 . 240 . 40 CCS A 1 1

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 40473 . 1—2021

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

　　第 1 部分：描述框架

　　Bankingapplicationsystem—Nonfunctionalrequirement—

　　part1：Frameworkfordescription

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

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

　　发

　　布

　　GB/T 40473 . 1—202 1

　　GB/T 40473 . 1—202 1

　　前 言

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

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

　　— 第 1 部分：描述框架;

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

　　— 第 3 部分：性能效率;

　　— 第 4 部分：兼容性;

　　— 第 5 部分：易用性;

　　— 第 6 部分：可靠性;

　　— 第 7 部分：安全性;

　　— 第 8 部分：可维护性;

　　— 第 9 部分：可移植性。

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

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

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

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

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

　　GB/T 40473 . 1—202 1

　　引 言

　　应用系统已经成为支撑银行业正常服务客户和内部经营管理的基础设施。 应用系统除了要实现业务部门所需的业务功能外，还有非功能需求。 在应用系统的需求研制、设计开发过程中，这些非功能需求往往引起的关注程度不够。 随着应用系统使用范围扩大、用户和交易量增加等因素，这些非功能需求会对应用系统正常发挥作用产生较大的影响，甚至导致应用系统不能发挥其预定的作用，从而对业务产生负面的影响。

　　在 ISO/IEC 24765:2017《系统和软件工程 词汇》中，明确了软件质量的概念，即“软件产品在规定

　　的条件下使用时，满足声明的或隐含的需求的能力”(capability of software product to satisfy stated and implied needs when used under specified conditions)。因此，以软件质量模型为抓手，是一种确定

　　应用系统的非功能需求的有效方法。

　　ISO 和 IEC早在 30 年前就制定了软件质量模型标准 ISO/IEC 9126:1991《软件工程 产品质量》，并自 2005 年开始，推出了新的软件产品质量需求和评估(SQuaRE) 系列标准，本文件即按照 SQuaRE系列标准中的软件产品质量提出非功能需求。 实际上，ISO/IEC 24765 : 2017 给出的软件质量定义，即

　　来自 ISO/IEC 25000:2014《系统和软件工程 系统和软件质量要求和评估(SQuaRE)—SQuaRE 指

　　南》。

　　在需求的描述方面，ISO/IEC 15408《信息工程 安全技术 针对 IT 安全的评估条件》系列标准

　　(即《Common Criteria for Information Technology Security Evaluation》，简称 CC标准)给出了方式，提

　　出了半形式化的方法，得到了业界的广泛认可，故在本文件中，对非功能需求采用了类似的组织和描述方法，并引入了与该系列标准一致的元素间的运算。

　　XML是目前得到广泛使用的信息表示方法，与纯文本相比，其具有更好的结构性，本文件中以XML作为非功能需求的逻辑陈述，以便于在可能的情况下使用信息技术手段进行进一步的处理。

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

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

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

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

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

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

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

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

　　GB/T 40473 . 1—202 1

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

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

　　GB/T 40473 . 1—202 1

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

　　第 1 部分：描述框架

　　1 范围

　　本文件给出了银行业应用系统的范畴，规定了非功能需求框架、非功能需求标识、非功能需求描述、非功能需求的定制包与定制轮廓、对非功能需求的技术管理与评价要求，以及非功能需求的 XML 描述的方式。

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

　　2 规范性引用文件

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

　　GB/T 18336 . 1—2015 信息技术 安全技术 信息技术安全评估准则 第 1 部分：简介和一般模型

　　GB/T 18793—2002 信息技术 可扩展置标语言(XML) 1 . 0

　　GB/T 25000 . 10—2016 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第 10 部分：

　　系统与软件质量模型

　　ISO/IEC 9899 : 2018 信息技术 程序设计语言 C(Information technology—Programming lan- guages—C)

　　ISO/IEC 15288 : 2015 系 统 和 软 件 工 程 系 统 生 存 周 期 过 程 ( Systems and software engineering—System life cycle processes)

　　3 术语和定义

　　下列术语和定义适用于本文件。

　　3 . 1 应用系统和需求

　　3 . 1 . 1

　　应用 application

　　应用系统 application system

　　通过计算机收集、保存、处理和展现数据的系统。

　　注：一般用“应用”这个术语来指明一个可执行的软件部件，其由一个或多个的部件、模块或子系统构成。

　　[来源：ISO/IEC 24765:2017,3 . 167]

　　3.1.2

　　需求 requirement

　　翻译或表达某种需要及相关约束和条件的陈述。

　　GB/T 40473 . 1—202 1

　　注：需求存在于不同层次，并以高层形式表达需求。 一个需求用“应”来表示，并且在使用时包括专有和适用的可选要求。 需求在交付、满足或符合时提供价值。 需求包括了提出方、客户和其他利益相关者的量化和文档化的需要、欲望和期盼。

　　[来源：ISO/IEC 24765:2017,3 . 3431]

　　3.1.3

　　功能需求 functionalrequirement

　　确定产品或过程应产生结果的陈述。

　　[来源：ISO/IEC 24765:2017,3 . 1704]

　　3.1.4

　　非功能需求 non-functionalrequirement

　　满足功能需求所需的框架条件。

　　[来源：ISO/TS 22163:2017,3 . 1 . 26]

　　3.1.5

　　内部的非功能需求 non-functionalinwardrequirement;NFIR

　　在应用系统(3 . 1 . 1)内部实现的非功能需求(3 . 1 . 4) 。

　　3.1.6

　　外部的非功能需求 non-functionaloutwardrequirement;NFOR

　　由应用系统(3 . 1 . 1)的开发、测试、运行环境实现的非功能需求(3 . 1 . 4) 。

　　3 . 2 非功能需求的组织层次

　　3.2.1

　　类 class

　　具有共同约束应用系统非功能需求某一个方面的族的集合。

　　3.2.2

　　族 family

　　一组共同约束应用系统非功能需求的某一方面，但侧重点或严格程度可能不同的组件的集合。

　　3.2.3

　　组件 component

　　包含在非功能需求中的最小可选元素集。

　　3.2.4

　　元素 element

　　不可再分的非功能需求。

　　4 应用系统的范畴

　　本文件所提及的应用系统符合 ISO/IEC 15288 : 2015 中 5 . 2 描述的系统。 应用系统包括实现这些非功能需求的软件产品(在此称为目标软件产品)和承载目标软件产品运行的目标应用系统。 目标应用系统中包含了计算机硬件、支撑或配合目标软件产品运行的软件以及与软件运行相关的数据。 目标应用系统可以是一个更大的应用系统的一个部分，该更大的应用系统还可以包括其他的应用系统、通信系统、局域网和广域网等。

　　在提出非功能需求时，应明确实现这些非功能需求的应用系统的边界。 在某些情况下，应用系统的用户不同，可能边界也不同。

　　GB/T 40473 . 1—202 1

　　5 非功能需求框架

　　5 . 1 层次划分

　　应用系统的非功能需求划分采用层次分类法分为不同的非功能需求类，并进一步划分为族、组件和元素，其体系划分方法与 GB/T 18336 . 1—2015 一致。

　　每个非功能需求类的描述方式见图 1 。

　　a 一个非功能需求的类应至少包括一个族，可包括多个族。

　　b 一个非功能需求的族应至少包括一个组件，可包括多个组件。

　　c 一个非功能需求的组件应至少包括一个元素，可包括多个元素。

　　图 1 非功能需求类的描述方式

　　每个非功能需求的类和族均单独给出概念，族中的非功能需求组件不再单独给出概念。 每个组件下列出了属于该组件的元素。 元素的层次结构描述了同一组件的元素之间的依赖关系。 若被依赖的元素对某个应用系统来说不适用，则所有依赖该元素的其他元素均不适用。

　　5 . 2 顶层分类

　　非功能需求类的划分与 GB/T 25000 . 10—2016 中质量特性的划分一致，每个类和各类中划分的族如图 2 所示。

　　GB/T 40473 . 1—202 1

　　图 2 银行业应用系统的非功能需求层次模型

　　宜在非功能需求划分的某一个级别上，与软件产品质量的特性和子特性的属性建立关联，以便于系统与软件质量要求和评价(SQuaRE)系列标准在应用系统需求、开发、测试和评估中的应用。

　　各利益相关方对非功能需求的不同方面的关注度不同，其可能关注的例子见附录 A。

　　6 非功能需求的标识

　　应用系统非功能需求采用如下方式唯一标记，格式为：

　　“类缩写”+“_”+“族缩写”+“.”+“组件编号”+“.”+“元素编号”+“.”+“元素值序号”

　　其中：

　　组件编号为自然数，从 1 开始编排;

　　元素编号为自然数，从 1 开始编排;

　　元素值序号是指一个元素可能有多个取值时的序号。 元素值序号用小写英文字母排序，当一位字母不够使用时，增加一位字母，依此类推。

　　非功能需求类缩写与族缩写见表 1 。所有的类均分为 NFIR 和 NFOR,在编码时分别在表 1 的类缩写前冠以“I”或“O”。

　　表 1 非功能需求的类缩写和族缩写

　　GB/T 40473 . 1—202 1

　　表 1 非功能需求的类缩写和族缩写(续)

　　7 非功能需求的描述

　　7 . 1 总体要求

　　非功能需求描述采用下列方式：

　　a) 非功能需求应采用文字方式描述，可采用其他方式补充，当不一致时，以文字描述为准：

　　b) 为使文字描述易于理解，可采用图形乃至原型补充，这些图形和原型用以理解非功能需求的文字，但不是非功能需求的正式组成部分：

　　c) 采用原型进行补充的，应对原型进行配置管理，并确保所有版本的可存取性。

　　7 . 2 适用性判定

　　对非功能需求的每一类、族、组件、元素，均应首先进行适用性判定，判定逻辑如下。

　　GB/T 40473 . 1—202 1

　　a) 是否已经考虑。 若未考虑，则可选择“未考虑”，且不必再考虑其下属和依赖的内容。 所有未考虑的情况均应说明理由，“认为没有必要”“没有时间考虑”“没有资源考虑”均为本文件允许的理由。

　　b) 是否可以确定。 若未确定，则可选择“未确定”，且不必再确定其下属和依赖的内容。 所有未确 定的情况均应说明理由，“不具备确定条件”“后继阶段确定”“没有时间确定”“没有资源确定”均为本文件允许的理由。

　　c) 是否能够适用。 若不适用，则可选择“不适用”，且不必再分析其下属和依赖的内容。 所有不适用的情况均应说明理由，“认为不相干”“性价比太低”“出现概率太小”“没有时间实现”“没有资源实现”均为本文件允许的理由。

　　d) 一类非功能需求为“未考虑”“未确定”和“不适用”的，其辖属的所有族均应为相同取值;一族非功能需求为“未考虑”“未确定”和“不适用”的，其辖属的所有组件均应为相同取值;一组件非功能需求为“未考虑”“未确定”和“不适用”的，其辖属的所有元素均应为相同取值;一个元素非功能需求为“未考虑”“未确定”和“不适用”的，所有依赖该元素的其他元素均应为相同取值。

　　7 . 3 非功能需求的实例化

　　7 . 3 . 1 元素内容的操作

　　对元素内容允许的操作如下，在需要时使用方头括号“【】”标记操作：

　　a) 重复：允许一个元素在相关内容变化时被使用超过一次以上;

　　b) 赋值：允许指定参数;

　　c) 选择：允许从一个列表中选定一项或多项;

　　d) 细化：允许增加细节。

　　7 . 3 . 2 重复操作

　　重复操作采用【重复：……【枚举项：……】……/* 重复体 */】的方式描述。

　　重复操作可在每个元素中使用，用于实现基于同一元素提出不同方面(指标、度量等)的需求。

　　元素每次重复操作的结果均产生一个新的非功能需求，对元素实施的每次重复操作均应进行唯 一标识。

　　7 . 3 . 3 赋值操作

　　赋值分为“描述赋值”和“指标赋值”，描述如下。

　　a) 描述赋值。 即对赋值的内容没有数字、量纲和枚举项的赋值。 采用【描述赋值：赋值的内容和要求】方式描述。 描述赋值可包括指标赋值的内容。

　　b) 指标赋值。 即对赋值的内容确定数字、量纲和集合项的赋值，包括对某一确定范围内的赋值。采用【指标赋值：赋值的数字、量纲和(或)集合项列表】方式描述。 指标赋值不应仅仅包括描述性内容。

　　7 . 3 . 4 选择操作

　　选择分为“单选”和“多选”，描述如下。

　　a) 单选。 即从多个选项中选择一个且仅选择一个的操作。 采用【单选：选项清单】方式描述。

　　b) 多选。 即从多个选项中至少选择一个且所有选中选项同时有效的操作。 采用【多选：选项清单】方式描述。

　　GB/T 40473 . 1—202 1

　　7 . 3 . 5 细化操作

　　细化操作用于对 GB/T 40473 的其他部分规定的非功能需求模板进一步展开描述，在需要细分为多种情况时，可与重复操作联合使用。 由于是否需细化和细化内容事先不能确定，故应在细化之处说明。

　　细化操作应使得应用系统在满足了细化的非功能需求后继续满足细化前的非功能需求，否则，应视作对非功能需求的扩展而不是细化。

　　对《银行业应用系统 非功能需求》的其他部分描述的非功能需求内容，只有在特定情况下才有效的，应执行细化说明有效的相关信息。

　　7 . 3 . 6 操作的嵌套关系

　　四种操作可以嵌套使用，且只要在逻辑上通顺，在应用时对嵌套关系并无限制。

　　7 . 3 . 7 操作中列项的取值

　　操作中所涉及的选择项和枚举项中列项的处置方式如下：

　　a) 在不致混淆的情况下，直接采用文字进行描述，各列项之间用逗号分隔;

　　b) 在列项中含有逗号的情况下，每个列项用双引号进行标记，各双引号标记的列项间用逗号分隔;

　　c) 在同一个操作中，直接文字描述和双引号标记的方式不准许混用。

　　7 . 3 . 8 操作中列项适用性取值

　　在对元素按本文件 7 . 2 进行适用性判定后，对元素中的描述，允许如下的特殊取值。

　　a) 重复。 重复中任何一种情况对应的要求，均可描述为“未考虑”“不适用”和“不确定”之一 。

　　b) 赋值。 任何赋值均可为“未考虑”“不适用”和“不确定”之一 。

　　c) 选择。 任何一种选择的结果，均可为“未考虑”“不适用”和“不确定”之一 。

　　d) 细化。 细化为两种以上情况的，任何一种情况均可为“未考虑”“不适用”和“不确定”之一 。

　　7 . 4 注释

　　在编制的非功能需求中，允许存在注释，以便对非功能需求的要求或相关取值进行解释。

　　非功能需求的注释不是非功能需求的组成部分，即：不要求在相关设计中实现。 GB/T 40473 的其他部分中的注释文本是正文的一部分，可以包括要求和建议。

　　非功能需求的注释采取 ISO/IEC 9899 : 2018 中 6 . 4 . 9 规定的格式，即：

　　a) 在“/*”和“*/”之间的内容作为注释，可以在任何地方应用;

　　b) 在“//”之后直到本行末的所有内容作为注释。

　　7 . 5 类、族、组件和元素的扩展

　　在银行业应用系统非功能需求给出的类、族、组件和元素不能满足对应用系统非功能需求的描述时，可按照如下规则扩展类、族、组件和元素。

　　a) 扩展应一直到元素，即便一个类仅有一个族，一个族仅有一个组件，一个组件仅有一个元素，也应分别给出元素所属的组件、组件所属的族和族所属的类。

　　b) 类和族均应给出定义，其缩写不应与本文件中现有的类和族冲突。

　　c) 类、族、组件和元素均不应与 GB/T 40473 的其他部分规定的模板中已有的类、族、组件和元素内容重叠。

　　GB/T 40473 . 1—202 1

　　8 非功能需求的定制包与定制轮廓

　　8 . 1 非功能需求的定制包

　　针对不同种类的应用系统，可在银行业应用系统非功能需求的基础上编制适用于某特定种类应用系统的非功能需求的定制包。

　　定制包应明确适用的应用系统种类及其判别方法。

　　定制包应从银行业应用系统非功能需求现有的非功能需求中进行选择，可对非功能需求进行扩充，但不应对内容进行删减或细化。

　　一个定制包中即可以包含 NFIR,也可以包含 NFOR。

　　8 . 2 非功能需求的定制轮廓

　　对一些在银行业应用系统非功能需求中仅仅提及了有关内容但并没有给出指标要求的非功能需求，在某一个范围内实施时，可在银行业应用系统非功能需求的基础上编制适用于该种类应用系统的定制轮廓。

　　定制轮廓应明确适用的应用系统种类及其判别方法，同时应明确使用的范围。

　　定制轮廓应从银行业应用系统非功能需求现有的非功能需求中进行选择，可对非功能需求进行扩充，宜对非功能需求进行细化以明确要求的指标与阈值。

　　非功能需求的定制轮廓可以对“不考虑”“不确定”和“不适用”的使用提出严于本文件的要求，明确在何种情况下不能取这些值，或若取了这些值便不符合定制轮廓的要求。

　　非功能需求的定制轮廓宜在非功能需求的定制包基础上编制，但可仅发布定制轮廓。

　　一个定制轮廓中既可以包含 NFIR,也可以包含 NFOR。

　　9 对非功能需求的技术管理与评价

　　9 . 1 对非功能需求的技术管理

　　对非功能需求的技术管理，要求如下：

　　a) 应纳入整体项目管理中;

　　b) 应与功能需求一并进行分析与评审;

　　c) 应确保非功能需求的配置管理正确，所有版本可跟踪;

　　d) 宜建立非功能需求的变更管理机制，评估并记录非功能需求的变更给应用系统带来的影响;

　　e) 宜采用 XML格式进行存储。

　　9 . 2 对非功能需求的评测

　　对非功能需求的评测，宜体现在需求、设计阶段的评审和软件编码完成后的测试两个典型阶段，要求如下。

　　a) 宜至少考虑如下评审：

　　1) 非功能需求的定制包正式发布前;

　　2) 非功能需求的定制轮廓正式发布前;

　　3) 某一具体的应用系统的非功能需求实施设计前;

　　4) 全新应用系统投产前;

　　5) 应用系统的重要变更投产前。

　　GB/T 40473 . 1—202 1

　　b) 在评审和测试的过程中，应关注取值为“不考虑”“不确定”和“不适用”的非功能需求类、族、组件、元素的是否合适。 尤其要关注在非功能需求中描述为“不确定”或“不适用”而实际非功能需求取了某种值或状态的情况。

　　c) 对已经制定了非功能需求的定制包或定制轮廓的情况，应特别关注这些定制包或定制轮廓对非功能需求的覆盖。 在需要时，可依据多个定制包或定制轮廓进行评测。

　　10 非功能需求的 XML描述

　　非功能需求采用 GB/T 18793—2002 规定的 XML语言进行逻辑描述，在适宜的情况下，也可作为物理描述。 逻辑描述的框架应符合附录 B。

　　GB/T 40473 . 1—202 1

　　附 录 A

　　(资料性)

　　各利益相关方对非功能需求的关注程度

　　非功能需求模型是一个汇集各利益相关方要求的框架。 各利益相关方主要涉及以下的用户。

　　a) 主要用户：与应用系统进行交互并达到主要目标的人。

　　b ) 次要用户：对应用系统的构建、运行、维护提供支持的人。

　　c) 内容提供者、系统管理人员、安全管理人员是次要用户，而维护人员、分析人员、移植人员、安装人员也是次要用户，但这些用户关注的内容也存在差异。

　　d) 间接用户：使用系统输出，但是不和系统进行交互的人。

　　表 A. 1 给出了非功能需求用户要求的例子。

　　表 A.1 非功能需求的用户关注内容举例

　　GB/T 40473 . 1—202 1

　　表 A.1 非功能需求的用户关注内容举例(续)

　　上述每个类型的用户在特定环境中使用应用系统时都会涉及应用系统的非功能需求，表 A. 1 中仅提供了一些例子，且没有涉及具体的应用和环境。

　　在应用系统开发或获取之前，对各利益相关方的非功能需求要求进行定义，可以为应用系统满足这些利益相关方的要求奠定良好基础，进而有利于应用系统能够良好地得到应用、改进。

　　GB/T 40473 . 1—202 1

　　附 录 B

　　(规范性)

　　非功能需求的 XML描述

　　B.1 概述

　　本附录给出了应用系统非功能需求 XML逻辑描述的方式。

　　为了保持最大程度的兼容性，本附录中 XML标签采用了英文，同时，为了便于理解，采用注释描述了 XML标签的对应中文。 非功能需求本身的注释应作为非功能需求的内容一并纳入非功能需求的描述中，而不应作为 XML 的注释。

　　B.2 应用系统的标识

　　每个应用系统应有一个唯一标识。 唯一标识的产生和维护不作为银行业应用系统非功能需求的一部分。

　　B.3 非功能需求的版本

　　每个非功能需求均应有版本控制。 参照 JR/ T 0116—2014 中 7 . 4 . 2 的要求，在银行业应用系统非功能需求中，采用如下方式进行版本的标记。

　　〈 VersionInfo 〉

　　〈 Version/〉

　　〈 Release/〉

　　〈 Edition/〉

　　〈BeginEditingDate/〉

　　〈EndEditingDate/〉

　　〈 Editor/〉 〈/VersionInfo 〉其中：

　　Version 为 2 位数字，表示编辑者认为应具有的内容版本号;

　　Release 为 2 位数字，表示发布到编辑组之外的发布版本号;

　　Edition 为 3 位数字，表示编辑流水版本号;

　　BeginEditingDate 为 4 位数字的年、2 位数字的月、2 位数字的 日;

　　EndEditingDate 为 4 位数字的年、2 位数字的月、2 位数字的 日 ;

　　Editor 为本版本编辑者的名称，可以是作者、修订者、审核者，也可以是多个人的并列。

　　B.4 类、族、组件、元素

　　类、族、组件和元素的取值，均使用第 6 章定义的缩写作为 XML 的 Tag分层进行描述。

　　B.5 对元素值的描述

　　对元素值采用如下的方式进行描述。

　　a) 当一个元素中未执行重复操作，则该元素仅有一个取值，即为取值 a。

　　b ) 当一个元素中有一个以上的重复时，按英文字母顺序增加取值。 在 1 位英文字母不够使用时，在右侧增加一位英文字母，同时左侧的英文字母重新从 a开始递增。

　　GB/T 40473 . 1—202 1

　　B.6 非功能需求的描述框架

　　非功能需求的逻辑展现基本模型示例如下，在该模型中，仅描述了一个类、一个族、一个组件下的一个元素，该元素目前仅有一个取值。

　　〈?xml version= "1.0" encoding="GB18030"?〉

　　〈 !--根元素为非功能需求 --〉

　　〈Non-FunctionRequirement〉

　　〈 !--应用系统的标识 --〉

　　〈ApplicationSystemID〉

　　000000000001

　　〈/ApplicationSystemID〉

　　〈 !--应用系统非功能需求的版本 --〉

　　〈 VersionInfo 〉

　　〈 Version〉

　　01

　　〈/Version〉

　　〈 Release 〉

　　00

　　〈/Release 〉

　　〈 Edition 〉

　　001

　　〈/Edition 〉

　　〈BeginEditingDate〉

　　20180305

　　〈/BeginEditingDate〉

　　〈EndEditingDate〉

　　20180310

　　〈/EndEditingDate〉

　　〈 Editor 〉

　　Li , Kuan

　　〈/Editor 〉

　　〈/VersionInfo 〉

　　〈 !-- 功能适宜性类功能完整性族第 1 个组件第 1 个元素的一个取值 --〉

　　〈OFS〉

　　〈OFS. FCP〉

　　〈OFS. FCP. 1〉

　　〈OFS. FCP. 1 . 1〉

　　〈 OFS. FCP. 1 . 1 .a〉

　　在【需求分析】阶段，描述应用系统功能集合的方法是【期望功能列表】。

　　〈/ OFS. FCP. 1 . 1 .a〉

　　〈/OFS. FCP. 1 . 1〉

　　GB/T 40473 . 1—202 1

　　〈/OFS. FCP . 1〉

　　〈/OFS. FCP〉 〈/OFS〉

　　〈/Non-FunctionRequirement〉

　　GB/T 40473 . 1—202 1

　　参 考 文 献

　　[1] GB/T 7027—2002 信息分类和编码的基本原则与方法

　　[2] GB/T 8566—2007 信息技术 软件生存周期过程

　　[3] GB/T 8567—2006 计算机软件文档编制规范

　　[4] GB/T 15272—1994 程序设计语言 C

　　[5] GB/T 15834—2011 标点符号用法

　　[6] GB/T 18336 . 2—2008 信息技术 安全技术 信息技术安全性评估准则 第 2 部分：安全功能组件

　　[7] GB/T 20158—2006 信息技术 软件生存周期过程 配置管理

　　[8] GB/T 30270—2013 信息技术 安全技术 信息技术安全性评估方法

　　[9] GB/T 32421—2015 软件工程 软件评审与审核

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

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

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

　　[13] JR/T 0116—2014 银行业标准化工作指南

　　[14] ISO/IEC 9126 : 1991 Software enginnering—Product quality

　　[15] ISO 9241-110 : 2006 Ergonomics of human-system interaction—Part 110: Dialogue princi- ples

　　[16] ISO/IEC 12207 : 2017 Systems and software engineering—Software life cycle processes

　　[17] ISO/IEC 15289 : 2019 Systems and software engineering—Content of life-cycle information items ( documentation)

　　[18] ISO/IEC 15408 Information technology—Security techniques—Evaluation criteria for IT security

　　[19] ISO/TS 22163 : 2017 Railway applications—Quality management system—Business man- agement system requirements for rail organizations : ISO 9001 : 2015 and particular requirements for application in the rail sector

　　[20] ISO/IEC 24765 : 2017 Systems and software engineering—Vocabulary

　　[21] ISO/IEC 25000 : 2014 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—Guide to SQuaRE