Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 6: Von der Produktlinieninfrastruktur zum Produkt
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 1
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 2: Die Produktlinieninfrastruktur
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 3: Variabilität innerhalb einer Produktlinie
- 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 5: Werkzeuge für produktlinienorientiertes Anforderungsmanagement (Implementierung)
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 6: Von der Produktlinieninfrastruktur zum Produkt
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 7: Die Produktlinieninfrastruktur und ihre Produkte
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 8: Die Unternehmensstruktur für ein produktlinienorientiertes Anforderungsmanagement
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 9: Retrospektive: Komplexität der Variabilität beherrschen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 10: Variabilität und Use Case Beschreibungen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 11: Variabilität und Use Case Diagramme
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 12: Variabilität und Feature Graphen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 13: Variabilität in UML
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:
- 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. - 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.
Karsten Krennrich
Kontaktieren Sie Karsten KrennrichHerr 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.
Wissen, das bewegt!
Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.
Jetzt abonnieren und keine wichtigen Insights mehr verpassen!
Diskussion