Kravspecifikation: sådan skriver du en (gratis skabelon)

En kravspecifikation er et dokument der beskriver hvad et system skal kunne, hvem der skal bruge det, og hvilke rammer det skal bygges inden for. En god kravspecifikation beskriver problemet og brugernes opgaver, ikke skærmbilleder og teknologi, og den er præcis nok til at flere udviklere kan give en pris på det samme. Skabelonen herunder er bygget på de spørgsmål jeg selv stiller i et forprojekt, så du kan bruge den direkte når du indhenter tilbud.

Jeg er freelanceudvikler, så jeg sidder typisk i den anden ende og læser kravspecifikationer. Rådene er skrevet derfra: hvad der gør et dokument let at sætte pris på, og hvad der får en udvikler til at lægge en buffer i tilbuddet.

Den korte version: hvor detaljeret skal den være?

Sidetallene er mit grove skøn, ikke en regel. Til de fleste projekter i små og mellemstore virksomheder er den midterste kolonne det rigtige niveau, og det er den skabelonen er lavet til. Kravspecifikationen hører til den første fase af et udviklingsprojekt, og du kan se hele forløbet i min guide til hvordan et softwareprojekt foregår fra idé til drift.

Hvad en kravspecifikation er, og hvad den ikke er

En kravspecifikation samler kravene til et system ét sted. Kravene falder i to grupper. Funktionelle krav beskriver hvad systemet skal kunne, fx at en kunde kan se sine fakturaer. Ikke-funktionelle krav beskriver hvordan det skal fungere: hvor hurtigt, hvor sikkert, hvor data skal ligge, og hvad der sker hvis noget går ned.

Strukturen er ikke opfundet til lejligheden. Den internationale standard for kravarbejde hedder ISO/IEC/IEEE 29148 og har afløst den ældre IEEE 830, som mange skabeloner på nettet stadig bygger på. I det offentlige er kravspecifikationen typisk et bilag til Digitaliseringsstyrelsens standardkontrakter, fx K02 til længerevarende it-projekter. Begge dele er for tunge til et projekt i en mindre virksomhed, men grundelementerne er de samme.

Tre ting er en kravspecifikation ikke:

• Et design. Skitser og skærmbilleder kan ligge som bilag, men kravene skal kunne forstås uden dem.
• Et teknisk valg. Skriver du at systemet skal bygges i et bestemt framework, får du tilbud fra dem der kan det, ikke nødvendigvis fra dem der løser opgaven bedst. Valget mellem fx Laravel og Next.js bør ligge hos udvikleren, medmindre I har en konkret grund som et eksisterende team.
• En kontrakt. Den bliver typisk et bilag til aftalen, men den erstatter ikke aftalen om pris, ejerskab og ansvar.

Hvor detaljeret dokumentet skal være, afhænger også af hvordan projektet skal køre. I et agilt forløb er det kortere fordi detaljerne bliver afklaret undervejs. Jeg har sammenlignet de to tilgange i agil udvikling vs. vandfald.

Skabelonen: 10 afsnit og spørgsmålene til hvert

Kopiér overskrifterne ind i et tomt dokument, og svar på spørgsmålene under hver. Du behøver ikke kunne svare på alt. Et ærligt "ved ikke endnu" er mere værd end et gæt fordi det viser udvikleren hvor der skal spørges ind.

1. Baggrund og formål

Beskriv problemet som det ser ud i dag. Det er det afsnit udvikleren læser først, og det farver hvordan resten bliver forstået.

• Hvad er problemet, og hvem mærker det?
• Hvad koster det i dag i timer, fejl eller tabte kunder? Et groft skøn er fint.
• Hvordan kan I om et år se at projektet er lykkedes?

2. Brugere og roller

Brugerne er grundlaget for login og rettigheder, og de påvirker en stor del af prisen.

• Hvilke typer brugere er der, fx kunder, medarbejdere og administratorer?
• Hvor mange er der cirka af hver, i dag og om to år?
• Hvad må hver rolle se, oprette, rette og slette?
• Sidder de ved en computer på kontoret eller står de med en telefon ude hos en kunde? Svaret afgør om løsningen skal være en webapp, en app eller en PWA, som jeg har sammenlignet i webapp vs. app vs. PWA.

3. Arbejdsgange i dag

Beskriv hvordan arbejdet foregår nu, trin for trin. Her gemmer de skjulte krav sig: den mail der altid bliver sendt, eller det regneark som én person holder styr på.

• Hvilke værktøjer bruger I i dag: regneark, mails, papir eller et ældre system?
• Hvordan ser en typisk opgave ud fra start til slut?
• Hvad virker godt og skal bevares?

4. Funktionelle krav med prioritet

Skriv hvert krav som en handling: hvem skal kunne gøre hvad, og hvorfor. Giv kravene numre (K1, K2, K3), så du og udvikleren kan henvise til dem. Formen minder om user stories, og et krav kan sagtens blive delt op i flere af dem senere.

Et eksempel: "K7, skal med: En medarbejder skal kunne markere en opgave som udført på telefonen, så kontoret kan fakturere samme dag."

Marker hvert krav som skal med, bør med eller kan vente. Det er en forenklet udgave af MoSCoW-metoden, som anbefaler at de nødvendige krav typisk højst fylder ca. 60 % af indsatsen.

5. Data

Data er ofte den dyreste del at få på plads, og den der lettest bliver glemt.

• Hvilke oplysninger skal systemet gemme, fx kunder, ordrer, dokumenter eller billeder?
• Er der persondata, og er nogle af dem følsomme?
• Skal eksisterende data flyttes over? Hvor meget, fra hvilket system, og hvor rodet er det?
• Hvor længe skal data gemmes, og hvem skal kunne trække dem ud?

6. Integrationer

Lav en liste over de systemer løsningen skal tale med. En integration kan tage fra få timer til flere uger, afhængigt af hvad det andet system giver adgang til.

• Hvilke systemer: økonomisystem, CRM, betaling, login eller lager?
• Skal data gå én vej eller begge veje, og hvor ofte?
• Har systemet et dokumenteret API, og har I adgang til det? Ved du det ikke, så skriv systemets navn og version, så kan udvikleren undersøge det.

7. Sikkerhed, hastighed og drift

Det er de ikke-funktionelle krav. De lyder kedelige, men de kan ændre både opbygningen og prisen.

• Skal data ligge i EU på grund af GDPR, kundekrav eller jeres branche?
• Hvor slemt er det hvis systemet er nede en time? En hel dag?
• Hvor mange brugere er der på samme tid når der er travlest?
• Er der krav om totrinsbekræftelse ved login, log over hvem der har gjort hvad, eller tilgængelighed for brugere med handicap? Sælger du til forbrugere online, kan der være lovkrav om webtilgængelighed. Spørg en rådgiver hvis du er i tvivl.

8. Afgrænsning: hvad er ikke med

Skriv det ned som ikke skal med i denne omgang. Afsnittet sparer flere diskussioner end noget andet fordi alle kan se at det er et fravalg og ikke en forglemmelse.

• Funktioner der er skubbet til en senere fase
• Platforme der ikke er med, fx en app til iOS og Android
• Opgaver I selv står for, fx tekster, billeder eller oprettelse af data

9. Budget, tidsplan og beslutninger

Det er fristende at udelade budgettet for ikke at afsløre for meget. Det er en fejl. Uden en ramme kan udvikleren ikke vurdere om du skal have en enkel eller en grundig løsning, og så får du tilbud der ikke kan sammenlignes. Har du ingen fornemmelse af niveauet, så start med min gennemgang af hvad softwareudvikling koster.

• Hvilket budgetinterval arbejder I med?
• Er der en deadline, og hvad sker der hvis den skrider?
• Hvem træffer beslutningerne, og hvor meget tid kan den person bruge om ugen?

10. Efter lancering

Et system skal holdes ved lige når det er sat i drift. Beskriv hvad I forventer.

• Hvem står for hosting, opdateringer og backup?
• Hvilken hjælp forventer I når der opstår fejl, og hvor hurtigt?
• Hvem ejer koden, og hvilken dokumentation skal I have ved overlevering? Min holdning er at kunden skal eje koden fra første dag.

Læg til sidst bilag ved: eksisterende materiale, skitser, skærmbilleder af de systemer I bruger i dag, og eksempler på løsninger I godt kan lide.

Sådan udfylder du skabelonen i seks trin

1. Start med formålet. Skriv afsnit 1 færdigt før du skriver et eneste krav. Kan du ikke beskrive problemet i et par sætninger, er det for tidligt at liste funktioner.
2. Tal med dem der skal bruge systemet. Gå arbejdsgangen igennem med to eller tre af dem, gerne ved skærmen mens de arbejder. De nævner ting som ledelsen ikke ved findes.
3. Skriv alle ønsker ned, og sortér bagefter. Når listen er komplet, giver du hvert krav en prioritet. Ender mere end halvdelen som skal med, har du ikke prioriteret listen, kun omdøbt den.
4. Gør kravene konkrete. Erstat de vage ord med noget der kan afprøves, som i boksen ovenfor. Det er her de fleste misforståelser bliver fanget.
5. Saml de åbne spørgsmål ét sted. Det du ikke ved, skal stå som et spørgsmål og ikke skjules i en formulering der lyder sikker. Så kan udvikleren svare på det i tilbuddet i stedet for at gætte.
6. Lad en udenforstående læse dokumentet. Bed en kollega der ikke kender projektet, om at forklare dig hvad systemet skal kunne. Det kollegaen misforstår, vil en udvikler også misforstå.

Sådan bruger du dokumentet til at indhente tilbud

Kravspecifikationens vigtigste opgave er at gøre tilbuddene sammenlignelige. Det kræver at alle får det samme grundlag og bliver bedt om det samme.

• Send den samme version til alle, og del svar på spørgsmål med alle, ikke kun med den der spurgte.
• Bed om at tilbuddet henviser til kravnumrene, så du kan se hvad der er med, og hvad der ikke er.
• Bed om én pris på de krav der skal med, og én pris på det hele. Så ved du hvad det koster at starte småt.
• Læg mærke til spørgsmålene. En udvikler der stiller gode spørgsmål, har læst dokumentet. En der sender en pris efter en time uden at spørge om noget, har sandsynligvis gættet eller lagt en buffer ind.

Er priserne meget forskellige, er det ofte et tegn på at dokumentet kan læses på flere måder. Så er det tid til at præcisere, ikke til at vælge den billigste.

Hvornår du ikke skal skrive den selv

Skabelonen passer ikke til alle situationer. Her er tre hvor du er bedre stillet uden:

• Når du ikke kender problemet godt nok endnu. Så er et betalt forprojekt med en udvikler bedre fordi spørgsmålene afslører huller du ikke selv kan se. Jeg laver selv forprojekter til fast pris før større opgaver, og resultatet er netop den slags kravspecifikation skabelonen lægger op til.
• Når opgaven er lille. Til en afgrænset opgave på få dage er en mail med problemet, et eksempel og en deadline nok.
• Når et standardsystem kan dække behovet. Så er en kort liste over krav til at sammenligne færdige systemer mere nyttig end en kravspecifikation til udvikling.

Du kan også sagtens kontakte en udvikler uden en kravspecifikation. En kort beskrivelse af problemet er nok til en første snak.

Næste skridt

Når skabelonen er udfyldt, så gå tjeklisten igennem før du sender dokumentet ud.

På min prisside kan du se hvordan jeg arbejder med et forprojekt til fast pris, og hvordan det fører til en fast pris på selve projektet.

Ofte stillede spørgsmål

Hvem skal skrive kravspecifikationen, kunden eller udvikleren?+

Begge dele, men du ejer indholdet. Du kender forretningen, brugerne og problemet, mens udvikleren ved hvilke tekniske spørgsmål der skal besvares. Den mest effektive vej er ofte at du skriver et første udkast med skabelonen, og at udvikleren gør det færdigt i et forprojekt. Sørg for at aftalen giver dig retten til resultatet, så du kan bruge det hos andre.

Hvor lang tid tager det at skrive en kravspecifikation?+

Til et typisk projekt i en mindre virksomhed skal du regne med nogle dages arbejde fordelt over et par uger. Selve skrivningen går hurtigt. Det der tager tid, er at tale med brugerne, finde svar på spørgsmål om data og integrationer og træffe beslutninger om prioritering. Går der måneder, er det et tegn på at du skriver løsningen i stedet for at beskrive problemet.

Er en kravspecifikation juridisk bindende?+

Ikke i sig selv, men den bliver det ofte i praksis, når den lægges som bilag til kontrakten. Så er den en del af det udvikleren har lovet at levere, og ændringer skal aftales og prissættes. Det er endnu en grund til at kravene skal være konkrete og til at afgrænsningen skal stå sort på hvidt. Få en advokat til at se på selve kontrakten ved større projekter.

Kan jeg bruge AI til at skrive kravspecifikationen?+

Ja, til struktur og formuleringer, men ikke til indholdet. En AI-assistent kender ikke jeres arbejdsgange, jeres data eller jeres prioriteter, og den kan fylde dokumentet med generiske krav der ser grundige ud, men ikke passer til jer. Brug den hellere til at finde huller, fx ved at bede den foreslå spørgsmål som en udvikler ville stille til dit udkast.