Kravspecifikation uden fagsprog: hvad skal I kunne beskrive, før en udvikler går i gang?

I artiklen 8 afsnit

1. Hvad er en kravspecifikation, og hvornår skal I bruge en?
2. Fem spørgsmål før kode
3. Før og efter: en brief
4. Hvad behøver I ikke at kunne?
5. Hvad sker der, hvis I starter uden?
6. Hvordan kan jeg hjælpe?
7. Hvad kan I gøre nu?
8. Ofte stillede spørgsmål

Hvad er en kravspecifikation, og hvornår skal I bruge en?

En kravspecifikation er en beskrivelse af, hvad en løsning skal kunne, og hvad der skal være sandt, når den er færdig. Ordet lyder tungt, men til et lille forløb behøver den ikke fylde mere end en side. En brief er det samme i kortere form: behovet og rammerne i almindeligt sprog.

Længere specifikationer er først nødvendige, når flere leverandører skal byde på samme opgave, eller når mange personer skal tolke beskrivelsen ens. Er I i gang med et lille udviklingsforløb, svarer beskrivelsen til trin 1 og 2. Ordet "krav" betyder her bare, hvad I ønsker af løsningen, ikke juridiske krav.

Fem spørgsmål før kode

Modellen hedder Fem spørgsmål før kode. Den er min egen måde at holde en brief enkel på, ikke en standard. Tabellen viser spørgsmålene, hvordan et godt svar kan se ud, og hvad der sker, hvis I springer det over. Eksemplerne er tænkte.

Det første spørgsmål er den arbejdsgang, I allerede har. Kender I den ikke godt nok, så start med at kortlægge den. Det femte spørgsmål er det sværeste og det vigtigste: Det kræver, at nogen tør sige nej.

Før og efter: en brief

Forskellen er ikke længden. Det er, at "efter" kan afprøves: Man kan se, om ordren er oprettet én gang, og om salg kan se den. "Før" kan alle blive enige om og alligevel forstå forskelligt.

Hvad behøver I ikke at kunne?

I behøver ikke at vælge teknologi, tegne arkitektur eller kende fagord som API og integration. Det er udviklerens arbejde at foreslå en løsning ud fra jeres beskrivelse. Ved I, at data skal flyttes mellem to systemer, så læs, hvornår en integration giver mening. Er I i tvivl om, hvilken løsningstype I har brug for, så hjælper AI-agent, automatisering eller integration.

Det, I skal kunne, er at forklare, hvad der sker i hverdagen, og hvad I vil have ændret. Det er også det, en god udvikler vil spørge om.

Hvad sker der, hvis I starter uden?

Uden en beskrivelse bygger udvikleren på gæt. Misforståelser opdages først, når noget er bygget, og rettelsen koster mere, end beskrivelsen ville have gjort. Nogle gange opdager I også først i prøvedriften, at de rigtige brugere ikke var med, eller at en vigtig integration mangler. Hvad den manuelle arbejdsgang koster i dag, og dermed hvad en løsning skal kunne betale sig mod, står i artiklen om hvad manuel administration koster.

Hvordan kan jeg hjælpe?

Brug, data, adgang og relevante krav er en del af arbejdet hele vejen. Ofte skriver vi de fem svar sammen i en samtale, og så skriver jeg dem rent bagefter. Er I i tvivl, om I skal købe, tilpasse eller bygge, så læs købe, tilpasse eller bygge. Se mine systemer og løsninger. Jeg giver ikke juridisk rådgivning og garanterer ikke compliance. Når løsningen er i drift, kan et register som SPOR bevare overblikket over, hvad der kører, og hvem der ejer det.

Hvad kan I gøre nu?

Gør dette:

1. Skriv de fem svar på én side i almindeligt sprog.
2. Læs det højt for en bruger. Kan brugeren genkende arbejdsgangen, er I godt på vej.
3. Skriv, hvad der ikke skal med i første version.
4. Send det til en udvikler, og bed om spørgsmål, ikke om et tilbud.

Når I har fem svar, så læs, hvordan I vælger udvikler eller leverandør: Hvordan vælger I udvikler eller leverandør? Syv spørgsmål at stille.

Kort sagt: Fem svar i almindeligt sprog er et bedre udgangspunkt end en lang liste af funktioner. Næste skridt er at køre forløbet fra behov til første version.

Ofte stillede spørgsmål

Hvad skal en kravspecifikation indeholde?

For et lille forløb er fem svar nok: hvad der starter arbejdsgangen, hvem der rører den, hvilke systemer og data der indgår, hvad der skal være sandt, når den er færdig, og hvad der ikke skal med. Længere specifikationer er først nødvendige, når flere leverandører skal byde på samme opgave.

Skal jeg have en kravspecifikation, før jeg kontakter en udvikler?

Nej. Men I skal kunne svare på de fem spørgsmål, før arbejdet går i gang. Ofte kan I finde svarene i en samtale, hvor udvikleren stiller spørgsmålene, og I skriver dem ned bagefter.

Hvad er forskellen på en kravspecifikation og en brief?

I praksis er de to ord glidende. En brief er kortere og beskriver behovet og rammerne. En kravspecifikation er mere detaljeret og bruges, når flere skal kunne tolke den ens, for eksempel ved en udbudsrunde. Til et lille forløb er en brief med de fem svar normalt rigeligt.

Hvordan beskriver jeg et behov, hvis jeg ikke er teknisk?

Beskriv, hvad der sker i hverdagen, ikke hvilken teknologi I tror, I mangler. Skriv, hvad der starter arbejdet, hvem der gør hvad, og hvor tiden eller fejlene opstår. Det kan I gøre på en side i almindeligt sprog.

Artiklen er generel vejledning og ikke juridisk rådgivning. Udgivet 3. oktober 2026.