Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Forstudie og Kravspesifikasjon Av Anne Kristine Ellen Gunn Marie Olaug.

Liknende presentasjoner


Presentasjon om: "Forstudie og Kravspesifikasjon Av Anne Kristine Ellen Gunn Marie Olaug."— Utskrift av presentasjonen:

1 Forstudie og Kravspesifikasjon Av Anne Kristine Ellen Gunn Marie Olaug

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

3 Fasene Forstudie Kravspesifikasjon Konstruksjon Implementering Testing Forstudiet danner grunnlaget for alle kommende faser!

4 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

5 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!)

6 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

7 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!!

8 Ø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?

9 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

10 Eksempel på løsninger av forstudie

11 Case 1: Dynamisk trafikkinformasjon

12 Utfordringer Kunden visste hva de ville ha Eksisterende prosjekt – mye å sette seg inn i

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

14 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.

15 Dagens situasjon Fantes ikke ett system som inneholdt all ønsket funksjonalitet

16 Ønsket situasjon

17 Overordnede funksjonelle krav Systemrelaterte krav  Eks: Innhenting og samordning av trafikkdata Brukerrelaterte krav  Eks: Anbefaling av reiserute på web

18 Bakgrunnsdokumenter Relevante dokumenter utlevert av kunde  Teknologi  Informasjon om prosjektet

19 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

20 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

21 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.

22 Utfordringer Nytt og ukjent fagfelt Kunden hadde begrenset datakunnskap, vi fikk derfor få føringer på hvordan prosjektet skulle løses.

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

24 Kvantekjemi o Hva er kvantekjemi o Kvantekjemiske metoder o Viktige begreper o 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:

25 Dagens system (1/2)

26 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

27 Forretningsmessige krav Kravn r Krav FM-1Systemet skal tilby en enkel og effektiv måte å administrere og aksessere data fra ulike kjemiske beregninger på. FM-2Systemet skal være open source. FM-3Systemet skal være mest mulig kostnadseffektivt. FM-4Alle verktøy som er nødvendige for å bruke systemet skal være open source og gratis. FM-5Systemet skal kunne kommunisere med Zerlock. FM-6Systemet skal være mulig å utvide med plugins. FM-7Systemet skal ha en god dokumentasjon. FM-8Systemet skal kunne ligge både lokalt på en pc og sentralt på en server. FM-9Systemet skal både ha webgrensesnitt og kommandogrensesnitt. FM-10Systemet skal støtte Linux.

28 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.

29 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.

30 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.

31 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.

32 KRAVSPESIFIKASJON

33 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.

34 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

35 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.

36 Eksempel på løsning av kravspesifikasjon

37 Vår løsning Kunde: Telenor FoU Oppgave: Lage en teletjeneste over ParlayX (avstemming via SMS) Oppsett: IEEE-standarden for kravspesifikasjon Metode: Iterativ prosess.

38 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

39 Oversikt over systemet

40 DFD i kravspek

41 Sekvensdiagram i kravspek

42 Eksempel på ikke- funksjonellekrav 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.

43

44 Eksempel på funksjonelle krav

45 Eksempel på brukstilfelle

46 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!

47 Spørsmål?


Laste ned ppt "Forstudie og Kravspesifikasjon Av Anne Kristine Ellen Gunn Marie Olaug."

Liknende presentasjoner


Annonser fra Google