可用于测量固有或依赖系统的属性

可用于测量固有或依赖系统的属性

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

6.5.1质量需求来源

旅游标准GB/T25000.302021

宜根据ICT产品的来源来考虑两种类型的需求：基于领域的需求（在需求分析过程中，根据利益相 关方在其所属领域的要求而直接得到的）和ICT需求（在设计过程中因采用某些ICT技术解决方案而 引人的新需求）。质量需求也包含同样的类型。 例如：采用一种基于web的系统（ICT技术解决方案）涉及一些用户需求，例如在浏览器中单击后 退按钮后系统如何响应（功能要求）、用户界面的自我描述（PQR：易学性）和浏览器兼容性（PQR）

6.5.2ICT产品的类别

不同ICT产品之间的质量需求存在差异，因此，对于确定哪些质量特性具有更高的优先级以及宜 更用哪些质量测度等问题时，考虑目标系统的类别至关重要 ISO/IECTR12182提供了ICT产品分类的框架，包括一组典型的分类轴，在第一层中这些分类轴 按层级组织为五个轴：目标系统的架构/基础结构，属性，运行环境，数据和利益相关方。这些分类轴可 用于确定哪些质量特征具有更高的优先级。对于确定优先级非常重要的分类轴包括： a）功能（及其问题框架）； b）系统和数据的关键点； c）利益相关方的特征。 注：附录A列出了支持所需质量级的IT决策的例子

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

质量需求不能与功能需求、数据需求分开定义和分析。一些质量需求附属于功能需求或数据需求； 比外，一些质量需求通过规定新的功能需求实现。 示例1：附属于功能需求的质量需求： 时间效率（响应时间）定义为功能的响应时间。 示例2：通过规定新的功能需求而实现的质量需求： a）一些保密性需求通过访问控制功能需求实现； b）一些易学性需求通过帮助功能需求实现； c）一些易分析性需求通过记录功能需求实现， 注1：与功能需求不同，大多数质量需求表示系统的紧急属性，这些属性出现在一组组件上，而不是某个特定的组件 上。因此，很难建立和维护质量需求的可追溯性，也因此在整个产品生存周期中需要确信无疑地实施和验证。 产品需求不能与数据需求分开定义。ICT产品消耗并产生数据。质量需求（产品质量需求或数据 质量需求）可随系统分解发展为产品质量需求/数据质量需求 注2：从ICT产品的角度来看，有三种类型的数据：外部输入和/或输出数据、内部组件存储的数据和内部配置数据 注3：以下是ICT产品与数据相互依赖的一个例子，以及它们的PQR与DQR之间的关系： 配置数据文件为配置ICT产品而编写。它的DQR（例如，灵活性需求）由ICT产品需要满足的功能和质量需求 确定； 客户数据作为业务支持系统的输人，其质量（例如，准确性）影响系统的产品质量（例如，易操作性和功能正确 性）； ） ICT产品的软件组件之间交换的数据及其DQR(例如，效率）对ICT产品的组件实现方法和产品质量（例如，时 间效率）有很大的影响

GB/T25000.302021

和需求定义”来标识利益相关方（参见附录C）。 应确定作为质量需求潜在来源的所有利益相关方群体的代表，并在可能的情况下参与抽取这些代 表。表2描述了哪种类型的质量需求来源于哪种类型的利益相关方和用户

表2利益相关方和质量需求的类型

质量需求的用户（开发方，需方/独立评价方等)有责任建立和维护质量需求，因此他们宜考虑与社 会相关的抗风险需求，哪些（谁应是）是受系统影响的群体，哪些不能直接成为需求的来源。 注：利益相关方可被视为一个角色，因此一个人或组织可以拥有多个角色。此外，利益相关方不应属于特定类型的 组织。例如，在开发消费者产品的例子中，需方和开发方可以属于同一家公司，以考虑受系统影响的人的任何 风险

7.3.2定义利益相关方的要求

本条涉及GB/T22032中的利益相关方要求和需求定义过程的活动b）“定义利益相关方要求”（参 见附录C）。 应从已标识的利益相关方中提取目标信息系统的假定使用周境和在该使用周境下的质量要求。如 果现有系统存在，则还应从分析利益相关方使用该系统的经验反馈分析中提取。 注1：附录E提供了一个质量要求抽取的推荐过程。 注2：在这种情况下，质量要求主要与使用质量有关 注3：利益相关方的要求不仅包括明确陈述的内容，还包括隐含的或未知的内容。为了在特定的使用周境中详尽地 抽取相关的利益相关方要求，可以使用利益相关方一目标矩阵，如附录F所示。 对所抽取的利益相关方的质量要求宜优先考虑并在此基础上进行选择，其中应考虑ICT产品的类 别（6.5.2），以确定哪些是对目标实体重要的质量特性 注4：由于不同的利益相关方对目标系统有不同的要求，因此利益相关方的要求可能不一致和/或不完整；因此，应 检查所有准备好的要求，以定义、分析和维护一组利益相关方的需求。 注5：由于某些商业原因，并非所有利益相关方要求可选作定义利益相关方需求。例如，软件包软件提供商能够在 权衡开发成本和对市场的影响后，决定不选择在软件包中实现某些用户的要求。 注6：对于消费产品，可以使用市场细分技术识别共享共同需求和偏好的用户子群体。 需方的质量要求可以记录为其利 爱水 一部分，以及其所有者和必要的证据

7.4定义质量需求步骤

宜明确清楚地定义质量需求，并在适当情况下，定量地定义质量需求，以免出现依赖于理解上的主 10

GB/T25000.302021

观判断和无法证实的需求。 图6为定义了用于此目的的所有类型的质量需求的步骤。 这些步骤涉及GB/T22032中的以下过程和活动（参见附录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)

观判断和无法证实的需求。 图6为定义了用于此目的的所有类型的质量需求的步骤。 这些步骤涉及GB/T22032中的以下过程和活动（参见附录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)

GB/T25000.302021

高级别的每个QIUR，PQR和DQR，确定目标实体实现它们所需的质量特性（以及如何实现它们）。 ，使用GB/T25000.10一2016中定义的质量模型进行QIUR和PQR的分类。同样，对于DQR，使 GB/T25000.12一2017中定义的质量模型。 注1GB/T25000.10—2016和GB/T25000.12—2017能够通过提供定制模型和标准模型之间的映射和定制基础 来定制质量模型。附录G中可以找到定制模型和标准模型之间映射的示例。 注2：系统层次结构较高层次的质量需求包括额外的PQR和源自ICT需求的DQR（6.5.1）。 注3：当从较高级别的系统层次结构的QIUR，PQR和DQR中推导出目标实体的质量需求时，详尽地检查质量模型 的所有特性/子特性可以防止错过重要的质量需求。 注4：附录H给出了一个从QIUR导出PQR的示例。 明确所选质量特性的质量需求 对所选的质量特性明确质量需求，以便可以清楚地理解以下项目： 1）目标实体； 重要的质量特性/子特性； 用户和任务（仅限QIUR）； 4）有条件的质量目标。 注：表3示出了特定系统的“明确PQR的示例

表3“明确POR”的示例

d）指定质量需求优先顺序 根据其对利益相关方的重要性和影响来确定导出的质量需求的优先顺序（重要性和影响在8.1中 论）。 注：与功能性需求不同，有许多方法可以在更高级别系统层次结构实现QIUR/PQR/DRQ，因此从它们导出的质量 需求可以是多个候选项的可选组合，并且它们也可能具有某种灵活的可接受范围。因此，有必要根据其重要性 级别和影响对导出质量需求进行优先排序，以便可以适当地选择和定义它们。 e）使用质量测度和所需的准则规定质量需求 将每个质量声明转换为包含如下项的质量需求： 1）目标实体； 2） 所选的特性； 3） 用户和任务（仅限QIUR）； 4） 有条件的质量目标； 5）质量测度； 6） 目标值； 7） 可接受值的范围。 对QIUR使用GB/T25000.22一2019，对PQR使用GB/T25000.23一2019，对DQR使用 B/T25000.24一2017来规定质量测度。 注1.附录工提供了规定质量需求的一个示例

GB/T 25000.30=2021

注2：ISO/IEC25065规定了在记录用户需求时使用的格式和语法，包括与用户相关的质量需求，其中能够包括使 用质量需求。 注3：由于大多数采用测量方法的质量测度已在GB/T25000.22一2019，GB/T25000.23一2019和GB/T25000. 24一2017中定义，因此质量需求中使用的质量测度不一定要从头开始定义，可从这些标准中选择。 注4：根据业务或管理需要，不同的利益相关方能够有不同的目标值 注5：监管机构可以为某些目标值设置最小/最大限制。 f）分析质量需求 从以下角度分析质量需求以确认它们： 1 是否符合其来源的原始要求和需求； 是否与其他质量需求和约束保持一致； 是否可以验证； 4） 是否可行。 并解决所发现的问题。 注1：质量需求权衡见6.5.5并参见附录B。 如果发现质量需求之间的冲突和矛盾，宜根据其给定的优先级在它们之间找到适当的平衡来解决。 在此步骤中，还应对每个质量需求进行风险分析，以识别和解决质量需求可能带来的风险。应考虑 人类、经济、健康、安全和环境风险，以选择适用于该问题的特定类别。应评价质量需求是否能够如预期 的那样充分降低更高级别的系统风险 注2：为了执行风险分析需求，工程师可以与用户一起识别特定于每个质量需求的业务相关风险，此外，与开发人员 一起识别特定于质量需求的技术风险。 g）管理质量需求 首先，获得有关这些QIUR和PQR/DQR的明确协议，并且宜得到所有利益相关方组织的批准。 其次，建立并保持所定义的质量需求与其来源（质量要求，QIUR，PQR和更高级别的DQR）之间的 可追溯性。 最后，如果确定需要改进质量需求，则迭代执行所有步骤

注2：ISO/IEC25065规定了在记录用户需求时使用的格式和语法，包括与用户相关的质量需求，其中能够包括使 用质量需求。 注3：由于大多数采用测量方法的质量测度已在GB/T25000.22一2019，GB/T25000.23一2019和GB/T25000. 24一2017中定义，因此质量需求中使用的质量测度不一定要从头开始定义，可从这些标准中选择。 注4：根据业务或管理需要，不同的利益相关方能够有不同的目标值。 注5：监管机构可以为些目标值设置量小/最大限制

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

应根据系统的使用周境和设计权衡来选择目标实体的质量需求，并据此对其按照优先级排序。同 时，应根据满足利益相关方目标的关键因素来选择确定要验证或确认的目标实体的质量需求，并据此对 其按照优先级排序。 注1：质量需求实现两个目的：a)指导预期能够满足质量需求的设计解决方案并对其按优先级排序；b)提供可评估 的验收标准。 由于在实际中最小化开发成本和开发时间也很重要，因此质量需求的实现、验证和确认的整个过程 宜既有效文高效，在某些情况下，需要进行折中考虑。因此，建议采用一种基于风险的质量需求分析方 法，包括以下步骤： a）评价每个质量需求，并优先考虑以下几点： 重要性：对关键的利益相关方的义务，以及对社会、商业、人类生活和/或环境的重要程度 一影响：由于返工对开发和维护过程所造成的影响。 b 验证和确认质量需求的计划活动及执行要点（在开发阶段），并估算其成本和效果。此类活动 包括测试、检查、原型设计、采纳有效的设计方法，送代过程等。 C 对每个高优先级的质量需求，对需求未实现的风险与采取行动以避免风险发生的成本两者之 间进行权衡。如果采取行动被认为具有成本优势，那么就采纳这些行动并将其纳入开发计划。

8.2质量需求的可追溯性

GB/T25000.302021

应在产品的整个生存周期内维护和再确认质量需求和ICT组件之间的双向可追溯性： a）产品设计，实现和评估等制品要素； b）利益相关方的需求和系统需求。 在产品开发生存周期中实现PQR/DQR可追溯性的示例： a）功能需求；如，安全需求以及实现安全需求的访问控制功能； b 体系结构；如，容错需求和实现容错需求的结构； C 所部署组件的PQR/DQR；如，软件的响应时间需求和软件组件的响应时间需求； d）设计过程中的原则；如，安全需求和实现安全需求的安全编码原则。 注：参见附录「中一个实现开发阶段质量需求可追溯性的示例

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

GB/T25000.302021

GB/T25000.302021

本附录提供了任何两种产品质量特性之间关系的示例。 表B.1显示了产品质量特性之间可能存在的关系的示例

表B.1产品质量特性之间的关系示例

对表格的每一行给出以下解释： 添加一些功能以获得更好的功能完备性（功能性特性）需能够导致所有其他质量特性的质量问题。 提高某些组件的可靠性（成熟性）有助于实现整个系统的信息安全性和维护性。 实现一组功能的性能效率（时间效率）需求，能够带来更好的易用性（功能的易操作性），同时它 能够导致更差的维护性（可重用性，组件的模块化）。 实现更好的用户差错防御性的无限撤销功能，需要大量内存用于其撤销缓冲区（性能效率一资 源利用性），并且可能增加从缓冲区窃取某些信息的可能性（信息安全一保密性）。 获得更好的信息安全性能够对其他特性造成负面影响，例如，引人过多认证会严重影响易用性 （易操作性）。 增加与其他系统的互操作性能够通过与它们协作来提高功能性特性，同时它也能够导致一些 性能效率问题，并且由于其繁重且易受攻击的通信协议能够引人一些安全漏洞 通过使用简单的流接口实现更好的易测试性，需要额外的文本处理计算时间（性能效率一时间 效率），能够通过接口轻松操作信息（信息安全性验证），同时它能够有助于简化初始测试，使安 装更顺畅。 在许多平台上实现更好的适应性，能够在某些平台上引起一些性能和安全问题，同时它能够促 进更好的兼容性（互操作性）。 注：关系并不总是对称的。 要找出两个需求之间的冲突，应检查显示需求质量特性之间关系的两个单元格

GB/T25000.302021

表C.1示出了本文档中定义质量需求的步骤与GB/T22032一2021中定义的需求相关过程之间 系

表C.1本部分中质量需求的步骤与GB/T22032一2021中需求相关过程之间的关系

GB/T25000.302021

表D.1给出了ISO/IEC/IEEE29148:2018中需求类型属性重要示例。

表D.1ISO/IEC/IEEE29148:2018中需求类型属性重要示例

D.2将质量需求映射到推荐原则

十要点[StRS，SyRS,SRS]的示例。 所推荐的StRS的文档编写原则主要涉及GB/T25000.10 2016中的使用质量，如表D.2所示

GB/T25000.302021

表D.2使用质量与StRS.SyRS和SRS的映射关系

所推荐的SyRS和SRS文档编写原则主要涉及GB/T25000.10一2016中的产品质量

表D.3产品质量到StRS、SyRS和SRS的映身

GB/T25000.302021

GB/T25000.302021

E.2.2列出项目的一般性假设

输人：无 产出：一般性项目假设 此阶段的第一步是在项目的特定周境下考虑以下假设： a） 客户/用户是其业务领域的专家； b）客户/用户不太可能熟悉系统/软件质量的概念； c） 质量工程师擅长于质量需求的发现和定义，但不是客户/用户业务领域的专家； d）任何从质量角度出发的与项目相关的其他必要假设。 因此，质量工程师宜在开始流程之前考虑所有这些因素，并宜熟悉这些因素，以便充分规定正确的 质量需求。如下所述，规定质量需求的过程是基于确定支撑不同的已识别的利益相关方的业务要求的 质量要求。质量工程师越详尽地识别项目的必要假设，他就能越好地与客户/用户协作并定义不同利益 相关方的质量要求。因此，负责规定利益相关方质量要求的质量工程师宜牢记这一系列假设，以完成系 统/软件质量需求的规定

E.2.3研究项目的领域

输人：一般项目假设 输出：项目领域的特性，业务要求 这一步对于更好地理解项目领域以及ICT产品必须部署的常规周境，是必不可少的。此步骤在规 定质量需求的过程中非常重要，因为它可以让质量工程师获得更多项目领域的专业知识，并更好地理解 客户/用户的业务需求。此外，这一步骤对于确定项目各方面的可行性是不可或缺的，因为它清晰地描 述了为满足客户/用户所需的ICT产品质量，所必需的资源（金融资本和技术上的基础设施）和技能（人 员和知识）。 随后，执行此步骤将使质量工程师能够更好地了解项目所在领域的不同方面，并且有利于与不同利 益相关方的沟通，这些对于规定系统/软件的质量需求至关重要

E.2.4规定项目的约束

输人：项目领域的特性，业务要求 输出：预算上、技术上、组织上以及其他方面的约束 在此步骤中，质量工程师宜使用上一步对项目领域的理解，来规定项目的约束。此步骤宜由项目的 客户/用户以及来自ICT产品供方团体的不同利益相关方共同参与。 这一步定义三类主要约束： a 预算上的约束，本质上取决于为ICT产品质量而分配的财政资源。 b）技术上的约束，通常由软件提供方的开发团队陈述的。但是，如果在系统/软件部署之后客户/ 用户必须对其执行维护，客户/用户的技术团队就很有必要参与该步骤。此外，由客户/用户自 由支配的基础设施必然会给开发团队带来一些技术上的限制。 c 组织上的束，主要是由客户/用户公司的组织架构及公司内部已有的各种交互方式所决定 的。因此，规定ICT产品质量需求的活动宜考虑到这些约束，以便它们可以很好地集成到项 目执行中，并进一步融人ICT产品所支持的业务模型中。 最后，质量工程师宜在客户/用户或开发团队的协助下识别与特定项目相关的其他类型的约束。完 整的约束清单对于评估工程师所规定的系统/软件质量需求的可行性具有决定性作用

E.2.5列出所有利益相关方

输入项目领域的特性，约束

GB/T 25000.30=2021

输出：与已识别的利益相关方相关的使用周境 这一步宜与利益相关方协作执行，确定针对特定的利益相关方或用户群的ICT产品的使用周境， 为实现这一目标，质量工程师宜确定： a 用户使用ICT产品想要实现的目标； b 为实现该目标用户要执行的任务； 用户的特性： d 使用ICT产品的技术上、物理上和组织上的环境， 了解利益相关方的使用周境可以帮助质量工程师在过程的后期确定最终的质量要求。由于任何利 益相关方通常都很了解自已的使用周境，因此他们在这一步骤中的协作对于确保其成功至关重要。 为了定义使用周境，质量工程师可以使用许多技术手段来获取该信息： a）调查； b）观察； c）采访； d）任何其他适宜的手段。 在某些情况下，为了获得更多信息，可以组合使用上述的多种技术手段，进而为此后规定系统/软件 质量需求奠定更强的基础。 最后，质量工程师可以参考ISO/IEC25063将每个利益相关方的使用周境采用通用的行业格式记 录下来形成文档，以确保它的可追溯性， 注1：ISO/IEC25063不仅适用于文档记录，还可用于识别要收集的信息类型 宜仔细检查用户为实现其目标而执行的任务，因为这些任务通常包含大多数质量属性，例如，本地 化性能或指定任务的易用性。 注2：高层级目标分析没有展示出这些指定的质量要求

E.3.3提取和归档质量要求

输人：使用周境、约束条件 输出：质量需求 为了识别利益相关方的质量要求，质量工程师宜使用他从使用周境中获得的信息，即由每一个利益 相关方或者利益相关方的组织中的用户提供的使用周境中获得的信息。利益相关方的使用周境宜清楚 也反映他的质量要求并充许修订其范围。因此，质量工程师宜与利益相关方协作，列出所有最终的质量 要求，并与利益相关方进行验证和确认，以确保所获得的质量要求代表了他们的真实要求。 此外，为了正确识别和定义所有相关的质量要求，质量工程师宜考虑为实现利益相关方目标所必需 的所有任务，而且也宜考虑执行这些任务的环境。 质量工程师需要以一种能够迫潮其来源的格式记录所有质量要求

E.3.4将每项质量要求与其支持的业务要求联系起来

输人：质量要求、业务要求 输出：与各自业务要求相关的质量要求 这一步骤对于质量过程其余部分的执行不一定具有决定性作用，但对于证明实现所识别的质量要 求所需的努力是必不可少的，因此质量工程师需要明确规定每个确定的质量要求源于哪一项业务要求。 完成此步骤后，质量工程师宜并始下一步，即整个过程的中心。该步骤中质量工程师可以使用前 阶段定义的质量要求来为每个利益相关方规定ICT产品质量需求。 注：E.2.3中提到的周境包括对包含ICT产品的业务模型的理解，或至少是正在分析的ICT产品将会运行的部分业 务模型。

表F.1示出了在互联网上进行购物时，某些用户和任务的一些重要质量要求。

GB/T25000.302021

*1用户1：互联网购物客户，他们浏览商店、选择商品，并购买商品。 a) 主用户：互联网购物方，通过互联网使用计算机搜索商品，选择、决定并订购商品。 b) 辅用户：帮助主用户使用系统的助手。 c） 间接用户：想要购买东西的客户，要求某人进行网上购物，他们自已并不直接使用该系统 *2用户2：负责管理和运行网站的互联网购物网站管理员和操作员。 a 主用户：使用计算机上传和显示商品数据的操作员，或回答端用户间题。 b) 辅用户：系统的买方部门、销售部门、会计或安全控制的经理。 C） 间接用户：拥有并运行互联网购物网站的物主。

表F.2展示了某些利益相关方及其部分任务的一些重要质量需求。

表F.2展示了某些利益相关方及其部分任务的一些重要质量需求。

GB/T25000.302021

附录G （资料性附录） 质量要求映射到质量特性的示例

本附录提供了一个将质量要求映射到GB/T25000.10一2016中的质量特性的示例。 一些质量要求不能直接映射到模型的特定特性上，但仍需要明确和规定。结合GB/T25000.10 2016中模型的几个特性以及子特性，下面的过程描述了如何根据这些质量要求定义质量需求。 对于不能直接明确和规定映射到需要的GB/T25000.10一2016独特的质量特性，可以使用现有特 生或子特性作为基本构件生成新的特性。 注3：新的特性/测度可能不同于其组成部分的简单合并或相加。它们表达了包括在产品中的新的质量特性。 注4：保持正确使用特性/子特性和测度的原则，模型可以扩展和裁剪并针对多种不同情况进行定制。 GB/T25000.10一2016提出的基本特性可以作为构建模块，以表示产品所需的更复杂的质量特性。

G.2示例：映射"移交控制”质量要求

使用附录E提取第1个质量需求。 产品： 自动驾驶汽车、全自动。 项目： 产品经理陈述与自动驾驶汽车相关的客户质量要求，以下是其中一项功能需求： 车辆根据自身的情况识别来决定是否将控制权移交给人类驾驶员，这对于没有经验的驾驶员，甚至 是有经验的驾驶员来说，在复杂的情况下都是有风险的。 产品经理对“移交控制”的质量需求如下： QN1：在极度困难的情况下，最大限度地减少车辆和人工驾驶员之间控制权的移交次数 GB/T25000.10一2016和GB/T25000.12一2017质量模型可用于描述质量特性。因为使用这些 模型有助于定义明确的、可验证的质量需求，所以这样做的组织具有可量化、可论证的产品质量，在竞争 中将会处于优势地位。 新产品的周境： 不成熟的技术或新技术； 不成熟的规定或新规定； 缺乏买方对产品的了解。 领域： 高度管制的市场，但在这项新技术方面还不成熟； 正在制定的标准； 规章制度因地域而异/正在制定的规章制度； 客户多样性； 需求多样性； 客户偏好多样性； 不同的地理区域、社会和文化；

GB/T25000.302021

众多供方； 众多商业模式的贡献者：保险、工会等。 利益相关方： 监管机构； 生产商； 客户/买家； 汽车零部件行业； 各类汽车维修服务； 商业机构； 保险公司； 运输业（人员和商品）； 工会。 ·· 接下来，将上面定义的质量需求映射到一些质量特性或子特性中。但是，像QN1这样的高层级质 需求不能直接映射到GB/T25000.10一2016质量模型中的任何单个特性或子特性（以及 B/T25000.22—2019，GB/T25000.23—2019和GB/T25000.24—2017中定义的测度）。对于这种情 海洋标准，可以使用一组子特性来规定所需的质量需求。 要规定QN1的质量需求，可以组合使用表G.1中的使用质量模型子特性及其测度

表G.1将QN1映射到使用质量模型子特性的例子

注：一些特性/子特性的质量需求 通过技术和业务决策来解决

通过技术和业务决策来解决

GB/T25000.302021

一种QIUR能够隐含如下儿种PRQ： ·考虑使用目标产品的业务运营来获取产品的有效性、效率和满意度需求。例如，效率需求可能 意味着产品的时间效率、易用性、功能正确性和易操作性需求，因为这些产品质量需求会一起 影响业务运行的效率。 ·通过考虑目标产品被误用或恶意使用以及自身的故障的场景，来获取产品抗风险的需求。抗 风险需求可能意味着功能正确性、可靠性、信息安全性、易用性和维护性需求。 ·通过考虑各种使用环境（包括不同类型的用户和操作环境的变化）的场景来挖掘产品的周境覆 盖需求。周境覆盖需求可能意味着易用性、兼容性、维护性和时间效率需求。 根据系统类别，可以通过很多推导模式从使用质量特性得到产品质量特性。表H.1示出了一个 “核反应堆控制系统”的推导模式的例子

"核反应堆控制系统”从QIUR到POR的推导过利

核反应堆控制系统应具有强大的抗风险需求。由于系统被分类为实时和人力密集型系统，因此不 又可靠性，而且性能效率和易用性都很重要。使用ISO/IECTR12182考虑目标系统的类别可以更好 也进行产品质量需求的挖掘。 注：在某种程度上给水排水标准规范范本，使用质量需求与产品质量需求之间的关系取决于任务本身。例如，维护性和可移植性将影响维 护和移植任务的有效性、效率和满意度

GB/T25000.302021