Willkommen zurück. Im ersten Teil haben wir die häufigsten Gründe aufgedeckt, die Softwareprojekte ins Straucheln bringen. Du kennst jetzt die Warnsignale: vage Wünsche und die verlockende Hoffnung, ein neues Tool könnte alle Probleme lösen.
Doch was kommt danach? Wie machen wir es stattdessen richtig? Als Software-Denker, der Dich durch diesen Dschungel begleitet, öffne ich heute meinen Werkzeugkoffer. Es geht nicht um starre Bürokratie, sondern um einen strukturierten Dialog. Ich zeige Dir den 3-Schritte-Prozess, mit dem wir gemeinsam aus einem diffusen Wunsch einen klaren, umsetzbaren Plan schmieden.
Schritt 1: Bedürfnisse ermitteln; die Kunst, die richtigen Fragen zu stellen
Der häufigste Fehler am Anfang ist, die falsche Frage zu stellen. Die Frage „Was willst Du?“ führt zu einer Wunschliste an Features. Die entscheidende Frage lautet aber: „Welches Problem soll gelöst werden?“
Stell Dir vor, Du hast Produkte wie in dieser Tabelle: Herunterladen
| Produkt-ID | Name | Kategorie | Preis |
|---|---|---|---|
| 101 | Premium-Schraube V2A | Eisenwaren | 0,79 |
| 205 | Profi-Hammer 500g | Werkzeuge | 24,99 |
Der Vertrieb sagt: „Ich will die Preise direkt in einer Liste ändern können!“ Das ist der Wunsch.
Als Software-Denker frage ich weiter: „Warum willst Du das? Welches Problem löst das für Dich?“
Die Antwort könnte lauten: „Weil ich für Großkunden individuelle Rabatte geben muss und das aktuell Stunden dauert.“ Siehst Du den Unterschied? Das Problem ist nicht die fehlende Funktion, sondern der manuelle Aufwand bei der Rabattierung. Vielleicht ist die Lösung gar keine editierbare Liste, sondern ein intelligentes Rabatt-Modul. Anforderungen richtig zu ermitteln, bedeutet, hinter den Wunsch auf das eigentliche Bedürfnis zu blicken.
Schritt 2: Anforderungen analysieren; die Punkte verbinden
Selten hat ein Unternehmen nur einen Stakeholder. Der Vertrieb will schnelle, flexible Preise. Die Buchhaltung will nachvollziehbare, standardisierte Preisänderungen, um die Abrechnung nicht zu verkomplizieren. Das IT-Sicherheitsteam verlangt kontrollierte Zugriffsrechte.
Hier kommt meine Rolle als Software-Denker ins Spiel. Meine Aufgabe ist es, diese scheinbar widersprüchlichen Wünsche zu analysieren und auf ein gemeinsames Ziel auszurichten.
Wir bringen alle an einen Tisch und visualisieren den Prozess:
- Wie sieht der Weg eines Preises von der Eingabe bis zur Rechnung aus?
- Wer muss wann informiert werden?
- Welche Daten braucht die Buchhaltung am Monatsende?
Indem wir den gesamten Prozess transparent machen, schaffen wir Verständnis für die Bedürfnisse der anderen. Oft entstehen so die besten Lösungen: ein flexibles Rabatt-Modul, das jede Änderung in einem Protokoll für die Buchhaltung festhält.
Schritt 3: Annahmen validieren; Klartext schaffen, bevor es teuer wird
Wir haben jetzt eine Idee. Aber reden wirklich alle vom Gleichen? Nichts ist gefährlicher als Annahmen. Deshalb ist der letzte Schritt vor der Umsetzung der Realitäts-Check.
Statt ein 100-seitiges Dokument zu schreiben, das jeder auf andere Art interpretiert, nutzen wir einfache, aber wirkungsvolle Methoden:
- Der Klick-Dummy: Wir erstellen eine simple, klickbare Oberfläche ohne echte Funktion. Der Vertriebsmitarbeiter kann sich durch den Rabatt-Prozess klicken. Fühlt es sich richtig an? Ist es wirklich schneller?
- Die Whiteboard-Skizze: Manchmal reicht eine 10-Minuten-Skizze, um aufzudecken, dass zwei Abteilungen von völlig unterschiedlichen Prozessen sprechen. Diese Skizze hat schon unzählige Stunden an teurer Nacharbeit gespart.
Dieser Schritt der Validierung ist die günstigste Form der Qualitätssicherung. Jede Unklarheit, die wir hier aufdecken, spart ein Vielfaches an Kosten im Vergleich zu einer Änderung an der fertigen Software.
Fazit und Ausblick
Anforderungsentwicklung ist kein passives Dokumentieren. Es ist ein aktiver, begleiteter Prozess des Verstehens, Vermittelns und Validierens. Er verwandelt vage Wünsche in ein solides Fundament, auf dem dann Software-Entwickler aufbauen können.
Dieser Prozess rettet aber nicht nur Dein Projekt, er kann die Kultur Deines Unternehmens verändern. Im letzten Teil dieser Serie zeige ich Dir die strategischen Auswirkungen, die ein sauberer RD-Prozess für Dein ganzes Unternehmen hat – weit über ein einzelnes Projekt hinaus.
Was ist der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen?
Eine funktionale Anforderung beschreibt, was das System tun soll (zum Beispiel „Berechne den Rabatt“). Eine nicht-funktionale Anforderung beschreibt, wie es das tun soll (zum Beispiel „Die Berechnung muss in unter 0,5 Sekunden erfolgen“ oder „Das System muss sicher vor unbefugtem Zugriff sein“).
Muss ich immer alle drei Schritte durchführen, auch bei kleinen Projekten?
Ja, unbedingt! Der Aufwand skaliert mit der Projektgröße. Bei einem kleinen Projekt kann „Validieren“ auch ein 15-minütiges Gespräch am Whiteboard sein. Die Schritte zu überspringen, ist immer riskanter, als sie im kleinen Maßstab durchzuführen.
Wie gehe ich mit Anforderungen um, die sich während des Projekts ändern?
Änderungen sind normal und oft sogar gut, weil sie auf neuen Erkenntnissen basieren. Ein guter Anforderungsprozess schafft einen klaren Weg, wie diese Änderungen bewertet, priorisiert und eingeplant werden (das sogenannte „Change Management“), anstatt das Projekt ins Chaos zu stürzen.