- Er problemet beskrevet som noe som skjer, ikke som noe som mangler? «Frister oversittes» er et problem. «Vi mangler fristvarsling» er en løsning forkledd som problem. Se behovsanalyse.
- Vet dere hva problemet koster i dag? Minst ett tall med forklart grunnlag. Uten det kan ingen vurdere om løsningen er verdt prisen.
- Er alternativene til nytt system vurdert og forkastet skriftlig? Endret rutine, bedre bruk av det dere har, utvidelse. Se trenger dere nytt system?
- Har dere tre til fem mål med nåverdi, ønsket verdi og tidspunkt? Mål uten utgangspunkt kan ikke etterprøves. Se mål og gevinster.
- Er interessentene kartlagt, inkludert de med høy påvirkning og lav interesse? Personvernombud, arkiv, drift, tillitsvalgte. Se interessentkartlegging.
- Har dere snakket med folk som faktisk gjør jobben? Fem intervjuer er minimum. Se intervju.
- Har dere volumtallene? Brukere, samtidige brukere, transaksjoner, datamengde, historikk. Se dagens situasjon.
- Er budsjettrammen kjent — for hele avtaleperioden? Ikke bare anskaffelsen. Drift og forvaltning er som regel den største samlede posten.
- Vet dere hvem som kan ta beslutninger om kravene? Med navn, ikke med avdeling. Se hvert krav trenger en eier.
- Har dere snakket med markedet? Det er lov, det er nyttig, og det avgjør om kravene blir realistiske. Se markedsdialog og RFI.
Det ene spørsmålet som betyr mest
Hvis du bare rekker ett: har dere snakket med dem som skal bruke systemet? Nesten alle de andre punktene lar seg reparere underveis. Et kravdokument skrevet uten brukerne gjør det sjelden.
Hva du gjør med hullene
Du trenger ikke svare ja på alt for å begynne. Du trenger å vite hvilke du ikke kan svare på, og hva du gjør med dem. Skriv dem opp som åpne punkter med en eier og en frist — da blir de fulgt opp i stedet for å bli antakelser i kravteksten.
Det er også helt i orden å skrive et første utkast parallelt med at hullene tettes. Faren er bare at utkastet får lov til å bli sannheten før tallene kommer.