Steve M. Easterbrook

Requirements engineering: a roadmap

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.

Selecting Empirical Methods for Software Engineering Research

Selecting a research method for empirical software engineering research is problematic because the benefits and challenges to using each method are not yet well catalogued. Therefore, this chapter describes a number of empirical methods available. It examines the goals of each and analyzes the types of questions each best addresses. Theoretical stances behind the methods, practical considerations in the application of the methods and data collection are also briefly reviewed. Taken together, this information provides a suitable basis for both understand- ing and selecting from the variety of methods applicable to empirical software engineering.

Matching and Merging of Statecharts Specifications

Model Management addresses the problem of managing an evolving collection of models, by capturing the relationships between models and providing well-defined operators to manipulate them. In this paper, we describe two such operators for manipulating hierarchical Statecharts: Match, for finding correspondences between models, and Merge, for combining models with respect to known correspondences between them. Our Match operator is heuristic, making use of both static and behavioural properties of the models to improve the accuracy of matching. Our Merge operator preserves the hierarchical structure of the input models, and handles differences in behaviour through parameterization. In this way, we automatically construct merges that preserve the semantics of Statecharts models. We illustrate and evaluate our work by applying our operators to AT&T telecommunication features.

Using ViewPoints for inconsistency management

Large-scale software development is an evolutionary process. In an evolving specification, multiple development participants often hold multiple inconsistent views on the system being developed, and considerable effort is spent handling recurrent inconsistencies. Detecting and resolving inconsistencies is only part of the problem; a resolved inconsistency might not stay resolved as a specification evolves. Frameworks in which inconsistency is tolerated help by allowing resolution to be delayed. However, the evolution of a specification may affect both resolved and unresolved inconsistencies. A framework is presented and elaborated in which software development knowledge is partitioned into multiple views called ViewPoints. Inconsistencies between ViewPoints are managed by explicitly representing relationships between them, and recording both resolved and unresolved inconsistencies. It is assumed that ViewPoints will often be inconsistent, and so a complete work record is kept, detailing any inconsistencies that have been detected and what actions, if any, have been taken to resolve them. The work record is then used to reason about the effects of subsequent changes to ViewPoints, without constraining the development process. The paper demonstrates how inconsistency management is used as a tool for requirements elicitation and how ViewPoints provide a vehicle for achieving this. Inconsistency is used as a stimulus for eliciting missing information and capturing user-defined relationships that arise between elements of an evolving specification.

Using benchmarking to advance research: a challenge to software engineering

Benchmarks have been used in computer science to compare the performance of computer systems, information retrieval algorithms, databases, and many other technologies. The creation and widespread use of a benchmark within a research area is frequently accompanied by rapid technical progress and community building. These observations have led us to formulate a theory of benchmarking within scientific disciplines. Based on this theory, we challenge software engineering research to become more scientific and cohesive by working as a community to define benchmarks. In support of this challenge, we present a case study of the reverse engineering community, where we have successfully used benchmarks to advance the state of research.

Leveraging inconsistency in software development

Software engineers make use of many descriptions, including analysis models, specifications, designs, program code, user guides, test plans, change requests, style guides, schedules, and process models. But since different developers construct and update these descriptions at various times during development, maintaining consistency among descriptions presents several problems. Descriptions tend to vary considerably. Individual descriptions can be ill-formed or self-contradictory and frequently evolve throughout the life cycle at different rates. Also, checking the consistency of a large, arbitrary set of descriptions is computationally expensive. The authors assert that maintaining consistency at all times is counterproductive. In many cases, it may be desirable to tolerate or even encourage inconsistency to facilitate distributed team-work and prevent premature commitment to design decisions. They advocate using inconsistency to highlight problem areas, using it as a tool to improve the development teams shared understanding, direct the process of requirements elicitation, and assist with verification and validation.

A framework for multi-valued reasoning over inconsistent viewpoints

In requirements elicitation, different stakeholders often hold different views of how a proposed system should behave, resulting in inconsistencies between their descriptions. Consensus may not be needed for every detail, but it can be hard to determine whether a particular disagreement affects the critical properties of the system. We describe the Xbel framework for merging and reasoning about multiple, inconsistent state machine models. Xbel permits the analyst to choose how to combine information from the multiple viewpoints, where each viewpoint is described using an underlying multi-valued logic. The different values of our logics typically represent different levels of agreement. Our multi-valued model checker, Xchek, allows us to check the merged model against properties expressed in a temporal logic. The resulting framework can be used as an exploration tool to support requirements negotiation, by determining what properties are preserved for various combinations of inconsistent viewpoints.

Experiences using lightweight formal methods for requirements modeling

The paper describes three case studies in the lightweight application of formal methods to requirements modeling for spacecraft fault protection systems. The case studies differ from previously reported applications of formal methods in that formal methods were applied very early in the requirements engineering process to validate the evolving requirements. The results were fed back into the projects to improve the informal specifications. For each case study, we describe what methods were applied, how they were applied, how much effort was involved, and what the findings were. In all three cases, formal methods enhanced the existing verification and validation processes by testing key properties of the evolving requirements and helping to identify weaknesses. We conclude that the benefits gained from early modeling of unstable requirements more than outweigh the effort needed to maintain multiple representations.

Multi-valued symbolic model-checking

This article introduces the concept of multi-valued model-checking and describes a multi-valued symbolic model-checker, ΧChek. Multi-valued model-checking is a generalization of classical model-checking, useful for analyzing models that contain uncertainty (lack of essential information) or inconsistency (contradictory information, often occurring when information is gathered from multiple sources). Multi-valued logics support the explicit modeling of uncertainty and disagreement by providing additional truth values in the logic.This article provides a theoretical basis for multi-valued model-checking and discusses some of its applications. A companion article [Chechik et al. 2002b] describes implementation issues in detail. The model-checker works for any member of a large class of multi-valued logics. Our modeling language is based on a generalization of Kripke structures, where both atomic propositions and transitions between states may take any of the truth values of a given multi-valued logic. Properties are expressed in ΧCTL, our multi-valued extension of the temporal logic CTL.We define the class of logics, present the theory of multi-valued sets and multi-valued relations used in our model-checking algorithm, and define the multi-valued extensions of CTL and Kripke structures. We explore the relationship between ΧCTL and CTL, and provide a symbolic model-checking algorithm for ΧCTL. We also address the use of fairness in multi-valued model-checking. Finally, we discuss some applications of the multi-valued model-checking approach.

A manifesto for model merging

If a modeling task is distributed, it will frequently be necessary to merge models developed by different team members. Existing approaches to model merging make assumptions about the types of model to be merged, and the nature of the relationship between them. This makes it hard to compare approaches. In this paper, we present a manifesto for research on model merging. We propose a framework for comparing different approaches to merging, by treating merge as an algebraic operator over models and model relationships. We specify the algebraic properties of an idealized merge operator, as well as related operators such as match, diff, split, and slice. We then show how our framework can be used to compare existing approaches by applying it to two of our own research projects on model merging. We show how this analysis permits a detailed comparison of approaches, reveals the key features of each, and identifies weaknesses that require further research. Most importantly, the framework emphasizes the need to make explicit all assumptions about the relationships between models, and indeed to treat model relationships as first class objects.