Sådan skriver du en god kravspecifikation
4 tips til at skrive en god kravspecifikation - inkl. en skabelonHvad er en kravspecifikation?
En kravspecifikation er et dokument, som beskriver de tekniske og funktionelle krav i forbindelse med et bestemt projekt. Kravspecifikationer skrives ofte i forbindelse med udvikling af software.
Det er derfor vigtigt at skrive en kravspecifikation, når man skal starte et hjemmeside- eller app-projekt.
Måske har du tidligere skrevet et beskrivende dokument i forbindelse med et projekt uden at vide, det var en kravspecifikation.
I så fald bør du læse videre - for der er mange ting, man skal være opmærksom på.
Hvorfor er det vigtigt at have en kravspecifikation?
Der er mange gode grunde til at skrive en kravspecifikation, og mange ulemper ved ikke at gøre det.
Kravspecifikationen er grundstenen i projektets forløb. Eftersom den beskriver, hvad der skal laves, er det svært at gennemføre et projekt uden.
Ofte tror begge parter, at de er enige om projektets omfang. Når man endelig går i gang, finder man hurtigt ud af at det ikke passede.
Pludselig vil kunden have A, B, C og D, mens udvikleren mener, at de kun har aftalt A og C.
Kravspecifikationen hjælper med at konkretisere og prioritere alle kravene, både de tekniske og de funktionelle. For at kravspecifikationen fungerer optimalt, er det vigtigt at den følger best-practices.
Skabelon til kravspecifikation
Hvis du leder efter en skabelon, du kan bruge som udgangspunkt til din kravspecifikation, er du havnet det rigtige sted.
Vi har gennem tiden skrevet og læst rigtig mange kravspecifikationer.
I vores skabelon har vi samlet den viden, så du kan komme godt i gang.
Du kan hente skabelonen her.
4 tips til en god projektbeskrivelse
1. Definér målet med projektet og skriv en indledning
Hvis du ikke selv kender målet med projektet, er det svært at vurdere hvornår, det er færdigt.
Indledningen behøver ikke at være mange sider lang. Det skal blot være et par linjer om:
- Hvordan det står til lige nu
- Hvordan det skal stå til efter projektet
- Andre "outcomes" projektet skal resultere i
Den kan desuden indeholde en kort prioritering af kravene i forbindelse med projektet.
Her hos BravoApps arbejder vi primært med apps. Et eksempel kunne derfor være:
Tandklinikken ApS ønsker at udvikle og app til tidsbestilling, samt mulighed for afbud/ændringer. Lige nu eksisterer en web-platform til samme formål. Appen og hjemmesiden skal forbindes, så de viser samme data.
Derudover skal der opsættes et system til at vise "nyheder" i appen. Tandklinikken ApS skal selv kunne oprette/ændre/slette nyheder.
Denne simple indledning kan i sig selv være med til at undgå misforståelser. Hvis man vil være bedst muligt stillet, skal der dog mere til.
2. Vær konkret omkring detaljerne og få det hele med
I indledningen beskrev vi overordnet målet med projektet. Resten af kravspecifikationen skal bruges til at gå i dybden med hverenkelt element.
Det er vigtigt at være meget konkret. Det er for eksempel ikke nok at skrive "brugeren skal kunne logge ind". I stedet skal det specificeres hvordan brugeren skal kunne logge ind.
Eksempelvis kunne beskrivelsen være:
Sektion 3.1 Log-in
Brugeren skal kunne oprette en konto og derefter logge ind, direkte i appen.
Mulighederne for log-in skal være email + kodeord, Facebook og Google.
Hvis brugeren logger ind med en anden platform end de oprindeligt oprettede sig med, skal de nægtes adgang. I stedet skal appen fortælle dem hvilken platform, de er oprettet med.
Vi bruger altså et par ekstra linjer til at beskrive præcis hvordan log-in-systemet skal fungere. Ellers kunne man nemt komme i tvivl om hvor mange forskellige sociale medier, brugeren skulle kunne oprette sig med.
Især den sidste linje er interessant. Hvis man ikke har arbejdet med log-in før, er det nemt helt at overse muligheden for at logge ind med en anden platform end den man oprettede sig med.
Pointen er ikke hvordan man bedst håndterer det specifikke scenarie - det kan gøres på mange måder. Det vigtige er at få det nedskrevet på forhånd, så man ikke kommer i tvivl om det i løbet af projektet.
Derudover kan det være nyttigt at nedskrevet, måske oven i købet tegnet, de vigtigste brugerflows.
Et brugerflow er en række handlinger, der leder til et bestemt resultat. I vores eksempel herover kunne det for eksempel være "Brugeren bestiller en tid til tandlægen".
Det kunne for eksempel se sådan ud:
Ved at beskrive hele flowet fik fastlagt nogle ting, en udvikler måske ikke var klar over:
- Brugeren skal modtage 2 SMS'er - én lige efter bestilling og én 1 dag før tiden
- Brugeren skal kunne redigere sine kontaktinformationer under booking
Hvis du er tandlæge, sidder du måske og ruller med øjnene:
Selvfølgelig skal de modtage en påmindelse 1 dag inden tiden! Ellers er der alt for mange, der ikke møder op.
Og lige præcis derfor, er det vigtigt at få skrevet ned. For dig er det måske en selvfølge. Det er det helt sikkert ikke for en udvikler.
En god tommelfingerregel er: Intet er åbenlyst, hvis det ikke står i kravspecifikationen.
3. Lad specialisterne gøre deres arbejde
Nu har vi brugt en masse energi på at understrege vigtigheden af, at få skrevet det hele ned. Nu skal vi til at snakke om, hvad du ikke bør skrive i kravspecifikationen.
Her er det vigtigt at tage udgangspunkt i de specialister, der skal udføre projektet.
Lad os for eksemplets skyld sige at du samarbejder med en app-udvikler og en designer.
I så fald skal du ikke specificere præcis hvordan booking-flowet fra tidligere skal se ud. Ved punkt 2 ("Brugeren trykker BESTIL TID") kunne man få lyst til at notere at knappen skal være rund, blå og placeres i nederste højre hjørne.
En dygtig designer ville, efter at have læst kravspecifikationen, spørge dig hvorfor du synes, knappen skal udformes sådan. Selvfølgelig så den er nem at finde!
I så fald giver det meget bedre mening at notere at "knappen er appens primære formål, og den skal derfor være nem at finde".
Så kan designeren bruge sin faglige viden til at designe knappen bedst muligt.
En anden uhensigtsmæssig tendens, er at fortælle udvikleren hvilket programmeringssprog appen skal laves i. Det ved de som regel bedst.
Hvis du har nogle særlige krav til systemet, er det selvfølgelig vigtigt at få med!
Til Tandklinikkens app, er det en central pointe, at den kan integreres med hjemmesiden - og det påvirker højst sandsynligt valget af teknologi.
4. Snak kravspecifikationen igennem før projektstart
I mange tilfælde er dette punkt det absolut vigtigste. Idéen med en god kravspecifikation er at få opklaret så mange spørgsmål som muligt - før projektet går i gang.
Hvis kravspecifikationen tager højde for alt, kan det sagtens ske at den ikke bliver ændret inden projektstart. I mange tilfælde vil der dog stadig være tvivl omkring nogle af punkterne.
Derfor er det vigtigt at man grundigt gennemgår kravspecifikationen sammen med sine specialister, inden man skyder projektet i gang.
På den måde sikrer man at alle er på bølgelængde omkring hvad resultatet skal indeholde og hvad det ikke skal indeholde.
Vil du have hjælp til at skrive en kravspecifikation?
Vi sidder klar til at hjælpe - uanset om du allerede har en kravspecifikation, eller skal bruge hjælp til at skrive den.FAQ
Herunder har vi samlet de mest almindelige spørgsmål omkring kravspecifikationer- Definér målet med projektet og skriv en indledning: Hvis du ikke selv kender projektets mål, er det svært at vurdere, hvornår det er færdigt.
- Vær konkret omkring detaljerne og få det hele med: Et af de mest almindelige problemer med kravspecifikationer, er at de ikke indeholder nok information. Inkludér nok detaljer til at undgå tvivl!
- Lad specialisterne gøre deres arbejde: Man kommer nemt til at inkludere de forkerte ting. Hvis du arbejder med en udvikler, er det for eksempel ikke gavnligt at diktere hvilket programmeringssprog, systemet skal udvikles i.
- Snak kravspecifikationen igennem før projektstart: En god kravspecifikation skrives ikke i et vakuum. Gennemgå den derfor grundigt med specialisterne. På den måde sørger man for, at alle er på samme bølgelængde.
Du kan downloade vores skabelon til kravspecifikation.
En kravspecifikation er et dokument, der beskriver kravene til funktionalitet i forbindelse med et bestemt projekt. Kravspecifikationer skrives ofte i forbindelse med udvikling af software.
Det er derfor vigtigt at skrive en kravspecifikation, når man skal starte et hjemmeside- eller app-projekt.
Måske har du tidligere skrevet et beskrivende dokument i forbindelse med et projekt uden at vide, det var en kravspecifikation.
En god kravspecifikation behøver kun at indeholde 2 (nogle gange 3) dele.
- Indledning: Her beskrives de overordnede krav og mål til projektet.
- Krav: Her går man i dybden med den funktionalitet, der skal udvikles. Denne del vil udgøre størstedelen af kravspecifikationen.
- (hvis nødvendigt) Tidsramme: Gennemgang af den forventede tidsramme for projektet. Dette kan være vigtigt, hvis projektet skal være afsluttet inden en bestemt dag f.eks. Black Friday.
Under Krav er det en god idé at inkludere:
- Konkrete beskrivelser af funktionalitet
- Flow-diagrammer
- Krav til teknologien
Du kan komme hurtigt i gang med at skrive en kravspecifikation, ved at hente vores skabelon.
Vi har gennem årene været med til at skrive rigtig mange kravspecifikationer.
Vi har samlet alt vores viden og opsat en skabelon til kravspecifikation.
Du kan hente skabelonen her.