This pattern provides the structure for arguments that the contributions made by software to system hazards are acceptably managed.
Author: Richard Hawkins
Last update: 8/6/2009DOWNLOAD THE 'SOCSSAP' PATTERN
It is necessary to consider all of the ways in which errors may be introduced into the software which could lead to the software contribution. The software development process used will vary between different projects, however in all cases the software development is undertaken through varying levels of design. At each level the design must satisfy requirements of the higher level. These requirements may be explicitly captured as part of a requirements specification, or identified implicitly from the design itself. In  Jaffe et al propose an extensible model of development which captures this relationship between components at different tiers. Figure 1 illustrates the multi-tiered relationship between successively more detailed requirements and design information. Figure 2 illustrates in more detail the relationship among a tier n component’s requirements, its design representation, and the tier n+1 requirements of the tier n+1 (sub) components identified in the design representation.From a safety perspective, it is necessary to ensure that at each tier, the software safety requirements derived at the previous tier are adequately addressed. This involves making design decisions which mitigate potential failures and adequately allocating and decomposing the software safety requirements (SSRs) through consideration of the design at that tier. At each tier it is also possible to introduce errors into the software which could manifest themselves as hazardous failures. It is therefore important in the software safety argument to also consider additional hazardous contributions that may be introduced at each tier.This pattern therefore reflects the tier model discussed above in order to make it generally applicable to a broad range of development processes.