Julio Cesar Sampaio do Prado Leite

Requirements validation through viewpoint resolution

A specific technique-viewpoint resolution-is proposed as a means of providing early validation of the requirements for a complex system, and some initial empirical evidence of the effectiveness of a semi-automated implementation of the technique is provided. The technique is based on the fact that software requirements can and should be elicited from different viewpoints, and that examination of the differences resulting from them can be used as a way of assisting in the early validation of requirements. A language for expressing views from different viewpoints and a set of analogy heuristics for performing a syntactically oriented analysis of views are proposed. This analysis of views is capable of differentiating between missing information and conflicting information, thus providing support for viewpoint resolution. >

Enhancing a requirements baseline with scenarios

Scenarios are well recognised as an important strategy towards understanding the interface between the environment and the system as well as a means of eliciting and specifying software behaviour. We adopt a broader view of scenarios. For us, a scenario is an evolving description of situations in the environment. Our proposal is framed by Leite’s work on a client-oriented requirements baseline, which aims to model the external requirements of a software system and its evolution. Scenarios start by describing the environment situations, according to the main actions performed outside the software system. Scenarios also help to clarify the interrelation between functional and non-functional requirements. We have validated our strategy and the related representations based on case studies.

A Scenario Construction Process

Scenario is a description technique that has been attracting a lot of attention from practitioners and from researchers. Several disciplines have been using scenarios for some time now, but recently the information system community has dedicated special attention to the possibilities that this description technique provides to enhance understandability of task-related descriptions and communicability among stakeholders. This paper aims its attention at a particular scenario construction process, but while doing so it tackles important problems regarding scenario management, in particular scenario organisation. Our scenarios are described in a structured way, using a simple conceptual model together with a form-oriented language. We have been using this representation for some time now, and our results are based on several case studies conducted with real-world problems.

Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda

For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice? This paper attempts to provide answers to this question by describing obstacles that researchers and practitioners have encountered when they attempted technology transfer. In addition, major incentives for using RE methods are discussed, along with ideas for improving current RE practice. The paper summarises, clarifies and extends the results of two panel discussions, one at the Twelfth Conference on Advanced information Systems Engineering (CAiSE’00) and the other at the Fourth IEEE Conference on Requirements Engineering (ICRE’00).

A Meta-model for Representing Variability in Product Family Development

Effective product family based development depends on exploiting the commonality and variability in customer requirements. The desirability of variability in products is driven by the (manifest and hidden) needs of the various target market segments identified by various organizational units like sales and marketing. These are informed by other critical components of the context in which product families are developed including the technological capabilities, people/human resources available with the organization, the policies and procedures of the organization, and the strategic objective of the organization. Variability Management is seen as the key aspect that differentiates conventional software engineering and software product line engineering [Kruger 02]. Variability in a product family is defined as a measure of how members of a family may differ from each other [WeissLai 99]. Variability is made explicit using variation points. Variation points are places in design artifacts where a specific decision has been narrowed to several options but the option to be chosen for a particular system has been left open [Atkinson 01]. Identification of the points of variability is crucial in proliferating variety from a single product platform. A central component of product family approach is the management of variability. The product family development process involves managing variations among different members of the family by identifying common and variable aspects in the domain under consideration.

A Framework for Integrating Non-Functional Requirements into Conceptual Models

The development of complex information systems calls for conceptual models that describe aspects beyond entities and activities. In particular, recent research has pointed out that conceptual models need to model goals, in order to capture the intentions which underlie complex situations within an organisational context. This paper focuses on one class of goals, namely non-functional requirements (NFR), which need to be captured and analysed from the very early phases of the software development process. The paper presents a framework for integrating NFRs into the ER and OO models. This framework has been validated by two case studies, one of which is very large. The results of the case studies suggest that goal modelling during early phases can lead to a more productive and complete modelling activity.

From goals to high-variability software design

Software requirements consist of functionalities and qualities to be accommodated during design. Through goal-oriented requirements engineering, stakeholder goals are refined into a space of alternative functionalities. We adopt this framework and propose a decision-making process to generate a generic software design that can accommodate the full space of alternatives each of which can fulfill stakeholder goals. Specifically, we present a process for generating complementary design views from a goal model with high variability in configurations, behavioral specifications, architectures and business processes.

The world's a stage: a survey on requirements engineering using a real-life case study

In this article we present a survey on the area of Requirements Engineering anchored on the analysis of a real life case study, the London Ambulance Service [56]. We aim at bringing to context new methods, techniques and tools that should be of help to both reaserchers and practitioners. The case study in question is of special interest in that it is available to the public and deals with a very large system, of which the software system is only a part of. The survey is divided into four topics of interest: viewpoints, social aspects, evolution and non-functional requirements. This division resulted from the work method adopted by the authors. Our main goal is to bridge recent findings in Requirements Engineering research to a real world problem. In this light, we believe this article to be an important educational device.

Configuring features with stakeholder goals

Goal models are effective in capturing stakeholder needs at the time when features of the system-to-be have not yet been conceptualized. Relating goals to solution-oriented features gives rise to a requirement traceability problem. In this paper, we present a new model-driven extension to an Early Requirements Engineering tool (OpenOME) that generates an initial feature model of the system-to-be from stakeholder goals. Enabled by such generative mapping, configuration constraints among variability features can be obtained by reasoning about stakeholder goals.

A client oriented requirements baseline

Traceability, a major issue in software engineering, is seldom present at the initial requirements engineering process. The paper reports a proposal for organizing requirements statements as a model, where change and evolution are taken into consideration. The model uses natural language statements as its basic representation, which helps the communication between clients and software engineers. The model is supported by a customized software system for which a prototype was built and used in an industrial setting.