Klaus Pohl

A proposal for a scenario classification framework

The requirements engineering, information systems and software engineering communities recently advocated scenario-based approaches which emphasise the user/system interaction perspective in developing computer systems. Use of examples, scenes, narrative descriptions of contexts, mock-ups and prototypes-all these ideas can be called scenario-based approaches, although exact definitions are not easy beyond stating that these approaches emphasise some description of the real world. Experience seems to tell us that people react to ‘real things’ and that this helps in clarifying requirements. Indeed, the widespread acceptance of prototyping in system development points to the effectiveness of scenario-based approaches. However, we have little understanding about how scenarios should be constructed, little hard evidence about their effectiveness and even less idea about why they work.The paper is an attempt to explore some of the issues underlying scenario-based approaches in requirements engineering and to propose a framework for their classification. The framework is a four-dimensional framework which advocates that a scenario-based approach can be well defined by itsform, content, purpose andlife cycle. Every dimension is itself multifaceted and a metric is associated with each facet. Motivations for developing the framework are threefold: (a) to help in understanding and clarifying existing scenario-based approaches; (b) to situate the industrial practice of scenarios; and (c) to assist researchers develop more innovative scenario-based approaches.

The three dimensions of requirements engineering: a framework and its applications

Abstract There is an increasing number of contributions on how to solve the various problems within requirements engineering (RE). The purpose of this paper is to identify the main goals to be reached during the RE process in order to develop a framework for RE. This framework consists of three dimensions: • • the specification dimension • • the representation dimension • • the agreement dimension. We show how this framework can be used to classify and clarify current RE research as well as RE support offered by methods and tools. In addition, the framework can be applied to the analysis of existing RE practise and the establishment of suitable process guidance. Last but not least, the framework offers a first step towards a common understanding of RE.

A journey to highly dynamic, self-adaptive service-based applications

Future software systems will operate in a highly dynamic world. Systems will need to operate correctly despite of unespected changes in factors such as environmental conditions, user requirements, technology, legal regulations, and market opportunities. They will have to operate in a constantly evolving environment that includes people, content, electronic devices, and legacy systems. They will thus need the ability to continuously adapt themselves in an automated manner to react to those changes. To realize dynamic, self-adaptive systems, the service concept has emerged as a suitable abstraction mechanism. Together with the concept of the service-oriented architecture (SOA), this led to the development of technologies, standards, and methods to build service-based applications by flexibly aggregating individual services. This article discusses how those concepts came to be by taking two complementary viewpoints. On the one hand, it evaluates the progress in software technologies and methodologies that led to the service concept and SOA. On the other hand, it discusses how the evolution of the requirements, and in particular business goals, influenced the progress towards highly dynamic self-adaptive systems. Finally, based on a discussion of the current state of the art, this article points out the possible future evolution of the field.

Communicating the variability of a software-product family to customers

Abstract.Variability is a central concept in software product family development. Variability empowers constructive reuse and facilitates the derivation of different, customer specific products from the product family. If many customer specific requirements can be realised by exploiting the product family variability, the reuse achieved is obviously high. If not, the reuse is low. It is thus important that the variability of the product family is adequately considered when eliciting requirements from the customer.In this paper we sketch the challenges for requirements engineering for product family applications. More precisely we elaborate on the need to communicate the variability of the product family to the customer. We differentiate between variability aspects which are essential for the customer and aspects which are more related to the technical realisation and need thus not be communicated to the customer. Motivated by the successful usage of use cases in single product development we propose use cases as communication medium for the product family variability. We discuss and illustrate which customer relevant variability aspects can be represented with use cases, and for which aspects use cases are not suitable. Moreover we propose extensions to use case diagrams to support an intuitive representation of customer relevant variability aspects.

Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis

Feature diagrams are a popular means for documenting variability in software product line engineering. When examining feature diagrams in the literature and from industry, we observed that the same modelling concepts are used for documenting two different kinds of variability: (1) product line variability, which reflects decisions of product management on how the systems that belong to the product line should vary, and (2) software variability, which reflects the ability of the reusable product line artefacts to be customized or configured. To disambiguate the documentation of variability, we follow previous suggestions to relate orthogonal variability models (OVMs) to feature diagrams. This paper reuses an existing formalization of feature diagrams, but introduces a formalization of OVMs. Then, the relationships between the two kinds of models are formalized as well. Besides a precise definition of the languages and the links, the important benefit of this formalization is that it serves as a foundation for a tool supporting automated reasoning on variability. This tool can, e.g., analyse whether the product line artefacts are flexible enough to build all the systems that should belong to the product line.

Adapting traceability environments to project-specific needs

R equirements traceability is defined as the ability to describe and follow the life of a requirement, in both a forward and backward direction. It implies the life of each requirement can be understood from its origin, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration [6]. Requirements traceability is a prerequisite for effective system maintenance and consistent change integration [2]. Neglecting traceability or capturing insufficient and/or unstructured traces leads to a decrease in system quality, causes revisions, and thus, increases project costs and time. It results in a loss of knowledge if individuals leave the project, leads to wrong decisions, misunderstanding, and miscommunications [8, 11]. Recent empirical research shows that systems management practice is progressing from the initial simple compliance verification schemata to very sophisticated models and policies for requirements traceability (see Ramesh in this section as well as [6, 8, 11, 12]). Table 1 gives an indication of the richness of advanced traceability schemes. However, the same studies also point out that full capture of all conceivable traces according to these advanced models is neither desirable nor feasible when considering project cost and time. If requirements traceability is not customized it can lead to an unwieldy mass of unstructured and unusable data that will hardly ever be used [6, 9]. The adaptation of trace capture and usage to project-specific needs is thus a prerequisite for successfully establishing traceability within a project and for achieving a positive cost-benefit ratio. The traces to be captured are influenced by factors like project schedule and project budget [11], by the contract, the development standards applied, existing laws, or the expected trace usage. A number of examples, drawn from focus group data of the study reported by Ramesh, are sketched in the sidebar “Examples of Project-Specific Trace Capture and Usage.” The increasing use of commercial requirements traceability environments by industry reflects that traceability is recognized as a critical success factor. A vendor survey of commercial requirements traceability environments performed by :

Variability modeling to support customization and deployment of multi-tenant-aware Software as a Service applications

More and more companies are offering their software by following the Software as a Service (SaaS) model. The promise of the SaaS model is to exploit economies of scale on the provider side by hosting multiple customers (or tenants) on the same hardware and software infrastructure. However, to attract a significant number of tenants, SaaS applications have to be customizable to fulfill the varying functional and quality requirements of individual tenants. In this paper, we describe how variability modeling techniques from software product line engineering can support SaaS providers in managing the variability of SaaS applications and their requirements. Specifically, we propose using explicit variability models to systematically derive customization and deployment information for individual SaaS tenants. We also demonstrate how variability models could be used to systematically consider information about already deployed SaaS applications for efficiently deploying SaaS applications for new tenants. We illustrate our approach by a running example for a meeting planning application.

The Three Dimensions of Requirements Engineering

Requirements engineering (RE) is perceived as an area of growing importance. Due to the increasing effort spent for research in this area many contributions to solve different problems within RE exist. The purpose of this paper is to identify the main goals to be reached during the requirements engineering process in order to develop a framework for RE. This framework consists of the three dimensions: the specification dimension the representation dimension the agreement dimension Looking at the RE research using this framework, the different approaches can be classified and therefore their interrelationships become much clearer. Additionally the framework offers a first step towards a common understanding of RE.

Requirements elicitation and validation with real world scenes

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 analyzing scenarios about current system usage. 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 aim at making the abstraction process which leads to the definition of the conceptual models more transparent and traceable. 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: 1) explaining and illustrating a goal model to, e.g., untrained stakeholders and/or new team members; 2) detecting, analyzing, and resolving a different interpretation of the observations; 3) comparing different observations using computed goal annotations; and 4) refining or detailing a goal model during later process phases. Using the PRIME implementation framework, we have implemented the PRIME-CREWS environment, which supports the interrelation of conceptual models and captured system usage observations. We report on our experiences with PRIME-CREWS gained in an experimental case study.

Model Checking of Domain Artifacts in Product Line Engineering

In product line engineering individual products are derived from the domain artifacts of the product line. The reuse of the domain artifacts is constraint by the product line variability. Since domain artifacts are reused in several products, product line engineering benefits from the verification of domain artifacts. For verifying development artifacts, model checking is a well-established technique in single system development. However, existing model checking approaches do not incorporate the product line variability and are hence of limited use for verifying domain artifacts. In this paper we present an extended model checking approach which takes the product line variability into account when verifying domain artifacts. Our approach is thus able to verify that every permissible product (specified with I/O-automata) which can be derived from the product line fulfills the specified properties (specified with CTL). Moreover, we use two examples to validate the applicability of our approach and report on the preliminary validation results.