Så skriver du en kravspecifikation för din app

Kravspecifikationen har ett enda jobb i offertskedet: få flera leverantörer att prissätta samma sak, utan att låsa fast en lösning som visar sig vara fel. De flesta specar misslyckas åt ena eller andra hållet — antingen så vaga att offerterna blir gissningar, eller så detaljstyrda att leverantörens kompetens aldrig kommer till nytta. Här är hur du hittar rätt nivå.

Strukturmallen: sex avsnitt som räcker långt

En kravspec för offertskedet behöver sällan vara mer än 5–15 sidor, strukturerad ungefär så här:

1. Syfte och mål. Vilket problem löser appen, för vem, och hur vet ni om den lyckas? Ett par mätbara mål (t.ex. andel ärenden som flyttar från telefon till app) styr tusen detaljbeslut senare.
2. Målgrupp och användningssituation. Vilka är användarna, hur ofta använder de appen, i vilken miljö? En app som används dagligen av fältpersonal med handskar ställer andra krav än en som öppnas i soffan en gång i månaden.
3. Användarflöden. Beskriv de 5–10 viktigaste sakerna en användare ska kunna göra, som flöden: “användaren fotograferar kvittot, väljer projekt, attesteraren notifieras”. Prioritera i måste/bör/kan — det är prioriteringen som gör offerter jämförbara och etapper möjliga.
4. Integrationer. Vilka system ska appen prata med — affärssystem, inloggning, betalning, kartor? Ange vad som finns idag (API:er? dokumentation?) för varje system. Integrationer är en av de största kostnadsdrivarna, och okända integrationer är den vanligaste källan till spräckta budgetar.
5. Icke-funktionella krav. Prestanda, säkerhet, GDPR, tillgänglighet, offline-stöd, språk, plattformar och versioner. Skriv bara krav ni menar allvar med — varje “appen ska fungera offline” kostar riktiga pengar.
6. Ramar och antaganden. Budgetspann, önskad tidplan, vem hos er som fattar beslut, vad som ska hända efter lansering (förvaltning, vidareutveckling).

Misstagen som gör offerter ojämförbara

När tre offerter på samma spec skiljer sig med en faktor tre är det oftast specen, inte leverantörerna, som är problemet. De vanligaste orsakerna:

• Funktioner utan prioritering. Om allt verkar lika viktigt prissätter en leverantör allt, en annan ett rimligt urval — och summorna blir omöjliga att jämföra.
• Osynliga integrationer. “Koppling till vårt affärssystem” utan uppgift om vilket system, vilken version och om API finns. En leverantör antar det enkla, en annan tar höjd för det svåra.
• Lösningskrav förklädda till behov. “Appen ska ha en chattfunktion” — eller är behovet att användare snabbt får svar? Kanske räcker FAQ plus notiser. Beskriv behovet, låt lösningen vara öppen.
• Odefinierade begrepp. “Enkel administration”, “hög säkerhet”, “snabb”. Sätt siffror eller exempel på allt som går: vad ska en administratör kunna göra, vilken data är känslig, hur snabbt är snabbt?
• Ingen uppgift om vad som finns. Befintlig design, grafisk profil, backend, konton? Det som redan finns ska inte prissättas igen.

Ett bra test: kan två personer läsa specen och rita ungefär samma app på whiteboard? Om inte — förtydliga flödena.

Rätt detaljnivå i rätt fas

Kravspecen är inte ett dokument som blir klart en gång; detaljnivån ska växa med projektet:

• Idéfas: en sida. Problem, målgrupp, affärsidé. Räcker för att testa idén mot kollegor och få grova prisindikationer.
• Offertfas: 5–15 sidor enligt mallen ovan. Tydliga flöden och ramar, öppen lösning. Det är här jämförbarheten avgörs.
• Uppstartsfas: specen bryts ner tillsammans med vald leverantör till en prioriterad backlog, skisser och tekniska beslut. Nu får detaljerna komma — med utvecklarnas och designernas kunskap i rummet.
• Under utveckling: kraven förfinas per etapp. Att detaljera flöde 8 innan flöde 1 är byggt är bortkastat — ni kommer lära er saker som ändrar planen.

Att skriva hela detaljspecen i förväg känns tryggt men bygger på illusionen att ni redan vet allt. De bästa projekten låser målbilden tidigt och detaljerna sent.

Kom igång

Börja med syfte, målgrupp och de fem viktigaste flödena — det är 80 procent av värdet. Vill du ha ett andra par ögon på din kravspec, eller hjälp att ta fram den genom en kort förstudie? Vi på Weapp gör det regelbundet åt beställare, från MVP:er till stora systemappar — hör av dig så tittar vi på den tillsammans.