Sådan skriver du en kravspecifikation til din app

Af Weapp · Opdateret 2025-05-10

En god kravspecifikation til en app beskriver på 5–15 sider formål, målgruppe, de vigtigste brugerflows, integrationer og ikke-funktionelle krav som ydeevne og sikkerhed. Den skal være klar nok til sammenlignelige tilbud, men beskrive hvad appen skal opnå, ikke låse hvordan løsningen skal bygges. Detaljeniveauet vokser med projektets faser.

Kravspecifikationen har én eneste opgave i tilbudsfasen: at få flere leverandører til at prissætte det samme uden at låse en løsning fast som viser sig at være forkert. De fleste specifikationer fejler i den ene eller den anden retning: enten så vage at tilbuddene bliver gæt, eller så detaljestyrede at leverandørens kompetencer aldrig kommer i spil. Sådan rammer du det rette niveau.

Skabelonen: seks afsnit der rækker langt

En kravspecifikation til tilbudsfasen behøver sjældent at fylde mere end 5–15 sider, struktureret nogenlunde sådan her:

Formål og mål. Hvilket problem løser appen, for hvem, og hvordan ved I om den lykkes? Et par målbare mål (f.eks. andelen af henvendelser der flytter fra telefon til app) styrer tusind detaljebeslutninger senere.
Målgruppe og brugssituation. Hvem er brugerne, hvor ofte bruger de appen, og i hvilket miljø? En app der bruges dagligt af feltpersonale med handsker, stiller andre krav end en der åbnes i sofaen en gang om måneden.
Brugerflows. Beskriv de 5–10 vigtigste ting en bruger skal kunne gøre, som flows: “brugeren fotograferer kvitteringen, vælger projekt, godkenderen får besked”. Prioritér i skal/bør/kan. Det er prioriteringen der gør tilbud sammenlignelige og etaper mulige.
Integrationer. Hvilke systemer skal appen tale med: ERP-system, login, betaling, kort? Angiv for hvert system hvad der findes i dag (API’er? dokumentation?). Integrationer er en af de største omkostningsdrivere, og ukendte integrationer er den mest almindelige årsag til sprængte budgetter.
Ikke-funktionelle krav. Ydeevne, sikkerhed, GDPR, tilgængelighed, offlineunderstøttelse, sprog, platforme og versioner. Skriv kun krav I mener alvorligt. Hvert “appen skal fungere offline” koster rigtige penge.
Rammer og antagelser. Budgetspænd, ønsket tidsplan, hvem hos jer der træffer beslutninger, og hvad der skal ske efter lanceringen (drift og vedligeholdelse, videreudvikling).

Fejlene der gør tilbud umulige at sammenligne

Når tre tilbud på den samme specifikation afviger fra hinanden med en faktor tre, er det som regel specifikationen, ikke leverandørerne, der er problemet. De mest almindelige årsager:

Funktioner uden prioritering. Hvis alt virker lige vigtigt, prissætter én leverandør det hele og en anden et rimeligt udvalg, og beløbene bliver umulige at sammenligne.
Usynlige integrationer. “Integration med vores ERP-system” uden oplysning om hvilket system, hvilken version og om der findes et API. Én leverandør går ud fra det enkle, en anden tager højde for det svære.
Løsningskrav forklædt som behov. “Appen skal have en chatfunktion”, eller er behovet at brugerne hurtigt får svar? Måske er en FAQ plus notifikationer nok. Beskriv behovet, og lad løsningen være åben.
Udefinerede begreber. “Enkel administration”, “høj sikkerhed”, “hurtig”. Sæt tal eller eksempler på alt hvor det er muligt: Hvad skal en administrator kunne gøre, hvilke data er følsomme, hvor hurtigt er hurtigt?
Ingen oplysninger om hvad der findes. Eksisterende design, visuel identitet, backend, konti? Det der allerede findes, skal ikke prissættes igen.

En god test: Kan to personer læse specifikationen og tegne nogenlunde den samme app på en whiteboard? Hvis ikke, så gør flowene tydeligere.

Det rette detaljeniveau i den rette fase

Kravspecifikationen er ikke et dokument der bliver færdigt én gang. Detaljeniveauet skal vokse med projektet:

Idéfasen: én side. Problem, målgruppe, forretningsidé. Det er nok til at teste idéen på kolleger og få grove prisindikationer.
Tilbudsfasen: 5–15 sider efter skabelonen ovenfor. Klare flows og rammer, åben løsning. Det er her sammenligneligheden afgøres.
Opstartsfasen: Specifikationen brydes ned sammen med den valgte leverandør til en prioriteret backlog, skitser og tekniske beslutninger. Nu må detaljerne komme, med udviklernes og designernes viden i rummet.
Under udviklingen: Kravene forfines etape for etape. At detaljere flow 8 før flow 1 er bygget, er spild. I kommer til at lære ting der ændrer planen.

At skrive hele den detaljerede specifikation på forhånd føles trygt, men bygger på illusionen om at I allerede ved alt. De bedste projekter låser målbilledet tidligt og detaljerne sent.

Kom i gang

Start med formål, målgruppe og de fem vigtigste flows. Det er 80 procent af værdien. Vil du have et ekstra sæt øjne på din kravspecifikation eller hjælp til at udarbejde den gennem en kort forundersøgelse? Vi hos Weapp gør det jævnligt for kunder, fra MVP’er til store systemapps. Kontakt os, så kigger vi på den sammen.

Ofte stillede spørgsmål

Hvor lang skal en kravspecifikation være?

Til tilbudsfasen er 5–15 sider som regel nok. Er den kortere, bliver tilbuddene gæt; er den længere, er du sandsynligvis begyndt at designe løsningen for leverandøren. Detaljerne vokser derefter frem i løbet af projektet, flow for flow, sammen med det team der bygger.

Har jeg brug for skitser eller design i kravspecifikationen?

Enkle skitser af de vigtigste skærmbilleder, også håndtegnede, hjælper mere end lange tekstbeskrivelser. De viser hvad du mener, og afslører huller i tankegangen. Men bestil ikke færdigt design før leverandøren er valgt. Designet er en del af det arbejde du køber, og formes bedst i fællesskab.

Hvad er ikke-funktionelle krav?

Krav til hvordan appen skal fungere snarere end hvad den skal gøre: ydeevne, tilgængelighed, sikkerhed, overholdelse af GDPR, adfærd offline, skalerbarhed og hvilke platformsversioner der skal understøttes. De bliver ofte glemt i kravspecifikationer, men driver en stor del af omkostningen, så leverandører der ikke får dem, antager forskellige ting.

Skal jeg kræve en bestemt teknologi i kravspecifikationen?

Kun hvis du har en reel grund, f.eks. en eksisterende kodebase eller interne kompetencer der skal stå for drift og vedligeholdelse. Ellers: Beskriv behovet, og lad leverandørerne begrunde deres teknologivalg i tilbuddet. Hvordan de ræsonnerer om valget, siger meget om deres seniority, og du undgår at låse dig fast på den forkerte løsning.

Kan leverandøren hjælpe med at skrive kravspecifikationen?

Ja, mange bureauer tilbyder forundersøgelser hvor kravbilledet arbejdes frem i fællesskab. Det giver ofte en bedre specifikation end at skrive den alene, men lav den hos en part som du kan forestille dig ikke at bruge til selve udviklingen. Ellers bliver specifikationen let formet efter netop deres løsning. Ejerskabet af dokumentet skal være dit.