Share ZU:
5 February 2013 @ Karsten Krennrich

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 6: Von der Produktlinieninfrastruktur zum Produkt

This entry is part 6 of 13 in the series Produktlinien

In Teil 5 der Blogreihe wurde ein Beispiel für die Implementierung einer Produktlinieninfrastruktur gezeigt. Die Frage die wir heute beantworten ist: Wie entsteht ein konkretes Produkt aus der Produktlinieninfrastruktur?

Die Domäne, die unsere Produktlinieninfrastruktur abbildet, betrachtet Wecker. Hier nochmals die Anforderungen, die aus der Domänenanalyse aus Teil 5 resultierten:

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

Anforderungen auf Basis von Entscheidungen festlegen

Die Entwicklung eines neuen WeckersXY steht nun bevor und wir müssen die Anforderungen für den WeckerXY spezifizieren. Hierzu wollen wir unsere Domänenanforderungen nutzen.

Schauen wir uns die Anforderungen unsere Domäne an und leiten den neuen WeckerXY davon ab:

  1. Anforderungen, die WeckerXY laut unserer Domäne auf jeden Fall erfüllen muss:
    In unserem Fall sind dies die Anforderungen D-W_2 und D-W_3.
  2. Variable Anforderungen, die abhängig von Kundenwünschen oder Markteigenschaften „adaptiert“ werden müssen.
    a) Anforderung D-W_4: Der Kunde entscheidet sich hier für eine Zeitdauer von 5 Minuten.
    b) Anforderung D-W_5: Der Kunde möchte auch Radio hören können. Daraus folgt aufgrund der definierten Abhängigkeit, dass auch Anforderung D-W_6 erfüllt werden muss.
    c) Der Kunde möchte eine rote Zeitanzeige: Daraus folgt, dass Anforderung D-W_8 erfüllt werden muss und gleichzeitig D-W_7 obsolet ist.

Dokumentation der Anforderungen

Wie dokumentieren wir nun die Anforderungen für unseren WeckerXY, sodass der Bezug zur Domäne nicht verloren geht?

Für unser Beispiel nutzen wir wieder das Anforderungsmanagementwerkzeug IBM Rational DOORS V. 9.x. Wir haben ein Attribut „ProduktXY“ definiert in welchem wir pro Anforderungen festlegen, ob das Produkt die Anforderung erfüllen wird (enthalten) oder nicht (nicht enthalten).

Abbildung 2: Beispiel für die Abbildung eines Produkts

Über eine Filterfunktion können wir dann genau die Anforderungen selektieren, die für das ProduktXY gelten, und die Spezifikation für das Produkt erstellen.

(Ich möchte hier erwähnen, dass dies sicherlich nicht die einzige Lösungsmöglichkeit für die Abbildung der Produktanforderungen ist. Je nach Prozess- oder Entwicklungsvorgaben müssen evtl. andere Lösungsmöglichkeiten in Betracht gezogen werden.).

Im nächsten Teil des Blogs erörtern wir, warum der Zusammenhang „Abgeleitetes Produkt zu Produktlinieninfrastruktur“ ein nicht zu unterschätzender Aspekt für unsere Produktlinie ist.

Series Navigation<< Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 5: Werkzeuge für produktlinienorientiertes Anforderungsmanagement (Implementierung)Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 7: Die Produktlinieninfrastruktur und ihre Produkte >>

Karsten Krennrich

Kontaktieren Sie Karsten Krennrich

Herr Karsten Krennrich ist als Consultant der HOOD Group tätig. Seine Schwerpunkte liegen in der Beratung von Requirements Engineering (RE) orientierten Entwicklungsprozessen. Er ist als Projektleiter bei der HOOD Software Division verantwortlich für die Realisierung von Softwarelösungen im Bereich der Entwicklungsprozess unterstützenden Werkzeuge. Für diese Anpassungen und Erweiterung von Standard Werkzeugen erarbeitet Herr Krennrich auch die zur Realisierung notwendigen Konzepte. Bei deren Implementierung arbeitet Herr Krennrich unter anderem auch mit den Konfigurationsmanagement Werkzeugen CMSynergy und Subversion. Neben dem RM-Werkzeug DOORS® von IBM hat Herr Krennrich auch Praxiserfahrungen mit den Werkzeugen CaliberRM® von Borland und RequisitePro® von IBM. Er verfügt außerdem über Erfahrungen im Bereich Datenbanken und Informationssysteme, im Software Engineering und im Themenbereich Produktlinien.