Sådan laver du en kravspecifikation – Eksempel og en PDF til download

Du har en ide, en rigtig god en. Du skal have det udviklet og tager derfor fat i en udvikler.

Når jeg som udvikler modtager projektbeskrivelser, er det ofte op til mig at vurdere hvordan projektet faktisk skal være og ofte komme med en pris baseret på en 15 minutters telefonsamtale og et par mails.

Kunden har en ide og kan forestille sig det hele i hovedet. Han kan fortælle, tegne m.m. og har gået med ideen i flere måneder. Jeg har fået 15 minutter i en telefonsamtale til at få samme billede af ideen.

Kan du se hvordan problemer opstår?

Løsningen er en kravspecifikation! Jeg vil her forsøge at demonstrere processen, med meget enkelt eksempel (som sagtens kunne være rigtigt), på hvad kunden fortæller de vil have, hvad udviklerne hører de vil have og hvad de får. Det er næsten altid dét udvikleren hører, de også får.

Udviklere kan sagtens spørge ind til opgaver og det gør vi generelt også, men vi spørger ikke ind til hver enkelt detalje, fordi så bliver vi simpelthen aldrig færdige med at finde ud af hvad der skal laves.

Og vi spørger ikke om dét vi ikke ved vi skal spørge om!

En god kravspecifikation kan tage lang tid at lave men den kan være med til at sikre en gensidig forståelse (hvis du vel og mærke kan formulere din idé på skrift).

Lad os springe ud i et eksempel, for det er trods alt nemmest at jeg viser hvad jeg vil fortælle, fremfor at du bare får at vide “det skal være en god kravspecifikation”.

You get the point…🙃

“Et meget enkelt brugersystem”

Kunden beskriver opgaven som et meget enkelt brugersystem hvor kundens besøgende kan logge ind. Når de er logget ind, kan de så læse og kommentere
på indholdet.

Første spørgsmål jeg som udvikler kunne finde på at spørge om er, om hver bruger skal have deres eget login. Det skal de selvfølgelig, men igen gentager kunden den simple opgave:

  1. Login
  2. Se indhold
  3. Kommentér

That’s it!

For mig, som udvikler, er tankerne nu noget i retning af, at det egentlig bare er en kodeordsbeskyttet side, som kunden vil have. De skal derfor bare have en mulighed for at oprette en bruger, angive et kodeord (som de så sender ud til brugerne, som de må have en liste et sted) og man skal først kunne se indholdet af siden, når man er logget ind. NEMT! 🤣

3 timer og det vil være klaret!

I systemer som WordPress er det her nemt at lave fordi det, mere eller mindre, er standardfunktionalitet. Men ser vi lige bort fra dét, så er opgaven stadig nem nok at lave i de fleste systemer.

Der aftales med kunden at opgaven bliver lavet og at den vil tage 3 timer at lave.

Jeg går i gang med arbejdet og efter et par timers kodning er opgaven er nu klar til aflevering og kunden kan kigge løsningen igennem.
Der er brugt 2 timer plus den indledende kommunikation omkring opgaven, så ca. 2½ time i alt. De sidste 30 minutter er normalt afsat til rettelser og lige finpudse enkelte ting.

Nu har kunden har tid til at teste løsningen og sender en mail. (Ofte vil det stå i en lang kompliceret mail og ikke som en punkt liste som her).

  1. Hvad nu hvis kunden har glemt koden, så skal de jo kunne modtage en ny kode.
  2. Jeg kan ikke se hvem der har kommenteret, da folk kun skriver deres fornavn i feltet
    “navn”.
  3. Jeg vil godt have at jeg kan klikke på folks navne og se alle deres kommentarer
  4. Jeg mangler en mulighed for at udelukke folk hvis de skriver en kommentar jeg ikke
    vil have
  5. Den er ikke designet som jeg vil have det, den skal ligne mere den her: [LINK TIL EN ELLER ANDEN SIDE] der ikke har været omtalt tidligere, men indeholder nøjagtig hvad kunden ville have.
  6. Hvordan tilmelder folk sig, så de også kan logge ind?
  7. Jeg vil gerne have at man kan se nogle af siderne uden at man skal være logget ind.

Det blev lige pludselig en helt anden opgave. Opgaven gik fra en simpel 1-2-3 ting til at være en helt anden opgave, hvor timetallet overhoved ikke holder.
Den “nye” opgave er pludseligt en 20 timers opgave og det skal kunden nu have at vide, fordi der var forskellige opfattelser af opgaven.

Den korrekte beskrivelse af opgaven skulle lyde sådan:

Jeg vil gerne have et system, der giver de besøgende på siden mulighed for at oprette en bruger for derefter at kunne se det indhold, der er skjult for personer der ikke er logget ind. Systemet skal også gøre det muligt for brugerne at kommentere på indhold via deres profil. Brugerne skal også have en profil hvor man kan se alle kommentarer, de har lavet.
Som sideejer skal jeg kunne oprette brugere, redigere brugere, slette brugere, udelukke brugere samt se alle kommentarer på siden.

Det er en helt anden opgave end det, kunden oprindeligt beskrev.

Kravspecifikationen

Selvom den nye beskrivelse ovenover er bedre end den oprindelige, så er det ikke nok. Derfor har jeg lavet en skabelon for, hvordan en kravspecifikation kunne se ud for netop den opgave. Den er lavet ret enkelt for at vise hvor meget forskel der er på en normal opgavebeskrivelse og hvordan en kravspecifikation kan se ud.

Den kan du hente her: Kravspecifikation eksempel

I en kravspecifikation er det vigtigt, at du har så mange detaljer med som overhoved muligt. Gerne links og billeder også.

Hvis et punkt ikke står i kravspecifikationen, vil det være umuligt at have det med i et tilbud. Punkter som valg af hostingløsning og minimumskrav dertil kan også være med i en kravspecifikation.

Rigtig god fornøjelse!