Page 327 -

310 Chapter 12 Dependability and security specification

In September 1993, a plane landed at Warsaw airport in Poland during a thunder-
storm. For nine seconds after landing, the brakes on the computer-controlled braking
system did not work. The braking system had not recognized that the plane had
landed and assumed that the aircraft was still airborne. A safety feature on the air-
craft had stopped the deployment of the reverse thrust system, which slows down the
aircraft, because this can be dangerous if the plane is in the air. The plane ran off the
end of the runway, hit an earth bank, and caught fire.
The inquiry into the accident showed that the braking system software had oper-
ated according to its specification. There were no errors in the program. However,
the software specification was incomplete and had not taken into account a rare situ-
ation, which arose in this case. The software worked but the system failed.
This illustrates that system dependability does not just depend on good engineer-
ing. It also requires attention to detail when the system requirements are derived and
the inclusion of special software requirements that are geared to ensuring the
dependability and security of a system. Those dependability and security require-
ments are of two types:

1. Functional requirements, which define checking and recovery facilities that
should be included in the system and features that provide protection against
system failures and external attacks.
2. Non-functional requirements, which define the required reliability and avail-
ability of the system.

The starting point for generating functional dependability and security require-
ments is often high-level business or domain rules, policies, or regulations. These are
high-level requirements that are perhaps best described as ‘shall not’ requirements.
By contrast, with normal functional requirements that define what the system shall
do, ‘shall not’ requirements define system behavior that is unacceptable. Examples
of ‘shall not’ requirements are:

“The system shall not allow users to modify access permissions on any files that
they have not created.” (security)

“The system shall not allow reverse thrust mode to be selected when the aircraft is
in flight.” (safety)

“The system shall not allow the simultaneous activation of more than three alarm
signals.” (safety)
These ‘shall not’ requirements cannot be implemented directly but have to be
decomposed into more specific software functional requirements. Alternatively, they
may be implemented through system design decisions such as a decision to use
particular types of equipment in the system.