Heute schauen wir uns ein einfaches praktisches Beispiel der Implementierung einer Produktlinieninfrastruktur an.

Umfang der Domäne und Domänenanalyse

Der Umfang der Domäne unseres Beispiels sind Wecker. Die Systemanforderungen, die sich aus der Domänenanalyse für Wecker ergeben haben und die wir entsprechend der beschriebenen Klassifizierung aus Blog Teil 2 gruppiert und gegliedert haben, sind die folgenden:

1. Gemeinsame Anforderungen (Anforderungen, die jeder Wecker erfüllen muss)

  • Der Wecker muss über eine Weckfunktion mit einem akustischen Weckruf verfügen.
  • Der Wecker muss über eine Zeitanzeige verfügen.

2. Variable Anforderungen

a) Anforderungen mit Platzhalter (Platzhalter wird für die Spezifikation eines Produktes durch einen Wert ersetzt)

  • Der Weckruf muss über eine Dauer von <Zeitdauer> Sekunden ertönen.

b) Optionen (Anforderungen, die nicht notwendigerweise von einem Produkt erfüllt werden müssen)

  • Der Wecker muss ein Radio integriert haben.

c) Alternativen (Menge von Anforderungen, aus der eine oder evtl. auch mehrere von einem Produkt erfüllt werden müssen)

  • Die Zeitanzeige muss rot mit schwarzem Hintergrund sein.
  • Die Zeitanzeige muss blau mit schwarzem Hintergrund sein.

(Die Anforderungen sind im Beispiel möglichst kurz gefasst und stellen auch nur einen teilweise nicht ganz eindeutigen Auszug aus den Anforderungen der vollständigen Domäne dar.)

Abbildung der Anforderungen

Wie lassen sich nun die o.g. Anforderungen in einem Anforderungsmanagementwerkzeug abbilden? Für unser Beispiel verwenden wir das Anforderungsmanagementwerkzeug IBM Rational DOORS V. 9.x. Jedes andere Werkzeug, das ein Konzept zur Attributierung von Anforderungen implementiert, könnte an dieser Stelle aber auch verwendet werden.

Die folgende Abbildung zeigt wie eine Abbildung der Informationen aus der Domänenanalyse im Werkzeug erfolgen könnte:

Abbildung 1: Beispiel für die Abbildung von Domänenanforderungen

Das Beispiel aus Abbildung 1 zeigt die Anforderungen, die aus der Domänenanalyse resultierten. Die Klassifizierung der Anforderungen wurde mit Hilfe des Attributs „Anf-Typ“ durchgeführt. Dort ist bestimmt, ob die Anforderungen von jedem Produkt der Produktlinie erfüllt werden muss (obligatorisch ist), optional erfüllt werden kann oder Teil einer Alternative ist.

Zusätzlich ist in dem Beispiel noch die Spalte „Abhängigkeiten“ dargestellt. Dort werden mittels einer definierten Logik Einschränkungen oder Abhängigkeiten einer Anforderung zu anderen Anforderungen aus der Domäne spezifiziert. So muss Anforderung D-W_6 erfüllt werden, wenn die Anforderung D-W_5 erfüllt werden soll. Die Anforderungen aus der Alternative 1 können durch die definierte niemals gleichzeitig in einem Produkt erfüllt werden.

Nachdem wir nun die Implementierung einer Produktlinieninfrastruktur betrachtet haben, werden wir im nächsten Teil dieser Blog Reihe ein erstes Produkt daraus ableiten. Eine spannende Frage hierbei ist: Wie erhalte ich die Verbindung zwischen Anforderungen, die in einem spezifischen Produkt implementiert werden müssen, und deren korrespondierenden Anforderungen aus der Produktlinieninfrastruktur?

Series Navigation<< Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 4: Werkzeuge für produktlinienorientiertes Anforderungsmanagement (Kriterien)Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 6: Von der Produktlinieninfrastruktur zum Produkt >>