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.