Wir rocken Engineering Archiv

In der Folge geht es um die Frage, wie MBSE dazu genutzt werden kann, Entwicklungsprojekte besser zu strukturieren und Entscheidungen wirksamer vorzubereiten. Der Gastgeber ordnet die Episode als Gespräch über „Modellierung zur Entscheidungsfähigkeit“ ein und beschreibt, dass Modelle nicht Selbstzweck sein sollen, sondern konkrete Projektfragen beantworten helfen. Zu Gast ist Bastian Ribbers. Er schildert seinen Weg vom Studium der Konstruktion und Entwicklung über die Arbeit in der Konstruktion bis hin zur Beratung im Bereich Systems Engineering und MBSE. Dort unterstützt er Kunden dabei, Produktentwicklung strategisch und effizient zu organisieren und Projekte besser steuerbar zu machen. Ein Schwerpunkt des Gesprächs ist die Kritik an MBSE, wenn Modelle vor allem vollständig und detailliert aufgebaut werden, ohne dass klar ist, welche Entscheidung damit unterstützt werden soll. Ribbers betont, dass Modelle gezielt auf Fragestellungen ausgerichtet sein sollten, statt nur Dokumente in anderer Form zu ersetzen. Wichtig sei, die jeweils benötigte Evidenz für eine Entscheidung früh zu identifizieren. Daran anknüpfend erklärt er, dass man Entscheidungspunkte entlang von Meilensteinen oder Review Gates vorbereiten kann. Dafür werden konkrete Entscheidungsfragen abgeleitet, Informationsbedarfe definiert und festgelegt, wie diese nachgewiesen und bewertet werden sollen. So lasse sich erkennen, welche Daten, Analysen oder Nachweise noch fehlen. Ein weiterer Punkt ist der Umgang mit Risiken und Alternativen. Ribbers beschreibt, dass frühzeitig mitgedacht werden sollte, was geschieht, wenn eine Entscheidung noch nicht getroffen werden kann. Auch Alternativen, zum Beispiel unterschiedliche Technologien, sollen systematisch verglichen werden. Zum Schluss erläutert er sein Verständnis von MBSE: Entscheidend sei nicht ein einziges großes Modell, sondern die strukturierte und verknüpfbare Aufbereitung von Informationen über verschiedene Modelle und Werkzeuge hinweg. Der praktische Nutzen liege darin, Projekte zielgerichtet zu steuern, ohne sich in Formalität oder Modellierung zu verlieren.

In dieser Episode sprechen wir über SysML V2, Git und die Frage, wie sich die textuelle Notation bei der Versionsverwaltung verhält. Wir ordnen zunächst ein, was Git als Versionsverwaltungssystem leistet und warum Branches, Commits und Merges besonders wichtig sind. Wir erklären dann, dass SysML V2 nicht nur aus Text besteht, sondern ein zugrunde liegendes Modell mit verschiedenen Views hat. Die textuelle und die grafische Darstellung sind dabei zwei gleichwertige Ansichten auf dasselbe Modell und nicht das Modell selbst. Ein Schwerpunkt liegt auf den unerwarteten Herausforderungen beim Arbeiten mit textueller SysML-V2-Notation in Git. Wenn Elemente, Referenzen oder Abhängigkeiten geändert werden, erkennt ein textbasierter Merge nicht ohne Weiteres, welche inhaltlichen Auswirkungen das auf andere Teile des Modells hat. Wir diskutieren außerdem, dass zwar Editoren Syntax und Semantik prüfen können, Git beim Zusammenführen aber nur auf Textebene arbeitet. Dadurch kann ein automatischer Merge als erfolgreich erscheinen, obwohl das Modell später im Tool inkonsistent ist. Zum Schluss sprechen wir über mögliche Umgangsweisen. Wir betonen die Notwendigkeit von Awareness, einer Modell-zentrierten Sicht auf Diff und Merge sowie zusätzlicher Tool-Unterstützung, damit bei SysML V2 nicht nur Text, sondern das Modell als Ganzes berücksichtigt wird.

Prozesse schaffen Orientierung Prozesse sind wichtig. Sie zeigen, wie Arbeitsschritte ineinandergreifen und wer wofür verantwortlich ist. Sie machen Schnittstellen sichtbar und helfen Teams, mit einer verlässlichen Grundlage weiterzuarbeiten. Auch Freigaben gehören dazu. Sie schaffen Klarheit darüber, wann ein Arbeitsergebnis geprüft und bereit für den nächsten Schritt ist. So behalten alle den Überblick – und unfertige Ergebnisse geraten nicht unkontrolliert in Umlauf. Klare Abläufe können außerdem dabei helfen, Automatisierungspotenziale zu erkennen. Wenn Eingaben und Arbeitsschritte verlässlich feststehen, lässt sich besser beurteilen, welche Aufgaben automatisiert werden können – und ob künstliche Intelligenz dabei sinnvoll unterstützen kann. Prozesse dürfen Projekte nicht ausbremsen Genauso wichtig ist aber die Frage, ob jeder Prozessschritt in jedem Projekt wirklich notwendig ist. Bringt dieser Schritt einen Mehrwert? Muss das Ergebnis überhaupt erstellt werden? Oder lässt sich das Ziel auf einem anderen Weg besser erreichen? Nicht jeder Prozess passt unverändert zu jeder Situation. Manchmal braucht es zusätzliche Schritte. Manchmal lassen sich Schritte weglassen, die im konkreten Projekt keinen Nutzen bringen. Für mich bedeutet gutes Prozessdenken deshalb nicht, Regeln blind zu befolgen. Es bedeutet, Abläufe ernst zu nehmen und sie regelmäßig auf ihre Wirkung zu prüfen. Prozesse sollen Orientierung geben – und dabei helfen, gute Ergebnisse effizient zu erreichen.

In dieser Episode spreche ich mit Benjamin Zimmer über den Digital Thread im Systems Engineering. Wir klären, was sich hinter dem Begriff verbirgt und wie Unternehmen Entwicklungsdaten, Anforderungen, Tests, Hardware- und Softwareinformationen durchgängig miteinander verknüpfen können. Dabei geht es unter anderem um bessere Traceability, effektiveres Change Management und schnellere Impact-Analysen. Benjamin zeigt, welchen praktischen Nutzen ein Digital Thread bei Änderungen, Kundenproblemen sowie der Verifizierung und Validierung bietet. Außerdem sprechen wir darüber, warum Unternehmen nicht mit einem riesigen Digitalisierungsprojekt starten sollten. Stattdessen empfehle ich, zunächst ein konkretes Problem und einen überschaubaren Use Case auszuwählen. So lassen sich erste Erfolge sichtbar machen und Schritt für Schritt weitere Bereiche einbinden.

In dieser Episode spreche ich über die fünf häufigsten Hörerfragen zu KI im Ingenieurbüro. Ich erkläre, wie ich KI-Assistenten für die Erstellung von Lastenheften eingesetzt haben und welche Schritte mein Prozess umfasst: erfassen, sortieren, füllen, prüfen und freigeben. Außerdem beschreibe ich, wie ich die Assistenten konfiguriert haben. Dabei nutze ich keine eigene Modelltrainierung, sondern gebe per Prompt vor, wie die Assistenten mit den Quellen umgehen sollen, was sie tun dürfen und was nicht. Ziel ist, Halluzinationen zu vermeiden und sich an die vorliegenden Dokumente zu halten. Dann gehe ich auf das Ausgabeformat ein. Ich erzeuge Markdown-Dateien, stelle sie in Obsidian dar und exportieren sie bei Bedarf als PDF. Zusätzlich erwähne ich, dass auch ein Transfer in CSV oder künftig direkt in eine SysMLv2-Spezifikation möglich sein könnte. Ein weiterer Schwerpunkt ist der Einsatz von KI bei der Bewertung und Weiterentwicklung von Lastenheften. Ich sehe KI nicht als Ersatz, sondern als Unterstützung beim Finden von Informationen, Lücken und Parallelen. Für die Weiterentwicklung zu Pflichtenheften betone ich, dass neben dem Lastenheft auch eine grobe Systemarchitektur und vorhandene Dokumentation eingebracht werden können, die Ergebnisse aber immer menschlich geprüft werden müssen.

In dieser Episode spreche ich mit Andreas Horn, Experte für automatisiertes Testen in sicherheitskritischen Branchen wie Avionik, Automotive, Medizin und Robotik. Andreas erklärt, was eine Unit wirklich ist – und warum viele Unternehmen den Fehler machen, zu kleinteilig zu testen. Mit einem cleveren Vergleich aus der Küche macht er deutlich: Nicht jede Zutat muss einzeln probiert werden, aber das fertige Gericht sollte stimmen. Wir sprechen über typische Probleme bei der Unit-Größe, über Teststrategie, Grenzwerte, Robustheitstests und erfahrungsbasiertes Testen. Außerdem erkläre ich, warum Traceability – also die Verknüpfung von Anforderungen, Testfällen und Testergebnissen – kein Mehraufwand ist, sondern langfristig Zeit und Geld spart. Zum Abschluss sprechen wir über Abdeckungskriterien wie Statement-, Zweig- und MCDC-Coverage und klären: Tests beweisen keine Fehlerfreiheit, aber sie reduzieren Zweifel. Das wichtigste Fazit: Lieber früh und bewusst testen als zu viel – und niemals erst dann, wenn alles zusammengesteckt ist.

In dieser Episode spreche ich mit Sarah Schuh, Agile People Coach und Resilienz-Trainerin bei OSE in Hamburg, über eines der wichtigsten Zukunftsthemen für Macher und Entscheider: Resilienz im Arbeitsleben. Wir tauchen gemeinsam ein in die Frage, was Resilienz wirklich bedeutet – und stoßen dabei auf eine überraschende Erkenntnis: Resilienz ist keine angeborene Persönlichkeitseigenschaft. Sie ist erlernbar. Und sie hängt nicht nur vom Individuum ab, sondern vom gesamten System – vom Team, von der Führung, von der Organisation. Sarah erklärt, warum unser Gehirn in einer Welt voller Unsicherheit – Corona, geopolitische Krisen, KI-Wandel – an seine Grenzen stößt, und warum Burnout-Zahlen kein Zeichen mangelnder Belastbarkeit sind, sondern Symptome überfordernder Systeme. Ich bringe mein technisches Bild mit: Ein resilientes System ist nicht einfach das robusteste – es kennt seine Umgebung, seine Schnittstellen und seine eigenen Grenzen. Genauso funktioniert Resilienz beim Menschen. Wir sprechen darüber, was ich als Systems Engineer konkret tun kann: Stresssignale früh erkennen, Grenzen klar kommunizieren, den eigenen Einflussbereich kennen – und notfalls auch das System verlassen. Und wir sind uns einig: Soft Skills sind kein Add-on. Sie sind unverzichtbar.

In dieser Folge geben wir einen Zwischenstand dazu, wie wir KI schrittweise in unseren Requirements-Engineering-Prozess integrieren. Wir beschreiben, wie wir den Ablauf in einzelne Tätigkeiten zerlegt haben und bewusst prüfen, welche Schritte sich für Automatisierung eignen und wo der Mensch weiterhin nötig ist. Wir beginnen mit dem Aufbau einer neuen Plattform für communitybezogene Inhalte und dem geplanten Umzug des Podcasts. Außerdem weisen wir auf ein Requirements-Engineering-Event in Hannover hin, das wir als Community-Format verstanden wissen. Im Mittelpunkt der Episode steht ein Experiment mit mehreren spezialisierten KI-Agenten für ein Lastenheft. Als Beispiel dient uns ein Projekt rund um eine Wallbox. Zuerst erzeugt ein Agent aus einem Workshop-Foto mit System-Footprint und Post-its eine erste Dokumentstruktur. Danach verarbeitet ein zweiter Agent einzelne Dokumente und sortiert passende Inhalte in die Kapitel ein. Anschließend lassen wir einen weiteren Agenten Anforderungen aus dem Material formulieren. Dafür geben wir ihm klare Regeln für Form, Verbindlichkeit und Vorgehen mit. Danach prüft ein Konsistenz-Agent die erzeugten Anforderungen auf Widersprüche. Dafür ergänzen wir eindeutige IDs, damit die Ergebnisse nachvollziehbar bleiben. Wir halten fest, dass Lücken im Dokument weiterhin vom Menschen geklärt werden müssen. Auch Review und Freigabe bleiben interaktive Schritte. Zusätzlich denken wir über einen Agenten nach, der das Dokument im Review vorliest und gleichzeitig mehr Aufmerksamkeit für Reaktionen im Raum ermöglicht. Zum Schluss sprechen wir über die technische Umgebung: sensible Daten, lokale Speicherung über Markdown und die Nutzung von LangDoc. Außerdem erwähnen wir SysML V2 und die Idee, aus textuellen Beschreibungen später Modelle und Architekturartefakte zu erzeugen.

In dieser Episode zeige ich dir den dritten Teil meiner KI-Serie aus meinem Ingenieurbüro. Nachdem ich in Teil 1 mit dem „Dieter Dokumentenfresser" Anforderungen aus Dokumenten extrahiert und in Teil 2 mit „Richard Anford" ein Lastenheft erstellt habe, geht es heute um die Qualitätssicherung – übernommen von meiner KI-Agentin „Conny Sistent". Ich zeige dir, wie ich das fertige Lastenheft als PDF an Conny Sistent übergebe und sie es systematisch analysiert. Dabei nutze ich die KI-Plattform Langdock, in der ich der Agentin eine klare Rolle, Kernaufgaben, Verhaltensregeln und ein definiertes Ausgabeformat mitgegeben habe. Das Ergebnis ist beeindruckend: Conny Sistent liefert eine strukturierte Analyse mit Stärken des Dokuments, konkreten Hauptbefunden, Verbesserungsvorschlägen, offenen Klärungsfragen und einem Vorschlag für das weitere Vorgehen. Sie findet unvollständige Anforderungen, unscharfe Begriffe, inhaltliche Widersprüche (z. B. beim Eichrecht), Überlappungen zwischen Kapiteln und Lücken gegenüber dem System Footprint – darunter das komplett fehlende Thema Datenschutz/DSGVO. Besonders wertvoll: Sie schlägt ein kapitelweises Detail-Review vor und macht konkrete Umformulierungsvorschläge für einzelne Anforderungen – inklusive korrekter ID-Vergabe. Das spart nicht nur Zeit bei der Erstellung, sondern auch in der späteren Verifikation, weil doppelte Testfälle vermieden werden.

In dieser Episode zeige ich dir, wie ich den KI-Assistenten Richard Anford aufgebaut habe, um aus Textabschnitten strukturierte Anforderungen für ein Lastenheft zu erstellen. Ich erkläre, welche Rolle der Assistent in meinem Prozess übernimmt, welche Anweisungen, Regeln und Wissensgrundlagen ich ihm mitgegeben habe und wie daraus konkrete Anforderungstexte entstehen. Du erfährst, wie ich mit einer klaren Satzschablone arbeite, warum Prozesswörter, Verbindlichkeitswörter und eindeutige Formulierungen so wichtig sind und wie sich KI im Requirements Engineering sinnvoll einsetzen lässt. Gleichzeitig spreche ich auch offen über die Grenzen: Die Ergebnisse sind für den Einsatz auf Lastenheft-Ebene bereits nützlich, ersetzen aber noch nicht die Qualität menschlich erstellter Anforderungen. Außerdem gebe ich dir einen Ausblick darauf, wie sich Anforderungen künftig noch stärker automatisiert weiterverarbeiten lassen – etwa mit IDs, einzelnen Markdown-Dateien oder sogar in Richtung SysML V2. Wenn du wissen willst, wie du KI in der Anforderungserstellung, im Lastenheft und im Systems Engineering ganz praktisch nutzen kannst, bekommst du in dieser Episode konkrete Einblicke aus meiner Arbeitsweise.

In dieser Episode nehme ich dich mit in mein Ingenieurbüro und zeige dir, wie ich KI-gestützte Dokumentenanalyse in der Systementwicklung einsetze. Ich stelle dir meinen „Dokumentenfresser“-Agenten vor, den ich so konfiguriert habe, dass er die Rolle eines Senior Requirements Engineers übernimmt. Ich erkläre, welche Informationen ich ihm im Prompt mitgebe, welche Dokumente ich als Basis hinterlege und welche konkreten Aufgaben er für mich übernimmt: Anforderungen identifizieren, Inkonsistenzen aufzeigen, kritische Stellen markieren, Relevanz fürs Lastenheft bewerten und Empfehlungen geben, was ins Lastenheft gehört – und was nicht. Du erfährst, wie ich Schritt für Schritt aus verschiedenen PDF-Dokumenten und Grafiken ein strukturiertes Lastenheft aufbaue, welche Ergebnisse der Agent gut liefert und wo ich manuell nachschärfen muss. Anhand des Beispiels mit der Wallbox bespreche ich unter anderem Themen wie Zeitbasis (RTC), Update-Fähigkeit und die Abgrenzung zu anderen Systemen, etwa einem Batterieladegerät. Am Ende zeige ich dir, wie die gewonnenen Inhalte ins Lastenheft und später in die Systembeschreibung einfließen und welche offenen Punkte und Ideen – bis hin zu möglichen Geschäftsmodellen – die KI mir zusätzlich auf den Tisch legt. Mein Ziel mit dieser Episode ist es, dir praxisnah zu zeigen, wie du KI im Requirements Engineering nutzen kannst, ohne die Kontrolle über deine Inhalte zu verlieren. Du bekommst konkrete Anregungen, wie du deinen eigenen „Dokumentenfresser“ aufsetzt, klare Arbeitsanweisungen formulierst und so schneller zu einem besseren Lastenheft kommst.

In dieser Episode nehme ich dich mit auf meine Reise, wie ich KI sinnvoll in meinem Ingenieurbüro einsetzen möchte – speziell im Bereich Requirements Engineering. Dabei teile ich offen, warum es nicht funktioniert, einfach einen ganzen Prozess in eine KI zu „kippen“, und welche Schritte wirklich KI-tauglich sind. Ich erkläre, warum ich drei spezialisierte KI-Agenten entwickelt habe, welchen Nutzen sie bringen und welche Aufgaben weiterhin vollständig manuell bleiben müssen. Außerdem erfährst du, warum Tools wie LangDoc und Obsidian meine wichtigsten Begleiter sind und wie ich mit dem System Footprint arbeite. Diese Episode bildet den Auftakt einer mehrteiligen Serie, in der ich zeige, was funktioniert, wo ich scheitere und wie ich KI Schritt für Schritt in meine täglichen Prozesse integriere.

In dieser Episode erzähle ich dir, warum das RE-Camp für mich eines der wertvollsten Formate im Requirements und Systems Engineering ist. Ich gehe darauf ein, warum Barcamps so gut funktionieren, welche Sessionformate dich erwarten und wie du selbst Themen einbringen kannst. Außerdem erfährst du alles zur Location im Eisenwerk Hannover, zur Anreise und zu den Super-Early-Bird-Tickets. Ich freue mich besonders, dass Andreas Willert mit einem Impuls zum Thema KI dabei ist. Für mich ist das RE-Camp eine der besten Möglichkeiten, wertvolle Ideen mitzunehmen, direkt Feedback zu bekommen und sich mit Menschen auszutauschen, die ähnliche Herausforderungen haben. Wenn du dich weiterentwickeln willst, ist das RE-Camp genau der richtige Ort für dich.

In dieser Episode nehme ich Dich mit in die Welt des System Architecture Frameworks – kurz SAF – und zeige Dir, wie Du damit Struktur in komplexe Systeme bringst. Gemeinsam mit Moritz Kirchner schaue ich darauf, wo SAF herkommt und warum es ursprünglich entwickelt wurde: nämlich um Ordnung in komplexe Zusammenhänge zu bringen – weg von reiner IT-Architektur hin zu echtem Systems Engineering. Ich erkläre Dir, warum der zentrale Einstieg immer über Deine Stakeholder erfolgen sollte. Denn ihre Bedarfe – die sogenannten Concerns – bestimmen, welche Sichten auf Dein System überhaupt sinnvoll sind. Genau dafür liefert SAF eine Art Baukasten aus sogenannten Viewpoints. Ein besonders wichtiges Element ist dabei das SAF-Grid. Es hilft Dir, Dein System entlang verschiedener Ebenen – von der operativen Sicht bis hin zur physischen Umsetzung – strukturiert zu betrachten. Dabei wird eines ganz klar: Du musst nicht alles nutzen, was SAF bietet. Im Gegenteil – der wahre Mehrwert entsteht erst dann, wenn Du bewusst auswählst, welche Viewpoints für Dein konkretes Projekt sinnvoll sind. Mein Fazit für Dich: Wenn Du Dich einmal ernsthaft mit Frameworks wie SAF auseinandersetzt, gewinnst Du nicht nur Struktur – sondern vor allem Klarheit in Deinem Denken.