Artikel top billede

Sådan udarbejder du den perfekte krav-specifikation

Vil du undgå, at dit næste it-projekt pludselig invaderes af advokater med kontrakter, paragraffer og trusler om sagsanlæg, så læs med her.

Når først kunden og leverandørens advokater har taget over på et it-projekt, fører det oftest til en lang kamp i bokseringen med venstrehooks, uppercuts og jabs i form af juridiske paragrafer, kontrakter og sagsanlæg.

Det var for eksempel tilfældet med Amanda, der næsten er gået hen og blevet synonym med it-skandale.

Projektet gav store forsinkelser, arbejdsnedlæggelser og gensidige trusler om sagsanlæg mellem Arbejdsmarkedsstyrelsen og CSC, der stod for udviklingen.

Et af konfliktpunkterne var kravene til systemet, som blev fortolket på en måde af leverandøren og en anden af kunden. I sidste ende førte det til et besværligt og ustabilt system, som dog i store træk levede op til de opsatte krav.

Men med en ordentlig forarbejdet kravspecifikation, kan du dog et lang stykke hen ad vejen sørge for, at du aldrig ender i den juridiske boksemølle.

Kravspecifikationen er alfa omega

For den berygtede kravspecifikationen er, hvad sjippetorvet er for bokseren, nemlig helt uundværligt.

"Kravspecifikationer er alfa omega. Vi kan estimere prisen og tiden forkert, men hvis vi ikke ved, hvad det er, vi skal lave, så er vi rigtig på herrens mark. Så kommer alle juristerne rendende," siger Otto Vinter, der betegner sig som software engineering-mentor.

Otto Vinter er også ansat som ekstern lektor på masteruddannelserne i projektledelse og procesforbedring ved Roskilde Universitet. Han fortæller at hans kursister måber, når de ser, hvad en kravspecifikation bør indeholde.

"Når jeg viser dem, hvad der skal stå i en IEEE standard 830 kravspecifikation, bliver de forbløffede og siger 'så meget, så detaljeret?'," siger han, og følger selv op med svaret:

"Ja venner, det fylder en bondegård og en helvedes masse arbejde, og alligevel har I ikke sikkerhed for, at det holder."

Dette er den største fejlkilde

Du skal vide, hvad der skal laves

Men ifølge lektoren er der ingen smutveje, når man skal til at gå i gang med et it-udviklingsprojekt. Du bliver simpelthen nødt til at vide, hvad det er, der skal laves. Det er hele grundlaget for projektet:

"Kravspecifikation er en forudsætning for, at du kan lave en nedbrydning af, hvad der skal leveres. Ved at dele det op i arbejdspakker og aktiviteter kan vi styre projektet, og derved lave en tidsplan og i virkeligheden også komme med et tilbud. Man må derfor sige, at kravspecifikationen er yderst central."

Og hvis du fra start af ryster på hænderne, ja så er det ikke nemt at ramme plet.

"Hvis du har en 'shaky' kravspecifikation, som er formuleret vattet og usikker, hvordan kan man så lave den videre nedbrydning af aktiviteter eller komme op med en holdbar løsning?"

Leverandøren kan selvfølgelig begynde at gætte.

"Ja, de kan da være heldige at gætte rigtigt. Men i praksis viser det sig, at kunden ikke altid ved, hvad han vil have. Der er altid et hjørne, hvor kunden bevidst eller ubevidst har udtrykt sig vagt eller på en måde som kan misforstås," siger han og forsætter:

"Når leverandøren kører på med en misforståelse, og man kommer til en accepttest, vil kunden i værste tilfælde stille sig forurettet op og sige, 'det har jeg da aldrig sagt eller ment'."

Største fejlkilde er misforståelser

Vil du undgå at projektet ender i tolvte runde og juristerne skal tælle pointen sammen i form af brudte aftaler, krav og paragraffer, så handler det blandt andet om at fjerne misforståelserne i kravspecifikationen.

"For en del år siden lavede professor Søren Lauesen og jeg en undersøgelse, der viste, at den største fejlkilde i it-systemer skyldes misforståelser mellem dem som skrev kravspecifikationen, og dem som skal lave it-systemet. Det er selvfølgelig på alle niveauer, og er både fra kunde- og leverandørsiden," siger han.

Det er tilsyneladende stadigvæk sådan, mener Otto Vinter:

"Jeg har ikke lavet eller set andre undersøgelser af fejlkilder siden. Min fornemmelse er dog stadigvæk, at hvis du tager en vilkårlig kravspecifikation i hænderne, skal du ikke mere end fem linjer ned, før du siger 'hvad pokker mener de her?'."

Ramme plet med lukkede øjne

Og det forværrer problemet, hvis du ikke kan gribe telefonen og ringe til kunden og få en forklaring.

"Hvis det er en fleksibel kontrakt, og man har mulighed for løbende kontakt med kunden, så kan en dårlig og spinkel kravspecifikation måske godt gå. Men tager vi for eksempel EU-udbud, har du som leverandør ikke mulighed for at spørge kunden - for det kan give unfair konkurrence."

I nogle tilfælde skal leverandøren derfor forsøge at ramme plet med lukkede øjne.

"Hvad gør man som leverandør, når man ikke præcist ved, hvad kunden vil have, og man ikke har kommunikationen. Ja man forsøger at lægge en sikkerhedsbuffer eller noget andet ind. Men i virkeligheden beder og håber man på, at det her kommer til at gå godt, og at ens tilbud er lavere end de andres," siger Otto Vinter.

Her ligger ansvaret

Og hvis ansvar er det så?

Kravspecifikationen burde sætte klare retningslinjer op for et it-projekt og på den måde styrke samarbejdet - i sidste ende er det kundens ansvar.

"Det er kundens ansvar at lave en fornuftig og god kravspecifikation fra start. Det er den, der skal klargøre reglerne eller mangel på samme i det fremtidige system, og få klargjort, hvad det er, de vil have," mener Otto Vinter, der samtidig tilføjer:

"Jeg synes derfor, det er ligeså vigtigt, at leverandøren påtager sig et ansvar. Det hedder at tjekke kravspecifikationen for huller, uklarheder og krav, som kun svært kan lade sig gøre," fremhæver han.

Her er et paradoks

På den anden side skal man også passe på med regler, begrænsninger og krav. Det skal heller ikke ende med det rene fedtspil på egen banehalvdel, hvor man lurer på, at den anden begår fejl først.

"Kunden vil selvfølgelig gerne have, at leverandøren kommer med den mest moderne, bedste og nyeste teknologi. Derfor bliver nogle kravspecifikationer lidt bløde i kanterne - man lader vær med at tage stilling til for meget, for dermed ikke at udelukke geniale løsninger," siger Otto Vinter.

Men hvis leverandøren ikke kan læse og forstå, hvad brugerne og kunden i virkeligheden vil have, er det gift for leverandøren.

Dette paradoks - at kunden på den ene side gerne vil have innovative og geniale løsninger, men på den anden side vil have hånd i hanke med systemet - løses meget simpelt ved for det første at lave den 'gode' kravspecifikation.

Det handler for eksempel om at beskrive rationalet bagved hvert krav.

"Det vil sige, hvorfor vil jeg som kunde have det her? Herved kan leverandøren nemlig ledes til at forstå bevæggrunden eller rationalet for kundens krav og dermed bedre forstå, hvad det reelt er kunden vil have," forklarer han.

Det skaber bedre afklaring og bedre kommunikation mellem parterne.

"Med en 'god' kravspecifikation bliver det også nemmere for leverandøren at stille intelligente spørgsmål og komme på bølgelængde med kunden, og det er meget vigtigt for at få succes med udviklingsprojekter," siger han.

Vi skal lære at lave 'gode' krav

Derfor er det ikke specielt brugbart bare at sætte sig ned og gætte på, hvad der skal være i en kravspecifikation.

"Kunden er nødt til at have nogle teknikker, redskaber og folk, der hjælper dem med at forbedre kravspecifikationerne. Det kan godt være, de i sidste ende stadig skal være på tekstform og godkendt af kammeradvokaten og alt det der," siger Otto Vinter og pointerer:

"Men det betaler sig i sidste ende, hvis kunden får afklaret de ting, der kan give anledning til misforståelser."

Problemstillingen er ikke anderledes, hvis vi taler om et mere agilt projekt.

"Præcisionen i krav er nøjagtig den samme, hvad enten du arbejder med 3000 siders kravspecifikation eller arbejder med stories til et sprint - forstår jeg hvad kunden reelt siger?"

Konsekvenser er måske bare lidt mindre, når man arbejder i sprints på for eksempel en måned i et agilt projekt.

Men ikke desto mindre er du godt på vej mod en svingende knock-out, hvis du ikke får styr på din kravspecifikation.

"Jo færre misforståelser og ændringer til krav, du har undervejs - desto mere jævn glidende udvikling får du. Så ja, kravspecifikationer er alfa og omega,"




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?
Targit A/S
Udvikling og salg af software til business intelligence.

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

Kommende events
Computerworld Summit 2021

En moderne digital vindervirksomhed bringer nye teknologier i spil, skaber digital innovation, udnytter data som styringsværktøj og ser verden som én stor markedsplads. Men succes kræver, at du ved, hvor den dyre teknologi kan gøre den største forskel i forretningen. Den kræver, at du ved i hvilken retning den øgede politiske regulering af teknologi og data bevæger sig hen. Og den succes kræver, at du kan udnytte teknologien til at automatisere og skalere til gavn for bundlinjen og budgettet.

26. oktober 2021 | Læs mere


CIO Trends 2021: Sådan ser teknologiradaren ud hos Danmarks bedste CIOs

Teknologien i virksomheder spiller i den grad en større og større rolle, hvor vi er nødt til at stille endnu større krav til, hvordan vi udnytter den, og hvilke muligheder den giver. Spørgsmålet er dog, hvordan man formår at lede en virksomhed, der konstant skal forholde sig til teknologiens forandringer.

16. november 2021 | Læs mere


How to Sikkerhed: Awareness, email fraud og phishing

Man kan aldrig vide sig sikker, for uanset hvor godt man sikrer sig mod hackerangreb og anden svindel, vil hacker næsten altid være et skridt foran. De går efter organisationernes svageste led i håbet om at kunne snyde sig til data, penge eller andet værdifuldt. Få derfor konkrete bud på, hvordan du kan gribe opgaven an og understøtte et effektivt awareness-niveau i din organisation med enkel, men velfungerende, teknologi.

17. november 2021 | Læs mere