ISO/IEC/IEEE 15026-2:2022
(Main)Systems and software engineering — Systems and software assurance — Part 2: Assurance case
Systems and software engineering — Systems and software assurance — Part 2: Assurance case
This document specifies requirements for structure terminology of assurance cases. This document is applicable for developing and maintaining assurance cases.
Ingénierie du logiciel et des systèmes — Assurance du logiciel et des systèmes — Partie 2: Cas d'assurance
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/
STANDARD IEC/IEEE
15026-2
Second edition
2022-11
Systems and software engineering —
Systems and software assurance —
Part 2:
Assurance case
Ingénierie du logiciel et des systèmes — Assurance du logiciel et des
systèmes —
Partie 2: Cas d'assurance
Reference number
ISO/IEC/IEEE 15026-2:2022(E)
© ISO/IEC 2022
© IEEE 2022
---------------------- Page: 1 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2022
© IEEE 2022
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 or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
ii
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
Contents Page
Foreword .iv
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Use of assurance cases . 2
4.1 Overview . 2
4.2 Application of this document . 4
5 Structure of assurance cases . 4
5.1 General . 4
5.2 Top-level structure . 5
5.3 Description of types . 5
5.3.1 Context type . 5
5.3.2 Evidence type . 5
5.3.3 Claim type . 6
5.3.4 Inference type . 7
5.3.5 Supported claim type and argument type . 7
5.3.6 Narrative introduction type . 8
Annex A (informative) Examples of supported claims and arguments . 9
Annex B (informative) An example of top-level structure of assurance cases .13
Annex C (informative) Comparison of terminology .16
Bibliography .20
IEEE Notices and Abstract.21
iii
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
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 ISO/IEC documents should be noted. This document was drafted in
accordance with the rules given in the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see https://patents.iec.ch).
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 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards
Development Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC 15026-2:2011), which has been
technically revised.
The main changes are as follows:
— Clause 2 of the previous edition was deleted.
— The title of Clause 5 of the previous edition was changed and became Clause 4 of this edition.
— Revised contents of Clause 6 can be found in Clause 5 of this edition.
— Clause 7 was deleted and its revised contents can be found in 4.2 and 5.2 of this edition.
A list of all parts in the ISO/IEC/IEEE 15026 series can be found on the ISO website.
iv
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
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.
v
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
Introduction
The purpose of this document is to define assurance case structure terminology, thereby improving
consistency and comparability among instances of assurance cases and facilitating stakeholder
communications, engineering decisions, and other uses of assurance cases.
This document does not place requirements on the quality of the contents but describes the structure
and meaning of assurance cases with the necessary level of precision and detail so as to avoid
inconsistent and subjective use of the terms.
Existing standards addressing different application areas and topics related to assurance cases possibly
uses differing terminology and concepts when addressing common themes. This document is based on
experience drawn from these specialized standards and guidelines.
While several notations and slightly varying terminologies are currently used in practice, this document
does not require the use of any particular concrete representation including graphical representation.
Likewise, it places no requirements on physical implementation of the data; in particular, it includes no
requirements for redundancy or co-location.
Assurance cases are generally developed to support claims in areas such as safety, reliability,
maintainability, human factors, operability, and security. They are applicable to any property of a
system. These assurance cases are often called by more specific names, e.g. safety case or dependability
case. ISO/IEC/IEEE 15026-1 provides concepts, terminology, background and a list of standards related
to assurance cases.
[1]
This document uses the terminology and concepts consistent with ISO/IEC/IEEE 12207,
[5] [6]
ISO/IEC/IEEE 15288, and ISO/IEC/IEEE 15289. This document does not presume or require that it
[1] [5]
is applied in conjunction with ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 .
vi
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC/IEEE 15026-2:2022(E)
Systems and software engineering — Systems and software
assurance —
Part 2:
Assurance case
1 Scope
This document specifies requirements for structure terminology of assurance cases.
This document is applicable for developing and maintaining assurance cases.
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/IEEE 15026-1, Systems and software engineering — Systems and software assurance — Part 1:
Concepts and vocabulary
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 15026-1 and the
following apply.
ISO, IEC and IEEE 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/
— IEEE Standards Dictionary Online: available at https:// dictionary .ieee .org
NOTE For additional terms and definitions in the field of systems and software engineering, see
[7]
ISO/IEC/IEEE 24765, which is published periodically as a "snapshot" of the SEVOCAB (Systems and software
Engineering Vocabulary) database and is publicly accessible at computer .org/ sevocab.
3.1.1
assurance case
auditable artefact that provides a convincing and sound argument for a claim on the basis of tangible
evidence under a given context
Note 1 to entry: An argument is valid if and only if it is necessary that if all of the premises are true, then the
conclusion is true. An argument is sound if and only it is valid and contains only true premises.
1
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
3.1.2
assurance case report
auditable artefact that provides the claim of an assurance case (3.1.1) and a complete index of the
argument and evidence of the assurance case such that the assurance case of interest can be assembled
from the index
Note 1 to entry: An assurance case report is mapped to the report field [5.2 c)]. An assurance case report is
an introduction to the assurance case. Its content varies from one case to another. For simple and/or small
assurance cases a report can be superfluous. For larger or more complex assurance cases the report can include
a system description, some of the argument and its supporting evidence e.g. the higher-level arguments and their
supporting evidence.
Note 2 to entry: Assurance case reports are often issued as periodic updates to the assurance case at pre-
agreed points such as at the end of a life cycle stage. They report on results of assurance activities done so far, an
assessment of overall progress and a review of assurance activities’ performance. Assurance case reports can be
used at decision gates for stage exit/entry by suppliers and for project monitoring by acquirers.
3.1.3
basic assumption
assumption in a collection of claims shared by assurance cases (3.1.1) in a specific field
Note 1 to entry: Such a collection corresponds to a set of axioms in formal system in logic.
3.1.4
inference
reasoning step that derives a claim from a list of claims (premises) under a specified context
Note 1 to entry: The claim derived by inference is the conclusion, and the supported claims from which the
inference derives the conclusion are the premises.
Note 2 to entry: There are special inferences called obvious inferences. See 5.3.4 EXAMPLE 2.
3.1.5
property
attribute of things
3.1.6
type
set of values, elements or items
3.1.7
undeveloped argument
placeholder argument to be replaced by a concrete argument
3.2 Abbreviated terms
CAE claims arguments evidence
GSN goal structuring notation
SACM structured assurance case metamodel
4 Use of assurance cases
4.1 Overview
Assurance that the system achieves certain objectives is particularly important when the system and
its interaction with the environment are complex and evolving. Assurance cases make claims that
concern selected properties of the system, and argue for the truth of those claims. While properties
may be selected for any reason, the common reason of selection is that they are uncertain while high
2
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
confidence is demanded. An assurance case can be used to establish the values and the uncertainties
associated with the claims. The assurance case presents arguments that support the claims. However,
uncertainty can arise from a number of aspects of the argument including:
— the validity of the inference linking the claim to its supporting claims;
— the scope and relevance of applied context;
— the relevance and trustworthiness of the evidence supporting the claims.
The objective of the assurance case is to present a convincing argument along with specified ranges
of validity or confidence levels. To be convincing, the argument needs to address the uncertainties in
a balanced manner and assert that the arguments establish the claims only to the specified levels of
validity and confidence. The readers of the assurance case form their conclusions regarding sufficiency
of the evidence presented therein.
There are other sources of uncertainty; refer to 2:5.3.3 in Reference [9] for a more complete statement
on uncertainties in arguments.
NOTE 1 The values and their uncertainties established for each claim by an assurance case can be non-
numerical because not all claims are expressed in terms of numerically measurable property.
NOTE 2 The term "uncertainty" is used as a general term to cover "lack of certainty." See
ISO/IEC/IEEE 15026-1:2019, 5.6. Different communities restrict the application of this term to limited usage, e.g.
to predictions of future events, to physical measurements already made, or to unknowns; but in this document
the term applies to any uncertainty.
Users of the assurance case can assess the truth of the top-level claim that the property of interest
is realized in the product or service. The assessment can also cover the uncertainty in the truth of
the claim. The assessment of the top-level claim and its support along with related uncertainties and
consequences constitute a basis for rationally managing risk, establishing grounds for appropriate
confidence, and aiding in decision making. Stakeholders can make better decisions about a system
when the uncertainties of conclusions are understood and reduced. Assurance cases are developed for
various audiences, taking into account the needs and characteristics of each audience. For example,
an assurance case for service developers may differ from an assurance case for regulators, even if the
underlying system of interest is one and the same.
NOTE 3 The text often refers to a single assurance case. However, a system can have multiple assurance cases.
The degree of validity and confidence level provided by the assurance case needs to be proportionate
to the risk reduction required in the system of interest. Achieving an acceptable level of validity and
confidence depend upon the complexities of the system, the technology involved in its construction, the
developer’s experience with the technology and the novelty of the assurance arguments used. It may
also depend on the type of stakeholders concerned in the assurance case and the purpose of its use and
the context of their evaluation.
[3]
NOTE 4 See ISO/IEC 15026-3 for more detailed discussion on this point.
An assurance case argues that interactions of a system with the intended environment of use, including
the service it delivers, are as intended/specified. Consequently, the development of the assurance case
should be integrated into the whole system life cycle, considering the environment.
NOTE 5 Selecting the top-level claim and the properties it involves is not restricted by this document. Top-
level claims can be specified in stakeholder requirements, established by an approval authority for the system or
product, or selected for reasons internal to the system.
NOTE 6 Limitations of a system’s or product’s assurance case are reflected in
— the guidance,
— transition, operations, and maintenance documentation,
— training,
3
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
— operator and user aids,
— data collection capabilities, or
— services included in or accompanying the system or product.
Assurance cases need to be maintained as the system evolves. This includes changes in the system
design, its operational environment or its use, as these can impact the context and assumptions relied
upon in the argument. Assurance cases should be initiated at the earliest life cycle stage of the system
of interest and maintained through to its concluding life cycle stage. The system and its life cycle,
as well as their environment, change after initial delivery. The technical processes can be changed
because of the modifications needed after initial delivery. Also, useful evidence can be obtained after
continued operation in production, especially in the case of dependability related claims. In both cases,
the original assurance case should be modified or augmented.
NOTE 7 In the context of system life cycle process and software life cycle process, the maintenance activities
are not only invoked during operation stage but also during other stages by agreement processes, technical
management processes and technical processes. Assurance case maintenance follows the system maintenance life
cycle. The milestone for assurance case acceptance and any modifications to the baseline assurance cases, thereby
[5]
follows the governance of life cycle processes as provided by ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207.
[1] [4]
ISO/IEC/IEEE 15026-4, provides guideline for assurance activities as System Assurance process view and
Software Assurance process view.
The truth of the claim should be assessed in a balanced way so as to remove unconscious bias by
presenting, for instance, as much uncertainty as can be considered.
4.2 Application of this document
Application of this document supports use of assurance cases by providing for the following.
a) An assurance case having the structure specified by Clause 5 is provided as an artefact or collection
of artefacts of the system.
NOTE As an artefact of the system, the assurance case is generally constructed with the system and
maintained as the system is maintained.
b) A logical mapping between the assurance case and the structure specified by Clause 5 is provided
as a part of the assurance case. [5.3.6 f)]
c) Records documenting the fulfilment of the requirements of this document are produced and
provided as a part of the assurance case [5.3.6 g)].
5 Structure of assurance cases
5.1 General
Subclause 5.2 defines the structure of assurance cases by means of a record type that has three fields.
5.3 defines the types that are used in 5.2.
A mechanism shall be provided that helps ensure that each identifier refers to an unambiguously
defined value of some type, is an explicitly declared parameter, or is a generally accepted term.
The Appendix D to Reference [10] gives the basis for the approach taken in this clause.
Examples of each structure are provided in Annex A, and a more complex example is given in Annex B.
Annex C is a comparison of this document and three community standards GSN, SACM and CAE in terms
of mapping the structure terminology in the former to the terms in the latter.
4
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
5.2 Top-level structure
An assurance case is a record that has three fields: main field, evidence field and report field.
a) Main field
A supported claim (5.3.5).
NOTE An assurance case is incomplete if its main field contains an undeveloped argument (3.1.7).
b) Evidence field
A set of evidence items (5.3.2).
c) Report field
A narrative introduction (5.3.6). Its assurance goal field (5.3.6 d)) corresponds to the top-level
claim of the main field. The contents of the report field constitute the assurance case report (3.1.2).
5.3 Description of types
5.3.1 Context type
The context type is the type of list whose elements are:
a) the definition of a term or identifier;
b) a basic assumption (3.1.3) on the terms defined in the assurance case; or
c) a reference to a document concerning the system of interest.
NOTE 1 Contexts can be used to define identifiers specific to the assurance case that refer to, e.g. evidence
items, other components of the assurance case, the system of interest and its components, and the environment
of the system of interest.
NOTE 2 When multiple local definitions for an identifier are allowed, the mechanism required in 5.2 enforces
proper scoping rules to help ensure that each occurrence of the identifier refers to a unique local definition.
EXAMPLE 1
A definition of "tolerability targets" for each identified hazard can be given in a context.
EXAMPLE 2
A reference to the system requirements specification can be specified in a context.
5.3.2 Evidence type
The evidence type is the record type which has the following four fields. An element of evidence type is
called an evidence item:
NOTE 1 An evidence item is an available body of facts or information that support an assertion of truth of a
claim.
NOTE 2 Evidence can be a document that demonstrates a redundancy requirement has been physically
implemented in a component. It can also be operator and training manuals.
a) An artefact consisting of tangible data or information which includes the following:
1) description of items produced by the life cycle processes of the system of interest, such as
contracts and design descriptions;
2) reports provided by the activities of the system of interest, as listed in ISO/IEC/IEEE 15289:2019,
7.6;
5
© ISO/IEC 2022 – All rights reserved
© IEEE 2022 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC/IEEE 15026-2:2022(E)
3) record provided by the activities of the system of interest, as listed in ISO/IEC/IEEE 15289:2019,
9.3;
4) authoritative documents such as laws, standards and scientific documents on established
theory, history, and observations;
b) scope of applicability of the evidence;
c) uncertainty, including the credibility of its source (e.g. authenticity, trustworthiness, and
competence) and the measurement accuracy;
d) assumptions associated with the evidence.
NOTE 3 An evidence item can exist independently of the assurance case before its construction, or can be
newly created or collected for the purpose of constructing the assurance case. A description of preparation for
collecting an evidence item, such as field data, can be another evidence item. An evidence item is to support a
claim in the assurance case, as indicated in the definition of argument type (5.3.5).
NOTE 4 The artefact can become quite large. In such cases, the artefact is organized, located, and presented to
be understandable to those who review, approve, or directly use it.
NOTE 5 When evidence items are created in developing the assurance case, it is more convenient for them to
be managed independently of the arguments.
NOTE 6 Multiple assumptions in d) are taken as their conjunction.
NOTE 7 Evidence and claims are related by supported claim. Additional explanation can be given in a context
of that supported claim.
5.3.3 Claim type
The claim type is the type of claim as defined by ISO/IEC/IEEE 15026-1:2019, 3.1.4.
NOTE There are different ways of stating claims: by the probability of the claim being false, or the probability
of a situation invalidating the claim occurring or, by the duration for which the claim is valid.
EXAMPLE 1
−3
Failure rate of the memory board is less than 10 failures per year. (This is an example of limitation on the value
of the property associated with the claim. See Note 2 to entry of ISO/IEC/IEEE 15026-1:2019, 3.1.4).
EXAMPLE 2
The certificate for authentication is valid until 2020-12-31. (This is an example of limitations on duration of the
claim's validity associated with the claim. See Note 2 to entry of ISO/IEC/IEEE 15026-1:2019, 3.1.4).
EXAMPLE 3
−3
Probability of occurrence of a specific hazard in a year is less than 10 . (This is an example of condition-related
uncertainty. See Note 2 to entry of ISO/IEC/IEEE 15026-1:2019, 3.1.4).
EXAMPLE 4
The code coverage of the software testing is 99 % but the correctness of remaining 1 % is reviewed by the
supplier. (This is an example of limitations on the uncertainty of the property value meeting its limitations. See
Note 2 to entry of IS
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.