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

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 In practice, requirements and design are inseparable A system architecture may be designed to structure the requirements; The system may inter-operate with other systems that generate design requirements; The use of a specific architecture to satisfy non-functional requirements may be a domain requirement. This may be the consequence of a regulatory requirement

Krav: Hva? Beskriver Abstraksjonsnivå Grunnlag 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

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

Kravtyper Krav Brukerkrav Systemkrav 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.

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.

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.

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

Types of nonfunctional requirement

Metrikker for å spesifiser ikke-funksjonelle krav Figure 4.5 Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems

Kravprosess Utforskning og analyse Validering Forvaltning 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

Intervjuer Oppdagelse Formelle eller uformelle intervjuer TDT4180 Menneske-maskin interaksjon Intervjuer Oppdagelse 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. Interviews in practice Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Interviews are not good for understanding domain requirements Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.

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)

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 nye egenskaper som bør bli lagt til et system. Bruker mye tid Etnografi + prototyping Utviklingsresultater fra prototyper for ubesvarte spørsmål, kan fokusere den etnografiske analysen.

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

Reviewteknikker Systematisk, manuell analyse av krav. Spørsmål 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)?

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 er sjelden de samme menneskene. Human Computer Interaction Programvare (Systemarbeid og menneske-maskin interaksjon)

Konklusjon Er dette en funksjonell krav? 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»