Kravhåndtering. INF1050: Gjennomgang, uke 03

Transkript

1 Kravhåndtering INF1050: Gjennomgang, uke 03

2 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle krav Kravspesifikasjon

3 Kravhåndtering: Bakgrunn Hva? Prosess for å identifisere / analysere / spesifisere krav til et system Sentral del i de aller fleste utviklingsprosjekter Hvorfor? Vi utvikler IT-systemer for å løse et problem / Identifisere og utnytte muligheter Kravene forteller oss noe om hva som skal lages Kostbart å rette feil i kravene etter systemleveranse Utilstrekkelig kravhåndtering Viktigste årsak for problemer i systemutviklingsprosjekter Standish-rapporten Kravendringer vil alltid forekomme

4 Kravhåndteringsprosessen Forstudie / Målanalyse Kost/nytte-analyser Risikoanalyser Gevinstrealisering Kravinnsamling og kravanalyse Hva ønsker interessentene seg? Hva har de behov for? Prioritering av kravene Kravspesifisering Utgangspunkt for anbud og kontrakt Mellom kunde og leverandør Utgangspunkt for design, implementasjon og testing Utgangspunkt for estimater (tid og kostnad) Validering av kravspesifikasjonen Uttrykker kravspesifikasjonen det kunden og interessentene faktisk ønsker seg?

5 Kravhåndteringsprosessen Håndtering av kravendringer Brukere oppdager nye behov etter at systemet tas i bruk Formell prosess for vurdering og eventuell gjennomføring av foreslåtte endringer Hvilken endring foreslås? Hvem foreslår endringen? Vurdering av foreslått endring / Konsekvensanalyse Beslutning om endringen skal implementeres Hvem skal følge opp endringene? Kravspesifikasjonen som grunnlag for testing Kravspesifikasjonen sier noe om systemets funksjonalitet og oppførsel Kan brukes som grunnlag for testinnsatsen

6 Saksstudie: Ruter Ruter Har en applikasjon for kjøp av ulike typer billetter Betalingsmåter: Visa, MasterCard, Vipps, MobilePay, mcash, Strex Kunde Den som kjøper / bestiller produktet Ruter Kunde Sluttbruker av produktet De som bruker applikasjonen

7 Gjennomgang av ukesoppgaver Ukens tema : Aspekter ved systemutvikling

8 Oppgave 1(a) Hva er en kravspesifikasjon?

9 Oppgave 1(a): Løsningsforslag Hva er en kravspesifikasjon? Et dokument som spesifiserer hva som skal lages Bruker- og systemkrav Ikke et designdokument Sier ingenting om hvordan oppgaven skal løses Ofte en del av kontrakten Ulike standarder brukes Eksempel: IEEE

10 Oppgave 1(a): Løsningsforslag Hva er en kravspesifikasjon? Brukerkrav Uttrykkes på naturlig språk / diagrammer Viser ønsket funksjonalitet og hvilke føringer som gjelder (kvalitetsegenskaper) Kunden skal kunne forstå disse kravene uten problemer Systemkrav Detaljert beskrivelse av systemfunksjoner og hvilke føringer som gjelder Definerer hva som skal implementeres Basis for kontrakt mellom kunde og leverandør

11 Oppgave 1(b) Hvorfor er det nødvendig å lage en kravspesifikasjon?

12 Oppgave 1(b): Løsningsforslag Hvorfor er det nødvendig å lage en kravspesifikasjon? Basis for anbud Kan tolkes på ulike måter Skape interesse og tiltrekke seg leverandører som kan møte behovet Basis for kontrakt / design / implementasjon Leverandør og kunde blir enige om hva som skal lages Spesifiserer ytelsen Skape felles forståelse av systemet / enighet om hva som skal leveres Forhindre eventuelle konflikter Ulike forventninger

13 Oppgave 2 Gi en definisjon av begrepet interessent. List opp noen interessenter for en applikasjon som finner restauranter i nærheten av der du befinner deg.

14 Oppgave 2: Løsningsforslag Gi en definisjon av begrepet interessent. Interessent Mengde personer / grupper / organer som har interesse av systemet Blir påvirket av eller påvirker systemets utvikling og bruk Både direkte og indirekte Interessenter både påvirker og påvirkes av kravspesifikasjonen Fire hovedkategorier Kunde: Kjøper / bestiller produktet Bruker: Sluttbruker av produktet Leverandør: De som utvikler produktet Andre: Øvrige

15 Oppgave 2: Løsningsforslag Eksempler på interessenter for appen

16 Oppgave 3(a) Hva er funksjonelle og ikke-funksjonelle krav?

17 Oppgave 3(a): Løsningsforslag Hva er funksjonelle og ikke-funksjonelle krav? Funksjonelle krav Definerer HVA systemet skal gjøre Spesifikke funksjoner og tjenester systemet skal ha / oppfylle Hvordan systemet skal reagere på ulike typer input / stimuli Nyttig å fortelle hva systemet ikke skal gjøre Format Systemet skal... / Systemet bør (nice to have)...

18 Oppgave 3(a): Løsningsforslag Hva er funksjonelle og ikke-funksjonelle krav? Ikke-funksjonelle krav Definerer HVORDAN systemet skal innfri de funksjonelle kravene Sier noe om hvilke kvalitetsattributter systemet skal ha Egenskaper Hvordan skal systemet oppføre seg? Må være målbare Format System skal være [egenskap]

19 Oppgave 3(a): Løsningsforslag Hva er funksjonelle og ikke-funksjonelle krav? Sommerville: Figur 4.3 (p. 88)

20 Saksstudie: Ruter Eksempler på funksjonelle og ikke-funksjonelle Funksjonelle krav Systemet skal kunne vise en oversikt over brukerens kjøpshistorikk Systemet skal gi beskjed når det gjenstår under 24 timer til en periodebillett utløper Systemet skal tilby funksjonalitet for valg av billettype Systemet skal tilby hurtigkjøp av tidligere valgte billetter Ikke-funksjonelle krav En ny kunde skal kunne betale for en billett på under tre minutter Systemet skal kunne håndtere brukere samtidig Systemet skal utvikles ved hjelp av smidige utviklingsmetoder

21 Oppgave 3(b) Skriv fem funksjonelle krav til appen beskrevet i oppg. 2

22 Oppgave 3(b): Løsningsforslag Skriv fem funksjonelle krav til appen beskrevet i oppg. 2

23 Oppgave 3(c) Skriv fem ikke-funksjonelle krav til appen beskrevet i oppg. 2

24 Oppgave 3(c): Løsningsforslag Skriv fem ikke-funksjonelle krav til appen beskrevet i oppg. 2 Hva er problemet med de overnevnte kravene? Kan de måles?

25 Oppgave 3(c): Løsningsforslag Skriv fem ikke-funksjonelle krav til appen beskrevet i oppg. 2

26 Oppgave 3(d) Beskriv hvordan du kan evaluere de ikke-funksjonelle kravene

27 Oppgave 3(d): Løsningsforslag Beskriv hvordan du kan evaluere de ikke-funksjonelle kravene Evaluering ikke-funksjonelle krav Kravene må være målbare Unngå at utviklere tolker kravene på egen måte Definer krav som er direkte målbare Eksempelkrav: Et system skal kunne håndtere brukere samtidig Generelle krav, men spesifiser konkrete metrikker i evalueringen Eksempelkrav: Systemet skal være raskt Metrikk: En ny side skal laste inn på under tre sekunder

28 Oppgave 3(d): Løsningsforslag Beskriv hvordan du kan evaluere de ikke-funksjonelle kravene 1. Krav om responstid Gjennomfør tester der man måler tid Flere tester under ulike dekningsforhold 2. Krav om brukervennlighet Brukertester Mål tid som brukes 3. Krav om plattformuavhengighet Tester gjennomføres på ulike plattformer

29 Oppgave 3(d): Løsningsforslag Beskriv hvordan du kan evaluere de ikke-funksjonelle kravene 4. Krav om kapasitet Gjennomfør stresstester Sjekk hvor mye systemet tåler Når nås bristepunktet? 5. Krav til dokumentasjon Ja/Nei-spørsmål Sjekkes direkte

30 Oppgave 4 Hva vil det si å validere et system og hvorfor er det viktig?

31 Oppgave 4: Løsningsforslag Hva vil det si å validere et system og hvorfor er det viktig? Validering Har man utviklet det systemet som kunden faktisk ønsket seg? Kravspesifikasjoner kan valideres Beskriver kravspesifikasjonen det kunden gir uttrykk for? Avdekker avvik i forventninger og spesifikasjon Kostbart å endre et ferdigstilt system

32 Oppgave 4: Løsningsforslag Hva vil det si å validere et system og hvorfor er det viktig?

33 Oppgave 5(a) Hva er en brukerhistorie?

34 Oppgave 5(a): Løsningsforslag Hva er en brukerhistorie? Brukerhistorier Beskriver hva brukeren av et system ønsker å få ut av systemet Elementer Brukerens rolle Ønsket funksjon Nytteverdi av funksjonen Format Som [ROLLE] ønsker jeg [FUNKSJON] for å oppnå [NYTTEVERDI]

35 Oppgave 5(b) Nevn fordeler ved å bruke denne teknikken for å beskrive krav

36 Oppgave 5(b): Løsningsforslag Nevn fordeler ved å bruke denne teknikken for å beskrive krav Fordeler ved brukerhistorier Krever ingen teknisk kompetanse for å forstå kravet Skjuler kompleksitet Kravene uttrykkes på en kort og konsis måte Bruker Hver er kravet tiltenkt? Funksjon Hva er den faktiske funksjonen som etterspørres Nytteverdi Forstår nødvendigheten av ønsket funksjon

37 Oppgave 5(c) Drøft utfordringer ved å benytte brukerhistorier beskrevet på lapper på en tavle i store, smidige utviklingsprosjekter

38 Oppgave 5(c): Løsningsforslag Drøft utfordringer ved å benytte brukerhistorier beskrevet på lapper på en tavle i store, smidige utviklingsprosjekter Utfordringer Kaotisk med mange lapper som hoper seg opp Krever at man er tilstede for å kunne se hva som står på tavlen Generelle utfordringer Kan tolkes på flere måter Skjuler kompleksitet Funksjonen kan være vanskeligere å implementere enn antatt Skjuler underliggende krav Hva er den faktiske betydningen av brukerhistorien?

39 Oppgave 5(d) Skriv noen brukerhistorier for appen beskrevet i oppg. 2

40 Oppgave 5(d): Løsningsforslag Skriv noen brukerhistorier for appen beskrevet i oppg. 2

41 Oppgave 6 I systemutviklingsprosjekter med tett kundemedvirkning er det en fare for at kunden blir påvirket av utviklingsteamet og adopterer deres perspektiv. Da kan brukernes behov bli tillagt for liten vekt.

42 Oppgave 6(a) Foreslå tre måter å redusere dette problemet på

43 Oppgave 6(a): Løsningsforslag Foreslå tre måter å redusere dette problemet på Unngå at kunden blir påvirket av utviklerne Ha ulike representanter for kunden som deltar Fremfor én fast representant Hold tekniske diskusjoner til et minimum Kunden våger ikke å si at han/hun ikke forstår Går med på endringene Unngå at kunden blir en del av teamet Involver kunden kun der det er nødvendig

44 Oppgave 6(b) Diskuter fordeler og ulemper med kundeinvolvering

45 Oppgave 6(b): Løsningsforslag Diskuter fordeler og ulemper med kundeinvolvering Fordeler Raske tilbakemeldinger Sørger for at systemet ivaretar brukerens behov Ulemper Krever tid og ressurser av kunden Krever at kunden er tilgjengelig Krever at kunden har en god domeneforståelse

46 Oppgave 7 Forklar hvorfor det er nødvendig med to kravaktiviteter i prosessen for gjenbruksbasert systemutvikling

47 Oppgave 7: Løsningsforslag Forklar hvorfor det er nødvendig med to kravaktiviteter i prosessen for gjenbruksbasert systemutvikling Gjenbruksbasert systemutvikling Eksisterende programvare brukes på nytt i nye systemer Varierende grad Komponentbasert utvikling Benytter seg av komponenter fra ulike pakker Tjenesteorientert utvikling Benytter seg av tjenester som finnes på nett / i skyene

48 Oppgave 7: Løsningsforslag Forklar hvorfor det er nødvendig med to kravaktiviteter i prosessen for gjenbruksbasert systemutvikling Sommerville: Figur 2.3 (p. 35)

49 Oppgave 7: Løsningsforslag Forklar hvorfor det er nødvendig med to kravaktiviteter i prosessen for gjenbruksbasert systemutvikling Standard kravinnsamling og spesifikasjon Bestemmer hva som skal lages Komponentanalyse Undersøker hva som finnes på markedet Tilpasning av krav Ønsket funksjonalitet vil ofte variere fra det som allerede finnes Kravene tilpasses for å kunne ta utgangspunkt i den eksisterende programvaren

50 Til slutt Husk å registrere deg på en gruppe! 2-4 studenter per gruppe Alternativ 1 Registrer deg som enkeltperson og få tildelt gruppe Send e-post til den aktuelle gruppelæreren Alternativ 2 Registrer hele gruppen på Devilry

51 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

52 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

53 Takk for meg Neste uke : UML-modellering, kravhåndtering og use case