Forstudie og Kravspesifikasjon Anne Kristine Ellen Gunn Marie Olaug

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 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. Forstudiet vårt ble derfor litt annerledes enn mange andre sine. Måtte bruke mer ressurser på å sette oss inn i det nye fagfeltet. Kunden ble ingen ressursperson på det datatekniske. Dette måtte vi i veldig stor grad vurdere selv.

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

Kvantekjemi For å greie å løse oppgaven vår hadde vi behov for å sette oss inn i grunnleggende prinsipper innen kvantekjemi. Vi så på blant annet: Hva er kvantekjemi Kvantekjemiske metoder Viktige begreper Kjemi på datamaskinen Kvantekjemi: Hva skiller kvantekjemi fra vanlig kjemi Hva slags kjemiske egenskaper man ønsker å finne Metoder: Vi satte oss inn i en del kvantekjemiske beregningsmetoder. Dette fikk vi stor nytte av da vi senere skulle forsøke å forstå de data som kom ut av beregningene. Begreper: Viktig for vår egen forståelse, samt bedre kommunikasjonen med kunden. Kjemi på datamaskinen: Lettere å relatere ting opp mot vår oppgave

Dagens system (1/2) Vi benyttet en tekstlig beskrivelse + at vi understøttet denne med APM modeller. Det var viktig å forstå arbeidsprosessene, da dette var noe som vi skulle forsøke å endre på Forberedelser, gjøre beregninger, hente ut relevant informasjon, data analyse Utdypet prosess A3

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 På bakgrunn av modellen på forrige slide kom vi fram en punktliste med problemer ved dagens arbeidsmetoder. Dette gav oss grunnlag for å sette opp en liste med krav til vår løsning.

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. Brukte tabell form  oversiktlig Nummererte kravene  lett å referere til senere Viktig å ha målbare krav Dårlig eksempel: FM-3 og FM-7

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. Kunden hadde tenkt lite igjennom alle detaljer rundt systemet og hadde ingen eller liten formening om hvordan dette skulle være. Vi satte derfor opp en liste med parametre og hvordan disse kunne varieres. Hadde tett dialog med kunden hele tiden  Fikk han til å tenke gjennom hva han ønsket Satte opp tre alternativer til løsning som vi evaluerterte nærmere

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. Dette er nok den delen av forstudiet vi gjorde dårligst. Vi hadde allerede tidlig i prosjektet begynt å snakke om hvordan vi hadde planlagt å implementere prosjektet. Dette gjorde nok at vi ble fastlåst i en tankegang om hvilken løsning vi skulle gå for allerede før vi hadde starta markedsundersøkelsen. Opplevde hele tiden at det på senere tidspunkt i prosjektet dukket opp løsninger som vi kunne dratt nytte av eller kanskje til og med benyttet.

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. Alle evalueringskriteriene kunne spores tilbake til et forretningsmessig krav. Opptil fire kriterier for ett krav. Mer spesifisering av kravene. Vurderte både egne og eksisterende løsninger ut fra samme kriterier, noe som sikkert hadde vært veldig nyttig hadde vi vært mer grundig på å undersøke eksisterende løsninger.

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. Når vi skulle ta fatt på kravspesifikasjonen hadde vi mer oversikt over hva systemet skulle gjøre Kunden hadde tenkt mer igjennom hva han faktisk ønska, hva var viktig, hva var mindre viktig Kunden hadde også ”kjøpt” vår løsning og var veldig gira på den Brukte mindre tid på kravspesifikasjonen Lettere å unngå misforståelser mellom oss og kunde Vi hadde en oppgave der vi var avhengig av å ha lært en del om kvantekjemi Særlig i design og implementasjonen dro vi stor nytte av det vi lærte oss i forstudiet. Unngikk å bruke mye tid på å lære oss kvantekjemi senere i prosjektet, da hadde vi det veldig hektisk med andre ting!

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 Oversikt over systemet inneholder typisk: Produktperspektiv –hvordan ser produktet fysisk ut i sitt miljø Produkt funksjonalitet –hvordan fungerer produktet overordnet. Bruker –hvordan er brukeren av systemt Tekniske begrensninger Antagelser og avhengigheter Utvidelser Ikke funksjonelle krav: ytelse, kvalitetskrav, Lett å bruke, dokumentasjon

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. Tre inkrementer i den iterative prosessen Først en enkel versjon Deretter legge på mer funksjonalitet. Alltid mulig å leverer et produkt som fungerer men som kanskje mangler funksjonalitet.

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 Users End 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 web page.

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?