Requirements Engineering: Anforderungen, die tragen

Artikel-Übersicht

Die meisten Projektprobleme sind Anforderungsprobleme, die erst spät sichtbar werden — meist dann, wenn etwas gebaut ist, das niemand so wollte. Dieser Leitfaden behandelt Requirements Engineering aus der Sicht derer, die damit arbeiten müssen: Entwickler, die schlechte Anforderungen bekommen, und Architekten, die daraus Entscheidungen ableiten. Er beginnt mit den vier Tätigkeiten, unterscheidet die drei Arten von Anforderungen und arbeitet heraus, welche davon architekturrelevant sind. Es folgen Erhebungstechniken, drei Vorher-Nachher-Beispiele für Formulierungen, Priorisierungsverfahren und der Abschnitt zum Verhältnis von Anforderungsarbeit und agilem Vorgehen. Zwei Teile sind im englischsprachigen Schrifttum nicht zu finden: die Unterscheidung von Lastenheft und Pflichtenheft, und der Schritt von der Anforderung zur Architekturentscheidung.

Was Requirements Engineering ist

Requirements Engineering ist die systematische Arbeit daran, herauszufinden, was ein System leisten soll — und das so festzuhalten, dass alle Beteiligten dasselbe verstehen.

Vier Tätigkeiten stecken darin:

Erheben — herausfinden, was gebraucht wird, und zwar von den Menschen, die es brauchen.
Dokumentieren — so festhalten, dass es überprüfbar ist.
Prüfen — sicherstellen, dass die Anforderung widerspruchsfrei, vollständig und abnehmbar ist.
Verwalten — Änderungen nachvollziehen, denn Anforderungen ändern sich immer.

Der letzte Punkt ist der, den formale Vorgehensmodelle unterschätzen und agile Verfahren gut lösen: Anforderungen ändern sich nicht, weil jemand schlampig war, sondern weil man beim Bauen dazulernt.

Die Arten von Anforderungen

Art	Was sie beschreibt	Beispiel	Wer sie liefert
Funktional	was das System tun soll	„Der Sachbearbeiter kann eine Rechnung stornieren."	Fachbereich
Nichtfunktional (Qualitätsanforderung)	wie gut es das tun soll	„Die Rechnungsliste lädt in unter 500 ms bei 10.000 Einträgen."	Fachbereich und Technik gemeinsam
Randbedingung	was von außen vorgegeben ist	„Die Daten müssen in der EU verarbeitet werden."	Recht, Betrieb, Einkauf

Die nichtfunktionalen Anforderungen sind die architekturrelevanten. Das ist der Satz, um den es in diesem Artikel geht. „Rechnungen drucken" lässt sich in fast jeder Architektur umsetzen. „Muss 10.000 gleichzeitige Nutzer aushalten" oder „muss auch bei Ausfall eines Rechenzentrums verfügbar bleiben" entscheidet über die Struktur des ganzen Systems.

Und der häufigste Fehler dabei: Nichtfunktionale Anforderungen werden nachgereicht. Wenn die Skalierungsanforderung erst kommt, wenn das System steht, ist sie keine Anforderung mehr, sondern ein Umbau.

Anforderungen erheben

Fünf Techniken, jede mit ihrem Anwendungsfall:

Interview. Die naheliegendste und am häufigsten schlecht gemachte. Der Fehler: nach Lösungen fragen statt nach Problemen. Wer fragt „möchten Sie einen Exportknopf?", bekommt ein Ja — und erfährt nie, dass die eigentliche Aufgabe ein monatlicher Bericht war.
Beobachtung. Jemandem bei der Arbeit zusehen. Die aufwendigste Technik und die mit dem höchsten Ertrag, weil Menschen ihre eigenen Arbeitsschritte schlecht beschreiben können.
Workshop. Mehrere Beteiligte gleichzeitig. Deckt Widersprüche zwischen Abteilungen auf, die im Einzelgespräch nie sichtbar werden.
Prototyp. Etwas Anfassbares zeigen. Menschen können deutlich besser sagen, was an etwas falsch ist, als beschreiben, was sie wollen.
Dokumentenanalyse. Bestehende Formulare, Tabellen und Anleitungen lesen. Der billigste Einstieg, und oft der Ort, an dem die tatsächlichen Regeln stehen.

Der Grundsatz über allem: Frag nach dem Problem, nicht nach der Lösung. Der Fachbereich ist Experte für seine Arbeit, nicht für Softwareentwurf. Beides zu vermischen erzeugt Systeme, die vorhandene Papierprozesse eins zu eins abbilden — inklusive ihrer Umwege.

Gute Anforderungen formulieren

Der handwerkliche Kern. Drei Paare aus der Praxis:

Beispiel 1: die unmessbare Qualitätsanforderung

Vorher: „Das System soll performant sein."

Nachher: „Die Trefferliste einer Rechnungssuche über 100.000 Datensätze wird in unter 500 Millisekunden angezeigt, gemessen am Server, im 95. Perzentil."

Was den Unterschied macht: eine Zahl, ein Bezugspunkt, eine Messstelle und eine statistische Aussage. Ohne alle vier ist die Anforderung nicht abnehmbar.

Beispiel 2: die versteckte Lösung

Vorher: „Es soll einen CSV-Export der Rechnungsliste geben."

Nachher: „Die Buchhaltung muss die offenen Rechnungen eines Monats an das Steuerbüro übergeben können. Format und Weg sind offen; heute geschieht das über eine manuell gepflegte Tabelle."

Die erste Fassung schreibt eine Lösung fest, die zweite beschreibt das Problem — und öffnet damit die Möglichkeit, dass eine Schnittstelle die bessere Antwort ist.

Beispiel 3: die unklare Zuständigkeit

Vorher: „Rechnungen sollen automatisch geprüft werden."

Nachher: „Beim Anlegen einer Rechnung prüft das System, ob die Summe der Positionen dem Rechnungsbetrag entspricht. Bei Abweichung wird die Rechnung abgelehnt und der Erfasser erhält eine Meldung mit beiden Beträgen."

Konkret geworden sind: der Auslöser, die Regel, das Verhalten im Fehlerfall und wer informiert wird.

Der Prüfstein für jede Anforderung: Kann man sie abnehmen? Wenn zwei Personen unterschiedlich beurteilen würden, ob sie erfüllt ist, ist sie noch keine Anforderung.

Priorisieren

Drei gängige Verfahren:

MoSCoW — Must, Should, Could, Won't. Einfach und wirksam, solange „Must" tatsächlich knapp bleibt. Wenn achtzig Prozent im Muss landen, wurde nicht priorisiert, sondern beschriftet.
Kano — unterscheidet Basismerkmale (fehlen fällt auf, Vorhandensein nicht), Leistungsmerkmale (mehr ist besser) und Begeisterungsmerkmale. Nützlich, um zu erkennen, wo Aufwand tatsächlich wahrgenommen wird.
Kosten-Nutzen — Aufwand gegen Wert. Setzt voraus, dass beides schätzbar ist, was am Anfang selten stimmt.

Und die organisatorische Regel, die wichtiger ist als jedes Verfahren: Priorisierung ist eine Auftraggeberentscheidung, keine technische. Die Entwicklung liefert die Aufwandsschätzung; die Reihenfolge bestimmt, wer für das Ergebnis geradesteht.

Requirements Engineering und Agilität

Ein verbreitetes Missverständnis lautet, agiles Vorgehen mache Anforderungsarbeit überflüssig. Das Gegenteil ist der Fall — sie wird nur anders verpackt.

	Klassisch	Agil
Format	Anforderungsdokument	User Story mit Akzeptanzkriterien
Zeitpunkt	vorab, vollständig	fortlaufend, gerade rechtzeitig
Prüfung	Abnahme des Dokuments	Definition of Done, Review
Änderung	Änderungsantrag	eingeplant

Die vier Tätigkeiten bleiben dieselben. Was sich ändert, ist der Zeitpunkt: Statt alles vorab zu klären, klärt man das Nächste rechtzeitig.

Was dabei regelmäßig verloren geht, sind die nichtfunktionalen Anforderungen. Sie passen schlecht in User Stories, weil sie nicht zu einem einzelnen Sprint gehören — „das System bleibt bei Ausfall eines Knotens verfügbar" ist keine Geschichte, sondern eine Eigenschaft. Sie brauchen einen eigenen Ort: eine Qualitätszielliste, ein Architekturdokument, oder als Teil der Definition of Done. Wie Scrum die Artefakte organisiert, steht in Scrum: Rollen, Artefakte und was im Alltag davon ankommt.

Von der Anforderung zur Architektur

Der Abschnitt, den kein Lehrmaterial hat — und der eigentliche Nutzen von Anforderungsarbeit für Architekten.

Das Werkzeug dafür heißt Qualitätsszenario. Es macht aus einer vagen Eigenschaft eine prüfbare Aussage, indem es sechs Teile benennt:

Teil	Beispiel
Quelle	ein angemeldeter Sachbearbeiter
Auslöser	ruft die Rechnungsliste auf
Umgebung	im Normalbetrieb, 500 gleichzeitige Nutzer
Artefakt	Rechnungsmodul
Reaktion	die Liste wird angezeigt
Maß	in unter 500 ms im 95. Perzentil

Aus diesem Szenario folgen Architekturentscheidungen unmittelbar: Bei 500 gleichzeitigen Nutzern und einer halben Sekunde Antwortzeit ist ein Zwischenspeicher wahrscheinlich nötig, die Suche gehört indiziert, und eine Paginierung nach Cursor statt Offset ist die richtige Wahl — Letzteres begründe ich in API-Design.

Zwei weitere Beispiele für den Zusammenhang:

„Die Daten müssen in der EU verarbeitet werden" ist keine funktionale Anforderung, sondern eine Randbedingung, die die Anbieterwahl bestimmt und im KI-Umfeld oft den lokalen Betrieb erzwingt — nachzulesen in Ollama: lokale Sprachmodelle betreiben.
„Mehrere Teams müssen unabhängig ausrollen können" ist eine organisatorische Anforderung mit unmittelbarer Architekturfolge; sie ist das Hauptargument in Microservices oder Monolith.

Lastenheft und Pflichtenheft

Zwei Begriffe, die im deutschsprachigen Raum verbindlich verwendet werden und in englischsprachiger Literatur nicht vorkommen. Sie werden regelmäßig vertauscht:

	Lastenheft	Pflichtenheft
Wer schreibt es	der Auftraggeber	der Auftragnehmer
Was es enthält	was gebraucht wird, aus Sicht des Bedarfs	wie es umgesetzt wird, als Antwort darauf
Wann	vor der Vergabe	nach der Vergabe, vor der Umsetzung
Rechtliche Rolle	Grundlage der Ausschreibung	Grundlage der Abnahme

Die Merkregel: Der Auftraggeber trägt die Last, der Auftragnehmer die Pflicht.

Praktisch relevant ist das vor allem bei öffentlichen Ausschreibungen und in regulierten Branchen, wo beide Dokumente vertraglich bindend sind. In Österreich und der Schweiz gelten dieselben Begriffe, die Beschaffungswege unterscheiden sich aber — wer grenzüberschreitend anbietet, sollte das prüfen.

Werkzeuge

Kurz, weil die Werkzeugfrage überschätzt wird: Für die meisten Projekte reicht das, was ohnehin da ist. Ein Ticketsystem für die Verwaltung, ein Dokument für Qualitätsziele, eine Tabelle für die Rückverfolgbarkeit.

Spezialisierte Werkzeuge lohnen ab dem Punkt, an dem Rückverfolgbarkeit verlangt wird — also der Nachweis, welche Anforderung durch welchen Code umgesetzt und durch welchen Test abgedeckt ist. Das ist in regulierten Branchen Pflicht und sonst selten den Aufwand wert.

Häufige Fragen

Was ist Requirements Engineering? Die systematische Arbeit daran, herauszufinden, was ein System leisten soll, und es so festzuhalten, dass alle dasselbe verstehen. Vier Tätigkeiten: erheben, dokumentieren, prüfen, verwalten.

Welche Arten von Anforderungen gibt es? Funktionale (was das System tut), nichtfunktionale beziehungsweise Qualitätsanforderungen (wie gut) und Randbedingungen (was von außen vorgegeben ist). Die nichtfunktionalen sind die architekturrelevanten.

Wie schreibt man eine gute Anforderung? So, dass man sie abnehmen kann. Mit Auslöser, Regel, Verhalten im Fehlerfall — und bei Qualitätsanforderungen mit Zahl, Bezugspunkt und Messstelle.

Wie priorisiert man Anforderungen? Mit MoSCoW, Kano oder Kosten-Nutzen. Wichtiger als das Verfahren ist, dass die Priorisierung beim Auftraggeber liegt und „Muss" knapp bleibt.

Passt Requirements Engineering zu agilem Vorgehen? Ja — es ist dieselbe Arbeit in anderem Format und zu anderem Zeitpunkt. Was dabei oft verloren geht, sind die nichtfunktionalen Anforderungen; sie brauchen einen eigenen Ort.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft? Der Auftraggeber schreibt das Lastenheft (was gebraucht wird), der Auftragnehmer das Pflichtenheft (wie es umgesetzt wird).

Zusammenfassung und praktische Tipps

Anforderungsarbeit entscheidet früher über den Projekterfolg als jede Technologiewahl. Die wichtigsten Punkte:

Vier Tätigkeiten: erheben, dokumentieren, prüfen, verwalten — unabhängig vom Vorgehensmodell.
Nichtfunktionale Anforderungen sind die architekturrelevanten und werden am häufigsten zu spät gestellt.
Frag nach dem Problem, nicht nach der Lösung. Sonst baut man Papierprozesse nach.
Der Prüfstein ist die Abnahme. Was zwei Personen unterschiedlich beurteilen würden, ist keine Anforderung.
Qualitätsszenarien übersetzen Anforderungen in Architektur — sechs Teile, und die Entscheidung folgt fast von selbst.
Priorisierung gehört dem Auftraggeber, die Schätzung der Entwicklung.
Lastenheft vom Auftraggeber, Pflichtenheft vom Auftragnehmer — die Merkregel: Last vor Pflicht.

Mein Rat für den Einstieg: Nimm die drei wichtigsten Qualitätsanforderungen eures Systems und schreib sie als Szenario mit allen sechs Teilen auf. Wenn dabei bei einer die Zahl fehlt oder niemand die Messstelle benennen kann, hast du genau die Anforderung gefunden, an der euer Projekt später streiten wird — und du hast sie gefunden, solange die Korrektur noch billig ist.

Ressourcen

IREB – Requirements Engineering – der deutschsprachige Standardisierungsverband mit frei verfügbarem Glossar
Qualitätsszenarien (arc42) – Vorlage und Beispiele für Qualitätsanforderungen
User Story Mapping – Jeff Pattons Verfahren zur Strukturierung von Anforderungen