This paper presents a classification scheme for research efforts in requirements engineering. For those readers who are not familiar with requirements engineering, it is intended to provide an overview and a coherent framework for further study.

: This paper reports research into semi-automatic generation of scenarios for validating system requirements. The research was undertaken as part of the ESPRIT IV 21903 'CREWS' long-term research project. The paper presents the underlying theoretical models of domain knowledge, computational mechanisms and user-driven dialogues needed for scenario generation. It describes how CREWS draws on theoretical results from the ESPRIT III 6353 'NATURE'basic research action, that is object system models which are abstractions of the fundamental features of different categories of problem domain. CREWS uses these models to generate normal course scenarios, then draws on theoretical and empirical research from cognitive science, human-computer interaction, collaborative systems and software engineering to generate alternative courses for these scenarios. The paper describes a computational mechanism for deriving use cases from object system models, simple rules for use case composition, taxonomies...

Scenario based requirements analysis is an inquiry based collaborative process which enables requirements engineers and other stakeholders to acquire, elaborate and validate system requirements. A scenario, in most situations, describes the normative or expected system behaviour during the interactions between the proposed system and its environment. To account for non-normative or undesired system behaviour, it is vital to predict and explore the existence or occurrence of `exceptions' in a scenario. Identification of exceptions and inclusion of additional requirements to prevent their occurrence or mitigate their effects yields robust and fault-tolerant design solutions. In this paper, we outline the architecture of a toolkit for semi-automatic generation of scenarios. The toolkit is co-operative in the sense that it aids a requirements engineer in systematic generation and use of scenarios. The toolkit provides domain knowledge during requirements acquisition and validation of norm...

Software development is no longer a homogeneous field. Software is being developed for an increasingly diverse set of applications and user populations, each with different characteristics and development constraints. As a consequence, researchers and practitioners have begun to realize the importance of identifying and understanding the characteristics and special development needs of application domains. But domain analysis methods have largely focused on identifying and isolating a domain to organize source code components. A broader view is needed that defines “domains ” to be problem with similar characteristics and that captures the various knowledge needed to develop software applications, such as application domain knowledge and tips and techniques for development tools. This paper describes a software development support system for collecting, organizing, and disseminating project experiences that provides the basis for domain analysis techniques supporting the re-use of development knowledge and software artifacts. Subsequent projects benefit from these experiences by using tools to locate similar projects and reusing the knowledge accumulated in the repository. We develop a framework for a system to capture relationships between development projects and resources for developing software, including process models, methods, technologies, and tools. We then show how this information can be reused to improve the productivity and quality of software development efforts.

Reuse, system integration, and interoperability create a growing need for capturing, representing, and using application-level information about software-intensive systems and their evolution. In ESPRIT Basic Research Project NATURE, we are developing an integrative approach to requirements management based on a threedimensional framework which addresses formalism as well as cognitive and social aspects. This leads to a new requirements process model which integrates human freedoms through allowing relatively free decisions in given situations. Classes of situations and decisions are defined with respect to the three-dimensional framework through the integration of informal and formal representations, theories of domain modeling, and the explicit consideration of nonfunctional requirements in teamwork. Technical support is provided by a conceptual modeling environment with knowledge acquisition through interactive as well as reverse modeling, and with similarity-based querying. 1

This paper reports reuse of generic domain knowledge in the form of templates, patterns or clichés to aid requirements capture and validation. These templates are retrieved through machine-based analogical matching. A cooperative paradigm for domain knowledge reuse is proposed. Human interpretation of templates is needed to maximise benefits from knowledge reuse, necessitating explanation and exploration of domain templates. Keyword Codes: D.2.1 Keywords: Requirements/Specifications 1. INTRODUCTION

Most software reuse research has ignored the role of the software engineer. However, software engineers tend to be better reasoners and have more experiences to recall than tool-based reuse mechanisms. This paper argues for integrating software engineers into existing reuse paradigms and providing tool support to assist problem description and component understanding, selection and adaptation. However, empirical studies indicate that these reuse tasks are difficult, even for experienced software engineers. Therefore, guidelines and a high-level architecture for design of tool support are based on reports of behaviour and problems arising during reuse. 1: Introduction Many technical solutions to software reuse problems have failed to result in widespread reuse. One reason may be that these solutions ignore human involvement. This paper investigates specific problems which arise from excluding software developers from the reuse process and proposes solutions based on human involvement fo...

. Using formal specifications based on varieties of mathematical logic is becoming common in the process of designing and implementing software. Formal methods are usually intended to include all important details of the final system in the specification with the aim of proving that it possesses certain mathematical properties. In large, complex systems, this task requires sophisticated theorem proving, which can be difficult and complicated. Telecommunication systems are large and complex, making detailed formal specification impractical with current technology. However roughly formal "sketches" of the behaviours these services provide can be produced, and these can be very helpful in locating which service might be relevant to a given problem. Our case-based approach uses coarse-grained requirements specification sketches to outline the basic behaviour of the system's functional modules (called services), thereby allowing us to identify, reuse and adapt requirements (fro...

This paper presents a framework for the inclusion of enterprise information in the development of a software requirements specification (SRS). An enterprise model is described which includes organisational, as well as business process components. The mission of an enterprise will determine a number of business objectives, which are translated into quantifiable goals under constraints imposed by the business environment. These goals specify targets for the associated business processes, and are critical in constraining and scoping the requirements for information systems. This paper argues that by ensuring the consistency of these requirements statements against the enterprise objectives, the process of iterative construction of an SRS is enhanced. Further, the impact of changes in customer requirements, both during and after the requirements engineering phase of software development may be assessed with greater reliability. The feasibility of the approach is illustrated with examples.