Funktionelle og ikke-funktionelle krav i praksis
Funktionelle krav beskriver hvad systemet skal gøre: funktioner og flows. Ikke-funktionelle krav beskriver hvor godt det skal gøre det: ydeevne, sikkerhed, oppetid og brugervenlighed. Det er som regel de ikke-funktionelle krav der bliver glemt og ender som dyre overraskelser sent i projektet. Gør dem målbare og prioritér dem hårdt, for alt kan ikke være vigtigst.
De fleste kravlister er fulde af hvad systemet skal gøre og næsten tomme for hvor godt det skal gøre det. Netop dér, i det usagte, gemmer de dyreste overraskelser sig. Et system kan opfylde hvert eneste funktionelle krav og alligevel være ubrugeligt fordi det er for langsomt eller for usikkert, eller fordi det bryder sammen under belastning. Denne guide forklarer forskellen, viser hvordan du gør de glemte krav målbare, og hvordan du prioriterer når alt føles lige vigtigt.
Forskellen i klartekst
Funktionelle krav beskriver systemets funktioner: hvad en bruger skal kunne gøre. “Kunden skal kunne betale med kort”, “administratoren skal kunne eksportere en rapport”, “ordren skal sendes til lageret”. De er konkrete og lette at komme i tanke om fordi de svarer til det man forestiller sig når man tænker på systemet.
Ikke-funktionelle krav beskriver egenskaberne: hvor godt funktionerne skal fungere. Hvor hurtigt betalingen skal gå, hvor mange der kan handle samtidig, hvordan følsomme oplysninger beskyttes, hvor ofte systemet må være nede. De kan ikke ses i en funktionsliste, men afgør om systemet duer i virkeligheden. En almindelig misforståelse er at tro at de er “tekniske detaljer” som udviklerne alligevel løser. I virkeligheden er de forretningskrav: Et for langsomt system mister kunder, et usikkert system bliver en risiko.
Et katalog over de glemte kravområder
Netop fordi de ikke-funktionelle krav føles selvfølgelige, bliver de ofte ikke sagt højt. Her er de områder der oftest mangler, med eksempler på hvordan en kravformulering kan se ud:
- Ydeevne. “En sideindlæsning skal ske på under 2 sekunder for 95 procent af kaldene ved 500 samtidige brugere.”
- Skalerbarhed. “Systemet skal kunne klare en tidobling af antallet af brugere uden en ny arkitektur.”
- Oppetid og driftstid. “Tjenesten skal være tilgængelig 99,9 procent af tiden per måned, målt uden for planlagte servicevinduer.”
- Sikkerhed. “Alle personoplysninger skal krypteres i hvile og under overførsel, og adgang skal logges.”
- Brugervenlighed. “En ny bruger skal kunne gennemføre en bestilling uden vejledning.”
- Tilgængelighed for alle. “Brugerfladen skal opfylde WCAG på niveau AA.”
- Vedligeholdbarhed. “Systemet skal være dokumenteret så en ny udvikler kan sætte sig ind i det på rimelig tid.”
Listen er ikke udtømmende, men den fanger de områder hvis fravær plejer at blive dyrest. Bare det at gennemgå den med sit projekt afslører ofte krav som ellers først ville være dukket op i drift.
Sådan gør du kravene målbare og testbare
Et ikke-funktionelt krav der ikke kan måles, er værdiløst, for ingen kan sige om det er opfyldt. “Systemet skal være hurtigt og sikkert” lyder godt, men betyder ingenting. Det kan ikke testes og derfor heller ikke stilles som krav.
Forskellen ligger i at udskifte fornemmelsen med et tal, en betingelse og en måde at verificere på. “Hurtigt” bliver “under 2 sekunder ved 500 samtidige brugere”. “Sikkert” bliver konkrete krav til kryptering, adgangsstyring og logning. “Stabilt” bliver et tal for tilladt nedetid. Når kravet er formuleret sådan, kan man bygge efter det, teste mod det og holde leverandøren ansvarlig for det. En god test af et krav er enkel: Kan to personer være uenige om hvorvidt det er opfyldt? Hvis ja, er det ikke målbart endnu.
Prioritér når alt føles vigtigt
Når kravene først er skrevet ned, opstår den næste fælde: Alt føles som et skal. Men hvis alt har højeste prioritet, er der ingen prioritering, og så er det tilfældet eller den der råber højest, der styrer.
En afprøvet metode er at sortere hvert krav i skal, bør og kan, med et bevidst loft over hvor mange der må være skal. Det fremtvinger de reelle afvejninger. Et supplerende greb er for hvert krav at spørge: Hvad sker der hvis det ikke bliver opfyldt? Kan forretningen leve med følgen, er kravet sjældent et skal, hvor ønskeligt det end er.
| Prioritet | Betydning |
|---|---|
| Skal | Systemet er ubrugeligt eller ulovligt uden det: Loftet holdes bevidst lavt |
| Bør | Giver tydelig værdi, men kan skubbes til en senere version |
| Kan | Rart hvis tid og budget rækker, men aldrig på bekostning af et skal |
Pointen er at prioriteringen sker på papiret, i ro og mag, i stedet for under pres midt i projektet når et glemt krav pludselig kolliderer med budgettet.
Tag kravene alvorligt tidligt
Funktionelle krav er lette at komme i tanke om og bliver sjældent projektets faldgrube. Det er de ikke-funktionelle (ydeevne, sikkerhed, drift, vedligeholdelse) der afgør om systemet holder i virkeligheden, og de koster en brøkdel at bygge ind fra starten sammenlignet med at tilføje dem bagefter.
Hos Weapp hjælper vi ofte kunder med at få netop de krav frem som en del af vores ydelser, gerne i et kort forprojekt før udviklingen går i gang. Står I over for et projekt hvor kravene skal skærpes? Kontakt os, så drøfter vi hvilke ikke-funktionelle krav der er værd at slå fast først.
Ofte stillede spørgsmål
Hvad er forskellen på funktionelle og ikke-funktionelle krav?
Funktionelle krav beskriver hvad systemet skal gøre: En bruger skal kunne logge ind, afgive en ordre, oprette en rapport. Ikke-funktionelle krav beskriver hvor godt det skal ske: hvor hurtigt, hvor sikkert, for hvor mange samtidige brugere. Funktionelle krav handler om funktioner, ikke-funktionelle om egenskaber. Begge er nødvendige, men det er de sidste der oftest bliver glemt.
Hvorfor bliver manglende ikke-funktionelle krav så dyre?
Fordi de påvirker hvordan hele systemet bygges, ikke kun en enkelt funktion. Opdager I sent at systemet skal kunne klare ti gange flere brugere eller opfylde et sikkerhedskrav, kan det kræve at fundamentet laves om. Et ydeevnekrav der er kendt fra starten, former arkitekturen billigt. Dukker det samme krav først op efter lanceringen, kan det blive til en ombygning.
Hvordan gør man et ikke-funktionelt krav målbart?
Ved at erstatte vage ord med tal og betingelser. 'Systemet skal være hurtigt' kan ikke testes. 'En sideindlæsning skal ske på under to sekunder for 95 procent af kaldene ved 500 samtidige brugere' kan måles og stilles som krav. Et målbart krav har et tal, en betingelse og en måde at verificere det på. Ellers er det bare et håb.
Hvilke ikke-funktionelle områder bliver oftest glemt?
Ydeevne under belastning, sikkerhed, oppetid og driftstid samt hvad der sker når noget går galt. Også skalerbarhed, tilgængelighed for personer med handicap og hvor let systemet er at vedligeholde, ender ofte uden for kravspecifikationen. De føles selvfølgelige og bliver derfor ikke sagt højt indtil de mangler i det færdige system og skal bygges ind bagefter.
Hvordan prioriterer man når alle krav føles vigtige?
Ved at fremtvinge en forskel i stedet for at liste alt som vigtigt. En enkel metode er at sortere kravene i skal, bør og kan og sætte et loft over hvor mange der må være skal. Et andet greb er at spørge hvad der sker hvis kravet ikke bliver opfyldt. Kan forretningen leve med det, er det sjældent et skal.