Vi har efterhånden været med på en del forskellige projekter og oplevet en masse forskellige kravspecifikationer. Herunder har vi samlet de erfaringer, som vi har fået undervejs.
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 slutproduktet.
En kravspecifikation skaber klarhed for begge parter. Den hjælper til en fælles forståelse og sikrer, at alle er på samme side med hensyn til forventninger, funktionaliteter og design.
Kravspecifikationen kan bruges som en retningslinje, fordi den giver struktur og en klar målsætning, som man kan arbejde efter, hvilket effektiviserer udviklingsprocessen.
Kravspecifikationen hjælper med at skabe grundlaget for tilbuddet og kontrakten, 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 — så parternes forestillinger ikke viser sig at være forskellige.
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, SLA-aftaler |
| Pris & tidsramme | Budgetoverslag, betalingsplan, milepæle, deadlines |
| Ændringslog | Versionshistorie og godkendelser |
| Appendikser | Diagrammer, glossary, reference-dokumenter |
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 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.
Formål: Brugerne skal altid have opdaterede oplysninger om produkter.
Arbejdsgang: Webshoppen henter lagerstatus, pris og SKU fra ERP-systemet i realtid via API.
Input/Output: Forespørgsel til ERP → aktuel lagerstatus, pris og SKU vises på produktet.
Acceptkriterium: Når en vare er udsolgt i ERP, må den ikke kunne lægges i kurven.
Formål: Giver kunderne tryghed og overblik efter køb.
Arbejdsgang: Efter ordreafsendelse modtager kunden et link til Track & Trace, som også kan tilgås via kundens konto.
Input/Output: Ordrenummer → live tracking status fra fragtudbyder.
Brugsscenarie: Kunden logger ind og kan se leveringsstatus uden at kontakte kundeservice.
Formål: Sikrer, at kunder kan gennemføre køb med de mest anvendte betalingsmetoder.
Arbejdsgang: Kunden vælger betalingsmetode, webshoppen sender forespørgsel til betalingsgateway og modtager bekræftelse.
Acceptkriterier: Betaling accepteres inden for 3 sek. Visa/Mastercard via gateway X. Dankort via API Y.
Could-have: Betaling med PayPal, hvis tidsplan tillader det.
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 efter go-live.
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 opgaverne.
Beskriv hvordan fejl meldes ind, og hvor hurtigt de rettes afhængigt af alvorlighedsgrad (f.eks. kritiske fejl udbedres inden for 24 timer).
Definér hvilke supportkanaler der tilbydes (e-mail, telefon, ticket-system) samt forventede svartider.
Angiv hvem der er ansvarlig for at holde systemet teknisk opdateret, fx opdatering af CMS, frameworks, plugins og servermiljø.
Beskriv eventuelle serviceaftaler, der sikrer driftstid, overvågning eller proaktive opdateringer. SLA’en kan indeholde garantier for oppetid (f.eks. 99,5 %).
Klargør hvordan nye funktioner eller ændringer håndteres efter projektets afslutning (timepris, estimater, sprint-planlægning osv.).
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.
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 bør dokumentet indeholde en ændringslog.
Ændringsloggen fungerer som en historik over alle ændringer. Den bør som minimum indeholde:
| 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 | Kunde + udvikler |
Fordel: Både kunde og udviklere kan følge udviklingen af kravspecifikationen og se, hvornår og hvorfor ændringer er sket. Det giver transparens og minimerer risikoen for uenigheder.
Har du brug for hjælp med at udarbejde en kravspecifikation eller komme i gang med dit næste projekt? Vi står klar til at hjælpe.
