Wie Produktlinien systematisch entstehen

Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der Regel wird dabei zwischen Domänen-Engineering und Anwendungs-Entwicklung unterschieden. Doch was passiert eigentlich in diesen beiden Phasen und wie unterstützt iQUAVIS bei der Umsetzung dieses Ansatzes? 

Zwei mal zwei Perspektiven 

Im Schaubild Abb. 1 unten ordnen wir die wesentlichen Fähigkeiten von iQUAVIS ein. Das Bild ist horizontal in zwei Bereiche unterteilt: Links: Domänen-Entwicklung, die sozusagen die wiederverwendbaren Kernartefakte in den Blick nimmt. Rechts: die Anwendungs-Entwicklung, die auf ein konkretes Produkt fokussiert.

Vertikal werden zwei Ebenen unterschieden: Oben, die Marktperspektive, die Feature und Konfigurationen für die Kunden beschreibt, sowie unten die Architekturperspektive, in der es um die technische Basis geht, um ebendiese Feature realisieren zu können.

Domänen-Entwicklung: Die gemeinsame Basis schaffen 

Den methodischen Einstieg in die Domänen-Entwicklung bildet das Feature-Modell. Es repräsentiert die Marktsicht einer Produktlinie. Dabei ist ein Feature ein vom Kunden bestellbares Merkmal. Ein Feature fasst inhaltlich funktionale und nicht-funktionale Anforderungen zusammen.

Folgende Fragestellungen stehen hinter der Feature-Modellierung: 

• Welche Feature werden oder sollen zukünftig am Markt angeboten werden? 
• Wo gibt es Variabilität? 
• Welche Feature bedingen sich oder schließen sich aus? 
• Welche Features sind optional oder verpflichtend? 

Das Feature-Modell beschreibt also nicht ein einzelnes Produkt, sondern die gesamte Lösungsdomäne. Es ist das zentrale Kommunikationsmittel zwischen Vertrieb, Produktmanagement und Technik. 

Die Lösungsbausteine zu dem beschriebenen Feature-Modell finden wir in der Architekturperspektive in Form von Modulen bzw. architektonischen Bausteinen. Bei der Entwicklung dieser Bausteine zielt man auf: 

• Wiederverwendbare Komponenten 
• Architekturelle Muster 
• Schnittstellen 
• technische Variationspunkte 

Jeder Baustein ist so entworfen, dass er für viele Produkte wieder verwendbar ist. Variabilität wird bewusst eingeplant – nicht als Sonderfall, sondern als Kernprinzip. Das Ergebnis der Domänen-Entwicklung ist damit: 

• ein Feature-Model für die Markt‑ und Produktsicht 
• eine Referenzarchitektur aus Modulen/Bausteinen für die technische Umsetzung 

Anwendungs-Entwicklung: Konkrete Produkte bauen 

Während die Domänen-Entwicklung sozusagen die Bühne aufbaut, beginnt in der Anwendungs-Entwicklung die konkrete Ausprägung . 

Im oberen rechten Bereich des Schaubildes sieht man die Konfigurationen. Hier wird das Feature-Modell verwendet, um konkrete Produkte zu definieren: 

• Auswahl der Feature, aus denen ein konkrete Produkt besteht
• Berücksichtigung der Einschränkungen des Feature-Modells (Varianten, Optionen etc.)

Eine Konfiguration ist damit eine gültige Auswahl aus dem Feature-Model – sie beschreibt genau ein Produkt.

Aus der Konfiguration wird auf der Architekturebene im unteren rechten Bereich die Produktarchitektur abgeleitet. Das Schaubild zeigt: 

• Die Produktarchitektur entsteht nicht neu, sie wird aus den Bausteinen oder Modulen zusammengesetzt 
• Die Konfiguration steuert, welche Bausteine wie kombiniert werden 
• Aufgabe der Produktarchitektur ist die technische Plausibilisierung, also ob die Module über ihre Schnittstellen so zusammenpassen, wie es die Konfiguration definiert

So entsteht eine konkrete, lauffähige Architektur, die genau die zuvor gewählten Features unterstützt. 

Die Domänenentwicklung liefert also die Bausteine – die Anwendungsentwicklung setzt sie zusammen. 

Die Verbindung zwischen beiden Welten 

Ein zentrales Element des Bildes sind die Verbindungen: 

• Das Feature-Modell verweise auf die architektonischen Bausteine 
• Die Bausteine werden in konkreten Produktarchitekuren verwendet
• Eine Konfiguration verweist auf eine (plausible) Kombination von Featuren und die daraus abgeleiteten Lösungselemente

Genau diese Durchgängigkeit unterscheidet Product Line Engineering von klassischer Wiederverwendung oder Copy‑&‑Paste‑Entwicklung. Die Verknüpfung von Marktanforderungen bis zur technischen Umsetzung erfolgt modellbasiert und ist die Grundlage für Kommunikation und Kooperation Produktmanagent und Technik. Entscheidend ist, dass das aufgebaute Beziehungswissen nun in den unterschiedlichen Phasen der Produktentstehung genutzt wird:

• Für die Produktroadmap werden Feature zeitlich aufgeplant
• Die Architektur berücksichtigt die bestehenden Feature und die kommenden Feature (Big Picture) und wird entsprechend ausgelegt
• Technische Entscheidungen finden nicht isoliert, sondern vor dem Hintergrund ebendieser Planung statt
• Auch technische Risiken für bestimmte Feature oder Opportunitäten, die sich aus einer neuartigen Kombination von Lösungselementen ergeben könnten, werden auf dieser Basis erarbeitet
• Qualitäts- oder Risikomethoden berücksichtigen, in welchen Konfigurationen sich eine bestimmte Funktion oder Lösung befindet kann
• Bereits abgesicherte Module können wiederverwendet werden

Diese Liste an Nutzungsmöglichkeiten ließe sich noch weiter fortführen.

Wie unterstützt iQUAVIS bei diesem Ansatz? 

iQUAVIS bietet die notwendigen Toolfunktionalitäten, um den beschriebenen Ansatz umzusetzen. Es beinhaltet die Möglichkeit, Feature-Modelle zu definieren und entsprechende Abhängigkeiten zu modellieren. Die Feature können Lösungselementen zugeordnet werden. Bedingungen wie Exclude oder Mandatory können in verschiedenen Sichten angezeigt und bearbeitet werden (vgl. Abb. 2-4).

Der VariantenManager in iQUAVIS bietet darauf aufbauend die Möglichkeit, Varianten konkret auszuprägen – natürlich unter Berücksichtigung der Bedingungen des Featurebaums.

iQUAVIS bietet auch die Möglichkeit, wiederverwendbare Architekturbausteine anzulegen. Es stellt alle gängigen Modellierungsmethoden des MBSE zur Verfügung, um die Architekturbausteine in konkreten Systemmodellen zu nutzen.

Webinaraufzeichnung: Variantenmanagement für das Product Line Engineering

In diesem Webinar über Variantenmanagement mit iQUAVIS für das Product Line Engineering erhalten Sie einen praktischen Einblick. Beachten Sie zum Thema Varianten auch diesen Beitrag über Varianz im Systemmodell.

• 
  Produktmanagement mit iQUAVIS – Aufzeichnung
  von Sonja Feierabend
  26. Mai 2026
  Wenn Sie unser Live-Webinar über Produktmanagement mit iQUAVIS verpasst haben, erhalten Sie nun eine Chance, sich die Aufzeichnung anzusehen. Produktmanagement mit iQUAVIS Wie lassen sich strategisches Produktmanagement und modellbasierte Systementwicklung (MBSE) effektiv miteinander verbinden? Und wie kann ein Tool diese Zusammenarbeit konkret unterstützen?  In diesem Webinar zeigen wir, dass modernes Produktmanagement und MBSE nicht nebeneinander, sondern
• 
  iQUAVIS v10 – Update 2026
  von Christian Dr. Bremer
  19. Mai 2026
  Aus Japan hat uns die iQUAVIS v10 erreicht, an der wir noch einige Anpassungen für den europäischen Markt vorgenommen haben, damit iQUAVIS bei all unseren Kunden reibungslos läuft. Die wichtigsten Neuerungen der v10, die demnächst ausgerollt wird, stellen wir in diesem Blogartikel einmal vor. Hinzufügen vorhandener Daten in Arbeitsblätter Die Nutzerunterstützung beim Einfügen vorhandener Daten
• 
  Product Line Engineering mit iQUAVIS
  von Christian Dr. Bremer
  5. Mai 2026
  Im Product Line Engineering (PLE) entstehen Produktlinien systematisch aus einer gemeinsamen Basis. Dahinter steckt ein hochkomplexes Engineering, das wir in diesem Beitrag in der Theorie erläutern. In einem weiteren Beitrag werden wir die praktische Umsetzung aufzeigen. Wie Produktlinien systematisch entstehen Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Christian Dr. Bremer

Dr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS.

Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert.

www.two-pillars.de/

Einordnung in den RFLP Ansatz

Wir fokussieren uns in unserem Beitrag auf Varianz, die auf Systemebene entsteht. Betrachten wir ein Systemmodell nach dem RFLP-Ansatz, tritt Varianz typischerweise auf funktions-, logischer- und physischer Ebene auf. 

Auf Funktionsebene geht es typischerweise um mögliche alternative Funktionsumfänge, die das Produkt aufweisen kann. In diesem Zusammenhang wird an Stelle einer Funktion häufig auch der Begriff „Feature“ verwendet. Beschrieben wird, welche Funktionen oder Feature, ein Kunde wählen kann oder am Markt angeboten werden sollen.

Auf logischer Ebene wird dann zugeordnet, wie eine Funktion umgesetzt wird. Dabei findet man jedoch nicht unbedingt immer eine 1:1 Zuordnung, es wird vielmehr in Betracht gezogen, ob ein Systemelement bspw. mehrere Funktionen umsetzen kann oder ob eine Überspezifikation zugunsten einer Teileersparnis Sinn macht. Darüber hinaus kann es auch gut sein, dass Funktionen, die ähnlich klingen und vermeintlich nur geringfügige Unterschiede aufweisen, mit anderen Technologien oder unterschiedlichen Produktfamilien umgesetzt werden. Dementsprechend ergibt sich der Variantenbaum aus genannten Überlegungen und ist daher in der Regel kein einfaches Spiegelbild des Funktionsbaums.

Auf physischer Ebene wird die konkrete Umsetzung mit einem Bauteil definiert. Auf dieser Ebene spiegelt sich Varianz bspw. in Bauteilen wider, die von unterschiedlichen Zulieferern kommen, aber die gleich Spezifikation aufweisen oder an unterschiedlichen Standorten verbaut werden.

Berücksichtigung von Varianz im Systemmodell

Wie im Diagramm angedeutet, verstehen wir Varianz als Teil der Beziehungen zwischen den Modellelementen. Dabei kann diese Beziehung drei Ausprägungen annehmen:

• Variante: eine Entweder-Oder-Beziehung (XOR) zwischen verschiedenen Funktionen oder Systemelementen
• Option: eine Oder-Beziehung (OR) – eine Funktion oder ein Element ist nicht zwingend erforderlich, sondern kann in einer Konfiguration verwendet werden
• Default: Eine Funktion oder ein Element muss zwingend vorkommen

Darüber hinaus kann die Varianz in einem Modell durch Bedingungen eingeschränkt werden. Solche Bedingungen sind:

• Mandatory (oder requires): Eine Funktion oder ein Systemelement benötigt ein anderes zwingend
• Exclude: Wenn eine bestimmte Funktion oder Systemelement gewählt ist, kann ein bestimmtes anderes Element nichtmehr genutzt werden
• Wenn-Dann: Für komplexere Bedingungen können Wenn-Dann-Regeln definiert werden, die nach bspw. mehrere bedingende Funktionen oder Systemelemente beinhalten.

In iQUAVIS setzen wir Varianten-Beziehung als Teil der Hierarchiebeziehung um. Im Bild zu sehen ist das Beispiel einer Wetterstation, die bspw. über zwei verschiedene Bildschirmgrößen verfügen könnte. Mögliche Bedingungen werden mittels Abhängigkeitsbeziehung modelliert, im Beispiel zwischen der kleineren Bildschirmgröße und dem Feature, auch Wind messen zu können. Im rechten Teil des Bilds wird der Feature Baum im „Varianten Filter“ noch einmal visualisiert. Hier gibt es die Möglichkeit, mittels Checkboxen, eine bestimmte Variante oder Option auswählen und somit die Varianz des Systemmodells auszuprägen. Damit kann zum einen das Verhalten des Modells geprüft sowie zum anderen konkrete Konfigurationen erzeugt werden.

Nutzung des Systemmodells

Ein MBSE Modell, das Varianz beinhaltet, kann als Grundlage zur Kommunikation und Kooperation mit anderen Projektbeteiligten genutzt werden.

• Varianz kann bewusst geplant werden, insb. in Abstimmung zwischen Produktmanagement und Entwicklung, die auf Basis einen Modells ihr gemeinsames Verständnis sicherstellen
• Auf Basis der modellierten Varianz können konkrete Konfigurationen definiert werden, sei es, um in der Entwicklung bestimmte Konfigurationen fokussiert zu analysieren, Kundenkonfigurationen zu dokumentieren oder alle denkbaren Konfigurationen auszuleiten
• Die Integration von Varianz in das Systemmodell sichert die Traceability von Anforderungen über Funktionen bis zur Lösung. So kann insb. im Fall von Änderungen der Impact festgestellt werden.

Die Informationen zur Varianz im Systemmodell bilden die Basis für verschiedene aufbauende Aktivitäten. Eine Plausibilitätsprüfung kann sicherstellen, dass die modellierte Variantenlogik frei von Widersprüchen ist. Das Product Line Engineering benötigt die Möglichkeit, Varianz auf Systemebene darzustellen, die sie sowohl für die Beschreibung der Produktlinie als auch der Produktfamilie relevant ist.

In iQUAVIS setzt das Thema Varianz mit dem VariantenManager um. Mehr dazu erfahren Sie auf der Seite zum Variantenmanagement mit iQUAVIS.

Christian Dr. Bremer

Dr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS.

Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert.

www.two-pillars.de/

Ihr Download-Link

Über dieses Formular erhalten Sie den Link, um sich das Webinar kostenlos anzusehen.

Das Webinar: Inhalte

Vor einiger Zeit haben wir in diesem Webinar über Systems Engineering mit iQUAVIS die Grundlagen des MBSE erklärt. In dem Webinar über den VariantenManager steigen wir etwas tiefer in die Materie ein und stellen die folgenden Punkte vor:

• Anlegen von Varianten und Optionen
• Definieren von Abhängigkeiten (Exclude/ Mandatory)
• Erzeugen von Konfigurationen auf Basis der modellierten Varianz
• Zählen und Exportieren aller möglichen Konfigurationen
• Prüfen der Plausibilität
• Integrieren in das Systemmodell in iQUAVIS

Der VariantenManager

Der VariantenManager ist ein zusätzlich buchbares Feature für iQUAVIS. Wie uns unsere Kunden immer wieder bestätigen, zum Beispiel in unserer Interview-Reihe „Wir sind Systems Engineer“, ist er ein kleines, aber sehr mächtiges Tool, das iQUAVIS um die Aspekte der Varianz und der Konfigurationslogik erweitert – und zwar sowohl auf der Anforderungs- und Funktionsseite, als auch auf der Lösungsseite. So können Sie Varianten und Optionen definieren und ihre Abhängigkeiten zu anderen Teilen des Produkts modellieren. Damit unterstützt der VariantenManager die systematische Erarbeitung und das Management von Varianz.

Haben Sie Fragen oder Interesse an weiteren Informationen darüber? Melden Sie sich gern bei uns:

Weitere Webinare rund um MBSE

Wir planen weitere Webinare rund um MBSE und iQUAVIS. Haben Sie Themenwünsche oder Fragen, auf die wir eingehen sollen? Schreiben Sie uns gern einen Kommentar!

Die nächsten Webinartermine geben wir über unseren Newsletter, LinkedIn oder unsere Event-Seite bekannt!

Die Grundlagen des Systems Engineering lernen Sie in diesem Webinar.

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Sonja Feierabend

Sonja Feierabend ist Online Marketing Managerin bei der Two Pillars GmbH. Sie hat Literaturwissenschaft und Medienwissenschaft studiert und bloggt seit der Erfindung des Internets. Sie betreut die Website und Social Media sowie weitere Marketing-Themen, PR und Projekte.

www.two-pillars.de