Artikel top billede

Tjekliste: Sådan kommer du i gang med at skrive kravspecifikation

Et af de mest vitale områder for dit it-projekt er kravspecifikationen. Men det er ikke nogen let øvelse at mestre. Læs her, hvordan du lægger gnidningsfrit fra land.

Læs også:

Sådan udarbejder du den perfekte krav-specifikation.

Her er fem håbløse fejl i din kravspecifikation.

Styrelse dropper kravspecikationer: Satser på agil udvikling.

Sådan får du den bedste udviklingskontrakt.

Vil du undgå, at dit næste it-projekt pludselig befinder sig på dybt vand midt i en orkan af jurister, fordi der ikke var styr på kravene, så er det helt centralt, at du laver et grundigt stykke forarbejde.  

Hvad enten det er kunden, der skal formulere, hvad han ønsker, eller det er leverandøren, som skal tilpasse et standard-systemet, er kravspecifikationen helt vital.

Alfa og omega

"Jo færre misforståelser og dermed ændringer til krav, du har undervejs - desto mere jævn og glidende udvikling får du. Kravspecifikationer er alfa og omega," siger Otto Vinter, der betegner sig som software engineering-mentor.

Kravspecifikationen er grundlaget for hele dit it-projekt og skal kort fortalt sige så præcist som muligt, hvad du har behov for, at systemet skal kunne.

"Det er begyndelsen på det hele. Den afklarer, hvad der skal udvikles, men er også grundlaget for at kunne sætte en tidsramme og pris," lægger Otto Vinter ud.

Men før du overhovedet begynder at liste kravene op til it-løsningen, skal du først finde ud af, hvad du har brug for.  

Grundigt forarbejde

Det kan være svært bare at sætte sig ned og skrive kravene fra en ende af.

"Det lyder mærkværdigt, at du ikke bare kan skrive ned, hvad det er for nogle krav, du vil have opfyldt. Men du kan simpelthen ikke gætte dig til dem alle. Du får ikke det hele med, og du risikerer også at skrive dem på en måde, der kan misforstås," siger Otto Vinter, og tilføjer: 

"Der sker tit fejl, fordi man ikke har brugeren i fokus. Det kan være nogle helt banale ting, som gør, at det har en anden betydning for brugerne, end de, som skal udvikle det, tillægger det. Om en bestemt ting står oppe i højre hjørne på skærmbilledet eller nede i venstre hjørne kan være en verden til forskel for brugeren." 

Derfor skal du lave et grundigt forarbejde i stedet for bare at liste kravene op.

Dette skal du igennem inden den endelige kravspecifikation

Her kommer et bud på, hvordan dit indledende arbejde kan se ud. 

Begynd med scenarier
Først kan du begynde med at udarbejde såkaldte scenarier.

Scenarierne handler om at beskrive den arbejdssituation eller -gang, der ønskes it-understøttet.

"For mig er scenarier karakteristiske ved, at vi ikke tager stilling til, hvor it-grænsefladen ligger. Vi beskriver bare, hvordan arbejdet vil blive udført i praksis. Denne øvelse er meget central at få gennemgået, hvad enten det ender med use cases, stories eller noget helt tredje," siger han. 

Med denne øvelse får du relateret brugeres behov til brugssituationem.

Du bør ved hvert scenarie først definere: Formålet med opgaven, omgivelserne og hvem, der udfører opgaven. Selve arbejdsopgaven beskrives dernæst som en fortælling, nærmest en lille novelle, fra start til slut.

Efterfølgende kan man finde ud af, hvor it-grænsefladen optimalt set bør placeres, og dermed nå frem til at opstille kravene.  

Usabilitytests 

Når du har lavet dine scenarier og bestemt, hvor it-grænsefladen nærmere skal ligge, kommer vi til usability eller brugertests.  

Du starter ud med at lave en simpel prototype ud fra de scenarier, du har skrevet ned.

Prototypen tester du med tre brugere:

"Der er videnskabeligt belæg for, at hvis du har tre brugere med, finder du cirka 60 procent af problemstillingerne. Det er sådan en kurve, der starter stejlt og derefter flader mere og mere ud jo flere brugere, du tester den på. Derfor skal du minimum teste den med tre personer," siger Otto Vinter. 

Med den viden du nu har fået, reviderer du prototypen (og eventuelt scenariet) og tester igen med nye brugere. 

Erfaringen viser, at du skal gennemføre hele testseancen mindst tre gange.

"Jeg kan ikke sige andet end, at det er min erfaring. Den første prototype virker bare ikke. Næsten den første bruger vil få dig til at bryde hulkende sammen." 

"Ved nummer to kommer realismen ind, og her har man forsøgt at lave det rigtigt og taget højde for brugerens ønsker." 

"Den tredje er i virkeligheden en kontrol, af at du nu har forstået det rigtigt."

Du skal gerne frem til, at der i tredje omgang faktisk ikke er særlig mange problemstillinger, men hvis der stadig er, er du nødt til at revidere prtotypen igen, og så kører man selvfølgelig testen en gang til. 

Med disse tests er du i stand til at tjekke, om brugerne rent faktisk vil være i stand til at løse de fremtidige arbejdsopgaver med den it-løsningen, du har forestillet dig.  

Det belønner sig med et grundigt forarbejde.

På dette tidspunkt, efter du har udarbejdet scenarier og prototyper, laver du typisk den endelige kravspecifikation.

Her belønner det sig at have lavet et grundigt stykke forarbejde.

"Gevinsten er meget tydelig med et grundigt forarbejde. Du har for eksempel næsten fået defineret brugergrænsefladen og kan i rigt mål referere til de skærmbilleder og præsentationsformer, du brugte i prototyperne," siger Otto Vinter og tilføjer:     

"Jeg ved godt, at der er mange, der tænker hold da op - jeg skal bare skrive en kravspecifikation og så må leverandøren finde ud af resten. Men den holdning funger ikke i praksis. Det er i hvert fald ikke professionelt at gøre det på den måde," afslutter han.

Læs også:

Sådan udarbejder du den perfekte krav-specifikation.

Her er fem håbløse fejl i din kravspecifikation.

Styrelse dropper kravspecikationer: Satser på agil udvikling.

Sådan får du den bedste udviklingskontrakt.




Brancheguiden
Brancheguide logo
Opdateres dagligt:
Den største og
mest komplette
oversigt
over danske
it-virksomheder
Hvad kan de? Hvor store er de? Hvor bor de?
Ed A/S
Salg af hard- og software.

Nøgletal og mere info om virksomheden
Skal din virksomhed med i Guiden? Klik her

Kommende events
Compliance og strategisk it-sikkerhed efter DORA

Finansielle koncerner har i snit 85 sikkerhedsløsninger i drift – men er i snit op til 100 dage om at opdage et igangværende cyberangreb. Ydermere viser øvelser, at det typisk tager 4-6 uger at rense og genetablere sikker drift af centrale systemer efter et stort angreb. Fokus for dagen vil derfor være på henholdsvis governance samt om, hvordan du som it-leder i den finansielle sektor skal kunne håndtere fremtidens cybertrusler og arbejde effektivt med sikkerhed på et strategisk niveau.

04. april 2024 | Læs mere


EA Excellence Day

Hvad er det, der gør it-arkitektens rolle så vigtig? Og hvad er det for udfordringer inden for områder som cloud, netværk og datacentre, som fylder hos nogle af landets bedste it-arkitekter lige nu? Det kan du her høre mere om og blive inspireret af på denne konference, hvor du også får lejlighed til at drøfte dette med ligesindede.

16. april 2024 | Læs mere


IAM - din genvej til højere sikkerhed uden uautoriseret adgang og datatab

På denne dag udforsker vi de nyeste strategier, værktøjer og bedste praksis inden for IAM, med det formål at styrke virksomheders sikkerhedsposition og effektiviteten af deres adgangsstyringssystemer og dermed minimere risikoen for uautoriseret adgang og datatab. Og hvordan man kommer fra at overbevise ledelsen til rent faktisk at implementere IAM?

18. april 2024 | Læs mere