Im ersten Teil haben wir über den vertikalen Durchstich gesprochen – der erste schmale Pfad durch das System steht, die Technik funktioniert.
Und jetzt? Einfach den Rest runterprogrammieren?
Schön wäre es.
Die Realität ist: Anforderungen ändern sich, sobald Benutzer das erste Mal klicken. Was gestern auf dem Papier noch logisch klang, fühlt sich heute in der App falsch an.
Deshalb ist Requirements Engineering kein einmaliges Event am Projektstart. Es ist ein kontinuierlicher Zyklus, der erst aufhört, wenn das Projekt live geht (und oft nicht mal dann).
Der Zyklus: Ermitteln, Bauen, Lernen
Klassisch lernt man oft Modelle wie: Ermitteln -> Analysieren -> Spezifizieren -> Validieren.
Das klingt sauber und linear, aber in der Praxis ist es oft chaotischer. Und das ist okay.
Wir sehen es eher so:
- Verstehe das Problem (Ermitteln & Analysieren)
- Bau eine Lösung (Spezifizieren & Implementieren)
- Zeig es dem Nutzer (Validieren)
Und dann? Wieder von vorne.
Jede Runde macht dein Bild schärfer. Am Anfang ist alles neblig. Nach drei Runden erkennst du die Konturen. Nach zehn Runden die Details.
Versuchst du, alles im ersten Durchlauf perfekt zu machen, bleibst du ewig in der Theorie stecken.
Implizites Wissen: Was dir niemand erzählt
Das größte Risiko in der "Ermitteln"-Phase: Die Leute erzählen dir nicht alles.
Nicht aus Böswilligkeit. Sondern weil viele Prozesse für sie selbstverständlich sind. "Ja klar muss die Rechnung freigegeben werden, das macht die Karin immer am Freitag." – Das steht in keiner Prozessbeschreibung. Das weiß einfach jeder. Außer dir.
Deshalb reicht es oft nicht, Leute nur zu interviewen oder Doku zu lesen.
Unser Tipp: Geh dahin, wo gearbeitet wird.
Setz dich mal einen Vormittag neben den Sachbearbeiter, der die Anträge prüft. Schau dem Lageristen über die Schulter. Wir nennen das "Shadowing".
Du wirst Dinge sehen, die in keinem Meeting erwähnt wurden. Workarounds ("Da klick ich immer dreimal auf Zurück, sonst geht es nicht"), Zettelwirtschaften am Monitor oder informelle Absprachen.
Dieses implizite Wissen ist oft der Unterschied zwischen einer Software, die "technisch funktioniert", und einer, die den Leuten wirklich hilft.
Vorsicht vor dem "Big Design Up Front"
Auch wenn der Zyklus steht: Die Versuchung ist riesig, jetzt doch wieder alles durchzuplanen.
"Wir müssen erst das komplette Datenmodell finalisieren, bevor wir weiterbauen."
Nein, musst du nicht.
Du musst nur genug wissen, um den nächsten Schritt zu gehen.
Planung gibt Sicherheit. Aber zu viel Planung am Anfang ist oft eine Illusion von Sicherheit. Du planst auf Basis von Annahmen, nicht von Wissen.
Trau dich, Lücken zu lassen. Markiere Bereiche bewusst als "Unklar", statt sie mit Fantasie-Anforderungen zu füllen, nur damit das Ticket geschlossen ist.
Eine Lücke ("Hier wissen wir noch nicht, wie die Stornierung läuft") ist ehrlich. Eine falsche Spezifikation ("Stornierung geht immer über den Chef") ist teuer, wenn du sie später wieder ausbauen musst.
Dieser Zyklus aus Verstehen, Bauen und Lernen ist anstrengend. Er zwingt dich dazu, permanent Entscheidungen zu treffen und deine eigenen Annahmen zu hinterfragen.
Aber er ist der einzige Weg, Software zu bauen, die am Ende nicht nur fertig, sondern auch richtig ist.
Unterstützung benötigt?
Der Zyklus klingt gut, aber im Alltag frisst dich das Tagesgeschäft auf? Wir unterstützen dein Team dabei, diesen iterativen Prozess zu etablieren – pragmatisch und ohne theoretischen Ballast. Lass uns sprechen.
Im letzten Teil schauen wir uns an, wie KI-Tools und die speziellen Herausforderungen in kleinen und mittleren Unternehmen (KMU) diesen Prozess heute beeinflussen.