Et funksjonelt krav sier hva systemet skal gjøre. Håndverket i én enkelt kravsetning er dekket i sin helhet under Formulering — kravnivå, testbarhet, entydig språk, nummerering. Her handler det om kapittelet som helhet: hvordan du organiserer kravene, hvor detaljert du går, og hvordan du unngår at listen blir en ønskeliste.
Grupper etter arbeidsprosess, ikke etter skjermbilde
Den vanligste inndelingen er etter modul eller skjermbilde: «Søkefunksjonalitet», «Rapportmodul», «Administrasjon». Problemet er at du da har begynt å beskrive en løsning før du vet hvilken løsning du får. Se beskriv behovet, ikke løsningen.
Grupper heller etter det arbeidet som skal utføres: «Motta og registrere søknad», «Vurdere og behandle», «Fatte vedtak og arkivere», «Følge opp frister». Da kan en leverandør vise hvordan deres løsning dekker prosessen — også hvis den gjør det på en smartere måte enn dere hadde forestilt dere.
Prosessinndeling gjør det også lettere å se hva som mangler. Et hull i en prosess er synlig; et hull i en modulliste er det ikke.
Hvor detaljert?
Riktig detaljnivå er det som gjør kravet mulig å evaluere og etterprøve, og ikke mer. Går du lenger, begynner du å designe — og du betaler for det på tre måter: dokumentet blir lengre, tilbudene blir dyrere, og du utelukker løsninger som er bedre enn den du så for deg.
| Nivå | Eksempel | Vurdering |
|---|---|---|
| For grovt | Systemet skal støtte saksbehandling. | Kan ikke evalueres. Alle svarer ja. |
| Riktig | Systemet skal varsle saksbehandler når en sak nærmer seg lovpålagt frist, med varslingstidspunkt som kan settes per sakstype. | Etterprøvbart, uten å låse løsningen. |
| For detaljert | Systemet skal vise et rødt varselikon øverst til høyre i saksbildet, med tekst i 12 punkt. | Du har designet. Se for detaljert for tidlig. |
Hvor mange krav?
Det finnes ikke et riktig tall, men det finnes et varsku: hvis listen er så lang at ingen i prosjektgruppen har lest den i sin helhet den siste måneden, er den for lang. Da evaluerer du heller ikke tilbudene på den — du evaluerer på et utdrag, og resten er ballast som følger med inn i kontrakten.
En praktisk øvelse: gå gjennom listen og merk hvert krav med hvilket mål det tjener. Krav som ikke tjener noe mål er kandidater for stryking. Det pleier å være flere enn man tror.
Skill mellom krav og forklaring
Kravet er den bindende setningen. Alt annet — bakgrunn, eksempler, hvorfor dere trenger det — er nyttig, men skal stå tydelig atskilt. Ellers vet ingen hva som er avtalt og hva som er kontekst.
K-212 (skal) Systemet skal varsle ansvarlig saksbehandler når en sak har 10 virkedager igjen til lovpålagt frist.
Bakgrunn: Frister følges i dag manuelt i regneark. I 2025 gikk 14 saker over frist, 11 av dem fordi fristen ikke ble oppdaget.
Verifiseres ved: Demonstrasjon i akseptansetest, med sak opprettet slik at fristen inntreffer.
Tre linjer per krav høres mye ut, men det er raskere å skrive enn å diskutere i ettertid. Feltet «verifiseres ved» er også halve jobben med kapittel 11, gjort på forhånd.
La leverandøren svare strukturert
Be om svar per kravnummer, med en fast svarform: oppfylt som standard, oppfylt med konfigurasjon, oppfylt med tilpasning, eller ikke oppfylt. Da kan du sammenligne tilbudene mot hverandre i stedet for å lese fire ulike salgstekster.
Skillet mellom «standard» og «tilpasning» er verdt mye. Tilpasninger må vedlikeholdes, og de følger deg gjennom hele levetiden — det er en kostnad som ikke synes i tilbudsprisen.
Vanlige feil
- Kravene er hentet fra dagens system. Da spesifiserer du en kopi av noe dere er i ferd med å bytte ut. Se den kopierte kravlisten.
- Alt er merket skal. Se skal, bør og kan og når alt er skal-krav.
- Krav med flere krav i seg. «Systemet skal varsle og eskalere og logge» kan bli halvveis oppfylt. Se ett krav per krav.
- Ikke-funksjonelle krav gjemt i listen. Ytelse, sikkerhet og drift hører hjemme i kapittel 8, der de blir sett — ikke spredt utover som enkeltsetninger.