RE First – sonst bleibt’s bei Funktion statt Lösung

Digitalisierung scheitert selten an der Technik, sondern daran, dass niemand genau weiss, was eigentlich gebraucht wird. Ohne ein sauberes Anforderungsfundament wird jedes Projekt zur Wundertüte. Und du verlierst die Leute, die du eigentlich mitnehmen willst.

RE: Dein Frühwarnsystem im Projekt 🚨

Requirements Engineering ist dein Frühwarnsystem, bevor Projekte entgleisen. Es hilft dir, Risiken früh zu erkennen –und sauber gegenzusteuern. Wer hier schludert, stolpert später über Annahmen, die nie jemand validiert hat.

RE heisst: Du sprichst mit den richtigen Leuten, stellst die entscheidenden Fragen, dokumentierst klar und bleibst dran. Denn Anforderungen verändern sich. Wer das ignoriert, rennt später allem hinterher.

🎯 Das Ziel ist klar: Du willst nicht einfach irgendwas umsetzen, sondern das, was das Unternehmen wirklich braucht. Und was den Leuten, die damit arbeiten, den Alltag erleichtert.

RE Wundertüte
RE Wundertüte (Bildquelle: erstellt mit ChatGPT)

Warum RE so oft unterschätzt wird 🤷‍♂️

Wenn Projekte scheitern, liegt’s selten an der Technik. Meist war von Anfang an unklar, worum es überhaupt geht. Oder niemand hat es ordentlich festgehalten. Das führt zu Umwegen, Frust und misstrauischer Stimmung.

RE bringt dir:

👉 Klarheit von Anfang an
👉 Verbindung zwischen Fachbereich und IT
👉 Vertrauen, weil alle dasselbe Bild haben
👉 Priorisierung, statt jeder schreit „Ich zuerst“
👉 Flexibilität, ohne ständig die Richtung zu verlieren

 

Zwei RE-Fails, die richtig teuer wurden 💸

RE Fails
RE Fails (Bildquelle: erstellt mit ChatGPT)

1. Ariane 5 – Flug 501 🚀💥

Die Ariane-5-Rakete explodierte 1996 kurz nach dem Start. Warum? Weil eine Softwarekomponente aus der Ariane 4 übernommen wurde, ohne zu prüfen, ob sie zu den neuen Flugprofilen und Datenmengen der Ariane 5 passt. Eine 64-Bit-Zahl wurde in eine 16-Bit-Variable gepresst und das System stürzte ab. Der Fehler kostete rund 370 Millionen Dollar. Und war letztlich die Folge eines klassischen RE-Versäumnisses: Niemand hatte hinterfragt, ob die alten Anforderungen wirklich noch passen.

2. Toll Collect (Deutschland) 🚛📉

Das Mautsystem für LKWs wurde 2003 eingeführt, mit fast zwei Jahren Verspätung. Der Staat verlor mehrere Milliarden Euro an Maut-Einnahmen. Die Gründe? Anforderungen wurden zu spät definiert, Rollen und Zuständigkeiten waren unklar, und es gab keine zentrale Stelle, die alles koordinierte. Kommunikation und Abgrenzung der Anforderungen zwischen den Partnern verliefen im Sand. Ein Paradebeispiel dafür, wie teuer fehlendes Requirements Engineering werden kann.

 

Was ich selbst erlebt habe 👨‍💻

Wir haben bei uns eine neue Fahrer-App eingeführt, verteilt auf drei Geschäftsbereiche. Im Brenn- und Treibstoffbereich haben wir eine bestehende App ersetzt. Die Anforderungen wurden im Vorfeld sauber erhoben, validiert und dokumentiert. Ergebnis: Die Einführung lief reibungslos. ✅

Im Bereich Lose Schüttgut waren wir noch komplett analog unterwegs und mussten eine ganz neue App entwickeln. Wir haben uns die Zeit genommen, die Anforderungen zusammen mit den Nutzern sorgfältig zu erarbeiten. Die App hat gepasst, der Rollout lief reibungslos. ✅

Dann kam der Bereich Paletten und Detailhandel. Nach ersten Analysen, Interviews und dem Vergleich der alten App mit dem Standard des neuen Anbieters dachten wir, wir wissen genau, was gebraucht wird, und bleiben sowieso im Standard. Wir sind davon ausgegangen, dass alles klar ist. Genau das war der Fehler. Einige Anforderungen tauchten erst mitten im Projekt auf, andere wurden falsch verstanden. Das Ergebnis: Mehraufwand, Verzögerungen und Nachbesserungen. ❌

💡Mein Fazit: Selbst bei scheinbar bekannten Themen lohnt es sich, nochmal sauber hinzuschauen. Bauchgefühl ist kein Ersatz für echtes Requirements Engineering. 

RE mit und ohne
RE mit und ohne Bildquelle: erstellt mit ChatGPT)

So holst du mehr raus 💼

🧩 Hol alle an den Tisch, auch kritische Stimmen
🛠️ Nutze strukturierte Formate wie User Stories
🔍 Hinterfrage Anforderungen laufend
📋 Dokumentiere so, dass jeder es versteht
🌱Lebe das RE-Mindset, es geht uns alle an

 

Fazit

Requirements Engineering ist kein Mehraufwand. Es ist der Unterschied zwischen Lösung und Leerfahrt. Wenn du willst, dass deine Digitalisierung mehr bringt als ein nettes Interface, fang bei den echten Anforderungen an. RE ist dein Airbag im Projekt. Lieber früh bremsen, als später gegen die Wand.

RE sichert ab
RE sichert ab (Bildquelle: erstellt mit ChatGPT)

🔗 Weiterführende Links zum Thema

 

🧑‍💼 Info-Box «Autor oder Autorin»

Christian Clauss leitet IT & digitale Transformation bei TRAVECO, einem Schweizer Logistiker. Mit über 20 Jahren Erfahrung von der Strasse bis zur Software kennt er die Branche aus allen Perspektiven. Er bloggt direkt aus dem CAS Requirements Engineering.

Beitrag teilen

Christian Clauss

Head of IT & Digital Transformation | Passion is KEY🚀🦾

Alle Beiträge ansehen von Christian Clauss →

Schreibe einen Kommentar