dot.review - Die 30. Bärner Requirements Night in Bern vom 28. Januar 2026

Ich hab’s wieder einmal geschafft: eine Bärner Requirements Night besucht. Warum? Weil ich mit einigen Personen aus dem Board vertraut bin einerseits. Andererseits, weil das Thema mich umtreibt. Regelmässig bin ich im Thema Requirements Engineering verwickelt. In diesem Beitrag möchte ich diese Abendveranstaltung sanft resümieren. Willkommen.

Die Örtlichkeit

Die SBB sponsorte die Lokalität am Wylerpark. «Demnächst» soll ja die SBB alle ihre Büros am Campus Wankdorf zentralisieren. Für mich war’s aber irgendwie ein Zurückkommen. Ich habe im Wylerpark etliche Projekte bestritten und Workshops moderiert und Modelle skizziert. Nach so vielen Jahren bewegten mich diese Erinnerungen beim Eintreffen. Beispielsweise an das erste Vorstellungsgespräch bei der SBB im WYPB, wo ich mich als Modellierungsexperte am Flipchart beweisen musste. Danke Jüre!

Oder: Im selben Raum habe ich einst mal einen Vortrag zusammen mit Charlize Vogelsinger gehalten. Wir haben über die Unzulänglichkeit von Modellen uns Stichworte hin- und hergeworfen. Wir waren damals beide in Modelldiskussionen in der SBB beruflich vertieft – auch mit dem Gastgeber der 30. Requirements Nights, Alain Hofer. Danke euch beiden!

Für mich war die SBB immer mehr als nur eine Firma. Für mich ist die SBB ein nationales Symbol und ich bin weiterhin bin stolz erfüllt, dort in der Ära Meyer/Pilloud mitwirken und auch Mehrwert geleistet haben zu dürfen.

Doch nun zur Besprechung der Vorträge.

Christian Kaiser: AI ohne klare Anforderungen: Warum Erwartung und Realität kollidieren

Christian Kaiser ist Unternehmensarchitekt bei der SBB. Das war mal mein «Traumjob». Er verdeutlichte die Wichtigkeit der fundierten Problemanalyse – aka Requirements Engineering. Zudem warnte er davor, blind mit KI Probleme lösen zu wollen. Stattdessen solle die KI abgrenzbare Aufgaben erledigen. Als datenaffiner Architekt demonstrierte er zudem in anschaulichen SBB-Echtweltbeispielen die Bedeutung der Datenerfassung sowie -strukturierung. Ebenso sensibilisierte er die Teilnehmenden, dass für die Lösung eines Problems nicht nur eine Technologie angemessen sei – sondern in der Auseinandersetzung, also Problemerfassung die Technologie sich zeigen und herauskristallisieren werde.

So ungefähr meine Zusammenfassung. Sein kühler Vortragsstil, verstärkt durch eine subtile, aber gemutmasste Bewandtnis, hat die Aufmerksamkeitsspanne des Publikums maximiert. Ich hätte ihn sofort eingestellt oder engagiert – wäre ich suchend gewesen.

Rainer Grau: RE Education yesterday, today, tomorrow

Rainer Grau repräsentiert eine ganze RE-Epoche der Schweiz. Als Mitgestalter des bekannten IREB-Standards hat er kurz durch die Geschichte des Requirements Engineerings geführt. Als Faktenkenner habe ich keine Fehler zu beanstanden. In eleganten Klammern hat er jeweils zu aktuellen Trends sich geäussert – mit der bemerkbaren Zustimmung des Publikums.

Rainer konzentrierte sich auf die Tätigkeit des «Entwickelns». An der von ihm mitorganisierten Agile Unconference letzten Jahres war dies übrigens auch ein Thema. Für ihn versinnbildlicht Entwicklung nicht die Muskelmasse «Programmieren». Für ihn ist Entwicklung die vollendete Lösungsfindung eines Problems. Er postulierte den Requirements Engineer als grosser Orchestrator, der auch etliche KI-Agenten einsetzen kann, um das Problem zu lösen – und währenddessen stets über die Entwicklung auskunftsfähig sei. Faktisch ist das die Aufgabe eines RE, unabhängig, ob ein lokales Team, ein Near- oder Offshore-Team oder halt Agenten den Programmieraufwand bewältigen. In diese Rolle habe ich alle «meine» RE stets zu schulen versucht.

Jedenfalls verstand er es ausgezeichnet, das Publikum mit Anekdoten und Erfahrungswissen sowie Orakelfähigkeiten günstig zu beeinflussen. Auf die letzten acht Minuten seines Vortrages verzichtete er mit dem Hinweis, er brauch sie nicht. Das Publikum dankte. Sehr gelungen.

Gerd Maier: Zeitreise Anforderungs- und Nachweismanagement

Gerd Maier ist RE bei der armasuisse, der Beschaffungsorganisation des VBS. Auch Gerd ist schon seit einigen Jahrzehnten im Thema Requirements Engineering involviert. Sein Schwerpunkt bildete das Anforderungsmanagement, im aktuellen IREB-Lehrplan das 6. Kapitel, wo gemäss Alain am 3. Tag der Default IREB Foundation Schulung bereits alle Mitarbeitende dösen sollen.

Anforderungsmanagement bedeutet automatisch Werkzeugunterstützung (Kapitel 7). Also kombinierte Gerd seinen Lebenslauf mit der Geschichte der Requirements-Managements Werkzeugen. Am Anfang war das Papier, das per Business-Class durch die Welt mit entsprechenden Prüftechniken transportiert wurde. Und dann kam Excel. Und am Schluss wieder Excel.

Ich habe die Pointe bewusst vorweggenommen. Excel ist für ihn aber vielmehr «Frontend» statt «Backend». Er hat mit Excel erfolgreich die Zugänglichkeit für die Fachbereiche erhöht, weil diese komplizierten RM-Tools wirklich kompliziert in der Bedienung sind. Ich kenne riesige SMI-Konzerne, wo bloss eine handvolle Mitarbeitende die Struktur der System Requirements im spezialisierten RM-System korrekt rezitieren können – und einer davon wortwörtlich blind.

Ich bin ja bekanntlich kein Excel-Freund. Es gibt bessere Excel-Bediener (mehrheitlich männlich), ich kenne sogar in der Familie einen. Ich kann mir also gut vorstellen, dass in einem bestimmten Kontext Fachbereiche Excel bevorzugen. In diesem Sinne war Gerd der beste aller Requirements Engineers: Problem verstanden und Lösung ganz technologieoffen entwickelt. Dass Gerds Liebe zu Excel keine heimliche ist, hatte das Publikum verstanden.

BTW: Und Gerds Excel ist sowieso «nur» das Frontend, alle Anforderungen werden im «Backend» revisionssicher gespeichert; Nachvollziehbarkeit ist kein Thema - also dass wir uns hier nicht missverstehen. Für uns im Publikum war das klar.

Was nehme ich mit?

Den Netzwerk-Teil musste ich kurzhalten. Die soziale Energie ist manchmal erschöpft und der SBB-Fahrplan doch noch nicht so verdichtet. Deswegen kann ich nicht viel von neuen Kontakten etc. berichten – wäre auch als Blogformat nicht so vorteilhaft. Immerhin ein kurzes Wiedersehen mit einigen Kollegen am Platz Bern.

Für mich war Requirements Engineering niemals «gestorben». Weder zu agilen Hochzeiten noch im KI-Zeitalter. Insbesondere im KI-Zeitalter wird die Disziplin umso wichtiger. Es ist für mich weniger das «Prompt Engineering», das das Thema treibt. Das ist einigermassen «abgelatscht» – wie es beispielsweise Christian Kaiser im Nebensatz konstatierte. Für mich bleibt Requirements Engineering die Fähigkeit, Probleme zu verstehen und Lösungen entwickeln zu lassen und deren Richtigkeit überprüfen zu können – und das ganze prozessual zu begleiten und einigermassen nachhaltig im Sinne des Wissensmanagements zu dokumentieren. Umso schneller die Lösungen (beispielsweise in einer (IT-)Exploration), umso wichtiger diese Fähigkeit. Das muss meinetwegen nicht in einer ICT-Berufsrolle manifestiert sein.