Guest Editorial: Special Issue on Model Checking in Requirements Engineering

In the past decade, practical model-checking techniqueshave revolutionised research in formal software verifica-tion. Until the mid-1980s, when model checking wasfirst introduced [1,2], formal verification researchfocused primarily on techniques for proving a programis correct against a formal specification. For manyreasons, such techniques had had little impact onindustrial practice [3]. In contrast, model checking hasrapidly transferred into industrial practice, both forhardware and software verification. With its emphasis onpartial verification using fully automated techniques,model checking has led to an interest in ‘lightweight’formal techniques [4] that can be applied at differentlevels of abstraction, and during any stage of thedevelopment process. Model-checkers have becomepopular debugging tools and have been used to reasonabout system requirements [5], software architectures[6], program behaviour [7–9], hardware and circuitdesigns [10], communication protocols [11] and evenuser interfaces [12]. Because model checking can beused to analyse abstract behavioural models, it has anumber of natural applications in requirements engineer-ing.A model-checker takes as input a model, M,ofasystem, expressed as a finite state machine, and atemporal logic formula, j, and algorithmically deter-mines whether or not the model satisfies the property;i.e., it computes the value of the relation M |= j. From anengineering point of view, it is natural to consider thestate machine model to be the central artefact, and to talkof checking that various behavioural properties hold ofthe model. We can summarise the key advantages ofmodel checking over other forms of formal analysis asfollows:1. The procedure is fully automatic and quite fast, oftenproducing an answer in a matter of minutes.2. If a property is not satisfied, a model-checker willusually produce a counter-example – a sequence ofsteps leading to the problem, thus showing why theproperty is not satisfied.3. Model checking can be applied to partial models, so itis not necessary to fully specify a system nor all itsproperties before analysing its correctness.Model checking was first applied to requirementsengineering in the work of Atlee and Gannon [5]. Inrequirements engineering, the state machine typicallyrepresents an abstract description of the behaviour ofsome portion of the system to be specified, or itsenvironment. The properties to be checked typicallyrepresent high-level requirements including safetyproperties (some undesirable situation will neverhappen) and liveness properties (some desirable situationwill eventually occur). Reports of industrial case studies(e.g. [13]) indicate that it is rare to have well-formulatedtemporal logic properties from the outset. More usually,the model is developed first in an attempt to understandsome aspect of a system’s behaviour, and the exercise ofmodel checking then involves the interaction of domainexperts to discover high-level properties that ought tohold. In this sense, the model-checker becomes anexploration tool, used to discover properties of a modelbeing developed, rather than to verify it against a pre-existing specification. Because model checking does notrequire completeness of either the model or the proper-ties to be checked, it can be applied at very early stagesin requirements modelling.