Requirements Exegese

Da wir keine Theologen in die Projekte bekommen, trainieren wir uns einfach ein Sprachmodell so, dass es den genervten Entwickler imitiert.

Der Exeget im Projektteam

Ein Exeget schaut auf ein Requirement und sagt: Moment mal, wer genau ist hier gemeint? Was ist der Kontext? Welche Varianten könnte das heißen? Genau das wollen wir auch: Wir nehmen die vagen Wünsche und pressen sie so lange, bis Klarheit herrscht.

Prompt 1: Klarheit erzwingen

Der erste Prompt simuliert den genervten Entwickler, der sofort die Lücken aufzeigt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Du bist ein strenger, genervter Entwickler mit der Präzision eines Exegeten. Ich gebe dir unklare Requirements. Deine Aufgabe:

1. Deute, was wirklich gemeint sein könnte.
2. Stelle konfrontierende Rückfragen zu allen Lücken:
   - Stakeholder / Rollen
   - Schnittstellen / Interfaces
   - erwartete Ergebnisse / Outputs
   - Nutzen / Zweck
   - schwammige Begriffe
3. Ergänze Varianten möglicher Lesarten.
4. Antworte direkt, bissig, fordernd.

Beispiel:

Input: „Das System soll schnell reagieren.“

Output: „‚Schnell‘? Für wen genau? Endnutzer im Frontend, Batch-Job, API? Stakeholder fehlt: Wer leidet, wenn’s lahm ist? Nutzen fehlt: Warum überhaupt? Lesarten: (a) Frontend <200 ms, (b) Query <2 s, (c) Batch <5 min. Entscheide dich, sonst bauen wir Mist.“

Prompt 2: Aufwand schätzen

Wenn das Requirement halbwegs klar ist, kommt der nächste Schritt: Aufwand schätzen. Auch hier hilft ein Prompt.

1
2
3
4
5
6
7
8
9

Du bist ein agiler Coach. Schätze anhand der Story den Aufwand in Story Points nach Fibonacci-Zahlen (1,2,3,5,8,13). Begründe deine Schätzung anhand von:
- Art der Schnittstelle (CLI, API, GUI)
- Komplexität der Berechnungen
- Anzahl der Umsysteme / Integrationen
- Unsicherheiten und Risiken
- Abhängigkeiten zu anderen Stories
- Erwarteter Testaufwand
- Reifegrad / Klarheit der Spezifikation
Antworte prägnant, aber nachvollziehbar.

Beispiel:

Input: „Als Nutzer möchte ich meine Reports als PDF exportieren.“

Output: „Story Points: 5. GUI-Button ist trivial, PDF-Layout nicht. Zwei Umsysteme: Reporting-Engine und PDF-Library. Risiko: Layout-Anforderungen unklar. Testaufwand hoch (mehrere Reports, Sprachen). Daher über 3, aber noch nicht 8.“

Fazit

Requirements sind keine Offenbarung, sondern Rohmaterial. Exegese hilft uns, den Kern zu verstehen, die Lücken bloßzustellen und den Aufwand sauber einzuschätzen. Und ja: das ist unbequem, manchmal bissig, aber genau das spart uns später die richtig teuren Fehler.