It happened! Your company just pushed your new software product out. Months (or years?) of hard work culminate into this single moment. Your “baby” is now out in the wild – there to fend for itself.

It is perfect. You know it is. You and your team are using the latest in safety-rigid development life-cycles. You even pushed back your release date to finish your extensive test suite. There can’t possibly be a safety issue with your software.

The phone rings. There’s been an “incident”.

Safety in software is a troublesome topic. Much of safety testing and “assurance” relies on subjective and incomplete data or processes. These may leave significant voids in the identifying, analysis, and mitigation of safety “threats”. Test cases rely on the developer thinking of the possible ways that the test subject could be used, but what if the safety threat came from “legitimate” (passed validation) user input?

Tim Kelly argues that Safety Assurance Cases may be able to fill in the gap – and more.

Safety Assurance Cases are evidence-based arguments that prove (or disprove) the safety of a software system in a given context. They include technical and non-technical aspects of the system. This allows them to identify more than just the safety threats associated with validation, etc.

Kelly et al, in the paper “Introducing Safety Cases for Health IT”, describe the Safety Assurance Case in respect to the healthcare field. They discuss the evolution of the Safety Assurance Case along with the software (from requirements to deployment and maintenance). The process of claims is supported by arguments that are further supported by evidence. At the highest level is a claim about the overall safety objectives. This claim is supported by a series of arguments that further claim that some sub-aspect has been addressed. These arguments are further supported by evidence about the sub-aspects being addressed.

What Safety Assurance Cases do is give a solid argument for the safety of a system. They also identify weaknesses in the safety arguments of a system that may require additional evidence to support. Thus a Safety Assurance Case contributes externally and internally for the purpose of safety in the software system.