260 likes | 514 Views
Identifisere behov – og etablere krav. INF 1500; introduksjon til design, bruk og interaksjon 7 september 2012. Hva vi snakker om når vi snakker om krav og behov. “with UI, we are faced with counterintuitive interaction methods that are tailored to the needs of a computer.”
E N D
Identifisere behov – og etablere krav INF 1500; introduksjon til design, bruk og interaksjon 7 september 2012
Hva vi snakkeromnår vi snakkeromkravogbehov. • “with UI, we are faced with counterintuitive interaction methods that are tailored to the needs of a computer.” • Cooper Journal (August 29) • Behovogkrav; hvamener vi “egentlig”?
Krav og behov, kapittel 10 • Behov • Krav • Oppgavebeskrivelse • Oppgaveanalyse
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 • Noe vi alle vet hva er?
Hvorfor, hvordan, hva? Hvorfor? • Forstå så mye som mulig om brukerne, oppgaver, situasjoner, mål • Etablere stabile krav – som kan brukes under utviklingen Hvordan? • Data innsamling • Data analyse • Utrykke, beskrive, artikulere krav • En iterativ prosess
Etablere krav • Hva ønsker brukerne? Hva har de behov for? • Hva er ønsker? • Hva er behov? • Hva er krav? • I forhold til oppgaver? • Aktiviteter? • Mål? • Hvorfor ”etablere”? • Krav oppstår ved å forstå brukernes behov • Krav, sett i lys av de data som er samlet inn
Typer krav • Funksjonelle krav • Hva systemet skal gjøre? • Funksjoner • Ikke funksjonelle krav • Respons tid • Omgivelse • Lys, fuktighet, risting • Sosiale krav • Kommunikasjon, deling, gruppe • Organisatoriske
Hvem er brukerne? • Aktører (stakeholders) • Sluttbruker • Kunder • Innkjøper • De som drifter • De som vedlikeholder • De som reparerer • De som videreutvikler • Andre aktører?
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?
Personas • Gripe bruker karakteristikker • Ikke reelle personer, men skapt fra reelle brukere • Ikke ideelle • Gi liv – ved å gi navn, mål, bakgrunn; være konkret • Utvikle flere personas
Data innsamling for etablering av krav • Intervju • Med props • Eksplorerende • Fokus grupper • Gruppe intervju • For å oppnå konsensus – eller å fremprovosere konflikter • Individer kan dominere…
Data innsamling 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
Data innsamling for å etablere krav • Direkte observasjon • Aktørenes faktiske oppgaver • Bra for å forstå brukerens situasjon • Indirekte observasjon • Bra for å få bilde av eksisterende oppgaver
Data innsamling 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 bakrunnsinformasjon • Tar ikke opp tid blant aktørene (brukere, kunder) • Brukes sammen med andre måter å samle inn data
”ContextualInquery” • 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
Utfordringer ved datainnsamling 1 • Identifisere aktører • Brukere, ledere, støttepersonell… • Engasjere aktørene • Intervjuer, verksted (workshop) • Reelle brukere vs andre (ledere, representanter)
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
Utfordringer ved datainnsamling 3 • Politisk innen organisasjonen/gruppen • Dominans av ulike aktører • Økonomiske endringer • Teknologiske endringer • Balansere funksjonelle krav og brukbarhetskrav
Retningslinjer 1 • Fokusere på aktørenes behov • Involvere alle aktører • Involvere mer enn en person fra hver gruppe • Bruke flere teknikker for datainnsamling
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.
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
Oppgave beskrivelse • Scenario • En uformell fortellende historie, spesifikk for en bruker, ikke generaliser • Use cases • Forutsetter interaksjon med et system • Forutsetter detaljert forståelse av interaksjon
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)
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
Øvelse • Oppgavebeskrivelse av ”skriv melding på mobiltelefonen”? • Oppgaveanalyse? • Hva betyr brukerens situasjon for oppgaven?
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