Stan Bühne

Modelling requirements variability across product lines

The explicit definition of variability in software product lines is a key difference between the development of single software systems and software product line engineering. More and more companies maintain several software product lines which focus on different types of products, market segments, and/or domains. Those product lines typically share commonalities and variability. The companies thus face the problem of managing communality and variability across different product lines. In this paper, we identify essential requirements for the documentation of requirements variability across product lines. We propose a meta model for structuring the variability information, sketch a prototypical realisation for managing variability across product lines in DOORS, and illustrate the use of the meta model in a small example. We further report on experiences made with the proposed variability modelling approach.

Exploring the Context of Product Line Adoption

To successfully adopt a product line approach an organization needs to define its adoption goals, conceive a strategy, and implement a plan to achieve those goals. This process is repeated for each business unit and individual affected by the product line adoption. This paper describes how the characteristics of the market, organization, business unit, and individual influence product line adoption goals, strategies, and plans.

Scenario-Based Application Requirements Engineering

In domain requirements engineering, common and variable requirements are defined for reuse in application requirements engineering. The identification and definition of requirements for reuse has been introduced in Chap. 4. This chapter focuses on application requirements engineering, where a multitude of application requirements specifications can be developed by reusing the requirements artifacts that were defined in domain engineering. If the application stakeholders have specific requirements that cannot be fulfilled by the product line (further called application specific requirements), either the Abstract

Defining requirements at different levels of abstraction

Requirements engineering for complex software intensive systems has become a major challenge in many software development projects. Especially the automotive industry experiences the increasing complexity of software in vehicles, during the last years. An actual premium vehicle, for instance embodies up to hundred electronic control units (ECU) with easily a few hundred features, each. Beneath the definition of abstract features, an electronic control unit is described by different goals, scenarios, requirements, and constraints. To create a manageable and traceable requirements specification for complex systems that enables the change and reuse of requirements, many companies claim assistance for a seamless specification of requirements. To satisfy this claim necessary requirements-artefacts and abstraction levels have to be defined. Further the interrelations between different requirements-artefacts of one, and among different abstraction levels have to be analyzed and defined. Recent research in this area has shown the benefits of goals and scenarios in addition to traditional requirements. Moreover, several researchers and practitioners have already researched the interrelations between goals and scenarios. However these works do not focus on the interrelationships of goals, scenarios, and requirements on different abstraction levels. In a joint project with DaimlerChrysler and the Software Systems Engineering Group at the University of Duisburg-Essen, we introduced goals, scenarios, and requirements on different abstraction levels and applied it in the context of a development project at DaimlerChrysler.