Ukesoppgaver 3: Kravhåndtering

KRAV, KRAVARBEID, KRAVHÅNTERING

Krav og kravhåndtering er begge ord som går igjennom i store deler av design, bruk, interaksjon pensumet. I systemutvikling er kravhåndtering en sentral aktivitet.

1a) Hva er en kravspesifikasjon?
En kravspesifikasjon er et dokument som spesifiserer (angir i detalj) bruker og systemkrav. Kravspesifikasjonen brukes som basis for anbud, kontrakt, design og implementasjon for systemet. Kravarbeid er første fase i fossefallsmodellen.

1b) Hvorfor er det nødvendig å lage en kravspesifikasjon?
Det er nødvendig fordi en (god) kravspesifikasjon skaper felles forståelse av systemet, den skaper enighet om hva som skal leveres og den kan forhindre eventuelle konfliker som kan oppstå på bakgrunn av ulike forventinger. En kravspesifikasjon gjør det klart og tydelig hva som forventes i det kommende systemet.

2) Gi en definisjon for begrepet "interessent". 
Begrepet interessent benyttes for å angi en mengde personer, grupper og/eller organer som har interesse av systemet, altså blir påvirket eller påvirker systemets utvikling og/eller bruk, enten det er direkte eller indirekte. De påvirker eller blir påvirket av kravspesifikasjonene til systemet. Vi deler interesser inn i fire grupper: kunde (eier, ansatte), leverandør (eier, utviklere), bruker (ulike typer) og andre (myndigheter, andre bedrifter).

3a) Hva er funksjonelle og ikke-funksjonelle krav? Beskriv forskjellen.
- Funksjonelle krav definerer hva systemet skal gjøre. Og ikke gjøre, tilgjenglighet, brukervennlighet og sikkerhet fra brukerens ståsted. Beskrives gjerne slik "Systemet skal kunne utføre handlingen på under tre minutter".

- Ikke-funksjonelle krav er rammene for systemet. For eksempel responstid, opptid, ressursforbruk, antall samtidige brukere og lignende. Det er mulig å tallfeste ikke-funksjonelle krav. Kan beskrives slik "Systemet må være egenskap".

Forskjellen mellom funksjonelle og ikke-funksjonelle krav er at funksjonelle krav beskriver hva systemet skal gjøre mens ikke-funksjonelle krav beskriver hvordan systemet skal implementere de funksjonelle kravene. Tungvindt. Her er en illustrasjon som viser fem funksjonelle og ikke-funksjonelle krav for en "resturant app".


3d) Beskriv hvordan du kan evaluere de ikke-funksjonelle kravene:
Man har her to alternativer. Vi kan velge mellom å skrive krav som er direkte målbare. For eksempel "Systemet skal kunne håndtere 2000 brukere samtidig". Eller så kan man skrive generelle krav, "systemet skal være raskt" men her presistere med å skrive "systemet skal lastes inn på under 3 sekunder", da man ikke man måle "raskt". For å evaluere ikke-funksjonelle krav må man derfor gjøre dem målbare.

4) Hva vil det si å validere et system og hvorfor er dette viktig? 
Validering: Er dette systemet kunden faktisk vil ha? Man kan validere en kravspesifikasjon - beskriver dette systemet kundens ønsker? Validering er svært viktig da det er svært kostbart å endre på et ferdig system.

5a) I smidig utvikling benytter man gjerne brukerhistorier (user story). Hva er en brukerhistorie?
En eller flere setninger som beskriver hva brukeren av et system ønsker å få ut av systemet på forhånd. Eksempel på mal for en brukerhistorie er som følger: Som en <bruker> ønsker jeg <funksjon> slik at <verdi>. 

5b) Nevn noen fordeler ved å bruke denne teknikken til å beskrive krav.

- Man trenger ikke ha teknisk kompetanse for å forstå kravene

- Man forstår raskt hvorfor det er viktig å implementere funksjoner

- Det er lettere å se hvem kravet er tiltenkt.

5c) Drøft utfordringer ved å benytte brukerhistorier beskrevet på lapper på en tavle i store, smidige utviklingsprosjekter.

Blir fort rotete med så mange lapper + at det bare er de som er i rommet som får det med seg.

5d) Skriv noen brukerhistorier for appen beskrevet under oppgave 2. 

- Som kunde ønsker jeg å kunne se hva andre har kommentert på resturanter slik at det blir enklere å ta et godt valg.

- Som kunde ønsker jeg å kunne sortere resturanter etter kategori, slik at jeg kan finne en resturant som tilbyr mat jeg liker

- Som resturanteier ønsker jeg at appen skal vise menyen til resturanen så kunden får et godt overblikk over hva vi serverer.

6a) I systemutviklingsprosjekter med tett kundemedvirkning er det en fare for at kunden blir påvirket av utviklingsteamet og adopterer deres perspektiv. Da kan brukernes behov bli tillagt for liten vekt. Foreslå tre måter å redusere dette problemet på.

- Ikke ha kun en fast representant fra kunden som kommer, men bytte på

- Holde tekniske diskusjoner til et minimum

- Ikke gjør kunden til en del av teamet, kun der det er nødvendig

6b) Fordeler og ulemper ved kundeinvolvering

+ Raske tilbakemeldinger

+ Involverere en person med god domeneforståelse ()

+ Sørger for  at systemet opprettholder brukernes behov

- Krever mye tid og ressurs av kunde

- Krever at kunden er tilgjenlig