Software completeness

Exceptional states are typically defined by combinations of elementary states. The number of all possible combinations is an exponential function of the number of elementary states, making it impractical to consider each of them individually. Robert et al. (1998) provide a simple example of this problem in a hotel reservation system. A main source of state mismatch is the completeness problem, namely, the failure to consider the risks of all state combinations. For example, the Therac-25 accidents occurred in a specific operation sequence, in which the operators inadvertently depressed the wrong key, and then fixed it quickly, too quickly, before the system state could have been stabilized. To specify the system behavior for all possible state combinations, we need to classify the states according to the desired system reaction (e.g., reject request, prompt for confirmation, beep, etc.).

Operational completeness

Software completeness problems enable software bugs. Another aspect of the completeness problem is of user slips. For example, a radio-therapy intake form may have more than a hundred questions to ask and fill in. Many of the questions are context dependent, namely, they are applicable only for certain choices of earlier questions, and they are irrelevant otherwise. In sequential intake procedures, doctors often skip important questions. The number of intake errors is reduced drastically if only the relevant questions are enabled, and if the form is checked for completeness.

State charts

A common practice for arranging the system states is by state charts. State charts are excellent for describing the state-dependency of existing systems. However, they should not be recommended for defining state-dependency at the design stage, because they encourage introduction of undesired constrains, which might restrict the operator’s control during troubleshooting system faults.

Scenario-based design

In a scenario-based design we implement a model of the system behavior according to the operator’s perspective of the operational scenarios. In the supertanker example, we can define two main scenarios: maintenance and sailing. Then, we define the Control state as normal in maintenance mode and exceptional in sailing mode. The operator is required to set the scenario at the beginning of an operation cycle. This extra action is the key to enabling the system to alert on exceptional situations.

Enabling complete specification

Scenario-based design enables solving the completeness problem by taking the positive route; instead of specifying all exceptional state combinations (the negative route) we just specify the operational procedures for normal operation and for troubleshooting, corresponding to the scenarios. This type of specification is of low (linear) complexity, compared to the exponential complexity when taking the negative route.