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.

On the refinement of use case models with variability support

“…Halmans and Pohl [19] propose use cases as the means to communicate variability relevant to the customer and they also propose extensions to use case diagrams to represent variability relevant to the customer. Halmans and Pohl consider that generalizations between use cases are adequate to represent use cases' variants.…”

“…We could have modeled use cases marked with «variant» in our approach as being related to variation points. Usually, a variation point is associated with one or more variants (from [19]). We have not adopted variation points to avoid additional graphical elements to use case diagrams, to avoid more complexity to use case diagrams and to avoid reasoning about variability that shall be present in decision models.…”

“…We do not agree with this approach since it introduces more complexity to use case diagrams than modeling variability with stereotypes and use case relationships as well as it introduces a reasoning about variability that should be present in decision models (the selection of the variants to be present in the system and the system/product to which that selection applies according to the features). Pohl [20] uses the graphical notation used by Halmans and himself [19] to represent variability in use case diagrams. Salicki and Farcet [21] talk about variation points and additionally in decision models.…”

A development methodology for variant-rich automotive software architectures

“…To reduce complexity, the customer must not be confronted with technical details. They are encapsulated in internal variability (Halmans, Pohl, 2004).…”

Szenario-basierter Systemtest von Software-Produktfamilien

“…Use-Cases sind eine adäquate Systembeschreibung zur Ableitung von Systemtests bei der Einzelsystementwicklung [3]. Use-Cases sind in anderen Arbeiten um die Modellierung von Variabilität erweitert worden, so dass diese Art der Anforderungsbeschreibung in der Produktfamilien-Entwicklung eingesetzt werden kann [8].…”