Forstudie og Kravspesifikasjon

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

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

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

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?