Vad är icke-funktionella krav?

Det här är ett utdrag ur boken Kvalitetstårtan

Detta utdrag förklarar den grundläggande skillnaden mellan funktionella och icke-funktionella krav, och varför det ofta är i den icke-funktionella-dimensionen som IT-projekt misslyckas.

Varje IT-system börjar med en vision. Någon ser ett problem som behöver lösas eller en möjlighet som kan realiseras. ”Vi behöver kunna hantera våra kundärenden digitalt” eller ”Våra säljare måste kunna komma åt produktinformation i fält.”

Det är naturligt att vi först fokuserar på vad systemet ska göra, vilka funktioner det ska ha. Vi listar kraven: skapa ärenden, söka i produktdatabasen, generera rapporter. Vi ritar skisser på gränssnitt och diskuterar arbetsflöden. Allt detta är viktigt och nödvändigt.

I en typisk kravspecifikation tenderar funktionella krav att dominera både i antal och fokus. Men för att lyckas behöver vi förstå att varje system har två huvudtyper av krav:

Funktionella krav beskriver VAD systemet ska göra:

    • Registrera nya ärenden

    • Tilldela handläggare

    • Spåra status

    • Generera rapporter

Icke-funktionella krav beskriver HUR systemet ska fungera:

    • Hur snabbt det ska svara

    • Hur säkert det ska vara

    • Hur många användare det ska klara samtidigt

    • Hur det ska fungera när saker går fel

Det är i detta HUR som många IT-projekt misslyckas. Ett system kan uppfylla alla funktionella krav men ändå vara i praktiken oanvändbart om det är för långsamt, osäkert eller svårt att underhålla.

Ett konkret exempel

Låt oss ta exemplet ”skapa ärenden”:

VAD (funktionellt): Systemet ska kunna registrera kundärenden

HUR (icke-funktionellt):

    • Användbarhet: Nyanställda ska kunna registrera sitt första ärende utan utbildning

    • Drift: Klara upp till 1000 samtidiga användare under kontorstid med bibehållen prestanda

    • Livscykelhantering: Nya fält ska kunna läggas till utan kodändring

    • Säkerhet: Tvåfaktorsautentisering för alla användare

    • Regulatoriska krav: Uppfylla GDPR:s krav på dataradering

    • Testbarhet: Alla affärsregler ska kunna testas isolerat

Det är denna HUR-dimension vi utforskar i boken. För det är här, i de icke-funktionella kraven, som skillnaden mellan framgång och misslyckande ofta avgörs.

Kvalitetsområden och kvalitetsaspekter

För att systematiskt kunna arbeta med HUR-dimensionen delar vi upp de icke-funktionella kraven i sex kvalitetsområden: användbarhet, drift, livscykelhantering, säkerhet, regulatoriska krav och testbarhet. Dessa sex områden utgör tillsammans det vi kallar kvalitetstårtan, en modell som presenteras i detalj i del 2.

Varje kvalitetsområde innehåller i sin tur flera kvalitetsaspekter. Användbarhet omfattar till exempel aspekter som lärbarhet, flexibilitet och tillgänglighet. Drift omfattar aspekter som prestanda, tillgänglighet (i betydelsen systemet går att nå) och robusthet. Denna hierarki, från övergripande kvalitetsområde ner till specifik kvalitetsaspekt, ger oss ett strukturerat sätt att säkerställa att vi inte missar viktiga krav.

De osynliga kraven

Icke-funktionella krav är ofta osynliga. De handlar om kvalitetsaspekter som prestanda, integration, användbarhet och effektivitet. Icke-funktionella krav har flera egenskaper som gör dem särskilt svåra att fånga:

De artikuleras sällan. Användare säger ”jag vill kunna registrera patientdata” men säger sällan ”och det ska gå på under 30 sekunder även när jag har bråttom mellan patienter” eller ”information jag registrerar i ett system ska finnas tillgänglig i andra system som behöver den”.

De tas för givna. Både beställare och utvecklare antar ofta att vissa saker är ”självklara”. Men det som är självklart för en part är ofta osynligt för en annan.

De är svåra att mäta. Det är lätt att verifiera om en funktion finns eller inte. Det är svårare att definiera och mäta ”användarvänlighet” eller ”underhållbarhet”.

De syns först i verkligheten. På ritbordet ser allt bra ut. Det är först när hundra stressade läkare använder systemet dagligen som bristerna blir uppenbara.

Utmaningen med vaga formuleringar

Ett stort problem med icke-funktionella krav är att de ofta formuleras vagt:

    • Systemet ska vara ”snabbt”

    • Systemet ska ha ett ”modernt användargränssnitt”

    • Systemet ska ha ”hög säkerhet”

Men vad är ”snabbt”? För någon kan det innebära att en sida laddas på under 2 sekunder, medan det för någon annan innebär millisekunders svarstid. Att översätta kvalitativa krav till mätbara mål är en av de största utmaningarna i kravarbetet.

När icke-funktionella krav missas

När icke-funktionella krav missas eller nedprioriteras kan konsekvenserna bli allvarliga:

    • E-handlare vars system är så långsamma att kunderna väljer andra

    • Säkerhetsluckor som upptäcks först efter att intrång gjorts och data läckt

    • Underhållskostnader som skenar för att systemet är svårt att uppdatera

    • Användare som gör fel för att gränssnittet är otydligt

Balanserad helhetssyn

Ett system är en helhet och dess kvalitet beror på balansen mellan olika krav. Problem uppstår när vi fokuserar för mycket på en aspekt:

    • Överdriven säkerhet kan göra systemet omöjligt att använda

    • Ensidigt fokus på prestanda kan kompromissa bort säkerhet och tillförlitlighet

    • För stort fokus på mätetal kan leda till suboptimering

För att undvika dessa fallgropar måste vi ha en helhetssyn på vad vi bygger. Det handlar om att förstå vilka kvaliteter som är viktigast för verksamheten och hur de olika kraven påverkar varandra.

Det här var ett utdrag till min bok Kvalitetstårtan som du kan läsa mer om på den här sajten. Här kan du även ladda ner checklistorna jag nämner här.