Page 345 -

328 Chapter 12 Dependability and security specification

RR1: A pre-defined range for all operator inputs shall be defined and the system shall check
that all operator inputs fall within this pre-defined range. (Checking)
RR2: Copies of the patient database shall be maintained on two separate servers that are not
housed in the same building. (Recovery, redundancy)
RR3: N-version programming shall be used to implement the braking control system.
Figure 12.8 (Redundancy)
Examples of
functional RR4: The system must be implemented in a safe subset of Ada and checked using static analysis.
reliability (Process)
requirements

12.3.3 Functional reliability specification
Functional reliability specification involves identifying requirements that define
constraints and features that contribute to system reliability. For systems where the
reliability has been quantitatively specified, these functional requirements may be
necessary to ensure that a required level of reliability is achieved.
There are three types of functional reliability requirements for a system:

1. Checking requirements These requirements identify checks on inputs to the sys-
tem to ensure that incorrect or out-of-range inputs are detected before they are
processed by the system.

2. Recovery requirements These requirements are geared to helping the system
recover after a failure has occurred. Typically, these requirements are concerned
with maintaining copies of the system and its data and specifying how to restore
system services after a failure.

3. Redundancy requirements These specify redundant features of the system that
ensure that a single component failure does not lead to a complete loss of service.
I discuss this in more detail in the next chapter.

In addition, the reliability requirements may include process requirements
for reliability. These are requirements to ensure that good practice, known to
reduce the number of faults in a system, is used in the development process.
Some examples of functional reliability and process requirements are shown in
Figure 12.8.
There are no simple rules for deriving functional reliability requirements. In
organizations that develop critical systems, there is usually organizational knowl-
edge about possible reliability requirements and how these impact the actual reliability
of a system. These organizations may specialize in specific types of system such as
railway control systems, so the reliability requirements can be reused across a range
of systems.