Sådan laver du en kravspecifikation – Eksempel og en PDF til download
Vejen til en succesfuld udviklingsproces, uanset om det drejer sig om software eller fysiske produkter, begynder med en klar og omfattende kravspecifikation. I en verden, hvor ideer florerer og kreativitet blomstrer, er det afgørende at skabe en fælles forståelse mellem kunden og udvikleren / Producenten. For ofte har vi set, hvordan selv de mest velmente projekter kan ende i misforståelser og tidsspilde på grund af mangelfuld kommunikation.
Du har en ide, en rigtig god en. Uanset om det et fysisk produkt eller noget software du skal have lavet, så er en kravspecifikation en god ide. For selvom fysiske produkter er anderledes end software, så kræver det at producenten ved hvad du vil lave og ofte er der ikke stor forskel på hvordan du skal forklare produktet.
I artiklens første del tages der udgangspunkt i software og længere nede hardware.
Når en udvikler modtager projektbeskrivelser, er det ofte op til udvikleren at vurdere hvordan projektet faktisk skal være og ofte komme med en pris baseret på en kort telefonsamtale og et par mails med spørgsmål og svar.
Kunden har en ide og kan forestille sig det hele i hovedet. Personen kan fortælle, tegne m.m. og har gået med ideen i flere måneder, hvor udvikleren har fået måske 15 minutter i en telefonsamtale til at få samme billede af ideen.
Du får hvad modparten tror du vil have
Løsningen er en kravspecifikation! Her vil vi forsøge at demonstrere processen, med et 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 (eller i hvert fald tæt på).
Udviklere kan sagtens spørge ind til opgaver og det gør de generelt også, men de spørger ikke ind til hver enkelt detalje, fordi så bliver man 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 viser hvad man vil fortælle, fremfor at du bare får at vide “det skal være en god kravspecifikation”.
“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 en 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:
- Login
- Se indhold
- Kommentér
That’s it!
For en 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.
Det kunne være en 3 timers udviklings opgave 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.
Udvikleren 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 inden der laver det sidste oprydning i det udviklede og sidste rettelser.
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).
- Hvad nu hvis kunden har glemt koden, så skal de jo kunne modtage en ny kode.
- Jeg kan ikke se hvem der har kommenteret, da folk kun skriver deres fornavn i feltet “navn”.
- Jeg vil godt have at jeg kan klikke på folks navne og se alle deres kommentarer
- Jeg mangler en mulighed for at udelukke folk hvis de skriver en kommentar jeg ikke vil have på siden.
- 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 inklusiv alle funktioner.
- Hvordan tilmelder folk sig, så de også kan logge ind?
- 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 og forklaringen har har været givet overhoved ikke matcher hvad kunden har set på.
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 nødvendigvis nok. Her kan du se en liste med ting du bør bare med i en kravspecifikation for at gøre det nemmere for alle parter:
- En introduktion til hvad der skal laves
- Formålet med projektet.
- Hvordan produktet skal benyttes. Specielt vigtigt hvis du eksempelvis sigter efter en specifik målgruppe (mobil brugere) og det ikke står beskrevet nogen steder.
- Skitser eller billeder af lignende eller prototyper af det du ønsker lavet.
- Materiale eller systemer der skal bruges.
Derfor kan du hente 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.
Fysiske produkter og kravspecifikation
De samme regler gælder for fysiske produkter. Hvis det ikke er beskrevet så kommer det formentlig ikke med. Derfor er ting som mål på enheden (udvendigt og indvendigt) vigtige og ting som tollerancer er yderst vigtigt at få med i mange tilfælde, da man ellers kan stå med to af samme produkt som måske er flere millimeter forskellige fordi tollerancerne slet ikke er så præcise som de måske skal være til det de skal bruges til.
For fysiske produkter er det også vigtigt at materiale valget defineres og producenten ved hvad produktet skal bruges til. Dt kan være produkter som skal sidde isolen, og derfor skal have en UV beskyttelse eller være lavet af et materiale der ikke påvirkes så meget af UV.
Opsummering
En vellykket udviklingsproces, hvad enten det drejer sig om software eller fysiske produkter, starter med en klar og omfattende kravspecifikation. Kommunikationen mellem kunden og udvikleren/producenten er afgørende for at undgå misforståelser og tidsspilde.
Artiklen introducerer vigtigheden af en kravspecifikation og dens rolle i at skabe en fælles forståelse mellem parterne. Ofte kan udviklere modtage projektbeskrivelser baseret på en kort telefonsamtale og mails, hvilket kan føre til unøjagtige projekter.
Et eksempel med “Et meget enkelt brugersystem” demonstrerer, hvordan manglende detaljer i en opgavebeskrivelse kan føre til misforståelser mellem kunden og udvikleren. En omfattende kravspecifikation er nødvendig for at undgå sådanne problemer.
Artiklen anbefaler at inkludere så mange detaljer som muligt i kravspecifikationen, herunder links og billeder. For fysiske produkter er detaljerede beskrivelser af mål, tolerancer og materialevalg vigtige for at opnå det ønskede resultat.
En god kravspecifikation kan tage tid at udarbejde, men den er afgørende for at sikre gensidig forståelse og præcision i projektet. For at hjælpe læserne yderligere tilbyder artiklen en skabelon for, hvordan en kravspecifikation kunne se ud.
Afslutningsvis understreger artiklen betydningen af klart definerede kravspecifikationer for både software- og fysiske produktprojekter. Det er nøglen til at skabe vellykkede udviklingsprocesser og undgå misforståelser undervejs.