IN Introduksjon til design, bruk, interaksjon Krav og behov

Transkript

1 IN Introduksjon til design, bruk, interaksjon Krav og behov 4. september 2018 Institutt for Informatikk, Universitetet i Oslo joshi@ifi.uio.no IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 1

2 Dagens forelesning Praktisk informasjon Obligatorisk oppgave 2 Kapittel 10: Å forstå og definere krav Hva skiller krav og behov? Hvordan bruke datainnsamling til å etablere krav? Oppgavebeskrivelse og oppgaveanalyse IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 2

3 Kontaktstudent for IN1050 Jonatan Indahl Rollheim Henvendelser dere ønsker å ta opp anonymt forbedringspotensialer, klager, ros etc. Blir invitert på gruppelærermøte i løpet av september E-post: jonatair@student.matnat.uio.no IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 3

4 Ukene fremover Det er mulig vi skyver litt på forelesningen som er ment å holdes på Sundvollen men det er normale gruppetimer alle uker gruppetimene de neste ukene blir ekstra viktige med tanke på oblig 1 og 2 Vi sender beskjed på e-post og på emneside når vi vet hvordan det blir best for dere IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 4

5 Obligatorisk oppgave IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 5

6 Obligatorisk oppgave IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 6

7 Forrige uke: Datainnsamling hva og hvordan Bruk Kognisjon som et eksempel på et fagfelt som har hjulpet oss med å se hvordan vi kan forstå bruk Og hvordan forståelse av kognitive prosesser får implikasjoner for vårt design og vår utvikling Hva er data og hvordan går vi frem for å samle det inn? Eksempler på metoder for datainnsamling: intervju, observasjon og spørreskjema Hvordan planlegge og strukturere et intervju Dagens tema: Hvorfor trenger vi å samle inn data i det hele tatt? Hva ønsker vi å lære mer om og hvor skal vi med all dataen? IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 7

8 Nøkkelbegreper fra dagens forelesning Behov s. 12 Krav s. 17 Funksjonelle og ikke-funksjonelle krav s. 22 Personas s. 26 Domene s. 56 Scenario s IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 8

9 Hvor starter vi? 1. Designe et helt nytt system 2. Videreutvikle noe som finnes de fleste velger det siste eller en blanding (kjent konsept i ny drakt) Men hva finnes allerede der ute? Brukere Brukskontekst Innarbeidede rutiner, praksis, vaner etc. Derfor må vi forstå bruk, brukere og brukskontekst når vi foreslår nye eller alternative løsninger IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 9

10 Krav og behov Til nå har pensum dreid seg om samspillet mellom mennesker og maskiner og sånn skal det fortsette, men vi trenger litt flere begreper å lene oss på Vi skal lære oss å skille mellom språket, begrepene og antagelsene vi gjør når vi snakker om: Systemer Faglige begreper Teknisk språk Brukere Løsrevet fra spesifikke teknologier eller andre mennesker Dagligdags, ofte ikke-teknisk, språk Krav stilles til maskiner Behov avdekkes hos mennesker IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 10

11 Selvrealiseringsbehov Personlig, åndelig, kreativt, moral, spontanitet, måloppnåelse Anerkjennelsesbehov Selvrespekt, status, aksept, respekt, verdighet Sosiale behov Vennskap, familie, nærhet, intimitet, tilhørighet, kjærlighet Trygghetsbehov Sikkerhet, stabilitet, husly, beskyttelse, ressurser, helse, frihet, lover Fysiske behov Sult, tørste, søvn, åndedrett, sex, varme IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 11

12 Behov innen HCI og UCD Definisjoner: - Behov Behov beskriver hva vi som mennesker helt fundamentalt trenger i livet Hjelper oss med å forstå menneskers grunnleggende/iboende atferd og motivasjon Kontekstualiserer underliggende motivasjon for ønsker, verdier, preferanser etc. og er uavhengig av teknologi og andre mennesker Mye av vår forståelse rundt menneskelige behov er lånt fra psykologien (f.eks. Maslows behovspyramide) Eksempler på behov: Trygghet Mestring Forflytning Kommunikasjon Tilbakemelding IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 12

13 Eksempel: Selvrealiseringsbehov Personlig, åndelig, kreativt, moral, spontanitet, måloppnåelse Informatikkutdanning Anerkjennelsesbehov Selvrespekt, status, aksept, respekt, verdighet Sosiale behov Vennskap, familie, nærhet, intimitet, tilhørighet, kjærlighet Trygghetsbehov Sikkerhet, stabilitet, husly, beskyttelse, ressurser, helse, frihet, lover Fysiske behov Sult, tørste, søvn, åndedrett, sex, varme IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 13

14 Eksempel: Selvrealiseringsbehov Personlig, åndelig, kreativt, moral, spontanitet, måloppnåelse Sosiale medier Anerkjennelsesbehov Selvrespekt, status, aksept, respekt, verdighet Sosiale behov Vennskap, familie, nærhet, intimitet, tilhørighet, kjærlighet Trygghetsbehov Sikkerhet, stabilitet, husly, beskyttelse, ressurser, helse, frihet, lover Fysiske behov Sult, tørste, søvn, åndedrett, sex, varme IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 14

15 Selvrealiseringsbehov Personlig, åndelig, kreativt, moral, spontanitet, måloppnåelse Anerkjennelsesbehov Selvrespekt, status, aksept, respekt, verdighet Sosiale behov Vennskap, familie, nærhet, intimitet, tilhørighet, kjærlighet Trygghetsbehov Sikkerhet, stabilitet, husly, beskyttelse, ressurser, helse, frihet, lover Fysiske behov Sult, tørste, søvn, åndedrett, sex, varme IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 15

16 Vi må grave for å avdekke underliggende behov Vi blir ofte så opptatt av løsningen i seg selv og de umiddelbare funksjonene som tilbys at vi glemmer «hvorfor»-spørsmålet En vanlig teknikk benyttet under datainnsamling for å grave er «5 Whys» Problem: hodetelefonene fungerer ikke 1. hvorfor? fordi ledningen er ødelagt 2. hvorfor? fordi kablingen i ledningen er ødelagt 3. hvorfor? fordi det er oppstått brudd på jordingskabelen 4. hvorfor? fordi det er slitt og strukket for mye på hodetelefonene Underliggende årsaker blir forhåpentligvis klarere etter hvert som vi forstå mer av hvorfor problemet oppstod i utgangspunktet 5. hvorfor? fordi de kveilet sammen og lagt i bukselommer over lang tid IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 16

17 Krav Definisjoner: - Krav Krav beskriver funksjoner eller egenskaper til et system, en tjeneste, eller en løsning Innen HCI er krav altså noe vi stiller til systemer og ikke noe vi snakker om at brukerne har (de har sine behov) Krav er ofte koblet til spesifikke teknologier eller andre mennesker: plattformer, strategier, teknologier, enheter etc. Krav er ment å kunne forstås av utviklere: gir dem føringer på hvilke funksjoner og egenskaper som ønskes Krav lider ofte av utydelighet, tvetydighet eller mangelfullhet Er de noen gang enstydige og heldekkende? IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 17

18 Etablering av krav Hvorfor bry seg? Læreboka nevner at fasen med å etablere krav er den fasen i en utviklingsprosess hvor ting som oftest går galt IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 18

19 Hvordan komme seg fra behov til krav? Hva ønsker vi å oppnå? Forstå mest mulig om bruk, brukere, brukskontekst og oppgavene som skal løses Etablere et stabilt sett med krav Hvordan kan vi oppnå dette? Datainnsamlingsaktiviteter Analyse av data Formulere uttrykk og beskrivelser som «krav» Iterative prosesser med brukere og andre interessenter IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 19

20 Etablering av krav: typiske spørsmål å stille seg Hva ønsker brukerne å oppnå? hva har de behov for? Hva er brukernes ønsker? For hvilke brukergrupper eller aktører gjelder dette? Gjelder deres ønsker kun i henhold til oppgave, aktivitet, mål etc. eller alt de foretar seg? Uansett underliggende behov så er det vår jobb å klargjøre, fullføre, omstrukturere ( etablere) før det kan kalles krav Hvorfor «etablering»? Krav binder ofte sammen flere ulike behov som kun kan forstås i sin brukssammenheng, dermed «oppstår de» Vi henviser ofte til innsamlet data og bruker dataen til å rettferdiggjøre og forankre kravene dataen etablerer IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 20

21 Ulike typer krav Funksjonelle krav Ikke-funksjonelle krav Krav til omgivelser Sosiale krav Organisatoriske krav IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 21

22 Funksjonelle og ikke-funksjonelle krav Definisjoner: - Funksjonelle krav - Ikke-funksjonelle krav Funksjonelle krav Krav som sier noe om hva systemet skal kunne gjøre Absolutt formulert: «ja/nei»? Hvilke funksjonaliteter (og atferd) skal systemet ha? «Mobiltelefonen skal kunne lades trådløst» / «Mobiltelefonen skal kunne avspille musikk» Ikke-funksjonelle krav Krav som sier noe om hvordan systemet skal utføre sine funksjoner (dvs. kvaliteten på utførelsen) Målbart formulert: «hvor godt»? Hvilke kvaliteter og egenskaper skal systemet ha? «Mobiltelefonen skal ha en responstid på under 100ms ved ansiktsgjenkjenningsinnlogging» / «Mobiltelefonen skal ikke veie mer enn 200g» IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 22

23 Andre krav: omgivelser, sosiale, organisatoriske Krav til omgivelser Er det forhold ved omgivelsene som kan gi opphav til krav? «Mobiltelefonen skal være vanntett» / «Mobiltelefonen skal tåle støt/risting» Sosiale krav Er det sosiale elementer ved bruken eller brukskonteksten som kan medføre krav? «Mobiltelefonen skal støtte deling av bilder» / «Mobiltelefonen skal støtte samtaler med mennesker på andre siden av jorda» Organisatoriske krav Har organisasjonen hierarkiske, infrastrukturelle, holdningsmessige, sikkerhetsmessige eller andre type føringer som kan medføre krav? «Mobiltelefonen skal be om at ny sekssifret sikkerhetskode opprettes hver måned» / «Mobiltelefonen skal nektes rottilgang» IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 23

24 En normal kravhåndteringsprosess involverer mange Ulike aktører har sine behov og motivasjoner: Sluttbruker IN1050 Kunder Innkjøper Drifter Vedlikeholder Reparatør IN1030 Videreutvikler Andre aktører? Ikke-brukere? IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 24

25 Hva kan vi si om brukerne våre? Vi ønsker som regel å kunne si noe om: Hvem er de? hva er typiske karakteristikker som bakgrunn, utdanning, erfaring, holdning, kjennskap til teknologi etc.? Hvordan drevne er de? er de noviser eller eksperter? Hvor ofte bruker de systemet? ofte, jevnlig eller sjeldent? Hvordan er deres mestringsevne? nedsatt funksjonalitet, fysisk motorikk, styrke og bevegelighet etc.? Som regel ønsker vi å gi anonymiserte beskrivelser av ekte personer eller brukerkarakteristikker skapt fra reelle personer IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 25

26 Personas Definisjoner: - Personas Personas beskriver brukerkarakteristikken til en fiktiv bruker som er ment å representere en gruppe brukere Som regel holder man seg til 1-4 personaer for å dekke de mest interessante brukergruppene Vi har som oftest en primær persona blant de få vi lager Beskriver ikke reelle personer, men personas skapes som regel fra reelle personer Bringes til live ved å gi dem navn, mål, karakteristikker, bakgrunn etc. Må ikke idealiseres til å anses som 100 % perfekte, nøyaktige eller representative IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 26

27 Personas: eksempel fra lærebok IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 27

28 Personas: eksempel fra gruppetimer sist uke Ågot, 81 år Du ser ikke så godt, men er veldig nysgjerrig. Siden du aldri har brukt noe særlig datamaskin i arbeidssammenheng har du minimalt med teknologisk erfaring. Du fikk en mobiltelefon til jul i fjor, men den er veldig liten, og den er fryktelig komplisert. Alt for mange menyer og alt for mye unødvendig dilldall. Språket er også komplisert. SMS, chat, WiFi etc. Du skjønner ingenting. Knappene er altfor små og det er vanskelig å lese hva som står der. SMS klarer du ikke, selv om du har veldig lyst. Dessuten glemmer du ofte hvor du har lagt den, så den blir ofte borte fra deg. Julius, 8 år Du er en liten gutt. Du har aldri eid en mobiltelefon før. Du kan ikke lese så godt, så du liker best bilder for å forstå sammenhenger. Du har fått beskjed om å ha med deg mobilen overalt, så den bør tåle litt utendørsforhold: søle, sand, vann etc. Du elsker musikk så du vil gjerne ha høyttalere på mobilen. I tillegg ville et enkelt kamera vært megakult. Fordi du er så distre og glemmer klokka hele tiden bør du ha en stadig påminnelse, f.eks. analog klokke som skjermsparer eller en alarm som piper hver time (slik digitale klokker) gjør. Den bør kunne skiftes deksel på slik at du kan ha logoen til favorittlaget ditt i Tippeligaen bakpå. Funksjonalitet er ikke så viktig for deg, men en kul mobil som tåler litt trøkk betyr alt IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 28

29 Datainnsamling for å etablere krav Forrige uke lærte vi om ulike måter å samle inn data om bruk, brukere og brukskontekst på men hvordan går vi frem med datainnsamling når målet er å etablere krav? Forelesning 2 (s. 40): En enkel livssyklusmodell for UCD IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 29

30 Hvordan bruke datainnsamling til å etablere krav (1) Intervjuer «Props»: vi bruker gjerne rekvisitter og typiske gjenstander som en del av intervjuet for å forstå underliggende behov Intervjuer er godt egnet til å utforske forhold og få oversikt Kan brukes til å knytte relasjoner til deltagere og aktører som kan være relevante å inkludere senere Fokusgrupper Utføres som regel som gruppeintervjuer Fokusgrupper er godt egnet til å oppnå konsensus og/eller for å belyse og fremprovosere sensitive forhold eller konflikter Kan ofte medføre at enkeltpersoner dominerer IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 30

31 Rambøll Museums (INF2260 h17): - Thanh Thao Thi Tran - Mariann Gundegjerde - Sander Opperud Odden - Sebastian Dahl IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 31

32 KLIMB (INF2260 h17): - Marte Rimer - Therese Wiig - Kristine Hellem Anstad - Inger Helene Howells Engebretsen IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 32

33 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 33 AI for Library (INF2260 h17): - Caroline Janes - Live Nordli - Ida Jasmin Kalfoss - Helle Kyseth Heiestad

34 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 34 Magnus Li (IN1050 h17): - Masteroppgave/forelesning

35 Hvordan bruke datainnsamling til å etablere krav (2) Spørreskjema Brukes gjerne i kombinasjon med andre teknikker (husk triangulering) Kan gi oss både kvalitativ og kvantitativ data Spørreskjemaer er godt egnet til å få tak i svar på spesifikke spørsmål fra en større og spredt populasjon Studier av liknende løsninger Brukes som oftest når vi ønsker å forbedre et eksisterende system fremfor å introdusere noe helt nytt Krever at vi har kjennskap til eksisterende liknende løsninger i en tidlig fase Denne typer studier gir oss et godt grunnlag for å sammenlikne og utlede krav IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 35

36 Real Fiction (INF2260 h17): - Anders Brustad - Helene Mehre Ystgaard - Ulrik Palmstrøm - Jacob Kleivdal Ommundsen IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 36

37 AI for Library (INF2260 h17): - Caroline Janes - Live Nordli - Ida Jasmin Kalfoss - Helle Kyseth Heiestad IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 37

38 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 38

39 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 39

40 Hvordan bruke datainnsamling til å etablere krav (3) Direkte observasjon Vi får innsikt i brukernes faktiske oppgaver og omstendigheter Direkte observasjon er godt egnet for å danne seg et helhetlig inntrykk av brukerens situasjon og brukskontekst Krever svært mye tid og kan fort lede til store mengder data Indirekte observasjon Indirekte observasjon egner seg godt til å få en oversikt over eksisterende oppgaver, rutiner, aktiviteter etc. Brukes sjeldent alene i kravetablering, men kan gi støttedata som supplerer annen innsamlet primærdata (husk triangulering) IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 40

41 Rambøll Museums (INF2260 h17): - Thanh Thao Thi Tran - Mariann Gundegjerde - Sander Opperud Odden - Sebastian Dahl IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 41

42 KLIMB (INF2260 h17): - Marte Rimer - Therese Wiig - Kristine Hellem Anstad - Inger Helene Howells Engebretsen IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 42

43 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 43

44 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 44

45 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 45

46 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 46

47 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 47 Magnus Li (IN1050 h17): - Masteroppgave/forelesning

48 Hvordan bruke datainnsamling til å etablere krav (4) Dokumentstudier Vi får ofte tak i prosedyrer, regler og rutiner ved å se på manualer, instrukser, guider etc. Dokumentstudier er godt egnet til å forstå stegene som inngår i en aktiviteter samt hvilke regler og retningslinjer som regulerer aktiviteten Bør ikke brukes isolert sett (husk triangulering) Hjelper oss med å forstå relevant lovgivning og nødvendig bakgrunnsinformasjon Krever ikke tid fra deltagere! IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 48

49 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 49 Bredvid (INF2260 h17): - Johan Hoi - Snorre Ødegård - Mari Bruseth - Jonathan Ibsen

50 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 50 next. (INF2260 h17): - Hans Jonathan Esbjug - Pio Rasch-Halvorsen - Ingvild Alette Jensen - Kristian Dahl

51 Social Health Bots (INF2260 h17): - Aleksander Kjelstrup - Fredrik H Lauritzen - Andrea Ingvaldsen - Sondre Hamnvik IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 51

52 IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 52 Magnus Li (IN1050 h17): - Masteroppgave/forelesning

53 En konkret metode: Contextual inquiry Contextual inquiry er en metode innen UCD med røtter fra etnografien og brukes for å få oversikt over aktiviteter i praksis hvor man samarbeider med brukeren om å forstå situasjonen og på sikt etablere krav Struktureres gjerne som et én-til-én intervju med noen i deres normale arbeidsrutiner og diskusjon av aktiviteter og oppgaver Hovedregelen er at brukeren er eksperten og designeren er novisen Det følger med fire hovedprinsipper: Kontekst: vi får innsikt i reell brukskontekst og vi ser hva som typisk foregår der Partnerskap: bruker og designer samarbeider om å forstå situasjonen og brukerens arbeid og praksis Tolkning: alle observasjoner tolkes av begge før det trekkes en slutning Fokus: designer retter gjerne samtalen mot tematikker som virker interessante IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 53

54 Utfordringer ved datainnsamling (1) Når vi samler inn data uavhengig av metoder og teknikker vi velger må vi være oppmerksomme på en del utfordringer Hvem er interessentene (stakeholders)? hvem andre enn brukeren vil kunne mene om kravene til løsningen? Hvem kan vi engasjere i en UCD-prosess og hvordan? når, hvor og hvordan bør vi gå frem? Hvordan kommer vi tettest på «ekte» brukere og ikke ledere, administrativt ansatte og andre ikke-brukere? Proxy-brukere? Hvordan involverer vi deltagere uten at maktbalansen blir skjev og noen dominerer prosessen? Er det økonomiske eller organisatoriske forhold vi bør være kjent med som kan påvirke datainnsamlingen? IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 54

55 Utfordringer ved datainnsamling (2) Hvordan skal vi kommunisere mellom partene? Innen design- og utviklingsteamet Mellom designer og bruker Mellom brukere (ofte ulik terminologi selv innad i en bedrift) Hvor godt kjente er vi og brukerne med domenet og terminologi? Hvor god er tilgangen på faktiske brukere og nøkkelpersoner? IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 55

56 Domene Definisjoner: - Domene Vi designer ofte for spesifikke brukskontekster hvor god innsikt krever domenekunnskap For å skape gode brukeropplevelser må vi enten sette oss inn i domenet eller hente inn domeneeksperter Ofte er ikke løsninger overførbare mellom domener Domene et felt eller omfang av en bestemt kunnskap eller aktivitet Domenekunnskap kunnskap innenfor et bestemt domene Domeneekspert en ekspert innenfor et gitt domene IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 56

57 Oppgavebeskrivelse og oppgaveanalyse I dette kurset kommer er vi innom to metoder for oppgavebeskrivelser: Scenario Dette skal vi lære om og bruke i dette kurset (blant annet i senere obliger) Brukes svært ofte innen HCI og UCD Use case Kun kursorisk pensum som det står mer om i kap. 10 i læreboka Blir gjennomgått nøye i IN1030 til våren Brukes sjeldent innen HCI og UCD mest vanlig innen systemutvikling Vi skal innom én metode for oppgaveanalyse: HTA Listebasert og grafisk fremstilling av hvordan oppgaver kan brytes opp i mindre deler Brukes mest når det er snakk om konkrete og isolerte oppgaver i eksisterende løsninger IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 57

58 Scenario Definisjoner: - Scenario Et scenario er en uformell, narrativ fremstilling av en brukssituasjon hvor en problemstillingen eller foreslått løsning står i sentrum Scenarioer skal være enkle, naturlige, personlige og ikke generaliserbare de skal vise til en bestemt brukssituasjon Er ment både til å kommunisere og til å frembringe kritisk refleksjon blant designere som vurderer brukssituasjonen Brukes på ulike måter og finnes i ulike varianter, men vi konsentrerer oss om to typer: Scenario til fremstilling av et problem: Tekstlig scenario for å beskrive hvordan en problemstilling typisk utfolder seg og oppgaver som inngår Benyttes for å skape en illustrativ fremstilling som folk flest kan relatere seg til og som kommuniserer godt Det er ikke meningen at scenarioet skal forsøke å løse problemet eller forslå løsninger til problemet Pluss- og minusscenarioer: Et forsøk på å fremstille de mest positive/negative konsekvensene ved en foreslått løsning Brukes stort sett av designere for å danne seg helhetlige bilder av brukssituasjonen de ser for seg IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 58

59 Oppgaveanalyse Analyse av innsamlet data er tema for de to neste ukene, men akkurat nå snakker vi om oppgaveanalyse Oppgavebeskrivelser brukes ofte for å forestille seg nye eller alternative løsninger med utgangspunkt i eksisterende løsninger Vi forsøker å bryte opp eksisterende oppgaver i mindre deler som kan informere «nye» løsninger Fokuset ligger på de viktige aktivitetene og ikke de overfladiske: Hva er det brukerne prøver å oppnå? Hvorfor forsøker de å oppnå det? Hvordan går de frem for å få det til? Den vanligste teknikken for å gjøre en oppgaveanalyse er HTA IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 59

60 HTA HTA står for Hierarchical Task Analysis og kalles gjerne hierarkisk oppgaveanalyse på norsk Vi bryter ned en helhet i deloppgaver på en hierarkisk struktur Vi fokuserer på fysiske og observerbare aktiviteter Vi ser også på oppgaver som ikke nødvendigvis omhandler systemet vi interagerer med Vi starter med brukernes mål og ser på hvilke oppgaver de må gjennomføre for å nå sine mål IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 60

61 HTA: eksempel fra læreboka Tekstlig fremstilling: Grafisk fremstilling: 0. In order to buy a DVD 1. Locate DVD 2. Add DVD to shopping basket 3. Enter payment details 4. Complete address 5. Confirm order Plan 0: If regular user do If new user do IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 61

62 Oppsummering Krav og behov må ikke forveksles! Det å etablere gode, entydige krav er viktig for både designer og utvikler og IT-prosjekter bommer ofte på krav De vanligste datainnsamlingsmetodene for å etablere krav er intervju, spørreskjema, observasjon og fokusgruppe Vi kan bruke personas og scenarioer for å artikulere og kommunisere eksisterende og fremtidige løsninger Oppgaveanalyse (f.eks. HTA) er godt egnet til å studere eksisterende systemer og oppgaver IN1050 Introduksjon til design, bruk og interaksjon Forelesning 3: Krav og behov 62