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

Status
Published
Publication Date
06-Nov-2022
Current Stage
6060 - International Standard published
Due Date
19-Aug-2023
Completion Date
07-Nov-2022
Ref Project

RELATIONS

Buy Standard

Standard
ISO/IEC/IEEE 15026-2:2022 - Systems and software engineering — Systems and software assurance — Part 2: Assurance case Released:7. 11. 2022
English language
20 pages
sale 15% off
Preview
sale 15% off
Preview

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
© 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.

© 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.
© 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 .
© 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.

© 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

© 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,
© 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.
© 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;
© 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

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

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.