Kravhantering i systemutvecklingsprojekt: för att minimera risken för tvetydigheter

Kravhantering i systemutvecklingsprojekt

för att minimera risken för tvetydigheter

Erik Elebro

Systemvetenskap, kandidat 2020

Luleå tekniska universitet

Institutionen för system- och rymdteknik

Abstract

It is common for companies to use IT systems to facilitate and support their business processes. IT systems functions as a core and companies are therefore trying to gain competitive advantage by creating useful systems.

Developing IT systems is a challenging process and it still happens today that IT projects fail. The biggest reasons for this happening are considered to be lack of

structure, poor communication and prioritization of requirements. The reason for this is usually that there are ambiguities about the requirements. Ambiguities about the requirements can arise when the parties involved do not use the same terms or denotation e when communicating about requirements. This leads to

misinterpretation of important concepts about the future system.

The purpose of this study is to identify challenges and success factors for reducing the risk of ambiguities in the requirements management process for system development projects from system developer perspective and ensuring the usability of an IT

system. To achieve the purpose of the study, the author chose to use a small N-study with a semi-structured interview guide. The interviews were conducted on three system developers and one project owner.

The conclusions drawn from the study were, to reduce the risk of ambiguity, communication is vital. It is important that both parties use the same terms and denotations when communicating about requirements and also consensus when it comes to important concepts. A concept can have several meanings and can thus be interpreted in more than one way. Therefore, it is important to find out these early in the management process. The use of efficient processes in system development projects is also important to capture end-users' functional and non-functional

requirements, so that the usability and utility of systems emerges. It is also important that system developers and project commissioners initially set aside time in a system development project to agree on a common goal with the IT system.

Sammanfattning

Idag är det vanligt att företag använder sig av IT-system för att underlätta och stödja sina affärsprocesser. IT-systemen fungerar som kärnan i ett företag och företag försöker därmed få konkurrensfördel genom att skapa användbara system.

Att utveckla IT-system är en utmanade process och det händer än idag att IT-projekt misslyckas. Största anledningarna till att det händer anses vara bristande struktur, dålig kommunikation och prioritering av kraven. Orsaken till att detta är oftast att det råder tvetydigheter kring kraven. Tvetydigheter kring kraven kan uppstå när de

involverade parterna inte använder sig av samma referensramar vid kommunikation kring krav vilket leder till att viktiga begrepp misstolkas, utvecklare saknar

domänspecifik kunskap eller vid dokumentation av krav etc.

Syftet med denna studie är att identifiera utmaningar och framgångsfaktorer för att minska risken för tvetydigheter i kravhanteringsprocessen för

systemutvecklingsprojekt ur ett beställar–och systemutvecklarperspektiv och säkerhetsställa användbarheten ett IT-system. För att uppnå studiens syfte valde författaren att använda sig av en liten N-studie med en semi strukturerad

intervjuguide. Intervjuerna gjordes på tre systemutvecklare och en projektägare.

Slutsatserna som drogs från studien var, för att minska risken för tvetydigheter är kommunikation vital. Det krävs att båda parter använder ett gemensamt

referensramverk vid kommunikation i skrift och tal och även konsensus när det kommer till viktiga begrepp. Ett begrepp kan innefatta flera betydelser och kan därmed tolkas på fler än ett sätt. Därför är det viktigt att reda dessa tidigt i kravhanteringsprocessen. Även att använda sig av effektiva processer i

systemutvecklingsprojekt är viktigt för att fånga slutanvändarnas funktionella och icke-funktionella, så att användbarheten och nyttan i system framkommer. Det är också viktigt att systemutvecklare och projektbeställare initialt i ett

systemutvecklingsprojekt avsätter tid för att komma överens om ett gemensamt mål med IT-systemet.

Innehållsförteckning

1. Inledning ... 1

1.1 Problemformulering ... 2

1.2 Syfte... 5

1.3 Avgränsningar ... 5

2. Teorier ... 6

2.1 Systemutvecklingsprojekt ... 6

2.2 Projektmetoder ... 7

2.3 Sekventiell utveckling ... 7

2.4 Agil Utveckling ... 8

2.5 Krav och kravhantering i Systemutvecklingsprojekt ... 9

2.6 Typer av krav ... 10

2.7 Kravspecifikation ... 11

2.8 Kravinsamlingsprocessen ... 12

2.9 Kravhantering ... 13

2.10 Tvetydigheter i systemutvecklingsprojekt ... 14

2.11 Summering Teori ... 15

3. Metod ... 17

3.1 Forskningsansatser ... 17

3.2 Undersökningsdesign ...18

3.3 Urval ... 19

3.4 Datainsamlingsmetod ... 19

3.5 Analysmetod ... 20

3.6 Litteraturöversikt ... 21

3.7 Validitet ... 22

3.8 Reliabilitet ... 23

3.9 Etik ... 24

4. Resultat & Analys ... 25

4.1 Utmaningar ... 26

4.2 Kommunikationssvårigheter ... 26

4.3 Bristande struktur ... 27

4.4 Övriga faktorer som leder till tvetydigheter ... 29

4.5 Framgångsfaktorer ... 30

5. Slutsats ... 33

6. Förslag till fortsatt forskning ... 34

7. Referenser ... 35

Appendix ... 41

Appendix 1... 41

Appendix 2 ... 44

1

1. Inledning

Digitalisering innebär att information omvandlas från analogt till digitalt. Text, bilder, produkter och företag kan alltså ses via en digital skärm. Digitalisering har slagit igenom inom många områden som vi möter dagligen och mobiltelefoner, surfplattor, datorer men även aktivitets- och hälsoarmband är exempel på produkter som utnyttjar digitala tjänster. Även digitala plattformar har bidragit till möjligheten att närvara vid möten via chatt-, telefon- och videosamtal istället för att befinna sig på den fysiska platsen (NE Nationalencyklopedin, 2019). Digitaliseringen har alltså medfört stora fördelar, där produkter och sammankomster numera kan göras hemmavid, via elektronisk utrustning. “I dag har de flesta i Sverige tillgång till internet och många använder internet dagligen, varav de flesta använder en

mobiltelefon. Totalt över 6,5 miljoner svenskar, i åldern 16 till 85, använder mobilen för att ansluta till internet” (Digitaliseringsrådet, 2019). Företag har insett att

etableringen av attraktiva internetsidor eller andra sätta ett reklamföra sina produkter, är avgörande för deras överlevnad.

Digitaliseringen har även lett till att allt fler personer interagerar med IT-system vilket också ställer högre krav på designen av ett användargränssnitt. Ett

användargränssnitt är det som användare interagerar med vid användningen av ett IT-system, som till exempel startsidan på hemsidan där menyval finns tillgängliga.

Sättet dessa användargränssnitt är designade på har stor betydelse för

användarupplevelse och funktionalitet för användarna (Stone et al., 2005). Ett gränssnitt som är designat i en ologisk följd kan leda till att man som användare inte hittar den funktion man söker. Färger, stil på texten, ikoner m.m. bidrar även till användbarhet i ett system (Ormeno et al., 2013).

Användbarhet är definierat i ISO 9241-11, som till vilken utsträckning användare kan

använda ett system för att uppnå sina mål med effektivitet och tillfredsställelse i ett

specifikt sammanhang för användning (Obeidat & Salim, 2010). Användbarheten i

ett system är dess funktioner som möjliggör att användare ex. kan gå tillbaka och

ångra sig eller köra långt utdragna processer i bakgrunden medans användaren

arbetar på en annan uppgift (Röder, 2012).

2

Att implementera ett användbart IT-system är inte helt enkel då användbarhet tas ofta för given och fokus ligger ofta blir att snabbt leverera ett fungerande system.

(Gulliksen & Göransson, 2002). Användbarheten är en viktig faktor för ett lyckat IT- system men dess funktionalitet är ofta inte alls specificerad i kravspecifikationen vilket leder till att systemets fullständiga känsla försämras.

En Kravspecifikation är ett skriftligt dokument på kraven på ett IT-system eller tjänst. Kravspecifikationen utvecklas av utvecklingsorganisationen tillsammans med projektbeställaren utifrån beställarens behov (Röder, 2012). En projektbeställares behov skall motsvara kravspecifikationen men mestadels fungerar det inte att konvertera direkt från projektbeställarens behov till systemkrav eftersom i de flesta fallen har inte projektbeställaren tillräcklig kunskap kring den tekniska delen i utvecklingen därför krävs det ett nära samarbete mellan projektbeställare och utvecklingsorganisationen för att konkretisera, förtydliga och enas om realistiska krav tillsammans (Mordecai & Dori, 2017).

1.1 Problemformulering

Användare stöter än idag på problem vid användning av system. Det kan vara att man inte hittar funktionerna på en webbplats eftersom det är för krångligt att

navigera sig och användaren måste lägga ner onödigt mycket kraft och energi för att kunna utföra sin uppgift. Röder (2012) menar att krävs stöd i form av kunskaper, processer, metoder och verktyg för att utveckla användbara system annars kan konsekvenserna bli att användare ger upp och slutar använda tjänsten.

När användare interagerar med datorsystem så görs det via gränssnitt. Förenklat betyder gränssnitt det man ser på skärmen och varje interaktion med skärmen har ett eget protokoll, ett språk eller dataformat för att kommunikationen mellan den personen som navigerar med datorn blir rätt (McKay, 2013).

Tidigare användes datorer bara av personer som var specialiserade inom it och data men i dagsläget använder allt fler personer datorer utan att behöva sådan

specialkunskap. Det utökade datoranvändandet har medfört högre krav på

utvecklingen av användargränssnitt som stödjer personer med olika datorkunskap

3

och användningsområden (Stone et al,, 2005). Att skapa nya gränssnitt är en invecklad process, där ett knapptryck kan innebära att en viss tjänst startas, att information söks fram eller att en bild tas. Men resultatet av processen blir att systemet förstår användaren - och att användaren förstår systemet (Stone et al., 2005).

Anvisningar om att komma vidare på sidan genom pilar eller att val ska ha ett logiskt samband, eftersom det påverkar även användarens förståelse för systemet och i synnerhet när det handlar om att välja och köpa en produkt. När e-handel ökat gradvist, och ersatt många butiker, kan tjänster, det vill säga E-handels webbplatser vara ur försäljningssynpunkt det viktigaste för att locka till en vara. Men att

framställa användbara system ur konsument och försäljningssynpunkt handlar om att se alla delar som bidrar till dess användbarhet och inte endast design, utvärdering eller analysarbete av försäljningssiffror (Gulliksen & Göransson, 2002).

Eftersom kraven på system har utvecklats från att bara uppfylla funktionella krav samt förväntat sig kvalitet, till att numera efterfråga behagliga funktioner - så börjar den digitala designen av angnäma produkter ta centrum. Företag försöker därmed få konkurrensfördel genom att skapa ett starkt produktbehov (Oh & Khong, 2003). På grund av dessa skiftande omständigheter ställs det större krav på kravhanteringen vilket är en nyckelaktivitet i processen för IT-system där det slutgiltiga målet är att fastställa krav som skall systemet skall uppfylla. Detta det är inget enkelt uppdrag enligt Aasheim & Yang-Yang Zhao (2017). Kulkarni (2008) menar på att för att klara av denna utmanande process och skapa ett framgångsrikt IT-system är det

nödvändigt att tillgodose projektbeställare såsom slutanvändares krav på det

blivande systemet. Dessa intressenter kan komma att ha olika krav på hur det skall se ut och det gäller att dessa konflikter hanteras av utvecklingsorganisationen för att skapa en gemensam förståelse för kraven på hur det nya systemet skall bli. Det är likaså viktigt att kunna hantera att kraven kommer att behövas modifieras, revideras eller tas bort (Kulkarni, 2008).

4

5

1.2 Syfte

Syftet med denna studie är att identifiera utmaningar och framgångsfaktorer för att minska risken för tvetydigheter i kravhanteringsprocessen för

systemutvecklingsprojekt ur ett beställar–och systemutvecklarperspektiv och

säkerhetsställa användbarheten ett IT-system. Mer specifikt besvaras följande frågor:

- Vilka faktorer är viktiga att tänka på vid utveckling av en kravspecifikation?

- Vilka behov av tydliggörande behöver en systemutvecklare för att säkerhetsställa kravhanteringen?

- Hur uppnås användbarhet i en kravhanteringsprocess?

1.3 Avgränsningar

Studien kommer att identifiera och redogöra för utmaningar och framgångsfaktorer i kravinsamlingsprocessen i systemutvecklingsprojekt därför har författaren valt att enbart studera sambandet mellan projektbeställare och utvecklare och valt att

avgränsa bort slutanvändares perspektiv. Motivet till detta är att författaren anser att området med slutanvändares perspektiv blir för brett för denna studie.

6

2. Teorier

Detta avsnitt sammanfattar den litteratur inom de områden som studien fokuserar på. Teorierna är valda med avsikt att uppfylla studiens syfte genom att

inledningsvis beskriva området systemutveckling för och dess olika utvecklingsmetoder för att därefter begreppet krav, olika sorters krav, kravspecifikationen som är det dokument som beställaren specificerar sina önskningar på systemet, hur man går tillväga för att specificera kraven och slutligen tvetydigheter i systemutvecklingsprojekt.

2.1 Systemutvecklingsprojekt

Systemutvecklingsprojekt kan ha sin grund i att en beställare ser potential i att ett nytt system kunde gynna verksamheten. Baserat på det mål och syfte med ett system som beställaren har. Därefter formuleras ett behov som systemlösningar ska

tillfredsställa. Utifrån behovet och syftet med IT-systemet gör en kravställning för att uppfylla dessa (Wiktorin, 2018).

Systemutveckling kan beskrivas som en process för att utveckla IT-system som innefattar analys, programmering, design och test av ett system. Systemutveckling sker i dialog med en beställare, eller människor som skall använda systemet

(Leffingwell, 2011).

Systemutveckling har kommit att blivit en av de viktigaste teknologierna i världen och mycket av den moderna världen hänger på att IT-systemen fungerar. Över tid har applikationer och IT-system blivit allt mer omfattande medan kraven på kvalitet har ökat och leveranstiden för systemen minskat (Gurcan & Kose, 2017).

Projektmetoder som vattenfallsmodell har använts vid systemutvecklingen men har idag kommit att bli föråldrade då de inte hänger med i dagens utveckling av

användbara IT-system (Leffingwell, 2011). På grund av detta har utvecklare börjat röra sig mer mot agila metoder eftersom de anses smidigare och mer

anpassningsbara vid hantering av systemkrav vilket har visat sig ge snabbare

7

leveranstid, högre systemkvalitet och större tillfredställelse hos användarna (Lyytinen et al., 2011).

Projektbeställare bör känna till vilken utav dessa utvecklingsmetoder som används när de anlitar utvecklare på grund av att det påverkar i vilken omfattning, vilka roller, hur mycket tid och när arbetet kring krav sker (Eriksson, 2007).

2.2 Projektmetoder

I ett systemutvecklingsprojekt tillämpar man ofta någon metod för att underlätta projektarbetet. En projektmetod som, som är ett tillvägagångssätt för att understödja projektarbetet. Inom systemutvecklingsprojekt kan dessa projektmetoder vara av sekventiell och/eller agil typ. Sekventiella projekt kännetecknas av utveckling som sker stegvis, medan agila projekt kännetecknas av att vara mer lättrörliga.

2.3 Sekventiell utveckling

Vattenfallsmodellen är ett känt alternativ av en sekventiell utvecklingsmetod.

Sekventiell utveckling är när hela systemet utvecklas i en enda frekvens och

avancemanget i processen sker i ett flöde genom olika faser som omfattar planering, kravanalys, designanalys, programmering, testning samt underhåll där varje steg skall vara färdigt innan nästa steg påbörjats och det är inte möjligt att gå tillbaka till föregående steg (Leffingwell, 2011).

Faserna är oberoende av varandra samt överlappar inte heller. Vattenfallsmodellen är beroende av att kraven skall vara tydliga, lättbegripliga och en genomgående dokumentation av dessa. Problemen med detta är att oftast är inte kraven tydliga och lättbegripliga och de kan komma att ändras under utvecklingens gång vilket leder till projektförseningar, ökade kostnader och en slutprodukt som inte uppfyller de initiala kraven (Liu & Wei, 2018). Lyytinen (2011) menar att i sekventiella

utvecklingsmetoder är tydlig och felfri dokumentation en vital faktor, vilket nästan är omöjligt att åstadkomma när kraven ändras och därför har användningen av Agila projektmetoder blivit allt mer vanligt.

8

2.4 Agil Utveckling

Agil systemutveckling är en samling av flera utvecklingsmetoder som Scrum och Extreme Programming. Det agila arbetssättet kännetecknas av ett nära samarbete med projektbeställare och slutanvändare genomgående under ett projekts livscykel, att jobba agilt påverkar också hur kravhanteringsprocessen går till (Juhola et al., 2014). Iterativt och inkrementellt är det centrala för utvecklingsteam som nyttjar agila utvecklingsmetoder. Iterativt menas att upprepa en process tills det önskade resultatet är uppnått. Inom systemutveckling kan det gå ut på att utveckla samma funktion flera gånger tills den är tillräckligt bra, men det kan också vara att

genomföra samma projekt flera gånger tills det är tillräckligt bra för att delges till beställaren eller för att kunden kan börja nyttja det. Inkrementell handlar om att systemet delas upp i inkrement och stegvis testas mot användare och itereas tills dess att målen är uppnådda (Cohn, 2009).

I många agila utvecklingsmetoder startas det direkt med att utveckla delar av ett system baserat på de vittomfattande kraven utan att vänta på formella krav och designanalyser och genom kontinuerlig kontakt med projektbeställare formas

systemen i iterationer utifrån krav beställarna ställer på det kommande systemet där kraven och designen blir mer detaljerade,vilket skiljer sig från sekventiella metoder (Lan Cao & Ramesh, 2008).

Fördelen med att arbeta iterativt är att krav kan komma och ändras under ett projekts gång och när man arbetar iterativt blir det enklare att hantera detta eftersom kravhanteringen sker kontinuerligt (Davis, 2013). Nurdiani et al. (2016) menar dock att utmaningarna inom agil utvecklingsmetod är förstå förhållandena mellan systemkraven på det blivande systemet. Eftersom den agila

utvecklingsmetoden välkomnar ändringar under utvecklingens gång gör att systemkrav kan komma att påverka varandra vilket kan leda till ökad kostnad för projektet (Nurdiani et al., 2016).

Scrum

Ett exempel på en agil utvecklingsmetod är Scrum. Vid användning av Scrum

använder sig av ett inkrementellt och iterativt arbetssätt där teamet består av

9

produktägare, Scrum master och utvecklingsteamet. Produktägaren är länken mellan utvecklingsteamet och projektbeställaren och har som uppgift att säkerhetsställa att förväntningarna på systemets uppfylls. Scrum masterns uppgift är att

utvecklingsprocessen utförs samt att arbetet fortskrider och utvecklingsteamet

arbetar inkrementellt med systemet (Cohn, 2009). Scrums utvecklingsprocess består av tre faser. I första fasen summeras kraven och behoven som ligger till grund för förändringar på system som nya funktioner. Mål fastställs utifrån användarfall och arbetet delas upp i delar som sedan produktägaren prioriterar i vilken ordning förändringarna skall göras och summerar dem i backloggen som är en prioriterad lista på önskemål på systemet. I andra fasen anpassar sig teamet utifrån behoven som ändras eller lagt till vilket innefattar iterativa cyklar så kallade sprintar för att utveckla systemet inkrementellt där varje sprint omfattar samma faser som

vattenfallsmetoden planering, kravanalys, design, programmering, testning (Lyytinen et al,2011). I slutet av varje sprint skall avslutas med att något nytt levereras till det nya system som är värdefullt för slutanvändare eller

projektbeställare så att det är möjligt att få feedback i varje sprint (Cohn, 2009).

Slutgiltigen innehåller den sista fasen systemintegration och tester för att leverera det fullständiga systemet (Lyytinen et al., 2011).

Extreme programming

Annat exempel av Agil utvecklingsmetod är Extreme programming (XP). Inom Extreme Programming sker kommunikationen med slutanvändarna kontinuerligt under utvecklingsprocessen. Kravenhanteringen inom Extreme Programming sker genom verksamhetsberättelser, vilket är en kort beskrivning av systemet utifrån en användares perspektiv. Utvecklingen sker iterativt och mindre delar av systemet levereras inkrementellt (Leffinwell, 2011).

2.5 Krav och kravhantering i Systemutvecklingsprojekt

Begreppet krav är ett nyanserat begrepp som omfattar en mängd olika definitioner.

Det kan handla om att man har som behov att maten skall innehålla en viss

kryddighet eller att man önskar ha kallt när man skall sova. Begreppet krav innebär

att något skall uppfyllas ovillkorligen, vilket sällan är fallen inom

10

systemutvecklingsprojekt. (IEEE Standard Glossary Of Software Engineering Terminology) beskriver grundläggande vad ett krav innefattar utifrån ett ITperspektiv med följande punkter:

1. Ett villkor eller förmåga som en användare behöver för att lösa ett problem eller uppnå ett mål.

2. Ett villkor eller förmåga som måste uppfyllas eller innefattas av ett system för att uppfylla ett kontrakt, specifikation eller andra dokument.

3. En dokumenterad representation av ett villkor som i (1) eller (2).

Utifrån ovanstående punkterna beskrivs ett krav som en önskan eller begäran av en användare för att lösa ett problem.

Inom systemutvecklingsprojekt är kraven en beskrivning på vad ett system skall innehålla och kunna utföra. De beskriver vad som måste utvecklas och vad som skall levereras (Garg & Singhal, 2017). De flesta kraven är genomförbara och till viss del förhandlingsbara beroende på mängden kravställningar, låg/stor bemanning, liten/hög budget eller hur stor teknisk risk kraven innebär (Garg & Singhal, 2017).

Krav med stor teknisk risk kan innebära att hela IT-systemen behöver göras om, om något blir fel. Med andra ord är kravställningar viktiga att identifiera i början av ett systemutvecklingsprojekt för att kunna identifiera vad som möjligt och hur det skall gå tillväga (Eriksson, 2007).

2.6 Typer av krav

I ett systemutvecklingsprojekt finns det olika typer av krav. Dessa består av funktionella, icke-funktionella, globala krav eller så kallade globala parametrar.

Funktionella eller beteendemässiga krav handlar om systemets funktioner och vad systemet skall utföra, interaktionen mellan systemet och användaren. Dessa krav är ofta specificerade i form av användningsfall som i textbaserad form stegvis beskriver specifika interaktioner mellan systemet och slutanvändarna (Röder, 2012). Ett

exempel på ett funktionellt krav kan ”Hur kan vi spara en produkt i systemet”. Indata är produktens namn, pris och antal och förväntad utdada är att användaren får ett meddelande om att transaktionen har gått bra (Eriksson, 2007).

11

De icke funktionella kraven handlar om hur system ska designas för att uppnå användbarhet, tillförlitlighet och god prestanda för att de som slutligen använder systemet, exempelvis kunder, skall förstå och kunna nyttja det. För att

säkerhetsställa god kvalitet på systemet skall de icke funktionella kraven komplettera de funktionella kraven. Globalt krav är en relativt ny term som beskriver systemets egenskaper som helhet. Tidigare kallades dessa krav för allmänna krav eller

produktavgränsningar. Till exempel kan ett globalt krav vara att ”Systemet skall vara skalbart” eller att ”Systemet skall köras på existerande nätverk” (Wysocki, 2019).

Produktavgränsningar är de krav som ställs på designen av slutprodukten medan IT- system som också tillhör denna grupp handlar om tidsplanen för att utveckla

projektet, deadlines och budget. Alla krav är viktiga i processen där ett IT-system utvecklas och således också avgörande för hur slutprodukten blir (Wiktorin, 2018).

2.7 Kravspecifikation

Initialt inleds systemutvecklingsprojekt med att en beställare ser ett behov eller en potential i att ett nytt system skulle kunna gynna verksamheten. Baserat på den önskan beställaren har om vilka funktioner systemet skall ha, vilken design samt vad det skall användas för, formuleras därefter ett behov som skall mötas av

systemlösningar och omvandlas till tekniska konkreta krav på systemet vilket dokumenteras i en kravspecifikation (Shafiq et al., 2019).

En kravspecifikation är ett dokument där beställaren specificerar vilka önskningar, behov och krav hen har inför det kommande projektet, och den fungerar som en länk mellan systemutvecklare och beställaren. Detta möjliggör att systemet som skall designas följer den plan beställaren har och missförstånd minskar (Rempel & Mader, 2017). Det finns redan framtagna mallar för kravspecifikationer, vilket kan

underlätta kommunikationen mellan beställare och systemutvecklare. Mallarna är redan färdigt strukturerade och standardiserade vilket gör att systemet som skall utvecklas också följer en röd tråd, blir enhetligt och designmässigt snyggt (Eriksson, 2007).

12

Att kraven i kravspecifikationen är bristfälliga, tvetydiga och ofullständiga är den största orsaken till att systemutvecklingsprojekt misslyckas. Därför är det viktigt att hantera detta, projektbeställare har oftast inte någon bakgrund inom utveckling och att använda sig utav vanligt språk istället för modelleringsspråk såsom UML kan därför vara fördelaktigt för att konkretisera och tydliggöra kraven gentemot projektbeställarna (Fatwanto, 2012).

2.8 Kravinsamlingsprocessen

Att samla in kraven tillsammans med projektbeställaren är ett första steg till att bygga upp en förståelse om vad det är för problem som skall lösas och vad det är som skall utvecklas. Men för att skapa användbara system måste man också beakta de faktiska slutanvändarna som kommer att använda produkten, hur de kommer att använda systemet och hantera deras krav (Sohaib & Khan, 2010). Pastor et al. (2014) förklarar att det är fördelaktigt att involvera slutanvändarna i

kravinsamlingsprocessen för att skapa en bättre förståelse för kravinsamlingen.

Pastor et al. (2014) menar att involvering av de riktiga slutanvändarna är en

nyckelfaktor för att utveckla användbara system. Utvecklingsprojekt där kunskapen om slutanvändarna är låg leder oftast till missförstånd och slutresultatet blir en produkt som inte förgyller beställningen (Kulkarni, 2008). Kujala et al. (2005) beskriver också att involvering av användare i kravinsamlingsprocessen minskar osäkerheten över kraven. Kravinsamlingsprocessen är ett iterativt arbete i agila utvecklingsmetoder eftersom under utvecklingens gång kommer nya krav till eller förändras med tiden (Leffingwell, 2011).

För att lyckas med detta kan det vara till fördel att använda sig av en

användbarhetsspecialist eller UX-designer i utvecklingsteamet vid designen samt att utvecklarna avvaktar med att utveckla funktioner för användarna innan den

slutgiltiga designen av systemet är tydlig utifrån slutanvändarnas perspektiv (Sohaib

& Khan, 2010). Vidare kan det också vara till nytta att utöka den tidigare beskrivna tekniken användningsfall för att samla in krav genom att komplettera den med användbarhetskrav för varje användningsfall vilket möjliggör att utvecklare med lite eller ingen kunskap om användbarhet har möjlighet att utveckla användbara

systemet (Röder, 2012). För att identifiera kraven och skapa användbara system

13

använder man sig utav tekniker som intervjuer, frågeformulär, användningsfall, prototyping eller rollspel (Hujainah et al., 2018).

2.9 Kravhantering

Kravspecifikationen är i tidigt stadie den dokumentation på krav som projektbeställaren har på det framtida systemet, men under ett

systemutvecklingsprojekts gång kommer kraven att ändras, modifieras och att nya krav kan komma till som måste bearbetas. Kravhanteringsprocessen, innefattar en mängd aktiviteter för att uppfylla och realisera kraven från kravspecifikationen och Kulkarni (2008) menar på att det är en av de viktigaste faserna vid utvecklingen av IT-system. Dessa aktiviteter innefattas av att upptäcka, analysera, verifiera, validera, utveckla, dokumentera samt kommunicera med projektbeställare där det slutgiltiga målet är att etablera krav som skall ställas på det slutgiltiga system som skall

utvecklas (Aasheim & Yang-Yang Zhao, 2017).

Att hantera att kraven kommer att ändras under ett projekts livscykel problematiskt men centralt för en lyckad slutprodukt och för att lyckas med detta i

systemutvecklingsprojekt där flera intressenter och teams från olika geografiska platser är kommunikationen en viktig del i arbetet vilket man gör genom välskrivna dokumentationer. Även fast det finns avsevärt med information om hur man fångar och hanterar kraven är det oftast det som anledningen till att

systemutvecklingsprojekt misslyckas (Shafiq et al., 2018). Krav på större och mer komplexa system har lett till att utvecklings-teamen måste utökas vilket har

utmynnat i att personerna involverade i projekten kan sitta på olika platser i världen på samma projekt vilket gör det ännu viktigare att kraven är mer specifika och detaljerade (Kassab et al., 2018).

En studie som gjordes i Storbritannien visade på att 40 % av problemen som uppstår

under en utvecklingsprocess är kopplade till hanteringen av krav. Studien visade

även på att 50 % av systemkraven ändras under utvecklingens gång innan ett system

kommer till bruk. Otydliga och dåligt genomförda processer för hantering av krav

14

resulterar i många problem under ett utvecklingsprojekt i kostnader och tid vilket även kan äventyra projektets framgång (Anwer et al., 2019).

Det finns även förslag och lösningar för att effektivisera men också förenkla arbetet kring kravhanteringsprocessen. CRM (Change Requirement Management) är en modell som skall underlätta arbetet mellan beställare och utvecklare. Dessa faser innefattar möjligheten att kunna framkalla, dokumentera, genomföra och hantera ändringar av krav (Shehzadi et al., 2019). Modellen är konstruerad att följa processen från utvecklandet av ett nytt IT-system till själva slutprodukten. De viktigaste ur systemutvecklarens perspektiv är krav -orienteringsfasen, -prioriteringsfasen samt kundnoteringsfasen. Kravkategoriseringsfasen uppskattar tidsåtgången till alla stora som små förändringar som bör göras. Kravprioriteringsfasen stödjer utvecklarna att prioritera kraven med högst prioritet för att minska förseningar under projektets gång. De kraven med lägre prioritet sparas i en mapp för icke-implementerade krav.

Kundnoteringsfasen hjälper till att minska kommunikationsgapet mellan utvecklare och projektbeställare vilket skapar väg för en korrekt design (Shehzadi et al., 2019).

2.10 Tvetydigheter i systemutvecklingsprojekt

Anwer et al., (2019) beskriver att krav ska uppfattas på samma sätt oberoende på vem som läser det. I en studie gjord av Anwer et al. (2019) uppdagades det att

tvetydlig kommunikation i systemutvecklingsprojekt mellan är största orsaken till att projekten misslyckas. Då kan det handla om kommunikationen mellan teamen i systemutvecklingsprojekten men också gentemot användare och projektbeställare (Anwer et al., 2019).

Ferrari et al. (2016) beskriver att tvetydigheter betyder att ett krav kan uppfattas olika från person till person, via intervju eller text.

Under kravinsamlingsprocessen sker kommunikationen oftast verbalt genom intervjuer med slutanvändare och projektbeställare. Därmed menar Bjarnsson och Sharp (2014) att kommunikationen är viktig, speciellt i början av

kravinsamlingsprocessen. Gruppdynamiken och kommunikationen mellan

individerna inom gruppen är central för att projektet ska leda åt rätt håll och minska

tvetydigheterna i kommunikationen kring kraven. Bjarnsson och Sharp (2014)

15

förklarar att det är viktigt att kommunikationen mellan projektbeställare och

utvecklare är tydlig eftersom om utvecklarna initialt missförstår projektbeställarnas förväntningar och krav på systemet kommer det leda till ett IT-system som inte uppfyller deras förväntningar och kan därmed leda till längre tid för att leverera slutprodukten (Bjarnsson och Sharp, 2014). Kassab et al., (2018) menar på att numera sitter utvecklingsteam, projektbeställare och slutanvändare ibland på olika platser vilket gör att det ännu viktigare att kraven kommuniceras tydligt. Dessa tvetydigheter i kommunikationen mellan utvecklare projektbeställare och

slutanvändare är vital för att producera en kravspecifikation som är tydlig uppfyller det förväntade resultatet (Ferrari et al., 2016). Anwer et al., (2019) beskriver också att sociala och kulturella skillnader mellan individer är en faktor som också påverkar kommunikationen i utvecklingsprojekt men att det kan vara till fördel att använda sig av en specialiserad projektledare.

Att använda sig av tydliga processer har direkt inverkan hur effektivt ett

systemutvecklingsprojekt kommer gå. Otydliga och dåligt verkställande av processer leder till krav som är otydliga och slutligen en produkt som inte lever upp till dess förväntan (Shafiq et al., 2019). Shafiq et al., (2019) menar att ineffektiva och otydliga processer kan leda till mer arbete och därmed ett kostsammare utvecklingsprojekt.

Kravinsamlingen är en process som pågår under hela systemutvecklingens gång, därmed en omfattande och en komplex uppgift. Därför är det viktigt att de sätts ned tid, att kraven arbetas med löpande samt att effektiva processer används för att fånga in slutanvändarnas funktionella och icke-funktionella krav (Shafiq et al., 2019).

2.11 Summering Teori

Sammantaget finns det flera olika delar under ett systemutvecklingsprojekt.

Inledningsvis startar ett projekt inom systemutveckling med att man ser potential i att ett nytt system bör utvecklas. Sekventiell- och agil utveckling är två

projektmetoder som kan användas vid systemutveckling. Vid sekventiell utveckling

utvecklas en sekvens i taget, medan agil utveckling innebär att man arbetar med

kraven kontinuerligt. Krav innebär förväntningar på systemet samt hur system ska

designas för att uppnå användbarhet, tillförlitlighet och god prestanda för att de som

slutligen använder systemet skall förstå och kunna nyttja det. Vidare förtydligas krav

16

vid ett systemutvecklingsprojekt, där kravspecifikationen är grunden till hur slutprodukten blir. Kravspecifikationer som är bristfälliga eller otydliga är den största orsaken till att systemutvecklingsprojekt misslyckas.

Kravinsamlingsprocessen handlar därmed om att samla in alla krav, där det oftast kan vara fördelaktigt att involvera såväl projektbeställare som slutanvändare för en lyckad slutprodukt. Nästa steg i systemutvecklingsprojektet är kravhantering, där de krav som samlats in hanteras genom att realisera kraven från kravspecifikationen till ett framgångsrikt arbete. Kravhanteringen innefattar allt från att analysera och dokumentera till att kommunicera med projektbeställare. Kravhanteringen är en av de viktigaste faserna vid utvecklingen av ett IT-system. Slutligen nämns åter vikten av tydlighet i kravinsamlingen och kravspecifikationen, där tvetydigheter och

otydlighet är den största orsaken till ett fördröjt och misslyckat projekt. Slutsatsen är att kommunikationen är av betydelse för att uppnå konsensus bland alla inblandade i systemutvecklingsprojektet vilket därmed bidrar till en slutprodukt som motsvarar kraven.

17

3. Metod

Detta avsnitt ger en beskrivning av tillvägagångssättet i studien motiveringar till de var som gjorts. Avsnittet inleds med en beskrivning till valet av ämne,

forskningsansatsen, urval och analysmetod samt hur insamlingen av data har skett

3.1 Forskningsansatser

Att studera om kravhantering inom systemutvecklingsprojekt var ett beslut som togs tillsammans med DeLaval. DeLaval såg ett behov av att förändra de problem som funnits kring utvecklingen och beställningen av deras IT-system. I dagsläget har DeLaval nyttjat flera konsulter vid utvecklingen av deras användargränssnitt och system (som exempelvis webbsida) vilket har medfört att det inte funnits ett grundtema eller enhetlig röd tråd mellan dessa. Bristen på ett enhetligt system har skapat förvirring och oklarheter för slutanvändare. Med anledning av det finns behov av att identifiera utmaningar och brister kring kravhantering och beställning av systemutvecklingsprojekt. Studien beslutade därför uteslutande att undersöka systemutvecklares behov av att specificera beställningen, för att förenliga slutprodukten med den beställning som gjorts. Utifrån ovanstående och för att identifiera utmaningar och framgångsfaktorer för att minska risken för tvetydigheter i kravhanteringsprocessen för systemutvecklingsprojekt ur ett beställar–och

systemutvecklarperspektiv och säkerhetsställa användbarheten ett IT-system valde författaren en kvalitativ ansats.

Ett kvalitativt tillvägagångssätt är ett sätt att utföra en studie och då används frågor såsom vad, varför och hur och genom att besvara dessa frågor ges större utrymme åt deltagarna i intervjun att ge öppnare svar kring deras uppfattning kring deras största utmaningar och svårigheter i systemutvecklingsprojekt (Jacobsen, 2017). Vidare har undersökningsdesignen varit explorativ för att få fram nyanserad data kring de utmaningar och tvetydigheter som finns vid kravhanteringsprocessen i

systemutvecklingsprojekt utifrån systemutvecklares perspektiv (Backman, 2008).

Vid undersökningar med en problemställning som syftar till att forska kring nyanser

av ett problem är det lämpligt att bara koncentrera sig på ett fåtal enheter och gå in

på djupet i enheternas kunskap och samtidigt beakta sammanhanget. En sådan

18

problemställning kallas explorativ eller förklarande (Jacobsen, 2017). Denna studie studerade nyanserna kring problemen i kravhanteringsprocessen och går in på djupet i respondenternas kunskap för att identifiera utmaningar, tvetydigheter och framgångsfaktorer de erfarit för att sedan jämföra mot teorin. Alvesson och

Sköldberg (2008) menar att en abduktiva ansats passar bra när man använder sig utav fallstudiebaserade undersökningar såsom en liten n-studie är. Efter empirin samlats in genom intervjuer upplevde författaren att den teoretiska referensramen behövdes fyllas på med ytterligare teorier eftersom ny kunskap om området

tillkommit.

För att uppfylla studiens syfte och antogs en abduktiv ansats vilket innebär att det har vart en kontinuerlig problemlösande process (Jacobsen, 2017). Utifrån den teoretiska referensramen skapades en ökad förståelse för området kring

kravhantering i systemutvecklingsprojekt och dess största utmaningar och

tvetydigheter. Detta lade en grund för studien och empiri börjades att samlas in. Vid första intervjun uppstod ny kunskap vilket ledde till att intervjumallen utvecklades och nya frågor lades till och den teoretiska referensramen utvecklades.

3.2 Undersökningsdesign

Eftersom denna studies syfte var att fånga nya utmaningar och framgångsfaktorer som kan uppstå vid kravställningen vid systemutvecklingsprojekt, för att sedan kunna problematisera, definiera, förklara och tydliggöra dessa, därför ansåg denna studie dra fördel av liten N-studie med fokus på kravhanteringen i

systemutvecklingsprojekt.

N-studiens syfte är att undersöka är att undersöka hur kravhanteringen går till samt identifiera och beskriva utmaningar och framgångsfaktorer för att minska risken för tvetydigheter i kravinsamlingsprocessen för systemutvecklingsprojekt ur ett

beställar–och systemutvecklarperspektiv. För att komma till klarhet om detta

problem och uppfylla studiens syfte ansåg författaren att en liten N-studie skulle vara

gynnsam eftersom den är lämpligast när man vill gå på djupet av ett fenomen och får

en rik och detaljerad beskrivning om detta (Jacobsen, 2017). Rollerna som tas in är

19

systemutvecklare och ägare av utvecklingsramverk och fenomenet i denna studie är utmaningarna och tvetydigheterna i kravhanteringsprocessen.

3.3 Urval

Deltagare till studien inkluderades eller exkluderades genom specifika kriterier för att kvalitetssäkra studiens syfte i enlighet med Wallengren och Henricson (2012).

Inklusionskriterier var systemutvecklare som arbetar med att utveckla system utifrån kriterier, krav eller beställningar. Krav och beställningar kan ställas av

projektbeställare eller utvecklare. Studien fokuserade på att inkludera

systemutvecklare från olika företag. Kriterierna för urvalet till studien var att respondenterna skulle vara någorlunda insatt hur företaget har jobbat med kravhantering tidigare samt innehav praktisk erfarenhet av att jobba med kravhantering för att kunna ge ett grundligt svar på områdena insamling,

kommunikation/uppföljning, förvaltning, verifiering/validering och övriga frågor i intervjumallen. Exklusionskriterier som valdes till studien var systemutvecklare och projektägare som inte arbetar eller har arbetat med kravställningar. På grund utav att studien är ur systemutvecklares perspektiv och inte har till avsikt att undersöka den slutgiltiga produkten så exkluderades slutanvändarnas aspekt.

3.4 Datainsamlingsmetod

Empirins roll i undersökningen användes för att jämföras med vad teorin säger.

Studien använde teorin som utgångspunkt och formulerade intervjufrågorna utifrån den. I denna studie intervjuades totalt fyra personer av kategorin systemutvecklare och projektbeställare i syfte att ta fram utmaningar, tvetydigheter och

framgångsfaktorer i kravhanteringen under systemutvecklingsprojekt. Författaren använde sig utav Skype, telefonsamtal och fysiska möten för att intervjua

systemutvecklare och projektbeställare. Datainsamlingen skedde genom öppna

individuella intervjuer där författaren försökte styra den information som samlas in

så lite som möjligt vilket skapar en stor relevans och man får den riktiga förståelsen

av ett fenomen eller situation (Jacobsen, 2017). Den kvalitativa undersökningen

byggde på intervjuer och dialog med utvalda deltagare. Författaren strävade efter att

ha färdigt antecknade, öppna och neutrala frågor med syftet att få så essentiell

20

information som möjligt. Författaren undvek ledande frågor eftersom det kan bidra till förvirring och oengagerade svar. Ett antal frågor skrevs på förhand och en intervjuguide togs därefter fram för att skickas ut till de personer som skulle

intervjuas i syfte att de skulle vara förberedda på vilka frågor som skulle komma och därmed ha möjlighet att ge ett utförligare svar. Varje intervju varade mellan 30 minuter till en timme där strukturen på intervjufrågorna var semistrukturerade vilket gjorde att det också fanns möjlighet för respondenterna att svara öppet på frågorna så deras egna erfarenheter kring de största utmaningarna, svårigheter och framgångsfaktorer i kravhanteringsprocessen kunde fångas. Författaren använde sig utav Yin’s (2013) fem ståndpunkter under intervjuerna “var inte styrande” ,

“upprätthåll god relation”, “använd ett intervjuprotokoll”, “förbi neutral” och “tala måttligt mycket”. Samtliga respondenter arbetar aktivt med kravhantering eller har haft tidigare erfarenhet av kravhantering i IT-system som projektbeställare, ägare av ett ramverk eller som utvecklare. I studien strävade författaren att av undersöka huvudfrågan ”Vilka problem/utmaningar uppstår vid kravställningen för

systemutvecklare?” och informationen att tolkades i syfte att bredda förståelsen om vad som är orsaken till utmaningar och problem i systemutvecklingsprojekt.

3.5 Analysmetod

Författaren bearbetade all insamlade data genom att bryta ner den i delar, ta fram mönster och dela upp dem i teman om utmaningar, tvetydigheter och

framgångsfaktorer som sedan jämförs mot teorin. Detta innebär att författaren har reducerat komplexiteten i anteckningarna från intervjuerna till mindre

beståndsdelar för att försöka förstå delarna utifrån den helhet som bildades

(Jacobsen, 2017). Resultatet innehåller argument som är kopplade till teorin om om

utmaningar, tvetydigheter och framgångsfaktorer i systemutvecklingsprojekt för att

påvisa relevansen med studien. Analysprocessen har skett iterativt då författaren har

gått igenom data flera omgångar för att besvara frågor som: 1) Vad säger datan? 2)

Vad vill jag veta mer om? Detta iterativa arbete gav en fördjupad förståelse för

kontexten i den insamlade data.

21

För att analysera intervjuer utifrån en kvalitativ metod använder man sig ofta av fem faser (Yin, 2013). Författaren valde att använda dessa faser för att analysera den insamlade data. Analysen initierades med en sammanställning av all data som införskaffats. Vidare påbörjades demontering av data, vilket innebär att den bryts ned i mindre delar eller kategorier för att öka tydligheten i den insamlade datan.

Därefter placeras placerades data i listor eller tabeller som benämns

remonteringsfasen. I den fjärde fasen skedde en uppföljning av arbetet för att

ytterligare tolka den insamlade datan, vilket kan göra att man behöver gå igenom de olika faserna en gång till. Avslutningsvis drogs slutsatser utifrån analysen. Detta arbete sker iterativt och behöver inte heller ske sekventiellt då man har möjlighet att gå mellan olika faser.

Författaren vill poängtera att denna har en förförståelse från teorin om de vanligaste utmaningarna, tvetydigheterna och framgångsfaktorerna i systemutvecklingsprojekt och att det är ofrånkomligt att författaren inte har påverkat deltagare i studien.

Tolkningen av insamlad information är därmed subjektiv, och genom att vara transparent till ovanstående analysmetod skapas möjlighet till en objektiv tolkning av arbetet av en extern part (Helenius, 1990).

3.6 Litteraturöversikt

För att skapa en teoretisk bas till den empiriska undersökningen valde författaren att göra en artikelsökning (Appendix 2), med artiklar som är relevanta för studiens syfte.

Studiens teoretiska grund består av artiklar och böcker inom problemområdet

kravställning för systemutveckare. Under arbetets gång har författaren valt att belysa

övergripande aspekter kring kravhantering, utveckling och användbarhet. I enlighet

med Davidson & Patel (2003) bör teorin inledas på ett övergripande sätt för att

successivt avgränsas mot det valda problemområdet. Teorin avgränsades vart efter

för att avslutningsvis stämma överens med utvecklingen av en tydligare kravställning

i systemutvecklingsprojekt. Teorin jämfördes därefter med resultatet. I denna studie

användes den teoretiska basen som grund till intervjufrågorna men även som ett

hjälpmedel under intervjuerna så att författaren kunde använda sig utav teorin för

att ställa ytterligare frågor utanför intervjumallen för att ta fram rikare resultat.

22

Artikelgranskningen gjordes genom sökning av nyckelorden: software, management, change, problem, requirement, interface, development, usability, stakeholder som var framtagna för studiens syfte. Sökningarna gjordes manuellt och som fritext. Även de booleska orden AND och OR nyttjades för att vidare specificera sökningen.

Författaren valde att söka i databaserna: ACM OCH IEEE Xplore. Vilket utmynnade i flertalet artiklar som ansågs stämma med syftet att identifiera utmaningar,

tvetydigheter och framgångsfaktorer. Vid databassökning lästes upp till 100 titlar. De titlar som författaren ej ansåg uppfylla studiens syfte exkluderades. Artiklar som behandlades i detta arbete hade som inklusionskriterie att de skall vara skrivna på engelska. Enligt Forsberg och Wengström (2013) så är det av vikt att om möjligt studera aktuella forskningsresultat för att öka studiens relevans. Därför valdes artiklar efter årskiftet 2010 och t.o.m. 2020 att användas som en inklusionskriterie till studien. Författaren har inkluderat ett fåtal artiklar för årsskiftet på grund av relevansen till denna studie.

3.7 Validitet

Jacobsen (2017) menar att validitet är ett mått på hur giltig och relevant empirin är, det vill säga att undersökningen faktiskt mäter det den är avsedd att mäta och delar in validiteten i extern och intern giltighet. Med extern giltighet menar Jacobsen (2017) hur bra det går att generalisera slutsatserna från studien. Författaren i denna studie vände sig till fyra respondenter för att samla in empiri vilket däremot kan vara begränsat för att dra generella slutsatser utifrån studien. För att göra

generaliseringen trovärdigare hade fler respondenter behövts. Motivet av en

kvalitativ ansats är ett medvetet val författaren har gjort baserat på studiens syfte och därför anser författaren att den externa giltigheten är låg.

Med intern giltighet, menar Jacobsen (2017) huruvida resultaten uppfattas som riktigt d.v.s. mäter författaren det som avses att mätas och inga andra variabler utom det som författaren studerade orsakade resultatet. Den interna giltigheten kan kontrolleras på olika sätt menar Jacobsen (2017). Ett tillvägagångssätt kan vara att författaren själv kontrollerar studien kritiskt, eller att man låter utomstående

kontrollera studien och ett tredje sätt är att kontrollera mot andra studier (Jacobsen,

2017). Författaren i denna studie har själv kritiskt granskat studien och även

23

kontrollerat mot andra studier därför anser författaren att den interna giltigheten är hög.

3.8 Reliabilitet

Jacobsen (2017) skriver att reliabilitet visar hur trovärdig och tillförlitlig en studie är och om verkligheten och författarens beskrivning av verkligheten stämmer överens och för att uppnå hög reliabiliteten på studien skall både intervjueffekten och kontexteffekten vara låga vid individuella intervjuer. I samband med intervjuer kan undersökaren komma att ha påverkat det fenomen eller person som undersöks detta kallas intervjueffekt. Författaren använde sig av teorin och syftet i studien där

utmaningar, tvetydigheter och framgångsfaktorer identifierades och att formulerade frågor därefter för att uppnå riktig beskrivning av verkligheten. Karaktären på frågorna var semistrukturerade vilket gav respondenterna möjlighet att besvara relativt öppet om deras erfarenheter kring dessa utmaningar.

Kontexteffekten är istället om platsen för intervjun påverkar respondentens svar i undersökningen. För att uppnå en sann representation av verkligheten har

författaren lagt stor vikt vid att finna de rätta källorna som uppfyller studiens syfte och därefter att empirin har samlats in har författaren valt att verifiera svaren som insamlats in och mot andra undersökningar som tagits fram ifrån den teoretiska referensramen. För att finna de rätta källorna har författaren utgått utifrån inklusion och exklusionskriterier. Forskaren är medveten att dennes egen tolkning av

respondenternas svar kan ha påverkat reliabiliteten i undersökningen. För att motverka detta såg forskaren till att vara väl kunnig inom området. I avsikt att

förbättra reliabiliteten ytterligare tog författaren sig tid att anteckna respondenternas svar noggrant och efter intervjun var klar skedde en sammanställning av svaren.

Eftersom de flesta intervjuer har skett via telefonsamtal har kontexteffekten i

undersökningen vart svår att kontrollera. Men för att få bort överraskningsmomentet

har på förhand en avtalad tid planerats, vilket leder till låg kontexteffekt (Jacobsen,

2017).

24

3.9 Etik

Etiska problem förekommer vid genomförande av kvalitativa studier när författare kommer i kontakt med människor (Jacobsen, 2017). Med tanke på att studien ämnat undersöka utmaningar och tvetydigheter i kravhanteringsprocessen, kan

transparensen leda till att respondenterna svarat annorlunda för att påverka

resultatet (Jacobsen, 2017). Eftersom problemställningen gjordes i enlighet med

uppdragsgivare, har författaren betonat vikten av författarens oberoende i relation

till uppdragsgivaren för att inte producera ett specifikt resultat.

25

4. Resultat & Analys

I detta avsnitt redogörs resultatet från den empiriska underökningen. Avsnittet inleds med vad som har undersökts för att sedan redogöra respondenternas svar som har sammanställts i kategorier utifrån dataanalysen.

För att identifiera utmaningar i utveckling av användbara system och dess process, valdes DeLaval till grund för arbetet. Företaget utvecklar, tillverkar och marknadsför utrustning och system för mjölkproduktion och djurhållning. Utrustningen är bland annat GPS sensorer på korna för att följa deras rörelse, mjölkmätare för att

kontrollera mjölkproduktionen. All information kring mjölkning samlas, analyseras och presenteras till bönderna via mobila applikationer. DeLaval har utvecklats i snabb takt vilket har lett till att allt fler användargränssnitt har behövts

implementeras för dem som använder produkten, kallat slutanvändare. Själva designen av användargränssnitten har inte utvecklats i samma fart vilket har lett till ett behov av att anpassa sin design utifrån ett användarvänligt perspektiv. DeLaval har tills nu använt sig av diverse konsulter för utveckling av gränssnitt utöver flera av deras system vilket har lett till ologisk följd i designen mellan flera gränssnitt som utvecklats av olika utvecklare. DeLaval skall nu ta över ansvaret själva för att lösa detta och behöver en djupare förståelse för hur man skall tänka, utmaningar och svårigheter som uppkommer under processen för design av användarvänliga gränssnitt för multi-intressenter. Utifrån analysen av empiriska data identifierades två primära kategorier av utmaningar och svårigheter för utvecklingen av IT-system men även flera framgångsfaktorer.

26

Referens Befattning Utbildning Jobbat med krav från

Projektägare 1 Ägare av

utvecklingsramverk

Systemvetenskap 1990

Systemutvecklare 1 Systemutvecklare Dataingenjör 2008 Systemutvecklare 2 Systemutvecklare Systemvetenskap 2003 Systemutvecklare 3 Systemutvecklare Systemvetenskap 2010

I tabellen ovan framgår de olika respondenterna förhållande till deras befattning och referering används för att binda de påståenden som föregåtts under intervjuerna till dem.

4.1 Utmaningar

4.2 Kommunikationssvårigheter

En kategori som resultatet indikerar som en utmaning är

kommunikationssvårigheter. Vad denna kategori innebär koncist är att

projektbeställare ofta har en vision om att bygga ett IT-system och därefter snabbt kommunicerar sin idé till utvecklarna men saknar den tekniska kunskapen om hur det går till, hur länge projektet tar, vilka funktioner som skall vara med. Detta leder till att kraven på systemet missuppfattas av en utvecklare.

En anmärkning som gjordes på ett uttalande kring kommunikationssvårigheter var många och här visas samtliga. Systemutvecklare 1 ”Det svåraste inom

mjukvaruutveckling är att det blir missförstånd. Projektbeställare som vill bygga IT-system har stora visioner och tror att de snabbt kan förmedla sin ide men förstår sig inte på själva processen och vill bara ha det på ett specifikt sätt. De tar inte sig den tiden som behövs att säkerhetsställa det som de faktiskt vill ha, vilket leder till missförstånd eftersom språk innefattar många subtila substanser som kan misstolkas när krav som skrivs ned går att tolkas på flera olika sätt. ”

(Systemutvecklare, 1). Respondenten menade att detta är ett vanligt förekommande

utmaning inom kravhantering idag och att det kan leda till att utvecklingstiden

27

förlängs eller att systemutvecklingsprojektet faller samman helt. Ett annat påvisande som visar på kommunikationssvårigheter är

”Det som uppstår är att nya utvecklare och saknar domänspecifik kunskap medan projektbeställare är expert på deras domän som tex statistisk analys och

marknadsundersökningar. Därmed finns det standarduttryck som skiljer sig utifrån hur man tolkar dem, tex så kan en variabel betyda olika saker från person till person, skillnaden är liten men beroende på hur man tolkningen sker blir resultatet olika”. Detta... visar på att beroende på hur ord tolkas från

projektbeställare kan resultatet av IT-systemet påverkas. Detta påpekade

Projektägare 1 och utrycker sig ”Dålig kommunikation är oftast den största orsaken till missförstånd kring kraven. Det kan vara att man har för snäv kommunikation, att utvecklarna går för djupt in i det tekniska och missar nyttan och därmed utgår då från förutsättningar som inte är givna för beställarna vilket leder till missmatch mellan förväntat resultat och slutprodukt.” Projekägare 1 menar på att de som utvecklat och kodat funktionalitet har oftast gjort som de har blivit tillsagd men vid beställning av IT-system är det oftast flera intressenter från beställarsidan som kan komma med olika motstridiga krav hur de vill ha funktionalitet eller design.

Resultatet är i likhet med vad Kassab (2018) påpekar, dvs att större med

utvecklingsteamen så ökar kommunikationssvårigheterna vilket gör att kraven i kravspecifikationen måste vara ännu tydligare.

Bjarnason och Sharp (2014) förklarar att brister i kommunikationen har visat sig att vara en betydande anledning till att systemutvecklingsprojekt misslyckats eller att projektet har dröjt. Bjarnason och Sharp (2014) berättar att om en projektbeställare kommunicerar sina förväntningar och krav till en systemutvecklare och

systemutvecklaren inte uppfattar dessa korrekt utmynnas det i en slutprodukt som inte uppnår det förväntade resultatet och det kan ta längre tid, ökade kostnader samt en att en större insats behöver inrättas för att uppnå den önskade slutprodukten (Bjarnason och Sharp, 2014).

4.3 Bristande struktur

En annan utmaning som resultatet indikerar är att bristande struktur leder till

användbarheten och syftet med produkten missas. Bristande struktur kan det handla

28

om otillräckliga processer, fokus på fel saker samt att man går direkt på lösning och hoppar över viktiga delar i kravhanteringsprocessen. En respondent berättar att ”Ett problem som jag har upplevt är att utvecklare går ned på lösningen direkt och börjar utveckla funktionalitet och missar då nyttan och syftet vilket i sin tur leder till längre utvecklingstider och större kostnader” (Systemutvecklare,2).

Respondenten menade vidare att detta ofta förekommer inom

systemutvecklingsprojekt idag och kan leda till stora konsekvenser. Detta bekräftas av projektägaren och hen berättar att ”Kravställare som ställer krav ställer dem på för låg nivå vilket leder till att systemutvecklare går in på lösningen direkt och missar syftet” Projektägaren nämner också att ”En orsak att det uppstår problem kring kraven är också att intressenter ställer olika samt motstridiga krav”.

Detta resultat om bristande struktur påpekas även av

Kulkarni (2008) som menar att det är viktigt att alla relevanta intressenter identifieras och förhållanden emellan dem för att fånga alla krav och undgå

motstridiga krav. Gör man detta får man en större inblick i ursprunget av kraven och kan lättare förstå i vilket sammanhang kopplat till IT-systemet. Även Assaheim (2017) menar också att identifiera intressenterna i ett tidigt skede är viktigt att förstå vem dom är, vad dom bryr sig om och deras intressen, för att få en genomgående förståelse vad deras behov är eftersom andra kan ha mer makt när det kommer till utvecklingen av IT-systemet än andra.

Systemutvecklare 3 nämner också vikten av att använda sig av en tydlig struktur

”Utvecklingsorganisationen kan ha processer och metoder för att tackla utvecklingsprojekt men använder man sig inte av dem så leder det till stora problem” (Systemutvecklare, 3). Respondenten menade att en del

systemutvecklingsprojektet i fråga kan tyckas vara okomplicerade till en början men används inte de processer och metoder som finns kring hanteringen av krav kommer det att utmynnas i längre utvecklingstider och större kostnader. Systemutvecklare 1 instämmer med detta och berättade om ett tidigare vattenfallsprojekt som hen jobbat med: ”Kravspecifikationen som vi framställde kontinuerligt tillsammans med

beställarna tog tre månader och blev över 100 sidor lång, därefter var kontakten

29

mindre och delleveranser skedde tredje månad och sist en uppföljningsfas vilket ledde till att slutprodukten inte blev som de hade tänkt sig” (Systemutvecklare, 3).

Respondenten menade att projektbeställare måste också använda sig av en struktur när de beställer system och ta sig tid att säkerhetsställa vad de faktiskt vill ha annars uppstår missförstånd.

Prikladnicki et al. (2003) menar att använda sig av en väldefinierad

systemutvecklingsprocess kan leda till att man skapar en gemensam förståelse hur man på bästa sätt går tillväga för att utveckla ett IT-system, vilket kan leda till att organisationsproblem såsom kommunikationsproblem minimeras.

4.4 Övriga faktorer som leder till tvetydigheter

Målet inom kravhanteringsprocessen är att säkerhetsställa att en produkt eller ett ITsystem utvecklas utifrån projektbeställarnas krav och förväntningar. Kujala et al.

(2005) menar att även fast det är beställarna som betalar för systemet så måste slutanvändarnas krav och förväntningar på systemet hanteras för att åstadkomma användbarhet, eftersom det är användarna som är sakkunnig på specifika funktioner på det blivande IT-systemet (Kujala et al. 2005).

När det råder bristande struktur är det oftast användbarheten i ett IT-system som försummas (Röder, 2012). Röder (2012) förklarar att än idag byggs system med utvecklare med lite eller ingen som helst kunskap om hur man utvecklar utifrån ett användbarhetsperspektiv och syftar på att det fortfarande råder brist på struktur i de flesta systemutvecklingsprojekten och att användbarheten ses ofta som en

andrahandsprioritering som utvecklarna kan snabbt lägga in i ett senare skede. Detta kan leda till att användbarhetsfunktioner specificeras inte alls i kravspecifikationen vilket utmynnar i system med sämre kvalitét (Röder,2012).

Carver och Walia (2009) förklarar att noggrann, detaljerad och logisk

dokumentation av kraven är viktig för att säkerhetsställa att kravspecifikationen inte

består av tvetydigheter som kan misstolkas. Carver och Walia (2009) menar att det

kan vara fördelaktigt att systematisera krav efter funktionella och icke-funktionella

krav samt efter specifika funktioner. Likaså menar Davies (2013) att kraven som

30

dokumenteras måste vara i exakt form som det som uttrycktes och inget annat, annars kan det leda tvetydigheter och att det blir mer arbete vid ett senare skede för att uppnå det förväntade resultatet.

Dessa uttalanden rörande utmaningar och svårigheter beaktades i olika aspekter under intervjuerna men från de fyra respondenterna i den empiriska

datainsamlingen. De uttalanden som presenteras i resultatdelen är det som författaren anser har störst betydelse för att beskriva svårigheterna och

utmaningarna som upplevs under kravhanteringen i systemutvecklingsprojekt.

Kommunikationssvårigheter har författaren valt att inrätta som en central utmaning eftersom samtliga respondenterna i studien nämner det. Detta klarlägger vikten av ett nära samarbete med alla intressenter i systemutvecklingsprojekt när det kommer till att definiera och hantera kraven.

4.5 Framgångsfaktorer

Utifrån uttalanden från intervjuerna och data från den teoretiska referensramen har ett antal framgångsfaktorer identifierats när systemutvecklingsprojekt skall lyckas med att utveckla användbara IT-system. Systemutvecklare 2 uttrycker sig ”Det blir minde missförstånd i designen och kraven blir tydligare när man använder sig av en UX designer i utvecklingsteamet” Systemutvecklare 1 instämmer med föregående och berättar ” Vi har en UX person har ansvar att ta fram specifikationer ur

användbarhetsssynpunkt, de tas fram i olika steg. Om de är en funktion mot

användare så börjas det att de görs upp personas vem, vilken roll användaren har, för att sedan göra upp användarresor. Som beskriver vad personen vill

åstadkomma och sedan hur det ska ske från ett interaktions perspektiv. En grafisk prototyp görs sedan som kan testas mot användare. Slutligen Testas det mot slutanvändarna. De huvudsakliga användarna är de som sitter på kontoret, så de sker snabb feedback mot användbarhetstesterna vilket gör det hela mycket

enklare.”, Systemutvecklare 2 menar på att UX designern gör att det blir mindre missförstånd och underlättar för systemutvecklarna. Systemutvecklarna i sin tur behöver bara gå igenom specifikationen och kolla ifall det är görbart rent tekniskt.

Systemutvecklare 2 menar också på att det nära samarbetet med de faktiska

slutanvändarna underlättar i utvecklingsprocessen eftersom det uppstår oftast färre