Så skriver du en kravspecifikation för ett nytt system

Någon har sagt åt dig att skriva en kravspecifikation innan du skaffar ett nytt system, och nu undrar du var du ska börja. En bra kravspecifikation beskriver problemet, flödet och vad som måste fungera från dag ett, inte hur systemet ska byggas. För ett litet företag ryms den oftast på två till fyra sidor.

Jag bygger system åt små företag, så jag läser kravspecar från andra hållet, som den som ska sätta ett pris. På den här sidan får du veta vad som behöver stå med, en mall du kan kopiera och ett ifyllt exempel.

Vad är en kravspecifikation?

En kravspecifikation är ett dokument som beskriver vad ett system ska klara, för vem och varför, så att en leverantör kan förstå uppdraget och sätta ett pris. På engelska heter det requirements specification. I vardagen säger de flesta bara kravspec.

Det viktiga ordet är vad. Kravspecen säger vad som ska fungera, och hur det ska byggas är leverantörens sak att föreslå. Det är också där du kan jämföra olika svar mot varandra.

Behöver du ens en kravspec?

För ett litet system räcker det oftast med ett bra samtal och en sammanfattning på en sida. Går problemet att förklara på tio minuter blir en lång kravspec mest något som står i vägen innan du kommer igång.

En kravspecifikation för ett it-system i en kommun eller en koncern blir ofta tjock, eftersom många ska tycka till. För ett företag med fem eller femtio anställda behövs sällan det. En längre kravspec brukar ändå löna sig när det här stämmer:

• Du ska jämföra flera leverantörer. Alla behöver svara på samma fråga, annars går svaren inte att ställa mot varandra.
• Många ska använda systemet. Fler roller ger fler behov, och det är lätt att glömma någon.
• Systemet ska kopplas till andra system. Fortnox, webbshopen eller CRM:et behöver stå med från början.
• Budgeten är fast. Då vill du veta vad som ryms innan någon börjar bygga.

Det här ska finnas med i en kravspecifikation

En kravspecifikation för ett nytt system behöver åtta delar, och var och en kan vara några rader. Skriv som du skulle säga det till en ny kollega.

• Bakgrund och problem. Hur gör ni i dag, vad fungerar inte och vad kostar det i tid?
• Vilka som använder systemet. Roller, inte namn. Säljare, lager, ekonomi, och kanske kunderna själva via en kundportal där de ser sina egna order.
• Flödet steg för steg. Från att något kommer in till att det är klart. Vem gör vad, och i vilken ordning?
• Måste-krav och bra att ha. Det som måste fungera från dag ett, och det som kan vänta till nästa version.
• Kopplingar till andra system. Ska ordern bli en faktura i Fortnox? Ska kunderna hämtas från webbshopen eller CRM:et?
• Data som ska flyttas med. Kundregister, artiklar och gamla order. Var finns de i dag, och i vilket skick?
• Behörigheter. Vem får se vad, och vem får ändra?
• Budget och tidsram. Ett ungefärligt spann och när det behöver vara klart. Det hjälper leverantören att föreslå rätt nivå från början.

Kopplingarna är den del som oftast glöms bort, och den som oftast flyttar priset. Hur system pratar med varandra har jag skrivit om på sidan om systemintegration.

Kravspecifikation mall att kopiera

Här är en kravspecifikation mall som du kan kopiera rakt av. Fyll i den med egna ord, punktform går bra, och räkna med ungefär en timme. Den fungerar som mall för systemutveckling i de flesta mindre projekt, vare sig det gäller ett ordersystem eller ett ärendesystem.

KRAVSPECIFIKATION: [systemets namn eller arbetsnamn]
Företag: [namn]    Kontaktperson: [namn]    Datum: [datum]

1. Bakgrund och problem
   Hur gör ni i dag?
   Vad fungerar inte, och vad kostar det i tid eller pengar?

2. Vilka använder systemet?
   Roll:              Antal:   Vad de gör i systemet:
   [t.ex. säljare]    [3]      [lägger in order]

3. Flödet steg för steg
   1. [Vad startar flödet? Ett mejl, ett samtal, en order?]
   2. [Vem tar hand om det, och vad gör hen?]
   3. [Nästa steg ...]
   Klart när: [vad betyder klart för er?]

4. Krav
   Måste fungera från dag ett:
   - [...]
   Bra att ha, kan vänta:
   - [...]

5. Kopplingar till andra system
   [Fortnox, webbshop, CRM, mejl. Vad ska skickas åt vilket håll?]

6. Data som ska flyttas med
   [Vad, var finns det i dag och ungefär hur mycket?]

7. Behörigheter
   [Vem får se vad? Vem får ändra?]

8. Budget och tidsram
   Ungefärlig budget: [spann]
   Behöver vara klart: [datum, eller "inget bråttom"]
   Det här är viktigast för oss: [en mening]

När du är klar kan du testa den på ett enkelt sätt. Skulle en ny person på jobbet förstå hur ni arbetar efter att ha läst den? Gör hen det, så räcker den som kravspecifikation för ett projekt i den här storleken.

Kravspecifikation exempel: från Excel till eget ordersystem

Det här är ett påhittat exempel, inte en riktig kund. Företaget är en grossist med tolv anställda som tar emot order via mejl och telefon och för in dem i ett delat Excelark. Så här kan deras kravspec se ut, ifylld i mallen ovan.

1. Bakgrund och problem. Vi tar emot order via mejl och telefon och för in dem i ett delat Excelark. Bara en person kan redigera åt gången, och ibland missas en order när två svarar på samma mejl. Varje fredag lägger ekonomi en halv dag på att skriva över order till fakturor i Fortnox.

2. Vilka använder systemet? Fyra säljare som lägger in order. Två på lagret som plockar och skickar. En på ekonomi som fakturerar.

3. Flödet. Ordern kommer in och säljaren lägger in den. Lagret ser den i en lista, plockar och markerar den som skickad. Då skapas en faktura i Fortnox. Klart när fakturan är skickad.

4. Krav. Måste: alla kan jobba samtidigt, lagret ser nya order direkt och fakturan skapas i Fortnox utan att någon skriver av den. Bra att ha: kunderna kan själva se var deras order är.

5. Kopplingar. Kunder och artiklar hämtas från Fortnox. Fakturor skickas dit.

6. Data. Ungefär 400 kunder och 1 200 artiklar finns redan i Fortnox. Gamla order i Excel behöver inte flyttas.

7. Behörigheter. Säljare och lager ser alla order. Bara ekonomi kan ändra priser.

8. Budget och tidsram. Vi har tänkt oss mellan 100 000 och 150 000 kr. Klart före årsskiftet. Viktigast för oss är att fakturorna slutar skrivas för hand.

Det är allt, och det ryms på en sida. Lägg märke till vad som inte står med. Det finns inga skisser på skärmar och inga val av teknik, men flödet, kopplingen och det viktigaste kravet är tydliga. Det räcker för att jag ska kunna ställa rätt frågor och ge ett fast pris.

Vanliga misstag i en kravspec

De flesta misstag i en kravspec handlar om att den säger för mycket om lösningen och för lite om hur ni jobbar. Det här ser jag oftast:

• Du beskriver skärmar i stället för problemet. En skiss på en knapp säger mindre än en mening om varför knappen behövs. Ofta finns det ett enklare sätt att lösa samma sak.
• Allt är måste-krav. Då går det inte att se vad som är viktigast, och priset blir högre än det behöver vara. Fråga dig om ni skulle klara första månaden utan det.
• Du glömmer hur ni gör i dag. Sånt som någon gör av vana, som att ringa kunden innan leverans, står sällan nedskrivet. Fråga de som gör jobbet.
• Kopplingarna saknas. Att ordern ska bli en faktura i Fortnox känns självklart för dig, men det är ofta en stor del av bygget. Mer om vad som går att koppla finns på sidan om Fortnox-integration.
• Du skriver för en stor organisation. Mallar från upphandlingar och konsultbolag är oftast gjorda för affärssystem med hundratals användare. Styrgrupper och bilagor gör inte ditt system bättre.

Från kravspecifikation till fast pris

När jag får en kravspecifikation läser jag den, ringer upp med frågorna den lämnar öppna och ger sen ett fast pris. Du behöver inte ha en färdig kravspec för att höra av dig, det går lika bra att börja med ett samtal.

Det jag letar efter är flödet och kopplingarna. Saknas något frågar jag hellre än gissar, för det är gissningarna som gör ett pris fel. Ett eget system kostar från 90 000 kr hos mig, och på sidan om ärendehanteringssystem räknar jag på att hyra eller bygga om du vill se hur det står sig mot ett färdigt system.

Ett underlag du redan jobbar i säger ofta mer än ett nyskrivet dokument. Mitt första system byggde jag 2011 åt en speditionsfirma som hade hela transporthanteringen i ett delat Excelark, där bara en person i taget kunde redigera. Arket visade både hur flödet gick och var det tog stopp. Läs om hur det delade Excelarket blev ett eget system.

Ett annat exempel är tjänsteföretaget som använde Harvest för tidrapportering. De frågade helt enkelt om jag kunde bygga något motsvarande. Systemet de redan kände till blev utgångspunkten, och sen anpassade vi det efter hur de jobbar. Licensen på drygt 30 000 kronor om året försvann. Så gick det till när Harvest byttes mot ett eget system för tidrapportering.

Mer om hur jag tänker kring skräddarsydd mjukvara för små företag finns på tjänstesidan.

Uppdaterad 29 oktober 2026