GM1 Article 15(1)(b) Conditions for obtaining a certificate

SOFTWARE ASSURANCE — SOFTWARE ASSURANCE PROCESSES

The software assurance processes should provide evidence and arguments that they support, as a minimum, the following:

(a)     The software requirements correctly state what is required by the software in order to meet the ‘specification of services’ and the ‘safety support requirements’. For that purpose, the software requirements should:

(1)     be correct, complete and, when available, compliant with upper-level requirements; and

(2)     specify the functional behaviour in nominal and degraded modes, and in terms of timing performance, capacity, accuracy, resource usage, robustness to abnormal operating conditions and overload tolerance, as appropriate, of the implemented software.

(b)     The software implementation does not contain functions that could adversely affect the satisfaction of the service specification and/or does not cause undesirable behaviour that may impair the safe provision of services.

(c)      Traceability is addressed in respect of all software requirements as follows:

(1)     Traceable to the ‘specification of services’ or the ‘safety support requirements’.

(2)     Each software requirement allocated to a component should either be traced to an upper-level requirement, or its need should be justified and assessed that it does not affect the satisfaction of the safety support requirements allocated to the component.

(3)     Each software requirement is linked to a verification activity (e.g. analysis and/or tests), granular enough to efficiently demonstrate that the requirements are met.

(d)     The functional behaviour, timing performance, capacity, accuracy, resource usage (potentially on the target hardware), robustness to abnormal operating conditions and overload tolerance of the implemented software comply with the software requirements.

(e)     The software verification:

(1)     is correct and completely verifies the software requirements, with a sufficient level of detail demonstrating that the requirements are fully met (e.g. intent of the test; analysis; clear, expected behaviour; and pass–fail criteria);

(2)     confirms that the service behaves as specified in an environment representative of the intended operational environment;

(3)     allows to verify all the interfaces and the robustness of the implementation;

(4)     is performed through review, analysis and/or testing and/or other equivalent means, as agreed with the competent authority; and

(5)     generates traceable results, with clear identification of any failed item.

(f)      The evidence and arguments produced by the software assurance processes should be traceable to:

(1)     a known executable version of the software;

(2)     a known range of configuration data; and

(3)     a known set of software items and descriptions, including specifications, which have been used in the production of that version, or can be justified as applicable to that version.

(g)     The software assurance processes should include the necessary activities to ensure that the software life cycle data can be shown to be under configuration control throughout the software’s life cycle, including the possible evolutions due to changes or correction of problems.

The activities should include, as a minimum:

(1)     configuration identification, traceability and status-accounting activities, including archiving procedures;

(2)     problem reporting, tracking, and management of corrective actions; and

(3)     retrieval and release procedures.

(h)     Software quality control should be undertaken to assess the conformance of the development of the software with established processes and related procedures, and should be supported by any necessary corrective actions according to the findings. The software quality control should be performed independently from the software development team to ensure impartiality of the control.