Hoppa till huvudinnehållet
Institutionen för informationsteknologi

Inlupp: Behov, krav och användningsfall

Formalia

  • Inluppen görs individuellt. Ni får gärna samarbeta i termer av metodval, diskussion, etc - men varje student ska göra ett eget arbete och skriva en egen rapport!
  • Handledning, kontakta Elina Eriksson.
  • Inluppen introduceras på föreläsning 2, Fr 26/10, 13-15, sal 1111.
  • Inluppen görs i två steg.
    • Första steget delredovisas muntlig och diskuteras på inluppseminarium Fr 16/11, 8-10, sal 1111. Då finns också möjlighet att ta upp frågor och problem.
    • Hela inluppen redovisas muntligt och diskuteras på slutseminarium On 5/12, 10-12, sal 1111.
  • Skriftlig redovisning av hela inluppen
    • Inlämning senast Fr 7/12 17.00
    • Lämnas in i elektronisk version (pdf, doc, rtf, txt), via Studentportalen, till filarean Inlupp rapport. Obs! döp filen till inluppACSD_dittnamn .
    • Rapportens omfattning: motsvarande 5-10 A4-sidor exklusive framsida, innehållsförteckning och dylikt. Rapporten ska också innehålla en ordentlig källförteckning.
    • Ditt namn och din e-postadress ska tydligt framgå i rapporten.
    • Använd normal font o fontstorlek (t ex Times New Roman, 12 pt). Layout och struktur bestämmer du själv. Dock lägger vi större vikt på att det finns en bra beskrivning av hur du gått tillväga (metoder och beskrivningsmodeller, m m, med källor) än på att själva resultaten (t ex vad du kom fram till i intervjuer och kraven/användningsfall) är fullständigt beskrivna ner i minsta detalj. Det är också viktigt att du diskuterar och reflekterar över de metoder och modeller du har använt - vad var bra/dåligt, etc. Se mer om innehållet i rapporten nedan.
    • I samband med att du lämnar in rapporten ska du också lämna in en egenvärdering, se rapporten nedan.
  • Godkännande - för godkänt krävs godkänd rapport och aktivt deltagande i gruppdiskussioner på seminarierna. Seminarierna är alltså obligatoriska. Om du har problem att närvara - hör av dig till Elina Eriksson.

Beskrivning av uppgiften

Bokning av tvättstugan

Tid för att tvätta bokas idag ofta i tvättstugan, det finns många lösningar, allt från pappersbaserade bokningslistor till elektroniska system med smartcards. Nu ska det bytas system i "din" tvättstuga och du har blivit ombedd att komma med input till beställningen som ska göras.

Steg 1: Du ska

  • identifiera och beskriva användargrupperna
  • identifiera och beskriva deras behov. Obs! här måste du ta hjälp av en eller flera presumtiva "användare"
  • ta fram 1-2 OH-bilder. Skicka/lämna dem till Elina Eriksson senast Ti 13/11 17.00. (För mer info om OH-bilderna se Muntlig redovisning)

Steg 2: Du ska

  • skriva krav eller användningsfall för det tänkta systemet utifrån dessa behov. För tips se Kravspecifikation resp Användningsfall nedan.
  • ta fram 1-2 OH-bilder. Skicka in dem via Studentportalen, till filarea Inlupp 2 (eller i pappersformat till Elinas postfack) senast Fr 30/11 17.00. (För mer info om OH-bilderna se Muntlig redovisning)

Du får själv välja metod för att tillsammans med en eller flera användare identifiera behoven (t ex "contextual interviews*", observationsintervjuer, vanliga intervjuer, fokusgrupper, etc). Du väljer också själv hur du vill beskriva användargrupperna och deras behov (t ex aktörsmodeller, användarprofiler eller personas** respektive scenarios** eller enkla "work models*"). Du måste kunna redovisa och motivera varför du valt en viss metod och ett visst dokumentationssätt och ange relevanta källor.

När du har en bild över användargrupperna och deras olika behov ska du skriva enkla krav på systemet. Du kan göra detta i form av en traditionell kravspecifikation (föreläsning 5) eller i form av användningsfall (föreläsning 6). Oavsett vilket sätt du väljer att dokumentera kraven på ska du hålla dig till den "notation" och de hållpunkter som finns. Kraven ska uteslutande handla om användning och användbarhet. Du behöver inte skriva krav utifrån tekniska aspekter, eller fundera på ngn teknisk lösning (utöver om det finns kopplingar till användbarhetsfrågor, t ex tillgänglighet). Tänk på att det inte finns något rätt svar - vi har inte facit till hur kravspecifikationen/användningsfallen ska se ut. Det finns bättre och sämre lösningar - men inga rätta svar!

(*) Contextual interviews och work models beskrivs i boken Contextual Design av Beyer & Holtzblatt (se kurslitteratur)
(**) Personas och scenarios beskrivs i Cooper (1998), The Inmates are Running the Asylum.

Redovisning och rapport

Muntlig redovisning

Inför seminarierna ska du ta fram OH-bilder som kort beskriver ditt arbete (se nedan). Du kommer inte att behöva presentera själv inför gruppen. Istället kommer Elina att välja ut och visa OH-presentationer och ta upp frågor som är av allmänt intresse. Du måste alltså vara beredd att "försvara" dina OH-bilder muntligt på seminariet.
Du kan skicka bilderna som ppt-fil eller lämna in dem som plastbilder (går alldeles utmärkt med handgjorda!) i Elinas postfack, Hus 1, plan 1, längst in i MDI-hörnet (dvs "holken" i husets nordligaste hörn). Glöm inte att sätta ditt namn på bilderna!

  • Steg 1: ta fram 1-2 OH-bilder som sammanfattar ditt arbete och dina resultat så här långt. Fokusera framförallt på de metoder du använt: fördelar och nackdelar. Summera också kort resultaten - vilka är "dina" användargrupper, och hur ser deras huvudsakliga behov ut.
  • Steg 2: ta fram 1-2 OH-bilder. Fokusera på följande frågor (samma som i reflektionsdelen i den skriftliga rapporten)
    • vad är skillnaden mellan behov och krav?
    • hur fungerade de metoder/beskrivningssätt du valde - vad var bra, vad var dåligt?
    • hur fungerade samarbetet med de presumtiva användarna - vad var bra, vad var dåligt?

Skriftlig redovisning

Rapporten ska omfatta motsvarande 5-10 A4-sidor exklusive framsida, innehållsförteckning och dylikt. Rapporten ska också innehålla en ordentlig källförteckning.
I rapporten ska du redogöra för båda delstegen:

  • kort bakgrund - hur ser "verksamheten" ut i dag
  • metoder - vilka du använt och varför
  • resultat - vilka är användargrupperna, hur ser deras behov ut, samt krav/användningsfall
  • reflektion och diskussion av ditt arbete - fokusera på föjande frågor
    • vad är skillnaden mellan behov och krav?
    • hur fungerade de metoder/beskrivningssätt du valde - vad var bra, vad var dåligt?
    • hur fungerade samarbetet med de presumtiva användarna - vad var bra, vad var dåligt?

Egenvärdering
Innan du skickar in rapporten ska du ha läst igen och besvarat egenvärderingen. Bifoga egenvärderingen till rapporten när du skickar in den.
Tidigare år har det varit osäkerhet kring hur man skriver en rapport, och egenvärderingen är till för att du ska kunna fundera kring om du fått med allt. Tips på hur man t ex skriver en bra disposition finner du på Språkverkstadens hemsida.

Resurser

  • Föreläsning F2, F4, F5, F6 och F7.
  • Handledning, kontakta Elina Eriksson.
  • Gulliksen & Göransson kap 3, särskilt 3.2 - 3.5, kap 6.2.1 och kap 8.7.
  • Länkar om krav och användningsfall se länksidan.
  • Fler aspekter på användbarhetskrav
  • Några tips och exempel från tidigare kurser ( Obs! inluppen var då uppdelad i två separata uppgifter - en för krav och en för användningsfall):

Kravspecifikation

  • Specifikationen ska ta upp alla krav som rör systemets användbarhet på något sätt. Användbarhet handlar både om funktionalitet (vad man kan göra) och kvalitet (lätt-att-lära, lätt-att-använda, etc). Det innebär att kraven kan vara både funktionella och icke-funktionella. Ni behöver inte ta med krav som inte har med användbarhet att göra, men tänk på att många rent tekniska krav på något sätt faktiskt påverkar användbarheten.
  • Kraven ska vara tydligt och entydigt formulerade. De ska också i möjligaste mån vara spårbara och verifierbara.
  • Ni ska också prioritera kraven. Man kan använda många olika notationer för prioriteringen, men ett vanligt är att dela upp kraven i nödvändiga (skallkrav) och önskvärda/bra-att-ha (börkrav).

Användbarhetskrav är krav på användbarheten enligt ISO 9241:11:
"The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use."

Användbarhet är alltså något som gäller för specifika användare som ska uppnå specifika mål i ett specfikt sammanhang (se till exempel Gulliksen & Göransson, kapitel 3.2). Användbarhetskraven ska handla om ändamålsenlighet, effektivitet och subjektiv uppfattning/tillfredsställelse för just dessa användare, mål och sammanhang. Detta innebär att ni måste tänka på följande faktorer när ni specificerar kraven

  • vilka användare är aktuella. Användbarheten måste specificeras utgående från alla grupper som är tänkta som målgrupper.
  • vilka behov och mål har dessa användare - vad vill de uppnå, vad vill de göra? Detta innebär att ni också behöver fundera på systemets funktioner och "informationsinnehåll". Användbarhet handlar inte enbart om "ytliga" faktorer som "lätt-att-lära" och "lätt-att-använda". Ett system kan var lätt-att-lära och lätt-att-använda, men om det inte innehåller den information och de funktioner man behöver för att nå sitt mål är det inte användbart!
  • vilka sammanhang systemet kommer att användas i - hur ser det ut, finns det störningsmoment i situationen, stress. Beroende på användningssituationen ställs olika användbarhetskrav på produkten/systemet/applikationen/sajten - t ex om lätt-att-lära och intuitivitet är viktigt (s k walk-up-and-use-system/produkter) eller effektivitet (i arbetssituationer).

Många gånger täcker användbarhetskrav enbart effektivitet - men er kravspec ska täcka in användbarhetens "fulla bredd". Det är fritt fram att spåna vidare runt detta och ni kan använda ett antal olika faktorer och sätt att bryta ner användbarheten, t ex de som föreslås av Dix och/eller Nielsen (kapitel 3.2.1 i Gulliksen & Göransson). Men ni bör tänka på att deras definitioner inte är lika breda som ISO och att ni därför behöver komplettera dem så att er kravspec täcker de faktorer som ISO-standarden pekar på.

Användningsfall

  • Utgå ifrån att det kan finnas olika aktörer (användargrupper) som använder systemet på olika sätt och med olika villkor. Beskriv aktörerna respektive användningsfallet och dess förutsättningar på en rimlig nivå för att hålla den samlade dokumentationen mellan 5 och 10 sidor.
  • Användningsfallen ska beskrivas i textform, ni behöver inte göra en grafisk representation (UML-diagram). Användningsfallen ska vara "vanliga" användningsfall (även kallat system eller formal use case), inte "essential use cases" (eller business use case).
  • Beskriv:
    • systemgränserna
    • minst två olika aktörer (användarroller/roles) och
    • minst tre olika användningsfall (use cases) för systemet.

Ett exempel: Bankomat

Aktören Bankkund kan använda en uttagsautomat för att ta ut pengar, överföra pengar eller kontrollera saldo. Dessa egenskaper kan representeras som en mängd användningsfall (AF):

  • AF1: Ta ut pengar
  • AF2: Överföra pengar
  • AF3: Kontrollera saldo

Varje AF representerar något som systemet gör och som innebär ett värde för bankens kund, dvs aktören Kund. Tillsammans utgör AFarna alla möjliga sätt att använda systemet. Namnet på ett AF uttrycker vanligtvis det värde som AF ger aktören.

Händelseförlopp

Händelseförloppet beskriver sekvensen av händelser mellan aktören och systemet. Det skrivs på naturligt språk (svenska, engelska), i en konsekvent form och med termer från användningsdomänen.

Exempel på händelseförlopp för AF 1 "Ta ut pengar"

1. AF börjar när kunden för in ett kort i automaten. Systemet läser och kontrollerar informationen på kortet.
2. Systemet (S) frågar efter PIN-koden och slår in koden. S verifierar koden.
3. S frågar vad kunden vill göra. Kunden väljer "uttag".
4. S ber om ett belopp. Kunden slår in beloppet.
5. S ber om en kontotyp. Kunden väljer kontotyp (check, spar eller kreditkonto).
6. S kommunicerar med bankens nätverk för att kontrollera kontonr, PIN-kod och om beloppet finns på kontot.
7. S frågar om kunden vill ha ett kvitto. Detta steg utförs bara om det finns papper för att skriva ut.
8. S ber kunden ta kortet. Kunden tar kortet. (Detta är en säkerhetsåtgärd för att kunderna inte ska glömma sina kort i automaten).
9. S lämnar ut det begärda beloppet i sedlar.
10. S skriver ett kvitto om så begärts och AF avslutas.

När man använder fullständiga händelsesekvenser för att beskriva vad systemet gör förstår man snabbt att det finns många olika händelseförlopp - olika vägar genom AFet. Olika värden och resultat produceras och man måste ta hänsyn till alternativa förgreningar och olika fall (scenarier). AFens händelseförlopp tillsammans beskriver alla dessa möjliga vägar.

Exemplet ovan är taget från boken "The Rational Unified Process - en introduktion (svenska utgåvan)", av P. Kruchten, 2 utg, 2002.

Uppdaterad  2007-11-13 13:27:03 av Elina Eriksson.