Forstudie og Kravspesifikasjon

Forstudie og Kravspesifikasjon

Av Anne KristineEllenGunn MarieOlaug

FORSTUDIET

Et bra forstudie er det første skritt på vei til en ”A”.

Og det viktigste.

Fasene

Forstudie Kravspesifikasjon Konstruksjon Implementering Testing

Forstudiet danner grunnlaget for alle kommende faser!

Hva er et forstudie?

Hva er det egentlig kunden ønsker seg/trenger?

Hva finnes allerede på dette området? Kan vi gjenbruke eller lære av det som

allerede eksisterer? Unngå dobbeltarbeid!

Mål: Få oversikt over problemet og behovet, forstå hvordan det kan løses

Hva skal med i forstudiet?

Beskrivelse av problemstilling Begrepsavklaring, forkortelser Beskrivelse av

Dagens situasjon & løsning (”as is”) Ønsket situasjon & løsning (”to be”)

Overordnede krav til løsning Forretningsmessige krav Funksjonalitet (overordnet!)

Hva skal med… (2)

Kriterier for å evaluere eksisterende løsning Utledet av overordnede krav

Markedsundersøkelse Beskrivelse av alternative løsninger Evaluering av alternativer (inkl. kost/nytte) Sammenlikning av alternativene (iht.

evalueringskrit.) Bruk evalueringskriteriene ryddig og konsist!

Valg av løsning

Dagens situasjon & løsning

Beskrive dagens situasjon Hvem trenger systemet? Hvorfor?

Beskrive dagens system Hva eksisterer i bedriften i dag?

Lage system fra bunnen? Utvikle prototyp? Bygge videre på moduler/eksisterende delløsninger?

Hva eksisterer på markedet for øvrig? Søk på nett Spør kunden

Bruk figurer!!

Ønsket situasjon og løsning

Ønsket situasjon Hvordan skal et nytt system lette situasjonen? Skal arbeidsprosesser, org.struktur el.l. endres?

Ønsket løsning Leder til overordnede krav Hvilke bakgrunnsdokumenter/-systemer finnes

hos kunden?

Generelle tips

Skill mellom beskrivelse og evaluering Bruk kravene til å formulere

evalueringskriterier Bruk figurer og tabeller

VIKTIG: Sjekk mot effekt- og resultatmål Gjelder også senere faser! Generelt: Sørg alltid for rød tråd og konsistens i

og mellom fasedokumentene

Eksempel på løsninger av forstudie

Case 1: Dynamisk trafikkinformasjon

Utfordringer

Kunden visste hva de ville ha Eksisterende prosjekt – mye å sette

seg inn i

Disposisjon

Innledning Begrepsavklaring Dagens situasjon Ønsket situasjon Overordnede funksjonelle krav Bakgrunnsdokumenter Eksisterende systemer med evaluering

Begrepsavklaring

En avklaring av begrep som kan være nye for leseren.

Eksempel: Registreringspunkt – et punkt i veien som samler

inn data om trafikksituasjonen i det bestemte punktet

Punktdata – data som samles inn fra registreringspunkt i veien.

Dagens situasjon

Fantes ikke ett system som inneholdt all ønsket funksjonalitet

Ønsket situasjon

Overordnede funksjonelle krav

Systemrelaterte krav Eks: Innhenting og samordning av

trafikkdata Brukerrelaterte krav

Eks: Anbefaling av reiserute på web

Bakgrunnsdokumenter

Relevante dokumenter utlevert av kunde Teknologi Informasjon om prosjektet

Eksisterende systemer/evaluering

Fantes ikke ett system med alle ønskede krav på markedet

Kunden hadde krav om at vi skulle implementere alt selv – ville ikke kjøpe deler av andre system

Mål Få en oversikt av det som eksisterer og

lære av andre

Hva fikk vi ut av forstudiet?

En god dialog med kunden – hva vil de egentlig ha

Dypere forståelse av problemet Evalueringen vår av eksisterende

system var ikke god nok fikk ikke det utbyttet vi kunne ha fått

Case 2: Databaseverktøy for kvantekjemiske resultater

Kunde: Fysikalsk kjemi, NTNU Oppgave: Lage et databasedrevet

administrasjonsverktøy for å ta vare på kvantekjemiske beregninger. Dette innebar parsing av output filer fra beregninger, samt å lagre disse inn i en database.

Utfordringer

Nytt og ukjent fagfelt Kunden hadde begrenset

datakunnskap, vi fikk derfor få føringer på hvordan prosjektet skulle løses.

Disposisjon

Innledning Kvantekjemi Dagens System Forretningsmessige krav Morgendagens system Eksisterende løsninger Evaluering Konklusjon

Kvantekjemi

o Hva er kvantekjemio Kvantekjemiske metodero Viktige begrepero Kjemi på datamaskinen

For å greie å løse oppgaven vår hadde vi behov for å sette oss inn i grunnleggende prinsipper innen kvantekjemi. Vi så på blant annet:

Dagens system (1/2)

Dagens system (2/2)

Problemer med dagens system: For hver beregning som utføres må

kvantekjemikeren manuelt gå igjennom hver outputfil

Finnes ikke noe godt system for å ta vare på og strukturere ulike beregninger

Ikke noe system for å dele resultater med andre

Forretningsmessige krav

Kravnr

Krav

FM-1 Systemet skal tilby en enkel og effektiv måte å administrere og aksessere data fra ulike kjemiske beregninger på.

FM-2 Systemet skal være open source.

FM-3 Systemet skal være mest mulig kostnadseffektivt.

FM-4 Alle verktøy som er nødvendige for å bruke systemet skal være open source og gratis.

FM-5 Systemet skal kunne kommunisere med Zerlock.

FM-6 Systemet skal være mulig å utvide med plugins.

FM-7 Systemet skal ha en god dokumentasjon.

FM-8 Systemet skal kunne ligge både lokalt på en pc og sentralt på en server.

FM-9 Systemet skal både ha webgrensesnitt og kommandogrensesnitt.

FM-10 Systemet skal støtte Linux.

Morgendagens system Kunden hadde ikke tenkt gjennom

detaljer om hvordan systemet skulle være. Vi undersøkte derfor ulike muligheter: Aktører, brukergrensesnitt, sikkerhet,

administrasjon, rettigheter, prosesser og databaser

Vi satte opp tre alternativer til løsning som vi vurderte videre.

Eksisterende løsninger

Metode: Søk på nettet Tips fra kunden

Erfaringer: Brukte for lite tid på denne fasen. Kunne i mye større grad dratt nytte av

programmer som allerede var laget.

Evaluering

Evalueringskriterier med utgangspunkt i forretningsmessige krav.

Laget skjema for evaluering av de ulike systemene, brukte Lav-Middels-Høy som klassifisering om kriteriene var oppfylt.

Evaluerte både våre egne foreslåtte løsninger og de allerede eksisterende løsningene etter samme evalueringskriterier.

Våre erfaringer

Et grundig forstudie gjorde overgangen til kravspesifikasjon lettere.

Vi fokuserte for lite på eksisterende systemer. Dette førte muligens til et dårligere sluttprodukt.

Vi lærte mye om fagfeltet, noe vi dro nytte av i senere faser.

KRAVSPESIFIKASJON

Hva er en kravspesifikasjon?

En detaljert beskrivelse av hva som skal lages og i hvilket miljø man skal lage produktet.

En kontrakt mellom gruppen og kunden om hva som skal lages.

En spesifisering av hva man kom fram til i forstudiet.

En forberedelse til konstruksjonsfasen.

Hva bør være med i kravspesifikasjonen?

Oversikt over systemet Produktperspektiv (illustrer med figur) Produkt funksjonalitet (overordnet) Tekniske begrensninger Antagelser og avhengigheter Utvidelser

Funksjonelle krav Brukstilfeller

Ikke-funksjonelle krav Ytelse, kvalitet, lett å bruke og dokumentasjon

Krav til GUI Prototyper

Hvordan finne krav?

Spør kunden. Alltid viktig å ha god kontakt med kunden under denne fasen.

Se på hva dere fant ut i forstudiet. Viktig at kravspesifikasjon stemmer overens med forretningsmessige krav og valg av løsning fra forstudie.

Tenk over hva som skal være mulig eller ikke mulig å gjøre i systemet.

Eksempel på løsning av kravspesifikasjon

Vår løsning

Kunde: Telenor FoU Oppgave: Lage en teletjeneste over

ParlayX (avstemming via SMS) Oppsett: IEEE-standarden for

kravspesifikasjon Metode: Iterativ prosess.

Hva skal være med?

Oversikt over hele systemet Ikke-funksjonelle krav

Beskrivelse Oppsummering i tabell

Funksjonelle krav Tabell med alle krav Brukergrensesnitt Beskrivelse ved hjelp av use-case

Oversikt over systemet

DFD i kravspek

Sekvensdiagram i kravspek

Eksempel på ikke-funksjonellekrav

3.2.5.1 Ease of use for End UsersEnd users are the people initiating or participating in a vote session.

[NREQ: 4] To initiate a vote session should require no more than five minutes of instruction, or spending five minutes reading the documentation web page.

[NREQ: 5] To participate in a vote should require no more than three minutes of instruction, or spending three minutes reading the documentation webpage.

Eksempel på funksjonelle krav

Eksempel på brukstilfelle

Tips

Nummerer alle krav Sjekk at alle krav er målbare/testbare Lag presise krav Sjekk at det er rød tråd fra prosjektdirektiv

og forstudie Sjekk at dere er konsistent med ordbruk Hold god kontakt med kunden og sjekk at

dere snakker det samme språket!

Spørsmål?