Kravspecifikation för app – mall i sju delar

Varför kravspecifikationen avgör priset

Den vanligaste orsaken till att ett appprojekt blir dyrare än planerat är inte tekniken utan otydliga krav. "En app där kunder kan boka" kan betyda allt från en enkel lista med lediga tider till ett system med betalning, avbokningsregler, påminnelser och en adminpanel för personalen. Skillnaden i pris kan vara flera hundra tusen kronor.

En kravspecifikation tvingar fram besluten innan någon skriver kod. Den gör offerter jämförbara, minskar antalet ändringar under projektet och blir ett underlag som båda parter kan peka på när något är oklart. Har ni ännu inte formulerat idén alls kan ni börja med vår checklista från idé till app och sedan använda mallen nedan.

Mallen: sju delar

1. Mål

Skriv ett till tre mätbara mål. Inte "öka digitaliseringen" utan till exempel "minska antalet telefonsamtal om bokningar med hälften inom sex månader" eller "låta fältpersonalen rapportera utan pappersblanketter". Målen hjälper utvecklaren att föreslå enklare lösningar som ger samma effekt.

2. Målgrupp

Beskriv de olika användartyperna: kund, personal, administratör. Ange om de främst har iPhone eller Android, om de använder appen ute i fält med dålig täckning, och om de är vana användare eller ska klara appen utan instruktioner. Det påverkar val av plattform, offline-stöd och design.

3. User stories

En user story följer formatet "Som [roll] vill jag [göra något] så att [nytta]". Exempel för en bokningsapp:

• Som kund vill jag se lediga tider för en viss behandling så att jag kan boka utan att ringa.
• Som kund vill jag få en påminnelse dagen innan så att jag inte glömmer tiden.
• Som personal vill jag blockera tider när jag är sjuk så att inga nya bokningar hamnar där.
• Som administratör vill jag exportera bokningar per månad så att jag kan fakturera.

Skriv hellre fler korta stories än få långa. Varje story ska gå att testa: antingen fungerar den eller inte.

4. Funktioner enligt MoSCoW

MoSCoW delar in funktionerna i fyra grupper: Must (måste finnas vid lansering), Should (viktigt men appen fungerar utan), Could (trevligt att ha) och Won't (medvetet bortvalt i den här versionen). Gruppen Won't är minst lika viktig som Must – den visar vad som inte ingår i priset.

En tumregel är att Must ska rymmas i ungefär hälften av budgeten. Då finns marginal för det som dyker upp under projektet. Ett smalt Must är också grunden för en MVP-app.

5. Integrationer

Lista varje externt system och vad som ska flöda åt vilket håll. Exempel: inloggning med BankID, betalning med Swish eller kort, kunddata från affärssystemet, fakturor till Fortnox, push-notiser. Ange om systemet har ett API och om ni har dokumentation. Integrationer är ofta den största osäkerheten i en offert.

6. Icke-funktionella krav

Här beskriver ni hur appen ska fungera snarare än vad den gör:

• Vilka iOS- och Android-versioner som ska stödjas.
• Om appen ska fungera offline och synka senare.
• Krav på inloggning, behörigheter och lagring av personuppgifter (se GDPR i appar).
• Tillgänglighet, till exempel stöd för större textstorlek och skärmläsare.
• Förväntat antal användare och om data ska lagras inom EU.

7. Budget och tidsram

Att ange en budget känns ibland som att visa korten, men det hjälper utvecklaren att föreslå rätt nivå. Ett spann räcker. Ange också fasta datum, till exempel en mässa eller säsongsstart. Använd gärna priskalkylatorn för att få en första uppfattning.

Vanliga misstag i kravspecifikationer

• Lösningar i stället för behov. "Vi vill ha en meny med sex knappar" låser designen. Beskriv vad användaren ska uppnå.
• Allt är Must. Om allt är lika viktigt går det inte att prioritera när tiden eller pengarna tar slut.
• Adminsidan glöms bort. Någon ska lägga in innehåll, hantera användare och svara på frågor. Det kräver ofta en egen adminpanel.
• Ingen tanke på drift. Vem uppdaterar appen när Apple och Google släpper nya versioner? Planera för underhåll från början.
• För detaljerat för tidigt. Exakta färger och texter kan vänta till designfasen.

Räkneexempel: Must-listan för en enkel bokningsapp

Exempel (hypotetiskt): en salong med tre anställda vill låta kunderna boka i en app. Efter prioriteringen kan listan se ut så här:

Med en sådan lista blir det tydligt vad första versionen kostar, och vad som kan läggas till senare utan att något behöver byggas om.

Så går en förstudie till hos oss

Om ni inte vill skriva specifikationen själva gör vi den tillsammans med er i en förstudie:

1. Uppstartsmöte (video eller på plats i Stockholmsområdet) där vi går igenom mål, målgrupp och idéer.
2. Workshop om user stories där vi listar vad varje användartyp ska kunna göra.
3. Prioritering enligt MoSCoW och genomgång av integrationer.
4. Skisser av de viktigaste vyerna så att alla ser samma app framför sig.
5. Leverans av kravspecifikation, tidsplan och fast pris för utvecklingen.

Förstudien kostar 9 900 kr exkl. moms, tar 1–2 veckor och avräknas mot utvecklingen om ni går vidare. Specifikationen är er – ni kan använda den för att ta in offerter från andra också.

Ingår och ingår inte