Das Konzept der Systemfamilien¹⁰ wurde entwickelt, um den Aufwand von Einzellösungen zu reduzieren, indem Software wiederverwendet wird. Die Grundüberlegung ist, dass Softwareteile sich oft in Aufbau und Verwendung stark ähneln.
Deswegen ist es sinnvoll und ökonomisch solche Potentiale zu nutzen.
Zentrale Aufgabe ist die Wiederverwendbarkeit geeigneter Teile. Software soll nach diesem Prinzip aus einem festen Kern und variablen Teilen bestehen, um so Kundenanforderungen besser zu entsprechen. Um sie umsetzen zu können, müssen im Rahmen der Requirements Engineering Phase die bestehenden Anforderungen an die Software erhoben werden. Die erkannten Anforderungen werden in Modellen logisch angeordnet.
Schließlich werden sie evaluiert, umgesetzt und entsprechend variiert oder verändert.
Begleitend dazu muss der Aufwand geschätzt und Risiken bewertet werden. Der gesamte Prozess wird dabei dokumentiert. Zu diesem Thema werden verschiedene Konzepte, wie z.B. FAST, Feature Modellierung, FeatuRSEB und KobrA¹¹ in der Literatur beschrieben.
Veränderbarkeit, Familienorientierung, Konfigurationsmöglichkeiten, das Spektrum der Parameter sowie die Überprüfbarkeit sind die Aufgaben, an denen sie sich differenzieren. Die Analyse dieser Konzepte erfolgte ausführlich in der Dissertationsschrift¹². Problematisch an solchen Konzepten ist die Tatsache, dass sie nur mehr oder minder die jeweilige Aufgabe unterstützen.
Um jedoch ein konsistentes Modell zu schaffen, müssen alle genannten Aufgaben logisch verknüpft und vollständig gelöst werden.
Die Beschreibung einer Systemfamilie erfolgt dafür in einem Merkmalmodell. Hier ergeben sich durch die Struktur der Systemfamilie jedoch Probleme. Denn für die Ableitung einer Systemvariante müssen sowohl Merkmale als auch Anforderungen und deren Beziehungen im Modell hinterlegt werden. Die Eindeutigkeit dieser Beziehungen ist dabei das Entscheidende.
Ein in sich konsistentes, erweitertes Merkmalmodell ermöglicht so Varietät. Jedoch müssen auch im Vorfeld des Modells die erhöhten Anforderungen Beachtung finden. So müssen zusätzlich Dokumente und Personen im zeitlichen Verlauf festgehalten werden.
Die Lösung der genannten Probleme erfolgt im FORE-Modell im Hinblick auf die Automatisierbarkeit und Überprüfbarkeit der Varianten-Ableitung. So werden im Modell Versionen im Rahmen der Systemfamilie eingeführt und Beziehungen zwischen den erhobenen Anforderungen dargestellt. Das FORE-Modell erweitert unter Nutzung der traditionellen Konzepte das Merkmalmodell. Die Daten werden durch das Anforderungsmodell und das erweiterte Merkmalmodell erhoben. Durch Nutzung des Entwicklungsprozesses fließen die Daten in das Datenmodell ein. Dieses schließt den Prozess des Requirements Engineering ab und es erfolgt der Entwurf der Software.
Die einzelnen Schritte haben spezifische Aufgaben:¹³ Anforderungsmodell: Das Modell beinhaltet die hierarchisch angeordneten Anforderungen an das System und die entsprechenden Personen als Personenmodell, sowieso das referenzierte Dokumentmodell, welches die Struktur des Spezifikationsdokumentes¹⁴ enthält.
Die Beziehungen und Konflikte zwischen den Anforderungen müssen ebenso abgebildet werden.
Sie können sich unter Umständen gegenseitig ausschließen. Um Änderungen nachvollziehen oder rückgängig machen zu können, bedarf es einer Aufzeichnung der Änderungen, der Historie.
Um Anforderungen erheben zu können, wird eine Anforderungskarte benutzt. Sie protokolliert wichtige Informationen wie unter anderem Abhängigkeiten, den Autor, die Zuordnung zu einer Komponente oder ihre Bedeutung für den Kunden.
Merkmalmodell: Kernelemente in dem sich anschließenden Merkmalmodell sind die Beziehungen der Anforderungen zu den Merkmalen. Hier werden der Kern der Softwarefamilie mittels obligatorischer und die Varianten mittels optionaler Merkmale beschrieben. Merkmale sind als Zusammenfassung der Anforderungen an das System und somit als Eigenschaftsbeschreibungen zu verstehen.
Sie können unterschiedliche Intentionen haben: Sie können funktionaler Natur sein, Schnittstellen ausdrücken, Parameter darstellen oder der Strukturierung des Modells dienen. Auch für ihre Erhebung wird eine Merkmalskarte genutzt, die ähnlich aufgebaut ist wie die Anforderungskarte, hier werden alle Informationen zu einem Merkmal kompakt zusammengefasst. Die Darstellung der Merkmale erfolgt hierarchisch, um ihre Beziehungen untereinander und zu der Systemarchitektur zu verdeutlichen. Sie können z.B. Verfeinerungen oder Einschränkungen anderer Merkmale aufzeigen.
Zur Darstellung der zahlreichen Beziehungsmöglichkeiten wurde eine Notation geschaffen, sie wird in Anhang B gezeigt. So kann angezeigt werden, welche Varianten möglich sind und welche Merkmale sich ausschließen, sowie welche Merkmale zum Kern gehören, also notwendig sind, und welche für die Variante vom Kunden dazu gewählt werden können. Schließlich kann nur ein in sich widerspruchsfreies Modell automatisch überführt werden. Diese Überprüfung erfolgt anhand automatischer Regeln.
Entwicklungsprozess: Der Entwicklungsprozess wird in der Literatur durch das ''Six-Pack- Modell''¹⁵ dargestellt und wird für die Generierung des Datenmodells genutzt.
Dazu werden die Ergebnisse der Domänenanalyse, also dem Requirements Engineering der Softwarefamilie selbst und die Ergebnisse der Applikationsanalyse, also die Forderungen der Kunden an die Software, genutzt und abgeglichen. Das Resultat fließt in das Anforderungsmodell ein. Dieser Abgleich hat enorme Bedeutung, da ab hier Änderungen im Anforderungsmodell nur noch mit zusätzlichen Kosten und Aufwand zu bewältigen sind. Das FORE-Modell umfasst die genannten drei Module als ein Teil des Six-Pack-Modells, welches dem Systementwurf vorgelagert ist. Das Requirements Engineering der Systemfamilie und der kundenspezifischen Applikation ist ein weitreichender Prozess, hier wird auf die Dissertationsschrift verwiesen.
Datenmodell: Das Datenmodell ist die schriftliche Komprimierung der Resultate vergangener Schritte. Das Modell beinhaltet eine Sammlung der vollständigen Informationen. Das sind das Anforderungsmodell, das Merkmalmodell, das Systemfamilienmodell, das Dokumentmodell, das Personenmodell und ihre Beziehungen untereinander. Ziel ist es hier, die vielfältigen Beziehungen untereinander in einem UML-Diagramm darzustellen. Die Elemente selbst werden in einer Datenbank unter der entsprechenden Variante der Systemfamilie gespeichert.
Das Anforderungsmodell stellt die Ansprüche an das System systematisch gegliedert dar, ihnen werden Personen, Dokumente und zahlreiche Informationen zugeordnet. Die Anforderungen werden dem Kern bzw. einer oder mehrerer Varianten zugeschrieben. Ähnliches geschieht mit den Merkmalen im Merkmalmodell.
Hier liegt der Fokus vor allem in der Zuweisung der Art der Merkmale und der Frage, ob das Merkmal jeweils optional oder obligatorisch ist. Im Dokumentmodell schließlich sind alle erstellten Dokumente enthalten und das Personenmodell stellt alle Personen im Zusammenhang mit der Erhebung dar. Schließlich werden alle Änderungen mit dem entsprechenden Datum und der ausführenden Person in der Historie aufgeführt, die Erhebung der Merkmale ist damit abgeschlossen.¹⁶

• 10: Eine ausführlichere Darstellung dieses Konzeptes erfolgt in Kapitel 3.2.1.
• 11: Mehr Informationen unter [Stre 2004] S. 72 ff
• 12: Vgl. [Stre 2004] S. 68 ff
• 13: Vgl. [Stre 2004] S. 87 ff
• 14: Das Dokument enthält eine komplette Beschreibung der Systemfamilie einschließlich der Personen, der Anforderungen, der Varianten und deren Merkmale aus dem Merkmalmodell, sowie die Komponenten und Schnittstellen und dazu Kosten- und Risikobetrachtungen.
• 15: Das Six- Pack- Modell ist ein globales Modell der Systemfamilienentwicklung, vgl. [Stre 2004] S. 211. Das Modell einschließlich des gesamten Entwicklungsprozesses soll hier nur kurz erwähnt bleiben. Ausführlichere Erläuterungen sind [Stre 2004] S. 70 ff zu entnehmen.
• 16: Vgl. [Stre 2004] S. 87 ff