Kravspecifikation – Hvad er det?

Kravspec. bruges til at få udviklet det man har behov for

En hjemmeside eller et system er i virkeligheden et yderst komplekst produkt, specielt når hjemmesiden skal køre din forretning.

Derfor bruger hjemmesider udvikler kravspecifikationen, til at få alle dine behov integreret ind i din hjemmesideløsning. Det er derfor utroligt vigtigt at være meget specifik, i hvad man ønsker og har behov for, når man bedes udføre en kravspecifikation.

Behovet for en hjemmeside findes oftest i udstrækning af den forretningsmodel, som man har i sin normale drift. Hjemmesiden skal i de fleste tilfælde afspejle alle de funktioner, som bruges i driften. Lige fra marketing til salg til levering af det produkt man sælger.

Eksempel:
Har du en butik, hvor du både sælger detailvarer samt konfigurerbare varer? Så skal din webshop fungere i samarbejde med din fysiske butik og alle typer af varer du sælger. Webshoppen skal kunne sælge de samme varer, standard eller custom- og beregne prisen på varerne dynamisk, uden det har nogen negativ indflydelse på driften. Kundens valgmuligheder skal være fuldstændig ens, om de handler i butikken eller online.

Hvad er en kravspecifikation?

En kravspecifikation, ofte kaldet kravspec., er en omfattende beskrivelse af funktioner, egenskaber og begrænsninger for et IT-system eller softwareprodukt. Dette dokument skaber et klart og fælles billede mellem kunden og udviklingsteamet om, hvad der skal udvikles. Det inkluderer alt fra funktionelle krav, som beskriver, hvad systemet skal kunne gøre, til ikke-funktionelle krav, som beskriver kvalitetsattributter som sikkerhed, ydeevne og brugervenlighed.

Det, at tegne og forklare sin drift, så udefrakommende forstår den og kan konvertere denne til en hjemmeside eller et IT-redskab er utroligt svært. Fordi at driften for din virksomhed oftest indeholder langt flere konfigurerbare elementer end man lige tror. IT-udviklere tænker i detaljer og specifikke anvisninger, hvis man ikke nævner en funktion eller system indstilling.

Eksempler på hvad en kravspec. kan indeholde:

En udførlig handleplan

En kravspecifikation fungerer også som en detaljeret handleplan, der guider udviklingsteamet gennem hele projektet. Denne plan indeholder:

• Projektafgrænsning: En klar definition af, hvad projektet inkluderer, og hvad det ikke inkluderer.
• Tidsplan: En detaljeret tidsplan, der angiver milepæle og deadlines.
• Ansvarsområder: En fordeling af ansvar og opgaver mellem teammedlemmerne.

Organisationer er komplekse i sin natur

Som mennesker opstiller vi vores organisationer og arbejde i et kompliceret netværk af afhængige funktioner og processer – f.eks. kommunikerer vi sammen langt mere og hurtigere end man lige tror og den måde hvorpå vi organiserer vores arbejde, kan være svær at forstå for udefrakommende. Det er faktisk så svært, mener nogle organisationsteoretikere, at udefrakommende aldrig vil opnå den fulde forståelse for, hvordan en organisation egentlig fungerer og den drift der findes i hverdagen.

Det siger sig selv, at det at få et program til at handle i forlængelse af en organisation, kan være udfordrende. Det er her, at en kravspecifikation kommer ind i billedet.

Kravspecifikationen kan være svaret

En kravspecifikation kan være mange ting – oftest er det et dokument med en liste over krav, som kunden definerer til det købte program eller hjemmeside. Dokumentet indeholder så meget detaljeret information om krav og ønsker til hjemmesiden som muligt. Dokumentet gør, at udvikleren bedre forstår, hvordan han skal kode hjemmesiden.

I teorien burde det være kunden selv som udformer en kravspecifikation for produktet. Her skulle kunden indsamle information om deres egen driftsmæssige processer og udpensle det i et dokument.
Der tænker man med det samme; ”det er da let nok! Det er jo min egen organisation – jeg ved da alt omkring min egen organisation”. Men den antagelse kan vise sig at være en fejl, fordi man hurtigt bliver blind over for de driftsmæssige handlinger, som man foretager sig i hverdagen. Selvfølgelig ville det være ideelt, hvis kunden kunne udforme en kravspecifikation, men det er faktisk sjældent tilfældet.

Få specificeret kravene til opgaven

Hvis ikke jeg selv kan lave en kravspecifikation…, hvem kan så?

Webto har siden 2012 udviklet digitale webløsninger og ageret konsulenter til det danske erhvervsliv. Vores team på 12 webeksperter arbejder i dag ud fra kontoret i Slagelse, er et komplet webbureau, som er specialiseret i at udvikle unikke digitale løsninger i TYPO3 og Magento. Vi huser nogle af landets skarpeste eksperter inden for webudvikling og kan tilbyde skræddersyede hjemmesider og webshops. Som et komplet bureau kan vi foruden webudvikling sørge for online markedsføring via en bred vifte af digitale kanaler som sociale medier, google ads, email markedsføring og meget mere. Vores ambition er at være din digitale partner på hele rejsen.

Gennem årene har vi udviklet mere end 600 projekter, fra det simple website, til store komplicerede løsninger. Alle med det samme formål at løfte kundens forretning.

Vælger I derfor os som samarbejdspartner og konsulenter, vælger I et hold af dedikerede eksperter, der vil hjælpe jer med at udvikle jeres digitale løsning. Dette så jeres driftsmæssige behov lettest konverteres om til at IT-redskab, der vil gavne jeres forretning mange år ud i fremtiden.

Ekstra kravspecifikationer der er relevante at tage stilling til

1) Lovkrav og “compliance” bør være en fast del af kravspecifikationen

Når I beskriver krav til en ny hjemmeside, webshop eller digital platform, bør lovkrav ikke være en “ekstra tanke” til sidst. De bør være en fast krav-kategori på linje med funktioner, design og integrationer.

Grunden er enkel: Hvis løsningen ikke lever op til lovkrav, især for store virksomheder og virksomheder der handler og sælger uden for Danmark, kan det give dyre ændringer, forsinkelser og i værste fald klager, bøder eller tab af omsætning. Derfor er det smartest at få det skrevet ind som konkrete krav fra start.

Hvad betyder “compliance” i praksis?

“Compliance” betyder kort sagt: Løsningen skal overholde relevante regler og standarder – og det skal kunne dokumenteres.

Her er de mest typiske compliance-områder, man bør have som faste punkter i en kravspec:

Tilgængelighed (Accessibility)

Mange digitale services og webshops skal leve op til tilgængelighedskrav i EU. European Accessibility Act (EAA) gælder fra 28. juni 2025 for de omfattede produkter og services.

Kravene tager typisk udgangspunkt i WCAG 2.2, som er en officiel webstandard.

Eksempler på krav man kan skrive ind:

• “Checkout skal kunne gennemføres med tastatur alene”
• “Formularfejl skal forklares tydeligt (ikke kun med farve)”
• “Knapper/klik-områder skal have tilstrækkelig størrelse på mobil”

Datasikkerhed (Cybersecurity)

For nogle virksomheder/brancher bliver krav til sikkerhed og beredskab vigtigere (og kan være direkte lovkrav). EU’s NIS2 stiller krav om højere cybersikkerhed, og medlemslande skulle implementere direktivet senest 17. oktober 2024.

Eksempler på krav man kan skrive ind:

• “Der skal være logning og overvågning af kritiske hændelser”
• “Backups skal testes, og restore-procedure skal dokumenteres”
• “Adgangsstyring: 2FA på admin, rollebaserede rettigheder”

Persondata (GDPR)

Hvis løsningen håndterer persondata (kontaktformularer, kundelogin, nyhedsbrev, køb), skal GDPR tænkes ind som krav: roller, ansvar og aftaler.

Eksempler på krav man kan skrive ind:

• “Der skal være databehandleraftaler med relevante leverandører”
• “Sletning/anonymisering af kundedata skal kunne udføres efter politik”
• “Samtykker skal kunne dokumenteres”

Sådan gør I det konkret i kravspec’en

Lav en sektion som f.eks. “Lovkrav & compliance” med:

• Hvilke regler/standarder der gælder (tilgængelighed, sikkerhed, GDPR)
• Hvilke krav der er MUST vs. SHOULD
• Hvordan det testes (fx tilgængelighedstests, sikkerhedstjek, samtykkelogs)
• Hvem der har ansvar for hvad (kunde, udvikler, drift/hosting, tredjepart)

Bemærk: hvilke regler der gælder, afhænger af virksomhed/branche og løsningstype, så det er altid klogt at få det afklaret tidligt (evt. med juridisk sparring).

2) Et mere moderne krav-format: user stories og acceptkriterier (agilt)

Mange kravspecifikationer ender som lange dokumenter med “systemet skal…”-punkter. Det kan fungere, men ofte giver det bedre resultater at skrive krav i et agilt format, hvor man gør kravene lette at forstå, lette at bygge og lette at teste.

Det gør man typisk med user stories og acceptkriterier.

Hvad er en user story?

En user story beskriver en funktion set fra brugerens perspektiv. Den er kort og fokuserer på hvorfor noget skal laves, ikke kun hvad. Sæt jer i jeres kunders sted, gør klart hvad i ønsker og find så ud af hvordan jeres kunder, nemmest, kan gøre den handling i ønsker og få en god oplevelse.

En klassisk skabelon er:

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

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

Hvorfor er det smart?

User stories gør det nemmere at:

• sikre, at funktioner faktisk løser et behov
• undgå misforståelser mellem kunde, designer og udvikler
• prioritere funktioner ud fra værdi (i stedet for “alt på én gang”)

Hvad er acceptkriterier?

Acceptkriterier er de helt konkrete betingelser, der skal være opfyldt, før en user story er “færdig”. De fungerer som en fælles tjekliste for både kunde og udviklere.

Eksempel på acceptkriterier til favoritter:

• Kunden kan tilføje et produkt til favoritter fra produktliste og produktside
• Favoritter gemmes på kundens konto (så de findes igen efter login)
• Kunden kan fjerne et produkt fra favoritter igen
• Der vises en tydelig besked, når et produkt er tilføjet/fjernet
• Favoritter er nemt at tilgå igen, uanset hvor kunden er i webshoppen

Når acceptkriterierne er klare, er det også lettere at teste og godkende løsningen.

Bonus: “Given / When / Then” (super konkret)

Hvis man vil gøre det endnu mere testbart, kan acceptkriterier skrives sådan her:

• Given at jeg er logget ind
• When jeg klikker “Tilføj til favoritter” på et produkt
• Then skal produktet ligge i min favoritliste og kunne ses under “Min konto”

Sådan bruger man det i en kravspec

I en moderne kravspec kan I strukturere det sådan:

• Funktioner beskrives som user stories
• Hver story får acceptkriterier
• I prioriterer med f.eks. Must / Should / Could (så I kan levere hurtigt og udbygge bagefter)

Det giver en kravspec., der ikke bare beskriver “hvad”, men også gør det tydeligt hvornår det er lavet rigtigt og det sparer både tid, penge og frustrationer i udviklingen.

3) Drift, hosting og ansvar

Når man laver en kravspecifikation, handler det ofte om funktioner, design og integrationer. Men der er ét område, der alt for ofte bliver glemt – og som bagefter kan give store problemer: drift, hosting og ansvar.

Kort sagt: Det er ikke nok, at en løsning virker den dag, den går live. Den skal også køre stabilt, være sikker, kunne opdateres, og der skal være styr på hvem der gør hvad, når noget går galt.

Hvorfor er det vigtigt?

Hvis drift og hosting ikke bliver afklaret tidligt, ender man typisk med:

• uventede ekstraomkostninger (“det var ikke med i aftalen”) – Udviklere giver et tilbud på baggrund af kravspec. derfor er alt der ikke er inkluderet, uanset hvor basalt det måske så virker til at være efter, ikke en del af opgaven og er ofte herefter ekstra arbejde
• nedetid eller performance-problemer, som ingen tager ejerskab for
• usikkerhed om backups, opdateringer og sikkerhed
• konflikter om ansvar mellem kunde, bureau, hostingpartner og tredjepartsleverandører

Hvad bør en kravspec indeholde om drift og hosting?

Her er de vigtigste punkter at få skrevet ind, i et sprog alle kan forstå:

Hvor skal løsningen hostes?

• Skal det være en bestemt hostingudbyder?
• Skal der være udviklingsmiljø (dev), testmiljø (stage) og produktionsmiljø (live)?
• Hvem betaler for hosting, og hvad er budgetrammen?

Hvem har ansvaret for hvad?

Det bør stå helt tydeligt:

• Hvem står for drift og vedligehold?
• Hvem opdaterer system og plugins/moduler?
• Hvem håndterer domæne, DNS og e-mailopsætning?
• Hvem kontakter man ved fejl og hvem løser det?

Backup og gendannelse (restore)

Backup er kun tryghed, hvis man kan gendanne:

• Hvor ofte tages backup?
• Hvor længe gemmes den?
• Hvor hurtigt kan sitet gendannes, hvis noget går ned?
• Testes restore jævnligt?

Overvågning og alarmer

• Skal der være monitorering af oppetid og fejl?
• Skal der sendes alarmer ved nedbrud, fejl i betaling, manglende e-mails osv.?

Oppetid, svartid og support (SLA)

Hvis løsningen er forretningskritisk (f.eks. webshop), bør I aftale:

• forventet oppetid (f.eks. 99,9%)
• responstid på support (f.eks. inden for X timer)
• hvornår supporten gælder (kontortid / 24/7)

En simpel tommelfingerregel

Hvis det ikke står i kravspec’en, bliver det ofte “ingenmandsland” senere. Det vil gå op for jer at intet er besluttet og derfor bliver intet gjort og når der så opstår problemer, opstår der en flaskehals og tiden bliver spildt og løsninger udsat.

Derfor er drift/hosting/ansvar en vigtig del af en moderne kravspecifikation; fordi det sikrer, at løsningen ikke bare bliver flot og funktionel, men også stabil, sikker og nem at drive efter lancering.