GB/T 18905.3-2002 软件工程 产品评价 第3部分：开发者用的过程

ICS35.080

L77

中华人民共和国国家标准

GB/T25000.30—XXXX

代替GB/T18905.3-2002，GB/T18905.4-2002，GB/T18905.5-2002

系统与软件工程系统与软件质量要求和

评价（SQuaRE）第30部分：质量需求框

架

Systemsandsoftwareengineering—SystemsandsoftwareQuality

RequirementsandEvaluation(SQuaRE)—Part30:Qualityrequirements

framework

(ISO/IEC25030:2007,Systemsandsoftwareengineering—Systemsand

softwareQualityRequirementsandEvaluation(SQuaRE)—Quality

requirementsframework,MOD)

（征求意见稿）

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上

XXXX-XX-XX发布XXXX-XX-XX实施

GB/T25000.30—XXXX

目次

前言III

引言IV

1范围1

2规范性引用文件1

3术语和定义1

4缩写术语4

5符合性4

6质量需求概念4

6.1总则5

6.2质量需求类型5

6.3质量需求目标5

6.4质量模型和质量需求测度6

6.5质量需求的重要考虑因素7

7质量需求过程9

7.1总则9

7.2质量需求流程概述9

7.3引出质量需求10

7.3.1确定利益相关方10

7.3.2定义利益相关者的要求11

7.4定义质量需求的步骤11

7.4.1总体描述11

7.4.2步骤的定义13

8使用和管理质量需求15

8.1实现质量需求的关键成功因素15

8.2质量需求的可追溯性16

8.3测试质量需求的关键因素16

附录A（资料性附录）推导质量要求的推荐过程17

附录B（资料性附录）质量要求映射到质量特征的例子21

附录C（资料性附录）指定质量需求的例子23

附录D（资料性附录）与ISO/IEC15288（系统生命周期过程）的关系24

附录E（资料性附录）本标准与ISO/IEC/IEEE29148标准（需求工程过程）的关系27

附录F（资料性附录）根据使用质量需求导出产品质量需求31

附录G（资料性附录）产品质量特征之间的关系示例32

附录H（资料性附录）软件质量要求的部署和可追溯性示例34

附录I（资料性附录）利益相关方-目标矩阵示例35

I

GB/T2500.30—XXXX

附录J（资料性附录）不同ICT产品所需的质量水平级别示例（使用决策表格式）37

附录K（资料性附录）IT服务质量要求39

参考文献40

II

GB/T25000.30—XXXX

前言

GB/T25000《系统与软件工程系统与软件质量要求和评价(SQuaRE)》分为如下部分：

——第1部分：SQuaRE指南；

——第2部分：计划与管理；

——第10部分：系统与软件质量模型；

——第12部分：数据质量模型；

——第20部分：测量参考模型和指南；

——第21部分：质量测度元素；

——第22部分：使用质量测量；

——第23部分：系统与软件产品质量测量；

——第24部分：数据质量测量；

——第30部分：质量需求；

——第40部分：评价过程；

——第41部分：开发方、需方和独立评价方的评价指南；

——第45部分：可恢复性的评价模块；

——第51部分：就绪可用软件产品（RUSP）的质量需求和测试细则；

——第62部分：易用性测试报告行业通用格式（CIF）。

本部分是GB/T25000的第30部分。

本部分按照GB/T1.1—2009《标准化工作导则第1部分：标准的结构和编写》给出的规则

起草。

本部分由全国信息技术标准化技术委员会（SAC/TC28）提出并归口。

本部分的起草单位：

本部分的主要起草人：

III

GB/T2500.30—XXXX

引言

作为系统、软件和数据需求的一部分，标识和规定质量需求是非常重要的，因为如同规定明确的

功能需求一样，恰当平衡的质量需求同样是满足利益相关者目标的关键成功因素。质量需求对于实施

下列各项是需要的

规约系统（包括合同签订和招标）；

规划项目（包括可行性分析）；

开发系统（包括在开发期间对体系结构驱动和潜在的质量问题的识别）；

评价系统（包括质量的客观评估和认证）。

本标准聚焦于定义、使用、管控系统和软件质量需求。如果系统和软件质量需求没有清晰的定义，

则有关的利益相关方评审、解释、实现和评价它们是很困难的，由此可导致系统与用户期望不一致且质

量低下；并且因时间和成本超出原计划以致系统返工。因此系统和软件质量需求宜在系统开发早期尽可

能清晰地规定，以对软件开发或收购提供关键的输入。

本标准对软件质量需求的制定提出要求和建议，并给出用于定义和使用它们的步骤指南，达到改进

和提升质量需求的质量。

通过使用ISO/IEC2501n系列标准中定义的质量模型将质量需求分类为特性或子特性。这些特性或

子特性的测量在ISO/IEC2502n系列标准中被定义，而这些特性或子特性可用于规定一个目标系统或数

据的质量需求并评价其质量。ISO/IEC25030:2007发布后，定义这些模型和测度的若干国际标准陆续

发布，以致造成先前的版本与这些标准产生不一致。

此外，许多系统现已深度嵌入到人们日常生活中所使用的社会基础设施中。这需要系统能达到更

高的质量；例如，互联系统需要具备可互操作性、安全性、可靠性、可维护性和可用性。

本标准的此版本是结合了SQuaRE系列标准其他分部，对质量需求分部进行了更新，并进一步给出

了定义和使用质量需求的更多实践指导。

图1阐述了SQuaRE系列国际标准的组织，其组成部分均称为分部。SQuaRE系列国际标准由五大主分

部和扩展分部组成。SQuaRE系列中各分部的概述如下。

ISO/IEC2500n-质量管理分部。构成这个分部的标准定义了SQuaRE系列标准中的所有其他标准引

用到的全部公共模型、术语和定义。这一分部还提供了用于规划和管理一个项目的要求和指南。

ISO/IEC2501n-质量模型分部。构成这个分部的标准给出了包括计算机系统和软件产品质量、使用

质量和数据的详细的质量模型。同时还提供了使用这些质量模型的使用指南。

ISO/IEC2502n-质量测量分部。构成这个分部的标准包括系统或软件产品质量测量参考模型、质量

测量的定义及其应用的使用指南。给出了软件内部质量、软件外部质量和使用质量测量的示例。定

义并给出了构成质量测量基础的质量测度元素。

ISO/IEC2503n-质量需求分部。构成这个分部的标准帮助用户规定质量需求。这些质量需求可用在

待开发的系统或软件产品的质量需求抽取过程中、为实现必要的质量的设计过程或用作评价过程的

输入。

ISO/IEC2504n-质量评价分部。构成这个分部的标准给出了无论由独立评价方、需方还是由开发方

执行的系统或软件产品的评价的要求、建议和指南。还给出了按评价模块编制质量测量文件的支持

技术。

IV

GB/T25000.30—XXXX

ISO/IEC25050到ISO/IEC25099保留用于SQuaRE的扩展国际标准，目前包括ISO/IEC25051定义

就绪可用软件（RUSP）的质量要求和测试细则，以及ISO/IEC25060至ISO/IEC25069定义通用行业格

式（CIF）的可用性系列标准。

质量模型分部

2501n

质量需求分部质量管理分部质量评价分部

2503n2500n2504n

质量测量分部

2502n

扩展分部

25050-25099

图1SQuaRE系列国际标准的组织

V

GB/T25000.30—XXXX

系统与软件工程系统与软件质量要求和评价（SQuaRE）第30部分：

质量需求框架

1范围

本标准为系统、软件产品和数据提供了质量需求的框架，包括质量需求的概念，以及抽取、定义和

管理它们的过程和方法。本标准期望的读者包括、但不限于如下：

——需方：评价系统、软件产品和数据是否符合其价值定位，如是否满足期望质量。

——开发方：设计、实现和测试系统、软件产品和数据，以确保其满足期望的质量；

——测试者：验证和确认系统、软件产品和数据是否满足期望质量；

——项目管理者：规划、监督和控制期望质量的进展；

——独立评价方：按目标准则评价系统、软件产品和数据。

本标准遵循ISO/IEC15288中定义的技术过程，其与利益相关方的质量要求的抽取有关，并且与质

量需求的分析、定义和维护有关。在本标准中，ISO/IEC25010和ISO/IEC25012中的质量模型用于对质

量需求进行分类，并依据ISO/IEC2502n质量测量分部中的质量测度为量化质量需求奠定基础。

本标准不包含其他需求（如功能需求、过程需求等）的规约。本标准不指定任何特定的软件质量测

度，也不指定特定的开发过程。

2规范性引用文件

文中提到了以下文件，其中部分或全部内容构成了本文件的要求。凡是注日期的引用文件，仅注日

期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修订）适用于本文件。

ISO/IEC25000:2014，系统与软件工程-软件产品质量要求与评价(SQuaRE)：SQuaRE指南

ISO/IEC25010:2011，系统与软件工程-软件产品质量要求与评价(SQuaRE)：系统和软件质量模型

ISO/IEC25012:2008，系统与软件工程-软件产品质量要求与评价(SQuaRE)：数据质量模型

ISO/IEC25022:2016，系统与软件工程-软件产品质量要求与评价(SQuaRE)：使用质量测量

ISO/IEC25023:2016，系统与软件工程-软件产品质量要求与评价(SQuaRE)：系统和软件产品质量

测量

ISO/IEC25024，系统与软件工程-软件产品质量要求与评价(SQuaRE)：数据质量测量

ISO/IEC15288:2015系统与软件工程系统生存周期过程

3术语和定义

ISO/IEC25000中界定的以及下列术语和定义适用于本文件。

注：为了便于阅读，ISO/IEC25000系列标准及其他ISO标准中的基础定义在这里重复列出。

3.13

分类轴classificationaxis

1

GB/T2500.30—XXXX

按特定视角分类系统和软件的映射全部范围。

[源自ISO/IECTR12182:2015]

3.2

使用环境contextofuse

特定用户在特定环境中为达到特定目的而使用ICT产品（3.8）来作为更大信息系统的一部分（3.10）

的条件和限制。

注：这里的环境不仅包括诸如设备和资源等物理方面的因素，还包括社会方面的因素，比如文化和

人口统计数据等。

3.3

部署deployment

需求部署deploymentofrequirements

按照系统分解法对需求（3.16）的分配。

3.4

导出derivation

需求的导出derivationofrequirement

在同一系统级别中将需求（3.16）从一种类型的需求转换为另一种需求。

注：需求的类型包括使用质量需求、产品质量需求和数据需求。

3.5

基于领域的需求domain-basedrequirement

起源于应用领域的需求（3.16）。

3.6

功能性需求functionalrequirement

规定系统或系统部件应完成功能的需求（3.16）。

[源自IEEE730：2014]

3.7

ICT需求ICTrequirement

通过采纳设计过程中的一些ICT技术解决方案而引出的需求（3.16）。

注：ICT技术性解决方案包括基于Web的技术、云服务器等。

3.8

ICT产品ICTproduct

使用信息和通信技术（ICTs）的产品（3.12），可以成为信息系统（3.10）的一部分。

注：图3描述了ICT产品的组成以及与信息系统的关系。

3.9

间接用户indirectuser

接收系统的输出，但是不与系统进行交互的个人。

2

GB/T25000.30—XXXX

例如执行管理者、服务需方。

[源自ISO/IEC25010:2011]

3.10

信息系统informationsystem

由软件、硬件、通信设施、数据和为满足信息处理需求而给定的环境的使用者组成的系统

注：图3描述了信息系统的组成。

3.11

主要用户primaryuser

与系统进行交互以达到主要目标的用户（3.20）。

[源自ISO/IEC25010:2011]

3.12

产品product

生成的可量化、可交付的制品，其或者是一个最终项或者是一个组件项。

注1：该定义改编自项目管理知识体系指南（PMBOK）第五版。

注2：产品包括ICT产品，软件和软件组件。

3.13

使用质量需求qualityinuse

在特定使用环境（3.2）中，使用产品、系统或服务的行为、态度性结果及后果在多大程度上满足

用户（3.20）或其他利益相关者（3.18）的要求。

3.14

质量测度

被定义为两个或多个质量测量元素值的测量函数的度量

[来源：ISO/IEC25010：2011]

3.15

质量需求qualityrequirement

对ICT产品（3.6），数据或服务的质量特性或属性、以及为满足其使用目的而产生的需求（3.16）。

注：本文档中的质量需求不涉及服务质量需求。

3.16

需求requirement

转换或表达需求及其相关约束和条件的陈述。

[源自ISO/IEC15288：2015]

3.17

次要用户secondaryuser

与产品进行交互以支持主要用户（3.11）的用户（3.20）

例如内容提供者、系统管理者、行政管理者、安全管理者、维护者、安装者。

3

GB/T2500.30—XXXX

[源自ISO/IEC/IEEE24765a:2017]

3.18

利益相关方stakeholder

对系统或系统特性有权利、共享、主张或兴趣以满足其需要和期望的个体或组织。

注1：利益相关者包括用户、开发方、测试方、项目经理、需方、独立评估方、数据拥有方、支持方、培训方、监

管机构和受该系统影响的其他人。

[源自ISO/IEC15288:2015]

3.19

技术产品质量要求technicalproductqualityrequirement

在其开发和维护过程中所使用的技术上已识别的特性的产品质量需求。

3.20

用户user

在系统使用过程中，与系统进行交互或从系统中获益的个体或组织。

[源自ISO/IEC25010:2011]

3.21

确认validation

通过提供客观证据来证实针对某一特定预期用途的需求已经得到满足。

[源自：ISO/IEC25000:2014]

3.22

验证verification

通过提供客观证据来证实规定的需求已经得到满足。

[源自：ISO/IEC25000:2014]

4缩写术语

ICT信息和通信技术

PQR产品质量需求

QIUR使用质量需求

DQR数据质量需求

SRS软件需求规范

StRS利益相关者要求规范

5符合性

声称符合本标准的任何质量需求规约，则应满足本标准第6章、第7章和第8章规定的所有要求。

6质量需求概念

4

GB/T25000.30—XXXX

6.1总则

本章描述质量需求的概念，包括定义质量需求的目标实体，以及对它们的重要考虑。

6.2质量需求类型

使用质量需求(QIURs)从利益相关方的角度指定了所需的质量等级。这些需求源于不同利益相关方

的需求。QIURs与产品在特定使用情境中的使用结果有关，并且QIURs可用作产品确认的目标。

产品质量需求(PQRs)从ICT产品的角度指定了所需的质量等级。它们中大部分源于利益相关方的

质量需求，包括QIURs，可用作目标验证和目标ICT产品的确认。技术产品质量需求是要求技术上确

定的属性（如目标规范，源代码等）满足其他PQRs。技术产品质量需求可用作开发和维护各个阶段的

验证目标。

注1：PQRs还可用于指定可交付的、不可执行的软件产品的属性，例如文档和手册。

数据质量需求（DQRs）规定了与产品相关的数据所需的质量等级。具体包括源于输入和输出产品的

QIURs和PQRs需求。DQR可用于数据方面的验证和确认。

注2：许多DQRs可以从目标产品的PQR中导出，而某些DQRs可直接来自QIURs，例如数据完整性。

6.3质量需求目标

图2显示了上述三种质量需求的范围。信息系统中对QIURs的定义，不仅包括某种ICT产品，还

包括它的用户和相关产品(例如，由ICT产品监控/控制的机器和使用ICT产品的业务流程)。PQRs根

据ICT产品或其组成部分定义（包括ICT产品子件、硬件、通信设施、软件，在某些情况下，还包括

软件组件），而DQRs根据ICT产品内部的数据定义。

QIURs

信息系统

PQRsICT产品使用情境

DQRsPQRs

软件用户其他利益相关方

软件PPQQRRss

软件

组件相关环境其他环境

PQRs

硬件&通信设备

质量要求xQRs

实体类型可以为类型A实体

类型A

定义xQRs

图2质量需求范围

图2只描述了每种质量需求类型的范围，没有描述系统层次结构，该内容在图3中正式定义。

5

GB/T2500.30—XXXX

注1：附录K描述了如何处理IT服务质量需求。

信息系统

*

信息

子系统

1..*1..*1..*1..*

ICT产品用户其他利益相关方相关环境

*

ICT组件

1..*ICT组件*ICT组件*ICT组件*ICT组件

软件数据硬件通信设施

1..*

软件组件

*

软件

子组件

由...组成

实体类

*大于或等于0

1..*大于或等于1

图3图2中使用的系统层次结构

注2：用户包括主要用户、次要用户和间接用户。见表2。

注3：“系统中的系统”可以看作是一个信息系统，它递归地包含一些辅助信息系统。

注4：一个ICT产品包括软件，还可包括数据、硬件、通信设施和其他ICT产品作为其ICT组件。

6.4质量模型和质量需求测度

通过质量模型和质量测度定义质量需求。表1显示了可用于定义每种类型质量需求的国际标准。

表1质量模型和质量需求测度

质量需求质量模型质量测度

QIURsISO/IEC25010ISO/IEC25022

使用质量需求模型使用质量测度

PQRsISO/IEC25010ISO/IEC25023

系统和软件产品质量模型系统和软件产品质量测度

DQRsISO/IEC25012ISO/IEC25024

6

GB/T25000.30—XXXX

数据质量模型数据质量测度

ISO/IEC25022,ISO/IEC25023和ISO/IEC25024以表格形式提供质量测度列表，该表按质量特征及其子

特征分类。以下信息给出表中每一项质量测度：

ID：质量测度的识别码；

名称：质量测度名称；

描述：质量测度提供的信息；

测量函数：显示质量测量元素如何组合以产生质量测度的数学公式。

注：ISO/IEC25022中列出的每项质量测度可用于测量特定使用情境中的有效性、效率、满意度和抗风险程度。

ISO/IEC25023中列出的每项质量测度可用于度量内部属性（通常是中间产品的静态测度），外部属性（通常

通过测量执行代码时的行为）或两种兼而有之。ISO/IEC25024中列出的每一项质量测度都可用于测量固有或

系统相关的属性。

6.5质量需求的重要考虑因素

6.5.1质量需求来源

应该根据ICT产品的来源来考虑两种类型的需求:基于领域的需求（直接源于利益相关方对其领域的需

求，通过需求分析过程得出）和ICT需求（通过设计过程采用某些ICT技术解决方案而引入的新需求）。

质量需求也包含同样的类型。

一个ICT需求的示例如下：采用一种基于web的系统(ICT技术解决方案)承载一些用户要求，例如在浏

览器中单击后退按钮后系统如何响应(功能要求)、用户界面的自我描述(PQR:易学性)和浏览器兼容性

(PQR)。

6.5.2ICT产品的类别

不同ICT产品之间的质量需求存在差异，因此，对于确定哪些质量特征具有更高的优先级以及应

使用哪些质量测度等问题时，考虑目标系统的类别至关重要。

ISO/IECTR12182提供了ICT产品分类的框架，包括一组示例性分类轴，在第一层中这些分类轴

用四个轴按层级组织：目标系统的架构/结构，属性，操作环境，数据和利益相关方。这些分类轴可用

于确定哪些质量特征具有更高的优先级。对于确定优先级很重要的分类轴包括：

功能（及其问题框架）；

系统和数据的重要性；

利益相关方的特征。

注：附录J列出了支持所需质量水平的IT决策的例子。

6.5.3与功能需求、数据需求的相互关系

质量需求不能与功能需求、数据需求分开定义和分析。一些质量需求附属于功能需求或数据需求；

此外，一些质量需求是通过指定新功能的需求来实现。

7

GB/T2500.30—XXXX

例1附属于功能需求的质量需求

时间效率（响应时间）定义为功能的响应时间

例2通过指定新功能的需求而实现的质量需求

一些机密性需求通过访问控制功能需求实现；

一些可学习性需求通过帮助功能需求实现；

一些可分析性需求通过记录功能需求实现。

注1：与功能需求不同，大多数质量需求表示系统的紧急属性，这些属性出现在一组组件上，而不是特定的组件上。

因此，很难建立和维护质量需求的可追溯性，也因此在整个产品生命周期中需要确信无疑地实施和验证。

产品需求不能与数据需求分开定义。ICT产品消耗并产生数据。质量需求（产品质量需求或数据质量需

求）可随系统分解发展为产品质量需求和/或数据质量需求。

注2：从ICT产品的角度来看，有三种类型的数据：外部输入和/或输出数据、内部组件存储的数据和

内部配置数据。

注3：以下是ICT产品与数据相互依赖的一个例子，以及它们的PQRs与DQRs之间的关系。

配置数据文件是为配置ICT产品而编写。它的DQRs（例如，灵活性需求）由ICT产品要满足的功

能和质量需求确定。

客户数据作为业务支持系统的输入，其质量（例如准确性）影响系统的产品质量（例如互操作性和

功能正确性）。

ICT产品的软件组件之间交换的数据及其QDRs（如效率）对ICT产品的组件实现方法和产品质量

（例如时间效率）有很大的影响。

6.5.4质量需求的导出

在大型系统的情况下，重要的是要掌握质量要求的目标实体在系统层次结构中的位置，因为质量需

求是从较高层次的实体导出到较低层次的。

图4描述了实体的每种质量需求如何在某个层级上导出其它的需求。

质量需求的主要来源是用户，包括目标实体在内的信息系统的QIURs首先从用户那里获得并形成文档。

然后它们演化为目标实体的PQRs和DQRs。其他利益相关方，如开发人员和监管机构，也对目标实体

提出了一些质量需求。最后，其他实体给出了一些需求作为目标实体的约束，包括非目标ICT产品，

连接到目标或目标中使用的软件和数据，以及在其中使用的硬件和通信。

注：一种QIUR可以导出一组功能，其中每种功能都附加了一些PQRs，例如，用户任务的效率要求可以导出一种功

能，使某些部分任务自动化，并具有时间效率要求。类似地，在将它们部署到较低级别的目标时，PQRs同样

能导出一组功能，其中每个功能都附加了一些PQRs。见6.5.3。

8

GB/T25000.30—XXXX

用户

其他利益相关方

QQIIUUss

调节器等信息系统

用用户户相关环境

其他利益相关方

PQR/

开发者，测试者等DQR

ICT产品/数据

PQR/

DQRICT产品/数据

PQR/

DQR

非目标非目标

软件/数据ICT

软件/数据

产品/数据

PQR/子系统

DQR

非目标

硬件/通信设施

硬件/通信设施

来自

xQRS

质量要求类型实体类型可以为类型A将要求作为次要输入，例如指导方针

A实体定义xQRs

将要求作为约束ICT要求

图4质量需求导出

6.5.5质量需求的权衡

质量需求之间可能存在冲突。这些冲突不可避免地产生于质量特征之间的相互关系。当某一质量特

征对另一质量特征产生负面影响时，应进行权衡以解决冲突，找到两者之间的平衡点。

注：产品质量特征之间相互关系的例子见附录G。

7质量需求过程

7.1总则

本章描述质量需求过程的要求和建议，关于如何准备、定义和分析质量需求。

7.2质量需求流程概述

应使用ISO/IEC15288中定义的与需求相关的流程来引出，定义，分析和维护质量需求：利益相关

方要求和需求定义流程以及系统需求定义流程。通过这些流程，利益相关方需求将被引出并转化为系统

需求。

注1：系统和软件产品均被视为本标准中的ICT产品。

9

GB/T2500.30—XXXX

利益相关方要求利益相关方需求系统/软件需求

ISO/IEC15288:利益相关ISO/IEC15288:系统需求

陈述/隐含/者需要和需求定义过程定义过程

未知

用于用于

利益相关者IQURsPQRs和DQRs

质量要求产品和

使用质量数据质量

模型和测量模型和测量

对于系统对于系统

通过ISO/IEC15288中

的过程进行转换StRSSyRsSRS

系统记录信息ISO/IEC29148

中定义的文件

图5从利益相关者需求到系统/软件需求

利益相关方要求和需求定义过程确定了系统在整个生命周期中涉及的利益相关方或利益相关者类

及其需求。它将这些要求分析并转换为一组共同的利益相关方需求，这些需求表达了系统与其运营环

境之间的预期交互，并且是对每个结果运营能力进行验证的参考。利用使用质量模型和测度，目标系统

的质量要求被引出，作为利益相关方的部分要求，进而转换为QUIRs，作为利益相关方的部分需求。

系统需求定义过程创建了一组可测量的系统需求，从供应商的角度来看，这些需求指定了系统要具

备哪些特征，属性，功能和性能需求，以满足利益相关者的需求。作为系统需求一部分的PQR和DQR，

也使用产品和数据质量模型和测度（模型）进行定义和分析，以满足利益相关方的需求。

注2：与ISO/IEC15288和ISO/IEC/IEEE29148的详细关系分别在附件D和附件中描述E.ISO/IEC/IEEE

29148将上述两个相关过程与ISO/IEC12207中的过程联系起来，是另一个定义软件生命周期过程的国际

标准。

注3：需求工程中的迭代和递归在ISO/IEC/IEEE29148中描述。要求，体系结构和设计过程可以迭代地应用于

系统的同一级别，以便解决需求和体系结构之间的权衡。这些过程集也可以递归地应用于系统结构内的连续

级别的系统元件，以便成功地设计超出简单复杂度的系统。

注4：一般而言，质量需求比产品生命周期中的功能需求更稳定;但它们也可以改变，例如如果添加新功能，则需

要更改安全性需求，如果环境变化甚至一点点，则必须重新考虑互操作性需求。

注5：如ISO/IEC/IEEE29148中所定义，利益相关方需求可记录在利益相关方需求规范（StRS）中，系统和软

件需求可分别记录在系统要求规范（SyRS）和软件需求规范中（SRS）。

7.3引出质量需求

7.3.1确定利益相关方

本条款涉及ISO/IEC15288中的利益相关方要求和需求定义过程，“（a）为利益相关方的要求和需

求定义作准备”活动中，确定利益相关者（见附录D）。

应确定作为质量需求潜在来源的所有利益相关方群体的代表，并在可能的情况下参与引出这些代

表。表2描述了哪种类型的利益相关方是哪种类型的质量需求的来源，用户和相关的质量需求。

10

GB/T25000.30—XX