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.
