Kravspecifikation: Hvad er det, og hvordan skriver du en? (med skabelon)

En kravspecifikation er det dokument, der beskriver præcis hvad en ny hjemmeside, webshop eller et system skal kunne, hvilke krav det skal leve op til, og hvordan I sammen afgør, om det er leveret rigtigt.

Den er grundlaget for tilbuddet, for udviklingen og for den endelige godkendelse. Står det ikke i kravspecifikationen, er det som regel ikke med i prisen. Her får du en gennemgang af hvad den skal indeholde, en skabelon du kan kopiere, et udfyldt eksempel og de fejl, vi oftest ser.

Hvad er en kravspecifikation?

En kravspecifikation, ofte kaldet kravspec, er en samlet beskrivelse af de funktioner, egenskaber og begrænsninger, et IT-system skal have. Den skaber et fælles billede mellem dig som kunde og dem, der skal udvikle løsningen.

Kravene deles typisk i to:

• Funktionelle krav: Hvad systemet skal kunne. Fx “Kunden skal kunne booke en tid og få en bekræftelse på SMS.”
• Ikke-funktionelle krav: Hvor godt det skal fungere. Fx hastighed, sikkerhed, tilgængelighed, oppetid og hvilke browsere og enheder det skal virke på.

En hjemmeside eller et system, der skal drive din forretning, er et komplekst produkt. Det skal afspejle den måde, I faktisk arbejder på: fra markedsføring og salg til levering, fakturering og support. Har du fx en butik, der sælger både standardvarer og varer, kunden selv konfigurerer, så skal webshoppen kunne regne prisen ud på samme måde som i butikken, og valgmulighederne skal være de samme online og i butikken. Den slags skal stå sort på hvidt.

Hvorfor skal du bruge en kravspecifikation?

• Forventningsafstemning: I og udvikleren er enige om, hvad der skal laves, før der bruges penge på det.
• Sammenlignelige tilbud: Får flere leverandører den samme kravspec, kan du sammenligne priserne på et ærligt grundlag.
• Planlægning: Tidsplan, ressourcer og budget kan lægges ud fra noget konkret.
• Godkendelse: Når kravene er målbare, er det nemt at teste, om løsningen lever op til dem.
• Beskyttelse af dig som kunde: Kravspec’en er ofte bilag til kontrakten. Uenighed om “var det med?” afgøres ud fra den.

Hvad skal en kravspecifikation indeholde?

Ikke alle projekter skal bruge alle afsnit. En lille hjemmeside kan klares på få sider, mens et forretningskritisk system kræver mere. Brug tabellen som tjekliste og spring over det, der ikke er relevant.

Skabelon til kravspecifikation (kopiér og udfyld)

Kopiér skabelonen ind i et dokument, og udfyld den så godt du kan. Det er helt i orden at skrive “ved ikke” eller “skal afklares”. Et åbent spørgsmål er langt bedre end et, der er glemt.

KRAVSPECIFIKATION: [Projektets navn]
Version: [1.0]   Dato: [dd.mm.åååå]   Ansvarlig: [navn]

1. BAGGRUND OG FORMÅL
   - Om virksomheden:
   - Hvorfor laver vi projektet nu?
   - Hvilket problem skal løsningen løse?

2. MÅL OG SUCCESKRITERIER
   - Mål 1: [hvad skal være anderledes, og hvordan måler vi det?]
   - Mål 2:

3. BRUGERE OG ROLLER
   - Rolle: [fx kunde]          Må: [se/gøre ...]
   - Rolle: [fx medarbejder]    Må: [se/gøre ...]
   - Rolle: [fx administrator]  Må: [se/gøre ...]

4. FUNKTIONELLE KRAV (user stories)
   ID: F-01   Prioritet: [Must/Should/Could]
   Som [rolle] vil jeg [kunne gøre noget], så jeg [opnår en værdi].
   Acceptkriterier:
   - [konkret betingelse 1]
   - [konkret betingelse 2]

5. IKKE-FUNKTIONELLE KRAV
   - Hastighed: [fx grønne Core Web Vitals på mobil]
   - Sikkerhed: [fx 2FA for administratorer, rollebaserede rettigheder]
   - Tilgængelighed: [fx WCAG 2.2 niveau AA]
   - Enheder og browsere:
   - Sprog:

6. DATA OG INTEGRATIONER
   - Data der skal flyttes med: [kunder, ordrer, produkter ...]
   - Integrationer: [system, retning, hvor ofte, hvem ejer adgangen]

7. DESIGN OG INDHOLD
   - Designmanual/brand:
   - Hvem leverer tekster, billeder og oversættelser?

8. LOVKRAV OG COMPLIANCE
   - GDPR: [persondata, databehandleraftaler, sletning]
   - Tilgængelighed:
   - Cookies og samtykke:
   - NIS2/branchekrav:

9. DRIFT, HOSTING OG ANSVAR
   - Hosting og miljøer: [udvikling, test, live]
   - Backup: [hvor ofte, hvor længe, test af gendannelse]
   - Opdateringer og overvågning:
   - Support: [hvem kontaktes, hvornår, svartid]

10. TIDSPLAN, BUDGET OG GODKENDELSE
   - Deadline og milepæle:
   - Budgetramme:
   - Test og godkendelse: [hvem tester, hvem godkender]

ÅBNE SPØRGSMÅL
   - [det vi ikke ved endnu]

Et udfyldt eksempel

Her er et kort, fiktivt eksempel på, hvordan to afsnit kan se ud for en lille virksomhed, der vil have online booking på sin hjemmeside.

Sådan skriver du gode krav: user stories og acceptkriterier

Mange kravspecifikationer ender som lange lister med “systemet skal …”. Det kan fungere, men det giver bedre resultater at skrive krav, der er lette at forstå, lette at bygge og lette at teste. Det gør du med user stories og acceptkriterier.

User stories

En user story beskriver en funktion set fra brugerens side og fortæller både hvad og hvorfor:

Som [type bruger] vil jeg [kunne gøre noget], så jeg [opnår en værdi].

Eksempel fra en webshop: Som kunde vil jeg kunne gemme produkter som favoritter, så jeg hurtigt kan finde dem igen.

Acceptkriterier

Acceptkriterier er de konkrete betingelser, der skal være opfyldt, før en user story er færdig. Til favoritter kunne det være:

• Kunden kan tilføje et produkt fra både produktlisten og produktsiden.
• Favoritter gemmes på kundens konto og findes igen efter login.
• Kunden kan fjerne et produkt igen.
• Der vises en tydelig besked, når et produkt er tilføjet eller fjernet.

Vil du gøre det endnu mere testbart, kan du skrive i formatet Givet / Når / Så (Given / When / Then): Givet at jeg er logget ind, når jeg klikker “Tilføj til favoritter”, så ligger produktet på min favoritliste under “Min konto”.

Prioritér med Must, Should og Could

Giv hvert krav en prioritet. Must er det, løsningen ikke kan gå live uden. Should er vigtigt, men kan komme kort efter. Could er ønsker, der tages med, hvis tid og budget rækker. Metoden kaldes MoSCoW, og den gør det muligt at gå live hurtigere og bygge videre ud fra rigtige erfaringer i stedet for gæt.

Hvem skal skrive kravspecifikationen?

I teorien er det kunden, for det er jer, der kender forretningen. I praksis er det svært. Man bliver hurtigt blind for sine egne arbejdsgange, og meget af den viden, der får hverdagen til at køre, står ingen steder. Det er ofte de små ting, der bliver glemt: den særlige rabat til en fast kunde, den manuelle kontrol før en ordre sendes, eller regnearket, som kun én medarbejder forstår.

Den bedste kravspec bliver derfor til i et samarbejde. I leverer viden om forretningen, og udvikleren stiller de spørgsmål, der får det hele frem, og oversætter det til krav, der kan bygges og testes.

AI og klikbare prototyper i kravarbejdet

To ting har gjort kravarbejdet både hurtigere og bedre:

• AI som sparringspartner: Du kan bruge en AI-assistent til at gøre noter fra møder om til user stories, finde huller (“hvad sker der, hvis kunden aflyser?”) og foreslå acceptkriterier. Men AI kender ikke din forretning. Brug det til første udkast, og lad altid de mennesker, der kender arbejdsgangene, læse det igennem. Del ikke fortrolige oplysninger eller persondata med værktøjer, I ikke har en aftale med.
• Klikbare prototyper: Mange har svært ved at forestille sig et system ud fra tekst. En simpel prototype, man kan klikke rundt i, afslører hurtigt misforståelser, som et dokument aldrig ville have fanget. Det er billigere at rette en skærm i en prototype end i et færdigt system.

Hos Webto arbejder alle dagligt med AI, og vi bruger det også i afklaringen. Det betyder ikke, at AI skriver kravspecifikationen. Det betyder, at vi hurtigere kan vise jer noget konkret at tage stilling til.

Lovkrav og compliance i kravspecifikationen

Lovkrav bør ikke være en eftertanke. Lever løsningen ikke op til dem, kan det give dyre ændringer, forsinkelser og i værste fald klager eller bøder. Skriv dem ind som konkrete krav fra start.

Tilgængelighed

European Accessibility Act gælder fra 28. juni 2025 for en række produkter og tjenester, blandt andet mange webshops. Kravene tager udgangspunkt i WCAG-standarden, hvor WCAG 2.2 er den nyeste version. Eksempler på krav:

• Checkout skal kunne gennemføres med tastatur alene.
• Fejl i formularer forklares med tekst, ikke kun med farve.
• Knapper og klikområder er store nok på mobil.

Cybersikkerhed og NIS2

Den danske NIS2-lov trådte i kraft 1. juli 2025, og omfattede virksomheder skulle registrere sig senest 1. oktober 2025. Er I omfattet, eller er jeres kunder det, skal sikkerhedskravene stå i kravspecifikationen. Også selv om I ikke er omfattet, er disse krav et godt udgangspunkt:

• Logning og overvågning af kritiske hændelser.
• Tofaktorgodkendelse for administratorer og rettigheder efter rolle.
• Backups, der testes, og en dokumenteret procedure for gendannelse.

Persondata (GDPR)

Håndterer løsningen persondata via kontaktformularer, kundelogin, nyhedsbreve eller køb, skal GDPR med som krav:

• Databehandleraftaler med de relevante leverandører.
• Sletning eller anonymisering af kundedata efter en fast politik.
• Samtykker, der kan dokumenteres.

Skriv for hvert område, hvilke krav der er Must og Should, hvordan det testes, og hvem der har ansvaret. Hvilke regler der gælder, afhænger af branche og løsning, så få det afklaret tidligt, eventuelt med juridisk sparring.

Drift, hosting og ansvar: det mest glemte afsnit

Det er ikke nok, at løsningen virker den dag, den går live. Den skal køre stabilt, være sikker og kunne opdateres, og der skal være styr på, hvem der gør hvad, når noget går galt. Står det ikke i kravspecifikationen, bliver det ingenmandsland, og så opdager man det først, når det brænder.

• Hvor hostes løsningen, og hvem betaler?
• Er der separate miljøer til udvikling, test og live?
• Hvem opdaterer system, moduler og plugins, og hvor ofte?
• Hvem har domæne, DNS og e-mailopsætning?
• Hvor ofte tages backup, hvor længe gemmes den, og testes gendannelsen?
• Overvåges oppetid og fejl, og hvem får besked ved nedbrud eller fejl i betalingen?
• Hvilken oppetid og svartid på support er aftalt, og hvornår gælder supporten?

Hvad koster en kravspecifikation?

Skriver du den selv, koster den din tid. Får du hjælp fra et bureau eller en konsulent, betaler du typisk for timerne, og prisen afhænger af projektets størrelse og hvor meget der skal afdækkes. Hos Webto er timeprisen 1.000 kr.

Hvornår giver det mening at betale for den separat?

• Når projektet er stort eller forretningskritisk, og du vil indhente tilbud fra flere leverandører på det samme grundlag.
• Når du skal søge tilskud eller have en investering godkendt internt og har brug for et konkret grundlag.
• Når du er i tvivl om, hvorvidt du skal vælge et standardsystem eller en skræddersyet løsning.

Sørg for, at du ejer dokumentet bagefter og frit kan bruge det hos andre leverandører. Til en mindre hjemmeside er en separat betalt kravspec sjældent nødvendig. Her er en god snak og en kort, skriftlig opsummering af kravene ofte nok.

Står du mellem et færdigt system og en skræddersyet løsning, så læs vores gennemgang af standardsoftware vs. skræddersyet system. Og hvis jeres vigtigste værktøj i dag er et regneark, så se hvornår det giver mening at gå fra Excel til et registreringssystem.

Tjekliste før du sender kravspecifikationen

• Formålet og målene står i starten og kan forstås af en udenforstående.
• Alle brugerroller og deres rettigheder er beskrevet.
• Hver funktion er en user story med acceptkriterier og prioritet.
• Data, der skal flyttes med, og alle integrationer er listet.
• Lovkrav er beskrevet med ansvar og testmetode.
• Drift, hosting, backup og support er afklaret.
• Deadline, budgetramme og godkendelsesproces er skrevet ned.
• Åbne spørgsmål står samlet til sidst.

Ofte stillede spørgsmål

Kilder: AccessibleEU: European Accessibility Act fra juni 2025 · W3C: WCAG 2.2 · Trafikstyrelsen via Lovguiden: NIS 2-loven træder i kraft

“Det dyreste krav er det, ingen skrev ned, fordi alle troede, det var en selvfølge.”

Du er velkommen til at læse mere i nogle af vores andre blogindlæg