Identifisere behov – og etablere krav INF 1500; introduksjon til design, bruk og interaksjon 8 september 2014.

Presentasjon om: "Identifisere behov – og etablere krav INF 1500; introduksjon til design, bruk og interaksjon 8 september 2014."— Utskrift av presentasjonen:

1 Identifisere behov – og etablere krav INF 1500; introduksjon til design, bruk og interaksjon 8 september 2014

2 Behov “with UI, we are faced with counterintuitive interaction methods that are tailored to the needs of a computer.” – Cooper Journal (August 29-2012)

3 Krav og behov, kapittel 10 Behov Krav Måter å etablere krav Måter å representere krav

4

5 Behov og krav Behov – Noe som ikke er koplet til spesifikke teknologier eller andre mennesker – Behov for trygghet, forflytning, samhørighet, integritet, næring….. Krav (requirements) – Noe som er koplet til strategier/løsninger/teknologier/platformer Ønsker/forventninger/ambisjoner? – Noe vi alle vet hva er?

6 Startpunkt.. Videreutvikle løsning Erstatte løsning med noe helt nytt Lage et produkt Være både den som etablerer kravene – og den som har kravene

7 Hvorfor, hvordan, hva? Hvorfor? Forstå så mye som mulig om brukerne, oppgaver, situasjoner, mål, behov Etablere stabile krav – som kan brukes under utviklingen Hvordan? Data innsamling Data analyse Utrykke, beskrive, artikulere krav En iterativ prosess – med brukere/aktørerne

8 Etablere krav Hva ønsker brukerne? Hva har de behov for? – Hva er ønsker? – Hva er behov? – For hvilken aktør/brukergruppe? – Hva er krav? I forhold til oppgaver? Aktiviteter? Mål? Hvorfor ”etablere”? – Krav oppstår ved å forstå brukernes behov i sammenheng – Krav, sett i lys av de data som er samlet inn

9 Typer krav Funksjonelle krav – Hva systemet skal gjøre? – Funksjoner Ikke funksjonelle krav – Fx. Respons tid Omgivelse – Lys, fuktighet, risting Sosiale krav – Kommunikasjon, deling, gruppe Organisatoriske

10 Hvem er brukerne? Aktører (stakeholders) – Sluttbruker – Kunder – Innkjøper – De som drifter systemet – De som vedlikeholder – De som reparerer – De som videreutvikler – Andre aktører?

11 Hvem er brukeren? Brukeren – Karakteristika, bakgrunn, holdninger til datamaskiner – Novise – Ekspert – Hvilke sanser – sterke/svake – Frekvens Daglig, ukentlig, en gang i året, en gang i livet?

12 Personas Gripe brukerkarakteristikker Ikke reelle personer, men skapt fra reelle brukere Ikke ideelle Gi liv – ved å gi navn, mål, bakgrunn; være konkret Utvikle flere personas

13 Oppgave Lag en persona! Vis til sidemannen 5 minutter.

14 Datainnsamling for etablering av krav Intervju – Med props – Eksplorerende Fokus grupper – Gruppe intervju – For å oppnå konsensus – eller å fremprovosere konflikter – Individer kan dominere…

15 Datainnsamling for å etablere krav Spørreskjema – Ofte i bruk sammen med andre teknikker – Kan gi både kvalitative og kvantitative data – Bra for å finne ut av spesifikke spørsmål fra en stor populasjon Innsamle data fra ”liknende” tjenester/produkter/applikasjoner – Bra for å sammenligne – få opp krav

16 Datainnsamling for å etablere krav Direkte observasjon – Aktørenes faktiske oppgaver – Bra for å forstå brukerens situasjon Indirekte observasjon – Bra for å få bilde av eksisterende oppgaver

17 Datainnsamling for å etablere krav Studere dokumentasjon – Prosedyrer og regler er ofte nedtegnet i manualer – Bra for å forstå stegene som gjennomgås – Bra for å forstå lovgiving og bakgrunnsinformasjon – Tar ikke opp tid blant aktørene (brukere, kunder) – Brukes sammen med andre måter å samle inn data

18 ”Contextual Inquery” En mye brukt metode – oversikt over aktiviteter i praksis Brukeren er ekspert Utvikler er novise Fire hovedprinspipper – Context: Se ”arbeidsplassen” og hva som skjer – Partner: Bruker og utvikler – Tolkning: Observasjoner tolkes av både utvikler og bruker – Fokus: Formulere fokusområder

19 Utfordringer ved datainnsamling 1 Identifisere aktører – Brukere, ledere, støttepersonell… Engasjere aktørene – Intervjuer, verksted (workshop) Reelle brukere vs andre (ledere, representanter)

20 Utfordringer ved datainnsamling 2 Håndtering av krav, versjonskontroll, behandling av nye krav, eierskap Kommunikasjon mellom partnere – Innen utviklingsteam – Mellom utvikler og brukere – Mellom brukere Domene kunnskap – Hvordan fører du et regnskap? Hvordan sykler du? Tilgjengelighet til brukere og nøkkelpersoner

21 Utfordringer ved datainnsamling 3 Politisk innen organisasjonen/gruppen Dominans av ulike aktører Økonomiske endringer Teknologiske endringer Balansere funksjonelle krav og brukbarhetskrav

22 Retningslinjer 1 Fokusere på aktørenes behov Involvere alle aktører Involvere mer enn en person fra hver gruppe Bruke flere teknikker for datainnsamling

23 Retningslinjer 2 Støtt aktiviteten med props – prototyper og oppgavebeskrivelser Kjør pilot undersøkelser Hvordan analysere dataene som kommer inn Vurder nøye hvordan data tas opp og lagres, format etc.

24 Tolkning og analyse av data Start rett etter innsamling Initial analyse før ”dypere” analyse Ulike teknikker – Klasse diagrammer for objekt orienterte systemer – Entitet relasjoner for data intensive systemer

25 Oppgave beskrivelser Scenario – En uformell fortellende historie, spesifikk for en bruker, ikke generaliser Use cases – Forutsetter interaksjon med et system – Forutsetter detaljert forståelse av interaksjon

26 Oppgave analyse Oppgavebeskrivelse brukes for å se for seg nye systemer/tjenester Oppgaveanalyse gjøres for å undersøke eksisterende oppgaver – for å informere ”nye” Fokusere på viktige aktiviteter – Hva ønsker brukeren å oppnå? – Hvorfor gjør de det? – Hva gjør de for å få det til? Hierarkisk oppgaveanalyse er den viktigste teknikken (HTA)

27 Hierarkisk Oppgave Analyse (HTA) Hierarkisk oppgaveanalyse – Bryte ned helhet i deloppgaver Fokuserer på fysiske og observerbare aktiviteter Også de aktiviteten som ikke direkte angår ”datamaskinen” Starte med brukerens mål – og de oppgaven som gjøres for å komme dit

28 Øvelse Oppgavebeskrivelse av ”skriv melding på mobiltelefonen”? Oppgaveanalyse? Hva betyr brukerens situasjon for oppgaven? 5 minutter

29 I et nøtteskall

30 Oppsummering Krav – sentralt!! Behov – sentralt!! Forskjellige typer krav Datainnsamling for krav – Spørreskjema, observasjon, fokus grupper, direkte observasjon, studere dokumentasjon, studere tilsvarende tjenester/produkter Scenarier, ”use cases” kan bruke for å artikulere eksisterende og nye/tenkte arbeidspraksiser Oppgave analyse – viktig for å undersøke eksisterende systemer og praksiser