Sammanfattning

Vad en lösning ska göra – och hur den ska fungera – är två helt olika saker. I detta avsnitt reder vi ut skillnaden mellan funktionella och icke-funktionella krav, och varför det är avgörande att hålla isär dem. Vi visar hur tydliga krav sparar tid, undviker missförstånd och skapar lösningar som både fungerar och upplevs rätt i verkligheten.

Transkript

Välkommen tillbaka till Prime Arch-podden. Jag heter Patrik Hallén, och idag ska vi prata om något som låter självklart, men som väldigt ofta blir en källa till missförstånd – nämligen funktionella och icke-funktionella krav. Det här är en sådan sak som låter torrt, men som i praktiken kan göra skillnaden mellan ett lyckat projekt och ett projekt som havererar. För det handlar egentligen om en enda viktig sak – att skilja på vad en lösning ska göra, och hur den ska göra det. Och om man inte håller isär de två perspektiven, så blir det lätt rörigt både i modeller, i kravdokument och i diskussionerna mellan verksamhet och IT.

Men Patrik, är inte allt bara krav? Varför måste vi dela upp det i funktionella och icke-funktionella?

Jättebra fråga. Och det är precis den här missuppfattningen som ofta ställer till problem. Låt mig förklara skillnaden. Funktionella krav handlar om vad en lösning ska göra. Alltså vilka funktioner som måste finnas. Till exempel: “Systemet ska kunna ta emot en ansökan.” Eller: “Processen ska skicka en bekräftelse till kunden.” Det är saker som direkt beskriver verksamhetens behov eller steg i en process. Icke-funktionella krav, däremot, handlar om hur lösningen ska fungera. Till exempel: “Systemet ska kunna hantera 10 000 användare samtidigt.” Eller: “Svaret till kunden ska komma inom två sekunder.” Det är krav på prestanda, tillgänglighet, användarvänlighet, säkerhet eller andra egenskaper som inte är vad vi gör – utan hur vi gör det.

 

Jag brukar ta exemplet med en röd knapp. För Anna, som är verksamhetsutvecklare i offentlig sektor, kan ett funktionellt krav vara: “Det ska finnas en knapp för att avsluta ett ärende.” Det är vad som ska hända. Ett icke-funktionellt krav kan däremot vara: “Knappen ska vara röd, synlig på alla skärmar och det ska inte ta mer än en halv sekund att få bekräftelse när man trycker på den.” Det är hur funktionen ska fungera eller upplevas. För Johan, som är konsult, är det här avgörande. Han behöver kunna skilja på vad kunden vill uppnå, och vilka tekniska krav som måste till för att lösningen ska hålla i praktiken. Erik, som arbetar som verksamhetsarkitekt, använder ofta just denna uppdelning för att kunna spåra krav i modeller och förstå vilken typ av förändring som är på gång. Och Lena, som leder ett EA-team, behöver se till att hennes team inte drunknar i tekniska detaljer när de egentligen borde prata om verksamhetens behov.

Men Patrik, måste man verkligen skriva ner alla icke-funktionella krav? Är det inte självklart att saker ska gå snabbt eller vara säkra?

Väldigt bra fråga. Och det är precis där många projekt går fel. För vi tror att vissa saker är självklara – tills de inte är det. Tänk dig att du bygger en ny tjänst där folk ska boka tider online. Visst låter det självklart att sidan ska laddas snabbt. Men om du inte skrivit ner det som ett icke-funktionellt krav, kan det hända att någon bygger systemet så att det tar femton sekunder att visa kalendern. Tekniskt funkar allt – men användarna är missnöjda. I Prime Ark är vi därför väldigt noga med att dokumentera både funktionella och icke-funktionella krav. Och inte bara för system – utan även när vi modellerar processer och informationsflöden. För Anna handlar det om att krav inte ska missförstås när de lämnas över till IT. För Johan handlar det om att kunna sätta rätt förväntningar hos kunden. För Erik är det avgörande för att hålla isär vilka objekt som påverkas. Och för Lena handlar det om att teamet ska kunna planera sitt arbete rätt – utan att fastna i tekniska diskussioner när det egentligen är verksamhetens behov som ska stå i centrum.

I nästa avsnitt ska vi prata om något som är otroligt viktigt i Prime Arch – nämligen hierarkisk och värdebaserad komposition. Vi kommer prata om skillnaden mellan att bygga strukturer som är som IKEA-lådor, eller som en picknickkorg – och varför båda synsätten behövs. Tack för att du har lyssnat idag. Jag hoppas du fått en tydligare bild av varför det är så viktigt att skilja på vad vi vill göra och hur vi vill att det ska fungera. Välkommen tillbaka till Prime Arch-podden.

Länkar

🎧 Lyssna på Spotify
📱 Öppna i Prime Arch-appen

Den röda knappen