C.1.2 Method of use – 1
For guidance purposes, if it can be convincingly demonstrated that the desirable properties have been achieved in the development of the software safety requirements specification, then confidence is justified that the software safety requirements specification is an adequate basis for developing software that has sufficient systematic safety integrity.

Annex C Table C.1says that each of the Annex A Table A.1techniques typically achieves, to a greater or lesser extent, one or more of the above Table C.1properties that are relevant to the software safety requirements specification.

However, it is important to note that although Annex A Table A.1recommends specific techniques, these recommendations are not prescriptive, and in fact Annex A states clearly that “Given the large number of factors that affect software systematic capability it is not possible to give an algorithm for combining the techniques and measures that will be correct for any given application”.

In practice the techniques by which the software safety requirements specification is
developed are selected subject to several practical constraints (see 7.1.2.7) in addition to the inherent capabilities of the techniques. Such constraints may include:
– the consistency and the complementary nature of the chosen methods, languages and tools for the whole development cycle;
– whether the developers use methods, languages and tools they fully understand;
– whether the methods, languages and tools are well-adapted to the specific problems encountered during development.

Table C.1may be used to compare the relative effectiveness of the specific Annex A

Table A.1techniques in achieving the desirable properties of the software safety requirements specification lifecycle, while at the same time factoring in the practical constraints of the particular development project.

For example, a formal method is capable of giving a better basis (R3) for verification and validation than is a semi-formal method (R2), but other project constraints (e.g. the availability of sophisticated computer support tools, or the very specialized expressiveness of a formal notation) may favour a semi-formal approach.

In this way, the Table C.1desirable properties can provide the basis of a reasoned and
practical comparison of the alternative techniques that Annex A Table A.1recommends for developing the software safety requirements specification. Or more generally, a reasoned selection from the several alternative techniques recommended by Annex A for a particular lifecycle phase can be made by considering the desirable properties listed in the corresponding Annex C table.
But note carefully that due to the nature of systematic behaviour, these Annex C properties may not be achievable or demonstrable with the highest rigour. Rather, they are goals to be aimed for. Their achievement may even necessitate trade-offs between different properties e.g. between defensive design and simplicity.
Finally, in addition to defining R1 /R2/R3 criteria, it is useful for guidance purposes to make an informal link between (1 ) the increasing level of rigour of the R1 to R3 progression and (2) an increased confidence in the correctness of the software. As a general and informal recommendation, the following minimum levels of rigour should be aimed for when Annex A requires the corresponding SIL performance:

C.1.3 Method of use – 2
Although Annex A recommends specific techniques, it is also permitted to apply other measures and techniques, providing that the requirements and objectives of the lifecycle phase have been met.

It has already been noted that many factors affect software systematic capability, and it is not possible to give an algorithm for selecting and combining the techniques in a way that is guaranteed in any given application to achieve the desirable properties.
There may be several effective ways to achieve the desirable properties, and it should be recognized that system developers may be able to provide alternative evidence. The information in these Annex C tables can be used as the basis of a reasoned argument to justify the selection of techniques other than those given in the Annex A tables.