Karin Andersson
Kravinsamling vid utveckling av
mobila applikationer
En undersökning gjord utifrån utvecklares perspektiv
Informatik
B-uppsats
Termin: Vårtermin -14
Handledare: Prima Gustiené
Sammanfattning
Mobila applikationer är något som blir allt mer populärt och används dagligen. Kraven på
att skapa användarvänliga applikationer med hög affärsnytta blir allt större då
konkurrensen ökar. Detta är en stor utmaning för utvecklare då applikationerna har
begränsad funktonalitet och ett användargränssnitt som fungerar i de flesta miljöer. Inför
utveckling av mjukvara samlar man in krav för att ta reda på vad och hur systemetet bör
fungera i slutändan. Arbetet med kravhantering innebär flera steg där man bland annat
samlar in, prioriterar och strukturerar krav.
Syftet med den här högskoleuppsatsen är att undersöka i vilken utsträckning kravhantering
används vid utveckling av mobila applikationer. Studien visar de vanligaste metoder som
tillämpas för att ta fram rätt krav och vilka faktorer som påverkar i vilken utsträckning de
används.
Undersökningens mest intressanta fynd visar sig vara kunden. Studien visar på att det
element som påverkar mest i vilken utsträckning kravhantering används är kundens
engagemang och vilja. Kunden vill snabbt se resultat och inte lägga tonvis med tid och
pengar på att analysera krav. Vid agila utvecklingsmetoder är det viktigt att kunden följer
upp och bekräftar kraven under hela arbetets gång. Kan utvecklare förklara nyttan med ett
väl genomfört kravarbete är chansen större att mer tid läggs, rätt krav tas fram och
applikationen blir lyckad.
Förord
Jag skulle vilja tacka alla som varit med och bidragit till att göra denna uppsats möjlig. Jag
vill tacka alla respondenter som ställt upp och bidragit med sin kunskap i form av
intervjuer.
Jag vill även tacka min handledare Prima Gustiené som hjälpt mig och bidragit med nya
infallsvinklar till uppsatsarbetet.
Tack även till Amanda Sjödin och Elin Larsson som kommit med konstruktiv kritik och
idéer som hjälpt mig i skrivandet.
Innehållsförteckning
1. Inledning.................................................................................................... 2 1.1 Bakgrund................................................................................................ 2 1.2 Syfte........................................................................................................ 3 1.3 Målgrupp................................................................................................. 3 1.4 Avgränsning............................................................................................ 3
2. Teori.......................................................................................................... 4 2.1 Definition av begreppet krav................................................................. 4
2.2 Definition av begreppet mobil applikation............................................ 5
2.3 Konsekvenser......................................................................................... 5
2.4 Kravhanteringsprocessen....................................................................... 6
2.4.1 Insamling............................................................................................. 6
2.4.2 Dokumentation.................................................................................... 7
2.4.3 Prioritering........................................................................................... 8
2.4.4 Strukturering........................................................................................ 8
2.4.5 Kvalitetssäkring................................................................................... 9
2.4.7 Förvaltning........................................................................................... 9
2.5. Prototyper............................................................................................... 9
3. Metod....................................................................................................... 11 3.1 Val av ämne.............................................................................................11
3.2 Vetenskapligt tillvägagångssätt................................................................11
3.3 Undersökningsmetod.............................................................................. 12
3.4 Insamling av data.................................................................................... 13
3.5 Analysmodell.......................................................................................... 14
3.5.1 Tid........................................................................................................ 15
3.5.2 Utbildning............................................................................................ 15
3.5.3 Budget.................................................................................................. 15
4. Analys...................................................................................................... 17 4.1 Metoder inför utveckling av mobila applikationer................................ 17
4.2 Tid.......................................................................................................... 18
4.3 Kund...................................................................................................... 19
4.4 Budget.................................................................................................... 19
4.5 Tid hör ihop med budget....................................................................... 20
4.6 Utbildning.............................................................................................. 20
4.7 Tid hör ihop med utbildning.................................................................. 20
5. Slutsatser................................................................................................. 22
6. Källförteckning....................................................................................... 23 6.1 Tryckta källor....................................................................................... 23
6.2 Muntliga internet.................................................................................. 23
7. Bilagor..................................................................................................... 26 Bilaga 1: Intervjuguide............................................................................... 26
Bilaga 2: Respondent 1.................. ............................................................ 27
Bilaga 3: Respondent 2............................................................................... 29
Bilaga 4: Respondent 3............................................................................... 31
Bilaga 5: Respondent 4............................................................................... 33
2
1. Inledning
I det inledande kapitlet beskrivs bakgrunden till varför kravhantering av mobila applikationer
är ett aktuellt ämne. Därefter följer syftet som beskriver det tänkta slutmålet med uppsatsen.
Kapitlet innehåller också vald frågeställning, vilken målgrupp uppsatsen är riktad till samt
vilka avgränsningar som finns för undersökningen.
1.1 Bakgrund
Att samla in krav är ofta det första utvecklare gör när ett nytt IT-system ska tas fram
(Computer Sweden 2014). Kravhantering är enligt Eriksson (2008) en uppsättning aktiviteter
som innefattar insamling, dokumentation, prioritering, strukturering, kvalitetssäkring och
förvaltning av krav för ett IT-system. Blir det felaktigheter redan i det här stadiet kan det leda
till bristande kvalitet i det nya systemet. Konsekvenserna kan bli att systemet måste göras om
och det kostar förstås utvecklare både tid och leder till att kunden inte känner sig nöjd med
den färdiga produkten.
Under min studietid på universitetet har utbildningen till stor del handlat om kravhantering.
Kursernas innehåll har behandlat olika sätt att göra detta. Vattenfallsmetoden och Scrum är
exempel på olika metoder som används för att jobba med systemutveckling (Vinderos 2013).
Kravhantering är en viktig del av processen vid utveckling av ett IT-system. Detta är ett stort
ämne som många har skrivit om tidigare. För att avgränsa ämnet kombineras undersökningen
med ett annat ämne som inte fått lika mycket uppmärksamhet men som är mist lika aktuellt,
nämligen utveckling av mobila applikationer. Applikation, även kallat app, har på senare tid
kommit att stå för program och funktioner som hör till mobiltelefoner och plattor. Vissa
kostar pengar andra är gratis (Språkrådet 2014).
Företaget Apples "App Store" är en nedladdningstjänst för att ladda ner program till iphone
(Computer Sweden 2014). App Store presenterade nyligen siffror på att 50 miljarder
nedladdningar av applikationer gjorts. Motsvarande tjänst för Android är Google-play och de
kommer inte långt efter med 48 miljarder nedladdningar (Mobil 2014). Mobila applikationer
är något som blir mer och mer populärt och det ökar förstås kraven både på apparna och
utvecklarna som står bakom dem.
Ofta fokuserar företag i första hand på att skaffa en hemsida eller ett större IT-system
eftersom det tillhandahåller ett större utbud av funktioner. Den mobila applikationen kommer
oftast i andra hand som ett tillägg till den större tjänsten (Rosén 2011). Applikationer innebär
mindre funktionalitet men är mer lättillgängliga och blir allt mer populära att använda. Det är
alltså intressant att undersöka hur mycket energi och tid som läggs ner innan utvecklare sätter
sig och skapar de nya populära applikationerna.
3
1.2 Syfte
Syftet med den här uppsatsen är att undersöka i hur stor utsträckning kravhantering används
vid utveckling av mobila applikationer i jämförelse vid exempelvis utveckling av större IT-
system. Jag kommer ta reda på vilka metoder utvecklare använder idag och om företagen
anser att tid och pengar räcker till för att samla in tillräckligt med krav för att framställa en bra
produkt. Undersökningen avser att undersöka vilka faktorer som spelar in och påverkar hur
kravhantering används och vilka samband dessa faktorer har. Min undersökningsfråga avser
att ta reda på i vilken utsträckning kravhantering används vid utveckling av mobila
applikationer. Allt sett utifrån utvecklares perspektiv.
1.3 Målgrupp
Min målgrupp riktar sig mot IT-företag som håller på med just utveckling både av
applikationer men även andra system. Kravhantering kan vara intressant både från utvecklares
och användares perspektiv, därför avser min målgrupp båda parter. Kanske kan studien få
samarbetet att fungera bättre mellan parterna efter att de har fått en större förståelse för
utvecklarnas process. Undersökningen avser att kunna läsas av den som är intresserad av att
lära sig mer om kravhantering och vilka problem som kan finnas utifrån utvecklares
perspektiv när en mobil applikation skall tas fram. Min målgrupp sträcker sig även till
universitet som tillhandahåller utbildningar där man får lära sig om kravhantering.
Undersökningen kan visa på att studenter idag lär sig om helt rätt saker eller också kanske att
kursinnehållet borde ändras.
1.4 Avgränsningar
Jag har valt i den här undersökningen att fokusera på de metoder och tillvägagångssätt som
finns utifrån utvecklares perspektiv. Undersökningen avser vad som är aktuellt just nu. Endast
några av de vanligaste agila metoderna presenteras i undersökningen för att kunna avgränsa
ett så stort ämne som kravhantering. Uppsatsen innehåller en del material som återfinns i
kurslitteratur för kurser i kravhantering för att återkoppla till uppsatens bakgrund.
4
2. Teori
I det teoretiska kapitlet presenteras innebörden av begreppet krav och mobil applikation.
Sedan följer en förklaring på vilka metoder som finns för att hantera krav. Kapitlet avslutas
sedan med en analysmodell där avgörande faktorer tas upp och deras samband förklaras.
2.1 Definition av begreppet krav
Enligt Computer Sweden kan ett krav vara en funktion, egenskap, eller en beståndsdel som en
beställd tjänst eller produkt ska ha för att bli godkänd av kunden (2014). Ordet krav innebär
egentligen att något krävs. Ett krav är något som måste uppfyllas ovillkorligen. De flesta krav
är i verkligheten mer eller mindre förhandlingsbara och det finns ett antal faktorer som
bestämmer om kraven är genomförbara. Det första är oftast hur lång tid kraven tar att
realiseras. Om ett specifikt krav skulle ta alldeles för lång tid att implementera och det finns
andra krav som ger god affärsnytta men tar kortare tid att genomföra prioriteras ofta det
sistnämnda. Ett annat exempel är mängden krav. Finns det för många krav kommer alla inte
hinna realiseras. Personalen och projektets budget är också faktorer som spelar in (Eriksson
2008).
Pohl och Rupp (2011) beskriver något som kallas funktionella och icke funktionella krav.
Funktionella krav innebär det som behövs för att systemet ska fungera på ett speciellt sätt. Det
specificerar med andra ord vad systemet skall kunna göra. Ofta beskriver man funktionella
krav med att ange önskad in- och utdata. Det kan till exempel vara att kunden önskar att
kunna spara en kontakt i telefonboken. Indata är då kontaktens namn och telefonnummer.
Önskad utdata i det här fallet kan vara att kunden skall kunna plocka fram den sparade
kontakten och se den sparade informationen (Eriksson 2008).
De icke funktionella kraven är också viktiga för att kvalitetssäkra systemet. Dessa handlar
däremot hur applikationen skall göra det snarare än vad den skall göra. Det kan handla om
prestanda och användbarhet. Det är de icke funktionella kraven som i stor utsträckning avgör
hur applikationen kommer upplevas av användarna (Eriksson 2008). Här preciseras vad
systemet måste vara för att användare skall vilja använda det. Ett icke funktionella krav kan
vara hur användargränssnittet ska se ut eller hur många användare som skall rymmas. Det är
svårt att testa icke funktionella krav eftersom deras värde klassas som subjektivt. Vad som är
bra för en användare kan upplevas som sämre för en annan (Chung & Nixon 2000).
2.2 Definition av begreppet mobil applikation
För att kunna svara på frågan om hur vi samlar in krav för att utveckla applikationer behöver
vi först definiera vad en applikation är för någonting. En applikation betyder ett datorprogram.
Datorprogram behövs när människor inte vill eller kan göra saker manuellt.
5
Ett datorprogram kan även användas till underhållning och informationssökning. Man kan
säga att program är det som motiverar till att skaffa dator. Det är alltså inte mjukvaran för att
datorn skall kunna fungera utan det vi faktiskt använder datorn till (Computer Sweden 2014).
Om vi ser till ordet mobil applikation betyder då detta program för smart mobil eller
surfplatta. Applikation kan även kallas "app". Namnet har spritts sedan Apple började sälja
program till iPhone i sin "App Store". År 2011 publicerade Apple en lista på de mest
nedladdade apparna där gratisappen Facebook ligger i topp. Facebook är det mest kända
sociala nätverket och Facebook hade enligt egna uppgifter registrerat över en miljard
användare vid årsskiftet 2012-2013. Det startade som ett kontaktnät för studenter på Harvard
2004 (Computer Sweden 2014).
I en intervju med företaget Swedish Application säger man att vissa idéer till appar
egentligen passar bättre som en hemsida. De menar att i framtiden kommer apparna vara mer
som ett komplement med specialfunktioner än hela webbplatser som många är i nuläget. De
nämner även att push-meddelanden är något som kommer att utnyttjas mer. Om du valt att ta
del av erbjudanden från en specifik varukedja bör du få ett meddelande om detta så fort du
passerar deras skyltfönster. Du ska få information levererad till dig hellre än att behöva söka
upp den på egen hand (Blom Westergren 2014).
En applikation utvecklas för ett specifikt operativsystem och kan därför bara användas av
mobiltelefoner som använder just det operativsystemet. Android är ett operativsystem
utvecklat inom Google sedan 2005. Det är baserat på linux och skrivs i en variant av
programspråket java (NE 2014). Konkurrenten Apple använder ett operativsystem som kallas
iOS och är en variant av OS X. Applikationer för iOS är oftast skrivna i språket Objective-C.
Enligt Swedish Application är det fler saker än programmeringsspråken som skiljer dem åt.
Utmaningen med att utveckla i Android är att det går att kombinera på så många olika sätt. Du
behöver till exempel göra tredubbelt av alla grafiska element och lägga mer tid på att testa
appen. Det finns ett stort utbud av skärmstorlekar, processorer och så vidare att ta hänsyn till.
Apple däremot har en rad riktlinjer och kvalitetssäkringar som gör att det kan ta upp emot tre
veckors väntetid innan applikationen kommer ut i programbutiken. Hittar de något fel måste
du åtgärda det och processen börjar om. Hos Android market finns appen ute på en timme
oavsett hur den ser ut eller fungerar. På gott och ont menar Swedish Application (Blom
Westergren 2014).
2.3 Konsekvenser
Brister i kravhanteringen kan som tidigare nämnts leda till stora konsekvenser. Felaktiga krav
samlas in från fel personer som sedan dokumenteras på ett ineffektivt sätt. Missförstånd kan
uppstå mellan många parter om inte krav samlas in på ett bra sätt.
6
Konsekvenserna kan bland annat bli följande:
En funktion fungerar på ett felaktigt sätt.
Systemet blir färdigt senare än det var tänkt.
Utveckling och systemförvaltning kostar mer än planerat.
Användarna blir missnöjda.
Det är alltså viktigt att använda insamlingsmetoder som alla inblandade är införstådda i för att
undvika felaktiga system. Om användare är missnöjda kan det leda till att färre använder
systemet och företag kan förlora pengar. Om företag förlorar pengar kan det i sin tur leda till
att företag läggs ned (Eriksson 2008). Enligt Dr. Dorsey (2005) skulle felen minska drastiskt
om vi började se att bygga en applikation på samma sätt som att bygga en kontorsbyggnad.
Innan vi sätter igång och bygger görs ritningar, blueprints och planering. Att börja utveckla en
applikation innan man skrivit en kravspecifikation anser han är lika dumt som att ta in
tapetserare innan väggarna är byggda.
2.4 Kravhanteringsprocessen
Enligt Eriksson (2008) består kravinsamling av en rad aktiviteter som innefattar insamling,
dokumentation, prioritering, strukturering, kvalitetssäkring och förvaltning. Dessa aktiviteter
kallas för stjärnan och utförs iterativt, vilket betyder att man utför stegen upprepade gånger i
etapper. Man levererar små delar i taget. Man kan säga att man bygger ett fungerande system
som man sedan ersätter med förbättrade versioner. Detta sparar tid och resurser då varje steg
inte behöver vara fullständigt från början (Rouse 2011).
Under varje aktivitet i Erikssons modell finns ett antal olika metoder och tillvägagångssätt. I
den fortsatta undersökningen kommer aktiviteterna beskrivas för att läsaren skall få en
djupare insyn i vad kravhantering och de olika stegen innebär. Vi börjar med insamlingen av
krav.
2.4.1 Insamling
Det första steget är insamling där vi börjar med att ta reda på vilka intressenter som finns. En
intressent är ekonomiskt engagerad och intresserad i den aktuella verksamheten. De påverkas
av företagets åtgärder och kan själva vara med och påverka dem (NE 2014). Exempel på
intressenter kan vara användare, kunder, testare, servicetekniker och utvecklare. Alla
intressenter har någon form av specialkompetens som kan komma att användas i systemet vid
någon tidpunkt. Det är inte säkert att krav behöver samlas in från alla intressenter men det är
allt för ofta intressenters krav inte tillgodoses eller upptäcks (Eriksson 2008).
Kravinsamling anses vara den fas i början av ett projekt där vi dokumenterar de krav som
finns för projektets intressenter. Olika insamlingsmetoder fungerar olika bra beroende på
7
intressenternas intresse samt hur mycket förarbete projektledaren har gjort. Den mest vanliga
metoden för att samla in krav är intervjuer.
Den är enkel att strukturera och enkel att utföra. För att intervjun skall bli framgångsrik måste
personen som utför intervjun vara insatt i affärsområdet och ha en bra
kommunikationsförmåga. En fördel med att samla in krav vid intervju är möjligheten att styra
intervjun för att få så utförliga svar som möjligt på de ställda frågorna (Eriksson 2008).
En annan metod är styrda workshops. Många misstar workshops för ett vanligt möte då det
finns en del likheter. I en workshop träffas ett antal intressenter som styrs av en
workshopledare och diskuterar idéer till det kommande systemet. Metoden kräver att ledaren
för workshopen kan behärska ett antal tekniker för att kunna få ut så mycket som möjligt av
gruppen och att kunna stimulera deltagarna. Den stora skillnaden mellan möten och
workshops är att workshops innehåller ofta fysisk aktivitet av något slag och alla intressenter
är delaktiga hela tiden. Johansson (2011) menar att styrda workshops passar bättre i en miljö
där det finns olika åsikter om vad som behöver göras bland intressenterna.
Det finns en mängd olika tekniker för att samla in vilka krav som finns på det kommande
systemet. Det krävs ett iterativt arbetssätt med flera tillfällen och ofta en kombination av olika
tekniker för att samla alla krav. När de övergripande kraven på systemet fastställs är det dags
att kontrollera vilka krav som är möjliga att implementera och vilka krav som ger mest nytta
för verksamheten i förhållande till kostnad (Ahlmark 2013).
2.4.2 Dokumentation
Att sedan skriva ner vilka krav som man kommit fram till underlättar för både beställare och
utvecklare. Det finns två typer av dokumentation. Det ena är kravspecifikationen och det
andra innehåller användningsfall (Andersson & Aderud 2014). Kravdokumentationen
fastställer vad användaren vill ha genom en överenskommelse vad systemet skall innehålla.
Dokumentationen kan även fungera som en mall för att senare stämma av att systemet är
färdigt. Genom att skriva upp vilka delar projektet skall innehålla tvingas alla inblandade
tänka efter och risken för missförstånd minimeras. På så vis kan företaget bespara sig att
behöva göra om design, kod och test eftersom sannolikheten att det blir rätt från början är stor
(Eriksson 2008).
Dokumentation med användningsfall är ett sätt att dokumentera krav precis som
kravspecifikationer. Det är en modell som beskriver interaktioner mellan system och aktör.
Det kan beskrivas som en stillbild av olika händelseförlopp som utförs i systemet och är till
för att öka förståelsen för hur det framtida systemet kommer att fungera. Det är en grundlig
analys av alla sätt ett system kan användas på (Computer Sweden 2014).
8
2.4.3 Prioritering
När man antecknat vilka krav som finns är det dags att rensa. Syftet med prioritering är att
hitta de mest betydelsefulla kraven. Kravens prioritet bör baseras på värdet de har i
verksamheten eller för användarna. (Eriksson 2008) Beroende på hur lång tid utvecklarna har
på sig och hur mycket pengar intressenterna är villiga att betala kan bara ett antal av alla
insamlade krav realiseras. Det gäller då att hitta de som ger mest nytta för systemet. Enligt
Ahlmark (2013) finns det ett antal punkter att titta på för att göra en bra prioritering:
Verksamhetsnytta
Användarnytta
Tid
Komplexitet
Risk
Framtiden
Det känns naturligt att implementera kraven i prioritetsordning. Högst till lägst. Det vi lätt kan
glömma är att mindre prioriterade krav kan innebära komplexa lösningar som kan vara svåra
att implementera, tar lång tid eller innebär oväntade överraskningar längre fram i projektet.
Dessa komplexa krav bör implementeras tidigt för att undvika problem. Utvecklarna kan dock
inte leverera de riskfyllda kraven och de mest prioriterade samtidigt. Det är här vi tar hjälp av
rangordningstekniker (Eriksson 2008).
En vanlig metod för att rangordna kraven kan göras i samband med en workshop. Metoden
kallas tre pinnar och görs efter att kraven tagits fram och delats in i grupper som ofta
motsvarar systemdelar. Delarna är uppskrivna på post-it lappar på en whiteboardtavla. Varje
deltagare får tre streck att sätta vid den del de tycker är den viktigaste. Att endast ge
deltagarna få pinnar gör att de måste tänka till. Om alla får tio pinnar var är det lätt att alla
krav prioriteras lika mycket. Det är viktigt att kraven är av den typ att det går att jämföra deras
prioritet med varandra (Ahlmark 2013).
3.4.4 Strukturering
Struktur i allmän bemärkelse används när vi pratar om relationer mellan olika delar av en
helhet (NE 2014). I samband med kravhantering menar vi oftast beskrivning, prioritering och
kategorisering för att lättare förstå kraven. Ett mycket vanligt problem under
kravhanteringsprocessen är att man glömmer att krav bör struktureras. Struktureringen bör ske
parallellt genom alla faser där krav hanteras eftersom kraven förändras. Genom att strukturera
blir dokumentationen tydligare och ger en mer övergripande bild för alla aktörer. För att
underlätta arbetsprocessen och ytterligare försäkra sig om att man arbetar med rätt krav är
struktur en viktig del av kravhantering (Andersson & Aderud 2014).
9
2.4.5 Kvalitetssäkring
Det gäller att säkerställa att rätt krav är dokumenterade. Det görs med hjälp av
kvalitetssäkring. Vid kvalitetssäkring tillämpar man dokumentgranskning och prototyper
hellre än att använda testfall. Kvalitetssäkringen är en pågående process som följer under hela
utvecklingstiden eftersom att kraven kan komma att ändras. Det är bättre att leverera små bitar
av ett system än att ta kraven, gå hem och utveckla systemet och sen komma tillbaka och
leverera det färdiga systemet efter två år. Täta leveranser gör att man justera systemet om man
upptäcker fel eller att utvecklingen går åt fel håll (Eriksson 2008).
2.4.6 Förvaltning
När ett fel uppstår kallar vi det ofta för mänsklig faktor. Men vid en djupare analys kan vi se
att de mänskliga felhandlingarna ofta betingas av olämpliga systemlösningar eller dåligt
samspel (NE 2014). Enligt Erikssons modell för att hantera krav behöver vi en aktivitet där vi
förvaltar krav. Här krävs samspel. Så fort kraven är satta kommer någon vilja ändra på dem.
För att ge utvecklare bättre arbetsro och minska stress kan man göra något som kallas frysning
av krav. Efter att kraven är satta får då kraven inte får ändras på en viss tid. Den tiden brukar
oftast vara tills början av nästa iteration. Det är dock viktigt att man har korta intervaller
mellan iterationerna och att kraven är stabila innan de fryses. I början av varje iteration går
man sedan igenom vilka krav som skall förändras. Man kan ofta ha ett ändringsråd som
godkänner förändringarna innan de beviljas.
2.5 Prototyper
Som Benyon, Turner och Turner (2005) skriver kan prototyper användas för att presentera
eller visa en konkret implementation av ett system. Det kan vara bra att tidigt i designfasen
demonstrera specifika detaljer eller konstruktioner kring applikationen som skall skapas. Det
finns olika sätt att skapa prototyper men en gemensam nämnare är att de bör vara interaktiva.
Den skall visa att det händer något när användaren trycker på en knapp trots att det i
verkligheten kan betyda att knappen är avbildad för hand på papper. När en prototyp är gjort
på detta sätt kallas den även för en lo-fi prototyp. Lo-fi är även känd för sitt billiga och enkla
tillvägagångsätt. En fördel med prototyping är att det kan användas av personer som inte kan
programmera (Egger 2000).
Den andra betydligt mer avancerade prototypen kallas Hi-fi och har syftet att likna den
färdiga produkten. För att göra en prototyp av den här sorten krävs mer tid, pengar och
tekniskt kunnande från den som implementerar prototypen. Fördelen med den här metoden är
att användarna kan testa produkten på riktigt och få en bättre känsla för hur produktens
slutresultat kommer att bli utan att för den delen produkten måste vara färdigställd.
10
Dessa två prototyper används ofta i kombination med varandra för att tidigt i projektet kunna
presentera en design och testa den på användare. På det viset kan man efter arbetets gång
avgöra vad som behöver korrigeras inför den slutgiltiga designen (Benyon et al. 2005).
11
3. Metod
I metodkapitlet presenteras val av ämne, vetenskapligt tillvägagångssätt och metoder som
tillämpats för att samla in data för undersökningen. I det här kapitlet presenteras också en
tidig modell på analysmodellen som använts för att samla korrekt empiri. Därefter följer den
intervjuguide som tagits fram ur analysmodellen och som använts vid de fyra intervjuer som
utförts.
3.1 Val av ämne
Jag har valt att undersöka utifrån utvecklares perspektiv hur man idag går till väga för att
samla in, prioritera, strukturera, kvalitetssäkra och förvalta krav. Fokus ligger på utvecklarnas
upplevelser och erfarenheter. Uppsatsen avser att undersöka vilka faktorer som gör att man
använder sig av en viss metod framför en annan. Det är intressant att undersöka vad det finns
för problem och svårigheter som utvecklare. Eftersom smartphones och applikationer är ett
relativt nytt koncept finns det inte mycket forskning om kravhantering vid utveckling av
mobila applikationer. Däremot finns det mycket forskning om kravinsamling vid utveckling
av andra system. Det är därför ett intressant ämne att forska mer om och kanske skapa ett
bidrag till befintlig forskning. Mobilitet är något som vi tror kommer växa allt mer och stå för
en stor del av den informationsteknik som vi använder oss av i framtiden (Meyers 2011).
3.2 Vetenskapligt tillvägagångssätt
När vi skall ta reda på fakta och undersöka ett ämne kan vi välja att använda ett kvalitativt
eller kvantitativt sätt att göra detta på. Den kvantitativa metoden används främst om vårt
undersökningsproblem bygger på antal, vilka skillnader och relationer finns. Detta är främst
en metod som bygger på statistik. En kvantitativ forskning används när vi kan mäta data och
jämföra resultaten statistiskt.
En kvalitativ forskning däremot använder vi när vi vill göra en verbal analys där vi går in på
djupet för att förstå ett visst mönster eller en viss situation. I den här metoden ligger fokus på
de ”mjuka” delarna i en datainsamling. Vi ser hellre ett fåtal kvalitativa intervjuer än många
ytliga. Man använder ofta verbala analysmetoder. Här används analyser av lågt strukturerade
data, exempelvis enkäter och intervjuer med öppna svar som analyseras textkritiskt. Vid
kvalitativ forskning befinner sig ofta forskaren själv i den sociala verklighet som skall
analyseras (Patel & Davidson 2008).
Oavsett om vi använder oss av en kvalitativ eller kvantitativ undersökning vill vi ha hög
validitet och reliabilitet. När vi säger hög validitet menar vi att vi undersöker det vi avser att
undersöka. Det handlar om att veta vad vi undersöker. Det måste finnas en överensstämmelse
mellan det vi säger att vi ska undersöka och det vi faktiskt undersöker. Reliabilitet handlar om
att det vi undersöker stämmer. Vi måste veta att undersökningen görs på ett tillförlitligt sätt
12
och att vi kan lita på de resultat vi får. Till exempel vet vi att om vi ställer oss på en våg får vi
information om hur mycket vi väger. Vi litar på vad vågen säger och den har hög reabilitet.
Man kan säga att en våg har högre reabilitet än om till exempel någon skulle lyfta oss och tala
om för oss hur mycket vi väger.
Det finns enligt Patel och Davidson (2008) tre tumregler för hur validitet och reliabilitet står i
förhållande till varandra. ”Hög reabilitet är ingen garanti för hög validitet”. Om man vet att
man mäter ett ämne på ett säkert sätt och får ut den exakta siffran så behöver inte det betyda
att man undersökt rätt ämne i förhållande till vad man vill undersöka. ”Låg validitet ger låg
reliabilitet”. Om mina mätningar inte är tillförlitliga, kan jag inte veta vad jag mäter.
”Fullständig reliabilitet är en förutsättning för fullständig validitet”. För att veta vad som mäts
måste mätningen vara gjord på ett tillförlitligt sätt.
I den här studien kommer en kvalitativ metod användas för att undersöka i hur stor
utsträckning kravhantering används vid utveckling av mobila applikationer. Vi är inte
intresserade av att ta reda på numerisk data, utan istället vill vi undersöka och analysera varje
individuellt tillvägagångssätt. Det passar då bättre att använda en kvalitativ metod som
intervjuer.
Kvalitativa intervjuer används främst när man inte är helt säker på vilken information från
målgruppen som är intressant och det är lättare för den som intervjuar att styra intervjun så att
rätt information tas fram (E-delegationen 2012). Det är även bra när man vill ge möjlighet för
den intervjuade att lämna synpunkter eller kommentarer. En kvalitativ intervju innebär att
frågor ställs till målgruppen antingen vid ett fysiskt möte eller via ett telefonsamtal.
För den här uppsatsen kommer semistrukturerade intervjuer genomföras. De används som en
kvalitativ metod för att samla in information. Då används ett antal frågor som kommer
användas som riktlinjer för intervjun. Målgruppen kommer dock en stor frihet att styra
intervjun för att undvika att missa intressant information för undersökningen. Intervjuerna blir
då mer som ett samtal mellan personen som intervjuar och målgruppen (Patel & Davidson
2008).
3.3 Undersökningsmetod
Det finns olika sätt att samla information för att få en frågeställning besvarad. Ingen kan säga
att en metod är bättre än någon annan. Vilken teknik vi väljer beror ofta på vad vi avser att
undersöka och vad som kommer ge oss bäst svar på vår undersökningsfråga i förhållande till
den tid och medel vi har till vårt förfogande (Patel & Davidson 2008). Undersökningsmetoden
är det samlade tillvägagångssättet i hela uppsatsens undersökning. Det är ofta sammansatt av
flera olika metoder som finns att tillgå i ämnet (Rienecker & Jörgensen 2008).
I den här B-uppsatsen har jag valt att tillämpa en fallstudie med kvalitativa intervjuer för att
undersöka i vilken utsträckning kravhantering används vid utveckling av mobila
applikationer. Metoden avser att börja med insamling av redan existerande forskning kring
ämnet. Uppsatsen presenterar samlad teori kring kända tillvägagångssätt för kravhantering.
13
Arbetetet fortsätter med att teorier jämförs och undersöks för att ta fram en analysmodell för
att lättare kunna avgränsa vilka faktorer som påverkar i vilken utsträckning kravhantering
används. Analysmodellen kommer användas för att jämföra och utvärdera resultatet av den
insamlade empirin som erhållits av undersökningen.
Jag har utifrån eget tycke valt vilka respondenter som skall delta i undersökningen utifrån
deras arbete och tillgänglighet. En förutsättning är att deltagaren har erfarenhet av att samla in
krav inför utveckling av mobila applikationer. För att få ett bredare perspektiv på den
empiriska undersökningen ställs frågan om den intervjuade arbetar med applikationen även
efter att kraven samlats in. Detta för att undersöka om och i så fall på vilket sätt detta kan
påverka insamlingen. Övriga intervjufrågor har baserats på analysmodellen.
3.4 Insamling av data
När man samlar in data till en undersökning pratar man om primär- och sekundärdata.
Primärdata är data som forskaren själv samlar in, medan sekundärdata är uppgifter som redan
existerar och som någon annan samlat in (Akademin för ekonomi, samhälle och teknik 2014).
Uppsatsen består både av primärdata och sekundärdata. Sekundärdata i uppsatsen är hämtad
från litteratur, forskningsartiklar och andra relevanta artiklar. Främst har sökverktyget Google
Scholar använts.
Primärdata i den här B-uppsatsen samlas in med hjälp av personliga intervjuer där
respondenterna är konfidentiella i undersökningen. Eftersom undersökningen avser att ta reda
på information från ett fåtal respondenter var valet mellan enkät och intervju enkelt.
Möjligheten att styra frågorna efter intervjupersonen var viktig för att få ut så mycket relevant
information till undersökningen som möjligt. Vid intervjuerna har en semistrukturerad metod
tillämpats. Det innebär intervjuer med ett antal styrda frågor med utrymme för spontana
följdfrågor. Respondenterna har meddelats i förväg om att de kommer vara konfidentiella
genom hela undersökningen.
Jag valde att inte spela in intervjuerna utan istället föra anteckningar under intervjuns gång.
En nackdel med att föra inspelning av intervjuer är att det kan påverka respondenten på ett
negativt sätt. Vetskapen om att de spelas in kan göra dem mindre spontana och mer restriktiva
i sina svar. Det är också mycket tidskrävande att transkribera intervjuerna. När man väljer att
anteckna vid en intervju är det mycket viktigt att man direkt efter intervjun förtydligar sina
anteckningar då man har dem färskt i minnet. Jag valde att inte spela in intervjuerna eftersom
jag ansåg att tiden för att transkribera intervjuerna, ställt mot tidsåtgången för att färdigställa
rapporten var alldeles för stor. För den här undersökningen var det även viktigt att svaren från
intervjuerna blev spontana och ärliga. För att kunna återge så mycket som möjligt
förtydligades anteckningar direkt efter intervjuerna. Undersökningens primärdata återfinns
som bilagor.
För att komma fram till relevanta intervjufrågor för undersökningen användes en tidig modell
där viktiga faktorer återfinns baserat på de teorier som tagits fram. Undersökningen avser att
14
ta reda på i vilken utsträckning kravhantering används vid utveckling av mobila applikationer.
Analysmodellen beskriver vilka faktorer teoretiskt sett avgör detta.
3.5 Analysmodell
Syftet med analysmodellen är att utifrån tidigare nämnda teorier och studier skapa ett
underlag för den empiriska studien. En analysmodell kan användas för att ge läsaren struktur
och bestämma värdet av det insamlade material som beskrivs i teoridelen. Det är viktigt att
beskriva modellens olika delar och vilka samband de har mellan varandra (Olsson et al.
2012). Analysmodellen utgår ifrån kravhantering och dess samband som grund för
problemfrågan i den här uppsatsen. Vilka metoder som används beror på flera olika aspekter
som kommer att belysas med hjälp av analysmodellen.
Den här analysmodellen representerar viktiga faktorer som utifrån ovan nämnda teorier känns
viktiga för att besvara uppsatsens frågeställning. Analysmodellens olika delar kommer
användas för att undersöka hur de påverkar i vilken utstäckning kravhantering används vid
applikationsutveckling. De används även som mall för utformning av intervjufrågor till den
empiriska studien. Eftersom modellen visar viktiga faktorer som uppsatsen avser att
undersöka kommer intervjuguiden innehålla frågor angående tid, budget och utbildning.
Frågorna om varje del har utformats för att undersöka hur mycket varje del påverkar
kravhantering. Modellens olika delar har inte kopplats samman då deras syfte är att skapa ett
underlag för undersökningen. I undersökningens analys kommer faktorernas samband
förklaras och de olika delarna kopplas samman.
Figur 1. Tidig modell av påverkande faktorer.
Källa: Andersson
15
3.5.1 Tid
Hur lång tid man har på sig i ett utvecklingsprojekt kan vara avgörande för hur mycket arbete
man lägger på att samla in krav. Har man ont om tid prioriteras oftast andra saker som
implementering eller testning. Tiden måste fördelas jämt över projektets gång och har man då
minimalt med tid finns det risk att man inte hinner ta fram en ordentlig kravspecifikation. Lite
tid medför att kravhantering används i mindre utsträckning (Ahlmark 2013).
3.5.2 Utbildning
Kravinsamling är viktigt att göra inför utveckling av nya system. Har man kunskap och
erfarenhet om detta ökar därför chanserna att kravinsamling används i större utsträckning. Om
en utvecklare känner till olika metoder för att samla in krav och har fått ta del av
konsekvenser vid bristfällig kravhantering kan det öka chanserna för att mer tid läggs ner på
att samla in krav.
Har den utbildade även erfarenhet kan detta ytterligare bidra till att det finns tillräckligt med
tid så att man hinner samla in alla krav som behövs för att göra en lyckad applikation.
2.5.3 Budget
Tid är pengar och finns det mycket pengar för ett projekt kan man spara mycket tid. Budgeten
är det som avgör hur många personer som är med och arbetar i kravhanteringsprocessen men
även för hur stort projektet kommer att bli. Väljer en kund att lägga ner mycket pengar på en
applikation finns det större chans att företaget anlitar ett stort IT-företag där utbildning och
erfarenhet finns bland dem som tar fram kraven vilket i sin tur leder till att kravhantering
används i större utsträckning.
3.6 Intervjuguide
Med hjälp av ovan nämna faktorer utformades en intervjuguide som har använts vid de
semistrukturerade intervjuerna. Detta innebär att frågorna har ställts men i vissa fall har
följdfrågor ställts beroende på respondentens svar på frågan. Detta har gjorts för att kunna få
ut så mycket information som möjligt och kunna göra en djupare analys. Intervjuerna som
återfinns på nästa sida startar med att ta reda på grundläggande fakta om hur respondenten
generellt använder kravhantering vid utveckling av mobila applikationer. Detta för att få en
överblick som intervjuperson och även för att respondenten inte ska få för svåra frågor i
början av intervjun. Efter det följer frågor om tid, budget och utbildning och i vilken
utsträckning respondenten tror att de påverkar i vilken utsträckning kravhantering används.
Respondenterna fick svara på frågan om hur deras egen utbildning påverkat deras sätt att
arbeta med kravhantering.
16
Detta är en personlig fråga som valdes att tas med i intervjun för att respondenten skulle
referera till personliga erfarenheter. Detta för att göra intervjuerna intressantare och mer
trovärdiga. En sammanställning av varje intervju går att återfinna som bilagor i slutet av
rapporten.
Startfrågor
1. Vart jobbar du och i vilken utsträckning jobbar du/ni med att utveckla mobila
applikationer?
2. Vilken typ av kravhantering inför utvecklingen använder du/ni och vilka metoder används?
3. Vad skulle du säga är skillnaden mellan kravarbetet inför utveckling av en mobil
applikation och ett annat system?
Tid
1. Hur lång tid lägger du/ni på att arbeta med krav inför utveckling av en applikation?
2. Vad är det som avgör hur lång tid som läggs på kravhantering?
3. Hade ni/du gjort annorlunda om du/ni hade haft mer tid?
4. Har det hänt att du/ni varit tvungna att lämna kravhanteringen på grund av tidsbrist?
Budget
1. På vilket sätt påverkar budgeten hur mycket tid som läggs ner på kravhantering?
2. Hade ni gjort något annorlunda om det fanns mer pengar, i så fall vad?
Utbildning
1. Vilken utbildning har du?
2. Togs det upp någonting om kravhantering under din studietid, i så fall vad?
3. På vilket sätt tror du att din utbildning påverkar ditt sätt att jobba med kravhantering?
17
4. Analys
I analysdelen presenteras den empiriska studie som gjorts baserat på den analysmodell som tidigare
presenterats. Alla empiriska resultat redovisas och de olika delarna analyseras. Analysen sker först på
separata faktorer som följs av en presentation av deras sammanhang och hur de påverkar varandra.
4.1 Metoder inför utveckling av mobila applikationer
Enligt respondenterna används lite olika metoder beroende på kundens önskemål. Alla
respondenter som deltagit i undersökningen arbetar agilt vilket betyder att kraven ändras
löpande under projektets gång. Oftast börjar projektet med ett uppstartsmöte eller en
workshop där man gör en effektkartläggning. Det innebär att man tar fram och diskuterar
affärsnyttan med systemet och hur dessa kan tas fram (Ottersten & Balic 2007). Resultatet av
det första mötet kan bli en lista med funktionella och icke-funktionella krav. När det finns
möjlighet kan även fältstudier tillämpas för att kunna avgöra vad kunden behöver.
Den största skillnaden mellan kravarbetet vid utveckling av mobila applikationer och andra
IT-system är miljön som användarna befinner sig i. Eftersom det handlar om mobilitet ska
applikationen kunna användas i olika ljus- och ljudförhållanden. Man måste även ta hänsyn
till vilket operativsystem som kunden använder och vilken bandbredd som finns. Ibland kan
det även vara svårt att hitta rätt riktning på applikationen. Många kunder har en hemsida som
de vill komplettera med en applikation. Funktionerna på appen bör då vara begränsade men
ändå ha så stor affärsnytta att applikationen är värd att ladda ner. En av respondenterna
berättar om ett bra exempel på detta där en kund ville göra en applikation där deras användare
kunde se vilka varuhus de hade och deras öppettider. Utvecklarnas utmaning blev här att
förklara för kunden att en applikation där man endast kan se öppettider kommer inte vara nog
för att deras kunder ska ladda ner applikationen. I den här situationen kan en responsiv
mobilanpassad webbsida fungera bättre. Av detta tolkar jag att beroende på hur bra
kommunikationen mellan utvecklare och kund är kan man avgöra hur mycket kravhantering
som bör användas. Om utvecklare förstår precis vad kunden behöver och kunden förstår också
vad utvecklarna kan göra borde inte kravhantering behövas alls.
Interaktiva prototyper är en metod som är populär för att testa användargränssnittet för en
mobil applikation. Det är en simplifierad version av en app som låter dig se den tänkta
designen. Det som är speciellt för interaktiva prototyper är att du kan klicka runt och få en
känsla för hur applikationen kommer interagera utan att behöva programmera (Adnan 2014).
Fördelen med prototyper är att kunden snabbt kan säga om utvecklarna är på rätt väg med
applikationen. Utvecklare och kund som är på olika tekniska nivåer kan lättare kommunicera
när det finns en fysisk produkt i ett tidigt skede av projektet.
Dokumentationen av kraven är en mindre prioriterad del av kravhanteringen. Eftersom kraven
hela tiden förändras kan den ändå inte bli fullständig innan projektet är klart. Enligt
respondenterna är dokumentationen svårförstådd och kunden läser den sällan.
18
Det är bättre att visa bilder och prototyper. Det är också viktigt att ha målgruppen i åtanke när
man samlar in krav för en applikation. Utvecklare måste fundera över vilka som kommer
använda appen i slutändan.
Baserat på den insamlade empirin tolkar jag det som att kunden är den viktigaste faktorn för
vilka metoder man använder för att samla krav. Som Fowler (2005) skriver i sin artikel om
agila arbetssätt är det i slutändan människorna det hänger på. Är kunder och utvecklare inte
intresserade är det väldigt svårt att gå framåt i arbetet. Kundens intresse och miljö den
befinner sig i är något utvecklarna måste ta hänsyn till när de ska analysera kundens behov.
Det största problemet som ligger bakom min frågeställning är kommunikationen. Förmågan
att förstå vad vi menar när vi säger något. Enligt Nationalencyklopedin (2014) betyder
kommunikation överföring av information mellan människor, djur, växter eller apparater. För
att göra kommunikationen möjlig krävs ett språk eller en kod vari informationen uttrycks. En
förutsättning blir då att de som ska kommunicera pratar samma språk.
4.2 Tid
"Målet är inte att lägga så mycket tid som möjligt utan snarare att använda tiden bra och
samla in rätt krav från början" (Respondent 1, 22 juli 2014).
I analysmodellen beskrivs tid som en avgörande faktor till hur mycket kravhantering tillämpas
i ett projekt. Det är komplicerat att mäta tid för en specifik del som krav i ett projekt då alla
deltagare i studien jobbar agilt. Det betyder att man jobbar i etapper där kraven hänger med
genom hela projektet. Nackdelen med ett agilt arbetssätt är svårigheten att avgöra arbetets
tidsåtgång. Kraven förändras hela tiden och därför kan tiden för utvecklingen bli väldigt lång.
Utmaningen är att kunna prioritera krav och uppskatta tidsåtgång för implementering av olika
krav (Vinderos 2013). Krav ändras fortlöpande så därför kan man inte i början av projektet
bocka av krav som en punkt på en lista. Hårddraget kan man säga att krav tar lika lång tid som
projektet eftersom man hela tiden måste ha dem i baktanke.
För att kunna analysera tid på en nivå där den är mätbar måste vi avgränsa oss. Tid betyder
härmed hur lång tid som läggs på krav i början av projektet. Enligt den empiriska studien
börjar utvecklare vanligtvis med ett första uppstartsmöte där man samlar in grundläggande
krav för att starta upp arbetet. Det här mötet kan ta allt ifrån en dag till flera veckor enligt
respondenterna. Detta beror som Eriksson (2008) beskriver till stor del på kunden. Kundens
intresse är ett avseende som inte haft så stort fokus i analysmodellen men som visat sig vara
mycket viktig. Har kunden i fråga en klar bild av vad applikationen ska göra och hur den skall
se ut behövs inte mycket tid eller analys från utvecklarnas sida. Kunden kan vara i ett läge där
de behöver rådgivning från utvecklarna att ta reda på vad de behöver. Detta kräver fler möten
där affärsnyttan tas fram vilket i sin tur tar mer tid.
19
4.3 Kund
De som väljer att gå till ett IT-företag för att få hjälp med att göra en mobil applikation till sin
verksamhet kallar vi i det här sammanhanget för en kund. Kunden är en faktor som påverkar
utstäckningen av hur mycket kravhantering används. Om kunden är insatt i hur mycket kraven
påverkar det slutgiltiga resultatet används det i mycket större utsträckning än om intresse
saknas. Trots att de flesta utvecklare jobbar agilt där kraven är en del av hela projektet kan det
kännas omotiverat för många kunder att betala för massvis timmar av kravhantering. Här
gäller det för utvecklare att kunna förklara affärsnyttan med att göra ett bra förarbete innan
produkten utvecklas. En respondent nämnde i en av intervjuerna att den stora utmaningen var
att kunna förklara för kunden på en icke teknisk nivå. Har man väl klarat av den biten
fungerar kommunikationen mellan utvecklare och kund mycket bättre. Det är just det som
kravhantering i stor utsträckning handlar om, bra kommunikation mellan utvecklare och kund.
En annan typ av kund som gör kravhantering tidskrävande är en kund som inte vet vilken typ
av applikation de behöver. Oftast vill kunden ha ett system som gör deras verksamhet bättre
på något vis (Fowler 2005). En mobil applikation är ett portabelt program som ska fungera
som underhållning eller göra det lättare för människor att utföra vissa tjänster. Att ta reda på
hur en applikation kan förbättra läget för just den specifika kunden kan innebära timmar av
brainstorming och möten. Kunden är den som i slutändan bestämmer vad timmarna de betalar
för skall läggas på.
"Kunden är specialisten på sin verksamhet" (Respondent 3, 18 augusti 2014).
4.4 Budget
Många kunder som kommer till IT-företag och vill ha hjälp med att utveckla programvara vill
ha ett fast pris för vad projektet kommer kosta. Ett fast pris kräver stabila krav. Som vi vet
finns det inget som kallas stabila krav i ett agilt arbetssätt. Detta betyder inte att mjukvara inte
kan ha en fast budget. Dock måste tid, pris och etapper vara rörliga (Fowler 2005).
Fördelen med ett agilt arbetssätt är att kunden kan tidigt få ett fungerande system levererat
men utan alla fullständiga funktioner. Nackdelen är att kund och utvecklare måste ha en nära
relation där de stämmer av arbetet efter varje etapp. Enligt respondent nummer två har de
kunder som de stämmer av med varje vecka och vissa som de stämmer av med varje dag.
Om kunden sedan väljer att utöka budgeten den kan pengarna läggas på större funktionalitet i
applikationen. Kunden kan ha stora visioner på vad de vill göra men måste sedan begränsa sig
för att det de vill göra är för avancerat och kommer kosta för mycket pengar. Från utvecklares
synvinkel kan de ha idéer på hur de kan göra applikationen så optimal som möjligt men måste
även här begränsa sig efter kundens budget.
20
4.5 Tid hör ihop med budget
Undersökningen visar på att budgeten är en viktig faktor men eftersom de flesta projekt utförs
agilt så läggs procentuellt sett lika mycket tid på kravhantering i ett billigt projekt som i ett
dyrt. Man anpassar budget och tid efter projektet. Den empiriska studien har även visat på att
den största faktorn för hur mycket tid som läggs på krav i ett projekt beror främst på kunden.
Det är kunden som sitter på budgeten och bestämmer vad det skall läggas pengar på. Desto
mer funktioner på applikationen desto mer kostar det. Ibland kan kunden vara tekniskt
ointresserad och litar på att utvecklarna levererar någonting bra. Om kunden saknar intresse
och engagemang så läggs mycket mindre tid än om kunden är insatt och intresserad.
4.6 Utbildning
Vilken utbildning utvecklare har är den faktorn som påverkar minst vilka metoder som
används vid hantering av krav. I skolan får man lära sig om olika metoder som finns och som
i teorin fungerar. Ingen av respondenterna använder sig enbart av en metod utan har egna
tillvägagångsätt med inslag och inspiration av redan existerande metoder. Den enda
gemensamma beståndsdelen respondenterna emellan är att alla jobbar agilt. Både teori och
empirisk data visar på att vattenfallsmetoder är uråldriga. De tillhandahåller dåliga system av
uppenbara andledningar som tidigare nämnts. En av respondenterna som inte haft
kravhantering som ett ämne inom sin utbildning anser att man formas efter arbetsplatsen och
påverkas minimalt av utbildningen. Utvecklare får anpassa sig efter den metoden som
används. En annan respondent anser att utbildningen definitivt påverkat sättet att använda
kravhantering. Det har bidragit till att kunna se helhet och affärsnytta på ett annat sätt och
därmed kunna ge bättre lösningar på problem. Utbildning behöver inte endast innebära
högskolepoäng från ett universitet. Man lär sig av andra människor och olika arbetsplatser.
Både misslyckade och lyckade uppdrag från tidigare projekt kan också vara en lärdom.
Resultatet av empirin visar på att en utbildning där krav har ingått inte nödvändigtvis bidrar
till en mer effektiv användning av kravhantering. När det kommer till utbildning så tolkar jag
det som att kollegor och arbetsplatsens specifika metoder är en större avgörande faktor som
avgör i vilken utsträckning kravhantering används. Dock tror jag att vetskapen om
konsekvenserna som dålig kravhantering kan medföra bättre kommunikation mellan kund och
utvecklare. De respondenter som studerat kravhantering visar också en större medvetenhet
angående hur viktigt det är med bra kommunikation.
4.7 Tid hör ihop med utbildning
Det kan vara svårt att äska tid för krav om kunden inte förstår nyttan med dem. Om
utvecklarna lyckas lägga fram ett bra argument för kunden och kan förklara fördelarna med en
bra grund, kan mer tid läggas på kravhanteringen. En viktig del för att lyckas med detta är
utvecklarnas utbildning. De respondenter som haft kravhantering som en del av sin utbildning
är också mycket medvetna om vikten av kommunikation mellan kund och utvecklare.
21
Deras medvetenhet gör att de kan jobba aktivt med att förklara fördelar med att jobba agilt
och samla in krav under projektets gång. De vet att det är viktigt att kunden hela tiden är med
och stämmer av med hur arbetet utvecklas och kan kontrollera nya krav som uppkommer. Om
kunden är medveten om vilka konsekvenser ändringar av krav kan ge kan detta i större grad
undvikas och chansen att det blir rätt från början är stor. Resultatet av denna studie visar på att
utvecklare med utbildning inom krav använder kravhantering i större utsträckning. Det visar
även på att de kan använda det på ett mer effektivt sätt eftersom de är medvetna om
konsekvenser som kan uppstå vid utebliven kravhantering. Utbildning är alltså en viktig
faktor som påverkar hur mycket tid och engagemang som läggs på kravhantering vid
utveckling av mobila applikationer.
22
5. Slutsats
I det här kapitlet presenteras slutsatserna som gjorts av undersökningen och uppsatsens
frågeställning besvaras. Här presenteras även förslag till fortsatt forskning.
Syftet med denna B-uppsats i Informatik är att undersöka i vilken utsträckning kravhantering
används vid utveckling av mobila applikationer.
Vi kan konstatera att mobila applikationer i dagsläget är något av en modefluga. Precis som
när internet kom ville alla ha en hemsida utan att egentligen ha någon tänkt affärsnytta med
den. Många utvecklare upplever på samma sätt idag att kunder vill ha en mobil applikation för
att hänga med i utvecklingen. Många av de funktioner som kunder tänker sig att deras
applikationer skall få passar egentligen bättre som responsiv webb.
Resultatet av den här undersökningen visar att sammarbete och kommunikation mellan
människorna i ett projekt är den viktigaste beståndsdelen för att avgöra hur mycket
kravhantering används. Om kommunikationen är dålig behövs mer tid för att reda ut behov
från båda parters håll. Utvecklare måste förstå vad kunden behöver och kunden bör veta vad
utvecklarna menar. Det kan vara svårt att få kunder att förstå nyttan med att samla in krav och
därmed används det inte i lika stor utsträckning.
Kundens intresse och engagemang har också visat sig vara en viktig avgörande del i hur man
arbetar med krav. Om kunden har ett stort intresse för utvecklarnas arbete är det större chans
att kommunkationen fungerar bra. Utvecklare och kund är på samma nivå. Eftersom alla
respondenter arbetar agilt betyder det att kraven hänger med och förändras under hela
projektets gång. Det är då viktigt att kunden är med och regelbundet stämmer av de nya
kraven och försäkrar sig om att arbetet är på rätt väg. Om kunden har ett stort engagemang är
chansen större att kunden vill följa upp arbetet.
När man ska arbeta med krav inför utveckling av mobila applikationer är det viktigt att ta
hänsyn till slutanvändarnas behov. Har man stor kunskap om applikationens målgrupp krävs
mindre kravhantering än om kunden är helt ny på marknaden. De faktorer man behöver ta
hänsyn till vid mobil utveckling är användarnas miljö och vilken bandbredd som kan finnas
där de använder appen. Vi pratar om mobilitet där mjukvaran kommer användas i olika ljus,
ljud och andra yttre omständigheter.
Fokus i undersökningen var tid, utbildning och budget. De har alla visat sig vara faktorer som
påverkar i vilken utsträckning kravhantering används. De fynd som varit mest intressanta
under projektets gång är kundens roll i kravhantering. Studien visar att utbildningen påverkar
utvecklarna som i sin tur påverkar kunden. Kunden påverkar tid och budget som i sin tur
påverkar i vilken utsträckning kravhantering används. En bra utbildning kan altså vara
nyckeln till en bra applikation där kunden är nöjd.
23
Som förslag till fortsatt forskning kan en djupare analys av kundens upplevelser vid
kravantering utföras. Det skulle vara intressant att undersöka vilka faktorerer som påverkar
kundens engagemang och intresse för kravhantering. Den här undersökningen har avsett
utvecklares perspektiv av kravhantering vid mobila applikationer. För att ta med sig de
viktigaste fynden av den här uppsatsen och gå vidare i en djupare forskning kan samma
frågeställning användas men istället utgå från kundens perspektiv.
24
6. Källförteckning
6.1 Muntliga källor
Respondent 1, Karlstad, 2014-07-23
Respondent 2, Karlstad, 2014-08-06
Respondent 3, Karlstad via telefon, 2014-08-18
Respondent 4, Karlstad via telefon, 2014-08-18
6.2 Tryckta källor
Ahlmark, C (2013). Prioritering och rangordning inom kravhantering. [Elektronisk].
Tillgänglig: http://konsultbolag1.se/prioritering-och-rangordning-inom-kravhantering [2014-
05-13].
Akademin för ekonomi, samhälle och teknik. (2014) Primär- och sekundärkällor, primär- och
sekundärdata. [Elektronisk]. Tillgänglig:
http://www.mdh.se/student/minastudier/examensarbete/omraden/metoddoktorn/soka-
information/primar-och-sekundarkallor-primar-och-sekundardata-1.27203 [2014-05-19].
Andersson, A. & Aderud. J (2014). Kravhantering - brister och lösningar. Örebro:
Handelshögskolan Informatik, Örebro Universitet.
Benyon, David, Turner, Phil & Turner, Susan (2005). Designing interactive systems: people,
activities, contexts, technologies. Harlow: Addison-Wesley.
Blom Westergren, E (2014). Att leva på apputveckling. [Elektronisk]. Tillgänglig:
http://www.mobil.se/tips-tricks/att-leva-p-app-utveckling#.U3SluCh9Ir4 [2014-05-16].
Cederberg, J & Sjöström J (2012). Utgångsappen - En rapport om utvecklingen av en
mobilapplikation. Södertörn: Södertörns högskola, Instituitionen för kommunikation, medier
och it.
Chung, L, Nixon B, Yu E, Mylopoulos, J (2000). Software Engineering. [Elektronisk].
Tillgänglig: http://www.utd.edu/~chung/RE/NFR-18-4-on-1.pdf [2014-07-16]
Computer Sweden (2014). Språkrådet. [Elektronisk]. Tillgänglig:
http://cstjanster.idg.se/sprakwebben/ord.asp [2014-05-07].
Dorsey, P (2005). Top 10 reasons why systems projects fail. [Elektronisk] Tillgänglig:
www.hks.harvard.edu [2014-07-16]
25
E-delegationen(2012). Vägledning för behovsdriven utveckling: Kvalitativa metoder.
[Elektronisk]. Tillgänglig:
http://www.behovsdrivenutveckling.se/verktyg/metoder/kvalitativa-metoder/ [2014-05-06].
Egger, F.N. (2000). Lo-Fi vs. Hi-Fi Prototyping: how real does the real thing have to be?
[Elektronisk] Tillgänglig: http://www.telono.com/en/articles/lo-fi-vs-hi-fi-prototyping-how-
real-does-the-real-thing-have-to-be/ [2014-07-21]
Eriksson, U. (2008). Kravhantering för IT-system. Malmö: Studentlitteratur.
Fowler, M. (2005) The New Methodology. [Elektronisk] Tillgänglig:
http://martinfowler.com/articles/newMethodology.html#FlavorsOfAgileDevelopment [2014-
08-17]
Görling, S (2009). Att arbeta med IT-projekt. Malmö: Studentlitteratur.
JanCan (2014). Hur lyckas man med kravinsamling?. [Elektronisk]. Tillgänglig: http://jancan-
konsult.com/2014/04/16/hur-lyckas-man-med-kravinsamling/ [2014-05-13].
Jenselius, M (2011). Här är de populäraste apparna till Iphone. [Elektronisk]. Tillgänglig:
http://www.idg.se/2.1085/1.364112/har-ar-de-popularaste-apparna-till-iphone [2014-05-15].
Johansson, H (2011). Gör kravinsamlingen så effektiv som möjligt. [Elektronisk]. Tillgänglig:
http://www.motivation.se/projektleda/business-analysis/gor-kravinsamlingen-sa-effektiv-som-
mojligt [2014-05-07].
Meyers, J. (2011) From Backpack Transceiver to Smartphone: A Visual History of the Mobile
Phone. [Elektronisk] Tillgänglig: http://smartphones.wonderhowto.com/inspiration/from-
backpack-transceiver-smartphone-visual-history-mobile-phone-0127134/ [2014-08-17]
Mobil (2013). 50 miljarderappar nedladdade i App Store. [Elektronisk]. Tillgänglig:
http://www.mobil.se/business/50-miljarder-appar-nedladdade-i-app-store#.U11TN1d9Ir5
[2014-05-06].
Nationalencyklopedin (2014) - Kommunikation. [Elektronisk] Tillgänglig:
http://www.ne.se.bibproxy.kau.se:2048/lang/kommunikation [2014-08-19]
Nationalencyklopedin (2014). Android. [Elektronisk]. Tillgänglig:
http://www.ne.se.bibproxy.kau.se:2048/lang/android/1915967 [2014-05-16].
Nationalencyklopedin (2014). Intressent. [Elektronisk]. Tillgänglig:
http://www.ne.se/lang/intressent [2014-05-13].
Nationalencyklopedin (2014). Mänskliga faktorn. [Elektronisk]. Tillgänglig:
http://www.ne.se/lang/mänskliga-faktorn [2014-05-15].
Nationalencyklopedin (2014). Struktur. [Elektronisk]. Tillgänglig:
http://www.ne.se/lang/struktur [2014-05-14].
26
Olsson, J & Svärd, J (2012). Kundnöjdhet vid användning av mobila applikationer: En
explorativ studie utifrån konsumentperspektiv. Karlstad: Informatik, Karlstad Universitet.
Ottersten, I & Balic, M (2007). Effect Managning IT. Malmö: Liber
Patel, R & Davidson, B (2008). Forskningsmetodikens grunder – Att planera, genomföra och
rapportera en undersökning. Malmö: Studentlitteratur.
Pohl, K. & Rupp, C. (2011). Requirements Engineering Fundamental. Santa Barbara, CA:
Rocky Nook
Rienecker, L & Stray Jörgensen, P (2008). Att skriva en bra uppsats. Malmö: Liber.
Robertson, Suzanne & Robertson, James (1999). Mastering the Requirements Process.
Harlow: Addison-Wesley
Rosén, J (2011). Appar VS mobilanpassning - När skall man använda vad?. [Elektronisk].
Tillgänglig: http://angrycreative.se/appar-vs-mobilanpassning-nar-skall-man-anvanda-vad/
[2014-05-07].
Rouse, M (2011). Iterative. [Elektronisk]. Tillgänglig:
http://searchsoftwarequality.techtarget.com/definition/iterative?src=itke+stub [2014-05-15].
Språkrådet (2014). App. [Elektronisk]. Tillgänglig:
http://www.sprakochfolkminnen.se/sprak/nyord/nyord/aktuellt-nyord/2013-10-20-app.html
[2014-05-06].
Vinderos, P. (2013). Vad betyder egentligen att jobba agilt? [Elektronisk] Tillgänglig:
http://www.webbstrateg.nu/vad-betyder-egentligen-att-jobba-agilt/ [2014-08-14]
Yafi, A. (2014). Interaktiva prototyper - En designers bästa vän.[Elektronisk] Tillgänglig:
http://screeninteraction.com/insights/2014/06/interaktiva-prototyper-en-designers.html [2014-
04-14]
27
7. Bilagor
Bilaga 1: Intervjuguide
Startfrågor
1. Vart jobbar du och i vilken utsträckning jobbar du/ni med att utveckla mobila
applikationer?
2. Vilken typ av kravhantering inför utvecklingen använder du/ni och vilka metoder används?
3. Vad skulle du säga är skillnaden mellan kravarbetet inför utveckling av en mobil
applikation och ett annat system?
Tid
1. Hur lång tid lägger du/ni på att arbeta med krav inför utveckling av en applikation?
2. Vad är det som avgör hur lång tid som läggs på kravhantering?
3. Hade ni/du gjort annorlunda om du/ni hade haft mer tid?
4. Har det hänt att du/ni varit tvungna att lämna kravhanteringen på grund av tidsbrist?
Budget
1. På vilket sätt påverkar budgeten hur mycket tid som läggs ner på kravhantering?
2. Hade ni gjort något annorlunda om det fanns mer pengar, isåfall vad?
Utbildning
1. Vilken utbildning har du?
2. Togs det upp någonting om kravhantering under din studietid, isåfall vad?
3. På vilket sätt tror du att din utbildning påverkar ditt sätt att jobba med kravhantering?
28
Bilaga 2: Respondent 1
Respondent 1 jobbar på IT-företaget Evry där respondenten är del av ett mindre team som är
specialiserade på mobilitet. Teamet utgör cirka 10 % av företaget som erbjuder olika IT-
lösningar.
Typen av metoder som används beror lite på kundens önskemål. De börjar med
effektkartläggning i form av workshops där man tar fram affärsnyttan. Efter det följer flera
workshops där man bestämmer vilken teknik som skall användas för att utveckla
applikationen och andra beslut kring projektets gång. I de fall det är möjligt görs även
fältstudier ute hos kunden för att få en bättre bild av vad kunden behöver. För att säkerställa
användarvänligheten har teamet nyligen börjat använda sig av interaktiva prototyper där
kunden får möjlighet att se och testa användargränssnittet på ett helt annat sätt än tidigare då
kunden endast erhöll ett beskrivande textdokument över hur applikationen skulle fungera.
Den färdiga kravdokumentationen består av prototyper för att beskriva användardelen och text
för att täcka integration och tekniska bestämmelser.
Den största skillnaden på kravhanteringsarbetet anser respondenten vara att ta hänsyn till
användarnas arbetsmiljö. Eftersom det handlar om mobilitet så skall applikationen kunna
användas i olika ljus- och ljud-förhållanden. Man måste även ta hänsyn till att användarna
använder olika typer av operativsystem och olika modeller på telefoner och surfplattor. En
annan skillnad kan vara att hitta rätt riktning på applikationen. Om applikationen är en
förenklad version av en hemsida eller ett större system vill man ha begränsad funktionalitet
för att göra den enklare att använda. Det gäller då att lägga fokus på rätt funktioner för att få
fram affärsnyttan. Vid utveckling av mobila applikationer används även fältstudier i mycket
större utsträckning än vid utveckling av en hemsida.
När det gäller hur mycket tid som läggs på kravarbetet säger respondenten att arbetet fortlöper
genom hela projektet. Eftersom de arbetar agilt så blir "klara" i den betydelsen inte att de
lägger undan kraven utan de finns med hela tiden. Dock blir det större fokus i början av
projektet så kraven skall tas fram och i slutet för att stämma av att kraven uppfyllts. Har man
gjort ett bra arbete med att samla in rätt krav i början av projektet krävs mindre tid och arbete
på utvecklingen.
Målet är inte att lägga så mycket tid som möjligt utan snarare att använda tiden bra och samla
in rätt krav från början. Gör man ett bra förarbete sparar man tid vid själva utvecklingen. En
kund kan säga att utvecklarna har en viss tid på sig att samla in kraven och då måste de
anpassa sig efter det.
De hade definitivt lagt mer tid på förarbetet om mer tid fanns. Det kan vara svårt att motivera
för kunden att mer tid behövs för att reda ut krav. Det går däremot lättare att äska tid för
utvecklingen eftersom kunderna oftare förstår nyttan med det. Desto mer mogen mobiliteten
blir desto lättare kommer det bli att kunna lägga tid på kravhantering.
Det har hänt att kravhanteringsarbetet har avslutats på grund av tidsbrist i projektet men då
har det berott på att projektet inte startat i rätt läge.
29
När det kommer till budgeten för projektet anser respondenten att budgeten inte påverkar
kravhanteringsarbetet speciellt mycket. Procentuellt sett så används lika mycket tid till att
samla in krav för ett dyrt projekt som för ett billigare. De anser att det är viktig del av
projektet för att kunna göra ett bra arbete. Det krävs dock engagemang från kunden för att
kunna göra ett bra förarbete. Det svåraste är att förklara nyttan med kravhantering för kunden.
Återigen är det svårare att motivera kunden att betala för utveckling än för kravhantering.
Om det fanns mer pengar i projekten skulle det läggas mer tid på möten mellan olika
kompetenser. Det är här missförstånd kan uppstå. Om kravhantering är svårmotiverat för
kunden är interna möten mellan kollegorna ännu svårare. Det känns ofta självklart för
kunderna att de som jobbar med att samla in krav ska ha full koll på vad utvecklare eller
testare i sin tur gör.
Respondenten har en egen ihopsatt utbildning inom informatik med inriktning
interaktionsdesign motsvarande en fil. kand.
Det har under utbildningen pratats väldigt mycket om kravhantering. Mycket om de problem
som finns på företaget när det handlar om att motivera nyttan med kravhanteringen och brister
i utvecklingen när inte kravhantering utförs. Desto mer den mobila marknaden mognar desto
lättare kommer det bli att motivera vikten av användbarhet. Affärsnytta och användbarhet är
viktig oavsett projekt och det behöver inte bara handla om IT-projekt.
Respondenten tror sig se lösningar på ett annat sätt tack vare sin utbildning. Utbildningen har
även bidragit till att se nyttan med det man levererar och se helheten av arbetet. Det hjälper
till väldigt mycket i arbetet om man kan se vilka problem som kan lösas genom att ha ett
bredare perspektiv.
I övrigt ser man en positiv trend i utvecklingen av mobila applikationer. Kraven på
användarvänlighet ökar. Även om det handlar om appar som används inom företaget. Det är
lika viktigt att en utvecklare skall ha en bra app som att en snickare ska ha en bra hammare.
30
Bilaga 3: Respondent 2
Respondent nummer två jobbar på ett litet relativt nystartat företag som heter Samverkan där
de jobbar med att ta fram helhetslösningar åt sina kunder. De tar fram skräddarsydda
lösningar åt externa kunder där går från att spåna idéer till att utveckla produkten. När de har
levererat sin produkt jobbar de även med att underhålla sina färdiga system. Ungefär 25 % av
deras verksamhet består av mobilutveckling.
När det kommer till metoder för att samla in krav jobbar de uteslutande agilt. Det betyder att
de jobbar i etapper där kravhanteringen följer med genom hela projektet. Kravspecifikationen
blir då inte klar direkt utan man börjar med ett uppstartsmöte där man sitter tillsammans med
kunden och tar fram idéer och kommer fram till en utgångspunkt för att börja utveckla.
Resultatet av detta kan vara en lista på funktionella och icke-funktionella krav som skall
uppfyllas men man använder sig aldrig av långa kravdokumentationer. Beroende på kunden
kan de även ta fram en prototyp för att ännu tydligare kunna visa hur applikationen kommer
fungera i slutändan. Med en prototyp är det lättare att få en känsla eftersom det är där
användbarheten ligger i en mobil applikation. Respondenten jobbar också enligt utveckligs
sättet scrum där de sätter upp lappar med saker som skall göras i projektet. Det kan vara
småsaker som att flytta en knapp eller ändra en färg, men så fort kunden begärt det blir det ett
krav som sätts upp på en lapp. När de är klara stämmer de av med kunden antingen dagligen
eller veckovis. Här kontrollerar de att utvecklingen går åt det håll som kunden vill och vilka
nya krav som finns. Kravhanteringen blir alltså inte klar på en gång utan kraven är någonting
som kommer efter hand.
När det kommer till skillnader mellan kravhanteringsarbetet vid mobila applikationer och
andra system finns det ingen skillnad på hur de jobbar. Även här har de ett uppstartsmöte med
kunden där de tar fram funktionella och icke-funktionella krav. De anser att designmässigt
finns samma krav en hemsida och en applikation och de gör alla sina hemsidor responsiva.
Om en kund kommer och vill göra en app så försöker de ifrågasätta affärsnyttan. Vill ett
företag ha en applikation vid sidan av en hemsida behöver den ha speciell funktionalitet för att
deras kunder skall ladda ner och använda den.
Tiden som de lägger ner på kravhantering är svår att uppskatta eftersom de jobbar agilt men
deras uppsamlingsmöte tar i genomsnitt en dag innan de börjar utveckla. Deras kunder vill ha
någonting snabbt och det är viktigt att inte lägga allt för mycket tid på kraven i början
eftersom de hela tiden förändras. Tiden för kravhantering beror på hur "luddig" kundens idé
är. Om kunden vill ha en app för att höja affärsnyttan behöver de först tänka ut vad som kan
öka affärsnyttan och vilken sorts funktionalitet som behövs i en applikation. Kundens
engagemang är en viktig faktor för hur lång tid som läggs på att ta fram krav. Exempel på när
mindre tid läggs är när kunden kommer med en klar utformad specifikation, när kunden inte
bryr sig eller har litet tekniskt intresse. Det finns kunder som bokstavligt talat litar blint på att
produkten de får i slutändan blir bra. De gånger det tar längre tid är då kunden vill ha en
prototyp på applikationen. Då kan tiden för kravhanteringen sträcka sig upp till några dagar.
Eftersom respondenten jobbar på ett företag som tar fram skräddarsydda lösningar så är inte
31
noggrant utförd kravdokumentation lika viktigt som om de hade byggt generella lösningar
som används av många olika företag.
Om det fanns mer tid och viljan fanns hos kunden skulle det definitivt läggas mer tid på
kravhantering i början. Man skulle kanske lägga flera dagar då man bara spånar idéer och
pratar med kunden för att komma fram till en så bra utgångspunkt som möjligt.
Respondenten har aldrig varit med om att de behövt lämna kravhanteringsarbetet på grund av
tidsbrist. Krav måste prioriteras och styras efter vad som finns tid och pengar för. Det är hela
poängen med att arbeta agilt. När man jobbat i branschen ett tag får man ett hum om vad som
skall göras och hur lång tid det tar.
Desto mer tid som läggs på kravhantering desto mer pengar kostar det. När kunden får sin
faktura står det inte specificerat krav utan det är en del som är inbakat i projektet.
Finns det mer pengar i budgeten för projektet så kan man göra mer funktionalitet. Om kunden
fick välja mellan en veckas kravdokumentation och en veckas jobb med fokus på att utöka
funktionaliteten på applikationen så är antagligen valet ganska enkelt.
Respondenten är datavetare och har en civilingenjörsexamen i IT.
Under utbildningen läste knappt någonting om kravhantering. Det enda var litegrann om en
metod som kallas RUP - Rational Unified Process. Den bygger på en metod där man
dokumenterar funktionella och icke-funktionella krav. Här använder man sig av
användningsfall och scenarion för att ta reda på krav som verksamheten har.
Utbildningen påverkar inte sättet som respondenten arbetar med kravhantering. Det är snarare
arbetsplatsen som påverkar en och bestämmer vilket arbetssätt man använder. Man anpassar
sig efter företagets metoder.
32
Bilaga 4: Respontent 3
Den tredje respondenten i undersökningen jobbar på företaget Knowit inom ett område som
heter webb och digital. Respondenten sitter mestadels med sälj och systemarkitektur och är
ansvarig för att sammanhålla många projekt. Den intervjuade jobbar både med mobila
applikationer och responsiva hemsidor som är mobilanpassade.
Respondenten anser att det är fler företag som har nytta av en hemsida anpassad för mobil
snarare än en applikation med egen funktionalitet. Appar är ett relativt nytt koncept och därför
blir det en modefluga. Alla ska ha en app utan att de egentligen har någon affärsnytta. Av alla
kunder så är cirka 80 % av deras krav ren information som skall ut. Det görs oftast mest
effektivt med en hemsida istället för att lägga tid och pengar på att skapa en app som ska
fungera till alla olika operativsystem. Det blir onödigt dyrt att bygga ut och det är slöseri med
resurser som skulle kunna läggas på annat.
Företaget jobbar uteslutande agilt med en del inslag av Scrum. För att samla in krav använder
de sig av en backlog där kraven sätts upp. För att ta fram affärsnyttan använder de sig av
effektkartläggning där man ställer frågor som: "Varför gör vi det här?", "Vad har vi för syfte
med den här applikationen?", "Vad behöver målgruppen kunna göra?". Detta görs för att
förvissa sig om att rätt saker byggs och att det läggs fokus på rätt saker. Företaget använder
sig även av sketching där skelettskisser används för att fånga färg och form.
Interaktionsdesign är också en viktig del för att avgöra hur systemet bör fungera. Metoderna
de använder beror till stor del på hur kunden vill ha det.
När jag frågar om prototyper är något som används säger respondenten att de används till viss
del. Den personliga erfarenheten respondenten har är att protyper är något man lagt lite tid
och jobb på att skapa och att man då blir lite rädd för att ändra dem. Det är mycket enklare att
sudda, skissa och diskutera med ritningar på exempelvis en whiteboardtavla. Man bör inte
vara rädd för att komma med idéer i det här stadiet. Det viktiga är att lyssna på kundens
önskemål och inte vara rädd att göra fel. "Kunden är specialisten på sin verksamhet". Det är
kunden och utvecklarna tillsammans som kan göra ett bra jobb där samspelet tillverkar
slutresultatet.
Skillnaderna på kravarbetet mellan mobila applikationer och andra system är egentligen
obefintliga. Vi försöker se till kundens behov oavsett vilken mjukvara det handlar om. Men
när det kommer till själva sättet att tänka handlar det mycket om miljön användarna kommer
befinna sig i. Applikationen kommer användas olika miljöer där användaren är på språng. Det
kan vara högt ljud, starkt ljus och kort om tid. Användargränssnittet bör vara enkelt och lätt
att använda i stressade situationer. Man måste också ta hänsyn till att bandbredden kan vara
begränsad. En annan viktig aspekt att tänka på när man utvecklar för mobil är sökfunktionen.
Användaren befinner sig i ett gränssnitt där man inte orkar trycka sig igenom massa data utan
man ska kunna söka och hitta informationen snabbt.
Tid som läggs på kravhantering beror på projektets storlek och lösning. Det är ingen skillnad
på tid för kravhantering vid utveckling av olika mjukvaror utan vi anpassar oss även här efter
33
projektets och kundens behov. Vi siktar på att bygga en långvarig relation med kunden så
kravarbetet måste få ta den tid det kräver.
Viktiga faktorer som påverkar hur mycket tid som läggs är hur snart appen måste lanseras,
kundens budget och mognad. Om vi haft andra projekt och samarbeten med kunden tidigare
krävs oftast inte lika mycket tid som om kunden är helt ny inom affärsområdet. Det beror
också lite på om appen är affärskritisk. Om företagets överlevnad hänger på applikationen är
det viktigt att appen får rätt funktionalitet och det tar förstås mer tid. Det beror på kundens
engagemang och samspel mellan utvecklare och kund.
Kraven prioriteras alltid efter tiden som finns men man önskar självklart alltid mer tid åt
förstudien. Tiden skulle läggas på att möta kunden och göra en djupare analys på kundens
behov. Det finns alltid en konkurens mellan olika företag och kunden går till den utvecklare
som ger dem mest valuta för pengarna.
Frågan om tidsbrist för kravhantering har egentligen två svar. Antingen distribuerar man tiden
som finns eller så får man prioritera de krav som finns så man hinner med. Man kan lösa
tidsbrist med att samköra aktiviteter som så man hinner.
Innan man sätter igång görs en projektplan där man tar fram en budget för projektet. Här
räknar man på hur mycket timmar man måste lägga för de fasta delarna i projektet och
fördelar resten jämt där de behövs. Märker man att budgeten blir för knapp får man diskutera
med kunden hur de kan prioritera om tid och pengar. Har man ett bra samarbete med kunden
har man också större förståelse från kundens sida om projektet inte går som planerat. Kunden
är då insatt i varför projektet hamnade fel.
Om ett specifikt projekt fick en större budget skulle mer tid läggas på de mjuka delarna som
oftast prioriteras bort. Om 20 % mer tid lades på kravhantering, testning och prototyping
skulle slutresultatet bli mycket bättre.
Respondenten har en universitetsutbildning som ekonom med lite IT bakgrund. Under tiden
på universitetet fanns det ingenting om kravhantering. Dock läste respondenten om det på
gymnasial nivå och har även gått andra fristående kurser där krav berörts.
Respondenten anser att utbildningen som ekonom ger stora fördelar dagligen i jobbet. Det är
lättare att ligga på samma nivå som kunderna. Man måste kunna omsätta affärsnytta till ett
krav för att kunden ska få ut så mycket som möjligt. Kunden är den som ger slutresultatet och
det är viktigt att kunna ha ett bra samarbete. Det kan även vara bra att läsa på om kunden inför
ett nytt samarbete för att bättre förstå vad de behöver.
34
Bilaga 5: Respondent 4
Den sista respondenten i undersökningen arbetar på Ninetech AB där respondenten är
kundansvarig rådgivare. Det innebär att man är delaktig i kundens kravställning och i teamet
men sitter inte själv och utvecklar applikationer.
Det beror på kundens önskemål. Man kan säga att alla metoder används beroende på hur
mycket arbete kunden själv har gjort. Ibland kan man ha en mindre duktig beställare som tror
sig ha gjort en kravspecifikation. Då måste vi gå in och göra en förstudie där man tar reda på
vad kunden verkligen behöver. Ibland kan kunden vara insatt och kommer med en mycket
utförlig kravspecifikation då vi som utvecklare inte behöver göra mycket förarbete alls.
Generellt sett är 9 av 10 inte fullständiga kravspecifika så då måste en sammanställning av
kundens krav göras för att ta fram en bra grund för fortsatt arbete.
Det är väldigt stor skillnad på kravhantering mellan utveckling av mobila applikationer och
andra system. Om man ser på i Iphone till exempel så tillämpar det en mycket mindre yta att
jobba på. Här är användarvänligheten viktig. Man måste tillgodose vilka miljöer som
användaren befinner sig i. Om en app tillverkas för indstri måste man exempelvis tänka på
vilket ljus användarna kommer befinna sig i när de använder appen, om de har skitiga händer
och vilken uppkoppling de har. Det finns otroligt många enheter och operativsystem att ta
hänsyn till när man utvecklar mobila applikationer. Det finns ju tre olika versioner av iphone
till exempel.
Tiden som läggs på kravhantering är det mestadels budgeten som styr. Ibland kan det läggas
tjugo timmar till flera hundra timmar beroende på hur komplex appen är. I snitt läggs runt
åttio till hundra timmar.
Budgeten hos kunden är det som avgör. Om kunden inte har råd att göra en ordentlig
kravspecifikation avstår de hellre eftersom det i slutändan är företaget som ska stå för att
produktionen blir bra. Kundens intresse är avgörande i den här situationen. Saknar kunden
engagemang får företaget gå i och ta ett större ansvar. Dock är de flesta kunder väldigt
intresserade när det gäller mobila applikationer eftersom ny teknik alltid är kul och
spännande.
Om det fanns mer tid skulle respondenten i första hand lägga mer fokus på prototyper för att
komplettera upp kraven. Prototyper gör det lättare för kunden att få en känsla för hur appen
kommer bli i slutändan och det sparar tid i längden då man inte behöver arbeta om
applikationen på grund av att kunden inte är nöjd. Respondenten skulle även vilja lägga mer
tid på att testa prototypen med den tänkta målgruppen. Det har väl hänt att du laddat ner en
app och testat den en gång för att sen aldrig mer använda den. Det är det som blir
konsekvenserna av att man inte testat appen mot den tänkta målgruppen.
Ja, på sätt och vis kan man säga att kravhanteringen lämnats på grund av brist på tid. I vissa
fall har kravhanteringen blivit klar till 80 % men där man ändå kan lansera en första version
av appen. Kraven förändras hela tiden under arbetets gång. Utmaningen blir att ifrågasätta,
35
utmana och diskutera kundens specifikation. Företaget startar dock aldrig upp ett projekt utan
att ha gjort ett bra förarbete.
När kunden kommer till företaget har de många gånger bara budgeterat för produktion.
Kunden måste då antingen utöka budgeten eller minska funktionalitet för att få tid till
kravhantering. Ibland kan det vara svårt att motivera för kunden att det behövs tid för
kravinsamling. Om kunden inte förstår är vi antagligen inte rätt leverantör.
Som tidigare nämnts hade man lagt mer tid på prototyper mot den kravbild man har. Mer
tester där man måste ha rätt målgrupp. Om appen byggs för industri måste appen vara testad
av industriarbetare. Myndigheter som landsting har enligt erfarenheter visat sig vara bättre på
den här typen av test än andra icke statliga verksamheter. Respondenten tror att detta kan bero
på att de har högre press på sig att deras kunder måste använda deras appar. Om en app inte
används har mer eller mindre dess syfte kastats bort.
Respondenten har som grund en multimediateknisk utbildning på gymnasienivå följt av
juridik och företagsekonomi på högskola.
Det har inte funnits någonting om kravhantering under respondentens utbildning. Det har
istället blivit att man tagit eget ansvar för att lära sig om de olika delarna för kravhantering.
När det kommer till den biten har olika arbetserfarenheter inom projekt och olika målgrupper
gett mer kött på benen än vad utbildningen gjort. Man lär sig också en stor del av kollegor.