Kravspesifikasjonen var på førti sider. Hver funksjon var beskrevet i detalj: skjermbilder, felter, arbeidsflyt. Prosjektet leverte alt som sto der. Likevel klager brukerne. Systemet er tregt i rushtiden, innloggingen oppleves tungvint, og ingen vet om løsningen tåler dobbelt så mange brukere neste år.
Det som manglet, var ikke flere funksjoner. Det var kravene ingen skrev ned: hvor raskt, hvor sikkert, hvor stabilt. De funksjonelle kravene fikk all oppmerksomheten, mens de ikke-funksjonelle ble stående som antakelser.
Denne artikkelen gir deg forskjellen på de to kravtypene, konkrete eksempler på begge, og en praktisk tilnærming til å skrive krav som faktisk kan testes.
Hva er funksjonelle krav?
Funksjonelle krav beskriver hva en løsning skal gjøre: funksjonene, forretningsreglene og oppgavene systemet skal utføre. De svarer på spørsmål om atferd. Hva skjer når brukeren trykker send? Hvem skal ha tilgang til hva?
Typiske eksempler på funksjonelle krav:
- Brukeren skal kunne logge inn med BankID
- Saksbehandler skal kunne tildele en sak til en kollega
- Systemet skal sende kvittering på e-post når søknaden er mottatt
- Fakturaer over 100 000 kroner skal godkjennes av to personer
- Løsningen skal hente adressedata fra folkeregisteret
Funksjonelle krav er som regel enkle å få øye på. De kommer naturlig når fagfolk beskriver arbeidsdagen sin, og de er greie å teste: enten finnes funksjonen og virker som beskrevet, eller så gjør den ikke det.
Hva er ikke-funksjonelle krav?
Ikke-funksjonelle krav beskriver hvor godt løsningen skal gjøre jobben: ytelse, sikkerhet, brukervennlighet, tilgjengelighet, skalerbarhet og stabilitet. De handler ikke om hva systemet gjør, men om kvaliteten på måten det gjøres på.
Eksempler fra hver kategori:
- Ytelse: svartid under to sekunder ved 500 samtidige brukere
- Sikkerhet: all persondata skal være kryptert, både under lagring og overføring
- Brukervennlighet: en ny saksbehandler skal kunne løse en standardoppgave uten opplæring
- Tilgjengelighet: løsningen skal oppfylle WCAG 2.1 nivå AA
- Oppetid: 99,9 prosent i kontortiden
- Skalerbarhet: systemet skal tåle en dobling av datamengden uten endringer i arkitekturen
Legg merke til at hvert eksempel har et tall eller en etterprøvbar standard. Det er ingen tilfeldighet. Et ikke-funksjonelt krav uten målbarhet er en ønskeliste, ikke et krav.
Forskjellen på funksjonelle og ikke-funksjonelle krav
Den enkleste huskeregelen: funksjonelle krav beskriver hva, ikke-funksjonelle beskriver hvor godt.
| Område | Funksjonelt krav | Ikke-funksjonelt krav |
|---|---|---|
| Innlogging | Brukeren skal kunne logge inn med BankID | Innloggingen skal ta under tre sekunder |
| Søknad | Systemet skal lagre innsendte søknader | Ingen søknader skal gå tapt ved serverfeil |
| Rapport | Leder skal kunne ta ut månedsrapport | Rapporten skal genereres på under ti sekunder |
| Tilgang | Saksbehandler skal kun se egne saker | Tilgangslogg skal lagres i 13 måneder |
Begge kravtypene beskriver samme løsning. De funksjonelle definerer innholdet, de ikke-funksjonelle definerer kvaliteten. Mangler den ene typen, er spesifikasjonen halvferdig.
Derfor er ikke-funksjonelle krav de som velter prosjekter
Aspiria har levert prosjekt- og testledelse i snart 30 år, i bank, offentlig forvaltning og telekom. I offentlige anskaffelser ser vi ofte kravspesifikasjoner med hundrevis av funksjonelle krav og en halv side om ytelse og sikkerhet. Det er sjelden de funksjonelle hullene som skaper krisene.
De glemmes fordi ingen eier dem
Funksjonelle krav har alltid en eier. Fagavdelingen vet hvilke funksjoner de trenger, og savner dem høylytt hvis de mangler. De ikke-funksjonelle kravene er alles og ingens ansvar: bestilleren antar at leverandøren ordner ytelsen, leverandøren antar at kravene kommer fra bestilleren.
Tallene viser hvor dyrt det blir. En undersøkelse fra PMI fant at mangelfull kravhåndtering var en hovedårsak i 47 prosent av mislykkede prosjekter, og analyser av Standish-tallene gjengitt av Reqtest sporer rundt 80 prosent av programvarefeil tilbake til kravene.
De er vage helt til noen gjør dem målbare
«Systemet skal være raskt.» «Løsningen skal være brukervennlig.» Slike formuleringer er umulige å teste, og dermed umulige å avtale. Rask for hvem? Målt hvordan?
Jobben er å oversette forventning til tall: svartid under to sekunder ved normal last, målt på de fem mest brukte skjermbildene. Først da kan teststrategien planlegge hvordan kravet skal verifiseres, og først da kan leverandøren prises på det.
De dukker opp som feil etter lansering
Et funksjonelt hull oppdages i demoen. Et ikke-funksjonelt hull oppdages i produksjon, gjerne den dagen belastningen er størst. Da er det ikke lenger et krav som mangler, det er en hendelse som må håndteres.
Kravtypen styrer også testtypen: funksjonelle krav verifiseres med funksjonelle tester, mens ikke-funksjonelle krever egne testformer som ytelsestest og sikkerhetstest. Den forskjellen er forklart i artikkelen om funksjonell og ikke-funksjonell testing.
Slik skriver du krav som faktisk kan testes
Gjør kravet målbart
Ta hvert vage krav og spør: hvordan skal vi bevise at dette er oppfylt? Svaret gir deg formuleringen.
- Før: «Systemet skal være stabilt». Etter: «Oppetid på minst 99,9 prosent i kontortiden, målt per kvartal»
- Før: «Søket skal være raskt». Etter: «Søkeresultater skal vises innen ett sekund for 95 prosent av søkene»
- Før: «Løsningen skal være sikker». Etter: «Sårbarhetsskanning skal gjennomføres før hver produksjonssetting, uten funn av kritisk alvorlighetsgrad»
Koble hvert krav til akseptansekriterier
Et krav uten akseptansekriterium blir en diskusjon ved leveransen. Definer for hvert krav hva som skal demonstreres, i hvilket miljø og med hvilke data. Dette er kjernen i akseptansetesting: bestilleren skal kunne bekrefte at kravene er oppfylt, ikke bare stole på leverandørens ord.
Prioriter, for ikke alle krav er like viktige
En kravliste der alt er «må ha», er en kravliste ingen tør røre. Skill mellom det som stopper lansering og det som kan komme i neste versjon. Prioriteringen bør skje tidlig, sammen med de andre avklaringene i spørsmålene du bør stille før prosjektstart.
Ofte stilte spørsmål om funksjonelle og ikke-funksjonelle krav
Hva er eksempler på ikke-funksjonelle krav?
Svartid og ytelse, oppetid, sikkerhet og kryptering, universell utforming (WCAG), skalerbarhet og krav til logging og sporbarhet. Felles for gode ikke-funksjonelle krav er at de er tallfestet eller knyttet til en etterprøvbar standard.
Hvem har ansvaret for de ikke-funksjonelle kravene i et prosjekt?
Bestilleren eier behovet, men noen må konkretisere det: ofte en løsningsarkitekt eller teknisk rådgiver, med testleder som verifiserende part. I prosjekter Aspiria leder, sørger vi for at de ikke-funksjonelle kravene får en navngitt eier tidlig. Uten det blir de stående som antakelser til produksjonssetting.
Hvordan testes ikke-funksjonelle krav?
Med egne testtyper: ytelsestest og belastningstest for svartid og kapasitet, sikkerhetstest for sårbarheter, brukervennlighetstest for arbeidsflyt. Disse må planlegges inn i teststrategien fra start, fordi de ofte krever egne verktøy og miljøer.
Hva skjer hvis ikke-funksjonelle krav mangler i kravspesifikasjonen?
Da bygges løsningen på antakelser, og avvikene oppdages først i produksjon, der de er dyrest å rette. I tillegg blir ansvaret uklart: leverandøren har levert alle funksjonene, men ingen avtalte hvor godt de skulle virke.
Det du ikke spesifiserer, får du ikke
Funksjonelle krav definerer hva løsningen skal gjøre. Ikke-funksjonelle krav definerer om den er brukbar i praksis. Prosjektene som lykkes, behandler begge kravtypene med samme alvor: målbare formuleringer, tydelige eiere og akseptansekriterier som kan testes.
Trenger du hjelp med kravarbeid og kvalitetssikring i IT-prosjekter? Ta kontakt med oss for en uforpliktende prat.