Wie erfasst und präzisierst du Anforderungen?

Question

Accepted Answer

**Anforderungserfassung** ist der Prozess, herauszufinden, was tatsächlich gebaut werden muss — und *warum* — bevor es gebaut wird. Der größte Fehler von Junioren ist, eine Anfrage wörtlich zu nehmen, ohne das zugrunde liegende Problem zu verstehen.

## Wie man es angeht

```text
1. ASK WHY → understand the problem behind the request, not just the request
2. TALK to the real users / stakeholders, not just the requester
3. CLARIFY scope → what's in, what's out, what "done" looks like
4. SURFACE assumptions and constraints (deadlines, budget, tech limits)
5. WRITE IT DOWN → confirm your understanding back to them
```

## Die Anfrage vom Bedarf unterscheiden

Ein Stakeholder sagt "füge einen export-to-PDF-Button hinzu." Das reale Bedarf könnte sein "Ich muss Berichte mit meinem Chef teilen." E-Mail, ein gemeinsamer Link oder ein Dashboard könnten es besser lösen. *Warum* fragen öffnet bessere Lösungen.

## Gute klärende Fragen

```text
✓ "What problem does this solve for the user?"
✓ "What happens today without it?"
✓ "How will we know it worked?"
✓ "What's explicitly out of scope?"
✓ "What are the edge cases / what could go wrong?"
```

## Eine häufige Falle

Anzunehmen, dass du verstanden hast und anfängst zu bauen. Spiegele Anforderungen immer zurück — "also das, was du brauchst, ist X, bis Y, und Z ist außerhalb des Geltungsbereichs?" — um Lücken früh zu erkennen.

## Warum es wichtig ist

Ein festgestellter Anforderungsfehler in der Ideaphase kostet Minuten; derselbe Fehler, der nach der Veröffentlichung gefunden wird, kostet Tage oder Wochen Überarbeitung.

Klare Anforderungen sind die billigste Versicherung gegen den Bau des Falschen.

*Warum* zu fragen verwandelt dich von einem Auftragsempfänger in einen Problemlöser.