Udviklingsmetoder - specificering af krav

Når man skal udvikle et it-system, app eller en hjemmeside, er det vigtigt at kende sine brugere og forstå hvilke behov de ønsker at få opfyldt. Vi har behov for at forstå vores brugere, så man ved hvordan produktet, der udvikles kan hjælpe dem i deres problemstilling. Vi har også behov for at kende nogle krav, så vi har noget at designe og udvikle ud fra. Vi har behov for at afklare kravene, så vi kan indgå en aftale med kunden omkring hvad produktet skal kunne og hvad det kommer til at koste. Her er et overblik over forskellige teknikker der kan bruges til at danne og beskrive kravene for et it-produkt.

Hvad er et krav?

Et krav er en beskrivelse af hvad et it-produkt skal kunne gøre for brugeren, hvordan det bliver brugt og hvordan der virker. Kravene bliver skrevet i en kravspecifikation, som er det dokument der danner aftalegrundlag for det produkt der skal udvikles. I en god kravspecifikation bliver der beskrevet hvordan it-produktet opfylder brugernes behov og hvordan den tilfører værdi til virksomheden.

Hvordan beskriver vi kravene?

Vi finder frem til kravene ved, at man som udvikler samarbejder med kunder og brugere, ved at indsamle data fra vores kunder og brugere, kan vi få defineret kravene. Der findes forskellige metoder at indsamle data på, som kan bruges enten hver for sig, men kan med fordel kombineres.

• Spørgeskema
  Spørgeskemaer bruges til at nå en bred målgruppe
  
• Spørgeskema
  Bruges til specifikke målgrupper
  
• Gruppeinterview
  
• Observationer
  Bruges til at forstå opgavens sammenhæng
  
• Observationer
  Der udarbejdes en prototype tidlig i processen, der kan testes på brugerne.
  
  

Dataindsamling kan foregå forskelligt, alt efter projekt størrelse og type.

Et lille vedligeholdelsesprojekt Her bliver ændringsønsket ofte aftalt mellem kunden og designeren/udvikleren. Kravspecificeringen foregår typisk over nogle screenshots, hvor man skriver eller tegner de ønsker man har.

Et mindre projekt
Er det derimod et projekt hvor kunden skal fx skal have udviklet en hjemmeside, med fx et bookingsystem og han/hun kender kravene på forhånd, udarbejdes kravspecifikationen typisk mellem designer/udvikler og kunden. Her bliver brugeren ikke involveret, da kunden i forvejen kender kravene og har en ide over hvad siden skal kunne.

Store projekter
Ved større projekter, hvor en større virksomhed f.eks. har et ønske om at få udviklet et system der understøtter deres daglige arbejdsopgaver, bliver der foretaget en analyse af organisationen og dets brugere og opgaver. Analysen udarbejdes med henblik på at vurdere behovet for it-systemet og forbedringer af arbejdsgangene. Når opgaven bliver sat i gang laves der en kravspecifikation.

De forskellige brugere af kravene

Designeren/udvikleren Bruges så de kan se hvad der udvikles

Ledelsen Bruges til at vurdere tid, omkostninger og til at se om opgaven er realistisk at gennemføre. Bruges også som grundlag for kontrakten. Kravene skal være en mellemting mellem at kommunikere til kunden og at definere præcist og detaljeret for udvikleren/designeren hvad der skal

Der findes to forskellige kravs typer:

Funktionelle krav
Beskriver hvad produktet skal kunne

Ikke-funktionelle krav

• Hjemmesiden skal være brugervenlig
• Der skal bruges en bestemt farve i logoet, hvilket giver begrænsninger i designet
• Hjemmesiden skal kunne ses i forskellige browsere
• Der skal være mulighed for at kunne shoppe med appen

• Hjemmesiden skal være brugervenlig
• Der skal bruges en bestemt farve i logoet, hvilket giver begrænsninger i designet
• Hjemmesiden skal kunne ses i forskellige browsere
• Der skal være mulighed for at kunne shoppe med appen

Produktvision

• Bruges til at give overblik over målene
• Bruges til at give overblik over de forretningsmæssige baggrunde for systemet, dets brugere, samt interessanter
• Bruges til at give overblik over de vigtigste features
• Bruges ofte på baggrund af den dataindsamling man har foretaget.
• Bruges til at danne en fælles forståelse for hvad der skal laves og bruges.
• Kan bruges til at beskrive hvordan modtageren ser afsenderen
• Kan bruges til at definere målgruppen
• Bruges til at beskrive hvordan budskabet skal ud, så man får den bedst mulige virkning

• Indeholder både de funktionelle og ikke funktionelle krav
• Her anvendes feature og un-feature list
• Skitser af data og informationsstruktur, kan benyttes sammen med
• Der skal være mulighed for at kunne shoppe med appen

Produktbacklog

• Kravene bliver priorteret og bliver tilføjet løbende
• Detaljeringsgraden er mindre – kun de højeste krav uddybes/li>
• Features kaldes for items
• Kravene bliver skrevet i form af user stories i et storykort
• Indeholder både storynavn og ID
• "As a” (f.eks. ”som køber”)"
• I want to (f.eks. ”vil jeg gerne”)
• So that (f.eks. ”så jeg kan”
• Estimate (Den forventede tid)
• Actual (Faktisk tid)
• Priority (prioritet)

MoSCoW-skalaen

• Must have
  Det nødvendige for at produktet kan fungere
• Should have
  Noget der har værdi for kunden eller brugeren, som burde være med, men som dog ikke er en nødvendighed for produktets succes
• Could have/nice to have
  Er noget der har en værdi for brugeren, men som man sagtens kan undværes?
• Wont have/would like to have
  Noget man har tænkt over, men som ikke har noget værdi endnu. Kan blive aktuelt senere

Brugerprofiler, personas og aktører

Brugerprofilbeskrivelse: Er en vigtig del af kravspecifikationen og er en beskrivelse af brugernes mål med anvendelse af it-produktet.

Personas:
Er nogle fiktionelle personer som repræsentere forskellige typer brugere, som interessere sig for fx en hjemmeside. En brugerprofil omfatter blandt andet navn, demografi, uddannelse, job, interesser, erfaringer i anvendelse af nettet samt mål med brug af siden. Brugerprofilerne bruges til at inddrage igennem udviklingsprocessen, så man hele tiden holder sig på sporet. Sådan er brugerprofilerne med til at danne de funktioner og den brugervenlige version, der skal til for at danne en hjemmeside.

• En aktør er rollen, som en persona kan have i forhold til brugen af et system.
• Aktøren er med til at klargøre brugen af hjemmesiden
• Aktøren behøver nødvendigvis ikke at være en person, men kan også være et system.

Scenarier og use-cases

Brugerprofilbeskrivelse: Er en vigtig del af kravspecifikationen og er en beskrivelse af brugernes mål med anvendelse af it-produktet.

Scenarier og use-cases er omfattende og har mange detaljer i forhold til stories. Man bruger det til at kunne samle kravene og gruppere dem i forhold til de mål brugerne ønsker at opnå. Begge bruges til at demonstrerer systemets funktionalitet, som findes i ens kravliste eller produkt backlock.

• Konkrete historier om hvordan personaer kommer til at bruge det givne produkt.
• Beskriver hvordan den enkelte bruger handler og tænker. s
• Er med til at danne et grundlag for hvilke krav brugerne har, ved hjælp af diskussion og udforskning.
• Understøttes ofte af prototyper
• Foretrækkes ved mindre formelle beskrivelser
• Kan bruges til at beskrive brugerne og de følelser de udtrykker ved det de gør.

• Der fokuseres på interaktion mellem bruger og system.
• Er som regel mindre omfattende
• Kan være en beskrivelse af hvordan et køb foregår.
• Hvis en sekventiel orden finder sted bruges use-cases.
• Bruges hvis det visuelle har en lille betydning.

Prototyper

• En skitse af forestillingen om hvordan et design kan se ud.
• Evalueres sammen med brugeren, så man kan om de vigtige elementer/funktioner er med og om tingene står i den rigtige rækkefølge.
• Er velegnet til at udforske og præcisere krav
• Kan være et supplement til produktbackloggen samt kravspecifikationen.

Kilder:
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 150-151
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 152
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 153
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 155
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 156-160
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 160-162
Torben Larsen, Anne Mette Busch m. fl. Kommunikation i multimediedesign (KiM), 2. udgave, 2015, Hans Reitzels Forlag, ISBN 13: 9788741261683, s. 162