搜索结果: GB/T 25000.30-2021, GB/T25000.30-2021, GBT 25000.30-2021, GBT25000.30-2021
| 标准编号 | GB/T 25000.30-2021 (GB/T25000.30-2021) | | 中文名称 | | | 英文名称 | Systems and software engineering - Systems and software quality requirements and evaluation(SQuaRE) - Part 30: Quality requirements framework | | 行业 | 国家标准 (推荐) | | 中标分类 | L77 | | 字数估计 | 42,432 | | 发布机构 | 国家市场监督管理总局、中国国家标准化管理委员会 | GB/T 25000.30-2021
Systems and software engineering -- Systems and software quality requirements and evaluation(SQuaRE) -- Part 30: Quality requirements framework
ICS 35.080
L77
中华人民共和国国家标准
系统与软件工程
系统与软件质量要求和评价(SQuaRE)
第30部分:质量需求框架
2021-04-30发布
2021-11-01实施
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会 发 布
目次
前言 Ⅰ
引言 Ⅲ
1 范围 1
2 规范性引用文件 1
3 术语和定义 2
4 缩略语 4
5 符合性 4
6 质量需求概念 4
7 质量需求过程 5
8 使用和管控质量需求 14
附录A(资料性附录) 不同ICT产品所需的质量级别示例(使用决策表格式) 16
附录B(资料性附录) 产品质量特性之间的关系示例 18
附录C(资料性附录) 与GB/T 22032-2021(系统生存周期过程)的关系 19
附录D(资料性附录) 本部分与ISO/IEC/IEEE29148:2018(需求工程过程)的关系 21
附录E(资料性附录) 质量要求抽取的推荐过程 25
附录F(资料性附录) 利益相关方---目标矩阵示例 29
附录G(资料性附录) 质量要求映射到质量特性的示例 31
附录H (资料性附录) 从使用质量需求导出产品质量需求 33
附录I(资料性附录) 规定质量需求的示例 34
附录J(资料性附录) 质量需求到软件的部署和可追溯性示例 35
参考文献 36
系统与软件工程 系统与软件
质量要求和评价(SQuaRE)
第30部分:质量需求框架
1 范围
GB/T 25000的本部分为系统、软件产品及数据提供了质量需求的框架,包括质量需求的概念,以
及抽取、定义和管控它们的过程和方法。本部分期望的读者包括但不限于:
---需方:评价系统、软件产品和数据是否符合其价值定位,即是否满足期望的质量;
---开发方:设计、实现和测试系统、软件产品和数据,以确保其满足期望的质量;
---测试方:验证和确认系统、软件产品和数据是否满足期望质量;
---项目管理方:计划、监督和控制期望质量的进展;
---独立评价方:按客观准则评价系统、软件产品和数据。
本部分遵循GB/T 22032中定义的技术过程,其与抽取利益相关方的质量要求有关,并且与质量需
求的分析、定义和维护有关。在本部分中,GB/T 25000.10和GB/T 25000.12的质量模型用于对质量
需求进行分类,以及依照 GB/T 25000.20、GB/T 25000.21、GB/T 25000.22、GB/T 25000.23和
GB/T 25000.24中的质量测度,为量化质量需求奠定基础。
本部分不包含其他需求(如功能需求、过程需求等)的定义。本部分不规定任何特定的软件质量测
度,也不规定特定的开发过程。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 22032 系 统 与 软 件 工 程 系 统 生 存 周 期 过 程 (GB/T 22032-2021,ISO/IEC/
IEEE15288:2015,IDT)
GB/T 25000.1-2021 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第1部分:
SQuaRE指南(ISO/IEC 25000:2014,MOD)
GB/T 25000.10-2016 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第10部分:
系统与软件质量模型(ISO/IEC 25010:2011,MOD)
GB/T 25000.12-2017 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第12部分:
数据质量模型(ISO/IEC 25012:2008,MOD)
GB/T 25000.22-2019 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第22部分:
使用质量测量(ISO/IEC 25022:2016,MOD)
GB/T 25000.23-2019 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第23部分:
系统与软件产品质量测量(ISO/IEC 25023:2016,MOD)
GB/T 25000.24-2017 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第24部分:
数据质量测量(ISO/IEC 25024:2015,MOD)
ISO/IEC TR12182:2015 系统与软件工程 IT系统和分类的框架软件和应用指南(Systemand
可用于测量固有或依赖系统的属性。
6.5 质量需求的重要考虑因素
6.5.1 质量需求来源
宜根据ICT产品的来源来考虑两种类型的需求:基于领域的需求(在需求分析过程中,根据利益相
关方在其所属领域的要求而直接得到的)和ICT需求(在设计过程中因采用某些ICT技术解决方案而
引入的新需求)。质量需求也包含同样的类型。
例如:采用一种基于web的系统(ICT技术解决方案)涉及一些用户需求,例如在浏览器中单击后
退按钮后系统如何响应(功能要求)、用户界面的自我描述(PQR:易学性)和浏览器兼容性(PQR)。
6.5.2 ICT产品的类别
不同ICT产品之间的质量需求存在差异,因此,对于确定哪些质量特性具有更高的优先级以及宜
使用哪些质量测度等问题时,考虑目标系统的类别至关重要。
ISO/IEC TR12182提供了ICT产品分类的框架,包括一组典型的分类轴,在第一层中这些分类轴
按层级组织为五个轴:目标系统的架构/基础结构,属性,运行环境,数据和利益相关方。这些分类轴可
用于确定哪些质量特征具有更高的优先级。对于确定优先级非常重要的分类轴包括:
a) 功能(及其问题框架);
b) 系统和数据的关键点;
c) 利益相关方的特征。
注:附录A列出了支持所需质量级的IT决策的例子。
6.5.3 与功能需求/数据需求的相互关系
质量需求不能与功能需求、数据需求分开定义和分析。一些质量需求附属于功能需求或数据需求;
此外,一些质量需求通过规定新的功能需求实现。
示例1:附属于功能需求的质量需求:
时间效率(响应时间)定义为功能的响应时间。
示例2:通过规定新的功能需求而实现的质量需求:
a) 一些保密性需求通过访问控制功能需求实现;
b) 一些易学性需求通过帮助功能需求实现;
c) 一些易分析性需求通过记录功能需求实现。
注1:与功能需求不同,大多数质量需求表示系统的紧急属性,这些属性出现在一组组件上,而不是某个特定的组件
上。因此,很难建立和维护质量需求的可追溯性,也因此在整个产品生存周期中需要确信无疑地实施和验证。
产品需求不能与数据需求分开定义。ICT产品消耗并产生数据。质量需求(产品质量需求或数据
质量需求)可随系统分解发展为产品质量需求/数据质量需求。
注2:从ICT产品的角度来看,有三种类型的数据:外部输入和/或输出数据、内部组件存储的数据和内部配置数据。
注3:以下是ICT产品与数据相互依赖的一个例子,以及它们的PQR与DQR之间的关系:
a) 配置数据文件为配置ICT产品而编写。它的DQR(例如,灵活性需求)由ICT产品需要满足的功能和质量需求
确定;
b) 客户数据作为业务支持系统的输入,其质量(例如,准确性)影响系统的产品质量(例如,易操作性和功能正确
性);
c) ICT产品的软件组件之间交换的数据及其DQR(例如,效率)对ICT产品的组件实现方法和产品质量(例如,时
间效率)有很大的影响。
7.2 质量需求过程概述
应使用GB/T 22032中定义的与需求相关的“利益相关方要求和需求定义过程”和“系统需求定义
过程”来抽取,定义,分析和维护质量需求,通过图5中的过程,利益相关方的要求将被抽取并转化为系
统需求。
注1:系统与软件产品均被视为本部分的ICT产品。
利益相关方要求和需求定义过程标识了系统在整个生存周期中涉及的利益相关方或一类利益相关
方及其要求。它将这些要求分析并转换为一组共同的利益相关方需求,这些需求表达了系统与其运行
环境之间的预期交互,并且是对每个结果运行能力进行验证的基准。对于目标系统,利用使用质量模型
和测度,将作为利益相关方的部分要求的质量要求被抽取,进而转换为QUIR,作为利益相关方的部分
需求。
系统需求定义过程创建了一组可测量的系统需求,从供方的角度来看,这些需求指定了系统要具备
哪些特性、属性、功能和性能需求,以满足利益相关方的需求。为满足利益相关方的需求,使用产品和数
据质量模型和测度,来定义和分析作为系统需求一部分的PQR和DQR。
注2:与GB/T 22032和ISO/IEC/IEEE29148的详细关系分别在附录C和附录D中描述。ISO/IEC/IEEE29148
将上述两个相关过程与ISO/IEC 12207(另一个定义软件生存周期过程的国际标准)中的过程联系起来。
注3:需求工程中的迭代和递归在ISO/IEC/IEEE29148中描述。要求、体系结构和设计过程可以迭代地应用于系
统的同一级,以便解决需求和体系结构之间的权衡。该过程集也可以递归地应用于系统结构内的连续层级的
系统元素,以成功地将系统工程化繁为简。
注4:一般而言,在产品生存周期中质量需求比功能需求更稳定;但它们也可以改变,例如,如果添加了新功能,则需
要更改安全性需求,如果环境变化甚至一点点,则必须重新考虑易操作性需求。
注5:按照ISO/IEC/IEEE29148的定义,利益相关方需求可记录在StRS中,系统与软件需求可分别记录在SyRS
和SRS中。
7.3 质量要求抽取
7.3.1 标识利益相关方
本条涉及用GB/T 22032中的利益相关方要求和需求定义过程的活动a)“准备利益相关方的要求
和需求定义”来标识利益相关方(参见附录C)。
应确定作为质量需求潜在来源的所有利益相关方群体的代表,并在可能的情况下参与抽取这些代
表。表2描述了哪种类型的质量需求来源于哪种类型的利益相关方和用户。
表2 利益相关方和质量需求的类型
质量需求的用户(开发方,需方/独立评价方等)有责任建立和维护质量需求,因此他们宜考虑与社
会相关的抗风险需求,哪些(谁应是)是受系统影响的群体,哪些不能直接成为需求的来源。
注:利益相关方可被视为一个角色,因此一个人或组织可以拥有多个角色。此外,利益相关方不应属于特定类型的
组织。例如,在开发消费者产品的例子中,需方和开发方可以属于同一家公司,以考虑受系统影响的人的任何
风险。
7.3.2 定义利益相关方的要求
本条涉及GB/T 22032中的利益相关方要求和需求定义过程的活动b)“定义利益相关方要求”(参
见附录C)。
应从已标识的利益相关方中提取目标信息系统的假定使用周境和在该使用周境下的质量要求。如
果现有系统存在,则还应从分析利益相关方使用该系统的经验反馈分析中提取。
注1:附录E提供了一个质量要求抽取的推荐过程。
注2:在这种情况下,质量要求主要与使用质量有关。
注3:利益相关方的要求不仅包括明确陈述的内容,还包括隐含的或未知的内容。为了在特定的使用周境中详尽地
抽取相关的利益相关方要求,可以使用利益相关方-目标矩阵,如附录F所示。
对所抽取的利益相关方的质量要求宜优先考虑并在此基础上进行选择,其中应考虑ICT产品的类
别(6.5.2),以确定哪些是对目标实体重要的质量特性。
注4:由于不同的利益相关方对目标系统有不同的要求,因此利益相关方的要求可能不一致和/或不完整;因此,应
检查所有准备好的要求,以定义、分析和维护一组利益相关方的需求。
注5:由于某些商业原因,并非所有利益相关方要求可选作定义利益相关方需求。例如,软件包软件提供商能够在
权衡开发成本和对市场的影响后,决定不选择在软件包中实现某些用户的要求。
注6:对于消费产品,可以使用市场细分技术识别共享共同需求和偏好的用户子群体。
需方的质量要求可以记录为其利益相关方要求的一部分,以及其所有者和必要的证据。
7.4 定义质量需求步骤
7.4.1 总体描述
宜明确清楚地定义质量需求,并在适当情况下,定量地定义质量需求,以免出现依赖于理解上的主
观判断和无法证实的需求。
图6为定义了用于此目的的所有类型的质量需求的步骤。
这些步骤涉及GB/T 22032中的以下过程和活动(参见附录C):
需求定义过程:
a) 将利益相关方的要求转化为利益相关方的需求;
b) 分析利益相关方的需求。
系统需求定义过程:
a) 准备定义系统需求;
b) 定义系统需求;
c) 分析系统需求。
基于从利益相关方(包括来自现有系统的反馈)以及系统层次更高层次的QIUR,PQR和DQR中
获得的质量要求,定义、分析和记录QIUR/PQR/DQR。
通常,这些步骤以迭代和递归方式应用。当它们以递归方式应用于目标实体时,这些步骤宜应用于
实体内的所有ICT产品和数据,以实现目标实体质量所需的进一步管理活动。
注1:从管理角度来看,定义QIUR先于定义PQR/DQR,这对于开发定制产品非常合理,但实际上,对于消费产品,
通常情况下首先定义PQR/DQR,然后定义QIUR来评价运行情况下的目标实体。
为了满足某些PQR,在PQR定义步骤的迭代中,宜定义技术PQR,以便它们可以用作各个开发阶
段的验证目标。
在递归应用这些步骤的过程中,宜考虑某些功能需求来自某些质量要求(6.5.3)。
注2:实际上,上述步骤的递归应用通常是同时进行的。例如,下一次递归能够是构成目标ICT产品的子ICT产品
和数据(6.5.4)。
注2:ISO/IEC 25065规定了在记录用户需求时使用的格式和语法,包括与用户相关的质量需求,其中能够包括使
用质量需求。
注3:由于大多数采用测量方法的质量测度已在 GB/T 25000.22-2019,GB/T 25000.23-2019和 GB/T 25000.
24-2017中定义,因此质量需求中使用的质量测度不一定要从头开始定义,可从这些标准中选择。
注4:根据业务或管理需要,不同的利益相关方能够有不同的目标值。
注5:监管机构可以为某些目标值设置最小/最大限制。
f) 分析质量需求
从以下角度分析质量需求以确认它们:
1) 是否符合其来源的原始要求和需求;
2) 是否与其他质量需求和约束保持一致;
3) 是否可以验证;
4) 是否可行。
并解决所发现的问题。
注1:质量需求权衡见6.5.5并参见附录B。
如果发现质量需求之间的冲突和矛盾,宜根据其给定的优先级在它们之间找到适当的平衡来解决。
在此步骤中,还应对每个质量需求进行风险分析,以识别和解决质量需求可能带来的风险。应考虑
人类、经济、健康、安全和环境风险,以选择适用于该问题的特定类别。应评价质量需求是否能够如预期
的那样充分降低更高级别的系统风险。
注2:为了执行风险分析需求,工程师可以与用户一起识别特定于每个质量需求的业务相关风险,此外,与开发人员
一起识别特定于质量需求的技术风险。
g) 管理质量需求
首先,获得有关这些QIUR和PQR/DQR的明确协议,并且宜得到所有利益相关方组织的批准。
其次,建立并保持所定义的质量需求与其来源(质量要求,QIUR,PQR和更高级别的DQR)之间的
可追溯性。
最后,如果确定需要改进质量需求,则迭代执行所有步骤。
8 使用和管控质量需求
8.1 实现质量需求的关键因素
应根据系统的使用周境和设计权衡来选择目标实体的质量需求,并据此对其按照优先级排序。同
时,应根据满足利益相关方目标的关键因素来选择确定要验证或确认的目标实体的质量需求,并据此对
其按照优先级排序。
注1:质量需求实现两个目的:a)指导预期能够满足质量需求的设计解决方案并对其按优先级排序;b)提供可评估
的验收标准。
由于在实际中最小化开发成本和开发时间也很重要,因此质量需求的实现、验证和确认的整个过程
宜既有效又高效,在某些情况下,需要进行折中考虑。因此,建议采用一种基于风险的质量需求分析方
法,包括以下步骤:
a) 评价每个质量需求,并优先考虑以下几点:
---重要性:对关键的利益相关方的义务,以及对社会、商业、人类生活和/或环境的重要程度。
---影响:由于返工对开发和维护过程所造成的影响。
b) 验证和确认质量需求的计划活动及执行要点(在开发阶段),并估算其成本和效果。此类活动
包括测试、检查、原型设计、采纳有效的设计方法,迭代过程等。
c) 对每个高优先级的质量需求,对需求未实现的风险与采取行动以避免风险发生的成本两者之
间进行权衡。如果采取行动被认为具有成本优势,那么就采纳这些行动并将其纳入开发计划。
注2:当产品包含数据库管理系统(DBMS)软件组件时,由其处理的数据的DQR大大简化,甚至不存在。
8.2 质量需求的可追溯性
应在产品的整个生存周期内维护和再确认质量需求和ICT组件之间的双向可追溯性:
a) 产品设计,实现和评估等制品要素;
b) 利益相关方的需求和系统需求。
在产品开发生存周期中实现PQR/DQR可追溯性的示例:
a) 功能需求;如,安全需求以及实现安全需求的访问控制功能;
b) 体系结构;如,容错需求和实现容错需求的结构;
c) 所部署组件的PQR/......
|