Vikten av en bra kravspecifikation

Har du ett projekt som du önskar att genomföra som du länge har gått och tänkt på? Känner dig redo för att kontakta en utvecklare med hjälp att översätta dina idéer till en produkt? Stanna upp ett par minuter tänk efter, "har jag formulerat kraven på min produkt på ett bra sätt så att jag får det jag önskar levererat?".

En bra kravspecifikation är A och O om man önskar att driva igenom ett projekt så effektivt som möjligt, detta låter en potentiellt att spara stora summor pengar och kanske ännu viktigare: tid.

Vad är en kravspecifikation?

En kravspecifikation (eller "kravspec" kort kallat) låter kanske krångligt och tråkigt – och för en med många idéer som man snabbt vill genomföra är det kanske just det. Men specifikationen måste inte vara jättedetaljerad eller invecklad för att ändå vara värt arbetet att ta fram den.

Idén med kravspecifikationen är att låta både beställare och utvecklare förstå syfte och mål med projektet samt förhoppningsvis ge alla parter en idé om hur slutprodukten ska fungera och i vissa fall även hur den ska se ut.

Med en bra skriven specifikation kan man även enklare få in offerter från flera utvecklare för att enklare jämföra priser, utvecklingstider och annat som kan vara viktigt för att hålla en budget och deadline.

Vad ska en kravspecifikation innehålla?

Exakt hur en kravspecifikation ska se ut varierar beroende på vad det är för typ av projekt som ska drivas igenom, storleken, om beställningsmottagaren är extern part och en rad andra faktorer. Men de tre viktigaste punkterna för de flesta projekten är syfte, mål och krav.

Syfte och mål

Fråga dig själv vad syftet med projektet är; vad är det du vill uppnå? Vilket problem är det projektet ämnar att lösa?

Kanske skall en enkel e-postmodul tas fram som ska passas in i ett annat system, eller så är kanske målet något så ambitiöst som att ta fram en konkurrent till Facebook? Rimligtvis skiljer sig omfattningen på de båda kravspecifikationerna sig åt.

Målet låter en måla upp sin egna vision för den färdiga produkten som ska levereras. Detta ger ofta en snabb och direkt uppfattning om den potentiella storleken på projektet och om t.ex. en mindre utvecklare (som t.ex. mig...) faktiskt ens kan ta sig an arbetet.

Krav

Krav är både kanske den viktigaste och mest grundläggande punkten i en kravspecifikation. Kraven ger utvecklaren en snabb överblick över bl.a. funktionaliteten som kommer att behöva byggas för projektet. Det låter även beställaren konkret specificera vad produkten ska uppfylla. Kraven kan även definiera vilka tekniker som måste användas.

Åtminstone en kravlista bör alltid skickas med redan när man begär en offert, och särskilt när man lägger en beställning av t.ex. ett system. En del av listan kan vara så enkel som:

1.1) Användare skall kunna skapa en eget konto med en profil
1.2) Profilen skall innehålla: namn, e-postadress, bild
2.1) Användare skall kunna logga in till sitt konto
3.1) Användare skall kunna ändra och uppdatera sin profil

Detta ger utvecklaren en direkt idé om att t.ex. måste ett system tas fram för autentisering (inloggning), modeller för användare och profiler, samt att eventuellt måste ett system för att ladda upp profilbilder byggas.

Om man redan i planeringsfasen känner till tekniska krav bör även dessa tas med, t.ex:

1.1) Produktens layout och design skall bygga på Twitter Bootstrap 4.0
2.1) Produkten skall utvecklas i Laravel 5.5.

Vidare kan kraven delas upp i funktionella krav och icke-funktionella krav. Jag brukar kalla dem "skall"-krav och "bör"-krav, t.ex. skall en användarprofil finnas och den bör ladda på 0,5 sekunder eller snabbare.

Annat

Flera andra punkter kan sedan adderas till specifikationen efter behov; t.ex. beroenden, externa krav och kopplingar, detaljerade flöden m.m.

Helt enkelt; om du misstänker att en idé kan vara svår att förmedla på telefon, skriv ihop en liten text och addera gärna diagram och flödesscheman.

Exempel på ett (väldigt) enkelt flödesdiagram.

Vem ska skriva specifikationen?

Det är alltid beställaren i första hand som ska skapa och formulera kraven – detta för att säkerställa att det är beställarens standard och krav som efterföljs.

Dock så blir det mer ofta än sällan så att beställare och utvecklare tillsammans sedan förtydligar kraven och andra delar av specifikation för att se till så att båda parter är på samma "sida" med arbetet som faktiskt ska genomföras.

Jag brukar jobba som så att jag tar önskar en kravlista där jag sedan "renskriver" en kravspecifikation efter hur jag har tolkat att slutmålet med projektet ska vara, eventuellt med tillkommande krav. Därefter så går man igenom ett par feedback-loopar med kunden där man iterativt förtydligar och förbättrar samtliga delar i specifikationen.

Allt det här låter jobbigt!

Inte jobbigare än om det blir fel eller om budgeten spräcks – avkastningen på mödan som läggs ner på specifikationen kan vara otroligt stor.

Jag gillar analogin med ett husbygge. Givetvis kan man bygga ett hus utan ritningar, men detta kräver både mer tid och arbete från både beställaren och husbyggaren (utvecklaren) – ganska så snabbt inser man att ens visioner går isär och kanske väggar sätts upp som inte behövs, fel kakel läggs i badrummet och ytterdörren hamnar på fel sida huset – vilket medför extra merarbete och i sin tur givetvis extra kostnader och framflyttad inflyttning (lansering).

Med till och med den enklaste ritningen skulle en majoritet av allt detta merarbete kunna undvikas. Precis samma regler gäller för digitala projekt.

Inför ditt nästa projekt, pröva att skriva en så detaljerad kravspecifikation som möjligt och se skillnaden med att jobba efter en sådan!

Har du en färdig kravspecifikation och/eller funktionsbeskrivning och behöver en utvecklare för att förverkliga ditt projekt? Ta gärna kontakt med mig.