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. 1

Goals capture, at different levels of abstraction, the various objectives the system under consideration should achieve.

Requirements engineering (RE) is concerned with the identification of the goals to be achieved by the envisioned system, the operationalization of such goals into services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software. The processes involved in RE include domain analysis, elicitation, specification, assessment, negotiation, documentation, and evolution. Getting highquality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of RE as an area of utmost importance in software engineering research and practice. The paper presents a brief history of the main concepts and techniques developed to date to support the RE task, with a special focus on modeling as a common denominator to all RE processes. The initial description of a complex safetycritical system is used to illustrate a number of current research trends in RE-specific areas such as go...

Mobile devices, such as mobile phones and personal digital assistants, have gained wide-spread popularity. These devices will increasingly be networked, thus enabling the construction of distributed applications that have to adapt to changes in context, such as variations in network bandwidth, battery power, connectivity, reachability of services and hosts, and so on. In this paper we describe CARISMA, a mobile computing middleware which exploits the principle of reflection to enhance the construction of adaptive and context-aware mobile applications. The middleware provides software engineers with primitives to describe how context changes should be handled using policies. These policies may conflict. We classify the di#erent types of conflicts that may arise in mobile computing and argue that conflicts cannot be resolved statically at the time applications are designed, but, rather, need to be resolved at execution time. We demonstrate a method by which policy conflicts can be handled; this method uses a micro-economic approach that relies on a particular type of sealed-bid auction. We describe how this method is implemented in the CARISMA middleware architecture, and sketch a distributed context-aware application for mobile devices to illustrate how the method works in practise. We show, by way of a systematic performance evaluation, that conflict resolution does not imply undue overheads, before comparing our research to related work and concluding the paper.

We explore a framework for argumentation (based on classical logic) in which an argument is a pair where the first item in the pair is a minimal consistent set of formulae that proves the second item (which is a formula). We provide some basic definitions for arguments, and various kinds of counter-arguments (defeaters). This leads us to the definition of canonical undercuts which we argue are the only defeaters that we need to take into account. We then motivate and formalise the notion of argument trees and argument structures which provide a way of exhaustively collating arguments and counter-arguments. We use argument structures as the basis of our general proposal for argument aggregation.

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. In this paper, we describe the # bel framework for merging and reasoning about multiple, inconsistent state machine models. # bel 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, # chek, 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.

Behavior modeling has proved to be successful in helping uncover design flaws of concurrent and distributed systems. Nevertheless, it has not had a widespread impact on practitioners because model construction remains a difficult task and because the benefits of behavior analysis appear at the end of the model construction effort. In contrast, scenario-based specifications have a wide acceptance in industry and are well suited for developing first approximations of intended behavior; however, they are still maturing with respect to rigorous semantics and analysis tools. This article proposes a process for elaborating system behavior that exploits the potential benefits of behavior modeling and scenario-based specifications yet ameliorates their shortcomings. The concept that drives the elaboration process is that of implied scenarios. Implied scenarios identify gaps in scenario-based specifications that arise from specifying the global behavior of a system that will be implemented component-wise. They are the result of a mismatch between the behavioral and architectural aspects of scenario-based specifications. Due to the partial nature of scenariobased specifications, implied scenarios need to be validated as desired or undesired behavior. The scenario specifications are then updated accordingly with new positive or negative scenarios. By iteratively detecting and validating implied scenarios, it is possible to incrementally elaborate the

Inconsistencies in design models should be detected immediately to save the engineer from unnecessary rework. Yet, tools are not capable of keeping up with the engineers ’ rate of model changes. This paper presents an approach for quickly, correctly, and automatically deciding what consistency rules to evaluate when a model changes. The approach does not require consistency rules with special annotations. Instead, it treats consistency rules as black-box entities and observes their behavior during their evaluation to identify what model elements they access. The UML/Analyzer tool, integrated with IBM Rational Rose™, fully implements this approach. It was used to evaluate 29 models with tens-of-thousands of model elements, evaluated on 24 types of consistency rules over 140,000 times. We found that the approach provided design feedback correctly and required, in average, less than 9ms evaluation time per model change with a worst case of less than 2 seconds at the expense of a linearly increasing memory need. This is a significant improvement over the state-of-the-art.

In previous work we advocated continued development of specifications in the presence of inconsistency. To support this we presented quasi-classical (QC) logic for reasoning with inconsistent specifications. The logic allows the derivation of non-trivial classical inferences from inconsistent information. In this paper we present a development called labelled QC logic, and some associated analysis tools, that allows the tracking and diagnosis of inconsistent information. The results of analysis are then used to guide further development in the presence of inconsistency. We illustrate the logic and our tools by specifying and analysing parts of the London Ambulance Service. We argue that the scalability of our approach is made possible by deploying the ViewPoints framework for multi-perspective development, such that our analysis tools are only used on partial specifications of a manageable size. 1. Motivation and Background Inconsistent specifications are an inevitable intermediate p...

The development of software systems inevitably involves the detection and handling of inconsistencies. These inconsistencies can arise in system requirements, design specifications and, quite often, in the descriptions that form the final implemented software product. A large proportion of software engineering research has been devoted to consistency maintenance, or geared towards eradicating inconsistencies as soon as they are detected. Software practitioners, on the other hand, live with inconsistency as a matter of course. Depending on the nature of an inconsistency, its causes and its impact, they sometimes choose to tolerate its presence, rather than resolve it immediately, if at all.