Funktionella kontra icke-funktionella krav i praktiken
Funktionella krav beskriver vad systemet ska göra – funktioner och flöden. Icke-funktionella krav beskriver hur väl det ska göra det: prestanda, säkerhet, tillgänglighet och användbarhet. Det är oftast de icke-funktionella kraven som glöms bort och blir dyra överraskningar sent i projektet. Gör dem mätbara och prioritera dem hårt, för allt kan inte vara viktigast.
De flesta kravlistor är fulla av vad systemet ska göra och nästan tomma på hur väl det ska göra det. Just där, i det osagda, gömmer sig de dyraste överraskningarna. Ett system kan uppfylla varje funktionellt krav och ändå vara oanvändbart för att det är för långsamt, för otryggt eller faller ihop under last. Den här guiden reder ut skillnaden, visar hur du gör de bortglömda kraven mätbara och hur du prioriterar när allt känns lika viktigt.
Skillnaden i klartext
Funktionella krav beskriver systemets funktioner – vad en användare ska kunna göra. “Kunden ska kunna betala med kort”, “administratören ska kunna exportera en rapport”, “ordern ska skickas till lagret”. De är konkreta och lätta att komma på, eftersom de motsvarar det man föreställer sig när man tänker på systemet.
Icke-funktionella krav beskriver egenskaperna – hur väl funktionerna ska fungera. Hur snabbt betalningen ska gå, hur många som kan handla samtidigt, hur känsliga uppgifter skyddas, hur ofta systemet får vara nere. De syns inte i en funktionslista men avgör om systemet duger i verkligheten. Ett vanligt sätt att missförstå dem är att tro att de är “tekniska detaljer” utvecklarna löser ändå. I själva verket är de affärskrav: ett för långsamt system tappar kunder, ett otryggt system blir en risk.
En katalog över de bortglömda kravområdena
Just för att de icke-funktionella kraven känns självklara blir de ofta osagda. Här är de områden som oftast saknas, med exempel på hur en kravformulering kan se ut:
- Prestanda. “En sidladdning ska ske under 2 sekunder för 95 procent av anropen vid 500 samtidiga användare.”
- Skalbarhet. “Systemet ska klara en tiodubbling av antalet användare utan omarkitektur.”
- Tillgänglighet och drifttid. “Tjänsten ska vara tillgänglig 99,9 procent av tiden per månad, mätt utanför planerade fönster.”
- Säkerhet. “Alla personuppgifter ska krypteras i vila och under överföring, och åtkomst ska loggas.”
- Användbarhet. “En ny användare ska kunna slutföra en beställning utan instruktion.”
- Tillgänglighet för alla. “Gränssnittet ska uppfylla WCAG på nivå AA.”
- Förvaltningsbarhet. “Systemet ska vara dokumenterat så att en ny utvecklare kan sätta sig in i det på rimlig tid.”
Listan är inte komplett, men den fångar de områden vars frånvaro brukar bli dyrast. Att bara gå igenom den med sitt projekt avslöjar ofta krav som annars hade dykt upp först i drift.
Så gör du kraven mätbara och testbara
Ett icke-funktionellt krav som inte går att mäta är värdelöst, för ingen kan säga om det är uppfyllt. “Systemet ska vara snabbt och säkert” låter bra men betyder inget – det går inte att testa och därför inte att kräva.
Skillnaden ligger i att byta ut känslan mot ett tal, ett villkor och ett sätt att verifiera. “Snabbt” blir “under 2 sekunder vid 500 samtidiga användare”. “Säkert” blir konkreta krav på kryptering, behörighet och loggning. “Stabilt” blir en siffra på tillåten nertid. När kravet är formulerat så går det att bygga mot, att testa mot och att hålla leverantören ansvarig för. Ett bra test på ett krav är enkelt: kan två personer vara oense om huruvida det är uppfyllt? Då är det inte mätbart ännu.
Prioritera när allt känns viktigt
När kraven väl är nedskrivna uppstår nästa fälla: allt känns som ett måste. Men om allt är högsta prioritet finns ingen prioritering, och då styr slumpen eller den som ropar högst.
En beprövad metod är att sortera varje krav i måste, bör och kan – med ett medvetet tak för hur många som får vara måste. Det tvingar fram de verkliga avvägningarna. Ett kompletterande grepp är att för varje krav fråga: vad händer om det inte uppfylls? Kan verksamheten leva med följden är kravet sällan ett måste, hur önskvärt det än är.
| Prioritet | Innebörd |
|---|---|
| Måste | Systemet är oanvändbart eller olagligt utan det – taket hålls medvetet lågt |
| Bör | Ger tydligt värde men går att skjuta till en senare version |
| Kan | Trevligt om tid och budget räcker, men aldrig på bekostnad av ett måste |
Poängen är att prioriteringen sker på papperet, i lugn och ro, i stället för under press mitt i projektet när ett bortglömt krav plötsligt kolliderar med budgeten.
Ta kraven på allvar tidigt
Funktionella krav är lätta att komma på och blir sällan projektets fallgrop. Det är de icke-funktionella – prestanda, säkerhet, drift, förvaltning – som avgör om systemet håller i verkligheten, och de kostar en bråkdel att bygga in från start jämfört med att lägga till i efterhand.
Vi på Weapp hjälper ofta beställare att få fram just den kravbilden som en del av våra tjänster, gärna i en kort förstudie innan bygget börjar. Står ni inför ett projekt där kraven behöver skärpas? Hör av dig så resonerar vi kring vilka icke-funktionella krav som är värda att nagla fast först.
Vanliga frågor
Vad är skillnaden mellan funktionella och icke-funktionella krav?
Funktionella krav beskriver vad systemet ska göra: en användare ska kunna logga in, lägga en order, skapa en rapport. Icke-funktionella krav beskriver hur väl det ska ske: hur snabbt, hur säkert, för hur många samtidiga användare. Funktionella krav handlar om funktioner, icke-funktionella om egenskaper. Båda behövs, men det är de senare som oftast glöms.
Varför blir uteblivna icke-funktionella krav så dyra?
För att de påverkar hur hela systemet byggs, inte bara en enskild funktion. Upptäcker ni sent att systemet måste tåla tio gånger fler användare, eller uppfylla ett säkerhetskrav, kan det kräva att grunden görs om. Ett prestandakrav som är känt från start formar arkitekturen billigt; samma krav som dyker upp efter lansering kan bli en ombyggnad.
Hur gör man ett icke-funktionellt krav mätbart?
Genom att ersätta vaga ord med siffror och villkor. 'Systemet ska vara snabbt' går inte att testa. 'En sidladdning ska ske under två sekunder för 95 procent av anropen vid 500 samtidiga användare' går att mäta och kravställa. Ett mätbart krav har ett tal, ett villkor och ett sätt att verifiera det – annars är det bara en förhoppning.
Vilka icke-funktionella områden glöms oftast bort?
Prestanda under last, säkerhet, tillgänglighet och drifttid, samt vad som händer när något går fel. Också skalbarhet, tillgänglighet för personer med funktionsnedsättning och hur lätt systemet är att förvalta hamnar ofta utanför kravbilden. De känns självklara och blir därför osagda, tills de saknas i det färdiga systemet och måste byggas in i efterhand.
Hur prioriterar man när alla krav känns viktiga?
Genom att tvinga fram en skillnad i stället för att lista allt som viktigt. En enkel metod är att sortera kraven i måste, bör och kan – och sätta ett tak för hur många som får vara måste. Ett annat grepp är att fråga vad som händer om kravet inte uppfylls. Kan verksamheten leva med det är det sällan ett måste.