MBSE ist kein Tool-Projekt. Modellbasiertes Systems Engineering legt das Systemwissen nicht in verteilten Dokumenten ab, sondern in einem gemeinsamen Systemmodell, in dem Anforderungen, Struktur, Verhalten und Schnittstellen verknüpfte Elemente sind. So werden Lücken und Widersprüche im Verbund sichtbar, bevor sie im Einsatz auffallen. Eine Modellierungslizenz allein leistet das nicht: Ein Modell mit vagen Anforderungen ist ein vages Modell mit besseren Bildern.
Im Video baut Stefan Wellhausen, Branchenaccount Manager für Defense und Aerospace bei der SOPHIST GmbH, das Szenario aus den ersten beiden Teilen der Reihe als Systemmodell auf und zeigt, welche Fragen das Modell stellt, die ein Lastenheft nie stellen würde.
Video: MBSE ist kein Tool-Projekt · SOPHIST GmbH
Das Wichtigste aus dem Video
- Drei Lastenhefte werden von drei Organisationen zu drei Zeitpunkten geschrieben. Ob eine Schnittstelle auf beiden Seiten gleich definiert ist, prüft niemand, weil die Definition nirgends an einer Stelle steht. Konsistenz zwischen Dokumenten ist Handarbeit und hält über Jahre nicht.
- Ein Systemmodell für den Verbund braucht vier Bausteine: den Systemkontext, den Ablauf als Sequenzdiagramm, die Schnittstellen als Datentypen und Anforderungen, die mit den Elementen verknüpft sind, die sie erfüllen.
- Das Modell stellt Fragen, die ein Dokument nicht stellt: Ein leerer Port ist sichtbar, ein uneinheitlicher Datentyp fällt bei der Konsistenzprüfung auf, eine Anforderung ohne Verknüpfung setzt niemand um, und eine fehlende Nachricht hinterlässt eine Lücke im Ablauf.
- Für den Einstieg gilt: mit dem Systemkontext anfangen, nicht mit dem Tool, die Schnittstellen vor jeder Funktion modellieren und jede Anforderung mit mindestens einem Modellelement verknüpfen.
- „Ein Modell macht Lücken sichtbar, bevor sie hinter einem Hügel sichtbar werden.“
Häufige Fragen
Modellbasiertes Systems Engineering. Statt Systemwissen in Dokumenten zu verteilen, werden Anforderungen, Struktur, Verhalten und Schnittstellen in einem gemeinsamen Systemmodell als verknüpfte Elemente abgelegt, zum Beispiel mit SysML.
Weil jedes Lastenheft von einer anderen Organisation zu einem anderen Zeitpunkt geschrieben und geändert wird. Ob die Schnittstellen auf beiden Seiten gleich definiert sind, prüft niemand, weil die Definition nicht an einer Stelle steht.
Mit dem Systemkontext, nicht mit dem Tool. Danach die Schnittstellen als Datentypen modellieren und jede Anforderung mit mindestens einem Modellelement verknüpfen.
Die Broschüre Systems Engineering kostenlos nutzen
Wie Requirements Engineering und Architektur bei komplexen Systemen zusammenspielen und welche Sichten dabei helfen, Schnittstellen früh sauber zu klären, steht in unserer kostenlosen Broschüre:
- Systems Engineering – mit RE und Architektur zum Erfolg: https://sophist.de/ylwu
- Alle kostenlosen Broschüren aus WISSEN-for-free: https://sophist.de/wissen/#WISSEN4free
Ihr wollt MBSE in einem Vorhaben einführen und überlegt, wo ihr anfangt, damit es nicht bei einer Toollizenz bleibt? Sprecht uns an, wir schauen uns eure Ausgangslage im Gespräch an.
Dieses Video ist der dritte Teil einer vierteiligen Reihe zu Interoperabilität in Multi-Domain Operations. Auf dem SOPHIST YouTube-Kanal erklären wir regelmäßig Requirements Engineering und Systems Engineering aus der Praxis. Abonniere den Kanal, dann verpasst du den letzten Teil nicht.
Weiterführend: Teil 1: Interoperabilität ist kein Technikproblem · Teil 2: Requirements Engineering ist kein Papierkram
Grundlage: SOPHIST-Broschüre „Systems Engineering – mit RE und Architektur zum Erfolg“ aus SOPHIST WISSEN-for-free und das Buch „Requirements-Engineering und -Management“ (7. Auflage, Chris Rupp und die SOPHISTen, Hanser).