forstudie og kravspesifikasjon
DESCRIPTION
Forstudie og Kravspesifikasjon. Av 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 - PowerPoint PPT PresentationTRANSCRIPT
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?