E.5.1 Introduction. This section gives guidance on the different parts that make up a
Software Safety Case, the suggested contents of each part and how these parts should be developed as the project progresses.
E.5.2 System and design aspects
E.5.2.1 This part, in conjunction with the software safety requirements and software
description, should give sufficient information to allow the safety arguments to be understood.
E.5.2.2 The contents should be derived from the Software Requirement and include:
(a) an overview of the system architecture including the system boundaries and interfaces; (b) an overview of the system functions;
(c) a brief description of the operating environment including both normal and abnormal modes of operation;
(d) a list of the main system safety requirements;
(e) a description of the system design approach (eg dual channel, fault tolerant hardware).
E.5.2.3 This information should be available for the preliminary version of the Software
Safety Case. It should be updated in later versions if any system or design aspect changes.
E.5.3 Software safety requirements
E.5.3.1 The contents of this part should be extracted from the Software Requirement and
should describe the role that the software plays in ensuring safety. The contents should include a list of the functional and non- functional software safety requirements that have been derived from the equipment safety requirements by a process similar to that shown in
E.5.3.1 (Cont)
together with any required software standards (eg configuration management, programming language definition). There should be traceability between the system and software safety requirements.
E.5.3.2 This information should be available for the preliminary version of the Software
Safety Case. The interim Software Safety Case should be updated if the process of writing a formal specification for the software results either in new safety requirements on the software being derived or the safety requirements being refined in some way. The operational
Software Safety Case should incorporate any new or changed safety requirements.
E.5.4 Software description
E.5.4.1 The contents of this part should be derived from the Software Design and should
describe the architecture of the software and how this contributes towards safety. The contents should include:
(a) an overview of the software architecture (eg main subsystems and their functionality); (b) a description of the main design features of the software (eg real-time aspects, user interfaces, key algorithms, communication protocols, interfaces, database);
(c) the means by which software of different safety integrity levels is segregated (if relevant).
E.5.4.2 This information may not be available and will not be complete for the preliminary
and interim Software Safety Case. The status of the information made available in these two versions should be clearly indicated.
E.5.5 Safety arguments
E.5.5.1 This is the key part of the Software Safety Case. A safety argument should be given
justifying how each software safety requirement has been or will be met. Part 1 of this Standard requires a justification of the achieved safety integrity level to be given by means of two or more independent safety arguments with, as a minimum, one argument based on analysis and one based on the results of testing. E3 describes some approaches to building safety arguments.
E.5.5.2 This section should also include safety arguments that all reasonable measures have
been taken to reduce the software contribution to system hazards to an acceptable level.
E.5.5.3 The contents of this section should be derived from the technical approaches
described in the key planning documents (eg Software Safety Plan, Code of Design Practice and the Software V&V Plan).
E.5.5.4 This part should focus on the high-level safety arguments and should summarize and
reference the evidence upon which the safety arguments are based. A complete list of all assumptions used in constructing the safety arguments should be given. As safety arguments at the software level could form part of a safety argument at the system level, there should be traceability between the system and software safety arguments.
E.5.5.5 The safety arguments should largely be in place for the preliminary Software Safety
Case with later versions reflecting any refinements of the more detailed parts of the
arguments that have occurred as the project proceeds. The detailed evidence which supports the safety arguments will not all be available for the preliminary nor the interim versions as many of the project activities which generate that evidence will not have been carried out. Each version of the Software Safety Case should clearly state the status of the supporting evidence (ie whether it has been or is still to be collected).
E.5.6 SRS development process
E.5.6.1 This part should give a justification that the software development process is
adequate to achieve the required safety integrity level of the SRS. E4 gives guidance on how this justification is to be given.
E.5.6.2 This part should:
(a) briefly describe the main methods, tools and key project staff; (b) summarize the results of the Process Safety Analysis;
(c) describe and justify the use of any previously developed software (including COTS software);
(d) provide a measure of the performance of the software development process (this should include the process data measures described in E.4;
(e) give the results of any safety or quality audits carried out;
(f) provide an analysis of historical data on the safety integrity of software developed using the proposed or similar software development processes.
E.5.6.3 The results of safety and quality audits should be included with a note of any non-
compliances and recommendations identified by the auditor and the status of any corrective actions taken or a justification for taking no action.
E.5.6.4 The results of an internal company or independent assessment of software process
maturity for developing SRS should be also be included. Clearly, an independent assessment would provide the stronger evidence.
E.5.6.5 The results of the process safety analysis should be included in the preliminary
Software Safety Case. The other information should be added as it becomes available.
E.5.7 Current status This part should state progress against plan (Software Safety Plan and
Software Development Plan) and discuss any outstanding issues which may affect safety such as:
(a) any safety requirements which are not being met
(b) any new or unresolved hazards which could potentially be caused by the software (eg a potentially hazardous software failure found during testing whose cause has not been
E.5.8 Change history. This part should summarize any requirements changes which have
affected the software and their impact on the safety. Any significant changes to the safety arguments since the previous issue of the Software Safety Case should be described.
E.5.9 Compliance
E.5.9.1 A statement of compliance against this Standard and any other required software
standard should be given with a list of all non-compliances together with their status (eg agreed, under discussion).
E.5.9.2 It should not be necessary to include a full clause-by-clause analysis of compliance
although such an analysis should be done and recorded separately in the Software Safety Records Log.
E.5.9.3 This part should be available in the preliminary Software Safety Case and kept up to
date
E.5.10 In-service feedback
E.5.10.1 This part should summarize any relevant experience with the SRS or any part of it,
from realistic operational testing, trials or in-service usage. This should include an analysis of any software failures on the safety of the equipment, addressing the possible consequences (ie hazards, accidents), the cause of the failure and any remedial action taken (this should include not only fixing any software faults but process improvement actions).
E.5.10.2 This part will not normally form part of a Software Safety Case for a new system
under development. However, if this is a development or enhancement of an existing system then this part should be completed and the relationship between the changes and the in- service feedback should be discussed (eg the reason for the software being changed might be to remove a new hazard which was overlooked in the existing system).
E.5.11 Software identification. This part should identify the current release of the software
Process Safety Analysis Procedure