metod f¶r initial behovs- och kravhantering i agila
TRANSCRIPT
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
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.