INDEXED Webbureau

Sådan udformes en kravspecifikation til IT projekt

Sådan udformes en kravspecifikation til IT projekt
Sværhedsgrad: 2/5
Målgruppe: Projektejer
Af

Indholdsfortegnelse

Denne oversigt vil kravspecifikationen være opdelt i og du kan bruge den som skabelon. Til afslutning kan en template downloades som kan benyttes i egne projekter. Denne skabelon indeholder et simpelt eksempel på hvorledes den kan dække over en hjemmeside.

  • Hvad er en kravspecifikation?
  • Hvad koster mit projekt at bygge?
  • Beskriv virksomheden bagved
  • Liste med de tekniske krav og funktionalitet
  • Hvad der helt specifikt skal inkluders som krav
  • Ikke funktionelle krav
  • Wireframes og flow

Hvad er en kravspecifikation?

En kravspecifikation er et dokument som beskriver funktionaliteten over et givent IT projekt og ud fra dette kan projektet estimeres og implementeres af udviklere. Et eksempel og andre krav kan du se på erhvervsstyrelsen.

Hvad koster mit projekt at bygge?

Et typisk spørgsmål fra projektejer efter en kort gennemgang på 2 min. Herefter svarer projektlederen: Hvad skal det kunne?

For at give projektejer et reelt og fair svar sætter man sig ned og beskriver i detaljer hvad der skal bygges, hvordan det skal se ud, hvordan det skal fungere samt hvilke problemer det skal løse. Det er derfor ikke et holdbart svar at sige 100 timer efter en gennemgang på 2 min. I softwareudvikling er der mange sorte kasser hvor man ikke ved hvad der er indeni før kassen åbnes. Et smugkig i kassen og efterfølgende beskrivelse i kravspek. vil give et godt estimat af opgaven.

Forretningsforståelsen af virksomheden er faktisk det vigtigste punkt for at projektet skal blive en success

Beskriv virksomheden bagved

En liste med krav giver ikke meget mening hvis ikke forståelsen bagved også er med. Derfor er det første afsnit i høj grad også det vigtigste da det skal indeholde en beskrivelse af virksomheden, historien bag ved og hvorfor projektet nu er nødvendigt. Indledningsvis i dokumentet har man derfor en problemformulering som beskriver det problem der ønskes at løses.

  • Beskriv hvilken problemstilling projektet skal løse
  • Beskriv historien bagved virksomheden
  • Forklar jargon og tekniske vendinger som benyttes af virksomheden i kravspecifikationen
  • Beskriv hvem målgruppen er for projektet dvs. hvem skal bruge produktet?

Forretningsforståelsen af virksomheden er faktisk det vigtigste punkt for at projektet skal blive en success. Ja hvorfor det? En udvikler som får at vide han skal bygget feature A, bygger den bare og kan så risikere at blive mangelfuld. Får udvikleren istedet at vide:

  • A. Hvad han skal bygge
  • B. Hvorfor han skal bygge det
  • C. Hvilket problem det skal løse

Så er sandsynligheden langt større for at han også kommer i mål med det som projekt ejeren ønsker.

Liste med de tekniske krav og funktionalitet

De enkelte krav og features bør listes på en nummereret liste så det er nemt at referer direkte til et punkt enten fra andre krav eller når man kommunikerer sammen. Når nye punkter tilføjes eller ændres efter påbegyndelse bør man tilføje dem som et tillæg og versionsstyres. Rediger derfor ikke i en endelige kravspecifikation for ellers vil nummer formatteringen også ændres. Mangler du inspiration til indholdet findes der en god liste med punkter her.

En nummereret liste form ser sådan her ud

  1. krav
  2. krav
    1. underpunkt med krav
    2. underpunkt med krav
  3. krav se figur 1
De enkelte krav og features bør listes på en nummereret liste så det er nemt at referer direkte til et punkt

Her er et eksempel på hvordan billeder kan vedhæftes. Giv denne mockup navnet figur 1 og referer til den i teksten.

wireframe
Figur 1

Hvad der helt specifikt skal inkluders som krav

Hvis vi helt konkret tager udgangspunkt i beskrivelsen af en kontakt formular. Så lad os forestille os at i version 1 af kravspecifikationen så noteres der at siden skal indeholde en kontaktformular og at denne skal sende kopi til xx@xxx.dk. Dette krav er overordnet ok, men der er også mange faldgruber for udvikleren og sansynligvis bliver der ikke udviklet det som der præcist forventes af kunden. Derfor skal sådan en kontaktformular uddybes for at undgå tvivl. Lad os tage udgangspunkt i dette eksempel.

Eksempel på kravspecifikation for kontakt side:
  1. Kontakt side
    1. I hovedmenu samt footer skal der være link til kontakt side
    2. På kontakt side skal der være kontaktformular med følgende felter: Navn på afsender, email på afsender, besked fra afsender
    3. Ved udfyldelse af kontakt formular skal der sendes en email til modtager og kunden skal modtage en bekræftigelse på mail
    4. Kontakt formularen skal validere at felter er korekt udfyldt før brugeren kan submitte formen
    5. Efter succesfuld udfyldelse skal brugeren sendes videre til en bekræftigelseside hvor der kvitteres med modtagelse
    6. Ved eksekvering skal der sendes event til Google Analytic
    7. På kontakt siden skal der udover formular også være virksomheds info som adresse, tlf. email og markering på Google Maps samt åbningstider, se figur 1

kontakt mockup
Figur 1

Her er der i eksemplet taget udgangspunkt i desktop versionen men der bør tilføjes punkter som beskriver den mobile version samt tilhørende mockup.

Det kan måske virke som udpensling af feature og tage tid at beskrive men det vil spare sig ind på implementeringsfasen for udvikleren ved præcist hvad der skal bygges. Udvikler vil derfor spare tid på spørgsmål til projektleder og projektejer og vil med større sandsynlighed ramme plet i første runde. Projektleder og projektejer vil også spare tid på tests, fejlmelding og feedback. Software udvikling er per definition en meget dyr process så kan man reducere denne vil den samlede omkostning for projektet også reduceres.

Det gælder derfor i disse beskrivelser at være specifik på hvad der ønskes og ikke hvordan det skal implementeres. Et krav som at kontakt siden skal være brugervenlig er ikke specifikt og kan fortolkes på mange måder.

I dokumentet kan der være et selvstændigt afsnit som beskriver projektplanen. Her angives hvilke dele der ønsker udviklet først og en nogenlunde timeframe for dette. Et Gantt chart er oplagt til dette.
gantt chart
Gantt chart som viser tidplan over forløbet

Når projektet nærmer sig den sidste fase bør der være en accept test til at verificere at alle krav er opfyldt. Der findes en lidt dybere udspecificering her på wikipedia.

Kravspecifikation skal beskrive funktionalitet og wireframes for både desktop og mobil version da disse kan og vil adskille sig

Ikke funktionelle krav

Nogle krav kan være ikke funktionelle, dvs. de angiver ikke en specifik funktionalitet. I dette afsnit angiver vi derfor de krav som er lidt mere "bløde". Som eksempler kan nævnes:

  • Hjemmeside skal fungere på en tablet og mobil via responsivt design
  • Hjemmeside skal være hurtig og svartid på under 1 sek. i gennemsnit for alle sider
  • Der skal være høj sikkerhed
  • Den skal fungere i nyeste versioner af IE11, Edge, Chrome, Firefox og Safari

Da f.eks. en hjemmeside bliver vist på et hav af forskellige browsere, enheder og skærmopløsninger bør man anvise hvilke den typisk bør fungere optimalt på og hvilke man accepterer en graceful degradation så hjemmesiden stadig fungere men kan se lidt anderledes ud eller helt mangle en given funktionalitet.

Wireframes og flow

Yderligere læsning

100+
Projekter gennemført
til tiden
50+
Kunder har vi haft
glæde af at hjælpe
450
udviklingstimer til
rådighed hver måned
55
WordPress
løsninger udført