04 Quiz: Requirements Engineering - Prozess & Praxis

Die Sichtweise des Startup-Gründers konzentriert sich auf Product-Market-Fit, Validierung und Pivotieren. Sie stellen Fragen wie „Gibt es einen Markt dafür?” und „Werden die Leute dafür bezahlen?” Der Entwickler konzentriert sich auf Implementierungsdetails, der Projektmanager auf das Eiserne Dreieck (Umfang, Zeit, Budget) und der Produktmanager auf Wertschöpfung und Priorisierung.

Das Eiserne Dreieck besteht aus Umfang, Zeit und Budget - mit Qualität in der Mitte, die von allen dreien beeinflusst wird. Der Spruch „Gut, Schnell, Günstig - wähle zwei” erfasst den Kompromiss. Man kann nicht alles haben: Den Umfang zu erweitern und dabei die Qualität beizubehalten, erfordert typischerweise mehr Zeit oder Budget.

Beobachtung eignet sich am besten, um den tatsächlichen Arbeitsablauf im Vergleich zu dem zu verstehen, was Benutzer sagen. Menschen beschreiben in Interviews oft idealisierte oder vereinfachte Versionen ihrer Arbeit. Beobachtung lässt Sie die Workarounds, Abkürzungen und Schmerzpunkte sehen, die sie möglicherweise nicht erwähnen würden. Achten Sie jedoch auf den Hawthorne-Effekt - Menschen können ihr Verhalten ändern, wenn sie beobachtet werden.

Option C ist offen und explorativ und lädt den Stakeholder ein, seine Erfahrungen und Schmerzpunkte zu teilen. Die anderen Optionen sind geschlossene oder suggestive Fragen: A führt zu einer bestimmten Antwort, B kann nur mit Ja/Nein ohne Einsicht beantwortet werden, und D ist subjektiv ohne verwertbare Informationen. Gute Fragen helfen, Anforderungen zu entdecken, nicht Annahmen zu bestätigen.

Die 5-Warum-Technik gräbt tiefer in das wahre Bedürfnis. Durch wiederholtes Fragen „Warum?” könnten Sie entdecken, dass „schnellere Berechnung” nicht wirklich das ist, was sie brauchen - vielleicht brauchen sie eine Echtzeit-Feedback-Schleife für die Kameraeinstellung, die mit Vorhersage/Vorschau statt mit schnellerer Berechnung gelöst werden könnte. Die geäußerte Anforderung ist oft nicht die wahre Anforderung.

Der Hauptunterschied liegt darin, ob dokumentierte Anforderungen existieren: Ein Bug bedeutet, dass die Software eine bestehende, dokumentierte Anforderung nicht erfüllt. Ein Change Request bedeutet, dass der Stakeholder etwas anderes oder zusätzliches zu dem möchte, was spezifiziert wurde. Diese Unterscheidung hat erhebliche geschäftliche Auswirkungen - Bugs fallen typischerweise in die Verantwortung des Anbieters (Gewährleistung), während CRs kostenpflichtig sein können und Fristen verlängern.

Wenn die Anforderung explizit „Winkel im Bereich 0-180” spezifiziert, dann ist die Behandlung von Winkeln größer als 180 Grad eine neue Funktionalität, die von der ursprünglichen Spezifikation nicht abgedeckt ist. Dies ist ein Change Request. Wenn die Anforderung „Winkel im Bereich 0-360” gesagt hätte, wäre es ein Bug. Wenn die Anforderung zum Winkelbereich nichts gesagt hätte, wird es zu einer Grauzone, die Stakeholder-Diskussion erfordert. Klare Anforderungsdokumentation verhindert diese Streitigkeiten.

Die Unterscheidung Bug vs. CR hat direkte finanzielle und rechtliche Konsequenzen. Anbieter könnten für „Change Requests” Geld verlangen, wenn sie echte Bugs beheben. Kunden könnten „Bugs” behaupten, um neue Features kostenlos zu bekommen. Unklare Anforderungen führen zu Streitigkeiten, die zu Vertragsverhandlungen oder Rechtsfällen eskalieren können. Deshalb schützt klare Anforderungsdokumentation beide Parteien.

Die unbequeme Wahrheit über Anforderungen ist, dass Kunden oft nicht wissen, was sie wollen, bis sie es sehen. Traditionelles RE nimmt an, dass Sie Stakeholder befragen, vollständige Anforderungen schreiben, das System bauen und das liefern können, was sie wollten. Realität: Sie beschreiben, was sie denken zu wollen, Sie bauen es, sie sagen „Eigentlich meinte ich…” Lean Startup adressiert dies durch schnelle Iteration mit MVPs.

MVP steht für Minimum Viable Product - das Kleinste, was Sie bauen können, um Ihre Hypothese darüber zu testen, was Benutzer wollen. Es geht nicht darum, etwas Vollständiges mit minimalen Fehlern zu bauen (A), noch nur um technische Machbarkeit (D). Jede MVP-Iteration verfeinert Anforderungen basierend auf echtem Feedback und ersetzt Raten durch validiertes Lernen.

„Zuerst Empathie” bedeutet, Benutzer tiefgreifend zu verstehen, bevor man zu Lösungen springt. Dies beinhaltet, Benutzer in ihrer Umgebung zu beobachten, sie über ihre Erfahrungen zu interviewen und zu versuchen, ihre Schmerzpunkte aus erster Hand zu verstehen. Anforderungen entstehen aus diesem Verständnis, anstatt vorab angenommen zu werden. Der Design-Thinking-Prozess geht dann weiter durch Definieren, Ideenfinden, Prototyping und Testen.

Gen AI ermöglicht schnelles Prototyping - was traditionell Wochen dauern könnte, kann in Stunden oder Minuten erledigt werden. Dies transformiert die Anforderungsermittlung: Anstatt langer Interviews gefolgt von geschriebenen Anforderungen gefolgt vom Bauen (und oft dem Bauen des Falschen), können Sie schnelle Gespräche führen, am selben Tag funktionierende Prototypen zeigen und schnell iterieren. Anforderungen werden zu Gesprächen mit funktionierender Software als gemeinsamer Referenz.

Traditionelles RE funktioniert gut für regulierte Umgebungen (Medizin, Luftfahrt), gut verstandene Domänen mit stabilen Anforderungen, Festpreisverträge mit klar definiertem Umfang und große Systeme mit vielen Integrationspunkten. Es kämpft mit Unsicherheit, „Ich weiß es, wenn ich es sehe”-Anforderungen, schnelllebigen Märkten und Innovationskontexten, in denen POC-getriebene Ansätze besser funktionieren.

Die Ironie ist, dass Royce den grundlegenden Wasserfall-Ansatz in seinem Paper als „riskant und zum Scheitern einladend” bezeichnete. Er präsentierte ihn als warnendes Beispiel, und der Rest seines Papers beschrieb iterative Verbesserungen und Feedback-Schleifen. Die Industrie übernahm sein Diagramm, ignorierte aber seine Warnungen. Was als „Macht das nicht” gedacht war, wurde zum Standardprozess.

Die wichtigste Innovation des V-Modells ist die Paarung jeder Entwicklungsphase (linker Arm des V) mit einer entsprechenden Testphase (rechter Arm). Entscheidend ist, dass die Testplanung parallel zur Entwicklung stattfindet - Abnahmetests werden entworfen, wenn die Anforderungen geschrieben werden, nicht nach dem Codieren. Dies adressiert die Schwäche des Wasserfalls, das Testen als Nachgedanken zu behandeln.

V-Modell XT ist der vorgeschriebene Standard für IT-Projekte der deutschen Bundesregierung - es ist nicht optional, es ist gesetzlich vorgeschrieben. Viele große deutsche Unternehmen (Siemens, Bosch, SAP) verwenden es ebenfalls oder Varianten davon. Es zu verstehen demonstriert, wie regulierte Industrien Softwareentwicklung handhaben, und ist oft relevant in deutschen Industrie-Bewerbungsgesprächen.

Das Kernproblem bei sequenziellen Modellen ist, dass funktionierende Software erst am Ende erscheint. Wenn Anforderungen falsch waren, entdeckt man es Monate (oder Jahre) nachdem die Entscheidung getroffen wurde - was zu teurer Nacharbeit führt. Das V-Modell verbessert das Wasserfallmodell, indem Tests früher geplant werden, leidet aber immer noch unter diesem grundlegenden Problem des späten Feedbacks.

Boehms Forschung zeigte, dass spät gefundene Fehler dramatisch teurer zu beheben sind. Ein Anforderungsfehler, der während der Anforderungsphase gefunden wird, bedeutet, ein Dokument zu ändern. Derselbe Fehler, der in der Produktion gefunden wird, bedeutet: Anforderungen ändern, Design aktualisieren, Code umschreiben, Tests erneut durchführen, erneut deployen, Kundenauswirkungen handhaben und möglicherweise Datenmigration. Die genauen Verhältnisse sind umstritten, aber das Prinzip ist robust: späte Änderungen kosten mehr.

Benutzer können ihre Bedürfnisse oft nicht vollständig artikulieren, bis sie mit etwas Konkretem interagieren. Das ist kein Versagen - es ist menschliche Natur. Designentscheidungen brauchen auch Feedback von der Implementierung. Software wird durch Iteration gelernt, nicht wie physische Produkte hergestellt. Sequenzielle Modelle nehmen Stabilität an, aber Softwareentwicklung ist von Natur aus unsicher.

Während die traditionelle Antwort auf Änderungen „mehr Planung, mehr Dokumentation, Änderungskontrolle” ist, ist die agile Antwort, Änderungen als unvermeidlich zu akzeptieren. Das bedeutet schnelle Iteration (Sprints), frühe Wertlieferung (funktionierende Software über umfassende Dokumentation) und Zusammenarbeit mit Kunden statt starrer Vertragsverhandlung. Anforderungen werden zu lebenden Artefakten, die durch häufiges Feedback verfeinert werden.