Funksjonelle og ikke-funksjonelle krav i praksis
Funksjonelle krav beskriver hva systemet skal gjøre: funksjoner og arbeidsflyter. Ikke-funksjonelle krav beskriver hvor godt det skal gjøre det: ytelse, sikkerhet, oppetid og brukervennlighet. Det er som regel de ikke-funksjonelle kravene som glemmes og ender som dyre overraskelser sent i prosjektet. Gjør dem målbare og prioriter dem hardt, for alt kan ikke være viktigst.
De fleste kravlister er fulle av hva systemet skal gjøre, og nesten tomme for hvor godt det skal gjøre det. Nettopp der, i det usagte, skjuler de dyreste overraskelsene seg. Et system kan oppfylle hvert eneste funksjonelle krav og likevel være ubrukelig fordi det er for tregt, for usikkert eller bryter sammen under last. Denne guiden forklarer forskjellen og viser hvordan du gjør de glemte kravene målbare, og hvordan du prioriterer når alt føles like viktig.
Forskjellen i klartekst
Funksjonelle krav beskriver systemets funksjoner: hva en bruker skal kunne gjøre. «Kunden skal kunne betale med kort», «administratoren skal kunne eksportere en rapport», «ordren skal sendes til lageret». De er konkrete og lette å komme på fordi de tilsvarer det man ser for seg når man tenker på systemet.
Ikke-funksjonelle krav beskriver egenskapene: hvor godt funksjonene skal virke. Hvor raskt betalingen skal gå, hvor mange som kan handle samtidig, hvordan sensitive opplysninger beskyttes, hvor ofte systemet får lov til å være nede. De vises ikke i en funksjonsliste, men avgjør om systemet holder mål i virkeligheten. En vanlig misforståelse er å tro at de er «tekniske detaljer» utviklerne uansett løser. I realiteten er de forretningskrav: Et for tregt system mister kunder, et usikkert system blir en risiko.
En katalog over de glemte kravområdene
Nettopp fordi de ikke-funksjonelle kravene føles selvsagte, blir de ofte aldri uttalt. Her er områdene som oftest mangler, med eksempler på hvordan et krav kan formuleres:
- Ytelse. «En sidelasting skal skje på under 2 sekunder for 95 prosent av forespørslene ved 500 samtidige brukere.»
- Skalerbarhet. «Systemet skal tåle en tidobling av antall brukere uten ny arkitektur.»
- Oppetid. «Tjenesten skal være tilgjengelig 99,9 prosent av tiden per måned, målt utenom planlagte vedlikeholdsvinduer.»
- Sikkerhet. «Alle personopplysninger skal krypteres både lagret og under overføring, og tilgang skal logges.»
- Brukervennlighet. «En ny bruker skal kunne fullføre en bestilling uten veiledning.»
- Universell utforming. «Grensesnittet skal oppfylle WCAG på nivå AA.»
- Forvaltbarhet. «Systemet skal være dokumentert slik at en ny utvikler kan sette seg inn i det på rimelig tid.»
Listen er ikke komplett, men den fanger opp de områdene som pleier å koste mest når de mangler. Bare det å gå gjennom listen for prosjektet deres avslører ofte krav som ellers først ville ha dukket opp i drift.
Slik gjør du kravene målbare og testbare
Et ikke-funksjonelt krav som ikke kan måles, er verdiløst, for ingen kan si om det er oppfylt. «Systemet skal være raskt og sikkert» høres bra ut, men betyr ingenting. Det kan ikke testes og kan derfor heller ikke kreves.
Forskjellen ligger i å bytte ut magefølelsen med et tall, en betingelse og en måte å verifisere på. «Raskt» blir «under 2 sekunder ved 500 samtidige brukere». «Sikkert» blir konkrete krav til kryptering, tilgangsstyring og logging. «Stabilt» blir et tall for tillatt nedetid. Når kravet er formulert slik, kan man bygge mot det, teste mot det og holde leverandøren ansvarlig for det. En god test av et krav er enkel: Kan to personer være uenige om det er oppfylt? Da er det ikke målbart ennå.
Prioriter når alt føles viktig
Når kravene først er skrevet ned, dukker neste felle opp: Alt føles som et må-krav. Men hvis alt har høyest prioritet, finnes det ingen prioritering, og da styrer tilfeldighetene eller den som roper høyest.
En velprøvd metode er å sortere hvert krav som må-, bør- eller kan-krav, med et bevisst tak for hvor mange som får være må-krav. Det tvinger frem de reelle avveiingene. Et utfyllende grep er å spørre for hvert krav: Hva skjer hvis det ikke oppfylles? Kan virksomheten leve med konsekvensen, er kravet sjelden et må-krav, uansett hvor ønskelig det er.
| Prioritet | Betydning |
|---|---|
| Må-krav | Systemet er ubrukelig eller ulovlig uten det; taket holdes bevisst lavt |
| Bør-krav | Gir tydelig verdi, men kan skyves til en senere versjon |
| Kan-krav | Fint hvis tid og budsjett strekker til, men aldri på bekostning av et må-krav |
Poenget er at prioriteringen skjer på papiret, i ro og mak, i stedet for under press midt i prosjektet når et glemt krav plutselig kolliderer med budsjettet.
Ta kravene på alvor tidlig
Funksjonelle krav er lette å komme på og blir sjelden prosjektets fallgruve. Det er de ikke-funksjonelle (ytelse, sikkerhet, drift, forvaltning) som avgjør om systemet holder i virkeligheten, og de koster en brøkdel å bygge inn fra start sammenlignet med å legge dem til i etterkant.
Vi i Weapp hjelper ofte kunder med å få frem akkurat disse kravene som en del av tjenestene våre, gjerne i en kort forstudie før utviklingen starter. Står dere foran et prosjekt der kravene må skjerpes? Ta kontakt, så drøfter vi hvilke ikke-funksjonelle krav som er verdt å spikre først.
Ofte stilte spørsmål
Hva er forskjellen på funksjonelle og ikke-funksjonelle krav?
Funksjonelle krav beskriver hva systemet skal gjøre: En bruker skal kunne logge inn, legge inn en ordre, lage en rapport. Ikke-funksjonelle krav beskriver hvor godt det skal skje: hvor raskt, hvor sikkert, for hvor mange samtidige brukere. Funksjonelle krav handler om funksjoner, ikke-funksjonelle om egenskaper. Begge trengs, men det er de sistnevnte som oftest glemmes.
Hvorfor blir manglende ikke-funksjonelle krav så dyre?
Fordi de påvirker hvordan hele systemet bygges, ikke bare én enkelt funksjon. Oppdager dere sent at systemet må tåle ti ganger flere brukere eller oppfylle et sikkerhetskrav, kan det kreve at grunnmuren bygges om. Et ytelseskrav som er kjent fra start, former arkitekturen billig; dukker det samme kravet opp etter lansering, kan det bety en ombygging.
Hvordan gjør man et ikke-funksjonelt krav målbart?
Ved å erstatte vage ord med tall og betingelser. «Systemet skal være raskt» kan ikke testes. «En sidelasting skal skje på under to sekunder for 95 prosent av forespørslene ved 500 samtidige brukere» kan måles og stilles som krav. Et målbart krav har et tall, en betingelse og en måte å verifisere det på. Ellers er det bare et håp.
Hvilke ikke-funksjonelle områder glemmes oftest?
Ytelse under last, sikkerhet, oppetid og hva som skjer når noe går galt. Også skalerbarhet, tilgjengelighet for personer med funksjonsnedsettelse (universell utforming) og hvor lett systemet er å forvalte, havner ofte utenfor kravene. De føles selvsagte og blir derfor aldri uttalt, helt til de mangler i det ferdige systemet og må bygges inn i etterkant.
Hvordan prioriterer man når alle krav føles viktige?
Ved å tvinge frem en forskjell i stedet for å føre opp alt som viktig. En enkel metode er å sortere kravene i må-, bør- og kan-krav og sette et tak for hvor mange som får være må-krav. Et annet grep er å spørre hva som skjer hvis kravet ikke oppfylles. Kan virksomheten leve med det, er det sjelden et må-krav.