Guide · 2026

Kravspecifikation skabelon: fra idé til fast pris

Det korte svar: En god kravspecifikation til software beskriver formålet, brugerne, hvad de skal kunne, hvad der er vigtigst, hvilke systemer løsningen skal tale med, og hvordan I ved, at den er færdig. Den behøver ikke fylde 40 sider. To-fem sider efter skabelonen herunder er nok til, at en leverandør kan give jer en fast pris.

10 min. læsning · Opdateret 29. september 2026

En kravspecifikation er det dokument, der gør en idé til noget, en leverandør kan prissætte. Uden den får I tilbud, der ikke kan sammenlignes, og projekter, hvor alle troede, de var enige. Med den får I sammenlignelige priser, færre overraskelser og et fælles svar på spørgsmålet “er vi færdige?”. Skabelonen herunder er den, vi selv ville ønske, at alle kunder sendte.

Skabelon: de otte blokke i en kravspecifikation

Formål og mål: Hvilket problem løser systemet, og hvordan måler I, om det virker? Fx “halvere tiden brugt på bookinger”.
Brugere og roller: Hvem bruger systemet, og hvad må hver rolle se og gøre? Fx kunde, medarbejder og administrator.
User stories: Hvad skal hver rolle kunne? Skriv én sætning pr. behov.
Prioritering (must, should, could): Hvad skal med i første version, hvad er ønsket, og hvad kan vente?
Integrationer: Hvilke systemer skal løsningen tale med, fx e-conomic, MobilePay, MitID eller jeres CRM?
Data: Hvilke data findes i dag, hvor ligger de, og skal de flyttes?
Ikke-funktionelle krav: GDPR, sikkerhed, login, hastighed, tilgængelighed og hvilke enheder der skal understøttes.
Acceptkriterier: Hvordan ved I, at en funktion er færdig og virker som aftalt?

Eksempel: en kravspecifikation til et bookingsystem

Et forkortet eksempel for en servicevirksomhed. Jeres egen udgave kan være lige så kort.

Blok	Eksempel
Formål	Kunder booker selv online, så telefonen ikke er flaskehalsen.
Roller	Kunde, medarbejder, administrator.
User story	Som kunde vil jeg se ledige tider og booke, så jeg ikke skal ringe.
Must	Booking, bekræftelse på mail, medarbejderkalender.
Should / could	SMS-påmindelse (should), anmeldelser efter besøg (could).
Integrationer	MobilePay til betaling, e-conomic til faktura.
Ikke-funktionelt	Data i EU, databehandleraftale, virker på mobil.
Acceptkriterie	En booking vises i medarbejderens kalender inden for et minut.

Hvordan skriver man gode user stories?

Brug formen “Som [rolle] vil jeg [handling], så [gevinst]”. Gevinsten er den vigtigste del, fordi den fortæller leverandøren, hvorfor funktionen findes, og ofte åbner for en enklere løsning end den, I selv havde forestillet jer. Skriv hellere 20 korte user stories end fem lange. Hver story bør kunne testes med et acceptkriterie, fx “når kunden har betalt, står bookingen som betalt i admin-panelet”. Grupper jeres user stories efter rolle, så er det let at se, om en af brugerne er blevet glemt, og om administratoren har de værktøjer, der skal til for at passe systemet i hverdagen.

Hvem skal skrive kravspecifikationen?

Den person, der kender arbejdsgangen bedst, ikke nødvendigvis den mest tekniske. Ofte er det ejeren, en driftsansvarlig eller den medarbejder, der i dag holder Excel-arket i live. Tal med dem, der skal bruge systemet hver dag, før I skriver: hvad tager tid, hvad går galt, og hvad spørger kunderne om? I behøver ikke kende de tekniske løsninger. Det er leverandørens opgave at oversætte jeres behov til funktioner, integrationer og en pris.

De mest almindelige fejl i en kravspecifikation

At beskrive løsningen i stedet for problemet, fx “en knap øverst til højre” i stedet for “kunden skal kunne aflyse”.
At gøre alt til must-have. Så er der ingen prioritering, og første version bliver for stor.
At glemme administratorens behov. Nogen skal styre brugere, indhold og data bag skærmene.
At springe integrationerne over. De er ofte den største enkeltpost i projektet.
At skrive 40 sider, som ingen læser. Kort og præcist slår langt og udførligt.
At mangle acceptkriterier, så “færdig” bliver et spørgsmål om holdning.

Er I usikre på, hvordan skærmene skal hænge sammen, så er en klikbar prototype ofte en bedre kravspecifikation end tekst. Hos Grundfos brugte vi feltstudier og klikbare prototyper til at gøre kundeportalerne konkrete, før de blev bygget. Overvejer I stadig, om I skal bygge eller købe, så læs skræddersyet software vs standardsystem.

Fra kravspecifikation til tilbud til fast pris

I sender beskrivelsen

Kravspecifikation, noter eller en kort tekst. Skabelonen hjælper, men er ikke et krav.

Vi tæller funktioner

User stories og must-haves bliver til funktioner og integrationer.

Vi vælger pakke

12, 24 eller 36 funktioner og 1, 2 eller 3 integrationer.

I får fast pris

Et skriftligt tilbud til fast pris inden for 24 timer.

Sådan bliver jeres dokument til en fast pris hos os.

24 t

Skriftligt tilbud til fast pris

12/24/36

Funktioner i Small, Medium og Large

40+

Færdige integrationer

Fordi pakkerne har et fast antal funktioner og integrationer, kan en god kravspecifikation oversættes direkte til en pris. Small koster 18.000 kr plus 600 kr om måneden, Medium 36.000 kr plus 900 kr og Large 54.000 kr plus 1.200 kr. Læs mere om, hvorfor vi foretrækker fast pris frem for timepris, eller se alle priser.

Har I en kravspecifikation, et udkast eller bare en idé? Send den til os, så vender vi tilbage med spørgsmål og et skriftligt tilbud til fast pris inden for 24 timer.

Spørgsmål om kravspecifikationer

Hvor lang skal en kravspecifikation være?

Til de fleste SMV-projekter er to-fem sider nok. Det vigtige er ikke længden, men at formål, roller, user stories, prioriteringer, integrationer og acceptkriterier er beskrevet. Et langt dokument, som ingen læser, skaber flere misforståelser end et kort, som alle har forstået.

Skal vi have en kravspecifikation, før vi kontakter jer?

Nej. En kort beskrivelse af problemet og hvem der skal bruge løsningen er nok til at komme i gang. Vi stiller de spørgsmål, der mangler, og vender tilbage med et skriftligt tilbud til fast pris inden for 24 timer. Skabelonen her gør bare processen hurtigere og tilbuddet mere præcist.

Hvad er forskellen på must, should og could?

Must er det, løsningen ikke kan lanceres uden. Should er vigtigt, men kan vente til kort efter lanceringen. Could er rart at have, hvis tid og budget tillader det. Prioriteringen gør det muligt at lancere en første version hurtigt og tilføje resten bagefter, i stedet for at vente på det hele.

Hvordan beskriver vi GDPR-krav?

Skriv hvilke persondata systemet håndterer, hvem der må se dem, hvor længe de skal gemmes, og om de skal ligge i EU. Bed om en databehandleraftale med leverandøren. Håndterer I følsomme oplysninger, eller skal brugerne logge ind med MitID, så skriv det tydeligt, fordi det påvirker både design og pris.

Kan kravene ændre sig undervejs?

Ja, og det gør de næsten altid. Pointen med en kravspecifikation er ikke at låse alt fast, men at have et fælles udgangspunkt. Hos os kan nye funktioner efter lanceringen tilføjes til en fast pris pr. funktion, så ændringer ikke bliver til en åben regning.

Er en prototype bedre end en skriftlig kravspecifikation?

Til skærme og flows ofte ja, fordi alle kan klikke sig igennem og se, om det giver mening. Til integrationer, data og GDPR er tekst stadig bedst. Den stærkeste kombination er en kort skriftlig kravspecifikation plus en klikbar prototype af de vigtigste skærme.

Læs også

Sammenligning

Skal vi bygge det for jer?

I får et fastpristilbud inden for 24 timer.

Send jeres kravspecifikation