Hvordan indsamler og præciserer du krav?

Question

Accepted Answer

**Kravindsamling** er processen med at finde ud af, hvad der faktisk skal bygges — og *hvorfor* — før det bygges. Den største fejl, som juniorer gør, er at tage en anmodning bogstaveligt uden at forstå det underliggende problem.

## Hvordan man tackler det

```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
```

## Skelne mellem spørgsmål og behov

En interessent siger "tilføj en export-to-PDF-knap." Det reelle behov kunne være "jeg har brug for at dele rapporter med min chef." E-mail, et delt link eller et dashboard kunne løse det bedre. At spørge *hvorfor* åbner op for bedre løsninger.

## Gode præciserende spørgsmål

```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?"
```

## En almindelig fælde

At antage, at du forstod det, og begyndte at bygge. Reflektér altid kravene tilbage — "så det du har brug for er X, efter Y, og Z er uden for scope?" — for at fange huller tidligt.

## Hvorfor det betyder noget

En fastlagt kravfejl på idéstadiet koster minutter; den samme fejl, der findes efter frigivelse, koster dage eller uger med omarbejde.

Klare krav er den billigste forsikring mod at bygge den forkerte ting.

At spørge *hvorfor* omdanner dig fra en ordreopfylder til en problemløser.