Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Kapittel 4 – Kravhåndtering/ Requirements Engineering Carl-Fredrik Sørensen.

Liknende presentasjoner


Presentasjon om: "Kapittel 4 – Kravhåndtering/ Requirements Engineering Carl-Fredrik Sørensen."— Utskrift av presentasjonen:

1 Kapittel 4 – Kravhåndtering/ Requirements Engineering Carl-Fredrik Sørensen

2 Tema for forelesningen Krav –Bruker og system –Funksjonelle og ikke- funksjonelle Kravspesifikasjons- dokument Kravprosesser –Utforskning og analyse –Validering –Forvaltning Gjesteforelesning: Per Håkon Meland, SINTEF Spesifikasjon Utvikling Validering Evolusjon

3 Krav: Hva? Beskriver Systemtjenester (Funksjoner) Begrensninger av hvordan systemet brukes og utvikles (ikke-funksjonelle eller kvalitetskrav) Abstraksjonsnivå høyt nivå detaljert matematisk Grunnlag for et anbud på en kontrakt - må derfor være åpen for tolkning; grunnlag for selve kontrakten - må derfor defineres i detalj

4 4 Hvem -- Interessenter Kunde – spesifisere & foreslå endringer Manager – planlegge et tilbud og prosess Programvareutvikler – forstå hva som skal utvikles Testingeniør – definere og kjøre tester Vedlikeholdsingeniør – Forstå systemet for å implementere endringer Brukere ++

5 5 Kravtyper Krav –Utsagn i et naturlig språk + diagrammer/figurer Brukerkrav –Beskrivelse av tjenester som systemet skal tilby –Operasjonelle begrensninger/restriksjoner. Systemkrav –Detaljerte beskrivelser av systemets funksjoner, tjenester og operasjonelle begrensninger/restriksjoner. –Definerer hva som skal bli utviklet. –Vil danne grunnlag for kontrakt mellome en klient og en kontraktør.

6 6 Eksempel på funksjonelle krav – LMS Det er mulig for studenter å melde seg selv inn i grupper. Systemet har funksjonalitet for deling av filer med håndtering av versjoner og alternativt sperring for samtidig editering. Systemet støtter mulighet for å kommentere publisert informasjon (f. eks. nyhetsmeldinger, meldinger om undervisningsaktiviteter, etc.) Kommentarmulighet kan slås av/på av den som publiserer informasjonen. Systemet tilbyr visning av studentens egen ePortfolio fra studentens hovedside (Min Side). Innebygde editeringsverktøy støtter fonetiske og matematiske spesialtegn.

7 7 Ikke-funksjonelle krav Definerer systemegenskaper og begrensninger f.eks. pålitelighet, responstid og lagringsbehov. Prosesskrav kan også spesifiseres, f.eks. bruk av IDE, programmeringsspråk eller utviklingsmetode. Ikke-funksjonelle krav kan være mer kritisk enn funksjonelle krav. Hvis disse ikke er oppfylt, kan systemet bli ubrukelig.

8 8 Eksempel på ikke-funksjonelle krav – LMS Systemet støtter FEIDE for autentisering og autorisering av brukere ved pålogging. Systemet lagrer læringsobjekter på en slik måte at det er mulig å hente ut disse gjennom API’er og XML-baserte protokoller fra andre IKT-løsninger ved NTNU. Systemet støtter generelt tilgang / operasjoner fra mobile enheter (smarttelefon / nettbrett). Beskriv i Bilag 2 hvilke funksjoner / operasjoner som støttes. Elektroniske brukertjenester skal være universelt utformet, og brukerne skal kunne benytte disse uten hensyn til tid, sted og kanal. Beskriv hvordan den foreslåtte løsningen tilfredsstiller dette. IKT-løsningen kan integreres med hjelpemiddelteknologi (for eksempel skjermoppbrekking, forstørrelse, talesyntese).

9 9 Types of nonfunctional requirement 9

10 10 Metrikker for å spesifiser ikke- funksjonelle krav Figure 4.5 PropertyMeasure SpeedProcessed transactions/second User/event response time Screen refresh time SizeMbytes Number of ROM chips Ease of useTraining time Number of help frames ReliabilityMean time to failure Probability of unavailability Rate of failure occurrence Availability RobustnessTime to restart after failure Percentage of events causing failure Probability of data corruption on failure PortabilityPercentage of target dependent statements Number of target systems

11 11 Kravprosess Utforskning og analyse –Oppdage krav Interagere med interessenter/stakeholders for å oppdage deres krav og domenekrav. –Kravklassifisering og logisk organisering –Prioritering og forhandling (løse konflikter) –Kravspesifikasjon (dokumentasjon) Validering Forvaltning

12 12 Intervjuer Formelle eller uformelle intervjuer Intervjutyper –Lukkede intervjuer basert på en pre-bestemt spørsmålsliste –Åpne intervjuer hvor forskjellige problemstilliner blir utforsket sammen med interessentene. Effektive intervjuer –Vær åpen og fordomsfri, unngå forutinntatte ideer om kravene og vær villig til å lytte til interessentene. –Påvirk intervjuobjektene for å få diskusjoner ved å gi spørsmål som springbrett, et kravforslag eller ved å arbeide sammen på en prototypsystem. Oppdagelse TDT4180Menneske-maskin interaksjon

13 13 Scenarier Scenarier er eksempler fra det virkelige liv om hvordan et system kan bli brukt. De bør inkludere –starttilstand/situasjon; –den normale flyt av hendelser; –hva som kan gå galt; –informasjon om andre samtidige aktiviteter; –stopptilstand (når scenariet er ferdig)

14 14 Etnografi Social science method : observere og analyser hvordan folk faktisk arbeider. Fordeler : –Folk trenger ikke å forklare eller beskrive sitt arbeid. –Viktige sosiale og organisatoriske faktorer kan bli observert. –Etnografiske undersøkelser har vist at arbeid normalt sett er rikere og mer komplekst enn det som blir foreslått med enklere modeller. –Etnografi er effektiv for å forstå eksisterende prosesser. Ulemper : –Kan ikke identifisere ny e egenskaper som bør bli lagt til et system. –Bruker mye tid Etnografi + prototyping –Utviklingsresultater fra p rototyper for ubesvarte spørsmål, kan fokusere den etnografiske analysen.

15 Kravvalidering 1.Validitet. Gir systemet de funksjonene som best støtter kundens behov? 2.Konsistens. Er det konflikter mellom forskjellige krav? 3.Kompletthet. Er alle funksjoner som kreves av kunden, inkludert? 4.Realisme. Kan kravene bli implementert gitt tilgjengelig budsjett og teknologi 5.Verifiserbarhet. Kan kravene bli sjekket?

16 Reviewteknikker Systematisk, manuell analyse av krav. Prototyping Test-case generering Spørsmål –Q1: Er krav realistisk testbart? – Q2: Er krav ordentlig forstått? – Q3: Er opprinnelsen til kravet klart formulert? (Traceability)? – Q4: Kan kravet bli endret uten en stor påvirkning på andre krav (Adaptability)?

17 17 Forvaltning av krav administrere endring av krav under spesifikasjon og utvikling. –Nye krav oppdages mens systemet er under utvikling, og etter det har tatt i bruk. Opprettholde relasjoner mellom krav som har en avhengighet Roller –de som betaler for et system (kunder) –brukere av dette systemet Software engineering Human Computer Interaction Programvare (Systemarbeid og menneske-maskin interaksjon)

18 18 Konklusjon Bruker- og systemkrav Hvordan ser et kravdokument ut? Tekst eller diagrammer? Standarder f.eks IEEE-standarden? Prosess –Utforskning og analyse –Validering (prototyping, test generasjon, gjennomgang)? –Endringsledelse – change management Er dette en funksjonell krav? –«Hver medarbeider bruker systemet skal være entydig identifisert av hans eller hennes 8-sifret ansattnummer»


Laste ned ppt "Kapittel 4 – Kravhåndtering/ Requirements Engineering Carl-Fredrik Sørensen."

Liknende presentasjoner


Annonser fra Google