For å kunne utvikle et godt og tilfredsstillende produkt for våre kunder er det ytterst nødvendig å gå gjennom en fase med kravspesifisering. Mange tenker at denne fasen ikke bør være for omfattende og lar det ofte være med et kort møte med kunden. Dette kan imidlertid by på store problemer senere i utviklingsfasen. 

En god løsning er å dele opp denne fasen i tre nivåer: Forretningskrav – overordnede mål kunden har med systemet, Brukerkrav – mål eller oppgaver brukerne ønsker å gjennomføre og Funksjonelle krav – hva utviklerne må implementere for at systemet skal ha ønsket oppførsel. Nedenfor er disse nivåene beskrevet i nærmere detalj. Dette innlegget forklarer nærmere hvordan en slik prosess kan gjennomføres og hvorfor dette er viktig.. 

Forretningskrav

Første steg er å definere det vi kaller business requirements eller forretningskrav. Forretningskrav er overordnede krav kunden har eller de markedsfordelene kunden ønsker å få med det nye systemet. Det er viktig at både kunde, konsulent og utvikler er bevisst på og har en felles forståelse av dette før man går videre i prosessen. Resultatet er en beskrivelse av hvorfor bedriften ønsker å implementere systemet og fokuset her ligger på bedriften og mindre på selve systemet. 

Visjon

I tillegg til å avklare hvorfor man implementerer et nytt system må man kunne beskrive hva som skal implementeres. Man bør gjøre seg opp en konkret mening om hva systemet skal gjøre og spesielt hva det skal gjøre for kunden. Dette er det vi kaller en vision eller visjon. En visjon er en overordnet beskrivelse av hva systemet skal gjøre og hvordan det skal løse de problemene som foreligger. Det er viktig også her at man ikke tenker for mye på hvordan systemet skal implementeres, men at man ser på dette som en løsning på problemene. Hvordan utviklerne velger å implementere løsningen ser vi nærmere på når vi kommer til funksjonelle krav.

Målsettinger

Etter at man er enige om hvorfor bedriften ønsker det nye systemtet og hva som skal produseres bør man sette seg noen konkrete målsettinger. Dette kaller vi ofte business objectives og man definerer gjerne 3-6 slike målsettinger for det nye systemet. Disse bør være formulert på en måte at de er målbare etter prosjektets slutt, men også under veis i prosessen. Ved å sette målbare målsettinger er det enklere å se hvor langt man har kommet i prosessen og man har noe litt mer konkret å jobbe etter når systemet implementeres. 

Suksessfaktorer og risikoer

Det kan i tillegg være fornuftig å beskrive noen typiske suksessfaktorer ved systemet. Suksessfaktorer er verdier man tar utgangspunkt i ved evalueringen av systemet under veis i prosjektet og etter levering. Man blir enige om noen parametere man ønsker å måle, for eksempel tall på økonomiske gevinst, antall klikk på en nettside eller antall besøkende i en butikk. 

Ofte er det risikoer knyttet til investeringen av et nytt system. Det bør være en felles forståelse av hvilke risikoer det innebærer, hvor sannsynlig det er at disse inntreffer og hvor store følger det kan gi dersom de inntreffer. Eksempler på dette er konkurrerende bedrifter, motvillige leverandører og interessenter eller uforutsette hendelser under implementeringen av systemet. Det er viktig at både kunde og konsulent er klar over risikoer som foreligger og at man er forberedt på at uforutsette hendelser kan skje. 

Brukerkrav

Forretningsmålene tar for seg de overordnede målene med det nye systemet og de kravene som kunden stiller til produktet. Nå er det på tide at vi graver litt dypere i disse og forsøker å definere noe som er litt mer håndfast. Vi skal nå ta en nærmere titt på det vi kaller user requirements, eller brukerkrav. 

Brukerkravene beskriver mål eller oppgaver som brukerne må kunne gjennomføre og som gir en verdi til noen. Hvis vi har et forretningsmål som går på det å kunne tilby brukere mulighet til å gjennomføre kjøp av matvarer på nett, hva er da våre brukerkrav? Det kan for eksempel være av brukerne skal ha muligheten til å velge ønskede varer i en handlekurv på telefonen, de skal kunne betale for sine valgte varer ved hjelp av Vipps og brukerne skal kunne få en beskjed når varene er tilgjengelig for henting. Som vi ser så er disse kravene på et lavere nivå enn forretningskravene – de beskriver i mer detalj hva sluttbrukeren skal kunne gjøre med systemet og hvilken verdi dette gir til brukerne.

Forretningskrav beskriver hvorfor systemet implementeres – brukerkrav beskriver hva som skal implementeres

Use case

Et verktøy for å representere brukerkrav er use cases. Use cases er konkrete beskrivelser av oppgaver som brukerne skal kunne gjennomføre med det nye systemet. 

Ved å benytte seg av use cases velger man eksplisitt å legge fokuset på brukerne. I stedet for å stille spørsmålet Hva ønsker brukerne at systemet skal gjøre? spør man heller Hvilke mål ønsker brukerne å oppnå? 

Brukerne ser ofte for seg hvordan de ønsker det nye systemet skal se ut, fungere og hvilken funksjonalitet det bør inneholde. Det er viktig at man ikke skyver dette under teppet, men i denne fasen er det viktig at man fokuserer på selve essensen av de ønskene brukerne kommer med. Skal man designe en bil, begynner man ikke med hvilken farge man skal ha på setetrekkene eller hvor stor motoren skal være. Man tar utgangspunktet i et mål om at brukeren skal ha en bil som er behagelig å sitte i, trygg å kjøre på norske veier og med krefter nok til å komme seg opp en gjørmete skogssti. 

Så hva er en use case?

Vi fortsetter med eksemplet vårt om et system som skal gjøre det enklere for brukerne å handle inn til middag. Eksempler på use cases for et slikt system kan være:

  • Legge matvarer i handlekurven
  • Lage brukerprofil på nettsiden
  • Betale for matvarene i handlekurven
  • Bestille levering til ønsket adresse
Use case-navnene er alltid skrevet på formen verb + objekt. Det skal være kort og konsist og reflektere noe brukeren ønsker å gjøre med systemet. Navnene bør også velges slik at det fremgår at det gir en verdi for en bruker. 

Hvem er brukerne?

En viktig del av spesifiseringen av use cases er å identifisere hvem brukerne er. Dette kan virke som en nokså enkel sak, men ofte kan det være personer som skal benytte seg av systemet som ikke har kommet fram av initielle møter eller tidligere faser. Det kan derfor være lurt å bruke litt tid på dette. 

I lys av use cases skiller vi også ofte mellom users og actors. På norsk kaller vi det brukere og roller. For et system som skal benyttes på et hotell har man gjerne brukere som resepsjonist og hotellsjef. De kan begge ta på seg rollen som ansatt, men bare en av dem kan ta på seg rollen som administrator. Følgende vil det være use cases som er gjeldende for alle ansatte, mens andre gjelder kun for de med administrator-rettigheter. 

Brukere (og roller) trenger ikke nødvendigvis å være fysiske personer. Det kan også være andre systemer som på en eller annen måte interagerer med det nye systemet og som dermed også har en verdi av å gjøre dette. Et eksempel på dette kan være database-systemer som enten henter ut eller tilbyr data. 

Use case diagram

Use case-diagrammer gir en visuell representasjon på et høyere abstraksjonsnivå. De består av et rektangel, som representerer systemet eller deler av systemet, og brukere, visualisert som strekmenn, utenfor systemet. Piler går fra brukeren og inn i systemet til de use casene som den respektive brukeren skal ha “tilgang på”. 

I figuren under ser vi et use case-diagram fra et system som håndterer kjemiske varer på et laboratorium. Requestor er her en rolle som kan utføre use casene Obtain Material Safety Data Sheet, Request a Chemical og Dispose of a Chemical. Man ser her at andre brukere (roller) også inngår i de samme use casene. Vi legger også merke til at Training Database inngår i diagrammet, som en egen rolle. Dette er ikke en fysisk person, men et database-system som utfører use caser i vårt system. 

Vi merker oss at use casene ikke beskriver hvordan systemet fungerer, bare hva systemet skal gjøre, eller mer presist hva brukerne skal gjøre med systemet.

Beskrivelse av en use case

En use case i form av dens navn gir ikke mye informasjon. Ofte er det nødvendig å beskrive dem ytterligere. Dette kan vi gjøre ved hjelp av et skjema, vist under. Det er på ingen måte noe krav om å fylle ut et slikt skjema fullstendig, men det kan være svært nyttig videre i prosjektet. 

De viktigste elementene i en use case er:

  • En unik ID og et konkret navn som reflekterer målet til brukeren
  • En kort tekst som beskriver formålet med use casen
  • En trigger som aktiverer utførelsen av use casen
  • Eventuelle forutsetninger som må være tilfredsstilt for at use casen kan begynne
  • En eller flere resultater som beskriver tilstanden til systemet etter at use casen er fullført
  • En nummerert liste med steg som viser dialogen mellom systemet og rollen. Dialogen går fra forutsetningene til resultatet.

Funksjonelle krav

Frem til nå har vi sett på forretningskrav og brukerkrav. Hvis vi ser for oss en trestruktur, der roten i treet er et forretningskrav, har vi nå utvidet med ett nivå som representerer brukerkravene. Dette er grenene som vokser ut fra roten. Det neste og siste laget i treet vårt kan vi se på som løv og utgjør det vi kaller funksjonelle krav.

Funksjonelle krav beskriver hvordan systemet skal oppføre seg under ulike forhold. Det beskriver hva utviklerne skal implementere for at brukerne skal kunne oppnå sine mål (brukerkrav). Funksjonelle krav utledes av brukerkravene, som igjen utledes av de forretningskravene kunden har til det nye systemet. Med de funksjonelle kravene på plass har vi fullført fasen med kravspesifisering og man er mer forberedt på å begynne utviklingen. 

Så hva er funksjonelle krav?

Når man definerer de funksjonelle kravene skriver man de ofte som såkalte skal-setninger, for eksempel Systemet skal vise en melding dersom varen er utsolgt eller Dersom brukeren har bestilt hjemmelevering skal det sendes ut en bekreftelse på mail som oppgir sted og tid

Det kan være nyttig å dele opp de funksjonelle kravene etter kategorier eller hvilken use case de oppfyller. Det er ikke alltid slik at en use case “består” (oppfylles) av et antall distinkte funksjonelle krav. Ofte kan funksjonelle krav være med på tilfredsstillelsen av flere use caser. Det viktigste er at summen av de funksjonelle kravene man kommer fram til tilfredsstiller alle kravene fra brukerne (brukerkravene).

Konklusjon

Da har vi fullført vår reise gjennom kravspesifiseringens verden. Vi begynte med å definere hva kravspesifisering er, hva det brukes til og hvorfor det er nyttig. Deretter definerte vi tre nivåer: Forretningskrav (Business Requirements), Brukerkrav (User Requirements) og Funksjonelle Krav (Functional Requirements). Disse tre nivåene resulterte i hvert sitt dokument som vil komme til nytte videre i utviklingen av systemet. 

Dokumentene

I dette innlegget er det nevnt en rekke dokumenter: Vision and Scope Document, User Requirements Document og Software Requirements Specification. Dette betyr ikke nødvnedigvis at det må skrives tre separate dokumenter for de ulike nivåene av kravspesifiseringen – dette er bare et utgangspunkt. Man kan velge å definere alle nivåene i ett dokument eller man kan dele det opp enda mer, dersom det er hensiktsmessig. 

Et dokument trenger ikke nødvendigvis å være et fysisk dokument, skrevet i Microsoft Word eller på papir. Ofte kan det være hensiktsmessig å benytte seg av andre verktøy, f.eks. Microsoft Excel, Freecamp, osv. 

Ikke en fasit

Til slutt vil jeg si at dette på ingen måte er noen fasit på hvordan man skal gjennomføre en kravspesifikasjon. Ulike prosjekter stiller ofte ulike krav til dokumentasjon og graden av kompleksitet gir en god pekepinn på hvor utfyllende, detaljert og nøye man bør være. I små prosjekter trenger man kanskje ikke bruke like mye tid på denne fasen som i større prosjekter med et mer komplekst produkt. Det viktigste er at man klarer å fange opp de kravene som brukerne stiller til det nye systemet og at man fokuserer på hvordan å oppnå størst mulig verdi for disse. 

Kilder

  • Software Requirements (3. edition), Microsoft Press, 2013, av Karl Wiegers og Joy Beatty