Guest Editorial: Special Issue on Model Checking in Requirements Engineering

Steve Easterbrook, Marsha Chechik
2002 Requirements Engineering  
In the past decade, practical model-checking techniques have revolutionised research in formal software verification. Until the mid-1980s, when model checking was first introduced [1,2], formal verification research focused primarily on techniques for proving a program is correct against a formal specification. For many reasons, such techniques had had little impact on industrial practice [3] . In contrast, model checking has rapidly transferred into industrial practice, both for hardware and
more » ... ftware verification. With its emphasis on partial verification using fully automated techniques, model checking has led to an interest in 'lightweight' formal techniques [4] that can be applied at different levels of abstraction, and during any stage of the development process. Model-checkers have become popular debugging tools and have been used to reason about system requirements [5], software architectures [6], program behaviour [7-9], hardware and circuit designs [10], communication protocols [11] and even user interfaces [12] . Because model checking can be used to analyse abstract behavioural models, it has a number of natural applications in requirements engineering. A model-checker takes as input a model, M, of a system, expressed as a finite state machine, and a temporal logic formula, j, and algorithmically determines whether or not the model satisfies the property; i.e., it computes the value of the relation M |= j. From an engineering point of view, it is natural to consider the state machine model to be the central artefact, and to talk of checking that various behavioural properties hold of the model. We can summarise the key advantages of model checking over other forms of formal analysis as follows: 1. The procedure is fully automatic and quite fast, often producing an answer in a matter of minutes. 2. If a property is not satisfied, a model-checker will usually produce a counter-example -a sequence of steps leading to the problem, thus showing why the property is not satisfied. 3. Model checking can be applied to partial models, so it is not necessary to fully specify a system nor all its properties before analysing its correctness. Model checking was first applied to requirements engineering in the work of Atlee and Gannon [5] . In requirements engineering, the state machine typically represents an abstract description of the behaviour of some portion of the system to be specified, or its environment. The properties to be checked typically represent high-level requirements including safety properties (some undesirable situation will never happen) and liveness properties (some desirable situation will eventually occur). Reports of industrial case studies (e.g. [13]) indicate that it is rare to have well-formulated temporal logic properties from the outset. More usually, the model is developed first in an attempt to understand some aspect of a system's behaviour, and the exercise of model checking then involves the interaction of domain experts to discover high-level properties that ought to hold. In this sense, the model-checker becomes an exploration tool, used to discover properties of a model being developed, rather than to verify it against a preexisting specification. Because model checking does not require completeness of either the model or the properties to be checked, it can be applied at very early stages in requirements modelling.
doi:10.1007/s007660200017 fatcat:q2mffp33ing4ng3fht6cit5h2q