Säkerhets- och Behörighetssystem ur ett användningscentrerad perspektiv

Transkript

1 ANVÄNDARCENTRERAD SYSTEMDESIGN Uppsala Universitet HT 2003 Säkerhets- och Behörighetssystem ur ett användningscentrerad perspektiv Johan Snellman Zakai kass-saliba Andreas Nissemark Pavel Carballo

2 Innehållsförteckning Sammanfattning Inledning Uppgift Metod Användningscentrerad Systemdesign Modellens kärna Processen Kravdialog Domänmodellering Uppgiftsmodellering med essentiella användningsfall Användarrollsmodellering Uppgiftsmodellering... 7 Exempel på Essentiella Användningsfall Gränssnitsinnehållsmodellering Implementationsmodellering Konstruktion Arkitektuell Iteration Användbarhetsinspektion Hjälpsystem och Dokumentation Standarder och Stildefinitioner Operational Contextualization Objektstrukturerad Design Projektplan Behörighets- och Säkerhetssystem Projektmål Förutsättningar Resurser Aktiviteter Kravdialog Uppgiftsmodellering Gränssnittsinnehållsmodellering Implementationsmodellering Konstruktion Hjälp och Dokumentation Tidplan För- och Nackdelar Referenser Kontaktinformation

3 Sammanfattning Projekt gick ut på att beskriva, planera och diskutera hur ett behörighets- och säkerhetssystem skall utvecklas utifrån Constantine & Lockwooods bok Software for use. Användningscentrerad systemdesign, vilket beskrivs av C&L, går ut på att med hög abstraktionsnivå skapa så kallade essentiella användningsfall, där de tekniska detaljerna sätts åt sidan för att lämna plats åt nytänkande. Resultatet av detta bör vara att utvecklarnas fokus alltid ligger på användningen av systemet samt användarnas behov. Typiskt för C&L: s teorier är att användarna endast skall involveras vid vissa aktiviteter i processen. Något som starkt strider mot ett användarcentrerat synsätt. 3

4 1 Inledning 1.1 Uppgift Uppgiften var att utveckla ett behörighets- och säkerhetssystem, som skall användas av olika typer av organisationer som företag, myndigheter, skolor etc. Systemet behöver vara flexibelt och anpassningsbart till organisationer med olika skyddsbehov och olika typer av lokaler. Systemet ska hantera in- och utpassering av personer, larm och lås av lokaler, både yttre entréer och rum inne i lokalen, och föremål som t.ex. skåp. Personer ska kunna ha olika behörighet till olika delar av lokalerna och vid olika tidpunkter. 1.2 Metod Genom att ha studerat hur Constantine & Lockwooods bok Software for use beskriver användningscentrerad design har vi kunnat utforma en projektplan för vår specifika uppgift. Vi kommer att kortfattat beskriva processen med de aktiviteter som ingår. För varje steg i processen beskrivs vilka produkter som kommer ut, vilken dokumentation som produceras och vilka olika roller som ingår. 2 Användningscentrerad Systemdesign 2.1 Modellens kärna Kärnan i användningscentrerad design består av tre enkla, men nära relaterade abstrakta modeller. Användarroll Role Model: En användarroll representerar en slags relation mellan användaren och systemet. Essentiella Användningsfall Task Model: Essentiella användningsfall är en mer abstrakt form av ett vanligt användningsfall. Gränssnitsinnehållsmodellering Content Model: Gränssnitsinnehållsmodellering beskriver innehållet och organisationen av det användargränssnitt som behövs för att stödja uppgiften. 4

5 2.2 Processen Användningscentrerad design är en systematisk process som använder abstrakta modeller för att utveckla system, som till fullo stödjer alla uppgifter som utförs av användaren. Användningen av denna process resulterar ofta i mindre och enklare system som uppfyller alla funktionskraven. Figuren nedan ger en överblick över den användningscentrerade designprocessen. Den visar alla aktiviteter som ingår i processen och hur dessa förhåller sig samt överlappar varandra. Förloppet skall läsas snett uppifrån vänster och diagonalt nedåt, men skall inte blandas ihop med vattenfallsmodellen, som utför aktiviteterna sekventiellt. I den användningscentrerade designprocessen utförs oberoende aktiviteter parallellt när det anses vara praktiskt. 5

6 2.3 Kravdialog Syftet är att komma fram till vilka krav som skall finnas på systemet. Detta fås genom en dialog mellan utvecklarna och användarna av systemet. Kraven ska vara abstrakta och fokuseringen skall vara på intentionerna och själva uppgiften mer än på detaljerna. En kravspecifikation produceras som särskiljer behov från önskemål. Här kommer utvecklare, designers och användare att delta. Kravspecifikationen kommer att ändras under projektets gång. 2.4 Domänmodellering Här kommer verksamheten att modelleras. Man undersöker vilka förutsättningar som finns för systemet samt vilka metoder som skall användas. Domänmodellering utvecklar en representation av alla interrelaterade koncept och bygger upp applikationens domän samt etablerar relationerna aktiviteterna emellan. Bilden nedan beskriver kärnan i den essentiella modellen samt de logiska relationerna mellan de viktigaste delarna 2.5 Uppgiftsmodellering med essentiella användningsfall Meningen med denna oerhört viktiga aktivitet är att utveckla en klar och komplett bild av arbetet som skall stödjas genom roll- och uppgiftsmodellering Användarrollsmodellering Första steget i processen användningscentrerad design är att definiera rollmodeller, d.v.s. kartlägga och förstå de olika användarrollerna. En användarroll är en sammanfattning av de behov, intressen, förväntningar, beteenden och det ansvar som karakteriserar ett förhållande mellan en sorts användare och systemet. 6

7 Användare är av intresse för utvecklarna, inte för sin egen skull, utan på grund utav de roller som de har i förhållande till systemet som skall designas och byggas. Det är viktigt att komma ihåg att en roll är en abstraktion, inte en person, jobbtitel, position eller funktion. Det är inte heller en verklig grupp av människor, utan en abstrakt klass definierad av en viss typ av förhållande till systemet. En användarroll kan spelas av många olika människor samtidigt som en person kan spela fler olika roller inom samma system. Rollmodelleringen kan ofta inledas med en viss användare i tanken och generaliseras sedan till en abstrakt användarroll. När tillräckligt många roller är skapade väljs det ut ett par stycken som ur något perspektiv är viktigast för designarbetet. Dessa kallas fokus användarroller och spelar en viktig del i utformningen av gränssnittet. I stora projekt med många olika roller underlättar det om man skapar så kallade användarrollsdiagram. De beskriver hur de olika rollerna är sammankopplade och definierar vem som skall använda systemet och hur. Rollerna kan förhålla sig till varandra på flera olika sätt, exempelvis affinity, classification eller composition Uppgiftsmodellering Uppgiftsmodelleringen beskriver hur en uppgift utförs sekventiellt och kan byggas på antingen scenarium, användningsfall eller essentiella användningsfall. Enligt Constatine and Lockwood så baseras uppgiftsmodelleringen på essentiella användningsfall. Essentiella modeller är menade att fånga essensen i problemen genom idealiserade och teknologi fria beskrivningar. Skillnaden mellan dessa två olika sorters användningsfall är att de essentiella baseras på de syften och intentioner som användaren har snarare än hur det utförs. Detta resulterar i att användarna enkelt kan förstå och utvärdera de essentiella användningsfallen. Eftersom dessa är mer problemorienterade istället för lösningsorienterade lämnar det fler designmöjligheter öppna. Genom att eliminera alla onödiga antaganden eller restriktioner om hur ett system ska implementeras, ger essentiella användningsfall en mer abstrakt, förenklad och generaliserad syn på användningsfall. Dessa är ofta kortare och enklare än konkreta användningsfall för samma interaktioner. Vanliga användningsfall lutar alltför nära mot implementering och håller inte kvar fokus på de problem som användarna möter. Inom uppgiftsmodellering finner vi också användningsfallsdiagram. För ett givet problem delar dessa upp systemets totala funktionalitet i en samling relaterade essentiella användningsfall. Genom att särskilja distinkta och meningsfulla interaktioner och visa hur de är sammankopplade kan vi konstruera en enklare översiktmodell för stödarbetet. Det är inte nödvändigt att diagrammen skall vara fullständigt korrekta, men modellen bör dela upp systemets användning i ett antal användningsfall som känns naturliga för användarna. 7

8 För att anse den essentiella användningsfallsmodellen komplett bör man identifiera en eller fler fokus användningsfall. Runt dessa centreras designarbetet och stödjer ofta fokus användarrollerna som identifierats i rollmodellering. Exempel på Essentiella Användningsfall I vanliga användningsfall beskrivs det användarinteraktionen med systemet. Typiskt beskrivs de handlingarna användaren utför samt hur systemet svarar. Nedan visas det klassiska exemplet: Bankomatsuttag. Uttag (Användningsfall) Användaruppgift Sätt in kort Skriver in kod Tryck ner tangent Tryck ner tangent Skriv beloppet Tryck ner tangent Ta kortet Ta kontanterna Systemets respons Avläs den magnetiska remsan Begär kod Verifiera kod Visa transaktions menyn Visa konto menyn Visa inmatningsfält för önskat belopp Visa beloppet Returnera kortet Betala ut beloppet I det essentiella användningsfallet beskriver man interaktionen fri från tekniska specifikationer. Resultatet blir en mer abstrakt beskrivning av användarens samspel med systemet. Uttag (Essentiellt användningsfall) Användaruppgift Identifiera sig Välja Ta kontanterna Systemets respons Verifiera identitet Erbjuda valmöjligheter Betala ut beloppet 8

9 2.6 Gränssnitsinnehållsmodellering Efter uppgiftsmodelleringen följer modelleringen av gränssnittets innehåll (Interface Content Model). Detta är en abstrakt (förenklad) representation av innehållet i de olika interaktionsytorna som bygger upp gränssnittet och relationen mellan dessa. Här skapas det också en så kallad navigationsdiagram som beskriver hur man förflyttar sig inom systemet. I denna process början skapas en behavioral map som modellerar ett enskilt essentiellt användningsfall. Sedan kombineras alla behavioral maps till ett diagram som beskriver hela interaktionsgången samt alla tänkbara utfall av interaktionen med systemet. Då kan man enkelt se arbetsflödet för ett användningsfall. Denna navigeringskarta tillsammans med en modell av gränssnittets innehåll kallas för en abstrakt prototyp. Vid enkla pappersmodeller kan dessa behöva kompletteras med tillståndsdiagram för att förklara prototypens beteende. Under implementationen, som är nästa steg i processen, kommer innehållsmodellerna att gestaltas av t ex fönster, dialogboxar och listor. Innehållsmodellen beskriver de tänkta delarna i gränssnittet. 2.7 Implementationsmodellering Implementationsmodellering är processen där en mer konkret modell med bl. a. fönster, listor och knappar skapas. Man utgår från den abstrakta modellen för att skapa prototyper, vanligtvis på papper, som ska se ut och fungera som det slutgiltiga systemet. Oavsett hur den ser ut är implementationsmodellen en ypperlig möjlighet att ta fram de slutgiltiga detaljerna utan att behöva skriva någon kod. Det är också ett effektivt medium för utvärdering och kommunikation med användarna och beställare. Constantine & Lockwood förordar ett antal designprinciper för att konstruera ett bra användargränssnitt. Organisera användargränssnittet på ett strukturerat och bra sätt baserat på precisa och konsistenta designmodeller. Sätt saker som hör till varandra på samma plats och gör så att saker som hör samman liknar varandra. Designa systemet så att ofta använda funktioner är enkla att genomföra, enkla att förstå och har enkla kortkommandon. Se till att alla valmöjligheter och all funktionalitet som krävs för att genomföra en uppgift är synliga samtidigt utan att ha med redundant och onödig information. Håll användaren uppdaterad om vad som händer i systemet genom enkla, lättförståeliga och entydiga förklaringar. Systemet skall vara flexibelt och tolerant för misstag från användaren. Det skall finnas funktioner för att ångra inmatningar och systemet skall kunna tolka olika sorters inmatningar. Gränssnittet skall vara konsistent i fråga om utseende, placering av komponenter och beteende. Detta gör det lättare att lära och komma ihåg hur det skall användas. 9

10 2.8 Konstruktion Konstruktion innebär att man i implementationsprocessen startar med den viktigaste funktionaliteten och därefter implementerar varje ny funktionalitet i prioritetsordning. Denna del utförs parallellt med Arkitektuell Iteration. 2.9 Arkitektuell Iteration Denna del är en iterativ process där mjukvaruarkitekturen och koden utvärderas. Utvecklarna tittar över saker som kodstruktur, paket, kommunikationsteknik, organisation av databaser och strukturella beslut. När utvecklarna hittar svagheter i de olika delarna så omevalueras dessa beslut och åtgärder tas för att förbättra strukturen. Koden skall vara flexibel och modulär Användbarhetsinspektion Användbarhetsinspektioner sker två gånger per iterationscykel, före och efter implementationsfasen. Dessa kan göras på många olika sätt och boken Software for Use nämner att man kan använda sig av olika metoder, t ex expertutvärdering och scenariebaserade utvärderingar, varav vissa metoder involverar användare och andra inte. Inspektionerna kompletterar ett gott gränssnittsarbete genom att hitta problem och begränsningar i designen. Dessa inspektioner och tester av användbarhet delas upp i olika typer där granskning, testning och inspektion är några viktiga exempel. Till denna grupp räknas flera olika former av mer eller mindre formella, systematiska processer för att lokalisera användbarhetsproblem. I en inspektion jobbar utvecklare och/eller användbarhetsexperter, ibland tillsammans med användare, med att hitta användbarhetsdefekter. Inspektion kan göras på nästan vad som helst, t.ex. kravspecifikation, designmodell, pappersprototyp, skärmbilder, en fungerande prototyp eller system. Inspektion gör sig bäst på tidiga pappersprototyper, den slutliga gränssnittsdesignen, på den eventuella fungerande prototypen och på den första releasen av systemet. Inspektion är en snabb och enkel process och kan leverera användbar information mycket tidigare än testning kan göra. Strukturerade inspektioner är organiserade aktiviteter med specifika roller och ansvarsområden. De utförs i steg för steg processer som försäkrar att viktiga aktiviteter är kompletta. 10

11 2.11 Hjälpsystem och Dokumentation Dokumentation och hjälpsystem har olika syften. Dokumentation är inte lämpligt som hjälp, även om det ibland används som det. Dokumentation dokumenterar, hjälp hjälper. Den bästa hjälpen skrivs i journalistisk stil, där man följer nedanstående tre punkter: Berätta hela historien i rubriken. Berätta hela historien i den första meningen. Berätta hela historien i första stycket. Oavsett när läsaren slutar läsa, kommer den att ha förstått vad historien handlar om. På detta sätt kan läsaren bestämma själv hur detaljerad information den vill ha. Vid design av hjälpsystem kan man genom att konstruera olika användningsfall för hjälpsystemet uppnå en optimal hjälpfunktion. Användningsfallen täcker då in de olika typer av användarfrågor som kan uppstå vid en konfrontation med systemet och de olika intentioner som ligger bakom att en person söker upp hjälpsystemet Standarder och Stildefinitioner Standarder upplevs ofta som mer absoluta och specifika medan stilguider inför bredare principer, såsom att låta användaren ha kontroll och tillåta en viss grad av användarmisstag. Det är viktigt att utvecklarna bygger upp erfarenhet innan standardisering av systemet börjar. Risken är annars att standarder inte följs eller inte fungerar, då ett alltför snabbt införande av standarder medför risken att utvecklarna inte ser vitsen med dem och därför blir mindre benägna att följa dem. Standarder utvecklas genom en kontinuerlig och adaptiv process som pågår jämte projektets övriga arbete. Både standarder och stilguider ska överses periodiskt för att försäkra att de fortfarande är giltiga, relevanta och aktuella. Eftersom standarder och stilguider kan ha en väldigt omfattande effekt på olika delar i projektet är det viktigt att dessa utvecklas med försiktighet. Kvaliteten som standarder håller kan utvärderas efter konformitet, grad av täckning, användbarhet, konsistens och till vilken grad den slutliga produkten verkligen reflekterar standarden Operational Contextualization Operational Contextualization används för att anpassa designen till den aktuella miljön som systemet skall användas i. Miljöns påverkan på systemet är underordnad betydelsen av de arbetsuppgifterna som systemet är avsett att stödja. Denna fas löper kontinuerligt genom hela projektarbetet Objektstrukturerad Design De stora fördelarna med att använda ett objektorienterat arbetssätt är bland annat att det går att sortera ut vissa händelser från skilda delar av systemet som behandlas på samma 11

12 sätt. På så sätt minskar komplexiteten. Detta gör också att systemet kan beskrivas på andra former, till exempel med UML-diagram. 12

13 3 Projektplan Behörighets- och Säkerhetssystem 3.1 Projektmål Uppdraget består i att utveckla ett behörighets- och säkerhetssystem som skall användas av olika typer av organisationer som företag, myndigheter, skolor etc. Systemet skall vara flexibelt och anpassningsbart till organisationer med olika skyddsbehov och olika typer av lokaler. Systemet skall hantera in- och utpassering av personer, larm och lås av lokaler, både yttre entréer och rum inne i lokalen, och föremål som t.ex. skåp. Personer ska kunna ha olika behörighet till olika delar av lokalerna och vid olika tidpunkter. 3.2 Förutsättningar Gemensamt för alla våra kunder är att de inte har något tidigare behörighets- och säkerhetssystem. Alla organisationer förutsägs vara medelstora med väldefinierad hierarki. 3.3 Resurser De aktiva projektrollerna beskrivs nedan. En användarroll kan spelas av många olika människor, samtidigt som en person kan spela flera olika roller inom samma system. Beställare (Best): Representant från skola, myndighet eller företag. Projektledare (ProjLed): Huvudansvarig för projektet gentemot beställaren. Användbarhetsdesigner (AnvDes): Ansvarig för att projektet leds på ett användningscentrerat sätt. Kravansvarig (KravAns): Ansvarig för framtagning och utvärdering av kravspecifikationen. Användningsfallsansvarig (AnvFall): Ansvarig för framtagning och utvärdering av essentiella användningsfall. Utvärderingsansvarig (UtväAns): Ansvarig för utvärderingsprocessen. Användargruppsansvarig (AnvGrAns): Ansvarig för samordning och kontakt med användargruppsdeltagarna. Användargruppsdeltagare (AnvGrDel): Tänkt användare av systemet. Systemarkitekt (SysArk): Ansvarig för designbeslut av olika slag. Utvecklare (Utv): Implementerar systemet. Hjälp- och Dokumentationsansvarig (HjDokAns): Ansvarig för hjälp och dokumentation. 13

14 3.3 Aktiviteter Aktiviteterna nedan står inte i någon särskild kronologisk ordning och kan överlappa varandra Kravdialog Beskrivning: Under denna inledande fas av projektet förs det samtal där användarnas önskningar och behov beskrivs. Samtalen inleds med Best representanten från den beställande organisationen. Under dessa samtal ombes Best. att beskriva den nuvarande säkerhetssituationen, alltså vilka grupper av användare det finns och vilken behörighet varje grupp skall ha. Samtal förs med representanter från dessa olika grupper, vilket resulterar i en initial användarrollsmodellering. Arbetet med kravspecifikationen inleds efter dessa samtal. I den initiala versionen av kravspecifikationen tar man upp ett antal funktionella och formmässiga krav samt användbarhetskriterier, begränsningar etc. Medverkande: Best, ProjLed, AnvDes, KravAns, AnvGrAns, AnvGrDel. Resultat: Första versionen av kravspecifikationen levereras Uppgiftsmodellering Beskrivning: Denna fas i projektet inleds med fortsatt modellering av de olika användarrollerna genom intervjuer. De tänkta användarna och deras vanor kartläggs och med hjälp av ritningar bestäms de olika säkerhetsområdena. Ur dessa kartläggningar väljs det vilka roller som skall vara fokus användarroller och vid behov skapas det användarrollsdiagram. Diagrammen beskriver relationerna mellan de olika rollerna. Nästa steg i utvecklingen är att börja modellera de olika essentiella användningsfallen. Dessa skapas enligt den tidigare producerade kravspecifikationen. Ömsesidig förståelse mellan användare och utvecklare är självfallet en förutsättning för lyckade essentiella användningsfall. På samma sätt som man valde fokus användningsgrupper, kan man välja fokus användningsfall som man baserar utvecklingen på. Vid behov kan man lägga till ett användningsfallsdiagram. Här skapas en komplett och tydlig bild av de arbetsuppgifter systemet skall stödja. Medverkande: AnvFall, AnsDes, KravAns, HjDokAns, SysArk, AnvGrDel. 14

15 Resultat: Användarrollsbeskrivning, Användarrollsdiagram, Användningsfallsbeskrivning samt Användningsfallsdiagram Gränssnittsinnehållsmodellering Beskrivning: Som namnet antyder modelleras det här användargränssnittets innehåll, struktur och organisation utan att behöva rita specifika bilder och behöva låsa sig vid en speciell gränssnitt. Prototyperna skall vara enkla pappersskisser utan specifika detaljer. Post-it lappar kan påminna utvecklaren om prototypens abstrakta natur. Faktumet att Post-it lappar inte ser ut som verkliga gränssnitt är en konstant påminnelse för utvecklaren, att det är en abstrakt metod, som lämnar många vägar öppna. Vid behov kompletteras dessa med tillståndsdiagram som beskriver arbetsflödet. Genom att arbeta på detta sätt bibehåller man fokus på användningen och användarnas behov. Medverkande: SysArk, Utv, AnvDes, KravAns, AnvGrDel, HjDokAns. Resultat: Abstrakta beskrivningar av informationsytor, innehållet i respektive yta samt deras relationer Implementationsmodellering Beskrivning: I detta steg kommer mer konkreta modeller att skapas. Här diskuteras vilka plattformar som finns och utvärderar dessa med hänsyn till behovet hos vår beställare/användare. I tidigare itereringar använder man sig av pappersmodeller, för att övergå till mer avancerade modeller senare i iterationsprocessen. Här finns det goda möjligheter för att bestämma slutgiltiga detaljer. Medverkande: SysArk, Utv, AnvDes, KravAns, HjDokAns. Resultat: Konkreta och detaljrika modeller Konstruktion Beskrivning: Bygga och implementera systemkomponenter utifrån den essentiella användningsfallsmodellen samt de beslutade ändringarna i de olika iterationerna. Medverkande: SysArk, Utv Resultat: Systemkomponenter. 15

16 3.3.6 Användbarhetsinspektion Beskrivning: Inspektionerna kommer att ske två gånger per iterationscykel, före och efter implementationsfasen. Enligt litteraturen finns det ett antal olika sätt att göra dessa inspektioner på. Där ingår utvecklare och/eller användbarhetsspecialister, ibland i samspel med användare. I vårt fall kommer användarna att vara involverade i allra högsta grad. Användarna får möjlighet att testa systemet under bevakning och tydliga användbarhetsproblem omhändertas. Medverkande: UtväAns, Utv, AnvDes, AnvGrAns, AnvGrDel, HjDokAns. Resultat: Lista över användbarhetsproblem Hjälp och Dokumentation Beskrivning: För att stödja systemet till fullo behövs det en aktivitet där hjälp och dokumentation skapas. Dokumentation skapas i form av en pappersmanual, där systemets olika delar beskrivs steg för steg. Lätt hanterliga och lättåtkomliga hjälpfunktioner skall stödja användarna. Denna aktivitet fortlöper under hela processens gång. Användarna väljer vi att inte involvera på grund av att hjälp- och dokumentationsansvariga varit med under hela processen och känner till användbarhetsproblemen. I slutet vill vi ha Projektledaren med för att utvärdera hjälp- och dokumentationsavsnitten. Medverkande: HjDokAns, ProjLed. Resultat: En komplett hjälp samt en fullständig dokumentationshandling. 3.4 Tidplan Vecka Aktiviteter Kravdialog Domänmodellering Uppgiftsmodellering Gränssnitsinnehållsmodellering Implementationsmodellering Användbarhetsinspektion Konstruktion Ark. Iteration Objektstrukturerad design Oper. Contex. Standard och stil definition Hjälp och dokumentation 16

17 4 För- och Nackdelar Den självklara skillnaden mellan Constantine och Lockwoods teorier och de teorier som framställs i kursboken Användarcentrerad Systemdesign (Gulliksen, Göransson) är att C & L valt att koncentrera sig på användningen av systemen istället för på användarna. Fokus ligger alltså på hur systemen skall användas, inte vem som skall använda dem. Vi anser att användarna inte behöver vara med i alla utvecklingsprocessens aktiviteter. Användarna kan i många fall hjälpa utvecklarna att definiera de behoven som systemen skall tillfredställa, dock kan de inte tillföra mycket vid exempelvis rent tekniska steg av utvecklingsprocessen. Essentiella användningsfall kan kräva väldigt duktiga utvecklare, som med relativt abstrakta beskrivningar skall kunna implementera riktigt användbara system. Ännu en nackdel med dessa användningsfall är att användarna kan ha svårt att förstå abstraktionsnivån och därmed kunna utvärdera de presenterade användningsfallen. De konkreta användningsfallen ger en bättre grund för utvecklarna att jobba efter. Dock kan man anse som en nackdel att konkreta användningsfall ofta medför att man låser sig för tidigt vid vissa lösningar och fokusen kommer bort från användningen av systemet samt användarnas behov. När det handlar om prototyper finns det ett antal skillnader. C & L ser som en förutsättning för användningscentrerad systemdesign att prototyper utvecklas sent utvecklingsprocessen. Detta för att man vill ha en stark grund att stå på innan prototypen designas. Systemutveckling anser vi skall se som en trial-and-error process där tidiga prototyper skulle innebära bättre inlärnings- och förståelsemöjligheter för användarnas situation. 5 Referenser Användarcentrerad Systemdesign: Jan Gulliksen, Bengt Göransson Software for Use: Larry L Constantine, Lucy A.D Lockwood 6 Kontaktinformation Johan Snellman: josn8375@student.uu.se Zakai kass-saliba: zico@zacay.com Andreas Nissemark: nissemark@hotmail.com Pavel Carballo: paca7069@student.uu.se 17

18 18