ISO/IEC TR 23951:2025

Technical
Report
ISO/IEC TR 23951
Second edition
Information technology — Cloud
2025-04
computing — Best practices for
using the cloud service level
agreement (SLA) metric model
Technologies de l'information — Informatique en nuage —
Bonnes pratiques pour l'utilisation du modèle métrique d'accord
de niveau de service (SLA) dans le Cloud
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 1
5 Structure of this document . 2
6 Motivation . 2
6.1 Preamble .2
6.2 Audience and some user categories .2
6.2.1 General .2
6.2.2 Cloud service customer (CSC) . .3
6.2.3 Cloud service provider (CSP) .3
6.2.4 Cloud service partner (CSN) .3
6.2.5 Regulators and policy makers .3
6.3 Usage patterns .4
6.3.1 General .4
6.3.2 Extract and clarify an existing metric description from an SLA . .4
6.3.3 Create and share a metric description .4
6.3.4 Compare metric descriptions .4
6.3.5 Share a common foundation for a set of metrics .5
6.3.6 Build a metrics catalogue .5
6.4 Examples of scenarios and roles involved in sharing metric definitions .5
7 The metric model in practice: templates . 6
7.1 A brief reminder of the metric model .6
7.2 A tabular representation .7
7.2.1 General .7
7.2.2 The tabular representation for the Metric element .8
7.2.3 The tabular representation for the Expression elements .9
7.2.4 The tabular representation for the Rule elements .10
7.2.5 The tabular representation for the Parameter elements .10
8 An example of metric definition: the cloud service mean response time metric .11
8.1 The cloud service mean response time metric: informal variant .11
8.1.1 Extracting metric elements from an SLA narrative .11
8.1.2 Using the tabular representation . 12
8.1.3 Overall structure of the metric . 13
8.2 The cloud service mean response time metric: more formal variant .14
8.2.1 A more formal variant of the metric .14
8.2.2 Adding a parameter .14
8.2.3 The metric rules . 15
8.2.4 The metric expressions . 15
8.2.5 Overall structure of the metric .16
8.2.6 Using constants .17
9 Guidelines for using the metric model with the tabular representation . 19
9.1 General .19
9.2 Guideline 1 about defining expression and rule languages .19
9.3 Guideline 2 about associating rules with expressions .19
9.4 Guideline 3 about relating expressions to each other . 20
9.5 Guideline 4 about the identifiers of metric elements . 20
9.6 Guideline 5 about rules specifically designed to support an expression . 20
9.7 Guideline 6 about the role of parameters .21

© ISO/IEC 2025 – All rights reserved
iii
9.8 Guideline 7 about representing constants .21
10 The simple cloud service availability metric.22
10.1 Measuring cloud service availability . 22
10.1.1 General . 22
10.1.2 Overall design approach . 22
10.1.3 SLA rules and metric rules . 22
10.2 The simple cloud service availability metric variant Simple_SAM_1 . 23
10.2.1 The Metric element . . 23
10.2.2 The metric rules .24
10.2.3 The metric expressions . 25
10.2.4 The metric parameters . 26
10.2.5 Overall structure of the metric . 26
10.3 The simple cloud service availability metric variant Simple_SAM_2 .27
10.3.1 Differences in metric design and assumptions .27
10.3.2 The Metric element . . 28
10.3.3 The metric rules . 28
10.3.4 The metric parameters . 29
10.3.5 The metric expressions . 30
10.3.6 Overall structure of the metric .31
10.3.7 An alternative metric design using the Configuration element option .32
Bibliography .33

© ISO/IEC 2025 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 38, Cloud computing and distributed platforms.
This second edition cancels and replaces the first edition (ISO/IEC TR 23951:2020), which has been
technically revised.
The main changes are as follows:
— alignment with ISO/IEC 22123;
— references to ISO/IEC 17788 and ISO/IEC 17789 have been changed to ISO/IEC 22123.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2025 – All rights reserved
v
Introduction
In most cases, cloud service providers (CSPs) and cloud service customers (CSCs) negotiate service level
agreements (SLAs) which include service level objectives (SLOs) and service qualitative objectives (SQOs) for
which CSPs make commitments. The commitments described in SLAs are expected to be measured against
actual performance of the service to ensure compliance with the SLA. How actual performance compares
against commitments in SLAs is explained in ISO/IEC 19086-2. Cloud SLAs are covered in ISO/IEC 19086-1
and in ISO/IEC 19086-4.
The metric model in ISO/IEC 19086-2 establishes common terminology, defines a model for specifying
metrics for cloud SLAs, and includes applications of the model with examples. This document provides
guidance and examples on using the metric model to compose the calculation of a cloud service performance
measure in order to compare against an SLA commitment. A few examples from the SLOs listed in
ISO/IEC 19086-1:2016, Clause 10 are given in the document, such as Cloud Service Mean Response Time and
Simple Cloud Service Availability. As specific, measurable characteristics of a cloud service, SLOs are the
basis for defining the metrics used to evaluate and compare agreements between parties.
In Clauses 8, 9 and 10 of this document, a basic explanation of these examples is provided using a
practical method based on a tabular format that is a refinement of the informative tables provided in
ISO/IEC 19086-2:2018, Annex B. The tabular representation described in this document serves as templates
for designing metrics. Guidance in using the metric model with these templates is provided while developing
metric examples.
© ISO/IEC 2025 – All rights reserved
vi
Technical Report ISO/IEC TR 23951:2025(en)
Information technology — Cloud computing — Best practices
for using the cloud service level agreement (SLA) metric model
1 Scope
This document provides best practices for using the ISO/IEC 19086-2 metric model, illustrated with
examples.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 22123-1, Information technology — Cloud computing — Part 1: Vocabulary
ISO/IEC 19086-1, Information technology — Cloud computing — Service level agreement (SLA) framework —
Part 1: Overview and concepts
ISO/IEC 19086-2, Cloud computing — Service level agreement (SLA) framework — Part 2: Metric model
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 22123-1, ISO/IEC 19086-1 and,
ISO/IEC 19086-2 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Symbols and abbreviated terms
CCRA cloud computing reference architecture
CSC cloud service customer
CSN cloud service partner
CSP cloud service provider
SLA service level agreement
SLO service level objective
SQO service quality objective
© ISO/IEC 2025 – All rights reserved
5 Structure of this document
In supporting the scope presented in Clause 1, this document develops the rationale for a practical metric
representation to complement the metric model in ISO/IEC 19086-2 in the following clauses:
— Clause 6 states the rationale for complementing the metric model as defined in ISO/IEC 19086-2 with
a practical representation and for providing related usage guidance as introduced by this document. It
identifies some usage patterns and highlights some usage scenarios where metric definitions are shared
across various parties. The users who benefit from this document include parties with roles defined in
ISO/IEC 22123-3 (Cloud computing — Reference architecture).
— Clause 7 introduces the tabular metric representation supportive of the metric model and derived from
the informative tables listed in ISO/IEC 19086-2:2018, Annex B. This representation is based on tables
intended to serve as templates for metric definitions. This clause represents initial guidance in using the
metric model, which is then illustrated and discussed throughout the examples developed later in the
document.
— Clause 8 introduces a simple case of metric definition that illustrates the use of the table templates
introduced in Clause 7. This example starts with the description of a metric as it would appear in the
narrative of an existing SLA and illustrates the extraction of this description toward a more structured
and distinct representation using the proposed tabular representation. The example shows practical
aspects when designing and developing metrics, such as how metric rules relate to expressions, and how
to parameterize rules and expressions.
— Clause 9 is a set of guidelines on how to use the metric model with the tabular templates (Clause 7).
This guidance is motivated and illustrated by the examples throughout the document. These guidelines
are best understood after developing a preliminary example (Clause 8). They explain how to use the
metric model with the tabular templates for metric use cases posing similar challenges or using similar
features.
— Clause 10 develops a more elaborate metric example for cloud service availability. It describes two
variants of the same metric that illustrate two different approaches in using the metric model elements.
Since it comes after the guideline items listed in Clause 9, it is easier to relate the development of this
second example to these guidelines.
6 Motivation
6.1 Preamble
This clause first identifies the audience of this document and for the tabular metric representation described
in this document. This clause then describes some metric usage patterns and then identifies scenarios and
roles for these metric usage patterns. Sharing common guidelines and conventions in using the metric
model improves the ability to reuse and compare metrics. These common guidelines extend to the aspects
of a metric that are part of the metric model but the details of which are out of scope of the metric model
in ISO/IEC 19086-2, such as the use of rule and expression languages and how these constructs relate to
each other. Supportive of the goal of harmonizing the usage of the metric model across users, this document
proposes a tabular representation for metric definitions that is derived from and augments the tables
provided in Annex B of the metric model in ISO/IEC 19086-2:2018, as explained in 7.2.2.
6.2 Audience and some user categories
6.2.1 General
The audience for this document is expected to be diverse, as the metric representation proposed in this
document is intended for different parties involved in providing or using cloud services. However not every
clause is of interest to all. Those who read, negotiate or create SLA content, such as business users and
administrators, are expected to be interested in Clauses 1 to 7 and in the initial approach to the first metric

© ISO/IEC 2025 – All rights reserved
example (see 8.1). In addition to these clauses, metric designers and developers are expected to be interested
in the remaining clauses including more elaborate examples of metrics (starting from 8.2 and beyond).
The parties interested in this document include representatives of the following roles defined in
ISO/IEC 22123-2.
6.2.2 Cloud service customer (CSC)
This document helps the CSC to understand the metrics used for service quality and other assurances
described in SLAs. When blended into the narrative of the SLA, metrics are often ambiguous or incomplete.
A structured definition as described in the metric model and made practical with a tabular representation
helps to avoid or at least detect such issues.
Specific types of customers are interested in understanding how a service is measured without having to
read the entire SLA or prior to establishing an SLA. These customers are defined in the CCRA as a cloud
service users (who uses a cloud service to fulfil her/his role), a service administrator (who oversees all the
operational processes relating to the use of cloud services, serving as intermediary between the user and
the provider) and a business manager (who has overall responsibility for the business aspects of using cloud
services, including the purchase of the service under appropriate terms and possibly the request of audit
reports).
The tabular representation in this document is also an analysis tool for the CSC to identify and extract the
metric material found in an SLA in order to get a clearer understanding of how the service is measured, as
illustrated in 8.1.
6.2.3 Cloud service provider (CSP)
This document helps the CSP to describe the service metrics that support his or her SLAs, potentially
avoiding contentious claims afterward that result from CSCs misunderstanding the terms and conditions
of these SLAs. It also helps providers to harmonize their metrics across data-centre operators or world
regions. Among activities expected from CSPs as defined in ISO/IEC 22123-3, the following are facilitated
by metric definitions and evaluations: monitoring service, administering service security, providing audit
data on request, defining and gathering metrics, managing security and risks, and, finally, handling support
requests, reports and incidents from cloud service customers. For these activities, this document helps to
establish a common and unambiguous representation of metrics used between parties involved in these
activities and distinct from other SLA material.
6.2.4 Cloud service partner (CSN)
The following CSN sub-roles are expected to find value in a metric definition template and guidelines:
— Cloud service developer: this user is responsible for designing, developing, integrating, testing, and
maintaining cloud services. Developers need to understand the measurements used to evaluate a cloud
service. This role includes composing a new cloud service from existing separate cloud services. By
having access to precise metric definitions and their rules, such as those illustrated in Clauses 8 and 10,
developers understand what features are to be monitored, what is the expected quality of the developed
cloud service and its priorities, as well as how to evaluate the quality and risks when integrating third
party cloud services.
— Cloud auditor: the auditor has the responsibility of conducting an audit of the provision and the use of
cloud services. A cloud audit typically covers operations, performance and security and examines whether
a specified set of audit criteria are met. By using metrics, the auditor understands or communicates
clearly the details of the measurements to perform. Such precision and clarity are provided by a distinct
and detailed metric representation, as illustrated in the two examples developed in Clauses 8 and 10.
6.2.5 Regulators and policy makers
Several aspects of policy definition and enforcement concern measurable properties both about the cloud
service usage (including cloud service usage duration and times, volume and type of data involved), and
the cloud service performance (such as cloud service quality, elasticity and scalability, availability and

© ISO/IEC 2025 – All rights reserved
reliability). Other policies (such as those about trust and transparency, security procedures, privacy) concern
the relationship, governance and risk management between parties, especially CSCs and CSPs. Whether
these policies involve automated monitoring or some human assessment instead, they rely on some form of
measurement for tracking their implementation. See ISO/IEC TR 22678 for more information regarding the
development of policies that govern or regulate cloud service providers (CSPs) and cloud services, and those
policies and practices that govern the use of cloud services in organizations.
The expression of policies and rules sometimes translates into predefined metric elements that are expected
to be used even when defining a customized metric. An example is of a policy that determines the formula
(metric expression) to be used when assessing cloud service uptime percentage, while leaving other details
unconstrained. As another example, if there is agreement for sharing across CSPs the common definitions
of “natural disaster” or “service misuse”, the reuse of such definitions helps to establish a common
understanding of what a valid cloud service downtime means. Creating and sharing predefined metric
material is a usage pattern described in 6.3.5 as sharing a metric foundation.
6.3 Usage patterns
6.3.1 General
A summary of various usage patterns for the tabular metric representation given in 7.2 and a rationale for
doing so are provided in the next subclauses. Some of these usage patterns match usage categories identified
in ISO/IEC 19086-2:2018, 6.4.2.
6.3.2 Extract and clarify an existing metric description from an SLA
Often, the metric(s) information in a cloud service SLA is scattered over the SLA narrative. Parts of metric
material (such as measurement rules, exceptions, underlying quantities and metrics) is mixed with related
information that is not part of the metric definition (such as performance objectives, remediation measures
and penalties).
Distinguishing a metric definition apart from its context of usage in an SLA and using for this the metric
model and its concrete representation helps detect ambiguities and missing elements. This also promotes
the reuse of a metric across SLAs and providers, (see 8.1 for an example of the extraction of a metric
definition from an SLA narrative). This pattern of using the tabular metric representation supports the usage
categories listed in ISO/IEC 19086-2:2018, 6.4.2.1 (cloud services) and 6.4.2.3 (cloud service agreements).
6.3.3 Create and share a metric description
A metric definition is sometimes intended to be used by various parties including CSP, different CSCs
and CSNs including sub-roles such as cloud service developer and cloud auditor. Using a common metric
representation and its usage conventions helps these parties to describe and understand metrics that they
use and share.
A metric representation separate from an SLA helps different parties to share metrics while leaving
aside any other SLA content. Beyond an informal plain text description understandable by all, the tabular
representation introduced in 7.2 supports more formal descriptions such as specific languages for the
calculation logic (expressions) and its rules, thus serving different users. See 8.1 for using different
expression languages of interest to various parties. This pattern of using the tabular metric representation
supports usage categories listed in ISO/IEC 19086-2:2018, 6.4.2.1 (cloud services) and 6.4.2.4 (developing
performance monitoring tools).
6.3.4 Compare metric descriptions
There are many variants of a seemingly common metric across CSPs. CSCs often want to compare these. Such
a comparison is made easier by using the same metric model and elements but also common representation
and guidelines. For example, significant variations have been observed between CSPs in a metric as common
as “service availability as uptime percentage” due to different definitions of cloud service downtime.

© ISO/IEC 2025 – All rights reserved
A well-structured metric representation makes it easier to assess comparable metric elements. This pattern
of using the tabular metric representation supports usage categories listed in ISO/IEC 19086-2:2018, 6.4.2.2
(comparing cloud services).
6.3.5 Share a common foundation for a set of metrics
In many cases, it is desirable to share the same metric conventions and elements, if not the same metric.
These conventions and elements are expressed as a partially developed metric definition, called a metric
foundation in this document for convenience. For example, a metric foundation can be defined for cloud
service availability that imposes the same general calculation of “availability” as cloud service uptime
percentage, leaving the details for each CSP to define (see 6.2.5 about policies requiring to use predefined
metric elements).
6.3.6 Build a metrics catalogue
A metrics catalogue collects metrics and their variants in specific areas, along with their association to
useful resources such as available implementations. This is of interest to CSPs or communities of CSNs
interested in sharing and reusing metric material.
A common metric representation and a set of conventions based on a shared metric model are a step toward
building a metrics catalogue. This also helps to create a catalogue of metric implementations of interest to
cloud service developers. Such catalogues in turn serve as resources for various parties to search, select and
reuse metrics or metric elements.
6.4 Examples of scenarios and roles involved in sharing metric definitions
Metrics can be used in various ways and for different purposes, which can result in differing measurement
definitions. For example, calculating car rental 'availability' differs from calculating 'airline seat availability.'
Cloud Service Providers (CSPs) can also define the same metric differently. For instance, some CSPs exclude
'planned maintenance outages' when calculating 'availability,' while others include them.
Consider an enterprise or government agency that purchases an IaaS service for compute. The role it plays
for the IaaS provider is the CSC who consumes a compute service. The enterprise (or government agency)
develops customized (PaaS) services to be reused by others in the enterprise or agency. After the PaaS
services are deployed, its role is also of a PaaS CSP.
Application developers in the enterprise (or government agency) can use the PaaS to help develop the
business applications (SaaS) for the benefit of their own end-users or business customers. After the SaaS
services are deployed, the department that provides these services acts in the role of SaaS CSP.
Availability metrics are of interest to several roles and sub-roles with different perspectives and concerns,
as illustrated in Table 1.
© ISO/IEC 2025 – All rights reserved
Table 1 — The use of cloud service availability metrics across roles
Metric: Cloud Service availability
Role description Use case scenario for the metric Potential availability metrics of interest
CSP – IaaS cloud com- What level of “cloud infrastructure compute Cloud infrastructure compute availa-
pute service provider service availability” can the CSP commit to for its bility
customers?
CSN – cloud PaaS ser- The PaaS developer needs to determine what avail- PaaS availability, Cloud infrastructure
vice developer ability “targets” are reasonable when developing compute availability
and deploying their PaaS services (such as APIs).
Does the cloud infrastructure compute service
availability commitment from the CSP enable PaaS
availability intended targets to be met?
CSC – cloud PaaS The user needs to understand what availability SaaS availability, PaaS availability,
service customer, as a “targets” are required to satisfy their customer Cloud infrastructure compute availa-
SaaS developer needs. Does the PaaS availability enable SaaS bility
availability targets to be met? Does the “Cloud
infrastructure compute service availability” CSP
commitment enable SaaS and/or PaaS availability
targets to be met?
SaaS customer What application service availability can be ex- SaaS availability
pected by the application user?
Table 1 illustrates the rationale for a metric definition that takes into account a variety of usages and
accommodates a range of users. A way to ease the understanding of a metric definition across various
parties is to describe it using more than one language, as illustrated in Clause 8.
Table 1 also suggests requirements for metrics to build on each other or to extend each other. An example is
of an IaaS CSP who does not include connectivity as part of the availability calculation, while other roles/sub-
roles are affected by outages related to network connectivity (such as between the CSNs, CSCs and the CSP)
and want it to be part of their notion of availability. A more complete cloud service availability metric could
compose a metric already developed for measuring the quality of network connectivity with an availability
metric for the service itself.
Designing a metric for reusability makes it more versatile and supports a variety of usages and intents.
This concern is briefly discussed in design options for the examples (see 8.2.4.2 and 10.2.3.2) as well as in
guideline 6 about parameterization in 9.7.
7 The metric model in practice: templates
7.1 A brief reminder of the metric model
An overview of the metric model is provided in Figure 1 as it appears in ISO/IEC 19086-2 in the form of an
UML diagram.
© ISO/IEC 2025 – All rights reserved
Figure 1 — The metric model in ISO/IEC 19086-2
Each one of the four blocks in Figure 1 (Metric, Rule, Expression, Parameter) is also called a metric element.
A more detailed description of the metric elements and their attributes is provided in ISO/IEC 19086-2.
The term Metric element (capitalized) is used to refer specifically to the element named Metric in the UML
diagram and the tabular representation of this element.
The term "metric element" is used generically to denote any element that is part of a metric, without
necessary reference to a particular element type (i.e., Metric, Expression, Rule, Parameter).
7.2 A tabular representation
7.2.1 General
A tabular rendering of the metric model usable as a set of templates for capturing the definition of a particular
metric is provided in Table 2, Table 3, Table 4 and Table 5. There is one table for each type of metric element
(Metric, Rule, Expression, Parameter). For example, the Metric table, once filled with values, represents the
definition of a Metric element. These templates are described in the next subclauses.
In the Metric table, the associations between the Metric element and its constituents (Rule, Expression and
Parameter elements) are represented as references to these constituent elements using the id attribute
(see associated element fields in Table 2). Such associations are illustrated as solid lines in the diagram of
Figure 1.
There are other relationships between metric elements that are accounted for in the metric model in
ISO/IEC 19086-2 although not represented in the diagram of Figure 1. These relationships are instead
represented in ways that depend on the metric languages (ruleLanguage, expressionLanguage), the
description of which is out of scope of the metric model. These relationships are between metric elements
that depend on other metric elements. Examples of such dependencies are:
— An Expression element using another underlying Expression element to support its calculation.
— An Expression element referencing Rule elements that govern its calculation.
— An Expression element referencing another (underlying) Metric element of which it uses the output.
— A Rule element designed on purpose to support a particular Expression element and referencing this
element.
© ISO/IEC 2025 – All rights reserved
— Rule or Expression elements parameterized by some Parameter element.
These cross-element relationships are denoted in this document as “depends on” relationships, as they
indicate that an element is somehow depending on another element. Unlike the association relationships
shown in the Figure 1 diagram and given explicit representation in the tabular templates (see the associated
element fields in Table 1), the “depends on” relationships are indicated inside the value of some fields of the
tables (such as ruleStatement, expressionStatement, or note attributes) and have no explicit support in the
table templates themselves.
In other words, the “depends on” relationship representation is dictated by user-defined conventions, such
as those described in ruleLanguage and expressionLanguage, and becomes apparent in the values given
to these fields for a specific metric. In the tables for the metric examples of this document, it is typically
represented by a reference to the id of the element that is depended on. The “depends on” relationship is
represented by dashed arrows in the figures that give an overview of the structure of each metric example,
such as in Figure 2 in 8.1.3.
7.2.2 The tabular representation for the Metric element
A non-normative tabular representation for metrics and their elements is provided in Annex B of the metric
model in ISO/IEC 19086-2:2018. The tabular representation proposed in this document and used in the
examples is a refinement of this metric model that differs mostly in its layout. Differences and their rationale
are pointed out for each table.
The table for the Metric element in this document clearly separates two sets of fields and qualifies explicitly
their expected content, to avoid any confusion for users:
— The attributes (content: a value);
— The associated elements (content: a reference).
The right column in the table template of Table 2 contains as an informative reminder a brief account of the
field definition (derived from the one originally provided in ISO/IEC 19086-2) and its multiplicity (number of
possible occurrences for that field in the table).
When used in an actual metric definition, the attributes are given a value in the right column, while the
associated elements contain a reference to another metric element, meaning to another table or table row in
this tabular representation.
In several examples, the id attribute is reported in the header of the metric for easier identification (in
addition to or instead of appearing in the same way as any other attribute), as shown in Table 2.
Table 2 — Tabular representation for the Metric element
Metric (id)
attribute value
id (1.1) A unique identifier for the metric.
description (0.n) A description of the metric. A case where several instances of this attribute are
used is when descriptions are provided in multiple languages.
source (1.1) The individual or organization that created this metric definition.
scale (1.1) Classification of the type of measurement result when using the metric. The
value of scale is one of: nominal, ordinal, interval, or ratio.
category (0.1) A grouping of metrics of similar characteristics or intent (e.g. “cloud elasticity” or
...