HCI-text Skriftlig examination

Människa-datorinteraktion, DVC002 17 Januari 2002 HCI-text Skriftlig examination Del 2. Grupp A Johan Bergsten, mda00jbe@student.bth.se

Innehållsförteckning : Innehållsförteckning :... 2 Kravetablering... 3 Kravetablering i MDA-utbildningen... 3 Inledning... 3 Kravetablering: Interaktionsdesign vs. OOS... 4 Informationsinsamling... 6 Kravformulering i analysfasen... 6 Kravtyper... 8 Användbarhetskrav...10 Krav i designen av laboration 2...12 Reflektion på krav...12 Reflektion på HCI-kursen och dess innehåll...13 Källförteckning...15 2

Kravetablering Kravetablering i MDA-utbildningen Centralt på MDA-programmet är att vi studenter lär oss att designa användbara IThjälpmedel. Hittills har stort fokus legat på olika former informationsinsamling genom användarstudier och användarmedverkan. Resultatet presenterar vi ofta i en etnografisk rapport eller fältstudierapport i form av löpande text som berättar och beskriver arbetsutföranden, organisation, kommunikation mm. Något vi inte haft chansen att ägna oss lika mycket åt är överlappningen mellan rapport och kravformulering. En möjlig framtida arbetsuppgift för oss MDA-studenter är att arbeta med applikationsdesign. Ultimat ska detta arbete resultera i den kravspecifikation som ligger till grund för produkten som utvecklas. Vi vill därför ta chansen att utifrån HCI-kursens perspektiv lägga extra fokus på att beskriva arbetet kring kravetablering i vår fortsatta text. Kravetablering är ett mycket omfattande område. Vi väljer därför att återge och diskutera de delar inom kravetablering som vi finner intressantast och mest givande ur vårt MDA-perspektiv. Inledning Vilken interaktiv produkt som än ska designas så måste användarens behov, krav och mål analyseras. Detta kräver en förståelse för användarna och deras kapacitet, mål, uppgifter, omständigheterna under vilka produkten ska användas och riktlinjer för vad den ska kunna prestera. Arbetet med att klargöra vad en produkt ska kunna göra brukar beskrivas med många olika termer. Några är; kravinsamling, kravspecifikation eller kravanalys. Benämningen kravinsamling ger lätt den felaktiga synen att kraven är färdigformulerade och att det bara gäller att gå ut på fältet och hämta dem. En bättre svensk term att använda tycker vi är kravetablering. Syftet med kravetableringen är att göra en produkts krav så tydliga, 3

otvetydiga och specifika som möjligt. Kraven skiljer sig dock mycket åt i form av abstraktionsnivå och kravtyp. Detta kommer vi att diskutera nedan. A requirement is a statement about an intended product that specifies what it should do or how it should perform. (Preece, 2002) Att etablera krav är inte så enkelt som att skriva ner en öskelista med funktioner. Vi ska titta närmare på etableringen av krav, vilka olika kravtyper som existerar och beskriva några av dem närmare. Vi kommer också att diskutera skillnaden mellan kravformulering i objekorienterad systemutveckling och kravetablering inom HCI diciplinen Interaktionsdesign. Kravetablering: Interaktionsdesign vs. OOS Kravanalys är en omfattande aktivitet som inte följer ett sekventiellt mönster. Istället utvecklas kraven i en iterativ process. I stora drag handlar det dock om att samla in data, analysera datan och sedan formulera krav utifrån analysen. I objektorienterad systemutveckling, OOS, är kravspecifikationen en viktig del. Larman skriver att: The primary goal of requirements phase is to identify and document what is really needed, in a form that clearly communicates to the clients and to development team members. The challenge is to define the requirements unambiguously, so that the risks are identified and there are no surprises when the product is finally delivered. (Larman, 1998) Detta uttalande skulle även kunna stämma in på designen av vilken interaktiv produkt som helst. En viktig skillnad mellan kravspecifikationen i objektorienterad systemutveckling och kravetableringen i Interaktionsdesign är att fokus på den verkliga användaren helt utelämnas i objektorienterad systemutveckling. I Interaktionsdesign är användarcentrerad 4

design en självklarhet. Det är användaren som ska bruka produkten och därför har användaren en självklar roll i designarbetet av en interaktiv produkt. Vi vill hävda att kravetableringen inom Interaktionsdesign och kravetableringen inom OOS har skilda fokus, men att metoderna trots det går hand i hand. Medan OOS fokuserar på funktionella krav så utökar och bygger Interaktionsdesign ut kravspecifikationen genom att ta in verkliga användare som källor för designen. Kravetablering inom Interaktionsdesign tar också hänsyn till icke-funktionella krav som en viktig del i designen av en lyckad produkt. Skillnaden mellan funktionella och icke-funktionella krav beskriver vi under rubriken kravtyper nedan. Vi kommer också vidare i texten att diskutera var brytpunkten mellan Interaktionsdesign och OOS går. Att kravformuleringen blir rätt är avgörande för att lyckas med utvecklingen av en interaktiv produkt, skriver Preece (2002). Hon betonar att en av de största anledningarna till att många IT-projekt misslyckas är en dåligt formulerad kravspecifikation eller otydliga mål och krav. Ett exempel på en kravspecifikation visades upp på föreläsning (Kyhlbäck, 2002) på BTH. Exemplet påvisade några otydligt formulerade krav som ur systemutvecklarsynpunkt skulle vara svåra att arbeta efter. Efter diskussion i klassen kom förslaget fram att ett krav bör formuleras så tydligt att det går att svara ja eller nej på om kravet är uppfyllt (implementerat). 5

Informationsinsamling Att arbeta med informationsinsamling är vi MDA-studenter vana vid. Därför kommer vi inte att beskriva den aktiviteten särskilt omfattande här. Syftet med informationsinsamlandet är att skapa en så fullständig och riktig bild av användaren och användningskontexten som möjligt. Ur HCI-perspektiv handlar det traditionellt om att skapa förståelse för arbetsutförande och arbetsplatsen i sig. För detta finns en mängd metoder att tillgå. Några av dessa är enkätundersökningar, intervjuer, fokusgrupper, workshops, observation och dokumentationsstudier. Varje metod har både för och nackdelar beroende på i vilken situation den används. Om studieobjektet t.ex. inte är en arbetsutövare på en arbetsplats, utan en mobiltelefonanvändare i ett varierande kontext, så blir det betydligt svårare att utföra naturliga observationer i den varierande kontexten än i den stationära arbetsplatskontexten. I en sådan situation kan andra metoder för informationsinsamling vara bättre lämpade. Kravformulering i analysfasen Då den första informationsinsamlingen är klar börjar analyfasen. Preece (2002) skriver att det är bra att påbörja analysfasen så snart som möjligt efter informationsinsamlingen, då man fortfarande har en klar bild av informationskällan och inte har hunnit glömma detaljer. Syftet med analysfasen är att påbörja formuleringen och dokumentationen av krav. Att använda en mall såsom Voleres Requirement Specification Template (se figur 10 nedan) är bra enligt Preece. Den hjälper designern att fokusera på viktig information och guidar denne genom analysfasen, skriver hon. Då formuleringen av kraven påbörjats dyker med största säkerhet nya frågetecken upp. Det är då lämpligt att återvända till informationsinsamlandet för att finna svar. På detta sätt utvecklas kraven genom ett antal iterationer för att sedan sluta i en uppsättning välformulerade och väletablerade krav. 6

Fig.10 Kravmall från Volere Requirement Specification Template Värt att påpeka i mallen är punkten Fit Criterion. Den är ett sätt att mäta om lösningen uppfyller de ursprungliga kraven och kan närmast översättas till användaracceptans. Detta är alltså ett bidrag till att försöka lösa problemet med dåligt formulerade mål och krav. Vi kommer att titta närmare på Fit Criterion i beskrivningen av användbarhetskraven nedan. För att återkoppla till jämförelsen mellan kravformulering i objektorienterad systemutveckling och Interaktionsdesign så vill vi påpeka att det i OOS inte finns någon entydig motsvarighet till kravmallen ovan. Eftersom OOS i huvudsak behandlar funktionella krav (se beskrivning under kravtyper nedan) så ger notationen huvudsakligen vägledning i beskrivningen av funktionella detaljer och systemfunktioner. Ett exempel på detta är Kontrakt (Eng. Contract). Kontrakten beskriver vad en operation ska utföra och beskriver systemets svar på operationen. En kontraktmall (Larman 1998) visas i figur 11. Contract Name: Responsibilities: Class: Cross-references: Notes: Output: Preconditions: Postconditions: Fig. 11, Kontraktmall i UML. 7

Kravtyper I objektorienterad systemutveckling finns traditionellt två kravtyper. Dessa är funktionella och icke-funktionella krav. Preece (2002) skriver att de funktionella kraven beskriver vad systemet ska göra. De icke-funktionella kraven anger systemets ramar och begränsningar. Robertson and Robertson (2001), presicerar ytterligare genom att beskriva funktionella krav såsom en detaljerad specifikation för varje individuell funktion vilken utgörs av konkret data, logik eller algoritmer. De beskriver samtidigt icke-funktionella krav som den framtoning eller känsla produkten ska förmedla. Nedan följer några påhittade krav för en mobil enhet som exemplifierar de båda kravtyperna: Funktionella krav: Icke-funktionella krav: Enheten ska stödja typsnitten Arial och Times New Roman. Enheten ska varna användaren med ett textmeddelande och en ljudsignal på 442Hz då batteriets strömstyrka understiger 50%. Enheten ska vara så fysiskt liten som möjligt. Standby-tiden ska vara så lång som möjligt. Enhetens färg ska vara vit och rosa. Kravens abstraktionsnivå varierar vilket innebär att ett krav ofta byggs upp av flera delkrav. I HCI och i synnerhet inom diciplinen Interaktionsdesign (eng. Interaction design) blir de icke-funktionella kraven minst lika viktiga som de funktionella. Preece (2002) beskriver ett antal användbarhetsmål (kapitel 1.5.2) vars syfte är att förhöja användarupplevelsen. Några av dessa mål är att en interaktiv produkt ska vara rolig, underhållande, tillfredställande och estetiskt tilltalande. Vi tycker att målen har en tydlig koppling till de icke-funktionella kraven. Preece (2002) tycker att de icke-funktionella kraven är så viktiga att hon väljer att omfördela kravtyperna till nya kategorier. 8

Interaction design requires us to understand the functionality required and the constraints under which the product must operate or be developed. However instead of referring to all requirements that are not functional as simply non-functional requirements, we prefer to refine this into further categories. (Preece, 2002) Listan nedan är ett exempel som påvisar den mångfald av icke-funktionella krav som en designer måste kunna fånga. Exemplen är tagna från The Volere Requirements Specification Template. (Robertson and Robertson, 2001). Indelning av icke-funktionella krav Look and Feel-krav Användbarhetskrav Prestationskrav Operativa krav Underhålls- och Kompatibilitetskrav Säkerhetskrav Kulturella och politiska krav Rättsliga krav Vi kommer nu att titta närmare på användbarhetskraven i Robertsons och Robertsons (2001) kravmall och beskriva deras innebörd. Beskrivningarna har en direkt koppling till kravmallen i figur 10 ovan. Även användbarhetskraven delas in i delkrav. Dessa är enkelhet i handhavandet och enkelhet i inlärningen. 9

Användbarhetskrav 1. Enkelhet i handhavandet (Eng. Ease of use): Den första punkten under användbarhetskrav beskriver önskan om hur enkel produkten ska vara att använda för den tilltänkta användaren. Produktens användbarhet stammar från den tilltänkta användarens förmåga att använda produkten och från hur komplexa produktens funktioner är. Syftet är att ge utvecklaren vägledning vid implementationen av produkten som på så vis infriar användarnas förväntningar. Exempelkrav på enkelhet i handhavandet är att: Produkten ska vara enkel för en 10-åring att använda. Produkten ska hjälpa användaren med att undvika att göra fel. Produkten ska kunna användas av blinda. Exemplen påvisar användarens intentioner. För att ytterligare förtydliga kraven är det lämligt att lägga till en grad av acceptans, enligt Robertson och Robertson. Det är detta de kallar Fit Criterion i kravmallen. Fit Criterion har en given koppling till de tilltänkta användarna och kräver verkliga testpersoner. Fit Criterion anger hur väl applikationen uppfyller de krav som ställs av användaren. Ett exempel på Fit Criterion kan vara att; 90% av testpanelen med 10-åringar måste kunna genomföra en lista med uppgifter inom utsatt tid. Ett annat exempel kan vara att; 10% av användarna måste i en enkätundersökning svara att det tog max två veckor att lära sig använda produkten. 10

2. Enkelhet i inlärning (Eng. Ease of learning): Den andra punkten under användbarhetskrav beskriver hur enkelt det ska vara att lära sig att använda produkten. Kravet är alltså en tidsangivelse som sträcker sig från nolltid, d.v.s. användaren ska kunna använda produkten direkt t.ex. en parkeringsautomat, till lång tid för högteknologiska produkter. Syftet med kravet är att specificera den inlärningstid som (kunden tycker) är acceptabel innan användaren kan använda produkten. Kravet hjälper designern med att förstå hur användaren lär sig använda produkten. Resultatet kan t.ex. bli en hjälptext eller en steg för steg anvisning som guidar användaren i handhavandet. Alternativt designas produkten så att det är uppenbart för användaren hur den ska användas. Exempel på enkelhet i inlärningkrav är: Produkten ska vara enkel för en ingenjör att lära sig efter en fem veckors introduktionskurs. En arkitekt ska kunna använda programmet direkt. Vem som helst ska kunna använda produkten genast. Användaracceptansen (Fit Criterion) för det första exemplet ovan är: En ingenjör ska producera [ett specifikt resultat] inom [en viss tid]. Eller i exempel två, t.ex: 80% av arkitekterna i arkitekttestgruppen ska kunna lösa [ett antal uppgifter] utan särskild instruktion. Det är viktigt att designern ser till att kraven på enkelhet i inlärningen stämmer överens med de verkliga användarnas krav. Vi tycker att de verkliga användarna har en självklar roll i formuleringen av användbarhetskraven. Genom fältstudier har kontextspecifika förutsättningar noterats, vilka sedan kan ligga till grund för användbarhetskraven. I användar-workshops kan användbarhetskraven diskuteras och omformuleras. På så vis ökar chansen att man får med alla specifika användbarhetsomständigheter. 11

Krav i designen av laboration 2 Syftet med laboration 2 i HCI-kursen var att i praktiken försöka förena användning av designers standardutvecklingsresurser med principer för "människor datorinteraktion". Laborationen skulle laborationsgruppen utföra ett enkelt användartest på prototypen enligt ett utvärderingsprotokoll. Prototypen skulle också utvärderas av annan laborationsgrupp enligt samma utvärderingsprotokoll. I laborationen skapade vi en telefonbok (figur 6) med lite nytänkande i form av att kontakterna i boken presenterades som klickbara bilder på respektive person. Eftersom laborationen skulle utvärderas av annan laborationsgrupp och oss själva så ville vi skapa en så välfungerande och användbar prototyp som möjligt. Vi skulle följdaktligen kunna formulera ett användbarhetskrav på laboration 2 såsom att: En person med grundläggande datorvana ska genast kunna använda vår applikation utan särskilda instruktioner. Reflektion på krav Vi har sett att det finns två grundtyper av krav. Funktionella och icke-funktionella. De funktionella kraven behandlas utmärkt vid applikationsutveckling i disciplinen objekorienterad systemutveckling. Betydligt mindre vikt läggs dock på de ickefunktionella kraven och kopplingen till de verkliga användarna. Vi tror att HCI disciplinen Interaktionsdesign kan komplettera kravetableringen genom sina omfattande metoder för etablering av icke-funktionella krav. För informationsinsamlingen som ligger till grund för kraven har en lång rad metoder adapterats. Dessa är t.ex. intervjuer, observation och fokusgrupper. Genom en grundläggande informationsinsamling och analys kan tydliga krav formuleras. Dessa ligger sedan till grund för den vidare produktutvecklingen. Om produkten är en applikation så erbjuder objekorienterad systemutveckling utmärkta möjligheter för vidare analys och design på sitt manér med diagram som beskriver systemets funktion. 12

Reflektion på HCI-kursen och dess innehåll I kursen har vi lärt oss att skapa mer användbara applikationer. Kunskapen om designmönster är värdefull och något vi kommer ha nytta av i vårt framtida yrkesutövande. Man ska inte överbelasta användarens minne med komplicerade procedurer för att utföra en uppgift (Preece, Rogers, Sharp, 2002) De är just detta designern arbetar bort genom att designa med hjälp av designmöster. En användare ska känna att de förstår hur de ska gå tillväga när de ska utföra en uppgift. Är det för svårt, komplicerat och otydligt så kommer de troligtvis inte att använda programmet igen. I vår första övning fick vi arbeta på UNIX arbetsstationer. Där etablerade vi en utvecklingsmiljö med de verktyg vi behöver för att skriva och kompilera program. Eftersom UNIX miljön var ny för oss så blev upplevelsen vid första mötet detsamma som man kan tänka sig att en nybörjare upplever vid första mötet med en ny applikation eller produkt. En stor del av första övningen bestod i att bekanta sig med miljön och dess verktyg. Övning två tog vid efter den första övningen. Nu skulle vi manipulera några olika delar i ett färdigt program. Den första uppgiften gick ut på att göra applikationens bakgrundsfärg blå. Övningen fungerade som en mjukstart i användargränssnittsdesign i Java som vi vid det tillfället inte hade jobbat med på några månader. Genom att introducera oss till en ny arbetsmiljö fick vi en bredare syn på hur man kan arbeta när man skapar nya program. Att arbeta i par har både för och nackdelar. En fördel är att man motiverar varandra till fortsatt arbete. Man fungerar som varandras bollplank för att diskutera idéer och metoder. Att genom en egen HCI-text få chansen att fördjupa sig inom några valfria områden har varit intressant och roligt. Vi valde att fokusera på designmönster som vi tycker har en viktig plats i användargränssnittsdesign. Vi valde också att fokusera på kravetablering 13

eftersom vi inte läst särskilt mycket om det tidigare på MDA-programmet, samtidigt som vi känner att kravetableringen kan ha en viktig roll i vårt framtida yrkesutövande. Valfriheten i laborationer och examinationsmoment har bidragit till att göra kursen bra. Vi tycker sammanfattningsvis att det har varit en rolig och lärorik kurs. 14

Källförteckning Robertson, James & Susanne: Volere Requirements Specification Template Edition 8. http://www.volere.co.uk. 2001. Larman, Craig. Applying UML And Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall. 1998. Kyhlbäck, Hans. Föreläsning i HCI på BHT: MDI och Standard, krav och testning Blekinge Tekniska Högskola. Den 21 november 2002. Grand, Mark. Patters in Java: Volume 2. Wiley. 1999 Preece, Rogers, Sharp. Interaction Design Beyond human-computer interaction. Wiley 2002. 15