Günter Halmans

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.

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.

Documenting Application-Specific Adaptations in Software Product Line Engineering

Software product line engineering distinguishes between two types of development processes: domain engineering and application engineering. In domain engineering software artefacts are developed for reuse. In application engineering domain artefacts are reused to create specific applications. Application engineers often face the problem that individual customer needs cannot be satisfied completely by reusing domain artefacts and thus application-specific adaptations are required. Either the domain artefacts or the application artefacts need to be modified to incorporate the application-specific adaptations. We consider the case that individual customer needs are realised by adapting the application artefacts and propose a technique for maintaining traceability between the adapted application artefacts and the domain artefacts. The traceable documentation of application-specific adaptations is facilitated by an application variability model (AVM) which records the differences between the domain artefacts and the application artefacts of a particular application. The approach is formalised using graph transformations.