Modul 05 - Anforderungen die Entwickler verstehen

Was du danach weißt: Wie du einen Sachverhalt aus der Personalverrechnung so aufschreibst, dass ein Entwickler damit arbeiten kann — ohne dass du erklären musst, was Aliquotierung bedeutet.

Was du schon kannst

Du kannst jetzt Datenprobleme von Berechnungsfehlern unterscheiden, JSON in einem Fehlerlog lesen, die richtige Entität suchen und Regelkonfigurationen auf Plausibilität prüfen. Das ist die Hälfte der Arbeit. Die andere Hälfte: wenn etwas fehlt oder falsch gebaut wurde, musst du es so beschreiben können, dass ein Entwickler versteht was gebraucht wird.

Das Problem mit vagen Anforderungen

Vage Anforderung

„Das System soll das Gehalt bei unterjährigem Eintritt korrekt berechnen."

Was heißt korrekt? Ab welchem Tag? Wie viele Tage hat der Monat? Zählen Wochenenden? Was gilt im Februar?

Strukturierte Anforderung

Given: Mitarbeiterin tritt am 15. Mai ein
When: Abrechnungslauf Mai läuft
Then: Gehalt anteilig für 17 von 31 Tagen

Eindeutig, prüfbar, kein Interpretationsspielraum.

Given / When / Then

Das Format heißt Given / When / Then — es ist in der Softwareentwicklung der Standard für Akzeptanzkriterien (englisch: acceptance criteria), also die Bedingungen unter denen eine Funktion als „fertig und korrekt" gilt.

Given beschreibt die Ausgangssituation — die Daten, die im System stehen. When beschreibt den Auslöser — was passiert oder gestartet wird. Then beschreibt das erwartete Ergebnis — konkret, messbar.

Given Mitarbeiterin Huber, Vollzeit, Brutto 3.000 €, tritt am 15. Mai 2026 ein

When Abrechnungslauf Mai 2026 wird gestartet

Then Nettogehalt berechnet anteilig für 17 von 31 Tagen (≈ 1.645 € Brutto als Basis)

Edge Cases — dein Fachwissen als Anforderung

Entwickler kennen den Standardfall. Was sie nicht wissen: alle Ausnahmen, die in der Personalverrechnung selbstverständlich sind. Diese Ausnahmen heißen Edge Cases (deutsch: Sonderfälle, Grenzfälle) — und jeder Edge Case der nicht aufgeschrieben wird, wird meist nicht gebaut.

Eintritt am letzten Tag des Monats Aliquot für 1 Tag — SV-Beitragspflicht trotzdem prüfen

Eintritt im Februar (28 oder 29 Tage) Tagessatz variiert je nach Jahr — kein fixer Divisor

Rückwirkende Gehaltserhöhung Differenz muss nachberechnet werden — welcher Monat, welcher KV-Satz?

Austritt während Krankenstand Entgeltfortzahlung läuft — wann endet sie, wer zahlt?

Für jeden dieser Fälle schreibst du ein eigenes Given/When/Then. Das ist kein Mehraufwand — das ist dein Fachwissen in einer Form, die ein Entwickler direkt umsetzen und ein Tester direkt prüfen kann.

In deiner Arbeit bei P&I

Situation	Was du schreibst
Kunde meldet: „Teilmonatseintritt wird falsch berechnet"	Given/When/Then für den konkreten Fall — mit echten Zahlen aus dem Ticket
Neues Feature soll gebaut werden	Mindestens 1 Standardfall + alle Edge Cases die du kennst
Entwickler fragt: „Wie soll das bei Schaltjahr funktionieren?"	Given: Februar hat 29 Tage / When: … / Then: Tagessatz = Brutto ÷ 29

Du musst nicht wissen, wie der Entwickler es umsetzt. Du musst wissen, was das richtige Ergebnis ist — und das weißt du bereits. Given/When/Then ist nur die Form, in der du es aufschreibst.

Nach diesen fünf Modulen kannst du Datenprobleme benennen, Logs lesen, Entitäten zuordnen, Regelkonfigurationen prüfen und Anforderungen formulieren. Das ist das Handwerkszeug für deine Rolle bei P&I.

Denke mal nach: Welcher Sonderfall aus deiner Erfahrung in der Personalverrechnung hat dich selbst überrascht — etwas das du erst durch einen Fehler oder eine Rückfrage gelernt hast? Wie würdest du ihn als Given/When/Then aufschreiben?