Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC 15026 — Systems and Software Engineering — Systems and Software Assurance Series
Systems and Software Engineering — Systems and Software Assurance (2011–2015 Editions, 4 Parts)
🛡️ BS ISO/IEC 15026 is the British Standard implementation, adopted by BSI, of the ISO/IEC 15026 international series prepared by Technical Committee IST/15 (Software and systems engineering), classified under ICS 35.080. The series provides a conceptual framework and engineering methods for systems and software assurance, covering concepts and vocabulary, assurance case, system integrity levels, and assurance in the life cycle. It is the standard foundation for trustworthiness arguments of high-safety and high-integrity systems (aerospace, nuclear, medical, autonomous driving, and critical-infrastructure software).
💡 “Assurance” is not simply testing or compliance; it is building a credible argument (Assurance Case) that a system satisfies specified properties (safety, security, reliability). BS ISO/IEC 15026 systematizes the construction, expression, and review of such arguments, making safety arguments auditable and traceable.
1. Series Overview 📌
The BS ISO/IEC 15026 series consists of several parts; this batch covers Parts 1, 2, 3, and 4. Part 1 covers concepts and vocabulary; Part 2 the assurance case; Part 3 system integrity levels; Part 4 assurance in the life cycle. The series supersedes the earlier technical report (PD ISO/IEC TR 15026-1:2010), elevating it to a full international standard, and is used alongside process standards such as ISO/IEC 12207 (software life cycle processes).
The series primarily serves assurance engineers and assurance managers of critical and safety-related system projects, safety assessment and audit bodies, applicants in regulatory approval processes, quality departments of system integrators and software suppliers, and university research teams studying assurance methods and argument patterns.
2. Structure and Technical Highlights 📋
| Standard | Title | Core Content |
|---|---|---|
| BS ISO/IEC 15026-1:2013 | Concepts and vocabulary | Definitions of assurance-related concepts, terms, and scope of application; conceptual basis of the series |
| BS ISO/IEC 15026-2:2011 | Assurance case | Structure, content, and expression of the assurance case, plus conformance requirements, for arguing system properties |
| BS ISO/IEC 15026-3:2015 | System integrity levels | Definition, establishment, and use of system integrity levels, supporting risk grading and assurance strength allocation |
| BS ISO/IEC 15026-4:2012 | Assurance in the life cycle | Requirements for carrying out assurance activities across the system and software life cycle (scanned version, written from public-domain knowledge) |
⚠️ BS ISO/IEC 15026-4 in this material is a scanned version; its description is written from public-domain knowledge of the standard. Please refer to the official BSI publication for the authoritative text.
3. Key Technical Requirements 🔧
The key technical requirements of the BS ISO/IEC 15026 series center on the assurance case and integrity levels:
- Assurance case (Part 2): specifies that an assurance case shall include claims, arguments, and evidence, with structured relationships among claim-argument-evidence forming an auditable safety argument.
- Property description: the assurance case shall state the system properties being assured (safety, reliability, security) and clarify their scope, context, and assumptions.
- Conformance requirements (Part 2): specifies conformance requirements ensuring arguments are complete, evidence sufficient, and corresponding to claims.
- Integrity levels (Part 3): specifies how to define integrity levels: graded by severity and likelihood of system failure consequences; higher levels require greater assurance strength.
- Life-cycle assurance (Part 4): specifies implementing assurance activities across requirements, design, implementation, verification, and operation/maintenance stages for “whole-life-cycle argumentability”.
🚨 The value of an assurance case lies in its credibility: if arguments contain unverified assumptions, evidence is disconnected from management activities, or claims are vaguely defined, the assurance case becomes hollow. An independent review mechanism must verify the validity of arguments and sufficiency of evidence.
4. Engineering Practice Applications 🛠️
In engineering practice, the BS ISO/IEC 15026 series is mainly applied to:
- 🔍 Safety-related system argumentation: safety-critical systems in aerospace, rail transit, and nuclear instrument control argue their safety via assurance cases, supporting regulatory licensing.
- 🔧 Medical and autonomous-driving software: medical device software and autonomous driving functions allocate assurance strength via integrity levels, meeting functional safety and cybersecurity requirements.
- 📊 Critical infrastructure assessment: information systems of power, water, and finance critical infrastructure use assurance cases to explain their resilience against cyber threats and failures.
- 📋 Supply chain and procurement assurance: buyers require suppliers to provide assurance cases and evidence chains, ensuring the safety and trustworthiness of delivered systems are verifiable.
✅ It is recommended that projects plan assurance activities at inception: define the properties to be assured, determine integrity levels per Part 3, build and maintain the assurance case per Part 2, and implement assurance evidence at each life-cycle stage per Part 4.
5. Frequently Asked Questions ❓
❓ Q: What is the difference between an assurance case and document-based argumentation?
A: An assurance case is a formal argument with structured claim-argument-evidence relationships, emphasizing traceability and auditability; ordinary document-based argumentation often lacks claim decomposition and evidence mapping, making it hard to systematically prove a property is satisfied.
A: An assurance case is a formal argument with structured claim-argument-evidence relationships, emphasizing traceability and auditability; ordinary document-based argumentation often lacks claim decomposition and evidence mapping, making it hard to systematically prove a property is satisfied.
❓ Q: How are integrity levels determined?
A: Determined by combining the severity of consequences (casualties, environmental damage, economic loss) and the likelihood of system failure; higher levels demand greater assurance activity intensity (deeper analysis, testing, review).
A: Determined by combining the severity of consequences (casualties, environmental damage, economic loss) and the likelihood of system failure; higher levels demand greater assurance activity intensity (deeper analysis, testing, review).
❓ Q: What does “conformance” mean in Part 2?
A: Conformance means the assurance case’s structure and content meet the standard’s format and semantics, including complete correspondence between claims and evidence, explicitly declared and reasonable assumptions in arguments, and no unsupported claims — enabling effective third-party review.
A: Conformance means the assurance case’s structure and content meet the standard’s format and semantics, including complete correspondence between claims and evidence, explicitly declared and reasonable assumptions in arguments, and no unsupported claims — enabling effective third-party review.
❓ Q: How do BS ISO/IEC 15026 and IEC 61508 (functional safety) relate?
A: IEC 61508 specifies concrete technical requirements for the functional safety life cycle, while BS ISO/IEC 15026 provides a general framework for assurance cases and integrity levels that can express functional safety arguments. They complement: 61508 says “what to do”, 15026 says “how to argue it has been done”.
A: IEC 61508 specifies concrete technical requirements for the functional safety life cycle, while BS ISO/IEC 15026 provides a general framework for assurance cases and integrity levels that can express functional safety arguments. They complement: 61508 says “what to do”, 15026 says “how to argue it has been done”.
❓ Q: Does an assurance case need to stay updated?
A: Yes. System changes (requirement changes, design modifications, vulnerability fixes) affect assurance arguments. The assurance case must be continuously maintained and re-reviewed as the system evolves, otherwise it becomes “stale argumentation” that misleads safety decisions.
A: Yes. System changes (requirement changes, design modifications, vulnerability fixes) affect assurance arguments. The assurance case must be continuously maintained and re-reviewed as the system evolves, otherwise it becomes “stale argumentation” that misleads safety decisions.