Assurance Cases (most commonly, Safety Cases) continue to gain traction across many industries, despite some notorious detractors (more on that in a future article, perhaps), but could you describe succinctly the purpose of an Assurance Case? Sure? Many professionals believe they can. In this article I’ll reveal the actual purpose of an Assurance Case, and assert why an accurate definition of that purpose matters.
There are in fact, four pillars of an Assurance Case, and through an understanding of each pillar, one can deliver a more complete, compelling and defensible Assurance Case. Although I’ll use the property of ‘safety’ as an exemplar (specifically ‘system safety’) the four pillars are applicable to any property of interest. Let’s get started…
I always ask every cohort of my Assurance Case Masterclasses to consider the purpose of an assurance case, and discuss it within their groups. They only get ten minutes to ponder and discuss, before one brave (nominated) soul from each group presents their agreed answer in turn. Almost without fail, each group’s spokesperson will deliver text plucked from one of the many standards or regulatory organisations. Something akin to “to deliver a reasoned artefact…blah….which contains and argument of…blah…ad nauseam …blah…” Know the excerpts I mean? That is perhaps what an Assurance Case is, but it does not describe its purpose. One cannot simply add blithely “to deliver a…” at the beginning of the description of an Assurance Case and hope to have successfully defined its purpose!
The purpose of an Assurance Case should define the reason for its existence – the ‘why’. This is the first pillar of an Assurance Case, in fact. There are four pillars of an Assurance Case, and these pillars can be thought of and expressed in the form of four questions:
- Why?
- What?
- Who?
- When?
Let’s consider each of these in turn.
Why?
The ‘why’ pillar is the purpose of the Assurance Case – the rationale for its very existence. So why do we have an Assurance Case? Communication. Communication of information to support decision-making, more specifically. If your Assurance Case is not constructed with the aim of informing decisions, then it is probable that you have developed an intriguing article of shelf ware.
The purpose of an Assurance Case is to communicate to relevant stakeholders, the assurance argument (and evidence) for the assurance of the property of interest of the entity which is the subject of the case. Using a Safety Case as an exemplar, this translates into an assurance argument for the assurance of <safety> of the <system> which is the subject of the safety case. With me so far? Excellent!
What?
The answer to this questions is that normally given by cohorts of the training course when asked the purpose of an Assurance Case .
WARNING: There is a difference between an Assurance Case and an Assurance Case Report. The former is the living, breathing artefact which is perpetually managed and maintained through life. The latter is a report into the state of the case at a particular point in time.
There are academics and professionals which fiddle with the definition of an Assurance Case in perpetuity. They all say the same thing more or less, so I’ll offer the versions from three well-known and reputable sources, before offering a version based on the experience my training colleague and I have gained over decades.
ISO and IEC:
In fear of copyright infringement please refer to that given in ISO/IEC 15026-1:2019 (Systems and Software Engineering – Systems and Software Assurance Part 1: Concepts and Vocabulary).
UK Ministry of Defence:
Unsurprisingly, the MoD’s focus is on Safety as the property of interest, and defines the case as a suite of data which provides evidence that the safety requirements are met and that all identified risks are tolerable and As Low as Reasonably Practicable (ALARP). I do wonder about the unidentified risks, however…
The MoD also provide a ‘what’ for an Assurance Case Report – this being “the means by which a Project demonstrates that all of the safety issues relating to a project have been brought to a condition appropriate to the stage in the lifecycle. It therefore provides the safety justification to support the major project milestones.”
The Military Aviation Authority (MAA) offer a derivative of the ‘what’ of a case – being the means to “provide the ability to understand the cumulative and / or interrelated risks from the use of [the] complex system.”
Rail
Unbelievably, and I genuinely cannot believe I’m writing this, but as of 2024, the rail regulator in the UK no longer requires an Assurance Case! They did formerly require a case to “demonstrate that [the] company has the necessary ability, commitment, and resources to assess and control the risks associated with its activities.”
In Our Humble Opinion
Years of experience, and with many Assurance Case Masterclass courses under our belts, our version of the ‘what’ of an Assurance Case is more helpfully defined first by what an Assurance Case is not. It is not a document, nor a justification of a predetermined conclusion, nor is it an accumulation of convenient evidence amassed in direct support of a desired outcome.
An Assurance Case is a collection of relevant information which aims to inform decision-making. An Assurance Case should help the stakeholder(s) understand the degree to which safety is achieved, and understand the basis on which the stakeholder(s) can have confidence in any claims of safety. Whist the ‘top goal’ aims to ‘prove’ safety, an Assurance Case should help the stakeholder(s) understand whether, and under what circumstances the system may not, in fact, be safe. Moreover, the case should enable the stakeholder(s) to understand what is meant by ‘safe’ in the context of the system and its intended operating environment.
Who?
Who requires an Assurance Case, then? We’ve already established that the purpose of an Assurance Case is to communicate pertinent information to stakeholders, but just who are these stakeholders, and what do they need?
Stakeholders
There are many different kinds of stakeholders; each has a vested interest in your Assurance Case, and each will have a different interest in the contents, and the level of detail in your Assurance Case. The key here, therefore is to consider the different stakeholders and the level of detail they require of the Assurance Case when you are constructing it (I’ll consider how different views of an Assurance Case can be constructed in future articles). When considering the contents, tone, and abstraction levels in your Assurance Case, make sure you have identified the:
- Audience:
- those who will consume and / or react to the case
- those who will make the decisions based on the case, and
- those who will identify the impact of decisions made because of the contents of the case.
- Author and / or editor. The author and editor may be the same person, or these roles may be fulfilled by different people. There may even be multiple authors and / or editors.
- Contributors. Whilst the content of an Assurance Case may be compiled by a single person, that person may require data from multiple other stakeholders. When planning your Assurance Case, it is vital therefore to establish what data you will need, where this data will emanate from, and when you will require it.
- Impacted. Whilst these stakeholders may never see your Assurance Case, they have a vested interest in its content, nonetheless. Think members of the public, passengers, and third parties.
- Interested parties. What if the worst happens when your system is let loose in the wild? Think emergency services, responders, and even local council departments.
When?
Hint: the answer is most certainly NOT just before the system enters service.
When should an Assurance Case be ‘delivered’ then? Assuming one is needed, of course. More complex systems and systems of systems will undoubtedly require multiple iterations of an Assurance Case AND an Assurance Case Report. Establishing when these iterations are needed will define the ‘when’ of an Assurance Case (or Assurance Case Report):
- When will information be available?
- When are the progressive design or developmental maturity milestones planned which the Assurance Case has to support?
- When do decisions need to be made?
To recap, there are four pillars of an Assurance Case:
- Why
- What
- Who, and
- When.
If these four pillars are not fully understood and provided for, one cannot hope to deliver a complete, compelling, and defensible Assurance Case, or Assurance Case Report.
