Erst denken, dann coden: Requirements Engineering für Einsteiger

Wenn du noch nicht so lange programmierst, kennst du das vermutlich: Jemand erklärt dir kurz, was gebaut werden soll, du denkst dir "passt, hab ich verstanden" und legst los. Zwei Tage später stellt sich heraus: Missverständnis. Der Fachbereich wollte etwas anderes, ein wichtiger Fall wurde vergessen oder eine scheinbar kleine Anforderung zieht auf einmal einen Rattenschwanz an Änderungen hinter sich her.

Genau an dieser Stelle kommt Requirements Engineering ins Spiel. Das klingt erstmal nach großer Konzernwelt, Meetings und dicken PDFs. In der Praxis geht es aber um etwas ziemlich Bodenständiges: Klar verstehen, was gebraucht wird, bevor du länger an der Umsetzung sitzt.

Was ist Requirements Engineering eigentlich?

Requirements Engineering (oft kurz RE) ist der Teil der Softwareentwicklung, der sich damit beschäftigt, Anforderungen an ein System zu sammeln, zu strukturieren, zu prüfen und zu pflegen. Also alles, was vor dem eigentlichen Coden passieren sollte und währenddessen immer wieder mitläuft.

Der zentrale Punkt: Aus "Mach mal eine Zeitverwaltung" werden konkrete, verstandene und dokumentierte Anforderungen wie zum Beispiel:

- Benutzer sollen ihre tägliche Arbeitszeit erfassen können.
- Es muss möglich sein, Korrekturen für vergangene Tage zu beantragen.
- Teamleiter sollen die Zeiten ihrer Mitarbeitenden genehmigen können.

Damit wird aus einem vagen Wunsch eine greifbare Beschreibung, gegen die du entwickeln und später testen kannst.

Warum überhaupt der Aufwand?

Gerade als Anfänger ist die Versuchung groß, möglichst schnell Code zu schreiben. Requirements Engineering wirkt dann wie eine Bremse. In Wirklichkeit ist es das Gegenteil: Es spart dir Zeit, Nerven und peinliche Nachfragen im Nachhinein.

Ein paar typische Probleme ohne vernünftige Anforderungen:

- Du baust etwas, das formal funktioniert, aber am eigentlichen Bedarf vorbeigeht.
- Du vergisst Sonderfälle (Fehlerfälle, Randbedingungen, Sicherheit), weil sie nie klar angesprochen wurden.
- Schätzungen werden völlig danebenliegen, weil nicht klar war, wie gross der Umfang wirklich ist.
- Beim Testen weisst du nicht so genau, was "fertig" oder "korrekt" bedeutet.

Requirements Engineering sorgt dafür, dass aus "so in etwa" ein "genau so" wird. Und das ist die Grundlage dafür, dass dein Code später auch wirklich passt.

Arten von Anforderungen

Im Alltag wirst du immer wieder über drei Typen von Anforderungen stolpern, auch wenn niemand sie so nennt:

Funktionale Anforderungen beschreiben, was das System tun soll. Beispiel: "Das System berechnet für jede Buchung die Umsatzsteuer und speichert sie mit ab."

Nicht-funktionale Anforderungen beschreiben Qualitätsmerkmale. Also wie schnell, wie sicher, wie stabil das System sein soll. Beispiel: "Der Loginvorgang soll in unter zwei Sekunden abgeschlossen sein."

Randbedingungen geben Rahmen und Einschränkungen vor: bestehende Systeme, Technologien, rechtliche Vorgaben, Firmenstandards. Beispiel: "Die Anwendung läuft auf einem Wildfly-Server, die Daten müssen mindestens 10 Jahre aufbewahrt werden."

Wenn du Anforderungen aufschreibst oder mit jemandem klärst, lohnt es sich im Hinterkopf zu behalten, in welchen dieser Bereiche das Gesagte fällt. Dann merkst du schneller, was noch fehlt.

Wie kommst du zu guten Anforderungen?

Requirements Engineering klingt theoretisch, ist aber im Kern nichts anderes als vernünftig Fragen zu stellen und die Antworten verständlich festzuhalten. Ein paar konkrete Ansätze, die du direkt nutzen kannst:

1. Nach konkreten Beispielen fragen

Statt dich mit einem Satz wie "Wir brauchen eine flexible Berichtsfunktion" zufriedenzugeben, fragst du nach: "Welche Berichte genau?", "Wer nutzt die?", "Wie oft?", "Was muss darin mindestens stehen?".

2. Use Cases und Szenarien

Hilfreich ist, in Abläufen zu denken: "Benutzer meldet sich an", "Benutzer erfasst Zeiten", "Teamleiter prüft und genehmigt". Für jeden Ablauf fragst du dich: Was ist der normale Weg? Was passiert, wenn etwas schiefgeht (falsche Eingaben, fehlende Berechtigungen, technische Fehler)?

3. User Stories als leichtgewichtige Form

Gerade in agilen Teams werden Anforderungen oft als User Stories formuliert, zum Beispiel:

Als Teamleiter möchte ich die erfassten Zeiten meines Teams einsehen, damit ich sie kontrollieren und freigeben kann.

Dazu kommen dann Akzeptanzkriterien, also Bedingungen, die erfüllt sein müssen, damit die Story wirklich "fertig" ist:

- Zeiten müssen für den ausgewählten Zeitraum gefiltert werden können.

• Pro Mitarbeiter sollen Summe und Einzelbuchungen sichtbar sein.
• Nur Teamleiter mit entsprechender Berechtigung dürfen die Ansicht öffnen.

Solche einfachen Formate reichen für viele Fälle völlig aus, solange sie ehrlich gepflegt und bei Änderungen aktualisiert werden.

Dokumentieren, aber nicht tot-dokumentieren

Requirements Engineering bedeutet nicht automatisch, dass du riesige Word-Dokumente pflegen musst. Wichtig ist, dass die Anforderungen dort stehen, wo ihr im Alltag wirklich damit arbeitet:

- Als Tickets im Issue-Tracker (z.B. Jira, GitLab, GitHub).
- Als User Stories mit Akzeptanzkriterien im Backlog.
- Als kurze, klar benannte Seiten im Wiki für Querschnittsthemen (z.B. "Passwortregeln", "Performanceanforderungen").

Wichtiger als das Werkzeug ist die Qualität der Inhalte: verständlich, eindeutig, auffindbar und aktuell. Wenn sich Anforderungen ändern (und das tun sie), musst du die Dokumentation nachziehen. Sonst verlierst du das Vertrauen in deine eigenen Unterlagen und fängst wieder an, Dinge "aus dem Kopf" zu machen.

Wie Requirements Engineering dir beim Coden hilft

Am Ende des Tages soll RE dir das Leben als Entwickler leichter machen, nicht schwerer. Ein paar Effekte merkst du recht schnell:

- Du kannst aus einer klaren Anforderung direkt auf deine Schnittstellen und Datenstrukturen schliessen.
- Du erkennst früher, wenn etwas in der Architektur nicht zusammenpasst.
- Du kannst besser einschätzen, wie viel Arbeit eine Aufgabe wirklich ist.
- Du hast eine Basis für Tests: Jede Anforderung kannst du später pruefen.

Ein kleines Beispiel: Aus der Anforderung

Als Benutzer möchte ich meine persönliche Wochenarbeitszeit sehen, damit ich meine Überstunden im Blick habe.

kannst du dir schnell eine passende Methode vorstellen:

public WeeklyWorktimeOverview getWeeklyWorktimeOverview(UserId userId, LocalDate weekStart) {
    // Implementierung
}

Und du kannst später beim Testen konkret fragen: Wird für den korrekten Benutzer und den richtigen Zeitraum gerechnet? Werden Pausen richtig berücksichtigt? Das ist viel klarer, als einfach nur "irgendwie eine Überstundenanzeige" zu bauen.

Fazit: Requirements Engineering gehört direkt in deinen Alltag

Auch wenn du "nur" seit ein paar Monaten code schreibst: Requirements Engineering ist nichts, was erst ab einer gewissen Seniorität relevant wird. Im Gegenteil, je früher du dir angewöhnst, gezielt nachzufragen, Beispiele einzufordern und Anforderungen verständlich festzuhalten, desto entspannter werden deine Projekte.

Du musst dafür keine komplizierten Modelle malen. Fang einfach damit an, Anforderungen bewusst wahrzunehmen, sie schriftlich festzuhalten und sie mit den Beteiligten abzugleichen. Der Rest entwickelt sich mit der Zeit von allein. Und du wirst merken: Saubere Anforderungen fühlen sich irgendwann genauso selbstverständlich an wie ein sauber strukturierter Code.