A requirements specification defines the requirements for the future system at a conceptual level (i.e. class or type level). In contrast, a scenario represents a concrete example of current or future system usage. In early RE phases, scenarios are used to support the definition of high level requirements (goals) to be achieved by the new system. In many cases, those goals can to a large degree be elicited by observing, documenting and analysing scenarios about current system usage, i.e. the new system must often fulfil many of the functional and non-functional goals of the existing system. To support the elicitation and validation of the goals achieved by the existing system and to illustrate problems of the old system we propose to capture current system usage using rich media (e.g. video, speech, pictures etc.) and to interrelate those observations with the goal definitions. Thus, we particularly aim at making the abstraction process which leads to the definition of the conceptual models more transparent and traceable. More precisely, we relate the parts of the observations which have caused the definition of a goal or against which a goal was validated with the corresponding goal. These interrelations provide the basis for

Research issues related to requirements modeling are introduced and discussed through a review of the requirements modeling language RML, its peers and its successors from the time it was first proposed at the Sixth International Conference on Software Engineering (ICSE-6) to the present---ten ICSEs later. We note that the central theme of "Capturing More World Knowledge" in the original RML proposal is becoming increasingly important in Requirements Engineering. The paper highlights key ideas and research issues that have driven RML and its peers, evaluates them retrospectively in the context of experience and more recent developments, and points out significant remaining problems and directions for requirements modeling research. 1. Introduction "...Requirements definition is a careful assessment of the needs that a system is to fulfill. It must say why a system is needed, based on current and foreseen conditions, which may be internal operations or an external market. It must say wh...

Eliciting the requirements for a proposed system typically involves different stakeholders with different expertise, responsibilities, and perspectives. Viewpoints-based approaches have been proposed as a way to manage incomplete and inconsistent models gathered from multiple sources. In this paper, we propose a category-theoretic framework for the analysis of fuzzy viewpoints. Informally, a fuzzy viewpoint is a graph in which the elements of a lattice are used to specify the amount of knowledge available about the details of nodes and edges. By defining an appropriate notion of morphism between fuzzy viewpoints, we construct categories of fuzzy viewpoints and prove that these categories are (finitely) cocomplete. We then show how colimits can be employed to merge the viewpoints and detect the inconsistencies that arise independent of any particular choice of viewpoint semantics. We illustrate an application of the framework through a case-study showing how fuzzy viewpoints can serve as a requirements elicitation tool in reactive systems. 1

View merging, also called view integration, is a key problem in conceptual modeling. Large models are often constructed and accessed by manipulating individual views, but it is important to be able to consolidate a set of views to gain a unified perspective, to understand interactions between views, or to perform various types of end-to-end analysis. View merging is complicated by incompleteness and inconsistency of views. Once views are merged, it is useful to be able to trace the elements of the merged view back to their sources. In this paper, we propose a framework for merging incomplete and inconsistent graph-based views. We introduce a formalism, called poset-annotated graphs, which incorporates a systematic annotation scheme capable of modeling incompleteness and inconsistency as well as providing a built-in mechanism for ownership traceability. We show how structure-preserving maps can capture the relationships between disparate views modeled as poset-annotated graphs, and provide a general algorithm for merging views with arbitrary interconnections. We use the i ∗ modeling language [26] as an example to demonstrate how our approach can be applied to existing graph-based modeling languages, especially in the domain of early Requirements Engineering. 1

Nowadays, large-scale industrial software systems may involve hundreds of developers working on hundreds of different but related models representing parts of the same system specification. Detecting and resolving structural inconsistencies between these models is then critical. In this article we propose to represent models by sequences of elementary construction operations, rather than by the set of model elements they contain. Structural and methodological consistency rules can then be expressed uniformly as logical constraints on such sequences. Our approach is meta-model independent, allowing us to deal with consistency between different models whatever their kind. We have validated our approach by building a Prolog engine that detects violations of structural and methodological constraints specified on UML 2.1 models and requirement models. This engine has been integrated into two contemporary UML-based modelling environments, Eclipse EMF and Rational Software Architect (RSA).

In this paper we survey recent work on the use of abduction as a knowledge-based reasoning technique for analysing software specifications. We present a general overview of logical abduction and describe two abductive reasoning techniques, developed from the logic and expert system communities. We then focus on two applications of abduction in software engineering, namely, analysis and revision of specifications. Specifically, we discuss and illustrate, with examples, how the above two abductive reasoning techniques can be deployed to reason about specifications, detect errors, such as logical inconsistencies, provide diagnostic information about these errors, and identify (possible) changes to revise incorrect specifications. We then conclude with a discussion of open research issues.

A software component is typically modeled from one or more of four functional aspects: interface, static behavior, dynamic behavior, and interaction protocol. Each of these aspects helps to ensure different levels of component compatibility and interoperability. Existing approaches to component modeling have either focused on only one of the aspects (e.g., interfaces in various IDLs) or on well-understood combinations of two of the aspects (e.g., interfaces and their associated pre- and post-conditions in static behavioral modeling approaches). This paper argues that, in order to accrue the true benefits of componentbased software development, one may need to model all four aspects of components. However, this requires that consistency among the multiple aspects be maintained. We offer an approach to modeling components using the four-view perspective (called the Quartet) and identify the points at which the consistency among the models must be maintained. 1.

this article, we examine the PITS Web-based mechanisms for tracking issue reports.

Abstract. System engineering often states that respecting diversity during the upstream stages of a system designing is an unavoidable feature of the designing process. In the field of Information Systems, the ability to evolve is a pivotal quality of its computer aided components. A framework is presented to view an Information System as a designing place where viewpoints interact with each other on objects to be designed. Each actor of the Information system is the stakeholder of a particular viewpoint on the Information System. He or she triggers activities which are cooperating processes. Viewpoints are traces of these processes. 1

The software development process is described in terms of cost or effort via cost drivers. Some scenarios are inadequately addressed because the available elements to describe them become inappropriate. Those scenarios comprise a great amount of effort at the conception stage and at managing perspectives and relationships. This work explores several aspects not considered as cost drivers that could be relevant for the process. Data collected was analyzed to reveal if there is a significant enough relationship between them and the development cost and verify or refute the assumption that could allow these aspects to be presented as cost drivers. The investigation has been circumscribed to the web scope to delimit the work.