Wir rocken Engineering

Warum fällt es uns so schwer, unsere eigene Oberfläche zu testen? Weil wir jedes Menü schon kennen. In Folge 254 spreche ich mit Georg Haupt darüber, wie du dich davon löst. Lass Menschen ran, die dein Produkt noch nicht kennen, und beobachte sie. Du erfährst, warum einfache Papierprototypen schon früh Schwächen zeigen, zum Beispiel wenn die eingeblendete Tastatur ein wichtiges Feld verdeckt. Wir sprechen auch über das BFSG und die WCAG-Richtlinien. Klarer Kontrast, gute Struktur und verständliche Texte helfen vielen Menschen, nicht nur denen mit Einschränkungen. Du bekommst außerdem Tipps, wie du Usability-Anforderungen konkret formulierst, statt mit Begriffen wie „einfach“ oder „intuitiv“ zu arbeiten. Und du lernst drei Methoden kennen: Beobachtungstests, Prototypen und automatische Scanner. Die Scanner prüfen technische Details, aber Verständlichkeit beurteilt am Ende nur ein Mensch. Hör rein und prüfe deine nächste Oberfläche, bevor sie fertig ist.

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.