Metod för initial behovs- och kravhantering i agila systemutvecklingsprojekt

L I N U S E R I C S S O N o c h E M E L I E S V A R T L I N G

Examensarbete Stockholm, Sverige 2011

Metod för initial behovs- och kravhantering i agila systemutvecklingsprojekt

L I N U S E R I C S S O N o c h E M E L I E S V A R T L I N G

Examensarbete i människa-datorinteraktion om 30 högskolepoäng vid Programmet för teknisk fysik respektive medieteknik Kungliga Tekniska Högskolan år 2011 Handledare på CSC var Gustav Taxén Examinator var Olle Bälter

TRITA-CSC-E 2011:060 ISRN-KTH/CSC/E--11/060--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc

Metod för initial behovs- och kravhantering för systemutveckling i agila projekt Sammanfattning

Denna studie föreslår en metod för behovs- och kravhantering i början av systemutvecklingsprojekt. Studien har utförts på uppdrag av Försvarets Radioanstalt (FRA) där vi också har utfört arbetet. Vi har även utfört studiebesök på fem företag i stockholmsområdet för att få en översiktlig bild av hur behovs- och kravhantering kan gå till i näringslivet.

Initialt utgick vårt arbete från skapandet av en första backlog i scrumutveckling då uppdragsgivaren uppgav sig sakna ett inbyggt stöd för det i utvecklingsmetodiken. Vår undersökning visade att problemet inte bara låg i skapandet av backlogen. Det saknades ett enhetligt sätt att skapa en initial kravbild oavsett vilken utvecklingsmetodik som användes. Vi fann däremot att processer från projektstart till färdigt system var väletablerade i verksamheten. En konsekvens av bristen på process för initial behovs- och kravhantering blir att steget mellan idé och projektstart sker på olika sätt i varje projekt och att projektteamen ibland upplever detta arbete som dubbelarbete. Syftet med vårt arbete blev att ta fram en metod för den initiala behovs- och kravhanteringen som utifrån FRA:s behov ger stöd för detta arbete.

Method for Requirements Engineering in Agile Software Development Abstract

This study suggests a method for requirements engineering in early phases of software development projects. The study is performed on behalf of the National Defence Radio Establishment (Försvarets Radioanstalt), where the study was also realised. We have also conducted study visits at five companies located in the Stockholm area to get an overview on how requirements engineering is done in industry.

Initially our work was based on the issue on creating the initial backlog in the authority!s Scrum based development projects, which our commissioner stated had no methodology for initial backlog creation. It turned out that the problem was more widespread than just creating the backlog. We discovered that there was a lack of methodology in the whole initial requirements engineering process, regardless of development methodology used. On the contrary we found that the process from development to finished system was well established in the organization. The lack of methodology in the initial requirements engineering process results in variation in how the steps between idea and project initialization are carried out. The project members express that this work is often regarded as redundant. Our task was then to develop a methodology to support the initial requirements engineering processes adapted to our commissioner!s needs.

Tack Vi vill särskilt tacka vår handledare Fredrik som gett oss många viktiga uppslag och generöst delat med sig av sina erfarenheter. Tack Lennart för att du möjliggjort detta examensarbete och funnits tillhands under resans gång. Tack till övrig personal på Försvarets Radioanstalt (FRA) som med intresse och entusiasm hjälpt oss framåt i vårt arbete.

Tack till våra respondenter utanför FRA, som generöst och med stort intresse delat med sig av sin stora erfarenhet inom kravhantering och användbarhet. Utan er hade inte arbetet gått att göra.

Ett sista tack vill vi ägna till våra nära och kära som har haft tålamod med oss när vi arbetat med examensarbetet, avskärmade från omvärlden.

InnehållsförteckningBakgrund ........................................................................................................................................1!

Bakgrund till studien ..................................................................................................................1!Problemformulering ...................................................................................................................1!Syfte och mål..............................................................................................................................1!Frågeställning .............................................................................................................................2!Avgränsning ...............................................................................................................................2!Språkbruk ...................................................................................................................................2!Målgrupp ....................................................................................................................................2!

Metod .............................................................................................................................................3!Metodteori ..................................................................................................................................3!Induktion och deduktion.............................................................................................................3!Grounded Theory .......................................................................................................................3!Reliabilitet och validitet .............................................................................................................3!Datainsamling.............................................................................................................................4!

Intervjuer ................................................................................................................................4!Observationer .........................................................................................................................4!Designaktiviteter ....................................................................................................................4!

Prototyper ...........................................................................................................................4!Tillvägagångssätt........................................................................................................................5!

Val av metodteori och förklaringsmodell...............................................................................5!Studiens reliabilitet och validitet............................................................................................5!Val av datainsamling ..............................................................................................................6!

Praktiskt genomförande..............................................................................................................7!Beskrivning av vår förförståelse ............................................................................................7!Urval av teori..........................................................................................................................7!Urval av respondenter ............................................................................................................7!Intervjuerna ............................................................................................................................7!Observationerna .....................................................................................................................8!Dataanalysen ..........................................................................................................................8!Designprocessen.....................................................................................................................8!

Teoretisk referensram...................................................................................................................10!Systemutveckling .....................................................................................................................10!Projektstyrning .........................................................................................................................10!

Effektstyrning.......................................................................................................................11!Agil utvecklingsmetodik ..........................................................................................................12!

Scrum ...................................................................................................................................13!Rational Unified Process ..........................................................................................................13!Krav och kravhantering ............................................................................................................14!Användarcentrerad systemutveckling ......................................................................................16!

Organisationer och användarcentrerad systemutveckling....................................................16!Empiri...........................................................................................................................................18!

Respondenter på företagen .......................................................................................................18!Stora Fabriken ..........................................................................................................................18!Systemleverantören ..................................................................................................................18!Medicinteknikföretaget ............................................................................................................19!Kravkonsulten ..........................................................................................................................19!Granskningskonsulten ..............................................................................................................19!Försvarets Radioanstalt ............................................................................................................19!

Presentation av respondenter på FRA ..................................................................................20!Organisation .........................................................................................................................20!Projektstyrning .....................................................................................................................20!Innan projektstart..................................................................................................................21!Krav ......................................................................................................................................22!Utveckling ............................................................................................................................22!

Analys och diskussion ..................................................................................................................24!Innan projektstart......................................................................................................................24!Krav ..........................................................................................................................................25!

Användbarhet .......................................................................................................................26!Slutsatser ......................................................................................................................................28!

Svar på frågeställningar............................................................................................................28!Hur kan metoden underlätta för FRA gällande initial behovs- och kravhantering? ............28!Vad kan en metod för initial behovs- och kravhantering bestå av? .....................................28!Hur ska metoden gestaltas för att motivera till användandet av denna? ..............................28!

Slutsatser rörande införande av användarcentrerad systemutveckling på FRA.......................28!Kravkartan – en metod för behovs- och kravhantering............................................................29!Reflektion .................................................................................................................................31!

Fortsatta studier ....................................................................................................................31!Litteraturlista ................................................................................................................................32!Bilaga 1: Koncept och dimensioner .............................................................................................35!Bilaga 2: Konceptuell bild för uppgiftsfördelning i utvecklingsprocessen..................................38!Bilaga 3: Kravkartan ....................................................................................................................39!

Källhänvisningar Kravkartan ...................................................................................................40!

Bakgrund

1

Bakgrund I detta kapitel presenteras bakgrunden till denna studie. Här presenteras även syftet med studien samt frågeställningarna vi utgått från. Här definieras även målgruppen för rapporten och studiens avgränsning.

Bakgrund till studien När ett system utvecklas till kund är det av största vikt att systemet motsvarar beställarens förväntningar och krav men också att beställarens förväntningar är realistiska och att såväl beställare som utvecklare har en klar bild av vilken effekt systemet kommer att ha på verksamheten. Det är därför viktigt att tidigt i projektet undersöka hur systemet ska användas, vad systemet ska användas till och hur detta hjälper organisationen att lösa sina uppgifter. Robertson & Robertson (2007, s. 1) menar att det är först då man har förståelse för de bakomliggande behoven man kan skapa användbara system som utgör nytta för verksamheten. Förståelsen för behoven måste finnas hos beställare såväl som leverantör för att utvecklingsprojektet ska nå framgång.

Fenomenet systemutveckling och dess förutsättningar är väl undersökt. En central framgångsfaktor är att ha god förståelse för användarna (Robertson & Robertson 2007, s. 1). Standish Group undersökte ett stort antal amerikanska mjukvaruprojekt vilket resulterade i tre faktorer som uppgavs vara de viktigaste framgångsfaktorerna i systemutvecklingsprojekt. Dessa var användarmedverkan i utvecklingen, stöd från beslutsfattare och ledning samt tydliga krav (Standish group, 1995).

Det finns många olika metoder för att utveckla mjukvara. Dessa förutsätter ofta att en mer eller mindre noggrann behovs - och kravinsamling är genomförd när utvecklingen påbörjas. Att identifiera de bakomliggande behoven tidigt i ett systemutvecklingsprojekt är viktigt för att systemet ska kunna utgöra det goda stöd för verksamheten som beställaren förväntar sig vid systemets införande. Denna initiala behovs- och kravhanteringsfas skapar grunden och förutsättningarna för det fortsatta arbetet mot detta mål. Det har visat sig i denna undersökning att såväl beställare som utvecklare behöver stöd i denna relativt komplexa behovs- och kravprocess.

Problemformulering På FRA har utvecklingsmetodiken gått från Rational Unified Process (RUP) till delvis agil metodik, främst baserad på metoden Scrum. För det initiala kravarbetet vid agil utveckling saknas fortfarande en dokumenterad metod på myndigheten.

Syfte och mål Syftet med denna studie är att undersöka vilka behov FRA har gällande en metod för initialt behovs- och kravhanteringsarbete. Målet är att ta fram en metod för detta vilken är anpassad till FRA:s arbetssätt och organisation.

Bakgrund

2

Frågeställning Vår huvudsakliga frågeställning är:

”Hur kan en metod för initial behovs- och kravhantering som motsvarar FRA:s behov i agil utveckling se ut?” ’

Denna frågeställning kan delas upp i följande delar:

• Hur kan en metod underlätta för FRA gällande behovs- och kravhantering? • Vad kan en metod för initial behovs- och kravhantering bestå av? • Hur ska metoden gestaltas för att motivera till användandet av denna?

Avgränsning Vårt fokus ligger främst i de första faserna av systemutvecklingsprocessen där de första linjerna för projektet ritas upp. Detta initiala arbete påverkar i hög grad resten av projektet. Vi anser därför att det är viktigt att tidigt ha rätt fokus i arbetet. Denna rapport berör följaktligen även hur man säkerställer användbarhet i de första faserna i projektet. Detta kräver också att organisationen är mogen för ett användarcentrerat arbetssätt, varför vi berör även detta i rapporten.

Metoden som har tagits fram i samband med denna studie är tänkt att stödja arbetet med att gå från idé till ett principiellt lösningsförslag i agila utvecklingsprojekt. Denna studie berör inte hur prioriteringen mellan olika projekt ska gå till men metoden ska stödja i arbetet med att skapa ett underlag för att fatta välgrundade beslut där prioritering mellan projekt ingår.

Denna studie fokuserar inte på metoder för teknikfokuserad kravinsamling. Vi har istället valt att fokusera på användbarhetsaspekter i behovs- och kravhanteringsarbetet eftersom vi fann det behovet mer angeläget. Metoden täcker dock in alla typer av krav och ger förutsättningar för att öka kunskaperna även inom andra områden.

Språkbruk I de fall där vi översätter engelska ord till svenska har vi valt att sätta det engelska ordet inom parentes. När vi inte stött på någon svensk motsvarighet till ordet har det engelska använts.

Målgrupp Rapporten riktar sig i första hand till FRA som en del av vårt arbete på myndigheten. Den är dock skriven för att alla som intresserar sig för krav och användbarhet i agil utveckling ska kunna dra nytta av den. Vi förutsätter att läsaren har en översiktlig kunskap om systemutveckling och vanliga modeller för hur denna kan gå till.

Metod

3

Metod I det här kapitlet tar vi upp något om vetenskaplig metodik, vetenskapliga förklaringsmodeller samt begreppen validitet och reliabilitet. Begreppet Grounded Theory introduceras. Vidare ges även en översiktlig bild av datainsamlingsmetoder vilka använts i studien, vårt tillvägagångssätt samt det praktiska genomförandet.

Metodteori Det finns huvudsakligen två typer av undersökningar, kvalitativa och kvantitativa. De kvantitativa metoderna syftar till att koda observationer till siffervärden som kan användas som underlag för att dra slutsatser. Dessa har fördelen att det går att relativt enkelt göra fler mätningar för att stärka en hypotes. Kvalitativa data låter sig svårligen kodas som värden på ett fruktbart sätt och är mer tidskrävande att sammanställa. Denna typ av data kräver en mer sammansatt förklaringsmodell (Preece, Rogers & Sharp 2007, s. 356).

Induktion och deduktion Induktion är att härleda slutsatser från empiriska erfarenheter. Enligt principen om Occams rakkniv, som säger att en enkel teori är mer sannolik än en mer komplicerad, kan man reducera teorierna till de mest sannolika. (Hansson 2003, s. 53).

Deduktion innebär att ställa upp en hypotes utifrån ett antal antaganden (axiom eller tidigare hypoteser). Dessa hypoteser behöver inte nödvändigtvis leda till en utsaga som är med verkligheten överensstämmande, men måste kunna verifieras eller falsifieras för att kunna sägas vara sann. (Hansson 2003, s. 49-52).

Grounded Theory Grounded Theory är främst en induktiv metod för att koda kvalitativa data där man inducerar teori ur en datamängd genom att identifiera olika koncept och relationerna mellan dessa (dimensioner). Grounded Theory förutsätts fortsätta till dess att ny data inte längre tillför nya begrepp och relationer i modellen, utan bara bekräftar tidigare kunskap. (Bell 2006, s. 27-30).

Reliabilitet och validitet Under en forskningsprocess är det viktigt att kritiskt granska den insamlade informationens giltighet och tillförlitlighet. Ett instrument eller ett tillvägagångssätt för att samla in information kan ge olika resultat vid olika tillfällen trots att omständigheterna är desamma, vilka kan bero på slumpmässiga mätfel i studien. För att uppnå god reliabilitet ska studien innehålla så få mätfel som möjligt och inte påverkas av omständigheterna runt omkring eller av vem mätningen utförs. I exempelvis en intervjusituation kan svaren bero på en rad olika orsaker så som intervjupersonens humör, tidigare händelser, vart intervjun äger rum eller av vem respondenten blir intervjuad (Bell 2006, s. 117).

Validitet handlar om informationens giltighet, alltså om det empiriska materialet mäter det forskaren tänkt att det ska mäta. Det betyder alltså att forskningsansatsen ska ge data som med säkerhet kan sägas spegla det förhållande som ska mätas (Bell 2006, s. 118).

Metod

4

Datainsamling I detta avsnitt ges en översiktlig bild av metoder för att samla in data vilka vi använt under studien.

Intervjuer

Intervjuer kan utföras mer eller mindre strukturerat där den mest strukturerade formen kan liknas vid en enkät med ett antal förutbestämda svarsalternativ. Den mest ostrukturerade intervjun utgår från ett antal förberedda frågor men bygger på att föra ett samtal kring ett visst tema (Bell 2006, s. 160).

Observationer

Observationer kan ge data som annars vore omöjliga att ta fram och kan därför fungera som ett bra komplement till intervjuer. Forskaren måste vara medveten om att observatörens egen uppfattning påverkar tolkningen. Observationer sker antingen ostrukturerat eller strukturerande och deltagande eller icke-deltagande (Bell 2006, s. 187-188).

Ostrukturerade observationer är lämpliga när forskaren är klar över syftet med observationerna, och kan användas för att generera hypoteser exempelvis i Grounded Theory. Den deltagande observationen innebär att forskarna deltar i en social kontext och försöker förstå vad som händer genom att tolka sina intryck och genom att ställa frågor till gruppen. (Bell 2006, s. 188-189).

Designaktiviteter

För att skapa och utvärdera ett designförslag finns det en rad olika metoder. Dessa metoder har till syfte att på olika sätt stödja en process, och ofta att få människor att tänka i nya banor (Häggberg 2002, s. 2-3).

Prototyper

En prototyp är en representation av en tänkt design vilken kan användas som underlag för en första användbarhetsutvärdering. Det kan också vara ett användbart redskap för att diskutera och testa idéer med användare och projektmedlemmar. Genom att bygga en prototyp tvingas designern reflektera över sina idéer och hur produkten ska realiseras. (Preece, Rogers & Sharp 2007, s 11).

Inom interaktionsdesign talar man om två typer av prototyper: Low-fidelity (Lo-Fi) och High-fidelity (Hi-Fi). Lo-Fi-prototyper är mycket enkla, billiga och ska gå snabbt att skapa. De kan vara gjorda av pappkartong eller skissade på papper och används i ett tidigt skede i utvecklingsprocessen. Hi-Fi prototyper är mycket välgjorda och ska ge en trovärdig representation av produktens utformning (Preece, Rogers & Sharp 2007, s. 531).

Prototyper kan utvärderas på en rad olika sätt och olika syften. Användbarhetsdesignern kan låta användare prova lösningarna genom att utföra en viss uppgift i en workshop eller att föra in dem i verksamheten och observera hur de tas emot (Preece, Rogers & Sharp 2007, s. 530-531).

Metod

5

Tillvägagångssätt I detta avsnitt redogör vi för hur vi valt att gå tillväga i vårt datainsamlande och analysen av datat. Vi diskuterar även kring studiens reliabilitet och validitet.

Val av metodteori och förklaringsmodell

Vi har tillämpat Grounded Theory för att bygga upp en förståelse för nuvarande arbetssätt inom organisationen och försöka identifiera styrkor, förbättringsområden och behov. I analysen av våra data har detta delats i koncept (återkommande begrepp) som i sin tur har grupperats i dimensioner. En förteckning av dessa koncept hittas i Bilaga 1, och en övergripande konceptuell bild presenteras i Bilaga 2.

För att öka förståelsen för det agila arbetssättet har vi valt att lägga upp det praktiska arbetet utifrån utvecklingsmetoden Scrum. Metoden som helhet presenteras närmare i teoriavsnittet. Viktiga aspekter vid valet av Scrum är att metoden används i organisationen och att den har tydliga inslag av kontinuerlig feedback, vilket gynnar såväl designprocess som studiens reliabilitet. Dessutom ville vi att vårt resultat skulle vara kompatibelt med det agila arbetssättet. Scrum har i vårt arbete fungerat som vår projektmetod, för att stödja vårt praktiska arbete.

Vi har anpassat Scrum efter vårt arbete och vårt arbetssätt skulle kunna kallas ”Scrum-inspirerat”. Vi har dragit nytta av vissa aspekter som time-boxing, stories och scrumtavla. Arbetet har utgått från en backlog med uppgifter, vilka vi prioriterade själva. Vi har även haft sprintredovisningar på myndigheten, vilka utnyttjades för feedback på det arbete vi gjort under sprinten. Vi har inte haft någon uttalad Scrummaster eller produktägare, men vår handledare tog rollen som beställare. Scrum visade sig passa bäst för datainsamlingsarbetet. Under rapportskrivandet beslöt vi oss för att inte ägna oss åt Scrum lika uttalat men använde time-boxing och prioritering av uppgifter, även om detta till stor del bara skedde verbalt.

För att skapa vår metod för initial behovs- och kravhantering valde vi att arbeta kreativt enligt en strukturerad designprocess. Eftersom vår förståelse för behovet av en sådan metod successivt ökade ville vi utforska flera olika lösningar under arbetets gång. Dessa utvärderades för att få nödvändig feedback på lösningsförslagen.

På grund av begränsat dataunderlag används en induktiv metod och vårt data behandlades som kvalitativt. För att bygga en förklaringsmodell har vi använt Grounded Theory, för att skapa en nulägesbeskrivning där behov och problemområden inom behovs- och kravhanteringsarbetet kan identifieras. Dessa kan adresseras med en strukturerad designprocess. Analysen har skett främst utifrån ett användarcentrerat perspektiv, då vi anser att detta är en förutsättning för ett framgångsrikt systemutvecklingsarbete.

Valet av Grounded Theory grundar sig i att vi ville skapa oss en egen uppfattning om FRA:s möjliga problemområden eller behov. Vi kunde därför inte på förhand ställa upp en hypotes om hur nuläget såg ut. Vi ville inte begränsa oss till någon enskild förklaringsmodell utan ville själva skapa oss en bild av nuläget.

Vi bedömde att en kvantitativ metod skulle vara av begränsat värde för designprocessen då tillgång till kvantifierbar data var begränsad. Det hade varit svårt att kvantifiera de data vi samlade in för att få de resultat vi förväntade oss för skapandet av vår metod. Antalet respondenter var också för få för att en kvantitativ metod skulle ge tillförlitliga svar.

Studiens reliabilitet och validitet

För att stärka reliabiliteten har många intervjuer utförts (tjugo stycken). Frågorna var utformade på samma sätt för att utgångspunkten i intervjuerna ska vara densamma. Där intervjupersonen svarat otydligt eller svävande har frågorna omformulerats i samtalen för att få ett mer ingående svar.

Metod

6

Rummet där intervjuerna på FRA skett har varit detsamma utom i två fall där vi fick anpassa oss till intervjupersonerna. Alla intervjuer, även de på företagen, skedde i någon form av mötesrum, aldrig på respondentens eget kontor. Alla har intervjuats enskilt och har därför inte kunnat påverka varandra under intervjutillfällena. Under intervjuerna har bakgrund och utbildning efterfrågats och hänsyn till detta har också tagits vid analysen av vårt data.

Då intervjuerna varit ostrukturerade har det funnit möjligheter att validera påstående från tidigare intervjuer tillsammans med intervjupersonen. Dessa har sedan kunnat provas ytterligare med efterkommande intervjupersoner vilket stärker reliabiliteten i våra resultat. Vi har som examensarbetare och utomstående haft möjlighet att ställa naiva frågor vilket har varit till hjälp vid definition av olika begrepp och sakförhållanden.

På grund av den sekretess som råder på myndigheten har det funnits vissa svårigheter i att finna representativa personer som kunnat ge den information som eftersökts. Detta gör det svårt att veta huruvida de personer som intervjuats har gett en representativ bild av hur det ser ut på berörda delar av myndigheten. Intervjuerna har därför kompletterats med dagliga observationer och studier av bland annat skriftlig projektdokumentation. De data som samlats in har i vissa fall kontrollerats med vår handledare eller chef för att verifiera eller falsifiera vissa påståenden. I andra fall har påståenden kontrollerats under lunch- och fikarumsdiskussioner på i stort sett daglig basis.

Vi har haft ett visst bortfall bland våra respondenter. Detta kan bero på att de som inte hade tid att ställa upp hade mycket att göra. Detta kan betyda att de har haft stort ansvar och därmed god insikt i organisationen och dess arbetssätt. För att kompensera bortfallet av data från dessa intervjuer har vi kompenserat detta genom att intervjua desto fler personer i deras närhet. Vi anser därför inte att bortfallet påverkat resultatens reliabilitet nämnvärt.

Det finns en risk att vårt insamlade data inte ger en fullständig bild av myndighetens arbetssätt. Empirin är dock inte det enda som ligger till grund för våra slutsatser, dessa grundas även i litteratur och jämförelser med de företag vi besökt. Vi gör bedömningen att det empiriska underlaget är mer än tillräckligt för att använda vid syntes av vår metod.

Studien uppnår hög validitet genom att vi har tillbringat fyra månader på myndigheten, vilket kan ses som relativt lång tid, och aktivt följt upp våra resultat under arbetets gång. Våra observationer och slutsatser har dock löpandet kontrollerats med andra på myndigheten. De fenomen vi observerat återkommer och beskrivs i litteraturen och vi har även stött på dem under våra studiebesök.

Val av datainsamling

Vi valde tidigt att genomföra enskilda intervjuer skilt från respondentens arbetssituation då vi ansåg att respondenterna skulle känna sig obekväma i att prata fritt i sin vardagliga miljö. Det var framför allt viktigt att respondenterna själva hade kontroll över hur mycket information de delgav oss, vilket vi bedömde skulle vara lättast i en neutral situation utanför arbetsplatsen utan några kollegor närvarande. Detta gällde både myndighetspersonalen och respondenterna på företagen. Vi valde ostrukturerade intervjuer för att kunna föra ett fritt samtal kring nuläget för att försöka ringa in problemområden och tillsammans fundera på vilka metoder personerna använde idag. Vi ville även diskutera kring roller och hur dessa förhöll sig till varandra, vilket skulle ställa högre krav på frågorna i en strukturerad intervju.

Observationer utfördes på ett deltagande och ostrukturerat sätt genom att vi deltog i fikaraster, lunchdiskussioner och gemensamma aktiviteter på avdelningen. Vi har i stort sett dagligen befunnit oss på myndigheten vilket har gjort att vi på ett avslappnat sätt har kunnat prata med medarbetarna. Vi har också satt upp många lappar där vi bett om hjälp med olika saker och även bloggat internt, för att alla på avdelningen ska ha haft möjlighet att lära känna oss. Mycket fokus har lagts på att skapa ett förtroende mellan oss och medarbetarna på avdelningen.

Metod

7

För att utvärdera de prototyper vi producerat hölls sprintdemos och en workshop. Prototyper delades också ut till olika personer i utvecklingsverksamheten som fick utvärdera och prova dem. Tyvärr fanns det inte möjlighet att testa prototyper i ett skarpt projekt, varför vi var tvungna att simulera en projektstart under den workshop som genomfördes.

Praktiskt genomförande I detta avsnitt beskrivs genomförandet av studien, hur vi valt ut relevant teori och respondenter. Här ges även en beskrivning av vår förförståelse.

Beskrivning av vår förförståelse

Vi har studerat inriktningen Människa-datorinteraktion vid Kungliga Tekniska Högskolan i Stockholm. Vi har inte läst några kurser i kravhantering, men har viss erfarenhet av systemutveckling. Linus Ericsson har tidigare arbetat med viss kravställning av system. Eftersom vi båda har ett intresse för användarcentrerad systemutveckling har detta synsätt präglat studien.

Urval av teori

Vi har valt att fördjupa oss i den teori som kan förväntas ligga till grund för centrala begrepp i slutsatserna eller metoden. Vi har också fördjupat oss i teori för fenomen vi stött i vår data. I teorin har vi valt att titta närmare på hur organisationer ser på användbarhet och hur ett användarcentrerat synsätt kan införas i en organisation.

Vi har haft stort nytta av den litteratursökning vi gjort, men vi har valt att sålla bland de många utvecklingsmetoder vi bara sett förekomma i litteraturen då det är av begränsat värde för rapporten. Vi har redogjort för de utvecklingsmetoder vi stött på i empirin. Vi har noterat att det inte alls finns lika mycket skrivet om kravinsamlingsmetoder som olika metoder för den mer konkreta systemutvecklingen.

Urval av respondenter

På FRA intervjuades totalt 20 personer och vi genomförde sex intervjuer på totalt fem företag. Vi har försökt få representation både från beställare och leverantör av systemen. Därför har vi inom myndigheten valt att titta på ett begränsat urval av systemen och intervjuat så många olika roller och intressenter som möjligt i vart och ett av systemutvecklingsprojekten. Respondenterna var i första hand utvecklare, projektledare, användarrepresentanter och beställare. Dessa valdes i samråd med vår handledare för examensarbetet och verksamhetschefer.

Respondenterna på företagen hittades genom personliga kontakter som kunde tipsa oss vidare. Vi strävade efter att välja företag som antingen i något avseende liknade FRA eller sannolikt hade god kompetens inom kravställning och användbarhet. Då vi tittade på kravprocessen ur ett övergripande perspektiv var företagens verksamhetsområde av underordnad betydelse för studien. Samtliga företag levererade mjukvara i någon form med höga krav på kvalitet.

Intervjuerna

Som tidigare nämnts valde vi ostrukturerade intervjuer för att skapa en fri dialog och ett öppenhjärtligt samtal om ämnet. Vi var noga med att uppge vår säkerhetsklassning innan intervjun började för att intervjupersonen inte skulle behöva tveka om vad man kunde prata om och inte. Då vi var två som intervjuade ställde en person de flesta frågorna och den andra antecknade.

Intervjuerna bokades in via kortfattad mailkorrespondens med respondenten. Personerna fick frågorna på förhand, för att kunna förbereda sig och ta med eventuellt relevant material. Inga

Metod

8

bild- eller ljudupptagningar gjordes. Alla intervjuer med myndighetspersonal genomfördes i samma rum utom två, som på grund av respondenterna fick äga rum på annan plats, dock fortfarande i mötesrum. Fyra av intervjuerna med respondenterna på företagen skedde på respektive företag, en hölls på ett café i närheten av arbetsplatsen och en intervju utfördes som telefonintervju.

Observationerna

Vi förde kontinuerligt dagbok i slutet på varje arbetsdag för att samfatta de observationer som gjorts under dagen. Vi deltog även på en förstudiepresentation, ett dagligt Scrummöte och andra interna föreläsningar. Vi satt nära utvecklare som vi hade nästan daglig kontakt med.

Dataanalysen

Dataanalysen genomfördes manuellt. Anteckningarna renskrevs i ordbehandlare och varje mening skrevs som nytt stycke. De renskrivna anteckningarna skrevs ut i storlek 18, färgmärktes beroende på intervjuperson och klipptes isär. Det resulterade i hundratals lappar, vilka vi sorterade in i ca 90 koncept. Dessa tejpades återigen upp på papper och koncepten var tydligt antecknade och sattes in i en pärm. En innehållsförteckning gjordes. En genomgång av koncepten gjordes och ett fåtal centrala dimensioner identifierades.

På en vägg i arbetsrummet fästes fjorton blädderblockspapper i storlek A3, på vilka vi skrev ner de centrala dimensionerna i lämplig disposition, omgivna av de relaterade koncepten. Data tillhörande de olika koncepten dikterades av en av oss medan den andra antecknade datat i form av en tankekarta, där linjer kunde dras till relaterade begrepp i varje utsaga. Vissa utsagor insåg vi här inte var meningsfulla att försöka få med i förklaringsmodellen. Det framgick snart vilka begrepp och koncept och relationer mellan koncepten som var vanligast, det var helt enkelt bara att räkna antalet streck.

En genomgång av data också sorterat på koncept, listor på roller, aktivteter och centrala begrepp ,som exempelvis ”förstudie”, markerades och skrevs ut som stöd för visualiseringen och klistrades upp på tankekartan. Inte alla begrepp kom med, läsningen och försöken att förklara datat med hjälp av en tankekarta sållade alltså bort perifera begrepp (vilka vi troligtvis inte haft tillräcklig grund för).

Vi turades sedan om att ”läsa” tankekartan och skriva ned de slutsatser vi kunde dra utifrån kartan, exempelvis kommer meningen ”En allmän uppfattning hos utvecklarna att Scrum är bra på att fånga feedback från beställarsidan vilket man får under sina sprintdemos” sig av att flera intervjupersoner nämnt ”Scrum” och ”feedback från beställarsidan” och att begreppet ”sprintdemos” varit näraliggande ”feedback från beställarsidan”. Givetvis kunde vi av de erfarenheter vi dragit ut under intervjuerna veta att det inte var någon som hade sagt något direkt negativt om feedback från beställarsidan och Scrum, vilket förstås skulle ha gjort att vi förkastat den förklaringen. Diskussionen om slutsatsernas rimlighet diskuterades löpande under såväl diktering som bearbetning av de nedskrivna resultaten.

Värt att notera är att vi inte kunde uppnå teoretisk mättnad i analysen av intervjuerna från de olika företagen. Dessa data särredovisades därför, även om vi redogör för vissa gemensamma dimensioner och ibland relaterar det till data från FRA.

Vi har främst utgått från intervjumaterialet i analysen. Processbeskrivningar och andra dokument har inte genomgått samma analys som ovan, men jämfördes med förklaringsmodellen. Ur denna jämförelse framkom flera behov.

Designprocessen

Vi samlade redan tidigt på oss olika lösningsförslag, dels sådana vi själva kommit på, dels idéer från intervjurespondenter och andra anställda. Dessa nedtecknades och vi diskuterade dem med varandra såväl som med handledare och andra på FRA. Vi utvärderade idéerna genom att på ett

Metod

9

strukturerat sätt hitta styrkor och svagheter, bland annat med krysschema (Häggberg 2002 s 16). Ur lösningsförslagen kunde vi även ofta identifiera behov. Våra förslag gestaltades även med hjälp av prototyper av Lo-Fi-karaktär.

Utvärderingar skedde genom att vi kontinuerligt visade upp våra artefakter för besökare på vårt rum och andra vi tyckte borde se dem. Vi gav även bort prototyper till utvecklare att titta på och reflektera kring. Under vår workshop fick en grupp projektledare ett enkelt case rörande initial kravinsamling. Syftet med workshopen var att testa metoden för initial kravinsamling i användning.

Teoretisk referensram

10

Teoretisk referensram Här behandlar vi den teori som ligger till grund för vår undersökning. Vi tar upp systemutvecklingsmetodiker, projektstyrning och kravhantering. Vi tar även upp användarcentrerad systemutveckling och hur detta arbetssätt kan föras in i organisationer.

Systemutveckling Hökenhammar (2001, s. 273) definierar systemutveckling som en process för att skapa ett system vilken sträcker sig från ide till färdig produkt. Tonnquist delar upp systemutvecklingsprocessen i en förstudiefas, planeringsfas, design- och konstruktionsfas och en avslutande fas (Tonnquist 2008, s. 192).

Ett vanligt sätt att inleda systemutvecklingsprojekt är att inleda arbetet med någon form av kravprocess, där användare tillfrågas efter vilken funktionalitet som önskas eller att de på annat sätt formulerar behoven det producerade systemet ska uppfylla (Davis, Yourdon & Zweig 2000 s. 2-3). Tonnquist (2008, s. 192) förespråkar att kraven samlas in under förstudiefasen.

Det finns en rad olika metoder för systemutveckling vilka har som primärt syfte att föreskriva ordningen av de olika stadierna som ingår i processen. (Gulliksen & Göransson, 2002 s. 137). Den, enligt Gulliksen & Göransson (2002, s 139), vanligaste modellen för systemutveckling är Vattenfallsmodellen, som kom till 1970, och innebär att faserna behandlas sekventiellt. Innan en fas i systemutvecklingsprocessen påbörjas måste den tidigare ha avslutats. Kritik har dock framförts mot denna metod då arbetet lätt kan fastna i en “återvändsgränd” om projektgruppen tänkt fel i något av de tidigare stegen. Eftersom problemställningen systemet ska lösa ofta ändras eller kompletteras under projektets gång, har det utvecklats iterativa metoder för att bedriva systemutveckling. I de iterativa metoderna accepterar man att den initiala kravbilden förändras under projektet och löser detta genom att gör om och kompletterar dellösningar i produkten (Gulliksen & Göransson 2002, s 145).

Projektstyrning För att göra projektarbete förutsägbart och minimera riskerna för den investering ett projekt innebär har man utvecklat projektstyrningsmetoder. En projektstyrningsmetod består huvudsakligen av processer, roller och olika mallar och dokument. I ett projekt strävar man efter en styrmodell som ger tillräckligt med kontroll, men inte verkar begränsande (Tonnquist 2008, s. 332). Projektstyrningen verkar övergripande i ett utvecklingsprojekt och definierar projektets ramar. På en mer detaljerad och resultatinriktad nivå verkar någon utvecklingsmetodik (Tonnquist 2008, s. 337). Ett exempel på en utvecklingsmetodik är Scrum vilken beskrivs närmare nedan. För att finansiärer ska kunna styra projektet på en övergripande nivå har projektstyrningsmodellerna ett antal beslutspunkter. Detta är beslut som tas vid kritiska faser av projektet och som syftar till att projektets styrgrupp ska kunna ta beslut om projektet ska fortsätta eller inte (Tonnquist 2008, s. 13).

Tonnquist (2008, s. 334) nämner metoden PROPS, utvecklad av telekombolaget Ericsson under namnet ”Projektet för Projektstyrning”, som en vanlig projektstyrningsmetod för organisationer med flera parallella projekt. Standardversionen av PROPS föreskriver sex beslutspunkter. Exempel på tidiga beslutspunkter är beslut att inleda projektet, att inleda projektplanering samt att etablera och genomföra projektet.

Teoretisk referensram

11

Kvalitet i projekt kan upprätthållas med så kallade kvalitetsgrindar. Dessa kan finnas i projektstyrningsmodellen. Utifrån dessa ska den yttersta ledningen bedöma projektet utifrån den föregående fasen, och avgöra om projektet lever upp till förväntad kvalitet och ta beslut om projektet bör fortsätta (Hallberg 2009, s. 69). Dessa kan jämföras med projektets beslutspunkter. Hallberg (2009, s. 14) menar att ett potentiellt problem med kvalitetsgrindar är att de släpper igenom projekt som inte håller tillräckligt hög kvalitet. Vidare menar Hallberg (2009, s. 69) att detta ofta beror på att kriterierna för besluten är oklara för dem vars arbete ska bedömas.

Effektstyrning

Ottersten & Balic (2010, s. 21-22) anför dagens projektstyrningsmetoder som en anledning till att projekt inte strävar mot att uppnå de önskade effekterna med produkten i användning utan att projektgruppen istället strävar mot att producera kod, klara leveranser och att hålla budget. Vidare menar de att för att styra projektet mot förväntade effekter behövs ett strukturerat arbetssätt som bygger på att projektets styrgrupp har som huvudfokus att se till att projektets förväntade effekter infrias, snarare än att hålla tid och budget. Detta strukturerade arbetssätt kan införas i den befintliga projektstyrningsmetoden och kompletteras med beslutspunkter, så kallade effektbeslut, som syftar till uppfyllandet av effektmålen. Ottersten & Balic (2010, s. 21-22) förespråkar därför effektstyrning som en lämplig process för att styra projekt mot förväntade effekter.

Effektstyrningsprocessen är uppdelad i tre faser som i sin tur innehåller totalt tio effektbeslut. Figur 1 visar hur de tio effektbesluten är sammankopplade med de tre faserna i processen. I första fasen ägnar projektgruppen sig åt insamling av idéer och behov och vill fastställa beställarens förväntningar på den nytta som IT-systemet ska skapa i verksamheten. Denna kartläggning av nyttan kan sedan användas i upphandling. Andra fasen syftar till att styra produktens utformning så att de förväntade effekterna uppnås och den tredje handlar om att testa den färdiga produkten i användning för att värdera och godkänna den (Ottersten & Balic 2010, s. 71). Figur 2 beskriver de fyra första effektbesluten vilka kan sägas höra till förstudiefasen i traditionell systemutveckling.

Figur 1. De tio effektbesluten och hur dessa förhåller sig till de tre faserna i processen (Ottersten & Balic 2010, s. 72).

Fastställa förväntningar på nytta

Styra produktens utformning Värdera och godkänna produkten

1 Förbättrings- område definierat

2 Produktidén godkänd

3 Krav på kvalitet och införande

4 Princip-lösning godkänd

5 Detaljdesign godkänd

6 Produkt-utformning godkänd

7 Användnings-kvalitet godkänd

8 Teknisk kvalitet godkänd

9 Produkten godkänd

Upprepas, avser delar av produkten

10 Införande godkänt

Teoretisk referensram

12

Figur 2. De fyra första effektbesluten (Ottersten & Balic 2010, s. 75-80)

Agil utvecklingsmetodik Grundtanken bakom agil utveckling är att utvecklarna snabbt ska kunna bygga ett utkast till ett system som sedan kan testas. Arbetet sker i korta cykler, så kallade iterationer, och bryter ned utvecklandet av en produkt i mindre delar vilka färdigställs en i taget. Detta gör att utvecklingen enkelt kan ställas om vid förändrade behov (Agile Sweden, 2004).

Det huvudsakliga syftet med agil utvecklingsmetodik är att göra kunden nöjd genom att kontinuerligt leverera fungerande mjukvara under hela processen. Detta gör att kraven hela tiden kan ändras då projektgruppen ofta utvärderar leveranserna tillsammans med kunden. Detta ställer krav på kundens engagemang då man kan ha kontakt så ofta som på daglig basis (Agile Manifesto, 2001).

Den agila utvecklingsmetodiken sammanfattas i det Agila manifestet som lyder:

”Vi finner bättre sätt att utveckla programvara genom att utveckla själva och hjälpa andra att utveckla. Genom detta arbete har vi kommit att värdesätta:

• Individer och interaktioner framför processer och verktyg. • Fungerande programvara framför omfattande dokumentation. • Kundsamarbete framför kontraktsförhandling. • Anpassning till förändring framför att följa en plan.” (Agile Manifesto, 2001).

1. Förbättringsområde definierat

Här har någon i ledningsgruppen bedömt att IT kan användas som medel för att tillfredsställa ett behov i verksamheten. Här har en kostnadsbedömning gjorts och det finns en grov beskrivning av vilken nytta IT-satsningen kommer att utgöra för målgruppen.

2. Produktidén godkänd

I detta steg är man övertygad om att IT är en lönsam satsning för verksamheten för att uppnå en önskvärd förändring. Här har man större kunskap om målgruppen och vilken nytta som förväntas uppstå vid systemets införande.

3. Krav på kvalitet och införande

Här har man en beskrivning av de kvalitetskrav som finns på produkten, teknisk kvalitet såväl som användningskvalitet. Man bör därför undersöka alternativa produktutformningar och välja en lösning.

4. Principlösning godkänd

Detta beslut handlar om vad den slutliga produkten ska innehålla. I detta steg ska därför en grov interaktionsdesign där de viktigaste flödena finnas beskrivna. Samtliga funktionella krav också finnas beskrivna.

Övriga effektbeslut innebär att godkänna detaljdesign, produktutformning, användningskvalitet, teknisk kvalitet, produkten, införande.

Teoretisk referensram

13

Scrum

Scrum är en agil projektmetodik för mjukvaruutveckling som bygger på att projektarbetet delas upp i iterationer, så kallade sprintar. Varje sprint är en till fyra veckor lång och föregås av ett sprintplaneringsmöte. Projektteamet består av fem till nio personer. Inom teamet är professioner oviktiga och alla i teamet arbetar med det som bäst bidrar till att uppnå de uppsatta målen för sprinten (Mountain Goat Software, 2011).

Scrummastern är teamets coach och har till uppgift att se till att teamet ständigt presterar sitt bästa för att uppnå de uppsatta målen. Produktägaren (Product Owner) har till uppgift att se till att teamet arbetar i rätt riktning. Produktägaren tar även emot, hanterar och prioriterar önskemål om tillägg och ändringar rörande produkten (Mountain Goat Software, 2011).

Varje dag har teamet ett femton minuter långt möte, så kallat dagligt scrummöte (daily scrum), där projektgruppen, produktägaren och scrummastern deltar (Mountain Goat Software, 2011). Varje deltagare ska svara på tre frågor:

• Vad gjorde du igår? • Vad ska du göra idag? • Vilka eventuella hinder finns?

Genom att svara på dessa frågor kan projektgruppen tillsammans förstå problem och hjälpa varandra. (Nodder & Nielsen 2008, s. 13)

Scrum representerar funktionella krav i form av stories. Dessa beräknas ofta ta högst ett par dagar att implementera och har ofta formen av papperslappar som sätts upp på så kallade scrumtavlor så att alla i projektteamet kan se hur arbetet fortlöper. Alla stories prioriteras och i normalfallet arbetar teamet på den story som har högst prioritet. Alla stories samlas i en product backlog vilken projektarbetet utgår från (Kniberg, 2007, s. 18-19).

Produktägaren, som har ansvar för backlogen, prioriterar mellan stories för att teamet hela tiden ska arbeta med de viktigaste uppgifterna. Inför varje sprint skapar produktägaren sprint backlog vilken innehåller de stories som är högst prioriterade. Dessa ska ha implementeras för att målet med sprinten ska vara uppnått (Kniberg, 2007, s. 18-19). För att veta när en story är färdigställd, behöver projektgruppen ha en ”definition of done”, vilken är en överenskommelse mellan produktägare och teamet om när en story anses vara slutförd (Kniberg, 2007, s. 27). Varje sprint tidsbegränsas (time boxing) till iterationer som inte pågår längre än en månad. Under sprintarna är kraven frysta (Mountain Goat Software, 2011).

En vanlig metod är att under en sprint samla in alla krav som är nödvändiga för nästkommande sprint och ordningsställa dem inför sprintplaneringsmötet. Syftet är att ha kraven tillgängliga precis då de behövs, men inte förr. Eventuella brister som upptäcks kan rättas till längre fram (Kniberg, 2007, s. 18-19).

I slutet av varje sprint demonstrerar teamet den funktionalitet som implementerats för att få feedback från produktägaren och de intressenter som bjudits in till demonstrationen. Ytterligare ett möte hålls där teamet, scrummastern och produktägaren utvärderar föregående sprint för att hitta möjligheter till förbättringar under nästkommande sprint. Alla tillkomna eller förändrade krav som uppkommit under dessa två möten läggs i product backlog. Eftersom kraven i product backlog hela tiden kan ändras och nya krav kan tillkomma blir den aldrig färdigställd (Mountain Goat Software, 2011).

Rational Unified Process Rational Unified Process (RUP) är utvecklad av företaget Rational, vilket köptes upp av IBM 2002 (eWeek, 2002). RUP är enligt Gulliksen & Göransson (2002, s.187) den mest etablerade och vedertagna systemutvecklingsprocessen och har sitt ursprung i utvecklingsmetoden Objective som kom redan på 1980-talet. Rational Software (2008, s. 2) menar att en av de

Teoretisk referensram

14

centrala förtjänsterna med RUP är metoden är iterativ och utvecklar systemet i små delar. Gulliksen & Göransson (2002, s 187-188) menar dock att den i RUP föreskrivna metoden att dela upp uppgifterna kan ses som inkrementell, vilket skulle göra att den fortfarande särskiljer sig från de agila metoderna och användarcentrerad systemutveckling.

RUP delar in utvecklingen i fyra faser: inception, elaboration, construction och transition, alla med syfte att alltmer begränsa och förfina omfattningen av det system som ska byggas (Rational Software, 2008, s. 3). De inledande faserna fokuserar mycket på systemets arkitektur, och projektgruppen uppmanas i elaborationfasen att göra en prototyp på hög nivå för att tillse att arkitekturen är tillräcklig för det system man ska utveckla (Rational Software, 2008, s. 6). Inom alla utvecklingsfaser finns en stor mängd olika aktiviteter och tanken är att projektgruppen väljer ut aktiviteter specifikt för varje projekt. Företag föreslås ofta ta hjälp av RUP-konsulter för att få hjälp att välja vilka aktiviteter som passar företagets projekt väl (Rational Software, 2008, s. 3). RUP kan därmed sägas vara ett projektramverk eller en process snarare än en specifik metod (Rational Software, 2008, s. 1).

En av RUPs uttalade målsättningar är att överbrygga gapet mellan verksamhetsarkitekter och utvecklare, genom att använda symbolspråket UML som ett gemensamt språk. UML är ett antal överenskomna standarder för att beskriva hur mjukvara är uppbyggd (Rational Software, 2008, s. 1). Det finns diagram för användningsfall, hur datastrukturer ser ut och hur programmet modellerar objekt. Användningsfall är en enkel metod att beskriva vilken funktionalitet ett system ska ha, genom att ge bra exempel på sätt systemet ska användas och de förväntade resultaten av detta (Strand, 2001, s. 17).

RUP definierar roller på ett tydligt sätt, där varje roll tar ansvar för någon del av utvecklingsprocessen. Exempel på roller är testledare, arkitekt, prestandatestare, projektledare. En person kan ha flera olika roller. Rollernas belastning förändras över tid i projektet, och det finns diagram som schematiskt visar hur mycket rollerna förväntas arbeta under olika delar av projektet (Rational Software, 2008, s. 3).

Krav och kravhantering Davis, Yourdon & Zweig (2000, s. 2) beskriver krav som externt observerbara egenskaper, funktioner eller attribut vilka användare, beställare och andra intressenter vill att systemet ska bestå av eller karaktäriseras av. Robertson & Robertson (2007, s. 1) beskriver krav som de syften systemet ska uppfylla för användarna och vilka begränsningar som finns på systemet. I systemutveckling brukar man tala om två typer av krav; funktionella och icke-funktionella. Enligt Robertson & Robertson (2007, s. 9-10) beskrivs de funktionella kraven som produktens funktionalitet och de icke-funktionella kraven som de restriktioner som finns på produkten.

Tidigt i utvecklingsprocessen undersöks intressenternas behov. Behoven översätts sedan till funktionella och icke-funktionella krav på systemet. Vilka krav som prioriteras menar Davis, Yourdon & Zweig (2000, s. 2) beror på flera faktorer . Dessa kan bland annat vara att det för projektet finns begränsade resurser eller att projektet har höga krav på riskminimering. Davis, Yourdon & Zweig (2000, s. 2) förespråkar en strukturerad kravprioritering där nödvändiga intressenter deltar. Kraven sammanfattas ofta i en kravspecifikation på lämplig detaljnivå. (Preece, Rogers & Sharp 2007, s 476) menar också att det är viktigt att kraven ska vara tydliga och formulerade på ett sådant sätt att man entydigt kan avgöra när systemet uppfyller ett krav.

Kravarbetet måste anpassas till projektets storlek och projektmetod. Robertson & Robertson (2007, s. 7) föreslår tre olika storlekskategorier av utvecklingsprojekt, kanin-, häst och elefantprojekt där skillnaden mellan dessa är projektets storlek och behovet av noggrant kravarbete. Projekten går från att vara mycket agila (kanin) till mer vattenfallslika med en omfattande kravprocess i början av projektet och tydliga krav på dokumentation (elefant). Robertson & Robertson (2007, s. 9) menar att oavsett arbetssätt och projektets omfattning behöver man alltid skapa sig en förståelse för kraven och de bakomliggande behoven. Vidare

Teoretisk referensram

15

menar de att kostnaden av en god initial kravinsamling är oväsentlig jämfört med kostnaden av en bristfällig kravinsamling.

En allt för detaljerad kravbild i början av projektet motsäger ett iterativt arbetssätt då detta bygger på att man inte i förväg känner problemet och hur en lösning borde se ut (Gulliksen & Göransson 2002, s 108). Robertson & Robertson (2007, s. 20) menar att en kravprocess fortsätter under hela systemets livscykel. När en produkt, eller en del av en produkt, brukas av användarna upptäcks nya användningsområden och behov vilket ofta ger upphov till nya krav. Genom att leverera något till användarna i ett tidigt skede med minimal med funktionalitet kan man låta produkten utvecklas tillsammans med användarnas behov.

Robertson & Robertson (2007, s. 17) menar att man för att hitta rätt krav behöver systematik i sitt kravarbete. För att stödja kravinsamlingen har Robertson & Robertson utvecklat Volere, vilket är riktlinjer för att säkerställa att alla krav tas om hand i kravprocessen och under senare utvecklingsaktiviteter. Volere innehåller 27 kategorier vilka bland annat motsvarar olika typer av krav (se figur 3). Då dessa 27 kategorier inte nödvändigtvis behöver ses över i början av projektet fungerar Volere även som en checklista. (Robertson & Robertson, 2007 s. 11-13).

Figur 3. Lista över Voleres kategorier (fritt översatt) (Robertson & Robertson, 2007 s 13-14 )

Projektets drivkrafter 1. Syftet med projektet 2. Beställare, kund och andra intressenter 3. Användare av produkten Produktens begränsningar 4. Krav som begränsningar produkten och utvecklingsprojektet 5. Begreppsordlista 6. Relevanta kringförhållanden och antaganden Funktionella krav 7. Arbetets omfattning 8. Produktens omfattning 9. Funktionella krav och krav på data som behandlas Icke-funktionella krav

10. Utseendemässiga krav 11. Krav på användbarhet 12. Krav på prestanda 13. Bruksmiljöns krav på systemet 14. Förvaltning- och supportrelaterade krav på produkten 15. Säkerhetsmässiga krav 16. Kulturella och politiska krav 17. Juridiska krav Frågeställningar rörande projektet

18. Öppna frågeställningar 19. Befintliga lösningar 20. Nya problem 21. Att-göra-lista 22. Migrering till ny produkt 23. Risker med projektet 24. Kostnadsuppskattning 25. Användarmanual 26. Väntrummet (framtida kravställningar) 27. Lösningsförslag

Teoretisk referensram

16

Användarcentrerad systemutveckling Användarcentrerad systemutveckling bygger på att utvecklingen under hela processen utgår från användarna. Gulliksen & Göransson (2002, s. 114) framhåller att det är viktigt att ta hänsyn till användarnas behov, krav och förväntningar i utformandet av system för att kunna skapa system som gör nytta i användningssituationen. Gould, Boies & Ukelson (1997, s. 233) menar att projektgruppen måste skaffa sig kunskap om användarna genom empiri och att aktivt involvera användarna under hela utvecklingsprocessen. Användarcentrerad systemutveckling ska bedrivas iterativt med återkommande användbarhetsutvärderingar av systemet. Användbarhetsdesignen ska ske integrerat med den övriga utvecklingen.

Användarcentrerad systemutveckling kan ställas mot den teknikdrivna utveckling som är vanligt idag. Teknikdriven utveckling fokuserar ofta på systemets arkitektur, komponenter och funktioner, snarare än användbarhetsattribut såsom ändamålsenlighet, effektivitet och tillfredsställelse hos användaren (Gulliksen & Göransson 2002, s. 186). Vredenburg, Isensee & Righi (2002, s. 2) framhåller att skillnaden ligger främst i vilken utsträckning användarna involveras i utvecklingsprocessen och menar att en teknikdriven utvecklingsprocess missar att involvera användare under själva utvecklingsfasen. Fokus i en användarcentrerad utveckling ligger primärt på användarupplevelsen snarare än tekniken som ligger bakom.

Organisationer och användarcentrerad systemutveckling

Dagens agila utvecklingsmetodik lovar att lösa några av de problem som den traditionella vattenfallsmetodiken kan innebära. Det iterativa arbetet ska göra det lättare att fånga användarnas behov då kraven hela tiden kan ändras. Nodder & Nielsen (2008, s. 15) menar dock att problemet med de agila metoderna är att de är utvecklade av programmerare vilka huvudsakligen fokuserar på systemimplementationen snarare än användbarheten. Detta innebär att användbarhetsaspekterna än idag ofta blir förbisedd. Det är lätt att med ett pressat tidschema strunta i användbarheten då man inte tror att det finns tid för några användbarhetstester eller att studera användarna.

Ottersten & Balic (2010, s. 21) menar att organisationer inte arbetar användarcentrerat för att de personer som beställer systemen sällan har ansvar för systemets användningssituation eller har personalansvar för systemanvändarna. Hos beställare finns därför inget incitament att styra projektet mot att uppnå den förväntade nyttan, utan har istället fokus på att hålla budget och tid.

Gulliksen & Göransson (2002, s. 30) framhåller att man måste göra en avvägning i om ett projekt ska ha teknikfokus eller användarfokus, och menar att det inte självklart går att kombinera dessa två. Många systemutvecklingsprojekt har enligt Gulliksen & Göransson (2002, s. 30) ett tydligt fokus på tekniken i utvecklingen. Att införa ett användarcentrerat synsätt i systemutvecklingsprojekt kan innebära en stor förändring i många organisationer där man tidigare arbetat med tekniken i fokus (Vredenburg, Isensee & Righi 2002, s. 2). I införandet av ett användarcentrerat synsätt i utvecklingen är det viktigt att detta införs på ett sätt som kompletterar kravhanteringsprocessen och är bekant för utvecklarna. Det är också viktigt att det användarcentrerade arbetssättet passar ihop med den ursprungliga systemutvecklingsprocessen. Ett sådant arbetssätt bör förpackas på ett sådant sätt att det är attraktivt för systemutvecklarna så att de kan acceptera förändringen det kan innebära (Gulliksen & Göransson 2002, s. 47).

Vredenburg, Isensee & Righi (2002, s. 7) menar att det är viktigt att att organisationen integrerar ett användarcentrerat arbetssätt formellt i projektstyrningen. Detta för att säkerställa att aktiviteter som involverar användarna utförs i projekten. Det är därför vitalt att hela utvecklingsteamet ges kunskaper inom detta då hela teamet ska delta i det användarcentrerade arbetssättet. Vredenburg, Isensee & Righi (2002, s. 7) menar att de då är viktigt att komplettera med kompetenser inom detta område för att ansvara för de användarcentrerade aktiviteterna i utvecklingen vilka får avsatt tid och resurser för att genomföra detta. Nodder & Nielsen (2008, s. 20) utvecklar detta och menar att en sådan roll kunde fungera som en bro mellan utvecklare och användare. Denna roll skulle vara ansvarig för arbetet med användbarheten i projektet, och

Teoretisk referensram

17

att samla in data från användarna genom forskning, observationer och intervjuer. Gulliksen & Göransson (2002, s. 173) menar att denna roll behövs för att sätta fokus på användbarheten i utvecklingen.

Nodder & Nielsen (2008, s. 20) argumenterar för att det går att integrera ett användarcentrerat arbetssätt i en en agil projektmetodik så som Scrum. De menar att stories kan kompletteras med personas och information om användarna. Eftersom arbetet är uppdelat i sprintar innebär det också att man hela tiden har fokus på en hanterbar mängd producerat arbete som ska användartestas.

Cajander (2010 s. 81-85) har utforskat hur användarcentrerad systemutveckling kan införas i organisationer. Cajander presenterar i sin avhandling ett antal effektiva sätt att sprida medvetenheten om användbarhet på svenska myndigheter. En av metoderna som föreslås är att coacha nyckelpersoner inom organisationen att inse betydelsen av användbarhetsarbete vid systemutvecklingsverksamhet. En annan mer handgriplig metod är att låta utvecklare göra användarobservationer och reflektera över dessa med stöd från användbarhetsexperter. Cajander föreslår även en metod att mäta användbarheten i organisationens datorsystem genom att mäta användarupplevelsen genom en enkel enkät.

Empiri

18

Empiri I detta kapitel presenterar vi de respondenter vi intervjuat, såväl inom FRA som på de företag som hjälp oss i vårt arbete. Vi presenterar dels en de olika organisationernas bakgrund samt de insikter de olika intervjuerna har gett oss.

Respondenter på företagen Vi har totalt intervjuat sex personer från fem olika företag. Vi har valt att inte ange det verkliga namnet på företagen. Platsbesök genomfördes på tre av företagen vilka vi kallat Stora Fabriken, Systemleverantören (här träffade vi två respondenter) och Kravkonsultens företag. Vi träffade Granskningskonsulten på ett café i närheten av hennes arbetsplats. Med Medicinteknikföretaget genomfördes en telefonintervju.

Företagen valdes ut med hänsyn till deras storlek, deras verksamhetsområde och hur mogen kravprocessen skulle kunna tänkas vara. Konsulterna valdes ut för att de skulle kunna ge en bred bild och ett något annorlunda perspektiv då de har erfarenhet av flera olika organisationer.

Stora Fabriken Kärnverksamheten på Stora Fabriken är att tillverka en produkt med höga kvalitetskrav. Koncernen är stor och finns i flera olika länder. IT-avdelningen vi besökte har några tusen anställda vilket kan anses vara en stor avdelning. Vi besökte avdelningen vid ett tillfälle och träffade en person med ansvar för ett antal produkter.

Vi slogs av den stora processmognaden, de uttalade aktiviteterna och arbetsgrupper för allt från avvikelsehantering till processutveckling. Företaget har enkla regler som sammanfattas på ett visitkort med tydliga färgkoder för de olika momenten. Vår respondent menade att arbetet med att utveckla väldefinierade processer hade pågått under lång tid och att detta arbete skett på ett mycket medvetet sätt. Under besöket såg vi scrumtavlor och andra typer av planeringstavlor. Respondenten bekräftade också att företaget ofta använder Scrum i utvecklingen.

Koncernen har hundratals interna system och en väldefinierad och genomarbetad process för hur utveckling och förvaltning av systemen ska gå till. Då företaget är stort har man valt att prioritera att använda samma arbetssätt inom hela organisationen, snarare än att nödvändigtvis använda samma system. Företaget fokuserar alltså på att processen ska vara densamma snarare än att verktyget måste vara det.

En detalj vi lade märke till under vårt studiebesök på Stora Fabriken är att det finns en tydlig process för att hantera avvikelser i systemen. Vem som helst på företaget kan anmäla ett problem rörande verksamheten till en för ändamålet avsedd grupp som fattar beslut om eventuella vidare åtgärder. Dessa åtgärder kan innefatta systemutveckling eller andra förändringar i arbetssätt. Det finns även en särskild grupp som hanterar problem som återkommer upprepade gånger och har till uppgift att gå till botten med dessa och lösa dem.

Systemleverantören Systemleverantören har tusentals anställda och levererar flera olika egenutvecklade produkter vilka oftast är inbyggda system som levereras kompletta till externa kunder. På den avdelning vi besökte levererar man huvudsakligen system från sin produktportfölj, vilka anpassas specifikt för varje kund. Vid anpassningen tittar man bland annat på ergonomi och användbarhet.

Empiri

19

Systemutvecklingen utgår ofta från en juridiskt bindande kravspecifikation vilket gör att företaget lägger relativt stora resurser på kravanalys vid upphandlingens början. Kravanalysen görs för att ta reda på hur anpassningen av produkten ska ske. Mot slutet av projektet finns det tydliga avtal som reglerar om systemet levererats enligt överenskommelse.

Företaget har särskilda kravanalytiker som sköter mycket av upphandling men också kravhantering i senare skeden. Det finns en grupp som arbetar med användbarhet och ergonomi. Vår uppfattning är att företaget sällan fick beställningar där användbarhet beställdes explicit, vilket kan begränsa möjligheten att leverera systemen så att god användbarhet säkerställdes.

Medicinteknikföretaget Det internationella medicinteknikföretaget har tiotals utvecklare i Sverige som utvecklar en viss medicinteknisk utrustning. Eftersom det rör sig om medicinsk utrustning ställs höga krav på produkten och inga aspekter får missas i kravställningen. För att minimera risken för konstruktionsfel och fel i kravställningen utnyttjar man bland annat peer-review där någon som inte deltagit i kravarbetet får granska kraven såväl som producerad källkod. Bland företagets anställda finns personal som arbetat inom sjukvården med motsvarande produkter, dessa fungerar som en referensgrupp i utvecklingen. Utvecklarna gör studiebesök i bruksmiljön så ofta det är möjligt.

Kravkonsulten Kravkonsulten arbetar på ett mindre IT-konsultbolag och har lång erfarenhet inom kravanalys och kravställning. Hon arbetar gärna med RUP-baserade metoder men anpassar sig efter kundens önskemål på metod. Hon arbetar bara undantagsvis agilt då kunderna vanligtvis föredrar att arbeta med RUP. I de fall då det finns användbarhetsexperter i projektet arbetar hon tillsammans med dessa. Hon anser sig inte själv arbeta med användbarhetsfrågor.

Vår uppfattning är att respondenten har väl utvecklade metoder för att fånga behov och kartlägga processer. Hon framhöll i intervjun att det är viktigt att beskriva nuläget och nyläget var för sig. Något vi tog med oss var att det är viktigt att skapa konsensus när nuläget beskrivs. Kravkonsulten löser detta genom att samla berörda personer i ett och samma rum och låta dem gemensamt komma fram till en bild av hur processen egentligen går till genom att använda visuella metoder, ofta genom att rita på whiteboardtavla. Att intervjua olika intressenter enskilt är inget hon rekommenderar, då dessa ofta har olika uppfattningar om hur verksamheten fungerar. Som kravställare får man då ett digert arbete med att jämka samman en enhetlig bild av hur verksamheten ser ut. Kravkonsulten lägger mycket tid på att förmedla kravbilden till systemutvecklarna.

Granskningskonsulten Granskningskonsulten arbetar mycket med kodgranskning och hade vid intervjutillfället ett längre uppdrag inom den offentliga sektorn. Hennes erfarenhet är att företag ofta har svårt att sätta tydliga ramar för projekt och därmed ofta missar viktiga delar i det initiala kravarbetet. Något hon också upplevde som vanligt är att beställare lätt väljer en lösning för tidigt istället för att ta reda på verksamhetens egentliga behov.

Försvarets Radioanstalt Försvarets Radioanstalt (FRA) är den organisation vi fokuserat på i denna studie. FRA bedriver signalspaning på uppdrag av regeringen för att kartlägga yttre militära hot och andra

Empiri

20

förhållanden i utlandet som kan påverka Sveriges säkerhet. FRA stödjer också andra svenska myndigheter i sitt informationssäkerhetsarbete (FRA, 2011). För att dessa uppgifter ska kunna genomföras, behövs adekvata informationssystem som på olika sätt stödjer myndigheten i dess arbete.

Presentation av respondenter på FRA

Vi har tittat på fem utvecklingsprojekt av varierande storlek och komplexitet där vi intervjuat flera personer i varje projekt. Vissa personer har varit delaktiga i fler än ett av dessa projekt. Vi har även intervjuat personer med ansvar för utvecklingsprocessens utformning. Totalt har vi intervjuat 20 personer men vi har haft kontakt med ytterligare några på utvecklingsavdelningen under våra observationer.

Projektgrupperna består i allmänhet av fyra till åtta personer. I två fall fanns det användarrepresentanter med i projekten. I ett av projekten fanns en utvecklare med bakgrund i verksamheten systemen utvecklas för. Vi har tittat på projekt från flera av FRA:s verksamhetsområden. Vi har valt ut respondenter för att representera så många roller som möjligt i utvecklingsprojekten: systemutvecklare, projektledare, beställare och användarrepresentanter.

Organisation

FRA har en egen utvecklingsverksamhet som förser myndighetens kärnverksamheter med IT-lösningar. Internt regleras utvecklingen av dessa system med inom myndigheten uppsatta IT-mål. Dessa är till för att säkerställa att FRA har de förmågor som krävs för att genomföra sitt uppdrag.

Tidigare hade myndigheten en CIO (Chief Information Officer) som hade det övergripande ansvaret för uppfyllandet av IT-målen. Detta ansvar har nu flyttats ut i organisationen som ett led i att decentralisera verksamheten. Decentraliseringens orsak uppges vara att delegera ut ansvaret så nära de det berör som möjligt. Utvecklingsavdelningen har förhoppningar om att dessa förändringar ska leda till ett ökat ansvar på kundsidan för nyutveckling, förvaltning och drift av sina IT-system.

Under mitten av 2000-talet infördes en verksamhetsövergripande process för att strukturera arbetet med myndighetens IT-satsningar. Denna styrmodell kallas FRAIT (figur 1) och modellen lägger an ett förmågeperspektiv. En förmåga avser här samtidig tillgång på utrustning, kompetens och resurser. Detta perspektiv genomsyrar IT-satsningarna på strategisk nivå.

Projektstyrning

Under början av 2000-talet infördes ett processramverk för projektstyrning. Detta har under åren anpassats till utvecklingsavdelningens behov. Utifrån de intervjuer som gjorts med utvecklarna verkar projektstyrningsmetoden upplevas som positiv, inte minst genom de projektkontrakt som upprättas och tydligt specificerar ramarna för respektive projekt. Dessa fungerar som behovsunderlag under resten av projektet. Det har dock framkommit att beställningsförfarande och kravprocess inte sker på samma enhetliga sätt som resten av projektet vilket visar på behovet av denna studie.

En beställning av ett IT-system utgår alltid från ett behovsunderlag som beställare i verksamheten har till uppgift att formulera. Detta ska motivera satsningen på IT-systemet genom att beskriva hur projektet ligger i linje med FRAIT och de förmågor man önskar säkerställa. I behovsunderlaget kan idéer om vad som ska göras, mål, vision, krav och risker ingå. Behovsunderlaget ska vara frikopplat från lösningen och ge en bild av problemet och dess avgränsning. Målsättningen är att det inför projektstart ska finnas ett övergripande underlag för att kunna fatta beslut om huruvida projektet ligger i linje med verksamhetens behov och

Empiri

21

önskade förmågor eller inte. Figur 4 ger en bild av förhållandet mellan styrmodellen, projektstyrningsmodellen och utvecklingsmetodiker.

Figur 4. Förhållandet mellan styrmodellen, projektstyrningsmodellen och utvecklingsmetodik på FRA.

På utvecklingsavdelningen finns en särskild grupp som arbetar med projektstyrningen. De har till uppgift att bemanna projekten med projektledarkompetens och tilldela resurser. Vissa projekt saknar en formell projektledare och drivs istället av exempelvis utvecklare eller scrummaster. Anledningarna till detta uppges bland annat vara projektets storlek och karaktär eller resursbrist.

Innan projektstart

I beställningen av ett IT-system formuleras, som tidigare nämnts, ett behovsunderlag. För detta arbete finns stöd i form av en mall. Beställarna har olika vana och kompetenser då beställarsidan är organiserad i olika enheter med olika grad av teknikintensivitet. Beställare har i intervjuer framfört att man känner en viss otrygghet i beställarrollen då de upplever vissa svårigheter i att formulera behovsunderlaget. Detta menar de är delvis på grund av att man inte vet vad som är tekniskt möjligt och man uttrycker en önskan om stöd från utvecklingsavdelningen i detta. Enligt vår uppfattning är det vanligt att man som beställare tenderar att beställa en lösning utan att lyckas förmedla behovet som beställningen bottnar i.

Utifrån ett behovsunderlag inleds ibland en undersökning för att klargöra problemställningen. Detta kan göras antingen på beställarsidan eller av utvecklarna. Utredningen görs mer eller mindre formellt och oftast i form av en förstudie. När en förstudie är färdig, bör ett beslut kunna fattas om projektet ska fortsätta. Vi har inte sett att en förstudie har gett underlag för ett beslut som resulterar i att ett projekt inte startas, det verkar som att genomförandet av en förstudie i regel innebär början på ett projekt som inte avbryts.

Eftersom förstudierna görs på olika sätt och av olika roller varierar innehåll och omfattning. Förstudierna kan exempelvis innehålla prognoser om vilka nya förmågor som behövs, resultat från användarundersökningar och enkäter, lösningsförslag och kravlistor med varierande detaljnivå. Vår uppfattning är att det inte finns några enhetliga ramar för detta arbete.

Ibland överlämnas förstudien till utvecklingsteamet som kravspecifikation. Ibland ingår samma personer som gjort förstudien i projektgruppen, men inte alltid. I de fall där det sker en överlämning från förstudiegruppen till projektgruppen har det under intervjuer med utvecklare framkommit att kravbilden upplevs som svår att ta till sig. Utvecklarna tyckte då att en viktig del i överlämningen är att problemområdena från förstudien är prioriterade, så att de kan börja arbeta med rätt saker. Om någon från förstudiegruppen finns kvar även under projektarbetet förmedlar denna person kunskapen från förstudien under hela projektet.

Två framgångsrika projekt verkar ha varit betjänta av en längre tids initialt lågintensiv utveckling och detta har resulterat i en tydligare problemställning. Både utvecklare och beställare framförde i intervjuerna att det var bra att idén fick mogna.

Utvecklare i vissa projekt har påpekat att målbilden eller visionen för projektet förmedlats på ett otydligt sätt. Utvecklarna har också saknat tydliga leverabler för projektet. I de fall då det bakomliggande behovet inte är ordentligt utrett händer det att man kraftigt förändrar visionen eller målbilden under projektets gång.

Empiri

22

Krav

Vår generella uppfattning är att man som utvecklare upplever att FRA är en bra och innovativ arbetsplats där stor frihet finns att själv hitta bra lösningar. Detta understryks vara något man värnar om och vill bevara. Utvecklarna uttrycker att de är mest betjänt av inkommande krav på ett idémässigt plan och vill ha frihet att göra innovationer utifrån givna förutsättningar snarare än att implementera utifrån en detaljerad instruktion. Några av utvecklarna vill gärna ha kvar problemlösningsmomentet i utvecklingen.

Några utvecklare har erfarenhet av att kravbilden blivit för omfattande vilket gjort det svårt att avgränsa projektet och tillgodose de primära behoven. En utvecklare menade att detta direkt gick ut över användbarheten när man börjar implementera om man har för många krav. Systemet överlastas då lätt med funktionalitet och får ett gränssnitt som blir rörigt och osammanhängande.

Ofta ändras kraven under projektets gång. Då agil utveckling används kan man hantera detta i utvecklingsprocessen. Dock förutsätter agil utveckling att kraven kan prioriteras, något som försvåras vid för stora förändringar i kravbilden. En vanlig strategi vi sett är att låta beställaren prioritera bland kraven och att utvecklarna säger ifrån om kraven skulle bli onödigt omständliga att implementera. Detta tycker utvecklarna har fungerat bra.

En central del i scrumutveckling är att projektgruppen och beställarsidan tillsammans prioriterar bland kraven och bestämmer vad som ska ingå i nästa sprint. Detta underlättar kravprioriteringen. En anledning till att Scrum föredras framför exempelvis RUP är att utvecklarna upplever sig slippa mycket administration och snabbt kan sätta igång att implementera. Scrum ger också bra överblick över arbetsuppgifterna i projektet och utvecklarna uppskattar det gemensamma ansvaret som föreskrivs.

Utveckling

På utvecklingsavdelningen finns utvecklare, systemarkitekter, testare och projektledare. Dessa har många uppgifter. De gör förstudier, kravinsamlingar, prototyper, utvecklar och testar det som utvecklats. Inte sällan bidrar de även i hög grad vid installation och drift, och är senare inblandad i förvaltningen av systemen. De arbetar oftast i team om fyra till åtta personer, och arbetar med bland annat RUP- och Scruminspirerade metoder. Utvecklarna har ofta relevant högskoleutbildning, ibland även formell kompetens inom användbarhetsarbete. En del av utvecklarna har bakgrund i andra delar av verksamheten på FRA och bidrar därigenom med i nödvändig domänkunskap till de övriga projektmedlemmarna.

De nyanställda utvecklarna på myndigheten får ofta en grundläggande utbildning kring kärnverksamheten. Detta är i stort sett samma utbildning som nyanställda i respektive kärnverksamhet får. Syftet med utbildningen är att utvecklarna ska få inblick i den verksamhet systemen utvecklas för. Någon kontinuerlig uppföljning av denna utbildningssatsning har vi dock inte sett. Både utvecklar- och beställarsidan uttrycker önskemål om fler studiebesök i verksamheten för att utvecklarna ska hålla sig à jour med den. Utvecklarna menar att möjligheterna att göra studiebesök kringskärs av den sekretess som råder, samt att det stjäl tid från den ordinarie verksamheten. De är också oroliga för att störa i den dagliga verksamheten. Beställarsidan framhåller dock att detta inte skulle vara något problem då man under studiebesöken kan arbeta med mindre känsligt data. Vissa chefer på beställarsidan säger sig vara villiga att prioritera studiebesök från utvecklarna.

Vi har sett att det förekommer visst strukturerat användbarhetsarbete i systemutvecklingen. Detta verkar sällan vara sanktionerat utan sker på utvecklarnas eget initiativ. Det finns heller inga krav på det i projektstyrningen. Det användbarhetsarbete som vi sett förekommer är bland annat kontextuella intervjuer, prototyper som exempelvis Straw man, vilket innebär att en avsiktligt dålig prototyp levereras vilken provocerar fram feedback. Det händer dock att användbarhetsarbetet kommer in mot slutet av projektet. En vanlig uppfattning hos utvecklarna är att man först måste bygga ett grundsystem, för att ha något att användartesta.

Empiri

23

Vanligast är att användarperspektivet finns i projekten i form av användarrepresentanter. Dessa är tänkta att representera de som rent praktiskt ska använda systemet vilka ibland är flera disparata användargrupper. Representanterna har ofta lång erfarenhet av olika system inom verksamheten.

I de projekt där arbetet sker Scruminspirerat framhålls att projektgruppen värdesätter kontakten med beställaren och användarrepresentanten. Vissa beställare är med regelbundet på de dagliga scrummöten som projektgruppen har vid scrumutveckling. En allmän uppfattning hos utvecklarna att Scrum är bra på att fånga feedback från beställarsidan vilket man får under sina sprintdemos.

Värt att nämna är att vissa mätningar har gjorts på användbarheten på några av de interna systemen. Metoden har varit enkätstudier av användarnas upplevelse av systemet. Motsvarande undersökning har även gjorts på system utanför FRA med det sammanlagda resultatet att FRA fick sämre betyg av användarna än medeltalet för enkäten.

Vi har bland utvecklarna sett två tydliga synsätt rörande hur människor interagerar med datorer. Det ena är mer användarcenterat, det andra är mer rationalistiskt. Det senare med en tanke om att systemen ska automatisera mänskliga uppgifter när så är möjligt. Detta med följdresonemanget att användarcenterad systemutveckling verkar hämmande för automationen och att användarna aldrig skulle föreslå något som rationaliserar bort dem själva.

Analys och diskussion

24

Analys och diskussion Vår allmänna uppfattning om FRA är positiv. De anställda har varit mycket tillmötesgående och hjälpt oss under vårt arbete. Vårt samlade intryck är att alla vi träffat är måna om att leverera system av absolut högsta kvalitet och att det finns en vilja att ständigt förbättra verksamheten på alla plan. Att FRA gett oss möjligheten att titta noggrant på det initiala behovs- och kravarbetet visar en öppenhet och en insikt i att denna del av systemutvecklingsprocessen kan förbättras.

Att vi fått möjligheten att intervjua representanter från företag har gjort att vi kunnat bilda oss en uppfattning om hur det ser ut i andra organisationer. Detta har gett oss en bredare bild av hur behovs- och kravhantering går till och hur man arbetar användarcentrerat i andra organisationer. Detta har varit mycket lärorikt och en förutsättning för vårt arbete.

Innan projektstart Tidigt märkte vi att det på myndigheten fanns stora skillnader i uppfattningen om begreppet förstudie och vad det innebär. Många av våra respondenter var osäkra på hur det egentligen borde gå till och många som gjort förstudier på utvecklingsavdelningen var noga med att påpeka att det var viktigt att det fanns möjlighet att utföra detta arbete på olika sätt beroende på projekt. Vår tolkning är att utvecklarna befarar att processen blir för detaljstyrd och därmed svåranvänd om den definieras för noggrant. Vi tror att många utvecklare är rädda få in en metod som kräver mycket dokumentation, då de uttalat sig kritiskt mot dessa delar i RUP.

Vi anser att det inte finns någon motsättning i att ha en definierad process och att ha frihet att utforma sitt arbete anpassat till uppgiften och till sitt eget arbetssätt. Vi anser att det är viktigt att de som gör förstudien ska ha stor frihet att utforma denna lärprocess som de finner det bäst. Samtidigt måste förstudien kunna tjäna som beslutsunderlag för projektstyrningens beslutspunkter för att prioriteringen och beslutsfattandet ska bli tydligt. Hallberg (2009, s. 14) talar om att beslutspunkterna som saknar ”tänder” släpper igenom projekt som inte borde startas. Detta innebär att även FRA:s beslutspunkter gällande tidiga delar av projektet kan behöva ses över, till exempel genom att införa riktlinjer för hur beslut kring projektstart ska tas.

Då förstudier görs på olika sätt på FRA varierar även innehållet. Eftersom förstudien har visat sig vara en relativt komplex process i vilken det är lätt att missa centrala delar anser vi att ett stöd för detta arbete är nödvändigt då missade områden innebär ökade kostnader. Stödet bör också hjälpa till i beslutet kring projektets fortsatta genomförande. I övrigt är vår uppfattning är att projektstyrningen är väletablerad i verksamheten och fungerar väl i senare delar av systemutvecklingen då man lagt mycket arbete på att anpassa processen till verksamheten.

Vid vissa förstudier har det gjorts välgjorda undersökningar av användarna för systemet. Vår bedömning är att det finns mycket tid och arbete att spara på att identifiera och kartlägga målgrupper i någon utsträckning i alla projekt där det är relevant med användbarhetsfrågor. En målgruppsanalys kan hjälpa till att prioritera vilken funktionalitet systemet ska ha, så att man inte implementerar funktionalitet som inte kommer till användning.

Vi har upptäckt att förstudiens kanske viktigaste syfte är att ge de som ska arbeta i projektet tid att lära sig mer om förutsättningarna och de tekniker som krävs i projektet. Det är därför mindre lämpligt att försöka överlämna en förstudie i form av dokument till en ny projektgrupp. Det kan dock fungera om det finns en person med i projektgruppen som även var med och gjorde förstudien och kan förmedla kunskapen. Det har framkommit under intervjuer med utvecklare och Kravkonsulten att det är svårt att ta till sig dokument skrivna av någon annan då det alltid sker en tolkning och en kunskapsförlust.

Analys och diskussion

25

Man kan fråga sig hur länge en förstudie bör pågå. Projektdeltagare i några av projekten vi tittat på upplevde att projekten blivit bättre efter ett längre uppehåll mellan förstudie och projektstart då projektidéerna har fått mogna. Detta skulle kunna implicera att en förstudie bör ta lång tid. Vi tror dock att det går att accelerera processen genom att använda lämpliga metoder för att fånga behov och krav så att projektgruppen mer intensivt diskuterar och tvingas ifrågasätta idéerna.

I likhet med kännedomen om hur förstudie och kravinsamling bör gå till fann vi att kunskapen om de övergripande IT-målen i verksamheten var dåligt spridd. Det är inte orimligt att anta att detta kan leda till problem då det blir svårt att förstå vilka processer som ligger till grund för vilka projekt som startas eller måste vänta. Det är också viktigt att man förstår vilka principer som ligger till grund för besluten. Genom att arbeta mer med att sprida IT-målen i verksamheten blir det lättare för ledningen att få gehör för målsättningarna och styra verksamheten mot dem.

Då många beställningar sker internt gör det att organisationen slipper arbetskrävande beställningsjuridik. Detta kan jämföras med Systemleverantören som lägger mycket resurser på att få juridiska avtal rörande leveransen på rätt sätt. Man uppgav hos Systemleverantören att frysta kravspecifikationer tidigt i processen ibland lägger hinder för användbarhetsarbetet då beställare sällan beställer användbarhet explicit. Ett användarcentrerat arbetssätt ett iterativt arbete. En fryst kravbild och ett iterativt arbetssätt menar Gulliksen & Göransson inte går att kombinera. Då många beställningar sker internt finns det därmed goda förutsättningar för FRA att undvika att frysa kravspecifikationer tidigt i projektet, vilket förenklar ett användarcentrerat arbetssätt. En allt för otydlig kravbild och otydliga överenskommelser i vad som ska levereras kan dock leda till prioriteringsproblem och att utvecklingsavdelningen får svårt att veta när målet för projektet är uppnått. Det är fortfarande viktigt att ställa upp tydliga ramar för projektet.

Projektets målsättningar ser olika ut på olika nivåer i projektet. Projektstyrningsmetoden skall helst styra projektet mot en förväntad effekt i verksamheten vilket Ottersten & Balic förespråkar, men i praktiken riskerar den att fokusera för mycket på faktorer som tid, budget och levererad funktionalitet. Agil utveckling förespråkar kvalitet och kundnöjdhet som sina primära målsättningar. Det kan finnas en motsättning i de mål projektet arbetar mot. Eftersom metoderna verkar på organisatorisk nivå respektive projektnivå, tror vi dock att metoderna går bra att kombinera. Vi anser att det är centralt att det finns incitament och fokus att styra projektet mot nytta och kvalitet i användning. Med agil utveckling är det enkelt att besluta om förlängning av projektet, samtidigt som beställaren kan vara säker på att det som levereras håller hög kvalitet. Effektmålen skall vara skrivna så att det tydligt framgår när dessa mål är uppfyllda, vilket underlättar beslutsfattandet kring eventuell förlängning av projektet.

Vi vill att vår metod uppmuntrar en förtrolig dialog mellan beställare och projektgrupp där man tillsammans kan gå igenom och hantera så många frågor som möjligt i ett tidigt skede. Detta för att gemensamt komma överens om ramarna för projektet och identifiera eventuella problem som kan uppstå. Såväl litteratur som vår empiri tyder på att kraven måste växa fram successivt, vilket förutsätter förtroende mellan parterna.

Krav Krav förändras ofta under projektets gång då nya aspekter upptäcks vid implementation och användartestning. Vid iterativ utveckling arbetas kraven fram successivt under projektets gång. Detta hindrar dock inte att en systematisk genomgång av alla aspekter rörande kraven görs i början av ett projekt. Denna genomgång kan göras översiktlig då huvudsaken är alla delar av kravbilden diskuteras. Vi anser att det är orimligt att börja om från början i varje projekt då många krav, särskilt icke-funktionella, i vår fallstudie är relativt beständiga över tid och desamma för många projekt. Den översiktliga genomgången av kravbilden kan hjälpa beställaren och leverantören att sätta ord på annars outtalade förväntningar och föreställningar, vilket kan leda till missförstånd som får konsekvenser senare i projektet.

Analys och diskussion

26

Genomgången bör ha till funktion att identifiera områden som kan vara relevanta, och ge en översikt över det arbete som är absolut nödvändigt för att projektet ska kunna genomföras.

Enligt de utvecklare och projektledare vi intervjuat läggs mycket av ansvaret för att prioritera i backlogen på beställarsidan. Om man är ovan som beställare, eller inte helt säker på vad projektet ska uppnå kan detta vara en svår uppgift. Återigen är det viktigt att innan utvecklingen sker definiera en klar bild av vad verksamhetens behov egentligen är, och att projektgruppen känner till vad som ligger bakom beställningen.

Användbarhet

Det förekommer redan idag visst användbarhetsarbete på myndigheten men detta arbete är ofta kopplat till enskilda utvecklares intresse och förmåga att frigöra resurser för användarcentrerade aktiviteter. För att styra utvecklingen mot ett användarcentrerat arbetssätt anser vi att FRA måste styra utvecklingen mot att uttalat skapa användbara system samt att användbarheten kontinuerligt följs upp i både befintliga och nyutvecklade system.

Vi har sett att utvecklarna har en tendens att göra mycket genomarbetade prototyper i vissa projekt. Detta kan bero på att dessa projekt har använt RUP som utvecklingsmetodik. Metodiken föreskriver att man konstruerar prototyper för att testa arkitekturen, vilka kan kräva mycket arbete att implementera. Det kan tänkas att det då är svårt att ompröva en lösning om mycket arbete redan lagts på implementationen och den i testsituation visar sig vara svåranvänd. Detta i kombination med användartestning sent i projektet gynnar inte användbarheten i det slutgiltiga systemet. Lösningen bör vara att bygga enklare prototyper med verktyg som gör dem lättare att omforma, för att kunna användartesta prototyperna tidigt i projektet.

Många av projekten har användarrepresentanter, vilket är en viktig del i ett användarcentrerat arbetssätt. Användarrepresentanternas arbete behöver i regel kompletteras med andra aktiviteter såsom kontextuella intervjuer eller lämpliga workshops för att bredda hela projektgruppens bild av användarnas behov. Detta inte minst för att användarrepresentanten inte kan förväntas förmedla alla aspekter av hur systemet förväntas användas. Att utvecklarna deltar i aktiviteterna ställer också lägre krav på noggrann dokumentation.

Vi ser att det finns goda möjligheter till tätare kontakt mellan utvecklare och användare då delar av utvecklingen av nya system sker internt och man i allmänhet sitter nära varandra. En annan styrka vi sett på myndigheten är att man på utvecklingsavdelningen har utvecklare med en gedigen bakgrund i ordinarie verksamhet. Som utvecklare måste man ha en god förståelse och aktuell kunskap om verksamheten. Utvecklingsavdelningen får därför inte glömma bort att låta även utvecklare med bakgrund i ordinarie verksamhet hålla sig aktivt uppdaterad i den ordinarie verksamheten.

Sammanfattningsvis är vår uppfattning att det finns en mycket bra grund för att stärka användarcentrerade aktiviteter på FRA. Det finns utvecklare som har formell kunskap inom området eller har ett personligt intresse för användarcentrerad systemutveckling. Vi kan dock se att andelen utvecklare med detta intresse inte är tillräckligt stor för att ett användarcentrerat förhållningssätt kommer att få genomslag i verksamheten. Vi anser att detta bör stärkas upp genom kompetensutveckling eller nyanställning av personer med denna kompetens vilket Nodder & Nielsen, Gulliksen & Göransson och Vredenburg, Isensee & Righi också förespråkar. Då myndigheten väljer att satsa på användbarhetsarbete anser vi att uppföljning av detta arbete måste ske. Detta för att kunna påvisa vilka förbättringar arbetet har lett till och för att kunna prioritera de resurser som avsatts för att stärka användbarheten.

Ottersten & Balic diskuterar kring vad man har för incitament som beställare att styra systemen mot att de blir användbara. Som beställare måste man ha ett incitament att göra systemen bra och inte bara under budget eller i tid. Utifrån detta resonemang tror vi att det är viktigt för FRA att utvecklingsavdelningen ger stöd till ovana beställare så att dessa på ett bra sätt kan se till att deras användare få användbara system. Det är också en styrka om beställaren har personalansvar för dem som ska använda systemet.

Analys och diskussion

27

Införandet av en användarcentrerad systemutvecklingsmetodik måste anpassas till det befintliga arbetssättet. Som Gulliksen förespråkar så behöver detta arbetssätt formellt införas i projektstyrningen vilket vi tror är möjligt. Detta kan göras genom att införa effektmål som föreskriver användbarhet i systemen. Användbarhetsarbetet måste även införas i utvecklingsmetodiken. Nodder & Nielsen föreslår att man kompletterar stories i Scrumutveckling med information om användarna. Detta innebär att hela projektgruppen får kunskap om användarna vilket är viktigt då hela teamet är involverat i det användarcentrerade arbetet. Vi tror också att FRA kan ha stor nytta av de metoder Cajander föreslår för att införa ett användarcentrerat synsätt då metoderna är utvecklade på andra svenska myndigheter.

Slutsatser

28

Slutsatser I detta kapitel presenteras svaren på frågeställningarna, våra slutsatser samt den metod för behovs- och kravhantering vi utformat.

Svar på frågeställningar Den frågeställning detta arbete huvudsakligen utgått från är:

”Hur kan en metod för initial behovs- och kravhantering som motsvarar FRA:s behov i agil utveckling se ut?”

Frågeställningen delas upp i tre delar vilka besvaras nedan.

Hur kan metoden underlätta för FRA gällande initial behovs- och kravhantering?

En metod för behovs- och kravhantering kan hjälpa FRA att använda utvecklingsresurserna effektivare genom att fokusera på att tillfredsställa väl utredda behov. Metoden bör förmedla de bakomliggande behoven på ett enhetligt sätt. Detta för att underlätta prioriteringen mellan olika projekt och hjälpa utvecklarna att snabbt sätta sig in i olika projekt.

Genom att arbeta utifrån en enhetlig metod minskas risken för att centrala områden missas i förstudiearbetet. Detta kan hjälpa till att undvika kostsamma anpassningar av ett utvecklat system på grund av en bristfällig initial krav- och behovsinsamling. Metoden är också viktig för att stödja ovana beställare genom att dialog mellan utvecklare och beställare.

Vad kan en metod för initial behovs- och kravhantering bestå av?

Metoden bör bestå av en översikt, som hjälper till att visualisera processen för alla inblandade för att kunna planera aktiviteterna i processen. Metoden måste täcka in samtliga områden i kravprocessen för att man ska våga lita på metoden och att inte centrala delar missas.

Metoden ska också erbjuda stöd i arbetet så att projektgruppen kan välja rätt aktiviteter för att ta fram de olika kraven och identifiera behoven anpassat till varje projekt.

Hur ska metoden gestaltas för att motivera till användandet av denna?

Metoden ska vara lätt att ta till sig och inte hota någons kompetens. Därför ska metoden vara visuell och erbjuda god överblick. Den ska uppmuntra dialog kring kraven snarare än att resultera i onödigt utförlig dokumentation.

Det ska med hjälp av metoden vara lätt att planera sitt arbete, och andra ska förstå hur man har planerat, så att alla i projektgruppen blir delaktiga i arbetet. Det är också viktigt att alla intressenter ser att projektgruppen och beställaren berört alla delar i kravprocessen. Detta gör också att man tillsammans kan skapa ett underlag för att fatta underbyggda beslut om projektets fortsättning.

Slutsatser rörande införande av användarcentrerad systemutveckling på FRA

Den metod vi tagit fram stödjer de tidiga faserna i systemutvecklingsprojekt och uppmuntrar till användarcentrerad systemutveckling. Vi har anpassat metoden till FRAs verksamhet efter allra

Slutsatser

29

bästa förmåga. Vi ser vår metod som en del i ett organisationsutvecklingsarbete för att på lång sikt säkerställa användbarheten i myndighetens IT-system.

Vi anser att FRA bör se till att uppmuntra och sanktionera användandet av den kunskap kring användarcentrerad systemutveckling som redan finns i organisationen. Myndigheten bör även anställa användbarhetsexperter, vilka har till uppgift att bidra till ett användarcentrerat arbetssätt. Man bör inte underskatta det medvetna arbete som krävs för att göra den omställning av organisationens arbetssätt som är nödvändig för att framgångsrikt och på ett förutsägbart sätt kunna arbeta med användarcentrad systemutveckling. Det är viktigt att det användarcentrerade arbetssättet inte upplevs innebära merarbete utan att det på ett självklart sätt bidrar positivt till verksamheten. Vid införandet bör man även vara beredd på att kunna väga in användbarhetsrelaterade aspekter vid resurstilldelning och andra prioriteringar på olika nivåer.

För att försäkra sig om att användning av de resurser som läggs på användbarhetssatsningar gör största möjliga nytta, bör dessa följas upp. FRA har redan idag en enkät som mäter användarnas uppfattning av systems användbarhet. Denna skulle relativt enkelt kunna skalas upp. Resultaten från denna enkät sammanvägt med antalet användare ett visst system har skulle utgöra ett värdefullt beslutsunderlag för satsningar på användbarhet. En annan tänkbar indikator på användbarhet är hur många ärenden supportorganisationen tar emot relativt antal användare av systemen. Denna uppföljning skulle behöva kompletteras med en skrivelse i IT-målen rörande vilken nivå och/eller förbättring på användbarhet som är önskvärd.

Kravkartan – en metod för behovs- och kravhantering

Här presenterar vi Kravkartan vilket är den metod vi arbetat fram inom ramen för vårt examensarbete. Följande behov har vi utgått från i vår designprocess. Behoven kommer till stor del från empiri, men också litteratur. Dessa behov refereras till löpande i texten som följer.

Metoden ska: 1. ge överblick 2. bara innefatta nödvändig dokumentation 3. vara ett diskussionsunderlag för beslut 4. uppmuntra samarbete mellan beställare och utvecklare 5. stödja ovana beställare 6. vara lätt att ta till sig 7. inte hota någons kompetens 8. uppmuntra till kompetensutveckling 9. passa ihop med nuvarande organisation 10. sprida olika rollers kompetens 11. stödja utforskandet av beställningens bakomliggande behov 12. ge enhetlighet i tillvägagångssätt 13. vara så heltäckande som möjligt 14. uppmuntra till användarcentrerade aktiviteter

För att uppfylla dessa behov har vi skapat Kravkartan vilket är en affisch i A0-format (se bilaga 3). Denna kan sättas upp på väggen i projektrummet eller i allmänt utrymme. Kartan består av fyra kolumner vilka kan följas från vänster till höger. Dessa kolumner är inspirerade av de fyra första effektbesluten från effektstyrning. Innehållet i de fyra kolumnerna är inspirerat av Voleres 27 kravkategorier. Detta har tillsammans med erfarenheter från vår studie anpassats till att stödja FRA:s interna processer.

Den första kolumen syftar till att skapa klarhet i frågan om IT är en lönsam satsning att göra överhuvudtaget för att tillfredsställa ett behov i verksamheten. Man ska i detta steg formulera syftet med projektet, identifiera intressenter och redan här börja fundera på vilka som ska vara användare av det framtida systemet. Här definieras ramarna för projektet.

Slutsatser

30

Kolumn två erbjuder aktiviteter för att ta reda på användarnas behov, kompetens samt att formulera användningsmål. Förutom en målgruppsanalys bör man redan här titta på vilka förutsättningar som finns för att hantera risker förknippade med projektet. Syftet med detta steg är att utvärdera om den produktidé som föreslagits är rimlig.

I kolumn tre har man en klar bild över vad projektet ska uppnå. Här definieras bland annat krav på kvalitet och krav på prestanda och förvaltning och support. Målet är att undersöka ett antal lösningsförslag för att slutligen kunna välja ett av dem som den sista kolumnen syftar till att förfina.

Längst ned på Kravkartan finns det plats för att fylla i relevanta fakta och antaganden man gjort om projektet, öppna frågor och saker som ska sparas till senare. På Kravkartan finns också förslag på verktyg projektgruppen kan snegla på för att få inspiration till aktiviteter som kan utföras under hela projekttiden. Dessa verktyg kan vara till hjälp i exempelvis användarcentrerade aktiviteter. Relaterade behov: [14]

Avsikten är att projektgruppen får en ny karta vid varje nytt projekt och kan använda den på det sätt man finner lämpligt för projektet. På kartan föreslås en metod för att planera arbetet med hjälp av små runda klisterlappar i olika färger. Klisterlapparna används för att markera status för olika rutor och aktiviteter. Klisterlapparnas betydelse förklaras i tabell 1.

Svart Beställarens färg. Signalerar att man avser att lägga tid/prioritera denna aktivitet/ruta.

Vit Leverantörens färg. Signalerar att man avser att lägga tid/prioritera denna aktivitet/ruta.

Gul Aktivitet påbörjad

Grön Aktivitet avslutad

Röd Problem har uppkommit

Blå Aktivitet/ruta som inte kommer att beröras

Tabell 1: Betydelserna av klisterlapparnas färger.

Tanken är att affischen ska erbjuda stöd för beställaren som genom att beskriva sina tankar av verksamhetens behov, enkelt kan få utpekat av övriga projektgruppen var dessa funderingar kan placeras på kartan. Det finns till exempel en ruta för lösningsförslag, vilken direkt kom till användning under vår workshop, då beställaren tidigt kom med ett produktförslag i sin beställning. Relaterade behov: [4,5]

Kartan stödjer egentligen inte formuleringen av kraven utan är tänkt att fungera som en heltäckande översikt så att man inte missar centrala delar i förstudien. Det är också tänkbart att FRA får lättare att bygga upp rutiner för kravaspekter som återkommande visar sig innebära svårigheter i flera projekt. Relaterade behov: [13]

Metoden ska ge överblick för alla inblandade i den initiala behovs- och kravhanteringsprocessen. Vi har inspirerats av Kravkonsulten att göra arbetet visuellt så att man fysiskt ska kunna peka och ta på olika områden. Detta gör det lättare att diskutera annars abstrakta begrepp. Scrum löser detta genom att ha papperskort på en tavla. Vi valde att göra korten fasta vilket gör att alla som är vana användare av Kravkartan direkt kan se hur ett projekt går utan att tidigare ha varit delaktig i det. Den gemensamma spatiala bilden uppmuntrar till lärbarhet. Att korten är fasta uppmuntrar också till samarbete, eftersom det är enkelt för utomstående att rycka in och hjälpa till om vissa områden visar sig svåra. Relaterade behov: [1]

Metoden ska inte vara dokumentationstung då mycket dokumentation kan vara svårt att ta till sig. De som ska utveckla får en överblick och kan ställa frågor kring specifika delar. På kartan finns inte plats att skriva långa texter, men man kan vid behov komplettera den med ytterligare dokumentation. Kartan i sig kräver dock utförlig dokumentation. Relaterade behov: [2]

Slutsatser

31

Affischen bidrar till att göra resultatet av arbetet enhetligt. Processen ska gå att anpassa till projektets karaktär med hjälp av klisterlapparna då alla tydligt ser vilka områden som man planerar att gå igenom. Det gör arbetet lättare att ta till sig och ger projektgruppen frihet att arbeta så som de finner bäst. Relaterade behov: [3,9,12]

Vi hoppas att kartan kan uppmuntra till att man utnyttjar varandras kompetenser i projektgruppen. Vi tror att det blir lättare att förmedla sin kompetens då projektmedlemmar direkt kan peka på ett område de behärskar. Detta går i linje med det agila arbetssättet, som förespråkar att man utnyttjar och delar varandras kompetens. Inom myndigheten finns kompetens för användarcentrerad systemutveckling. Som vi tidigare nämnt skulle denna kompetens kunna stärkas genom att anställa dedikerade användbarhetsexperter. Som en dellösning har vi i kartan lagt in en utförlig översikt över metoder för att involvera användarna i systemutveckling. Denna verktygsrad är framträdande på kartan, och ger personer med kunskap inom metoderna uppmuntran att förespråka att dessa metoder används i utvecklingen. Relaterade behov: [7,8,10,14]

Kartan kan ge ett överväldigande intryck på grund av dess detaljrikedom, men mycket arbete har lagts på utformningen och formuleringar i de många texter som presenteras. Den är skriven på ett lekfullt sätt och tanken är att man ska kunna stå och studera den en längre tid. Relaterade behov: [6]

Kartans första kolumn ställer ett antal angelägna frågor kring varför egentligen projektet startas. Där uppmuntras beställaren och projektgruppen att utforska och reflektera vilket behov som ligger bakom beställningen. I en workshop var detta en av de funktioner som fungerade bäst, då utvecklingsteamet tillsammans med beställaren spontant började utforska de bakomliggande behoven. Relaterade behov [11]

Reflektion Vi har behandlat en stor mängd intervjudata, vilket har tagit mycket tid att analysera. Vi upplever att processen varit nödvändig men man kan tänka sig att istället för att ha ett stort antal intervjuer skulle vi kunnat samla personer från organisationen i workshop för att låta dem tillsammans kartlägga dagens processer. En sådan workshop kräver dock att man vet huvuddragen i det man vill ta reda på. Då vi inte visste exakt vad problemet var, hade vi antagligen inte kunnat få fram bra resultat.

Intervjuernas syfte förändrades alltefter våra kunskaper om dagens processer ökade. Initialt var syftet med intervjuerna att skapa oss en förståelse för nuläget, för att senare handla om hur en framtid skulle kunna gestalta sig. Om vi haft workshops hade vi behövt ta fler personers tid i anspråk, vilket hade varit svårare att genomföra praktiskt.

Designprocessen har varit ett växelspel mellan design och kravställning, som inte har varit särskilt linjärt. Vi har provat vissa idéer, och sedan diskuterat styrkor och brister i de olika lösningsförslagen. Vi kunde ha varit bättre på att tidigt prototypa och utvärdera dessa lösningsförslag för att få viktig feedback. Detta hade på ett bra sätt kunnat komplettera feedbacken från våra sprintdemos. Det var bra att använda Scrum, en metod som organisationen känner till.

Fortsatta studier

Det skulle vara intressant att titta på senare faser i utvecklingsarbetet och hur utvecklingsteamets kommunikation med användarna kan bibehållas under hela utvecklingsarbetet.

För FRA skulle det troligen vara intressant att titta närmare på begreppet ”agila kontrakt”, vilket ger ramar för att beställa agilt även från externa leverantörer.

Litteraturlista

32

Litteraturlista AGILE MANIFESTO. (2001). (Elektronisk).

Tillgänglig på <www.agilemanifesto.org>. (2011-01-24).

AGILE SWEDEN. (2004). (Elektronisk).

Tillgänglig på <www.agilesweden.org>. (2011-01-24).

BELL, J. (2006) Introduktion till forskningsmetodik. Studentlitteratur, Lund

CAJANDER, Å. (2010). Usability - Who Cares?: The Introduction of User-Centred Systems Design in Organisations. (Elektronisk). Acta Universitatis Upsaliensis, Uppsala

Tillgänglig på <http://uu.diva-portal.org/smash/get/diva2:310201/FULLTEXT01> (2011-01-24).

DAVIS, A M & YOURDON, E & ZWEIG, A S. (2000). Requirements Management Made Easy. (Elektronisk). Tillgänglig på <http://homepages.laas.fr/kader/Davis_et_al.pdf> (2011-01-24).

EWEEK. (2002). Desktops and Notebooks: IBM acquires Rational. (Elektronisk).

Tillgänglig på <http://www.eweek.com/c/a/Desktops-and-Notebooks/IBM-Acquires-Rational/> (2011-01-24).

FRA. (2011). (Elektronisk). Tillgänglig på <www.fra.se>. (2011-02-01).

GOULD, J D & BOIES, S J & UKELSON, J. (1997). How to design usable systems. I: Helander, M G & Landauer, T K & Prabhu, P V (Red.) Handbook of Human-Computer Interaction. Elsevier Science B.V.

GULLIKSEN, J & GÖRANSSON, B. (2002). Användarcentrerad systemdesign. Studentlitteratur, Lund.

HALLBERG, N & PILEMALM, S & WESTERDAHL, L & JUNGERT, E & ERIKSSON H & ANDERSSON, L (2008). Principer och metoder för systemutveckling. (Elektronisk).

Tillgänglig på <http://www2.foi.se/rapp/foir2628.pdf>. (2011-01-24).

HALLBERG, N. (2009). Ledningssystemsutveckling - Fallstudier kring kravhantering, modellering och kvalitetssäkring . (Elektronisk).

Tillgänglig elektronisk på <http://www2.foi.se/rapp/foir2892.pdf>. (2011-01-24).

Litteraturlista

33

HANSSON, S O. (2003). Konsten att vara vetenskaplig. (2:a upplagan, Filosofienheten, Kungliga Tekniska Högskolan, Stockholm).

HÄGGBERG, L (2002). Kreativitet och olika tekniker. (Elektronisk).

Tillgänglig elektroniskt på <http://www.csc.kth.se/utbildning/kth/kurser/DH2655/kid09/haggberg_2001.pdf> (2011-02-01)

HÖKENHAMMAR, P. (2001). Integrerad beställningsprocess vid datasystemutveckling. Institutionen för data- och systemvetenskap Stockholms universitet och Kungliga Tekniska Högskolan.

KNIBERG, H. (2007). Scrum from the trenches. (Elektronisk).

Tillgänglig på <http://www.infoq.com/minibooks/scrum-xp-from-the-trenches>. (2011-01-24).

MOUNTAIN GOAT SOFTWARE. (2011). (Elektronisk).

Tillgänglig på <www.mountaingoatsoftware.com>. (2011-01-24).

NODDER, C & NIELSEN, J. (2008). Agile Usability: Best practices for User Experience on Agile Development Projects. (1:a upplagan, Nielsen Norman Group, Fremont, Kalifornien).

OTTERSTEN, I & BALIC, M. (2010). Effektstyrning av IT: Nyttan uppstår i användningen. (Upplaga 2:1, Liber AB, Malmö).

PREECE, J & ROGERS, Y & SHARP, H . (2007). Interaction Design. 2:a upplagan, John Wiley & sons ltd, England.

RATIONAL SOFTWARE. (2008). Rational Unified Process: Best practices for software development teams. (Elektronisk).

Tillgänglig på <http://www.ibm.com/developerworks/rational/library/ content/03July/1000/1251/1251_bestpractices_TP026B.pdf>. (2011-01-24).

ROBERTSON, S & ROBERTSON, J. (2007). Mastering the requirements process. Pearson education, Inc, Boston.

STANDISH GROUP. (1995). CHAOS report. (Elektronisk).

Tillgänglig på <http://www.projectsmart.co.uk/docs/chaos-report.pdf>. (2011-01-24).

STRAND, L. (2001). UML & RUP: Att lyckas med oo-projekt. Docendo Sverige AB, Sundbyberg.

TONNQUIST, B. (2008). Project Management. Bonnier Utbildning AB, Stockholm.

Litteraturlista

34

VREDENBURG, K & ISENSEE, S & RIGHI, C. (2002). User-centered design. Prentice Hall, New Jersey.

Bilaga 1: Koncept och dimensioner

35

Bilaga 1: Koncept och dimensioner

Under vår analys inom ramen för Grounded theory, utkristalliserade sig ett antal återkommande inslag, koncept. Dessa kunde i sin tur ofta sammanfattas till än mer övergripande strukturer, dimensioner. Nedan ges en översikt över de mest centrala koncepten och dess dimensioner. I beskrivningen av koncepten beskriver de kursivt markerade orden andra koncept, vilka också finns med i tabellen.

Koncept Beskrivning Dimension Användarperspektiv Användarrepresentanten kan bidra med detta perspektiv

vid utvecklingen, i kombination med studiebesök och kontextuella intervjuer.

Användbarhet

Användarrepresentant Utvärdering av användbarheten på de system som används på beställarsidan.

Användbarhet, roll

Användarundersökning En undersökning av användarna för det system som ska skapas utifrån en beställning. Kan göras i samband med förstudie. Har utförts i form av en enkät.

Användbarhet

Användbarhetsarbete Görs ofta i förstudien av utvecklare i form av studiebesök kontextuella intervjuer och prototyper. Sker på utvecklarnas egen initiativ. Görs ibland bara i slutet av projektet.

Användbarhet

Behov Ett behov kan komma av att man saknar något i kärnverksamheten. Detta anses ofta kunna tillfredsställas genom att utveckla ett system.

Utveckling

Behovsunderlag En specifikation av det behov en beställning av ett system utgår från. Ska förmedla målbild och vision och motivera IT-satsningen.

Artefakter

Beställare Finns på beställarsidan och har till uppgift att formulera behovsunderlaget i samband med beställning. Har olika teknisk kompetens. Beställare är delaktig under hela projektet.

Roll

Beställarsidan Kärnverksamheten på FRA, drar nytta av de levererade systemen från utvecklingsavdelningen för att tillfredsställa sina verksamhetsbehov.

Organisation

Beställning Beställningen beskrivs i ett behovsunderlag. Beställningen föregås av en dialog mellan beställarsidan och utvecklingsavdelningen. En beställare har huvudansvaret för beställningen. Föregås ofta av ett på något sätt uttryckt behov.

Process

Domänkunskap Kunskap om beställarsidans verksamhet. Är till hjälp vid utvecklingen av system om en utvecklare har denna typ av kunskap.

Användbarhet

Förstudie En undersökning av problemställning. Förstudien kan inledas efter att ett behovsunderlag är upprättat. Förstudien kan göras på både utvecklingsavdelningen och på

Artefakter

Bilaga 1: Koncept och dimensioner

36

beställarsidan.

Kompetens Beställarsidan har olika kompetens, vilket påverkar hur mycket stöd de behöver från utvecklingsavdelningen under arbete med behovsunderlag och kravprioritering.

Jämför utbildning.

Organisation

Kontextuella intervjuer Intervjuer som genomförs på den plats där systemet ska implementeras. Genomförs av utvecklare i samband med förstudien.

Användbarhet

Krav Funktioner eller egenskaper som systemet ska ha.

Krav

Kravbild En sammanlagd abstrakt bild av systemets funktioner och egenskaper. Begreppet används ofta när man diskuterar krav. Bilden är tänkt att förmedlas i förstudien.

Krav

Kravinsamling Sker på ett övergripande plan i samband med förstudien, eller i formuleringen av behovsunderlaget. Det är oklart vilka aktiviteter som ingår i detta arbete.

Krav

Kravprioritering För att veta vilka krav som är viktigast bör kraven rangordnas. Ansvaret läggs här på beställarsidan, men görs ofta tillsammans med utvecklarna. Det finns en utbredd uppfattning om att detta arbete är svårt och krävande.

Krav

Kravspecifikation En beskrivning av kraven på systemet. Denna lista kompletteras under projektets gång, allteftersom behoven upptäcks.

Krav

Lösningsförslag Beställaren har ofta ett lösningsförslag i början av beställningen. Detta kan förändras under projektet om det visar sig att det inte uppfyller det ursprungliga behovet.

Krav

Målbild Vad projektet ska uppnå. Kan förändras kraftigt under projektets gång.

Artefakt

Problemställning Det faktiska problem som systemet ska lösa i verksamheten.

Artefakt

Projekt Projekt leds ofta av projektledare. I projekt kan ingå en förstudiegrupp, utvecklingsteam, beställare och användarrepresentanter från beställarsidan. Projekt pågår under en begränsad tid.

Process

Projektgrupp Vanligen fyra till åtta personer som arbetar med ett visst projekt utifrån en viss utvecklingsmetodik.

Roll

Projektledare Har ansvar för att driva projektet framåt. Ansvarar även för projektadministrationen och ser till att projektet följer projektstyrningsmodellen.

Roll

Projektstyrningsgruppen Bemannar projekt med projektledare.

Roll

Projektstyrningsmodell Definierar ramar och resurser för projektarbetet. Upprätthålls av projektledaren. Består av ett antal mallar

Process

Bilaga 1: Koncept och dimensioner

37

och dokument, bland en mall för behovsunderlag.

Prototyp Används i utvecklingen för att representera och testa olika lösningar. Ibland mycket välgjorda.

Användbarhet

Scrummaster Leder det praktiska utvecklingsarbetet vid scrumutvecklingen. Leder scrummöten och bjuder in till sprintdemos.

Roll

Studiebesök Främst för att utvecklare ska kunna utföra användbarhetsarbete och få ökad domänkunskap. Utvecklarna besöker kärnverksamheten (beställarsidan).

Användbarhet

System Den produkt vilken utvecklingsavdelningen ska leverera till beställarsidan. Detta kan vara nyutveckling eller vidareutveckling av befintliga system.

Artefakt

Systemarkitekt En utvecklare kan vara systemarkitekt, och därmed ta ett större ansvar vid utformning av systemets interna arkitektur och uppbyggnad.

Roll

Testare Testar att det utvecklade systemet uppfyller de krav som ställs på det, genom att prova systemet i ett antal testfall. Utvecklare har ofta ansvaret för testning av systemet.

Roll

Utbildning Utvecklarna har olika bakgrund, en del har bakgrund på beställarsidan, många har universitetsutbildning inom datavetenskap och andra är självlärda.

Organisation

Utvecklare Ingår i en projektgrupp. Arbetar med att utveckla system. Bidrar ofta till förstudier, vissa utvecklare har intresse för användbarhetsarbete. Kan göra förstudier, implementera system, göra systemarkitektur, utföra användbarhetsarbete, göra prototyper och utföra tester.

Roll

Utvecklingsavdelningen FRA har en egen utvecklingsverksamhet. Här arbetar utvecklare med olika roller och projektstyrningsgruppen. Dessa utvecklar och levererar system till beställarsidan.

Organisation

Utvecklingsmetodik Har som mål att stödja utvecklingen av ett system. Projektarbetet utgår från en utvecklingsmetodik som beskriver utvecklingsprocessen. Vi har stött på bland annat RUP och Scrum.

Utveckling

Utvecklingsprocessen Processen kan delas in i förstudie, utveckling och driftssättning även om dessa kan ske löpande. Utvecklingsmetodiken föreskriver i vilken ordning aktiviteterna ska genomföras.

Process

Bilaga 2: Konceptuell bild för uppgiftsfördelning i utvecklingsprocessen

38

Bilaga 2: Konceptuell bild för uppgiftsfördelning i utvecklingsprocessen

Bilaga 3: Kravkartan

39

Bilaga 3: Kravkartan

Bilaga 3: Kravkartan

40

Källhänvisningar Kravkartan De flesta rutorna i Kravkartan är inspirerade av metoden Volere (Robertsson, Robertsson 2002 s. 13-14). Rutorna ”Beskriv effektmålen”, ”Användarnas behov”, ”Formulera användningsmål” och ”Grov interaktionsdesign” är inspirerade av Effektstyrning (Ottersten & Balic 2010, s. 75-80).

Referenserna till verktygsraden är följande:

• Love-Hate (Häggberg 2002, s. 6).

• Enkät, FRA-intern enkät för att mäta användarskattning av system.

• PENG (Tonnquist, 2008, s. 52)

• Krysschema (Häggberg 2002, s. 16)

• Future Workshop (Hallberg et al. 2008, s. 41)

• Persona (Preece, Rogers & Sharp, 2007, s 484-5)

• Dokumentbaserade metoder/dokumentanalyser (Hallberg et al. 2008, s. 39)

• Prototyper (Preece, Rogers & Sharp, 2007, s 528-82)

• Intervjuer (Preece, Rogers & Sharp, 2007, s. 307-312)

• Wizard of Oz (Preece, Rogers & Sharp, 2007, s. 535)

• Nulägesdiskussioner - efter kortfattad beskrivning från Kravkonsulten vi intervjuade under studien.

• Indirekt observation (Preece, Rogers & Sharp, 2007, s. 338-342)

• Kontextuella intervjuer (Preece, Rogers & Sharp, 2007, s. 498-9)

• Fokusgrupper (Preece, Rogers & Sharp, 2007, s. 302-3)

• Plupp-metoden (Häggberg 2002, s. 15)

!

Lösn

ings

förs

lag

Här

kan

man

lägg

a lö

snin

gsfö

rsla

g un

der h

ela

proc

esse

ns g

ång.

Syfte

t med

pro

jekt

et

Mål

grup

psan

alys

Anv

ändn

ings

mål

Kor

t bes

kriv

ning

av

verk

sam

hete

n oc

h va

d so

m fö

ranl

eder

be

stäl

lnin

gen

av p

rodu

kten

.

Varf

ör b

ygge

r elle

r inf

örsk

affa

r vi d

en h

är IT

-pro

dukt

en?

Kos

tnad

er o

ch b

espa

ringa

r (R

OI)

På

vilk

et s

ätt g

agna

r det

här

ver

ksam

hete

n ek

onom

iskt

? Va

rför

är p

roje

ktet

vär

t att

geno

mfö

ra?

(PE

NG

!)

Bes

kriv

effe

ktm

ålen

Va

d sk

a pr

oduk

ten

ha fö

r effe

kt p

å ve

rksa

mhe

ten?

Love

-Hat

e G

örs

på b

efin

tligt

sys

tem

, man

får f

ram

vad

som

up

plev

s so

m b

äst o

ch s

ämst

i de

t nuv

aran

de s

yste

met

.

Alla

del

taga

re (v

arfö

r int

e al

la p

å av

deln

inge

n?) f

år

post

its i

olik

a fä

rger

, där

röd

är k

ärle

k oc

h bl

å ha

t. M

an

får s

edan

skr

iva

det m

an ty

cker

om

på

röda

lapp

ar o

ch

sätta

där

det

pas

sar p

å sy

stem

et e

ller d

ess

omgi

vnin

g.

Blå

lapp

ar s

ätts

på

sake

r man

hat

ar.

Res

ulta

ten

sam

man

stäl

ls o

ch d

isku

tera

s.

Vad

är e

gent

ligen

pro

blem

et?

Inte

säl

lan

tror m

an a

tt IT

kan

lösa

alla

pro

blem

, men

inna

n m

an g

er s

ig

in i

en lå

ng o

ch k

osts

am IT

-pro

jekt

erin

g m

åste

man

var

a rä

tt sä

ker p

å va

d so

m e

gent

ligen

är p

robl

emet

, och

vad

som

är l

ösni

ngen

på

det s

om

egen

tlige

n är

pro

blem

et.

Tips

: Lov

e H

ate,

Kon

text

uella

inte

rvju

er. F

råga

var

för,

varfö

r, va

rför?

. P

roce

sska

rtläg

gnin

g.

Utv

eckl

ings

avde

lnin

gen

har e

n vä

l utv

eckl

ad e

nkät

som

kan

gen

omfö

ras

för a

tt få

fram

det

nuv

aran

de s

yste

met

s up

plev

da a

nvän

dbar

het o

ch v

ad

man

tyck

er o

m d

et. (

15 m

inut

er/a

nstä

lld)

Den

här

enk

äten

kan

ock

så a

nvän

das

som

ett

effe

ktm

ål –

där

man

mät

er

hur a

nvän

darn

a up

plev

er ä

ven

den

nya

prod

ukte

n.

Kan

någ

on a

nnan

hjä

lpa

till?

Intr

esse

nter

, pro

dukt

en

Vilk

a är

anv

ända

rna

av produkten

på

FRA

(med

kun

der)

?

Vem

ska

ta h

and

om s

yste

met

?

Vem

ska

bet

ala

för s

yste

met

?

Vem

i pr

ojek

tet a

nsva

rar f

ör a

ttt P

UL

och

andr

a la

gar u

ppfy

lls?

Vem

ans

vara

r för

eko

nom

i och

resu

rser

?

Vem

stå

r för

stra

tegi

ska

IT-m

ål?

Vilk

a är

anv

ända

re?

Prim

äran

vänd

are

(dag

liga)

: S

älla

nanv

ända

re:

Drif

tspe

rson

al:

Ext

erna

kun

der:

Hur

ska

de

delta

i fö

rstu

diep

roce

ssen

? "  A

nvän

darr

epre

sent

ante

r (20

% a

rbet

stid

, en

elle

r två

per

sone

r)

"  P

roto

typw

orks

hop

(2 h

/del

taga

re, f

örbe

rede

lse

4 h)

"  T

estn

ing

av p

roto

type

r (ut

värd

erin

gar)

1 h

/del

taga

re

"  A

nvän

darte

ster

1 h

/del

taga

reE

kono

mis

ka a

vdel

ning

ar

"  L

önea

vdel

ning

en

"  A

ndra

…

"  K

onte

xtue

lla in

terv

juer

(1 h

/del

taga

re)

"  D

elta

gand

e ob

serv

atio

n (a

nstä

llda

kan

arbe

ta s

om v

anlig

t)

Om

krin

g tre

av

dess

a m

etod

iker

är l

ämpl

iga

i del

fles

ta p

roje

kt

Påve

rkan

på

befin

tliga

sy

stem

Vilk

a nu

vara

nde

syst

em o

ch p

roce

sser

på

verk

as a

v de

tta n

ya s

yste

m?

Ers

ätte

r man

ett

gam

mal

t sys

tem

? Fi

nns

det b

eroe

nden

till

detta

gam

la

syst

em?

Hur

mät

er n

i att

effe

kten

är u

ppnå

dd?

Tips

: Gör

tabe

ll. F

å el

ler m

ånga

mål

?

Tips

: vad

hän

der u

nder

ett

år?

Res

ursa

lloke

ring

Hur

myc

ket r

esur

ser t

ror d

u pr

ojek

tet k

omm

er a

tt kr

äva?

P

erso

nal o

ch e

kono

mis

ka re

surs

er, e

n up

pska

ttnin

g.

Intr

esse

nter

, pro

jekt

et

Vilk

a ko

mm

er a

tt be

höva

var

a de

lakt

iga

elle

r påv

erka

s un

der p

roje

ktet

s gå

ng?

Vilk

a ko

mm

er b

evak

a pr

ojek

tet?

"  _

____

____

____

____

____

____

_

"  _

____

____

____

____

____

____

_

"  _

____

____

____

____

____

____

_ "  _

____

____

____

____

____

____

_

"  A

nvän

darn

a på

avd

elni

ngar

na …

…

"  L

önea

vlde

ning

en…

Tips

: vad

hän

der u

nder

ett

år?

PEN

G

Enkä

t

Det

finn

s en

har

en

lätti

fylld

enk

ät s

om

på e

tt ko

ncen

trera

t sät

t sam

man

stäl

ler

info

rmat

ion

om e

tt vi

sst s

yste

ms

kval

itete

r. Fö

rdel

en ä

r att

man

får e

tt ko

nsta

nt m

ått p

å an

vänd

barh

et s

om

kan

mät

as ö

ver l

ängr

e tid

.

Intr

esse

nt 1

, che

fen…

#

Ris

ker i

pro

jekt

et

Beh

ovsu

nder

lag

- Elle

r vad

är p

robl

emet

?

Tips

: FR

AP

S-m

alle

n fö

r beh

ovsu

nder

lag,

den

ge

r myc

ket s

töd

i for

mul

erin

garn

a.

Lagm

ässi

ga k

rav

Lagm

ässi

ga k

rav

Tips

: Ta

en fi

ka m

ed J

UR

, och

ski

cka

beho

vsun

derla

get m

ed n

ågon

idé

om

lösn

ing,

så

kan

de g

öra

en p

relim

inär

bed

ömni

ng o

m y

tterli

gare

utre

dnin

g be

hövs

.

Gro

v fu

nder

ing

krin

g vi

lka

laga

r som

kan

påv

erka

sys

tem

et. K

rav

för a

tt pr

oduk

ten

ska

leva

upp

till

gälla

nde

laga

r och

föro

rdni

ngar

.

Kra

v på

efte

rfölja

nde

av s

tand

arde

r. In

gen

lagb

ok lä

r beh

övas

.

Proj

ekte

ts o

mfa

ttnin

g

Tips

: Sam

la e

tt br

ett s

pekt

rum

av

män

nisk

or o

ch s

ätt p

last

på

vägg

arna

och

bö

rja ri

ta. F

örsö

k få

en

enad

syn

på

hur d

et s

er u

t ida

g. T

ips:

Gå

och

inte

ru

nt o

ch in

terv

jua

folk

, för

då

kom

mer

du

inte

få ih

op d

in b

ild a

v ve

rksa

mhe

ten.

Nul

äge

(vilk

a sy

stem

finn

s, h

ur a

nvän

ds d

e, h

ur h

änge

r de

sam

man

, hur

fu

nger

ar o

rgan

satio

nen)

. Sys

tem

ets

bruk

smilj

ö. T

änk

ut v

ilka

arbe

tsup

pgift

er d

et fr

amtid

a sy

stem

et s

ka lö

sa (s

om id

ag g

örs

på n

ågot

an

nat s

ätt).

Plan

erin

g G

ör e

n pr

ojek

tpla

nerin

g oc

h fu

nder

a öv

er v

ad

som

ska

ingå

i va

rje fa

s.

Fram

tida

prob

lem

Vi

lka

pote

ntie

lla fr

amtid

a pr

oble

m fi

nns

med

det

nya

sy

stem

et. V

ad få

r det

för e

ffekt

er p

å

-  N

uvar

ande

sys

tem

milj

ö

-  In

stal

lera

de s

yste

m

- - a

nvän

darn

as a

rbet

smilj

ö

-  be

grän

sing

ar i

impl

emen

tatio

nsm

iljön

som

kan

på

verk

a pr

oduk

ten?

- 

Pot

entie

llt o

hant

erin

glig

a pr

oble

m

!Fa

kta

och

anta

gand

en

Sena

re…

Ö

ppna

fråg

or

# #

#

Kom

plet

tera

intr

esse

ntlis

tan!

Giv

na fö

ruts

ättn

inga

r Lö

snin

gsbe

gräs

ning

ar

Nuv

aran

de s

yste

mm

iljö

Med

pro

dukt

en s

amve

rkan

de a

pplik

atio

ner

Mju

kvar

a O

ff-th

e-sh

elf

Förv

änta

d ar

bets

milj

ö

Tids

begr

änsi

ngar

E

kono

mis

ka b

egrä

nsni

ngar

$

Anv

ända

rnas

beh

ov

Hur

säk

erst

älle

r du

att a

nvän

darn

as b

ehov

upp

fylls

? S

e lis

tan

i ste

g 1.

Titt

a i a

nvän

ding

s- o

ch b

ehör

ighe

tslo

ggar

! Gör

or

dent

lig a

naly

s.

Stu

dieb

esök

, kon

text

uella

inte

rvju

er. H

är b

ehöv

s M

DI-

kom

pete

ns. L

äs p

å w

ikip

edia

!

Anv

ända

rnas

kom

pete

ns

Tips

: Obs

erva

tione

r och

kon

text

uell

inte

rvju

Hur

ska

man

intro

duce

ra e

tt ny

tt sy

stem

för a

nvän

darn

a?

Beh

övs

myc

ket i

ntro

dukt

ion?

Futu

re w

orks

hop

Gen

om a

tt fö

rest

älla

sig

en

alte

rnat

iv fr

amtid

kan

man

få fr

am lö

snin

gar

med

fram

tiden

s te

knol

ogi.

Inte

säl

lan

går d

e fö

resl

agna

lösn

inga

rna

att

anpa

ssa

till d

agen

s te

knol

ogi.

Gör

att

delta

garn

a sl

ippe

r tän

ka p

å te

knis

ka

begr

änsn

inga

r.

1. In

trod

ucer

a de

ltaga

rna

i sch

emat

för d

agen

och

vilk

a re

gler

som

gäl

ler.

2. K

ritik

fase

n: D

en a

ktue

lla p

robl

emst

älln

inge

n un

ders

öks

nogg

rant

och

kr

itisk

t. Fö

rst g

enom

förs

en

visu

alis

erad

bra

inst

orm

ing

och

en p

robl

em

hitta

s. D

okum

ente

ra! D

etta

pro

blem

kan

inte

säl

lan

skriv

as ra

kt in

i be

hovs

unde

rlage

t. 3.

Fan

tasi

fase

n: A

lla d

elta

gare

form

uler

ar e

n ut

opi,

för a

tt rit

a en

öv

erdr

iven

bild

av

fram

tida

möj

lighe

ter.

Gen

omfö

rs fö

rsla

gsvi

s fö

rst i

m

indr

e gr

uppe

r för

att

seda

n pr

esen

tera

resu

ltate

n fö

r var

andr

a oc

h fö

rstä

rka

och

bygg

a på

var

andr

as id

éer.

Dok

umen

tera

!

4. Im

plem

enta

tions

fase

n: S

åväl

anv

ända

re s

om u

tvec

klar

e ka

n de

lta

och

titta

på

vad

av lö

snin

garn

a so

m ä

r gör

bara

reda

n id

ag, o

ch v

ad s

om

är p

rakt

iskt

gen

omfö

rbar

t.

Pers

ona

Per

sona

s är

ett

sätt

att k

omm

unic

era

anvä

ndar

e av

sys

tem

et

för u

tvec

klar

e. D

e sk

a vi

sa a

nvän

dare

n be

hov

och

mot

iv,

tank

en ä

r att

man

som

utv

eckl

are

kan

”pro

vkör

a” p

rogr

amm

et

som

olik

a an

vänd

arpr

ofile

r. (H

ur m

an g

ör?

Fråg

a …

.

Funk

tione

lla k

rav

och

data

K

ort b

eskr

ivni

ng a

v ve

rksa

mhe

ten

och

vad

som

föra

nled

er

best

älln

inge

n av

pro

dukt

en.

Varfö

r byg

ger e

ller i

nför

skaf

far v

i den

här

IT-p

rodu

kten

?

Kra

v på

kva

litet

oc

h in

föra

nde

Alte

rnat

iva

prod

uktu

form

ning

ar s

ka g

enom

lysa

s oc

h al

tern

ativ

a fo

rmer

fö

r anv

ända

rgrä

nssn

ittet

har

gåt

ts ig

enom

. Det

ta v

erifi

eras

bäs

t i

anvä

ndar

test

. Kra

v på

pro

dukt

egen

skap

er o

ch k

valit

etsm

ål fi

nnas

med

. A

nvän

dbar

hets

krav

är k

rav

på b

etee

nde

då p

rodu

kten

anv

änds

.

Tips

: Ta

fram

min

st tv

å, g

ärna

fler

lösn

inga

r (ta

gär

na in

anv

ända

rnas

id

éer g

enom

futu

re w

orks

hops

men

anv

änd

eget

om

döm

e). P

rova

lö

snin

garn

a ge

nom

finu

rligt

utfo

rmad

e an

vänd

arte

ster

, då

bruk

ar d

et

mär

kas

snab

bt v

ilka

lösn

inga

r som

fakt

iskt

fung

erar

. R

äkna

med

att

det b

ehöv

s åt

min

ston

e tv

å ite

ratio

ner,

se ti

ll at

t anp

assa

pr

otot

yper

na e

fter d

et –

pap

per s

tuln

a ur

skr

ivar

en o

ch b

lyer

tspe

nnor

fu

nger

ar n

ästa

n al

ltid

ovän

tat b

ra.

Vill

man

gör

a pr

otot

yper

på

dato

rn fu

nger

ar o

fta P

ower

poin

t utm

ärkt

–

ofta

blir

det

pre

cis

så fu

lt at

t man

förs

tår h

ur d

et ä

r tän

kt, u

tan

att d

et ä

r en

färd

ig p

rodu

kt. D

en b

ehöv

er in

te fu

nger

a.

Pres

tand

akra

v

• Sna

bbhe

t och

late

ncyk

rav

• Kra

v på

pre

cisi

on o

ch n

oggr

annh

et

• Kra

v på

tillg

ängl

ighe

t och

upp

tid (9

9%?

99.9

9999

%?

Red

udan

s?)

• Rob

usth

et o

ch k

rav

på fe

ltole

rans

• Kap

acite

tskr

av

• Kra

v på

ska

lbar

het o

ch u

tökn

inga

r

• För

vänt

ad li

vslä

ngd

på s

yste

met

Mål

med

det

ta s

teg:

Vi

lka

krav

har

vi p

å pr

oduk

ten?

Tek

nisk

a kr

av s

åväl

so

m a

nvän

dbar

hets

krav

. D

et h

ar b

livit

dags

att

spec

ifice

ra:

Valid

erad

Prin

cipl

ösni

ng

Dok

umen

tbas

erad

e m

etod

er

Rim

lighe

ts-

utvä

rder

ing

av

Prod

uktid

én

Inte

rvju

er

Var t

vå n

är n

i int

ervj

uar,

en s

om s

kriv

er o

ch e

n so

m

fråga

r. O

ftast

kom

mer

den

man

inte

rvju

ar ig

ång

efte

r 20

min

uter

, så

de fö

rsta

min

uter

na ä

r bo

rtkas

tade

alld

eles

oav

sett,

och

allt

vik

tigt s

ägs

när i

nter

vjue

n är

kla

r. Ju

mer

dat

a m

an h

ar, d

esto

läng

re ti

d ta

r det

att

beha

ndla

dat

at, s

å kl

ura

noga

på

vilk

a frå

gor o

ch

ämne

n so

m ä

r de

intre

ssan

ta, m

en v

ar b

ered

d at

t än

dra

dina

fråg

or o

m in

terv

jupe

rson

en k

omm

er

med

nya

fråg

or.

Indi

rekt

obs

erva

tion

Dag

böck

er

Logg

ar

Kul

ture

lll p

rob

Bli

dete

ktiv

och

klu

ra u

t vad

anv

ända

rna

egen

tlige

n ha

r för

sig

i pr

ogra

mm

et. A

nvän

d al

la ti

ll bu

ds s

tåen

de

med

el –

öve

rvak

ning

skam

eror

, kol

la lo

ggar

(elle

r läg

g in

i pr

ogra

mm

et),

be d

em s

kriv

a da

gböc

ker,

skic

ka u

t ku

lture

lla p

robe

r (på

sar s

om a

nvän

darn

a ka

n lä

gga

i sa

ker s

om ä

r vik

tiga

från

dera

s an

vänd

arm

iljö)

. Allt

är

möj

ligt.

Dok

umen

tera

ord

entli

gt. N

i kan

det

här

.

Tids

plan

erin

g, k

alen

der b

udge

t re

surs

, arb

etst

id

Går

det

att

få fr

am a

lla d

el re

surs

er s

om k

rävs

.

Finn

s de

t möj

lighe

t att

allo

kera

resu

rser

na, h

ur o

ch n

är?

Nyc

kelp

erso

ner

Ber

äkna

t ant

al m

antim

mar

(glö

m in

te te

st o

ch s

å)

Kal

ende

rtid

– be

räkn

ad lö

ptid

för p

roje

ktet

, sta

rtdat

um e

tc.

Beh

ovsu

nder

lag

Mål

med

det

ta s

teg

Här

ska

du

skap

a et

t und

erla

g så

att

besl

ut k

an

fatta

s om

IT i

det h

är fa

llet

kan

anvä

ndas

för a

tt fö

ränd

ra e

ller f

örbä

ttra

verk

sam

hete

n.

Bes

tälla

re, g

ärna

i sa

mrå

d m

ed a

vd T

ska

byg

ga e

tt:

Initi

al m

ålgr

upps

sana

lys

Bes

lut o

m fö

rstu

die

har t

agits

, och

förs

tudi

en in

leds

i:

Mål

med

det

ta s

teg:

H

är ä

r man

öve

rtyg

ad o

m a

tt IT

kan

åst

adko

mm

a en

fö

rbät

trin

g i v

erks

amhe

ten,

resu

rser

för e

n fö

rstu

die

finns

tilld

elad

e et

c…

Per

sona

s

Varfö

r jus

t nu?

Vad

händ

er o

m m

an in

te g

ör d

et n

u?

Uts

eend

emäs

siga

kra

v Fi

nns

det n

ågra

kra

v på

hur

pro

dukt

en s

ka s

e ut

?

Vad

ska

det f

inna

s fö

r kän

sla

elle

r stil

öve

r den

?

Ska

sys

tem

et p

assa

ihop

med

någ

ot a

nnat

som

har

ett

spec

iellt

uts

eend

e?

Prod

ukte

ns o

mfa

ttnin

g P

rodu

ktbe

grän

snin

gar (

Vad

ska

prod

ukte

n IN

TE k

lara

?)

List

a öv

er a

nvän

dnin

gsfa

llen

Indi

vidu

ella

anv

ändn

ings

fall

Tips

: Vän

d på

ste

ken

och

fråga

dig

: om

sys

tem

et h

ade

en

enda

funk

tion,

vilk

en s

kulle

det

då

vara

?

Förv

altn

ing

och

supp

ort

Kra

v på

förv

altn

ing

(80%

av

kost

nade

n på

ett

syst

em ä

r fö

rval

tnin

gsko

stna

d. K

an m

an m

insk

a de

n? V

ad få

r det

kos

ta?)

Kra

v på

sup

portb

arhe

ten

Kra

v på

anp

assn

ings

barh

et

Dok

umen

atio

n oc

h ut

bild

ning

av

anvä

ndar

e H

ur m

ycke

t utb

ildni

ng b

ehöv

er a

nvän

darn

a?

Hur

kon

takt

ar n

i anv

ända

rna?

Har

de

olik

a an

vänd

argr

uppe

rna

olik

a ko

mpe

tens

/dat

orva

na?

Kom

mer

de

olik

a an

vänd

argr

uppe

rna

anvä

nda

syst

emet

på

olik

a sä

tt?

Hur

ska

anv

ända

rman

uale

n ut

form

as?

Är s

yste

met

lärb

art?

Säke

rhet

skra

v K

rav

på a

cces

s K

rav

på d

atai

nteg

ritet

och

info

rmat

ions

säke

rhet

Kra

v på

per

sonl

ig in

tegr

itet o

ch la

grum

Kra

v vi

d sä

kerh

etsr

evid

erin

g/ac

kred

iterin

g K

rav

på s

tark

t ”im

mun

förs

var”

Kul

ture

llt b

etin

gade

oc

h po

litis

ka k

rav

Hur

ser

riks

dage

n på

sys

tem

et?

Hur

ser

en

vanl

ig s

vens

k på

sys

tem

et?

Hur

ser

ledn

inge

n på

sys

tem

et?

Finn

s de

t någ

ot s

om ä

r pol

itisk

t kän

slig

t?

[Pro

jekt

ledn

ing]

Prot

otyp

er

Bör

ja a

lltid

med

så

enkl

a pr

otot

yper

som

möj

ligt.

Gör

dem

tidi

gt

i pro

cess

en.

Pal

m p

ilot b

örja

de s

om tr

äbit,

App

lepr

oduk

ter b

ruka

r bör

ja s

om

över

tejp

ade

vide

okas

sette

r och

bat

terie

r. P

roto

type

rna

ska

vara

enk

la a

tt ka

sta

bort,

men

ska

gå

att d

isku

tera

krin

g.

Ju lä

ngre

in i

proc

esse

n, d

esto

mer

lik

slut

prod

ukte

n bl

ir pr

otot

ypen

. Sat

sa p

å at

t i v

arje

spr

int u

tvär

dera

en

prot

otyp

.

Form

uler

a an

vänd

ings

mål

Fö

r att

spec

ifice

ra m

ätba

r anv

ändb

arhe

t: fö

ljand

e in

form

atio

n be

hövs

• En

besk

rivni

ng a

v an

vänd

aren

s m

ål o

ch in

tent

ione

r • E

n be

skriv

ning

av

anvä

ndni

ngss

amm

anha

nget

, inb

egrip

et

anvä

ndar

e, u

ppgi

ftern

a, u

trust

ning

en o

ch m

iljöe

rna.

• M

ålen

elle

r fak

tiska

vär

den

för ä

ndam

ålse

nlig

het,

effe

ktiv

itet

och

tillfr

edss

tälle

se i

det a

vsed

da a

nvän

dnin

gsam

man

hang

et.

Fulls

tänd

ig li

sta

på

funk

tione

lla k

rav

Mig

rerin

g til

l ny

prod

ukt

Kra

v på

mig

ratio

n til

l ny

prod

ukt.

• Inf

orm

atio

n til

l anv

ända

rna

• Tes

ter a

v m

igra

tione

r

• Kan

det

gör

as e

tapp

vis?

• H

ur m

ycke

t ska

ni ö

vers

katta

tide

n oc

h pr

oble

men

som

ko

mm

er a

tt up

pstå

? • H

ur få

r anv

ända

rna

mer

stö

d un

der m

igra

tions

tiden

? K

olla

med

der

as c

hef!

• Dat

a so

m k

omm

er k

räva

kon

verte

ring

Gro

v in

tera

ktio

nsde

sign

D

e vi

ktig

aste

flöd

ena

ska

vara

bes

kriv

na ti

ll fu

llo. Ö

vrig

a de

lar a

v pr

oduk

ten

ska

vara

öve

rsik

tligt

bes

kriv

na m

en s

amtli

ga fu

nktio

ner s

ka h

a bå

de v

isue

ll oc

h te

xtue

ll be

skriv

ning

. S

e de

t som

en

ritni

ng fö

r int

erak

tione

n. F

ärg

ska

bara

finn

as m

ed o

m d

et ä

r vik

tigt

för p

rodu

kten

. D

en v

isue

lla in

tera

ktio

nsrit

ning

en m

åste

test

as m

ed a

nvän

darn

a (s

kriv

ut d

en o

ch

låt a

nvän

darn

a pe

ka o

ch k

licka

med

fing

ret o

ch b

yt p

appe

r) o

ch fö

rkla

ra v

ad s

om

händ

er.

Man

ska

kun

na u

ppvi

sa h

ur m

an u

ppnå

r öns

kade

effe

kter

(för

dela

r) m

ed d

en h

är

desi

gnen

, i e

nlig

het m

ed e

ffekt

mål

. Går

det

sna

bbar

e? K

an m

an u

tföra

upp

gifte

n m

ed h

ögre

pre

cisi

on ä

n tid

igar

e?

Prin

cipl

ösni

ng g

odkä

nd

Beg

repp

sord

lista

B

örja

skr

iv d

efin

ition

er p

å ol

ika

begr

epp

som

ni a

nvän

t und

er

förs

tudi

en. B

örja

till

exem

pel m

ed a

nvän

darn

as o

lika

rolle

r, oc

h ce

ntra

la b

egre

pp i

verk

sam

hete

n.

förf

ina

vald

lösn

ing

Mål

med

det

ta s

teg

Efte

r att

ha v

alt o

ch v

raka

t bla

nd a

lla fi

na

lösn

ings

förs

lag

är d

et d

ags

att b

estä

mm

a va

d pr

oduk

ten

ska

inne

hålla

.

Nu

har v

i val

t lös

ning

, och

det

är d

ags

för a

tt

Wiz

ard

of O

z P

reci

s so

m tr

ollk

arle

n i f

ilmen

, spe

lar m

an

mas

kine

n, a

ntin

gen

med

elle

r uta

n an

vänd

aren

s ve

tska

p. D

et g

år ti

ll ex

empe

l at

t gör

a ge

nom

att

styr

a po

wer

poin

tslid

es

med

an a

nvän

dare

n in

tera

gera

r med

sy

stem

et p

å en

fris

tåen

de s

kärm

, men

m

an k

an ä

ven

gene

rera

rapp

orte

r elle

r sö

kres

ulta

t i re

altid

, elle

r väl

ja fr

ån

förb

ered

da v

yer

Kry

ssch

ema

Hej

och

vä

lkom

men

! N

u ty

cker

du

kans

ke a

tt de

t här

ve

rkar

lite

myc

ket i

nfor

mat

ion

för

att g

öra

en fö

rstu

die.

Det

som

är

bra

är a

tt du

inte

beh

över

gör

a al

lting

!

Anv

änd

plup

pmet

oden

(!) f

ör a

tt be

stäm

ma

vad

ni s

ka g

öra!

Ett

tips

är a

tt lå

ta v

arje

tim

me

ni h

ar

på p

roje

ktet

repr

esen

tera

s av

en

plup

p oc

h sä

tta p

lupp

ar p

å de

sa

ker n

i tän

kte

göra

.

Här

ska

tekn

iska

funk

tions

krav

och

anv

ändn

ings

krav

finn

as

besk

rivna

.

Förh

oppn

ings

vis

har m

an h

är re

dan

en g

ansk

a br

a bi

ld a

v vi

lka

krav

som

bor

de s

tälla

s på

pro

dukt

en –

sam

man

stäl

l dem

i lä

mpl

igt v

erkt

yg, m

en b

örja

gär

na m

ed p

ost-i

tlapp

ar n

är n

i di

skut

erar

dem

. Arb

eta

inte

ens

am.

Sna

bbko

ll

• Är k

rave

t tyd

ligt?

• Ä

r mål

grup

pen

och

nytta

n fö

r mål

grup

pen

uppe

nbar

?

• Fin

ns e

n pr

iorit

etso

rdni

ng v

ilka

krav

som

är v

iktig

ast?

• Har

ni i

nte

för m

ånga

kra

v?

Be

gärn

a nå

gon

utom

ståe

nde

titta

på

krav

en. D

en p

erso

nen

ska

utifr

ån k

ravd

okum

enta

tione

n ku

nna

svar

a på

• Vilk

a kr

av s

om ä

r mes

t cen

trala

• V

ilka

krav

som

här

rör t

ill v

ilken

anv

ända

re

• Vilk

a kr

av p

å fu

nktio

ner m

an k

an ta

i se

nare

ske

den

av

impl

emen

tatio

nen.

"

Allt

bör

jar m

ed e

tt be

hov.

Va

nlig

tvis

är d

et n

ågon

som

är s

ur

för a

tt nå

got f

unge

rar d

ålig

t. In

nan

man

hop

par p

å lö

snin

gar,

mås

te m

an fa

ktis

kt ta

reda

på

vad

det ä

r som

fung

erar

dål

igt,

och

vad

beho

vet p

å et

t nyt

t sys

tem

är.

Det

är s

vårt

och

tar t

id, m

en v

i har

gj

ort e

n gu

die

här t

ill h

öger

.

Här

ska

det

stå

vad

den

" b

eror

på.

Vad

är

beho

vet?

Vad

fatta

s ve

rksa

mhe

ten,

eg

entli

gen?

Anv

änd

affis

chen

pr

ecis

som

du

vill

– rit

a på

den

elle

r sät

t pos

tits

elle

r klip

p sö

nder

den

oc

h an

vänd

ruto

rna

som

task

s. T

anke

n är

at

t alla

inbl

anda

de i

syst

emut

veck

lings

-pr

oces

sen

får e

n öv

erbl

ick

över

vilk

a sa

ker m

an fö

rr e

ller

sena

re k

omm

er s

töta

på

alld

eles

oav

sett.

%

&

Den

bäs

ta

lösn

inge

n

Off-

the-

shel

flösn

inga

r

"  C

lasO

hlso

n-ka

talo

gen

"  E

lfa-k

atal

ogen

" D

ustin

.se

"  W

ikip

edia

"  F

resh

mea

t.net

"  D

ina

kolle

gor

"  W

hite

boar

d i k

orrid

oren

Om

du

fick

1000

0 kr

att

för a

tt lö

sa p

robl

emet

med

hjä

lp a

v pr

oduk

ter e

ller l

ösni

ngar

från

hur l

ångt

sku

lle d

u ko

mm

a då

?

Metoder &

?

K

in

SW

OT:

S

treng

ths

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

.

Wea

knes

ses

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. O

ppor

tuni

ties

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

.

. . .

Thre

ats

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

!

Kra

v på

bru

ksm

iljön

Fö

rvän

tad

fysi

sk b

ruks

milj

ö K

rav

på s

amve

rkan

med

när

ligga

nde

syst

em

Kra

v på

rele

asef

örfa

rand

et

Kra

v på

tillg

ängl

ighe

t K

räve

r sys

tem

et fu

llgod

färg

syn?

K

räve

r sys

tem

et v

äldi

gt s

mid

iga

händ

er fö

r ta

ngen

tbor

dsko

mbi

natio

nern

a?

Krä

ver s

yste

met

bra

syn

för l

iten

text

elle

r svå

riden

tifie

rade

sy

mbo

ler?

K

räve

r sys

tem

et s

ärsk

ilt b

ra h

örse

l? K

an m

an a

nvän

da

syst

emet

med

hör

seln

edsä

ttnin

g?

Är s

nabb

kom

man

dona

erg

onom

iska

?

Ris

kera

r man

bel

astn

ings

skad

or?

Kan

en

fysi

skt f

unkt

ions

hind

rad

pers

on a

nvän

da p

rodu

kten

?

Form

uler

a an

vänd

ning

smål

H

ur s

ka p

rodu

kten

fung

era

för a

tt til

lgod

ose

anvä

ndar

nas

beho

v? F

råga

inte

vad

anv

ända

rna

vill

ha u

tan

stäl

l er s

jälv

a frå

gan

vad

anvä

ndar

na b

ehöv

er. U

tgå

från

er m

ålgr

upps

anal

ys

och

ha e

r per

sona

i ba

khuv

udet

.

Exe

mpe

l (O

rder

mot

tagn

ings

syst

em):

Anv

ändn

ings

mål

1:O

rder

mot

taga

re s

ka fö

redr

a sy

stem

et

fram

för p

enna

och

pap

per.

Anv

ändn

ings

mål

2: O

rder

mot

taga

re v

ill h

a fä

rre

oful

lstä

ndig

a or

drar

.

Nul

äges

disk

ussi

oner

O

fta ä

r det

lite

okl

art h

ur p

roce

sser

ser

ut.

Att

alla

inbl

anda

de h

ar o

lika

syn

på v

ad

man

ege

ntlig

en g

ör, g

ör a

tt tra

ditio

nella

indi

vidu

ella

inte

rvju

er b

lir e

tt re

digt

de

tekt

ivar

bete

som

kan

ske

är s

å fy

llt a

v m

otsä

ttnin

gar a

tt m

an in

te k

omm

er fr

am ti

ll nå

got s

ubst

ansi

ellt.

Leda

ren

för a

ktiv

itete

n fö

rber

eder

sig

så

gott

det g

år m

ed d

okum

ent o

ch b

efin

tliga

pr

oces

skar

tor f

ör a

tt ha

en

bild

på

hur d

et m

öjlig

en g

år ti

ll.Va

r i e

tt ru

m fy

llt a

v w

hite

boar

dtav

lor,

elle

r ska

ffa s

jälv

häfta

nde

plas

t frå

n ...

på

vilk

en m

an k

an ri

ta o

ch

fäst

a po

st-it

s. L

åt s

edan

var

och

ber

ätta

sin

del

av

proc

esse

n oc

h va

d so

m in

går,

och

förs

ök ti

llsam

man

s pu

ssla

ihop

en

sam

lad

bild

av

vad

som

ege

ntlig

en h

ände

r. S

e til

l att

alla

får k

omm

a til

l tal

s, g

å ig

enom

var

je p

erso

n oc

h be

kräf

ta i

slut

et.

Dok

umen

tera

. Grå

t och

tand

agni

ssla

n. B

örja

på

små

dela

r och

ska

la u

pp m

etod

en

efte

r han

d.

Välj

lösn

ing

'

(

)

*

+

,

-

Användartestning

Tids

estim

at: …

……

…..

h Ti

dses

timat

: ……

……

.. h

Tids

estim

at: …

……

…..

h Ti

dses

timat

: ……

……

.. h

Kra

vkar

tan

1.1

'

*

,

-

OK

Bygg om och användartesta

OK

*

Gör

enk

la p

roto

type

r av

lösn

ings

förs

lage

n oc

h an

väda

rtest

a de

m fö

r att

tills

lut v

älja

den

bäs

ta

lösn

inge

n. J

u en

klar

e pr

otot

yper

des

to fl

er lö

snin

gar h

inne

r man

test

a –

och

så ä

r de

ju

enkl

are

att s

läng

a bo

rt se

n. E

tt tip

s är

att

anvä

nda

lo-fi

-pro

toty

per.

Pap

per-

elle

r kar

tong

prot

otyp

er

Klic

kbar

pro

toty

p, e

xem

pelv

is P

ower

poin

t

Ans

varig

: ……

……

……

..

Sät

t sam

man

en

grup

p på

5-8

per

sone

r so

m ä

r ins

atta

i ve

rksa

mhe

ten

och

har

kuns

kap

om p

roje

ktet

. Li

sta

alla

tänk

bara

pos

itiva

effe

kter

för

såvä

l för

etag

et o

ch a

nstä

llda

som

för

kund

erna

.

Sät

t en

unge

färli

g pr

isla

pp p

å va

rje n

ytta

. S

umm

era

värd

ena

för a

tt få

fram

en

brut

tony

tta.

Jäm

för b

rutto

nytta

med

de

sam

man

lagd

a ko

stna

dern

a fö

r sjä

lva

inve

ster

inge

n sa

mt

tillk

omm

ande

kos

tnad

er.

/Pro

jekt

ledn

ing,

Bo

Tonn

quis

t

Fel o

ch a

vvik

else

r H

ur s

tor a

ndel

fel o

ch a

vvik

else

r kan

man

tole

rera

i sy

stem

et?

Hur

han

tera

s de

tta?

Hur

sto

r män

gd a

vvik

else

r kla

rar d

en p

erso

nal s

om ä

r sat

t att

hant

era

dess

a?

Går

det

att

få fr

am a

lla d

el re

surs

er s

om k

rävs

?

Anv

ända

rtes

ter

Des

sa a

nvän

dare

ska

kom

ma

på m

ina

anvä

ndar

test

er:

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

.

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

.

" J

ag h

ar k

öpt f

ika

till d

e an

vänd

are

som

stä

ller u

pp

Rim

lighe

tsut

värd

erin

g av

pr

oduk

tidén

S

amm

anst

äll d

en d

ata

du h

ittill

s ha

r och

gör

en

rimlig

hets

utvä

rder

ing

av p

rodu

ktid

én. T

a hä

nsyn

till

så m

ånga

as

pekt

er s

om m

öjlig

t; ek

onom

iskt

, res

ursm

ässi

gt,

verk

sam

hets

mål

och

så

vida

re.

Ans

varig

: ……

……

……

.. A

nsva

rig: …

……

……

…..

Ans

varig

: ……

……

……

..

Pap

per,

tejp

och

pen

na

Pow

erpo

int

Whi

tebo

ard

HTM

L O

K

Plup

pmet

oden

Grö

n pl

upp

bety

der k

lar

Blå

plu

pp b

etyd

er s

ådan

t som

inte

be

rör p

roje

ktet

/pro

dukt

en

Gul

bet

yder

initi

erat

– s

ka g

öras

.

Röd

plu

pp b

etyd

er p

robl

em/o

klar

t

Stat

uspl

uppa

r

Utv

eckl

ings

avde

lnin

gs fä

rg

Bes

tälla

rens

färg

Tids

plup

p

Pla

cera

ut T

idsp

lupp

ar e

fter h

ur m

ånga

tim

mar

du

ska

göra

de

olik

a bo

xarn

a. D

et g

er ty

dlig

an

svar

sför

deln

ing.

A

llt e

fters

om u

ppgi

ftern

a bl

ir fä

rdig

a –

mar

kera

med

st

atus

plup

par.

Det

gör

att

man

sna

bbt s

er o

m d

et

finns

pro

blem

elle

r okl

arhe

ter n

ågon

stan

s.

Box

ar s

om p

roje

ktet

/pro

dukt

en e

j ber

örs

av

mar

kera

s lä

mpl

igen

med

blå

a pl

uppa

r, så

att

alla

ve

t vad

som

gäl

ler.

Man

kan

ock

så a

nvän

da p

lupp

met

oden

för a

tt vä

lja

blan

d lö

snin

gar –

alla

får t

re p

lupp

ar ti

ll ex

empe

l:

# #

P

igge

lin

# #

# #

Mag

num

(v

inna

ren!

)

# #

#

S

oler

o

Foku

sgru

pper

E

n m

oder

ator

stä

ller f

örbe

redd

a frå

gor t

ill e

n re

pres

enta

ntiv

gru

pp

anvä

ndar

e. M

an k

an v

id b

ehov

förd

jupa

fråg

orna

för a

tt re

da u

t vi

ssa

deta

ljer.

En

utom

ståe

nde

pers

on a

ntec

knar

vad

som

säg

s un

der g

rupp

en.

Tänk

på

att d

et lä

tt är

dem

som

pra

tar m

est s

om h

örs.

Se

till a

tt få

in

alla

i sa

mta

let.

Bea

rbet

a se

dan

data

t. D

enna

met

od b

ör g

öras

tidi

gt

i pro

jekt

et. B

jud

på fi

ka.

Vem

blir

ans

varig

för f

örva

ltnin

g?

Leverabler

Kon

text

uella

inte

rvju

er

Gen

omfö

rs i

verk

lig a

nvän

dnin

gssi

tuat

ion,

rikt

iga

uppg

ifter

(ej t

illrä

ttala

gt!

– lå

t anv

ända

ren

inte

lägg

a sa

ker å

t sid

an fö

r att

”det

är ä

ndå

för s

vårt”

)

Det

är e

n ko

mbi

natio

n m

ella

n in

terv

ju o

ch o

bser

vatio

n. M

an få

r int

e ba

ra

fram

de

svar

som

inte

rvju

pers

onen

kan

ge,

uta

n äv

en lä

gga

mär

ke ti

ll fe

nom

en i

anvä

ndni

ngss

ituat

ione

n.

Kon

texu

ella

inte

rvju

er k

an g

enom

förs

tidi

gt i

proj

ekte

t för

att

kartl

ägga

an

vänd

arna

s m

ål. R

esul

tate

t av

inte

rvju

erna

blir

ofta

und

erla

g fö

r pe

rson

as.

Egen

met

od

Lägg

gär

na ti

ll eg

na m

etod

er. V

anlig

tvis

kom

bine

rar m

an g

ärna

m

etod

er fö

r att

täck

a in

fler

a as

pekt

er i

anvä

ndni

ngen

–

trian

gule

ring.

Dok

umen

tera

! Vi

d de

sign

arbe

te ä

r det

anv

ändb

art a

tt do

kum

ente

ra v

ad m

an g

jort,

m

an g

löm

mer

forta

re ä

n m

an tr

or. D

et v

iktig

aste

är e

gent

ligen

att

spar

a al

la s

kiss

er, m

ed d

atum

mär

knin

g. M

an k

an ti

ll ex

empe

l spa

ra

dem

i en

hög

i si

tt sk

åp, b

ara

man

kan

gå

tillb

aka

och

titta

hur

de

sign

en u

tvec

klat

sig

und

er a

rbet

ets

gång

.

$

Less

ons

lear

ned

Sam

la p

roje

ktgr

uppe

n oc

h lå

t alla

skr

iva

ner v

ad s

om v

ar b

ra o

ch d

ålig

t på

post

its.

Gru

pper

a de

ssa

på e

n ta

vla

och

skriv

ner

. Sam

man

fatta

här

elle

r i d

okum

ent v

id s

idan

av

..

Förb

ättr

inga

r av

Kra

vkar

tan

Des

sa s

aker

sak

nas

elle

r mås

te ä

ndra

s i K

ravk

arta

n:

Bra

:

Dål

igt:

Ska

gör

as a

nnor

lund

a:

Mat

s är

34

år o

ch e

kono

m. H

an v

ill

gärn

a gö

ra e

tt br

a jo

bb o

ch ä

r gan

ska

van

vid

dato

rer.

På

fritid

en g

illar

Mat

s at

t spe

la ja

zz o

ch a

tt sp

ela

hand

boll.

Mat

s är

gan

ska

nogg

rann

och

vill

ha

ett p

rogr

am d

är h

an k

änne

r att

han

har

hög

prec

isio

n på

sitt

arb

ete.

Att

alla

re

sulta

tbel

opp

blir

korr

ekt i

fylld

a oc

h at

t han

har

öve

rblic

k så

att

inga

fel

upps

tår ä

r de

vikt

igas

te m

ålen

för

Mat

s.

TRITA-CSC-E 2011:060 ISRN-KTH/CSC/E--11/060-SE

ISSN-1653-5715

www.kth.se