Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt. LINUS ERICSSON och EMELIE SVARTLING

Transkript

1 Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt LINUS ERICSSON och EMELIE SVARTLING Examensarbete Stockholm, Sverige 2011

2 Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt LINUS ERICSSON och EMELIE SVARTLING 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 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 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.

4 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.

5 Innehållsförteckning Bakgrund...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!

6 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!

7 Bakgrund 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. 1

8 Bakgrund 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. 2

9 Metod 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 ). 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 ). 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). 3

10 Metod 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 ). 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 ). 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 Highfidelity (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 ). 4

11 Metod 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 Scruminspirerat. 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 timeboxing 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. 5

12 Metod 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. 6

13 Metod 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 7

14 Metod 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 8

15 Metod 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. 9

16 Teoretisk referensram 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. 10

17 Teoretisk referensram 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 ) 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 ) 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. Fastställa förväntningar på nytta Styra produktens utformning Värdera och godkänna produkten 1 Förbättringsområde definierat 2 Produktidén godkänd 3 Krav på kvalitet och införande 4 Principlösning godkänd 5 Detaljdesign godkänd 6 Produktutformning godkänd 7 Användningskvalitet godkänd 8 Teknisk kvalitet godkänd 9 Produkten godkänd 10 Införande godkänt Upprepas, avser delar av produkten Figur 1. De tio effektbesluten och hur dessa förhåller sig till de tre faserna i processen (Ottersten & Balic 2010, s. 72). 11

18 Teoretisk referensram 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. Figur 2. De fyra första effektbesluten (Ottersten & Balic 2010, s ) 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). 12

19 Teoretisk referensram 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 ). 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 ). 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 ). 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 13

20 Teoretisk referensram centrala förtjänsterna med RUP är metoden är iterativ och utvecklar systemet i små delar. Gulliksen & Göransson (2002, s ) 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 14

21 Teoretisk referensram 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 ). 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 Figur 3. Lista över Voleres kategorier (fritt översatt) (Robertson & Robertson, 2007 s ) 15