Kravställning är en metod som blivit vanlig inom agil utveckling, den form vi använder i alla utvecklingsprojekt på Odd Hill. Kravspecifikation är en term som har flera år på nacken och som i regel förknippas med traditionell projektmetodik enligt vattenfallsmodellen. En sådan skulle kunna ses som en önskelista över allt ifrån nödvändiga krav till saker som skulle kunna var bra att ha med. Den tar ingen självklar hänsyn till om det går att göra eller hur svårt det är.

Kravställningen på Odd Hill tar processen ett steg vidare. Vad är syftet med funktionen? Hur lång tid tar den att bygga? Finns det några problem med att att ha den med? Finns det rent av saker som saknas och behöver vara med?

Det är viktigt att kravställningen utgår från målgruppen. Riktar den sig till utvecklare kan den vara mer teknisk. Är den till redaktörer så behöver den inte vara det.

Först när kravställningen är klar kan de olika kraven tidsestimeras och beställaren kan prioritera utifrån kostnad och relevans. Det är ganska sällan budgeten räcker till att göra allt. Kravställningen möjliggör det för beställaren att göra kloka prioriteringar för att få maximalt ut av sin investering.

Kravställning på Odd Hill

Kravställning på Odd Hill är en process som syftar till att alla parter som är involverade i ett utvecklingsprojekt ska förstå vad som kommer att göras och levereras – hos beställaren såväl som Odd Hill. Ofta kan det även finnas tredjepartsaktörer som behöver ta del av hela eller delar av kravställningen.

För oss på Odd Hill är kravställningen ett agilt dokument. Det är inte hugget i sten, utan kan revideras och kompletteras även när utvecklingen kommit igång. Alla förändringar är välkomna som kan göra slutprodukten bättre, så länge de inte förändrar budget eller tidplan.

Vad, hur och varför?

Utöver vad som ska göras är det viktigt att reda ut hur det ska göras. Vad kommer att krävas, hur ser arbetsgången ut och vem är ansvarig? Det är lätt att glömma formulera varför, en detalj som ofta är viktig för att även de som inte är så väl insatta ska förstå. Varför man vill ha med en funktion kan vara självklart för beställaren, men inte utvecklaren som ska bygga den och vice versa.

User stories – kravställningens minsta beståndsdelar

En user story är ett format som används inom mjukvaruutveckling för att ge en enkel och lättförstådd beskrivning av en funktion, sedd ur användarens synvinkel. En typisk user story skulle kunna se ut så här:

“Som en redaktör ska jag kunna lägga till en nyhet så att besökarna kan ta del av vad som händer på företaget.”

På ett väldigt enkelt och lättförståeligt sätt har man besvarat flera viktiga frågor. Vad är det man ska kunna göra, vem ska göra det, vem berörs och varför? Alla som läser formuleringen har nu en god överblick över funktionen. Man kan se den som en slags sammanfattning eller rent utav en lång rubrik.

Acceptanskriterier specificerar en user story

I nyhetsexemplet ovan finns det flera punkter som behöver tydliggöras. Det finns ingen given standard för vad en en nyhetsfunktion exakt ska innefatta i detalj. Det kan vara stor skillnad mellan att ta fram en grundläggande eller en avancerad funktionalitet för hantering av nyheter på en webbplats. Detta behöver specificeras i ett antal punkter som kallas acceptanskriterier. Lite förenklat skulle ett par sådana ungefärligen kunna se ut så här:

• Det ska gå att lägga till en rubrik
• Brödtexten ska kunna formateras
• Man ska kunna lägga till en bild
• Det ska finnas en funktion för att dela nyheten på Facebook, Twitter och Linkedin
• Etc.

En viktig poäng med acceptanskriterierna är att de förtydligar vad som kommer att levereras. Redaktörerna vet vad de har att jobba med och utvecklarna förstår exakt vad som ska implementeras. Risken för förvirring och tysta antaganden minimeras.

Antaganden (assumptions) – nödvändiga genvägar

Under kravställningsprocessen försöker vi att arbeta bort alla antaganden. Vi tar reda på fakta och kontrollerar hur förutsättningarna ser ut. Vissa saker kan dock ta orimligt lång tid att ta reda på, varför vi ibland väljer man att ta reda på dem när vi börja utveckla. Ofta händer detta när det finns ett beroende till en tredje part. Skall vi exempelvis göra en integration mellan en webbapplikation och ett annat system kan vi välja att förutsätta att det finns ett väl dokumenterat API* som vi kan använda. Vi vet att det finns ett API, bara inte hur väldokumenterat det är.

*API = En samling av funktioner som gör det möjligt för ett system att hämta information och interagera med ett annat system.

Antagandet känns rimligt och vi gör den bedömningen tillsammans med beställaren. Det är dock viktigt att kravställningen är tydlig med att detta är ett antagande. Skulle det visa sig vara fel förändras förutsättningarna. Antingen kan integrationen ta längre tid att bygga eller behöva göras på ett annat sätt.

Det visuella ett viktigt komplement

Om all information i en kravställning ska formuleras i text kan den lätt bli orimligt lång och tung att läsa. Därför är det visuella en viktig del som alla kan relatera till. Den gör att texten inte behöver vara så detaljerad och blir lättare att ta till sig. Nyhetsfunktionen skulle kunna visas med wireframes (principskiss) med alla sina komponenter, istället för att allt skulle behöva spaltas upp i text.

Vanliga visuella komponenter i Odd Hills kravställningar är wireframes, klickbara prototyper och ofta även färdig design. Den sistnämnda används som regel när det handlar om befintliga lösningar där det redan finns en övergripande design på plats.

Kravställning en förutsättning för ett bra slutresultat

För oss på Odd Hill så är kravställningen en väldigt viktig del av utvecklingsprojektet, om inte den viktigaste. Den säkerställer att det finns en samsyn hos alla involverade om vad som ska göras och levereras. Risken för dolda antaganden eller missuppfattningar minimeras. Ju bättre kravställningen är desto bättre blir resultatet.

Tips!

Lyssna gärna på avsnittet om kravställningar i Odd Pod, vår podcast om allt inom webb: