Hvordan samler og avklarer du requirements?

Question

Accepted Answer

**Kravinnsamling** er prosessen med å finne ut hva som faktisk må bygges — og *hvorfor* — før du bygger det. Den største feilen juniorer gjør er å ta en forespørsel bokstavelig uten å forstå det underliggende problemet.

## Hvordan du nærmer deg 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
```

## Skille forespørselen fra behovet

En interessent sier "legg til en eksport-til-PDF-knapp." Det virkelige behovet kan være "jeg må dele rapporter med sjefen min." E-post, en delt lenke eller et dashboard kunne løst det bedre. Å spørre *hvorfor* åpner opp for bedre løsninger.

## Gode avklaringsspørsmå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 vanlig fallgruve

Antakelse om at du forsto og begynning å bygge. Gjenspegl alltid krav — "så det du trenger er X, innen Y, og Z er utenfor omfanget?" — for å oppdage hull tidlig.

## Hvorfor det er viktig

En fast requirements-feil på idéstadiet koster minutter; samme feil funnet etter lansering koster dager eller uker med omarbeidelse.

Klare requirements er den billigste forsikringen mot å bygge feil ting.

Å spørre *hvorfor* gjør deg fra en ordremottaker til en problemløser.