Eine KI kann aus drei Stichpunkten in wenigen Sekunden eine beeindruckende Spezifikation schreiben. Mit sauberer Gliederung, professionellen Formulierungen und einer Vollständigkeit, die auf den ersten Blick kaum Wünsche offenlässt.
Das Problem: Sie kann genauso überzeugend die falsche Lösung spezifizieren.
Wenn Ziel, Beteiligte, Randbedingungen oder Erfolgskriterien ungeklärt sind, macht ein Sprachmodell die Lücken nicht automatisch sichtbar. Es füllt sie. Aus Vermutungen werden Sätze, aus Sätzen werden scheinbar belastbare Anforderungen und aus diesen Anforderungen wird irgendwann Software. Dann ist zwar viel dokumentiert – aber möglicherweise nicht das, was gebraucht wird.
Genau deshalb wird Requirements Engineering durch KI nicht überflüssig. Es wird wichtiger.
Requirements Engineering ist mehr als ein Anforderungskatalog
Requirements Engineering klärt systematisch, was ein System leisten soll, für wen, warum und unter welchen Bedingungen. Dazu gehören vier Aufgaben, die sich nicht auf das Schreiben eines Dokuments reduzieren lassen:
- Ermitteln: Bedürfnisse, Ziele, Beteiligte, Systemgrenzen und Randbedingungen verstehen.
- Dokumentieren: Anforderungen eindeutig und angemessen strukturiert festhalten.
- Prüfen und abstimmen: Lücken, Widersprüche, Machbarkeit und gemeinsames Verständnis klären.
- Verwalten: Prioritäten, Änderungen, Versionen, Abhängigkeiten und Nachverfolgbarkeit pflegen.
Gute Anforderungen beschreiben nicht nur Funktionen. Auch Sicherheit, Datenschutz, Leistung, Bedienbarkeit, Schnittstellen, Daten, Betrieb und rechtliche Vorgaben gehören dazu. Entscheidend ist, dass eine Anforderung notwendig, verständlich, realistisch und überprüfbar ist.
„Die Anwendung soll benutzerfreundlich sein“ klingt vernünftig, ist aber kaum abnehmbar. „Ein neuer Nutzer kann den Bestellvorgang ohne Schulung in höchstens drei Minuten abschließen“ lässt sich zumindest prüfen, diskutieren und bei Bedarf korrigieren.
PRD, Lastenheft und Pflichtenheft sind nicht dasselbe
In Projekten werden diese Begriffe gerne vermischt. Ihre Trennung ist aber nützlich, weil sie unterschiedliche Perspektiven sichtbar macht.
| Dokument | Perspektive | Leitfrage | Typische Verantwortung |
|---|---|---|---|
| Product Requirements Document (PRD) | Produkt und Nutzer | Welches Problem lösen wir für wen – und woran erkennen wir den Nutzen? | Produktmanagement oder Product Owner |
| Lastenheft | Auftraggeber | Was wird benötigt, wofür und unter welchen Bedingungen? | Auftraggeber oder Fachseite |
| Pflichtenheft | Auftragnehmer | Wie werden die Anforderungen erfüllt und nachgewiesen? | Auftragnehmer, Architektur und Umsetzungsteam |
Ein PRD beschreibt Produktproblem, Zielgruppe, Nutzen, Umfang und Erfolgskriterien. Es ist besonders in der kontinuierlichen Produktentwicklung verbreitet. Der Begriff ist jedoch kein universell normiertes Dokumentformat. Teams müssen deshalb vereinbaren, welche Inhalte ihr PRD tatsächlich enthält.
Das Lastenheft formuliert den Bedarf aus Sicht des Auftraggebers: Was wird erwartet und warum? Das Pflichtenheft konkretisiert aus Sicht des Auftragnehmers, wie diese Forderungen umgesetzt und geprüft werden sollen.
Nicht jedes Vorhaben braucht alle drei Dokumente. Ein kleines Produktteam kann mit einem gepflegten PRD, überprüfbaren Anforderungen und verknüpften Entscheidungen sehr gut arbeiten. Bei einer formalen Ausschreibung oder einem Werkvertrag ist die Trennung zwischen Lasten- und Pflichtenheft meist wesentlich wichtiger.
Die Dokumentnamen sind nicht der eigentliche Qualitätsnachweis. Entscheidend ist, ob Bedarf, Lösung, Verantwortung und Abnahme voneinander unterscheidbar bleiben.
Die gefährlichste Abkürzung: Der Prompt als Anforderung
„Baue mir ein Kundenportal mit Anmeldung, Dashboard und moderner Oberfläche“ ist ein brauchbarer Gesprächseinstieg. Es ist keine belastbare Spezifikation.
Offen bleiben unter anderem:
- Wer sind die Nutzer und welche Rechte haben sie?
- Welche Aufgabe soll das Portal besser lösen als heute?
- Welche Daten dürfen Nutzer sehen und verändern?
- Welche Systeme liefern diese Daten?
- Was passiert bei Ausfällen oder widersprüchlichen Informationen?
- Welche Sicherheits-, Datenschutz- und Verfügbarkeitsanforderungen gelten?
- Woran wird entschieden, ob die Lösung abgenommen werden kann?
Ein Coding-Agent kann aus dem Prompt trotzdem eine Anwendung erzeugen. Gerade das macht die Abkürzung gefährlich. Sichtbarer Fortschritt entsteht, bevor Einigkeit über das Ziel besteht.
Was KI im Requirements Engineering gut kann
Richtig eingesetzt ist KI ein ausgesprochen nützlicher Sparringspartner. Sie kann:
- aus Gesprächsnotizen erste Anforderungen extrahieren,
- unklare Begriffe und versteckte Annahmen markieren,
- Rückfragen aus verschiedenen Rollen formulieren,
- Widersprüche zwischen Dokumentständen suchen,
- Anforderungen in ein einheitliches Format überführen,
- Akzeptanzkriterien und Grenzfälle vorschlagen,
- Beziehungen zwischen Anforderungen, Entscheidungen und Tests vorbereiten.
Sie kann beispielsweise fragen, was „schnell“, „sicher“ oder „einfach“ im konkreten Projekt bedeutet. Sie kann daran erinnern, dass ein Löschvorgang auch Aufbewahrungsfristen, Backups und verbundene Systeme betrifft. Und sie kann aus einer Änderung ableiten, welche Akzeptanzkriterien vermutlich erneut geprüft werden müssen.
Was sie nicht übernehmen sollte, ist die Verantwortung für Ziel, Priorität und Abnahme. Ob ein Risiko akzeptabel ist, ein Wunsch wirklich zum Umfang gehört oder eine Anforderung als erfüllt gilt, bleibt eine Entscheidung der zuständigen Menschen.
Eine durchgängige Kette statt einzelner Dokumente
Requirements Engineering wird besonders wertvoll, wenn Anforderungen nicht als Textfriedhof enden. Eine belastbare Kette sieht so aus:
Bedarf → Anforderung → Akzeptanzkriterium → Entscheidung → Umsetzung → Test → Nachweis
Der Bedarf erklärt, warum etwas wichtig ist. Die Anforderung beschreibt das erwartete Ergebnis. Ein Akzeptanzkriterium macht es prüfbar. Eine Architecture Decision Record hält fest, warum eine bestimmte Lösung gewählt wurde. Umsetzung, Test und Nachweis zeigen schließlich, was tatsächlich geliefert wurde.
Diese Verbindungen helfen Menschen bei Reviews und Freigaben. Einer KI geben sie zugleich Orientierung: Sie kann erkennen, welche Forderung zu einer Codeänderung gehört und welche Prüfung deren Wirkung belegt.
So bleibt der Aufwand angemessen
Requirements Engineering muss kein monatelanges Dokumentationsprojekt sein. Der Umfang sollte zum Risiko passen.
Für eine kleine interne Automatisierung können Problem, Ziel, Nicht-Ziele, Randbedingungen und einige Akzeptanzkriterien genügen. Bei personenbezogenen Daten, geschäftskritischen Abläufen oder externen Auftragnehmern braucht es deutlich mehr Präzision und Nachverfolgbarkeit.
Ein pragmatischer Start:
- Problem und gewünschte Wirkung in wenigen klaren Sätzen beschreiben.
- Beteiligte, Systemgrenze und ausdrücklich ausgeschlossenen Umfang benennen.
- Funktionale und qualitative Anforderungen getrennt erfassen.
- Jede wichtige Anforderung mit prüfbaren Akzeptanzkriterien versehen.
- Annahmen, offene Fragen und Konflikte sichtbar halten.
- Änderungen an Anforderungen versionieren und ihre Auswirkungen prüfen.
- Anforderungen mit Entscheidungen, Commits, Tests und Releases verbinden.
KI darf dabei formulieren, sortieren und hinterfragen. Sie darf aber Unklarheit nicht geräuschlos in Gewissheit verwandeln.
Klarheit vor Geschwindigkeit
KI beschleunigt die Umsetzung. Dadurch wird es teurer, am falschen Ziel besonders effizient zu arbeiten.
Requirements Engineering bremst diese Geschwindigkeit nicht aus. Es richtet sie aus. Ein gutes PRD, ein klares Lastenheft oder eine nachvollziehbare technische Spezifikation schafft den gemeinsamen Bezugspunkt, an dem Menschen und Agenten arbeiten können.
Danach beginnt der nächste Teil der Verantwortung: Die richtige Anforderung muss kontrolliert durch Implementierung, Tests und Release gebracht werden. Darum geht es im nächsten Beitrag: Vom Commit bis zum Release.
