Hvorfor laver man en kravspecifikation?

Mange springer over, hvor gærdet er lavest, fordi de tror, det er vanskeligt, teknisk kompliceret og tidskrævende. Derfor er der forbavsende mange projekter, der starter med intet andet end en deadline, et budget og en løs forestilling om, hvad slutproduktet konkret skal være. Sådan et projekt kan nemt få en kedelig afslutning, når parternes forestillinger viser sig at være forskellige.

En kravspecifikation er derfor en vigtig del af enhver udviklingsproces, fordi den skaber klarhed for begge parter. Den hjælper til en fælles forståelse og sikrer, at alle parter er på samme side med hensyn til forventninger, funktionaliteter og design. Kundens behov og krav bliver tydeligt dokumenteret.

Kravspecifikationen kan også bruges af udviklerne som en retningslinje, fordi den giver struktur og en klar målsætning, som man kan arbejde efter, hvilket effektiviserer udviklingsprocessen.

Endeligt hjælper kravspecifikationen også med at skabe grundlaget for tilbuddet og kontrakten mellem kunden og udvikleren, da den giver en klar aftale omkring arbejdets omfang, betaling og leveringsdatoer.

Med andre ord hjælper kravspecifikationen med at skabe struktur, klarhed og en fælles ramme for udviklingen af hjemmesiden.

Hvad skal en kravspecifikation indeholde?

Selvom der kan være store forskelle på kravspecifikationer, er der alligevel visse elementer, som de fleste indeholder. Vi har gode erfaringer med følgende struktur:

Sektion	Indhold
Introduktion	Projektformål, målgruppe, interessenter
Omfang & definitioner	Hvad inkluderes/ekskluderes, akronymer, terminologi
Overordnet beskrivelse	Brugers behov, systemperspektiv, afhængigheder
Prioritering	MoSCoW-kategorier og tidsplan
Funktionskrav	Detaljerede krav med input/output, scenarier, test
Ikke-funktionelle krav	Performance, sikkerhed, tilgængelighed osv.
Eksempler & brugerflows	Wireframes, flows, use cases
Validering & test	Hvordan skal krav verificeres/testes
Traceability	Link mellem krav og test/dokumenter/design
Vedligeholdelse & support	Supportniveauer, svartider, opdateringsfrekvens, fejlrettelser, SLA-aftaler
Pris & tidsramme	Budgetoverslag, betalingsplan, milepæle, deadlines
Ændringslog	Versionshistorie og godkendelser
Appendikser	Diagrammer, glossary, reference-dokumenter

Introduktion og formål

Beskriv en kort introduktion til virksomheden eller projektet og angiv formålet med hjemmesiden. Forklar, hvad der motiverer oprettelsen af hjemmesiden og de forventede resultater.

Funktionelle krav

Funktionelle krav beskriver de handlinger og funktioner, som webapplikationen skal kunne udføre. Formålet er at skabe en tydelig forståelse af, hvad systemet skal gøre, hvordan det skal gøre det, og hvorfor det er vigtigt for brugeroplevelsen og forretningsmålet.

For hvert krav bør du:

• Beskrive formålet – hvilken værdi giver funktionen for brugeren eller virksomheden?
• Forklare arbejdsgangen – hvordan interagerer brugeren eller systemet med funktionen?
• Definere input og output – hvilke data kræves, og hvilket resultat skal leveres?
• Fastlægge prioritet – f.eks. efter MoSCoW-metoden (Must-have, Should-have, Could-have, Won’t-have).
• Angive acceptkriterier eller brugsscenarier – så kravene kan testes og valideres.

Vedligeholdelse og support

Når løsningen er lanceret, stopper arbejdet ikke. En kravspecifikation bør også beskrive, hvordan vedligeholdelse og support håndteres, så både kunde og leverandør har klare forventninger til samarbejdet efter go-live.

Følgende punkter kan med fordel indgå:

• Opdateringer og fejlrettelser
  Beskriv hvordan fejl meldes ind, og hvor hurtigt de rettes afhængigt af alvorlighedsgrad (f.eks. kritiske fejl udbedres inden for 24 timer).
  
  
• Supportniveauer og svartider
  Definér hvilke supportkanaler der tilbydes (e-mail, telefon, ticket-system) samt forventede svartider på hverdage, aftener og weekender.
  
  
• Vedligeholdelsesopgaver
  Angiv hvem der er ansvarlig for at holde systemet teknisk opdateret, fx opdatering af CMS, frameworks, plugins og servermiljø.
  
  
• Serviceaftale (SLA)
  Beskriv eventuelle serviceaftaler, der sikrer driftstid, overvågning eller proaktive opdateringer. SLA’en kan indeholde garantier for oppetid (f.eks. 99,5 %) og procedure ved nedbrud.
  
  
• Udviklingsønsker fremadrettet
  Klargør hvordan nye funktioner eller ændringer håndteres efter projektets afslutning (timepris, estimater, sprint-planlægning osv.).

En veldefineret sektion om vedligeholdelse og support sikrer, at kunden ikke står uden hjælp, når systemet er i drift, og giver udvikleren en klar ramme for, hvilke opgaver der ligger inden for aftalen.

Pris og tidsramme

Kunden vil naturligvis gerne have en idé om den forventede pris og tidsramme for at udvikle hjemmesiden. Klare oplysninger om omkostninger og tidsplan vil hjælpe med at skabe realistiske forventninger og undgå overraskelser.

Er der forskellige faser i projektet, kan det give mening at lave et Gantt-diagram.

Ændringslog

En kravspecifikation er sjældent statisk. Nye behov kan opstå undervejs i projektet, og eksisterende krav kan ændres eller præciseres. For at bevare overblikket og undgå misforståelser bør dokumentet derfor indeholde en ændringslog.

Ændringsloggen fungerer som en historik over alle ændringer, der er foretaget i kravspecifikationen. Den bør som minimum indeholde:

• Versionnummer (f.eks. v1.0, v1.1)
• Dato for ændring
• Beskrivelse af ændringen (hvad er tilføjet, fjernet eller rettet?)
• Ansvarlig person (hvem har godkendt ændringen)

En simpel ændringslog kan f.eks. se sådan ud:

Version	Dato	Beskrivelse	Ansvarlig
1.0	01-09-2025	Første version sendt til kunden	Projektleder
1.1	05-09-2025	Tilføjet krav om PayPal-betaling	Kunde + udvikler

Fordelen ved at have en ændringslog er, at både kunde og udviklere kan følge udviklingen af kravspecifikationen og se, hvornår og hvorfor ændringer er sket. Det giver transparens, letter samarbejdet og minimerer risikoen for uenigheder senere i projektet.