ISO/IEC/IEEE FDIS 30982

• Status: Not Published
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 6 - Software Product and System Quality
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 01-Jun-2026
• Completion Date: 01-Jun-2026

Overview

ISO/IEC/IEEE FDIS 30982:2026 provides a standardized approach for defining, collecting, and analyzing measures of the software aspects of dependability. Developed collaboratively by ISO, IEC, and IEEE, this international standard sets out essential terminology, requirements, and methodologies to support consistent and actionable quantification of key dependability attributes in software systems: reliability, availability, supportability, and recoverability.

Addressing the growing reliance on software in critical and complex environments, this standard establishes a unified measurement framework that is applicable throughout a system's life cycle. It delivers guidance to software and systems engineers, system operators, stakeholders, and anyone concerned with evaluating or improving the dependability of software-intensive systems.

The standard can be leveraged in a wide range of industries including communications, healthcare, finance, energy, defense, transportation, and environmental management, where high dependability of software systems is essential.

Key Topics

ISO/IEC/IEEE FDIS 30982 covers several fundamental areas relevant to software dependability measurement:

• Definitions and Scope:

  • Provides clear definitions of reliability, availability, supportability, and recoverability as they pertain to software.
  • Establishes the context for in-service dependability measurement, addressing all application domains and system environments.

• Measurement Framework:

  • Presents the In-Service Reference Model (ISRM) to guide uniform identification of measurable behaviors and actions.
  • Introduces a reliability class model for differential analysis, supporting nuanced assessments of dependability.

• Variables and Equations:

  • Details variables and sample equations used to quantitatively characterize software dependability attributes.
  • Stresses the importance of explicit, measurable requirements as prerequisites for effective dependability assessment.

• Data Collection and Analysis:

  • Outlines best practices for gathering and interpreting dependability data across the software life cycle.
  • Provides guidance on ensuring consistency and accuracy in dependability measurements.

• Exclusions:

  • This standard focuses on in-service measurement and does not delve into pre-release reliability prediction, dependability engineering techniques, or maintenance strategies.

Applications

Adhering to ISO/IEC/IEEE FDIS 30982 offers immediate practical benefits across many software engineering contexts:

• Operational Effectiveness Evaluation: Measure and benchmark the dependability of deployed software systems to ensure they meet service-level objectives.
• Risk Management: Inform maintenance planning, proactive support, compliance, and resource allocation based on quantitative dependability data.
• Quality Assurance: Improve corrective and preventive actions (CAPA) by integrating dependable measurement data into quality management systems.
• Service Monetization and Regulatory Compliance: Provide evidence-based metrics for stakeholder reports, compliance submissions, and optimization of software-driven services.
• Development Lifecycle Support: Apply dependability measurements during requirements engineering, system design, verification, and validation to predict operational performance and identify potential risks.

Sectors Benefitting from the Standard:

• Critical infrastructure (communications, energy, water management)
• Healthcare and medical devices
• Financial transaction and real-time systems
• Transportation and logistics
• Environmental monitoring and industrial automation

Related Standards

ISO/IEC/IEEE FDIS 30982 aligns with and references several key international standards to provide a comprehensive dependability measurement framework:

• IEEE Std 982™-2024: The corresponding IEEE standard for measures of the software aspects of dependability.
• ISO/IEC/IEEE 1633:2016: Recommended practice on software reliability, relevant to pre-release prediction and dependability engineering.
• ISO/IEC/IEEE 14764:2022: Standard for software maintenance processes.
• ISO/IEC/IEEE 90003:2018: Guidance for quality management systems in software products.
• ISO/IEC JTC 1/SC 7: Subcommittee focusing on software and systems engineering standards.

By implementing ISO/IEC/IEEE FDIS 30982, organizations can achieve consistent and actionable assessment of software dependability and underpin informed decision-making in the development, operation, and evolution of critical software systems. This deepens trust in software-driven processes and services and strengthens risk and quality management in a world increasingly reliant on robust software solutions.

FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
ISO/IEC JTC 1/SC 7
Software engineering — Standard
Secretariat: BIS
for measures of the software
Voting begins on:
aspects of dependability
2026-06-01
Voting terminates on:
2026-10-19
This document has not been edited by the ISO Central Secretariat.
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
FAST TRACK PROCEDURE
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
ISO/IEC JTC 1/SC 7
Software engineering — Standard
Secretariat: BIS
for measures of the software
Voting begins on:
aspects of dependability
Voting terminates on:
This document has not been edited by the ISO Central Secretariat.
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPORTING D OCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
© IEEE 2026
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
FAST TRACK PROCEDURE
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
TO BECOME STAND ARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: [e-mail]
Website: www.ieee.org
Published in Switzerland Reference number
© IEEE 2024
© IEEE 2026 – All rights reserved
ii
ISO/IEC/IEEE 30982:2026(en)
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.
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the process and establishes
rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test,
or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
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 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.
ISO/IEC/IEEE 30982 was prepared by the LAN/MAN of the IEEE Computer Society (as IEEE Std 982™-2024)
and drafted in accordance with its editorial rules. It was adopted, under the “fast-track procedure” defined in
the Partner Standards Development Organization cooperation agreement between ISO and IEEE, by Joint
Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems
engineering.
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.
© IEEE 2024 – All rights reserved
iii
IEEE Std 982™-2024
(Revision of IEEE Std 982-2005)
IEEE Standard for Measures of the
Software Aspects of Dependability
Developed by the
Software & Systems Engineering Standards Committee
of the
IEEE Computer Society
Approved 26 September 2024
IEEE SA Standards Board
ISO/IEC/IEEE 30982:2026(en)
Abstract: Definitions, sample requirements, equations, and guidance for data collection and analysis
necessary to make consistent and actionable measurements of a software system’s reliability,
availability, supportability, and recoverability are provided in this document. The dependability of
software systems is collectively defined by these characteristics.
Keywords: availability, dependability, IEEE 982™, measurement, recoverability, reliability,
supportability
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 1 November 2024. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers,
Incorporated.
PDF: ISBN 979-8-8557-1326-8 STD27387
Print: ISBN 979-8-8557-1327-5 STDPD27387
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit https:// www.ieee .org/ about/ corporate/ governance/ p9 -26 .html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
ISO/IEC/IEEE 30982:2026(en)
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE Standards documents are made available for use subject to important notices and legal disclaimers. These
notices and disclaimers, or a reference to this page (https://standards .ieee.or g/ ipr/ disclaimers.html ), appear in
all IEEE standards and may be found under the heading “Important Notices and Disclaimers Concerning IEEE
Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers involved in technical working groups
are not necessarily members of IEEE or IEEE SA and participate without compensation from IEEE. While
IEEE administers the process and establishes rules to promote fairness in the consensus development process,
IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness
of any judgments contained in its standards.
IEEE makes no warranties or representations concerning its standards, and expressly disclaims all warranties,
express or implied, concerning all standards, including but not limited to the warranties of merchantability,
fitness for a particular purpose and non-infringement IEEE Standards documents do not guarantee safety,
security, health, or environmental protection, or compliance with law, or guarantee against interference with
or from other devices or networks. In addition, IEEE does not warrant or represent that the use of the material
contained in its standards is free from patent infringement. IEEE Standards documents are supplied “AS IS”
and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments received
from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity, nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document should rely upon their
own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate,
seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: THE
NEED TO PROCURE SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
ISO/IEC/IEEE 30982:2026(en)
Translations
The IEEE consensus balloting process involves the review of documents in English only. In the event that
an IEEE standard is translated, only the English language version published by IEEE is the approved IEEE
standard.
Use by artificial intelligence systems
In no event shall material in any IEEE Standards documents be used for the purpose of creating, training,
enhancing, developing, maintaining, or contributing to any artificial intelligence systems without the express,
written consent of IEEE SA in advance. “Artificial intelligence” refers to any software, application, or other
system that uses artificial intelligence, machine learning, or similar technologies, to analyze, train, process, or
generate content. Requests for consent can be submitted using the Contact Us form.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board Operations
Manual is not, and shall not be considered or inferred to be, the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE or IEEE SA. At
lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards
shall make it clear that the presenter’s views should be considered the personal views of that individual rather
than the formal position of IEEE, IEEE SA, the Standards Committee, or the Working Group. Statements
made by volunteers may not represent the formal position of their employer(s) or affiliation(s). News releases
about IEEE standards issued by entities other than IEEE SA should be considered the view of the entity issuing
the release rather than the formal position of IEEE or IEEE SA.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations, consulting
information, or advice pertaining to IEEE Standards documents.
Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is
important that any responses to comments and questions also receive the concurrence of a balance of interests.
For this reason, IEEE and the members of its Societies and subcommittees of the IEEE SA Board of Governors
are not able to provide an instant response to comments or questions, except in those cases where the matter
has previously been addressed. For the same reason, IEEE does not respond to interpretation requests. Any
person who would like to participate in evaluating comments or revisions to an IEEE standard is welcome to
join the relevant IEEE SA working group. You can indicate interest in a working group using the Interests tab
in the Manage Profile and Interests area of the IEEE SA myProject system. An IEEE Account is needed to
access the application.
Comments on standards should be submitted using the Contact Us form.
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not constitute compliance to any applicable regulatory
Available at: https:// development.standards .ieee.or g/ myproject-web/ public/view .html#landing .
Available at: https:// standards .ieee .org/ about/contact/ .
ISO/IEC/IEEE 30982:2026(en)
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
compliance with applicable laws, and these documents may not be construed as doing so.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and
data ownership in the context of assessing and using the standards in compliance with applicable laws and
regulations.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under US and international copyright laws. They
are made available by IEEE and are adopted for a wide variety of both public and private uses. These include
both use by reference, in laws and regulations, and use in private self-regulation, standardization, and the
promotion of engineering practices and methods. By making these documents available for use and adoption
by public authorities and private users, neither IEEE nor its licensors waive any rights in copyright to the
documents.
Photocopies
Subject to payment of the appropriate licensing fees, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual, non-
commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; [phone]; https://www .copyright
.com/ . Permission to photocopy portions of any individual standard for educational classroom use can also be
obtained through the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10 years old
and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some
value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have
the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended through
the issuance of amendments, corrigenda, or errata, visit IEEE Xplore or contact IEEE. For more information
about the IEEE SA or IEEE’s standards development process, visit the IEEE SA Website.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard number and
year of approval to access the web page of the published standard. Errata links are located under the Additional
Resources Details section. Errata are also available in IEEE Xplore. Users are encouraged to periodically
check for errata.
Available at: https:// ieeexplore.iee e .org/ browse/ standards/ collection/ieee .
Available at: https:// standards .ieee .org/ standard/index .html.
ISO/IEC/IEEE 30982:2026(en)
Patents
IEEE standards are developed in compliance with the IEEE SA Patent Policy.
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE
SA Website at https://standards .ieee.or g/ about/sasb/ patcom/patents .html. Letters of Assurance may indicate
whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation
or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries
into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions
provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are
reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the
validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility.
Further information may be obtained from the IEEE Standards Association.
IMPORTANT NOTICE
Technologies, application of technologies, and recommended procedures in various industries evolve over
time. The IEEE standards development process allows participants to review developments in industries,
technologies, and practices, and to determine what, if any, updates should be made to the IEEE standard.
During this evolution, the technologies and recommendations in IEEE standards may be implemented in ways
not foreseen during the standard’s development. IEEE standards development activities consider research
and information presented to the standards development group in developing any safety recommendations.
Other information about safety practices, changes in technology or technology implementation, or impact
by peripheral systems also may be pertinent to safety considerations during implementation of the standard.
Implementers and users of IEEE Standards documents are responsible for determining and complying with all
appropriate safety, security, environmental, health, data privacy, and interference protection practices and all
applicable laws and regulations.
Available at: https:// standards .ieee .org/ about/sasb/ patcom/materials .html .
ISO/IEC/IEEE 30982:2026(en)
Participants
At the time this draft standard was completed, the Standard for Measures of Software Aspects of Dependability
Working Group had the following membership:
Robert Binder, Chair
Pieter Botman Louis Gullo Ann Marie Neufelder
Lynn Robert Carter Jon Hagar Joanna Olszewska
Sigrid Eldh Pratap Lakshman Annette Reilly
Michael Grottke Phillip Laplante Rob Schaaf
The following members of the individual Standards Association balloting group voted on this standard.
Balloters may have voted for approval, disapproval, or abstention.
Boon Chong Ang Louis Gullo Thomas Owens
Jon Hagar Howard Penrose
Butch Anton
Robert Binder Sheri Harshberger Rajaraman
Juris Borzovs Werner Hoelzl Ramachandran
Pieter Botman Ronald Jarrett R. K. Rannow
Lawrence Catchpole Piotr Karocki Annette Reilly
Zhiman Chen Madhav Krishna Robert Schaaf
Diego Chiozzi Xiao Liang Jhony Sembiring
Scott Crawford Murray Little Thomas Starai
Ronald Dean Johnny Marques Walter Struppler
Kurniawan Diharja Roberto Moreno John Vergis
David Fuschi Rajesh Murthy Oren Yuen
Emanuel Grant Andrew Nack Janusz Zalewski
Joanna Olszewska
When the IEEE SA Standards Board approved this standard on 26 September 2024, it had the following
membership:
David J. Law, Chair
Jon Walter Rosdahl, Vice Chair
Gary Hoffman, Past Chair
Alpesh Shah, Secretary
Sara R. Biyabani Hao Hu Paul Nikolich
Ted Burse Yousef Kimiagar Robby Robson
Stephen Dukes Joseph L. Koepfinger* Lei Wang
Doug Edwards Howard Li F. Keith Waters
J. Travis Griffith Xiaohui Liu Sha Wei
Guido R. Hiertz John Haiying Lu Philip B. Winston
Ronald W Hotchkiss Kevin W. Lu Don Wright
Hiroshi Mano
*Member Emeritus
ISO/IEC/IEEE 30982:2026(en)
Introduction
This introduction is not part of IEEE Std 982-2024, IEEE Standard for Measures of the Software Aspects of
Dependability.
Reliance on software in all manner of critical systems has increased tremendously since the previous version
of this standard was issued, as have concerns regarding growing cyber threats. The expanding dialog on
software dependability and the increasing body of work in software assurance call for a broader perspective
and a revision of this standard to ensure its continuing relevance. Therefore, the revised standard updates and
augments the set of measurable attributes of the software aspects of dependability while acknowledging the
significance of prior work, preserving its rigor, and retaining essential measures and concepts.
This standard provides equations and definitions to characterize in-service dependability along with guidance
to develop these measurements. It presents a unified framework for measurement of quality characteristics
evidenced by system behavior, including functionality, performance, safety, and security; and by the time
consumed by certain kinds of support actions. The intended audience for this standard is primarily software
and systems engineers; persons operating or supporting software systems; sponsors, managers, and users of
software systems; researchers and other parties interested in software systems.
Dependability measurements, produced at any life cycle stage, can be used for many purposes: evaluation
of operational effectiveness, evidence for key performance indicators, service level management, service
monetization, system health monitoring, troubleshooting, identification of product gaps and opportunities,
failure identification and mitigation, dependability prediction, allocating resources for support, and regulatory
compliance.
Although this standard focuses on in-service measurement, its definitions can also be applied during
development. Such pre-release measurements are essential to guide system engineering, manage development
activities, improve development processes, predict operational dependability, and assess post-release risks.
As part of a quality management system, development and operational dependability measurements can be
used to manage risks and as an input for preventative and correction actions for process improvement.
This standard supersedes and completely replaces inactive standard IEEE Std 982.1™-2005, IEEE Standard
Dictionary of Measures of the Software Aspects of Dependability, which replaced IEEE Std 982.1™:1988,
IEEE Standard Dictionary of Measures to Produce Reliable Software.
ISO/IEC/IEEE 30982:2026(en)
Contents
1. Overview . 10
1.1 Scope . 10
1.2 Purpose . 10
1.3 Applicability . 10
1.4 Word usage . 12
2. Normative references . 13
3. Definitions, acronyms, and abbreviations . 13
3.1 Definitions . 13
3.2 Acronyms and abbreviations . 19
4. Dependability measurement model . 21
4.1 Dependability is a composite quality characteristic . 21
4.2 System of interest (SOI) . 21
4.3 Content and role of dependability requirements . 22
4.4 Dependability requirements . 24
4.5 In-service reference model (ISRM) . 26
4.6 Timing . 31
4.7 Abstract data model . 35
5. Dependability measures . 36
5.1 Reliability . 36
5.2 Availability . 48
5.3 Supportability . 60
5.4 Recoverability . 62
Annex A (informative) Bibliography . 67
ISO/IEC/IEEE 30982:2026(en)
IEEE Standard for Measures of the
Software Aspects of Dependability
1. Overview
1.1 Scope
This standard identifies, classifies, and defines measures of the software aspects of in-service dependability.
As such, it provides a framework for stakeholders to understand the software aspects of dependability and to
make dependability measurements throughout the system life cycle.
It provides definitions, requirements, and guidance for the data collection and analysis necessary to make
consistent and actionable measurements of a software system’s reliability, availability, supportability, and
recoverability.
This standard is applicable to any software system or service. It is particularly useful for critical systems where
the reliability of their safety, security, functionality, performance, and utilization, as well as recoverability,
supportability, and availability are foremost. Examples of critical systems include those supplying
communications infrastructure, first responder services, energy production and distribution, real time financial
transactions, medical devices, health care administrative services, defense capabilities, personal and mass
transportation, environmental monitoring, and water and waste management.
1.2 Purpose
The purpose of this standard is to establish guidance for measuring the software aspects of dependability as
applicable to a system's operational context. It is intended for in-service measurement. It may be used during
requirements, architecture, and design development; software construction and integration; and verification
and validation of the software products of these activities. The overall objective is to enable stakeholders to
measure dependability in software intensive systems throughout software operations and maintenance.
1.3 Applicability
This standard is intended for use in any domain of software application, whether user-facing or embedded,
including personal convenience, real-time control, medical devices, high-volume transaction processing,
high-performance numerical computing, data communications, industrial control, or artificial intelligence,
to name a few. It is intended for use with any kind of computer hardware, runtime stack (operating system),
or programming language; or in any computing infrastructure including personal computers, smartphones,
on-board embedded devices, industrial controllers, edge devices, network operations centers, or data centers.
ISO/IEC/IEEE 30982:2026(en)
IEEE Std 982-2024
IEEE Standard for Measures of the Software Aspects of Dependability
As a catalog of measures, this standard:
— Defines variables and equations to quantitatively characterize the software aspects of dependability:
reliability, availability, supportability, and recoverability.
— Presents the in-service reference model (ISRM), a framework for uniform identification of system
behaviors and support actions to be measured.
— Presents the reliability class model to support consistent and extensible differential analysis of the
effects of anomalies and failures on the reliability of safety, security, functionality, performance, and
utilization.
— Defines downtime subsets for certain types of activity (slices), providing insight into factors
contributing to availability and supportability.
— Calls for explicit and bounded dependability requirements as a prerequisite for measurement and
therefore provides normative criteria and guidance for their development and use.
It does not address other pre-release development practices including 1) software reliability prediction, 2)
software engineering techniques for improving dependability, or 3) software maintenance.
IEEE Std 1633™-2016, Recommended Practice on Software Reliability [B15] provides a thorough resource
for topics 1 and 2. ISO/IEC/IEEE Std 14764:2022, Software engineering—Software life cycle processes—
Maintenance [B21] likewise addresses topic 3.
Although this standard calls for well-formed and complete expressions of capability and dependability
requirements, it does not address how to set specific levels of reliability, availability, supportability, or
recoverability for any system or class of systems. It does not address how to develop software artifacts that
achieve acceptable levels of functionality, performance, utilization, fault-tolerance, security, or safety.
This standard contains notional examples of requirement statements for reliability, availability, supportability,
and recoverability. These are informative and not requirements of this standard.
Certain software engineering and operational processes, practices, and artifacts tend to result in higher
dependability; their absence tends to result in lower dependability (Bourque and Fairley [B3]). Although
general principles of software engineering for dependability are well-established, specific practices evolve
and become irrelevant, often rapidly. This standard therefore focuses on defining useful measures of in-service
dependability, regardless of the developmental and operational practices applied to a system of interest (SOI).
NOTE—IEEE 1012™-2016 [B13] provides guidance for requirements-based verification and validation of software/
hardware systems.
Often, identical copies of a software system are installed on numerous host computers. A population of
deployed instances often has substantial variation in versions, configuration, operating conditions, and usage
patterns. This variation typically has material effects on the dependability of any given instance. When this
standard was revised, no generally accepted and validated techniques or models for measuring dependability
of a software population were published and proven in practice. Therefore, this standard’s dependability
measurements are limited to a single instance of a system in a particular context; it does not address obtaining
or characterizing population dependability measurements.
The numbers in brackets correspond to those of the bibliography in Annex A.
Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this
standard.
ISO/IEC/IEEE 30982:2026(en)
IEEE Std 982-2024
IEEE Standard for Measures of the Software Aspects of Dependability
Consistent and accurate measurements of in-service dependability and other quality attributes are essential for
effective corrective and preventative actions (CAPA) in all software life cycle stages. Software product and
process improvement through CAPA is a well-established and well-documented best practice. This standard
therefore does not address CAPA.
NOTE—ISO/IEC/IEEE 90003:2018 [B18] provides comprehensive guidance for establishing a quality management
system for software products and identifying software-related CAPAs.
This standard does not attempt to provide a mathematically formal and complete model for a measurement
system, its abstract functions, or its binding to any data management system. It does not identify techniques to
obtain logs or records of events from any specific software SOI or runtime environment.
To characterize dependability, this standard is focused on the classification and quantitative characterization
(analysis) of certain operational activities and system behaviors from an external observer’s perspective.
Except to the extent necessary to make these measurements, it does not address other engineering or
operational topics that may affect or depend on the nature or degree of these behaviors. It does not address
characterizations of source-code, software architecture, or development practices, as they do not produce in-
service behavioral data. Although some implementation measurements have been shown to be useful leading
indicators of in-service dependability, many application-specific factors can confound these predictions (Hall,
Beecham, Bowes, Gray, and Counsell [B9]).
Most extant definitions of software system trustworthiness include some or all of the dependability
measurements defined in this standard (Newman [B30]). They also call for evidence to support claims that
a system is sufficiently unlikely to behave in an anomalous, insecure, or harmful manner, and that its future
behavior is likely to be consistent with socio-technical norms. These claims may be supported by evidence or
analysis of any phenomena deemed relevant (Cho, Chan, and Adali [B3]). The observational measurements of
this standard can provide some of this evidence, but do not address the broad scope of artifacts and activities or
the subjective characterizations necessary to judge system trustworthiness.
1.4 Word usage
The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard
8,9
and from which no deviation is permitted (shall equals is required to).
The word should indicates that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily
required (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals
is permitted to).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can
equals is able to).
The use of the word must is deprecated and cannot be used when stating mandatory requirements; must is used only to describe
unavoidable situations.
The use of will is deprecated and cannot be used when stating mandatory requirements; will is only used in statements of fact.
ISO/IEC/IEEE 30982:2026(en)
IEEE Std 982-2024
IEEE Standard for Measures of the Software Aspects of Dependability
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments or corrigenda) applies.
10,11,12,13
ISO/IEC/IEEE 15939, Systems and software engineering—Measurement process.
ISO/IEC/IEEE 24765, Systems and software engineering—Vocabulary.
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary
Online should be consulted for terms not defined in this clause. Definitions for other system and software
engineering terms can be found in ISO/IEC/IEEE 24765, available at .
abnormal termination: Uncommanded cessation of software execution, typically resulting in a terminal
failure. Syn: abend, blue screen, crash, dump, panic.
absolute time: A tick in a generally agreed chronological frame of reference. Contrast: relative time, natural
unit.
EXAMPLE—a calendar date and time of day in a given reference time zone, such as Coordinated Universal
Time (UTC).
abstract behavior: A description, model, or other general characterization of similar behaviors.
NOTE—There are many representations that express abstract behavior, for example, use cases, protocol message types,
sequence diagram messages, and interface control documents.
adaptive support: Modification of an in-service SOI performed after installation to keep it usable in a changed
or changing runtime environment. (Adapted from IESO/IEC/IEEE 14764:2022 [B21])
additive support: Modification of an in-service system performed after installation to add functionality or
features to a system instance. (Adapted from IESO/IEC/IEEE 14764:2022 [B21])
NOTE—In contrast to perfective support, additive support results in new functions or features.
anomaly: A judgment that a system’s behavior or artifact deviates from expectations based on 1) the system’s
high-level goals for outcomes, similar requirements, development or operational documentation, 2) applicable
standards, regulations, or laws, or 3) an observer’s perceptions or experiences.
NOTE—An anomaly can result in a revealed requirement.
ISO publications are available from the International Organization for Standardization (https://www .iso .org/ ) and the American
National Standards Institute (https://www .ansi .org/ ).
IEC publications are available from the International Electrotechnical Commission (https://www .iec.ch ) and the American National
Standards Institute (https://www .ansi .org/ ).
IEEE standards and products are trademarks owned by The Institute of Electrical and Electronics Engineers, Incorporated.
IEEE publications are available from The Institute of Electrical and Electronics Engineers (https://standards .ieee.or g/ ).
IEEE Standards Dictionary Online is available at: http://dictionary .ieee.or g. An IEEE Account is required for access to the dictionary,
and one can be created at no charge on the dictionary sign-in page.
Information on references can be found in Clause 2.
ISO/IEC/IEEE 30982:2026(en)
IEEE Std 982-2024
IEEE Standard for Measures of the Software Aspects of Dependability
availability: The ratio of uptime divided by the sum of uptime plus downtime, that is,
uptime / (uptime + downtime) .
NOTE 1—In the ISRM, the proportion of an in-service span during which an SOI is in READY or RUNNING mode.
NOTE 2—Availability is a quantitative component of dependability, expressed as a requirement parameter (threshold),
as a probability (prediction or estimate), or as a measurement obtained during test or in-service operation (observation).
behavior: An observable sequence of inputs and outputs for a system, sufficient to evaluate compliance with
its requirements, or for an observer to identify an anomaly. (Adapted from ISO/IEC/IEEE 24765)
blocking bug: A software defect that obstructs further work on a particular task or feature until it is resolved.
capability requirement: A requirement that specifies a condition or behavior that a system is to achieve under
stated conditions. Contrast: dependability requirement.
configuration item (CI): Unit or aggregation of hardware, software, or both that is designated for configuration
management and treated as a single entity in the configuration management process.
NOTE—Although a flat file is the most commonly used software configuration item, item
...