„Wir brauchen ein zusätzliches Statusfeld.“
Das klingt nach einer überschaubaren Anforderung. Ein neues Feld, ein paar Auswahlwerte, fertig.
Vom Änderungswunsch zum Verständnis des Ablaufs
Nehmen wir ein vereinfachtes Beispiel aus dem ÖPNV: Mitarbeitende bearbeiten Kundenanliegen. Sie möchten besser erkennen, welche Vorgänge noch auf eine Rückmeldung warten.
Im Fachgespräch wird deutlich: Manche Rückmeldungen kommen von anderen Organisationen. Einige Vorgänge brauchen eine Vertretung. Und gelegentlich bleibt unklar, wer als Nächstes tätig werden muss.
Das Statusfeld kann helfen. Aber reicht es aus, um diese Situationen zu unterstützen?
Vielleicht braucht es zusätzlich eine klare Zuordnung, eine Wiedervorlage oder eine verständliche Übergabe. Welche Lösung passt, lässt sich erst beurteilen, wenn wir den Ablauf kennen.
Gemeinsam prüfbare Anforderungen entwickeln
Deshalb ist für mich eine der wertvollsten Fragen in der Softwareentwicklung:
„Was passiert in dieser Situation heute und was müsste künftig besser funktionieren?“
Die Menschen, die täglich mit einem Prozess arbeiten, kennen seine Ausnahmen. Die Entwicklung kann zeigen, welche Möglichkeiten es gibt und welche Folgen eine Umsetzung hat.
Im Gespräch entsteht daraus eine Anforderung, die beide Seiten nachvollziehen und später gemeinsam prüfen können.
Warum Fehler in Anforderungen später teuer werden können
Anforderungen bilden die Grundlage für die spätere Entwicklung. Eine Unklarheit oder eine falsche Annahme an dieser Stelle kann sich durch die gesamte Umsetzung ziehen: in die Implementierung, in die Tests und bis in die Auslieferung. Aus einem kleinen Fehler können dadurch größere Folgeprobleme entstehen. Bei einer späten Korrektur müssen wir dann möglicherweise nicht nur die Anforderung präzisieren, sondern auch die darauf aufgebaute Software und die zugehörigen Tests überarbeiten und erneut ausliefern. Das kostet Zeit und Geld.
Was sich durch Vibe-Coding verschiebt
Beim Vibe-Coding wird dieser Zusammenhang aus meiner Sicht leicht unterschätzt. Die Implementierung wird erheblich schneller, während das Verstehen und Klären der fachlichen Anforderungen weiterhin Zeit braucht. Dadurch kann die Anforderungsentwicklung plötzlich den größten Anteil der Entwicklungsarbeit ausmachen. Das kann sich so anfühlen, als würde die sorgfältige Vorbereitung den gewonnenen Geschwindigkeitsvorteil wieder aufbrauchen. Wer sie deshalb abkürzt, riskiert jedoch, dass sich falsche Annahmen schneller in der Software verbreiten und spätere Korrekturen einen Teil des Zeitgewinns tatsächlich wieder aufzehren.
Anforderungen klären gehört zur Entwicklung
Aus meiner Sicht gehört diese Arbeit zur Entwicklung genauso wie die technische Umsetzung. Sie hilft uns, die passende Funktion zu bauen und ihren Nutzen verständlich zu machen.
Welche Nachfrage hat bei euch aus einem vermeintlich kleinen Änderungswunsch eine klarere Anforderung gemacht?