Att fastställa metod för effektiv behovs-och kravhantering i IT-projekt

Adamma Sallah

Att fastställa metod för effektiv behovs- och kravhantering i IT-projekt

En fallstudie på Ninetech

Establish ing method for effective needs and requirements management in IT

projects

A case study of Ninetech

Informatik C-uppsats

Termin: VT-2017

Handledare: Odd Fredriksson

Förord

Jag vill börja med att tacka Ninetech för att de var öppna och välkomnande för den här studien. Det betyder otroligt mycket att ni gav mig fria händer och det kreativa utrymme som behövdes för den här studien. Vill dessutom rikta ett stort tack till alla respondenter som ställt upp på intervju och bidrog med sin kunskap och kompetens inom området, samt för att ha visat ett jättepositivt engagemang under empiri undersökningen.

Ett stort tack till min handledare Odd Fredriksson som gett mig konstruktiv kritik under hela arbetets gång, var öppen för mina idéer och förslag samt lyssnade och guidade mig i rätt riktning under hela skrivprocessen. Vill även rikta ett tack till samtliga i min

handledningsgrupp för feedback och diskussioner under arbetets gång.

Slutligen vill jag tacka min familj och vänner för all stöttning och förståelse för att jag varit lite frånvarande under en period. Vill även tack er för att ni trott på mig samt varit min styrka de tillfällen jag tvivlat på mig själv.

Ett jättestort tack till alla som har gjort denna uppsatsstudie möjlig!

Trevlig läsning!

________________

Adamma Sallah

” She needed a hero, so that’s what she became” - Okänd

Sammanfattning

Kravhantering är en självklar process att använda sig av insamling av krav. Dock så hoppar många över behovsanalysen som ska genomföras innan kravinsamlingen kan påbörjas. Att hoppa över behovsanalysen leder till många brister under kravhanteringen. Behovsanalys genomförs för att alla ska förstå varandra och undvika oklarheter. Under behovsanalysen så använder leverantörerna inte sig av tekniska termer utan alla pratar fritt och detta leder till att de kan förstå varandra bättre och underlättar när behovskraven sedan översätts till

systemkrav.

Kravstrategi är en långsiktig plan för verksamheten som innehåller vilka tekniker och metoder som finns i företaget. Inför varje projekt tas en kravplan fram med stöd från kravstrategin för att underlätta arbetet för alla i projektet.

Syftet med denna kandidatuppsats inom informatik är att undersöka och beskriva hur en fastställd metod bidrar till effektivitet vid krav- och behovshantering vilket i sin tur är en bra förutsättning för en mer kvalitativ leverans mot kund. Val av fallverksamhet är Ninetech och målet är att ta fram en metod som är anpassad för deras verksamhet. Som underlag för denna studie genomfördes 4 semi-strukturerade skarpa intervjuer med personer som jobbar på Ninetech. Samtliga respondenters roll hade något med kravarbetet att göra. Den insamlade empirin har sedan ställts mot forskningen som samlats in.

De viktigaste slutsatserna är: att inte hoppa över behovsanalysen, att utföra en behovsanalys så utförligt som möjligt. Brist av behovsanalys leder till oklarheter eftersom användaren och utvecklaren talar olika språk när det gäller krav så är chansen stor att de missförstår varandra.

Vikten av att ha en kravstrategi i företaget, vars uppgift är att underlätta kravarbetet för verksamheten.

Nyckelord: Krav, behov, kravstrategi, kravutveckling, kravfångst, metod, IT-projekt, analys

Innehållsförteckning

1 INLEDNING ... 1

1.1 Problembakgrund ... 1

1.2 Syfte ... 2

1.3 Målgrupp ... 2

2 METOD ... 3

2.1 Vetenskapligt angreppssätt ... 3

2.2 Forskningsmetod ... 3

2.3 Kvalitetsmått för kvalitativ metod ... 4

2.3.1 Validitet och reliabilitet ... 4

2.3.2 Källkritik ... 5

2.4 Datainsamling ... 6

2.4.1 Intervjuguide ... 6

2.5 Undersökningens uppläggning ... 7

2.6 Fallstudie ... 7

2.6.1 Val av fallföretag ... 7

2.6.2 Urval av respondenter ... 8

2.7 Etiska överväganden ... 11

3 TEORI ... 13

3.1 Projekt ... 13

3.2 Projektmodell ... 14

3.2.1 Faser ... 15

3.2.2 Roller ... 16

3.3 Krav ... 17

3.4 Kravhanteringsprocessen ... 17

3.4.1 Samla in ... 19

3.4.2 Prioritera ... 20

3.4.3 Dokumentera ... 21

3.4.4 Kvalitetssäkra ... 22

3.5 Analysmodell ... 24

3.5.1 Kravstrategi ... 25

3.5.2 Behovsanalys ... 26

3.5.3 Kravhantering ... 27

3.5.4 Kravspecifikation ... 29

4 ANALYS ... 30

4.1 Kravstrategi ... 30

4.1.1 Kravledning ... 30

4.1.2 Kravutveckling ... 32

4.1.3 Uppföljning och dokumentation av kravarbetet ... 33

4.2 Behovsanalys ... 33

4.2.1 Kravplan ... 33

4.2.2 Identifiera samt Prioritering av intressenter ... 34

4.2.3 Insamling och bearbetning av intressenternas behov ... 34

4.3 Kravhantering ... 35

4.3.1 Insamling ... 36

4.3.2 Analys och förhandling ... 36

4.4 Kravspecifikation ... 37

4.4.1 Dokumentation & validering ... 37

4.4.4 Övrig dokumentation ... 40

5 SLUTDISKUSSION ... 41

5.1 Slutsatser ... 41

5.2 Fortsatta Studier ... 42

5.3 Modifiering av analysmodellen ... 42

KÄLLFÖRTECKNING ... 44

Skriftliga källor ... 44

Muntliga källor ... 47

BILAGOR ... 48

BILAGA 1: INTERVJUGUIDE ... 48

1

1 INLEDNING

Inledningsvis presenteras en bakgrund till undersökningen och den teoretiska empirin, vidare presenteras C-uppsatsens syfte samt målgrupp..

1.1 Problembakgrund

Felaktigheter i kravinsamling leder till bristande kvalitet i det IT-system som utvecklas. Med felaktig kravfångst kanske fel krav samlas in från fel personer med hjälp av fel tekniker och sedan dokumenteras på ett ineffektivt sätt (Eriksson 2008).

Hur ska kommunikationen gå till i ett projekt så att de insamlade kraven från kund tillfredsställs. Asztalos och Giertz (2010) belyser om hur viktigt det är att all information angående ett projekt ska tas tillvara så att både projektdeltagarna samt nya deltagare som kommer in i projektet efter att projektet har påbörjats kan ta del av all information. De

exemplifierar att problem med bortfall av information kan leda till att utvecklare antingen inte får tillräckligt med information för det systemet som kunden begär eller att de helt enkelt missförstår kravspecifikationen.

Dennis, Wixom och Ruth (2010) anser att när insamling av krav för ett system påbörjas så genomförs en analys bestående av 3 steg. Första steget är att förstå hur systemet fungerar samt förstå situationen. Steg två handlar om att med hjälp av den förståelsen som uppnåtts i steg ett identifiera möjliga förbättringsmöjligheter hos systemet. Tredje samt sista steget handlar då om att definiera kraven för det nya systemet.

”Systemutveckling sker idag under stor press och kräver att leverans sker i rätt tid, med rätt kvalitet och inom budget. För att kunna leverera i tid behövs en kravhanteringsprocess som gör det möjligt att arbeta effektivt utan att behöva uppfinna hjulet på nytt varje gång”

(Eriksson, 2008, s. 20).

Nuseibeh och Easterbrook (2000) anser att det är vid kravinsamlingsfasen som ett

systemutvecklingsprojekts syfte noga anges, intressenter identifieras samt att kundens behov då kartläggs. Det är IT-leverantörernas uppgift att hitta och definiera kundernas krav och detta sker genom kravinsamling som kan ske via en mängd olika metoder (Eriksson 2008).

Insamlingsfasen är en definitiv fas då det är den fasen som avgör hur de resterande fasen kommer att genomföras. Nuseibeh och Easterbrook (2000), Eriksson (2008) samt De Lucia och Qusef (2010) anser att om det är fel person-/er som man samlar in krav ifrån så blir följden att kraven är bristfälliga samt av dålig kvalité vilket leder till att resultaten blir av dålig kvalité.

Språk är ännu en del som kan leda till att kraven blir av dåligt kvalité på grund av språkglappet mellan leverantörerna och kunderna (Eriksson 2008; De Lucia & Qusef 2010).

Saiedian och Dale (2000) lägger tyngd vikt på kravinsamlingen som de anser är den viktigaste fasen under systemutvecklingsprocessen. De förklarar att om kravspecifikationen inte är väl författat så leder det till att utvecklarna inte vet vad ska göra samt att användarna inte vet vad ska förvänta sig. Genom deras långvariga erfarenhet av systemutvecklingsprojekt så anser de att de kan dra slutsatsen att de flesta projekt som misslyckas, misslyckas redan i tidigt skede av projektet eftersom utvecklarna inte riktigt förstått hur användarnas värld ser ut samt att de helt enkelt inte förstår användarna.

Soares, Vrancken och Verbraeck (2011) förklarar hur världen blir alltmer komplext vilket innebär att kravinsamlingen blir allt viktigare men samtidigt även svårare att hantera.

2 Anledningen till höjningen av komplexiteten är på grund av omständigheter så som

omgivningen och teknik.

Naz och Khokhar (2009) anger att målet med kravhanteringsprocessen är att analysera samt ta fram en kravspecifikation som utvecklingen ska utgå ifrån. De tillägger även att ändringar i kravspecifikationen kan ske under utvecklingen.

1.2 Syfte

Syftet med denna fallstudie är att undersöka och beskriva hur en fastställd metod bidrar till effektivitet vid krav- och behovshantering vilket i sin tur är en bra förutsättning för en mer kvalitativ leverans mot kund.

1.3 Målgrupp

Målgruppen för detta examensarbete är verksamheter som har i åtanke att införa en metod för krav- och behovshantering inom IT som ska gälla för alla typer av projekt. Genom denna kandidatuppsats kan konsulter, projektledare och eventuella kunder se uppmärksammade faktorer som påverkar kravarbetet inom ett projekt.

Denna uppsats kan även vara av intresse för andra som vill öka kunskap om kravfångstsmetoder samt studenter inom ämnet informatik.

3

2 METOD

Metodkapitlet är den vetenskapliga utgångspunkten för uppsatsen. I detta avsnitt kommer val av metod att presenteras, tillvägagångssättet för datainsamlingen presenteras samt urvalet av respondenter som ingår i undersökningen.

2.1 Vetenskapligt angreppssätt

Det vetenskapliga förhållningssättet har stor betydelse för hur information samlas in och bearbeta samt vilka slutsatser som dras. Patel och Davidsson (2011) beskriver att en forskares huvudsakliga uppgift är att relatera teorin och verkligheten, eller empiri som det även kallas, till varandra vilket också bekräftas av Björklund och Paulsson (2003) som förmedlar att under uppsatsarbetets gång vandrar forskaren mellan olika abstraktionsnivåer där teorin och empirin utgör ändpunkterna.

Det finns enligt Patel och Davidsson (2011) tre begrepp som forskaren kan arbeta med för att relatera teori och empiri, de tre begreppen är deduktion, induktion och abduktion.

Abduktion är ett angreppssätt som en forskare kan använda sig av för att relatera teori och empiri till varandra genom en kombination av induktion och deduktion (Patel & Davidsson 2011). Patel och Davidsson (2011) belyser att det första steget vid abduktion påminner om det induktiva angreppssättet då utifrån ett enskilt fall formulera ett hypotetiskt mönster som kan förklara mönstret. I det andra steget förklarar Patel och Davidsson (2011) att forskaren prövar hypotesen eller teorin från steg ett på nya fall, denna steg liknar därmed det deduktiva

angreppssättet. Det abduktiva angreppssättet tillåter forskaren att pendla mellan olika sätt att relatera teori till empiri (Patel & Davidsson 2011). Alvesson och Söderberg (2008) nämner att abduktion är ett angreppssätt som ofta används vid fallstudier. Varken induktion eller

deduktion var tillräcklig för att förklara hur människor resonerade, detta var anledningen till att abduktion uppstod (Gold et al. 2011). Abduktion är enligt Järvensivu och Törnroos (2010) ett mellanting mellan induktion och abduktion.

Författaren för denna akademiska uppsats följer den abduktiva angreppssättet då författaren har pendlat mellan olika sätt att relatera teori med empiri för att få en ökad förståelse för frågeställningen. Forskningen under uppsatsen gång inleddes med att information inom det aktuella ämnet söktes i redan existerade teorier. Teorier hittades via vetenskapliga artiklar, tidigare studentuppsatser samt kurslitteraturer. Via teori undersökningen bildade författaren en analysmodell som utformade intervjuguiden som användes för att samla in empiriska data.

Genom användningen av det abduktiva angreppssättet så har författaren kunnat göra en djupgående analys och skapat en förståelse för resultatet som erhållits.

2.2 Forskningsmetod

Valet på forskningsmetod beror alltid på vad man vill ha för svar i sin forskning (Patel &

Davidsson 2011). Hedin (1996) beskriver att forskningsprocessen vid kvalitativa så börjar man alltid med litteraturundersökning för att beskriva forskningsfronten samt för att få en inblick av vad som redan är känt kring ens forskningsfråga; man börjar med att samla in data, analyserar data, sammanställer resultaten och diskuterar dem i ljuset av vad som tidigare är känt (Hedin 1996).

4 Kvalitativ forskningsmetod används när en verbal analys utgörs, genom metoden så går man in på djupet för att förstå ett visst mönster eller situation (Patel & Davidsson 2011). Inom

kvalitativ forskning räknas allt som inte är kvantitativ forskning. Patel och Davidsson (2011) beskriver att den kvalitativa metoden innebär enbart användning av verbala analyser där datainsamlingen fokuserar på så kallad ”mjuka” data. Dessa så kallade ”mjuka” data är i form av kvalitativa intervjuer och tolkande analyser. Metoden används när problemet handlar om att tolka och förstå t.ex. människors upplevelser eller underliggande mönster som bör besvaras genom verbala analysmodeller (Patel & Davidsson 2011).”Kvalitativ forskning är tolkande forskning” (Alvehus 2013).

I denna akademiska uppsats kommer tillämpning av forskningsmetod inriktas på den

kvalitativa forskningsmetoden. Då arbetets utformning kommer att baseras på Ninetech samt intervjuer med stjärnroller när det kommer till kravarbetets tillvägagångssätt hos Ninetech, så är kvalitativ forskningsmetods tillämpning som passar bäst.

2.3 Kvalitetsmått för kvalitativ metod

För denna studie så kommer författaren att använda sig av kvalitativa undersökningar och metoder. För att uppnå så hög grad av säkerhet i den information vi avser att använda, så är det några centrala begrepp som forskare måste beakta enligt Patel & Davidsson (2011).

Kvalitetsmått inom kvalitativa metod bedöms utifrån två kriterier, reliabilitet och validitet och det är dessa två begrepp som forskaren måste beakta. Patel och Davidsson (2011) anser att begreppen validitet och reliabilitet är så sammanflätade att kvalitativa forskare sällan använder begreppet reliabilitet. Istället får begreppet validitet en vidare innebörd inom kvalitativ

forskning (Patel & Davidsson 2011). Enkelt uttryck omfattar kvalitet i kvalitativa studier hela forskningsprocessen (Patel & Davidsson 2011).

2.3.1 Validitet och reliabilitet

Patel och Davidsson (2011) belyser att inom kvalitativa studier så är validiteten inte enbart relaterad till själva datainsamlingen utan att man strävar efter god validitet genom

forskningsprocessens samtliga delar. I kvalitativa studier betecknar validiteten att upptäcka företeelser, att tolka och förstå innebörden av livsvärlden, att beskriva uppfattningar eller en kultur (Patel & Davidsson 2011). Gunnarsson (2002) förklarar att det inte går att skatta tillförlitligheten med siffror vid kvalitativ forskning. Vidare belyser Gunnarsson (2002) att validitet och reliabilitet i kvalitativ forskning handlar om att kunna beskriva hur man samlat in och bearbetat data på ett systematiskt och hederligt sätt. Dessa kan beskrivas genom att man använder sig av vissa begrepp för att beskriva de givna omständigheterna inför projektet samt hur resultaten växer fram under processen. (Gunnarsson 2002). När det kommer till kvalitativa undersökningar så anser Denscombe (2014) nästan omöjligt att repetera undersökningar exakt vilket är anledningen till att många forskare idag använder ordet trovärdig istället för validitet.

Trovärdighet när det gäller insamlade data handlar om att man på goda grunder kan säga att det data man har är rimligt, detta genom att man försäkrar att insamlade data är tolkad på rätt sätt genom att återkoppla till intervjuobjektet och frågar om man tolkat dennes svar korrekt (Denscombe 2014).

Gunnarsson (2002) anser att man kan använda sig av begreppen triangulering och

kommunikativ validitet för att beskriva förutsättningarna vilket också bekräftas av Patel och Davidsson (2011).

Triangulering

5 Triangulering kan enligt Patel och Davidsson (2011) ske på flera olika sätt samt att man kan använda flera olika datainsamlingsmetoder vid datainsamling t.ex. intervjuer, observationer, dagböcker och dokument.

Informationen som samlats in via de tidigare nämnda datainsamlingsmetoderna vägs sedan samman i analysen för att ge en så fyllig bild som möjligt (Patel & Davidsson 2011).

Triangulering handlar enligt Gunnarsson (2002) om att man ser på problemet ur flera synvinklar, t.ex. att man intervjuar personer med olika relation till problemet. Patel och Davidsson (2011) förklarar att triangulering innebär att forskaren validerar genom att välja flera olika datakällor, t.ex. olika personer, platser, tidpunkter där det aktuella fenomenet yttrar sig för att sedan studera samma fenomen men i olika sammanhang för att kunna tolka

variationen hos detta.

Författaren har använt sig av källtriangulering som handlar om att man intervjuer personer med olika relation till problemet, detta genom att jag intervjua roller som t.ex.

Lösningsarkitekt, strateg, testare hos Ninetech för att från deras synvinkel förstå hur de ser på problemet med brist på en fastställd metod för behov- och kravhantering på verksamheten.

Samtliga respondenters arbete påverkar eller påverkas av hur kravinsamlings processen genomförs.

Kommunikativ validitet

Kommunikativ validitet innebär att tolkningarna som forskaren presenterar bör byggas under så att den som läser forskningsrapporten bildar sig en egen uppfattning av rapportens

trovärdighet (Patel & Davidsson 2011). Gunnarsson (2002) anser att kommunikativ validitet handlar om forskarens förmåga att kommunicera hur forskningsprocessen påverkar

kunskapens giltighet. Dessutom förklarar Patel & Davidsson (2011) att kommunikativ validitet även innebär att andra forskare såväl som de som deltog i studien ska kunna ta del av

resultaten. Ett sätt att arbeta med kommunikativ validitet enligt Patel & Davidsson (2011) är genom att låta respondenterna ta del av resultatet samt ge återkoppling till forskaren om dennes tolkningar och slutsatser är rimliga. Den kommunikativa validiteten består av

beskrivning i detalj av hur datainsamlingen har gjorts, beskrivning av hur deltagarna har valts ut samt beskrivning av vad som hänt under analysprocessen alltså hur man gjorde samt vilka beslut som togs genom att tydligt hänvisa till vad som är författarens egna tolkningar

(Gunnarsson 2002).

Om analysen bygger på intervjuer så är det viktigt att respondenternas svar inte tas ur sitt sammanhang (Patel & Davidsson 2011). Forskaren kan därmed välja att redovisa längre sekvenser och svar från en intervju samt välja i analysen att föra samman svar från olika respondenter för att understödja en tolkning (Patel & Davidsson 2011). Patel och Davidsson (2011) förklara även att utifall studien baseras på intervjuer så bör forskaren försöka få en bra balans mellan citat från intervjupersonerna samt forskaren egna kommenterande texter, detta ger läsaren möjlighet att bedöma tolkningens trovärdighet.

2.3.2 Källkritik

En del av källorna som författaren har använt sig av vid undersökningen är från 90-talet men eftersom nyare källor fortfarande hänvisar till källorna från 90-talet så påvisas det att de äldre källorna fortfarande är aktuella.

6 2.4 Datainsamling

Patel och Davidsson (2011) förklarar att det finns olika sätt för forskaren att använda sig av för att samla information för att få ens frågeställningar besvarade. Patel och Davidsson (2011) skiljer på primärdata och sekundärdata. Vilken källa som forskaren väljer att använda sig av beror bland annat på vilken tid samt vilka medel som finns till förfogande (Patel & Davidsson 2011).

Patel och Davidsson (2011) förklarar att primärkällor är källor som forskaren som utför studien själv samlar in. Dahlström (2011) anser att primärdata är data som framtagits av författaren själv genom enkäter, intervjuer eller fallstudier. Vidare klargör Dahlström (2011) att fördelen med primärdata är att insamlingen kan utformas efter avgränsningar och

forskningsfrågorna samt att nackdelen med primärdata är att det blir kostsamt vad gäller tid, arbetsresurser och monetära resurser. Kort sagt så innebär primärdata, data/information som utmärkande har samlats in för den egna undersökningen (Patel & Davidsson 2011).

Sekundärdata innebär andrahandsinformation, alltså att det är en annan forskare som samlat in källorna. Björklund och Paulsson (2012) belyser att sekundärdata är data/information som inte är primärt insamlat för den egna studien. Sekundärdata är tillskillnad från primärdata

tidsbesparande, kostnader undviks samt att datan vanligtvis är av högkvalitet. Med högkvalitet så menas att undersökningarna ofta är nationella och därmed välgrundade (Bryman & Bell 2011).

Uppsatsen består av både primär- och sekundärdata. Uppsatsens teorikapitel innehåller sekundärdata i form av vetenskapliga artiklar, studentlitteraturer, Internetkällor, tidigare uppsatser samt böcker. Insamling av primärdata för denna uppsats har skett genom kvalitativa intervjuer. Undersökningen började med att jag kontaktade Ninetech och förklarade för de mina intresseområden och ifall de eventuellt hade något av intresse för studien. Kontakten sköttes först via mejl för att sedan inplanera ett inledande möte där jag fick träffa försäljnings och marknadschefen på ett möte för att diskutera undersökningens upplägg och syfte. Under mötet förklarade försäljning och marknadschefen om hur Ninetech i nuvarande stund inte har en fastställd kravfångstmetod och att de skulle behöva hjälp med att ta fram en

kravfångstmetod. Efter mötet på Ninetech då jag även fick tag på dokument av gamla Ninetech projekt så hade jag tillräckligt grund för att börja med insamlingen av sekundära data.

Den insamlade primärdata gällande empirin återfinns i analyskapitlet där även en jämförelse av teori och empiri ingår.

2.4.1 Intervjuguide

I studien så användes semi-strukturerade intervjuer vilket innebär att man utgår från ett frågeområde istället för att ställa exakta samt detaljerade frågor. Intervjuguiden utformades utifrån analysmodellen med studiespecifika semi-strukturerade intervjufrågor (Bilaga 1). Polit och Beck (2013) förklarar att semi-strukturerade intervju innebär att intervjun följer en mall med frågor som respondenten ska svara på dock så finns det dessutom plats för att ställa kompletterande frågor. Bryman (2011) tillägger att det är tillåtet att ställa frågor som inte finns med på intervjuguiden vid en semi-strukturerad intervju men att intervjun bör följa

intervjuguidens struktur. Intervjuguiden innefattar områdena; kravstrategi, behovsanalys, kravhantering samt kravspecifikation. Intervjun började med bestämda frågor om deras bakgrund för att sedan börja med mer öppnare frågor en bit in i intervjun.

Vid utformandet av intervjuguiden så utnyttjades ”tratt-metoden” som Patel och Davidsson (2011) nämner.

7 2.5 Undersökningens uppläggning

”Utifrån vår problemformulering måste vi bestämma hur vi ska lägga upp undersökningen”

(Patel & Davidsson 2011). Med detta menar Patel och Davidsson (2011) att forskaren måste bestämma sig angående vilka individer som ska medverka i undersökningen, vilka tekniker forskaren ska använda sig av för att samla in information, om en förundersökning ska göras och/eller en pilotstudie sam bestämma undersökningens tidsplan. Detta bekräftas även av Bryman och Bell (2011) som belyser att undersökningens uppläggning handlar om kriterier som används vid en bedömning eller utvärdering av undersökningar. Undersöknings

uppläggning är därmed en ram för hur empiriska data ska genereras som ska stämma in på de uppsatta kriterierna samt för de frågeställningarna forskaren har valt.

Det finns enligt Patel och Davidsson (2011) olika sätt att samla information på för att få en frågeställning besvarad samt att ingen kan förutsäga att en metod är bättre än någon annan.

Tekniken forskaren väljer att använda sig på beror mestadels på vad vi avser att undersöka samt vad som kommer att ge oss bäst svar på vår undersöknings fråga i förhållande till den tid och medel vi har till vårt förfogande (Patel & Davidsson 2011).

Jag ska i uppdrag av Ninetech ta fram en metod för behov- och kravhantering för deras webb och IT-projekt. Metoden ska vara flexibel och kunna funka för både stora samt små men även enkla och komplexa projekt. Det är dock av allra störst vikt att metoden främst ska funka på de stora och komplexa projekten, samt de stora och enkla. I dagslägets projekt i Ninetech så jobbar de mestadels agilt samt i små sprintar.

Ninetech uppmuntrar självständighet och frihet i hur man som konsult arbetar i projekten. Den friheten är viktig för konsulten och någon man uppskattar väldigt mycket hos Ninetech. Ur ett projektledarperspektiv är det dock önskvärt att variationerna i arbetssätt inte skiljer sig åt för mycket, utan att det finns vissa rutiner/mallar som alla konsulter följer.

2.6 Fallstudie

Yin (2014) förklarar att utgångspunkten för en fallstudie är att djupgående undersöka och söka förståelse för ett enda fall i verkliga sociala sammanhang. Vidare belyser Yin (2014) att syftet med fallstudie är då att skapa en värdefull och djup förståelse i fallen som sedan

förhoppningsvis kan resultera i nya insikter och lärdomar om den sociala verklighet som studien är tänkt för.

Patel och Davidsson (2011) konstaterar att fallstudier är en undersökningsprocess som går ut på att man gör en djupgåendeundersökning på ett ende eller några mindre fall för att kunna få mer kunskap om det man ämnar undersöka. Ett fall kan därmed vara en eller flera individer, grupper, intressegrupper, organisation, en situation osv som studeras av väldigt detaljerad.

2.6.1 Val av fallföretag

En fallstudie är att en undersökning som genomförs på en mindre avgränsad grupp. Det som vill uppnås med en fallstudie är att det informationen ska bli så heltäckande som möjligt.

Fallstudiemetoden har tillämpats som undersökningsupplägg i denna uppsats. Undersökningen fokuserar på företaget Ninetech. En av fördelarna med fallstudiemetoden enligt Denscombe (2014) är att det möjliggör att fokusera undersökningen på en mindre enhet. Patel och

Davidsson (2011) tillägger att det i sin tur leder till djupare kunskap eftersom att en enhet kan studeras i helhet. Nackdelen däremot enligt Denscombe (2014) är att det är svårt att tydligt definiera ett fall. Nedan presenteras tillvägagångssättet för valet av fallföretag.

8 Ninetech

Efter kontakt med en utvecklare på Ninetech så framgick det att de idag saknar en metod att använda sig av vid kravhanteringsarbetet. Genom utvecklaren kom jag i kontakt med försäljnings och marknadschefen som även var min handledare på företaget under hela uppsatsen. Försäljnings och marknadschefen förklarade att de försöker allt mer hitta

metodramverk och olika typer av processer att följa. De är sprungna ur en slags ingenjör och problemlösarkultur där de är ganska fria i hur de jobbar, men de ser också ett behov av att strukturera upp vissa delar, och just när det gäller kravhantering så gör de det i väldigt hög grad men på väldigt många olika sätt. De kände att det är ganska intressant att få någon utifrån som kanske inte har med sig erfarenheter från likartade verksamheter utan har mer en teoretisk och akademisk approach på det, som skulle kunna titta på det och se hu de jobbar idag, vad de saknar samt att eventuellt komma med förslag på hur de skulle kunna göra framöver.

En kravfångstmetod kommer enligt försäljnings och marknadschefen att underlätta genom att om det finns en metod att utgå ifrån så är det lättare att lära ut internt, det är lättare för fler personer att sätta sig in i metoden och kunna jobba med krav, kravhantering, jämfört med att det helt och hållet bygger på egna erfarenheter. Alltså dels att fler kan jobba med det och sen att de i bästa fall får upp kvalitén på kravarbetet samt att det finns en grundnivå och

grundstruktur som de följer, vilket gör att de vet oavsett om det är konsulten A eller B som jobbar med krav så ser det likartad ut och följer nån slags grundläggande kvalité i arbetet.

2.6.2 Urval av respondenter

Forskaren behöver vid en undersökning få tillgång till information, detta sker ofta genom att forskaren intervjuar ett urval av den aktuella populationen (Bryman & Bell 2012). Denscombe (2014) förklarar att principen med urval är att det är möjligt att skapa rimliga och korrekta slutsatser utan att behöva samla data från varje enskild medlem ur en forskningsgrupp, samt att detta är speciellt attraktivt för enkätundersökningar.

Denscombe (2014) belyser att vid val av stickprov så kan forskaren göra en av två saker, antingen kan de försöka få tag på representativt urval eller så kan de försöka få tag på ett utforskande urval. De olika sätten innebär olika tillvägagångssätt och tenderar att vara associerade med olika typer av social forskning. (Denscombe 2014). Representativt urval handlar om användandet av kvantitativa data samt att det mestadels brukar förknippas med enkätundersökningar medans utforskande urval ofta används i småskalig forskning samt att det genererar kvalitativa data (Denscombe 2014). Författaren för denna uppsats har valt att

använda sig av ändamålsenligt urval, detta urval innebär att respondenterna deltog frivilligt men att de även hade ett intresse samt en gemensam upplevelse av det som författaren skulle undersöka. När det handlar om ändamålsenligt urval kan forskarna välja informanterna utefter deras kunskap om det som ska studeras (Polit & Beck 2008).

Tabell 1: Sammanställning av intervjuade respondenter Källa: Författaren

RESPONDENT BEFATTNING FÖRKORTNING I UPPSATSEN

TID YRKESERFARENHET Jonas Aronsson Försäljnings & marknadschef Försäljnings &

marknadschef

- 8år Rickard Nilsson Lösningsarkitekt & Senior utvecklare Lösningsarkitekt 1 56 min 10år Anders Bergström Lösningsarkitekt Lösningsarkitekt 2 1h 16min 7år

Tina Lungström Testare Testare 42 min Ca.1år

Mattias Berglund Strateg (Verksamhetsrarkitekt) Strateg 48 min 11år

9 Tid för intervjutillfället med försäljnings och marknadschefen anges inte på grund av att han var min handledare på fallföretaget och att ett flertal intervjuer genomfördes med honom. Han är således inte en av respondenterna av studien.

Försäljnings och marknadschef – Jonas Aronsson

Jonas Aronsson sitter med i ledningsgruppen på Ninetech och har jobbat sammanlagt 8år på Ninetech. Han är dessutom ytterst ansvarig för alla Ninetechs konsulter, dock så har han valt att inte kalla sig själv för konsultchef men det är en vanlig sån titel. Han jobbar också mycket med försäljning och kundansvar för några av Ninetechs största kunder. Jonas har en

universitets examen inom media och kommunikationsvetenskap, så han är egentligen utbildad informatör kommunikatör. Han har jobbat med försäljning, projektledning och rådgivning inom reklam marknadsföring och webb och it sen 2003. Innan han börja på Ninetech så jobba han på andra webbyråer och även på reklambyråer.

Han är nog en sån person som inte har en normal arbetsdag men det är det som är det roliga också för hans del då han jobbar ganska fritt. Ibland kommer han lite senare till kontoret men sitter kanske hemma och jobbar lite på kvällen. Så det är inget klassiskt 8–5 jobb.

Den mest normala arbetsdagen är nog att han kommer till kontoret, går igenom mejlen, kikar igenom kalendern, vilka möten han har bokade och sen tar det bara fart i nån riktning. Det är ganska mycket dialog med kollegor, ganska mycket ledning och styrning, hjälpa Ninetech team chefer att fatta rätt beslut. De perioder han jobbar mycket med kunder så blir det ganska mycket resor också så då är det inte en kontorsdag utan då är det att han tar tåg/flyg/bil kanske tidigt på morgonen för att träffa en kund.

Jonas förklarar att ena sidan av hans arbetsuppgifter så är det försäljning och key account management, att vara med och driva Ninetechs största kunder framåt, stötta kundteamet, strateger, projektledare, arkitekter så att de är drivande mot kunder och hjälper de med sina utmaningar, så lite affärsrådgivning. Den andra delen är att agera ledare i organisationen och finnas där för andra chefer och för konsulter som behöver en klapp på axeln eller lite stöttning, ganska mycket beslut som ska fattas under en dag där kanske man vill bolla med honom innan man fattar besluten. Han har alltså en extern roll mot kunderna och sen har han en intern roll som handlar mycket om att leda, styra delegera samt coacha.

Lösningsarkitekt, Senior utvecklare & Team Chef – Rickard Nilsson

Rickard Nilsson jobbar som lösningsarkitekt, senior utvecklare och team chef på Ninetech.

Han läste civilingenjörsprogrammet med informationsteknologi inriktning på Karlstads Universitet och har sedan dess jobbat på Ninetech i sammanlagt 10år. Oftast sitter Rickard med en leverans där han antingen skriver lösningsförslag eller så har han lämnat

lösningsförslag och är med och följer upp och leder arbetet kring att bygga det. Rickard sitter med i kund möten, interna möten med utvecklarna och projektledarna. Under

lösningsförslagasarbetet är det möten med kund, träffar kundens kund samt workshoppar tillsammans med andra utvecklare och lösningsarkitekter. Som teamchef så har han medarbetarsamtal och avstämningar kring rekrytering och debiterings grad osv.

Lösningsarkitekt – Anders Bergström

Anders Bergström är lösningsarkitekt på Ninetech och har jobbat på Ninetech i 7 år. Anders har gått dataingenjör programmet på Karlstads Universitet och har jobbat på några andra it bolag i Karlstad innan Ninetech. Som lösningsarkitekt så varierar Anders arbetsdag beroende på om han är i ett större projekt, då vet han oftast vad det är han ska göra, då är det bara att köra på. Ibland kan han vara inne på flera projekt samtidigt då kanske han börjar dagen med

10 att gå igenom sitt klander och planera lite vad han ska syssla med. Sitter han i ett projekt och det är flera kolleger som är inblandade så har de oftast en stå upp möte på morgonen där alla samlas och pratar och drar sin egen planering för att kunna synka lite. Sitter han t.ex. i ett projekt där han jobbar mot kund och kundens andra leverantörer som kanske inte har så många ninetechare med sig då beror det lite på, antingen så stämmer han av på samma sätt med kunden eller lägger man upp sin dag, det beror lite på vilken typ av projekt men nån typ av planering börjar han dagen med.

Anders förklarar att som lösningsarkitekt kan man ju beskriva men sen hamnar man väldigt sällan i ett projekt där man gör exakt det som man beskriver sin roll som för oftast så får … man får anpassa sig lite. Ta fram en lösning, en lösningsarkitekt kanske försöker översätta kundens behov till en teknisk lösning och det kan ju innefatta allt från att ha de första mötena med kunden genom olika metoder kanske tex genom intervjuer, workshops, få ut av kunden vad har de för problem, önskemål och krav och sen försöka ta fram nån typ av systemstöd egentligen för att lösa de problemen som de har eller om de vill ha en ny typ av system som de inte har haft förut. Ta kundbehoven och kunna sätta sig in i verksamheten och sen kunna översätta det till nån typ av teknisk lösning

Testare – Tina Lungström

Tina Lungström är utbildad programvarutestare genom en 2årig YH-utbildning. Som testare är Tina alltid inblandad i flera projekt samtidigt, vissa projekt vill att hon utgör tester en viss veckodag, andra projekt är lite mer flexibla medans andra har behov av att man utför testning på engång. Som testare har Tina jättesvårt att planera hennes dagar i förväg, hon gör vanligtvis en grovplanering av veckan men vet att den alltid kommer att ändras. Hon behöver därmed vara superflexibel och strukturerad samtidigt.

Som testare behöver hon veta framförallt vad kunden förväntar sig att Ninetech gör, samt att det är lika viktigt att veta hur slutanvändaren ska få nytta av lösningen Ninetech levererar.

Tina jobbar mycket med att sätta sig in i kundens verklighet och hur saker och ting ska fungera. Uppgiften som testare är att ta reda på vad kan man göra så att lösningen inte ska fungera. Hennes uppgift är inte att verifiera så att det fungerar för det gör utvecklarna så bra själva, hennes uppgift är att leta problem.

Strateg (Verksamhetsrarkitekt) – Mattias Berglund

Mattias Berglund är dataingenjör på utbildnings biten i från Karlstads Universitet. Mattias förklarar att han har jobbat ganska klassiska karriärvägar som har varit att han började som utvecklare, sen blev han tekniskt projektledare, lösningsarkitekt, projektledare,

affärsområdeschef i ett antal år på Ninetech och nu jobbar han bara som konsult som digital strateg och rådgivare, han är en kodare från början.

Mattias har inga vanliga arbetsdagar, endera så är han hos några av Ninetechs kunder och jobbar tillsammans med kunderna själv eller tillsammans med någon kollega. Den ena typen av arbetsdag som finns så är det workshop eller arbetsmöten med kund, den andra typen av dagen kanske han är på Ninetech och jobbar i några projekt tillsammans med projektledare och utvecklare då handlar det mycket om att han hjälper till, kravställer och förklarar kundens behov så att de bygger rätt lösningar utifrån det. Egentligen så jobbar han tillsammans med kund eller så representerar han kund och sen är det endels presentationer, ganska mycket säljarbete samt lite föreläsningar.

11 Mattias arbetsuppgifter innebär dels att hjälpa Ninetechs kunderna och lista ut vad de vill och vad de behöver, det är den viktigaste arbetsuppgiften. Väldigt många kunder som han träffar har egentligen inte tillräckligt bra koll på vad och hur de ska göra i sitt digitaliseringsarbete, alla vet att de måste göra nånting och att världen blir mer och mer digital men det är jättesvår att veta exakt vad det är de ska göra, i vilken ordning det ska göras, när de ska göra det och vad är det som är viktigast. Detta är den viktigaste uppgiften han har. Sen är hans andra uppgift att och se till så att arkitekterna och utvecklarna på Ninetech att förstå och lära sig kundens behov med hjälp av honom, de är också med och träffar kund då han inte jobbar ensam utan de jobbar tillsammans. Att hjälpa och rådge kunderna hur de ska göra och vad de ska satsa på och sen när projektet startar igång så är det att hjälpa till och brygga ihop

verksamhetsbehovet ner till Ninetechs lösningsarkitekter och utvecklare så att rätt lösningar byggs på rätt sätt.

Samtliga respondenter kontaktades via mejl och informerades om studien, eftersom jag ville att de skulle känna sig bekväma vid intervjutillfället så fick de bestämma var intervjun skulle ske. Jag träffade samtliga respondenter enskilt en gång innan där jag genomförde sonderande intervju för bekvämlighetens skull för att sedan boka in de skarpa intervjuerna.

2.7 Etiska överväganden

Målet för allt forskningsarbete handlar enligt Patel och Davidsson (2011) om att kunskapen som tas fram ska vara högst trovärdig och viktig inte bara för individen men även för samhällets utveckling. Vidare förklarar Patel och Davidsson (2011) att även mindre

forskningsarbete t.ex. uppsatsarbete ska omfattas av noga överväganden av forskningsetiska aspekter.

Patel och Davidsson (2011) och Vetenskapsrådet (2002) belyser att det finns fyra övergripande etikregler att ta hänsyn till vid forskning. De fyra huvudkraven är:

1. Informationskravet

Forskaren ska informera de som berörs av forskningen om forskningsuppgiftens syfte.

De berörda skall inför undersökning mottagit uppgift om syfte samt beskrivning av hur undersökningen ska genomföras. Att individerna som deltar i undersökningen

medverkar frivilligt måste framgå samt att uppgifterna de lämnar inte kommer att användas för något annat syfte än vad undersökningen är ämnad för.

2. Samtyckeskravet

Individerna som deltar i undersökningen bestämmer själv över sin medverkan samt att forskaren ska inhämta samtycke från individerna inför undersökningen. Individerna ska även kunna avbryta sin medverkan utan att det får negativa följder.

3. Konfidentialitetskrav

Uppgifter angående personer som deltar i en undersökning bör behandlas konfidentiellt samt att identifiering av enskild individ vid presentation av uppsatsen bör vara

omöjligt. Undersökningar sker mestadels genom att individerna lämnar information eller svarar t.ex. på frågor genom intervjuer, forskaren måste då värna om

informationen som individerna lämnar samt värna om deras integritet.

4. Nyttjandekravet

Uppgifter om enskilda, insamlade för forskningsändamål, får inte användas eller utlånas för kommersiellt bruk eller andra icke-vetenskapliga syften.

12 Vetenskapsrådet (2002) anser att forskaren bör informera berörda personer av var

forskningsresultatet kommer att publiceras eller erbjuda en rapport eller sammanfattning av undersökningen ifall de är intresserade.

Informationskravet togs hänsyn till genom att alla berörda respondenter i uppsatsstudien informerades innan via mail om vad undersökningen handlade om, eftersom att de flesta på Ninetech redan hade ett hum om undersöknings syfte sedan tidigare. Respondenterna valde själva om de ville delta på en intervju, de blev även informerade att intervjuerna önskades spelas in för uppsatsstudien ändamål, vilket samtliga respondenter samtyckte till.

Samtyckeskravet togs hänsyn till genom att respondenterna återigen på plats blev informerade angående vart deras medverkan skulle komma att publiceras, vilka fler som skulle vara del av studien, att intervjun önskades spelas in och att de när som helst hade möjlighet att avbryta eller meddela om det var något de sagt som de inte önskade skulle tas med i uppsatsstudien.

Samtliga respondenter samtyckte till att medverka i uppsatsstudien och var medvetna om att det var helt frivilligt.

Konfidentialitetskrav togs hänsyn till genom att bekräfta med respondenterna att de godkände och kände sig bekväma med att deras namn uppgavs i uppsatsen. Samtliga respondenter kände sig trygga i sin relation sinsemellan och upplevde inga bekymmer med att delta vid namn. I uppsatsen kommer dock samtliga respondenter nämnas vid respektive titel istället för namn, detta för att underlätta för läsaren och ge perspektiv utifrån de olika rollerna i förhållande till innehållet i analysen, se kapitel 4. Analys.

Nyttjandekravet togs och tas hänsyn till genom att den insamlade empirin från samtliga intervjuer med samtliga respondenter inte kommer att nyttjas till något annat än denna uppsatsstudie. Den sammanfattade empirin publiceras endast i denna uppsats samt att ingen annan än författaren har tagit del av de inspelade intervjuerna.

13

3 TEORI

Detta kapitel avser att redogöra för den teoretiska insamlingen som genomförts för undersökningen. Inledningsvis behandlar teorikapitlet olika källor främst hämtade från vetenskapliga artiklar, uppsatser samt böcker. Fortsättningsvis presenteras analysmodeller,

3.1 Projekt

För att kunna förstå betydelsen av ett IT-projekt så är det mycket betydelsefullt att man först förstår fenomenet projekt, utifrån beskrivningen av vad ett projekt är så går det att definiera IT-projekt. Nordberg (2008) förklarar att ordet projekt kommer från det latinska ordet

projicere som betyder ”kasta fram”. Carlson och Nilsson (2012) klargör att det är en tanke som kastas fram som sedan leder till utveckling av en idé som man vill pröva för att utveckla samt förbättra en verksamhet. Marttala och Karlsson (2011) definierar projekt som en tidsbegränsad och från övrig verksamhet unik och avgränsad aktivitet, som genom styrning och resurser ska nå ett bestämt mål vilket också bekräftas även av Görling (2009) som beskriver ett projekt som

”…en temporär organisation som sätts samman för att under en begränsad tid lösa ett specifikt problem”.

Det är idag mycket vanligt att arbeta i projektform. En förutsättning för att kunna driva ett projekt är att man har någon sorts kunskap i detta och behärskar grunderna i traditionell projekthantering. (Eklund 2011)

Enligt Andersen, Grude och Haug (1994) karaktäriseras ett projekt av följande:

- Det är en engångsuppgift

- Det ska leda fram till ett bestämt resultat - Det kräver olika typer av resurser

- Det är tidsbegränsat.

Nordberg (2008) definierar ett projekt som:

”Projekt är en välplanerad handlings- och framtidsinriktad verksamhet, med ett specifikt syfte inom ett avgränsat område, som utförs under begränsad tid av en tillfällig organisation, med öronmärkta pengar och andra erforderliga resurser.”

Utöver definitionen ovan samt de kriterierna som Andersen, Grude och Haug (1994) nämner, så tydliggör Nordberg (2008) ett projekt genom följande kriterier:

- Välplanerat

- Tillfällig organisation - Avgränsat område

Carlsson och Nilsson (2012) tillägger utöver de ovanstående följande kriterier:

- Har alltid en beställare och mottagare - Utgår från en klart formulerad idé

- Syftar i regel till utveckling eller förändring av organisation

14 3.2 Projektmodell

Eklund (2011) beskriver att i ett projekt så arbetar man ofta efter en projektmodell.

Projektmodell är enligt Eklund (2011) de samlade regler och hjälpmedel som används för att driva ett projekt, de är bra att ha för att skapa en överblick, karta över projektet. Genom att strukturera upp alla delar kan man snabbt och enkelt orientera sig och identifiera de olika stegen i modellen, samt skapa en gemensam bild i projektet och i den övriga verksamheten.

Vidare skriver Eklund (2011) att projektmodellen ska innehålla: arbetsflöde, projektets olika steg, avstämningspunkter, roller och olika dokument.

Ett projekt kan beskrivas som en sammanhängande enhet av flera delar, där alla delar beror av och på varandra. Balic och Ottersten (2010) förklarar att ett IT-projekt kan delas in faser, hur många faser just ett projekt har beror på vilken projektmodell som används. Det är upp till projektägaren att uttrycka vad som efterfrågas med projektet och om det efterfrågade resultatet har levererats. Därför är ansvaret för de två första och sista faserna alltid ytterst

projektägarens. De faserna infaller före respektive efter att projektorganisation är på plats.

Nedanstående projektmodell är indelad i sex olika faser, där de blåmarkerade faserna i modellen handlar om att förberedning av projektet samt utvärderingen av resultatet vilar på verksamheten. De grönmarkerade fasen är projektledarens ansvar och de belyser det arbetet som utförs i projekt (Håkansson 2010).

BP står för beslutspunkt. Enligt Håkansson (2010) så är det en enorm fördel att det finns tydliga beslutspunkter där man stannar upp, rapporterar och fattar beslut för att få en bra styrning före och under projektet. Macheridis (2005) anser att ett effektivt sätt att hantera övergångarna mellan faserna är genom att koppla samman delmål med beslutspunkterna detta medför att man kan följa upp, stämma av samt diskutera alternativa handlingsplaner samt revidera tidsplaneringen. Beslutspunkterna är tydliga avgränsningar mellan de olika faserna och sker således i början och i slutet av alla faser. Dessa är obligatoriska vilket innebär att för att kunna fortsätta till nästa fas så krävs det ett aktivt beslut om projektets fortsättning, ifall projektet ska ändra inriktning, avslutas eller fortsätta (Håkansson 2010).

Håkansson (2010) förklarar att under projektets genomförande är det dock styrgruppen som är den beslutande instansen. Projektledaren har avstämningar med styrgrupp och presenterar projektets resultat och prestationer. Styrgruppen bestämmer utifrån det om projektet ska fortsätta, ändras eller avslutas. Styrgruppen i sin tur stämmer av med beställaren, om inte beställaren ingår i styrgruppen.

Figur X: Projektmodellen Källa: Författaren

15 En projektmodell är vanligtvis uppdelad i olika faser med tydlig avgränsning. Att projektet är uppdelad i olika faser betyder dock inte att faserna är helt åtskilda. T.ex. så är arbetet som görs i behovsfasen underlag samt så adderas det till förstudien. Förstudien är i sig ett underlag i projektplaneringen och så vidare. Den enda fas som kan vara överflödig är förstudien om man redan efter behovsfasen har tillräckligt med kunskap. Man ska dock beakta att varje fas tjänar sitt syfte för att bygga på kunskapsbasen, avgränsa och planera vad som ska göras (Håkansson 2010).

Projekt är en arbetsform som kännetecknas av att mycket arbete läggs på att planera väl. I de första faserna ska behovet kartläggas, alternativa lösningar utredas, genomförandet ska

planeras och mål formuleras. Det är inte ovanligt att planeringen av ett projekt tar lika lång tid som dess faktiska genomförande. Ju bättre planerat projektet är desto smidigare kommer genomförandet att bli och oddsen att projektets syfte uppnås ökar avsevärt (Håkansson 2010).

3.2.1 Faser

Nedan presenteras faserna i projektmodellen. Utvärdering av projekt kommer inte beskrivas då det faller utanför ramarna för denna studie.

❖ Behov - Behovsfasen handlar enligt Håkansson (2010) i korta ordalag om att förstå vad som är det faktiska behovet samt vad de bakomliggande orsakerna till behovet är, alltså kännetecknar behovsfasen idéer och problem. I behovsfasen ska man undvika att diskutera lösningar och aktiviteter, annars riskerar man att tidigt låsa in sig på endast en lösning. Fokuset under behovsanalysen handlar om att man fått en idé om hur man ska förbättra verksamheten alternativt så har ett problem uppstått som ska åtgärdas i ett projekt; det finns helt enkelt ett behov (Håkansson 2010).

❖ Förstudie - Gustavsson (2013) förklarar att förstudien ska ge svaret på vad projektet ska åstadkomma samt att förstudiefasen oftast definierar projektets ramar som anger gränser för tid, kostnad och omfång. Förstudie är enligt Jansson och Ljung (2004) dan fasen där det undersöks om, samt i så fall när ett eventuellt projekt ska genomföras.

Syftet med förstudien är att utreda samt ta fram alternativa lösningar på hur behovet kommer att lösas (Håkansson 2010). Hur långt en förstudie kan fortgå beror på från fall till fall, det kan alltså vara från en kort studie på ungefär en vecka till ett mer

omfattande projekt på flera månader där man praktiskt testar olika metoder och tjänster (Håkansson 2010).

❖ Planering – Planerings fasen ska ge svaret på hur projektet ska genomföras, samt att resultatet från planeringsfasen är bland annat en tidsplan, en budget, ett

organisationsschema samt en rikslista (Gustavsson 2013).

❖ Genomförande – Projektet genomförs en andra gång på denna fas, dock så

genomfördes projektet bara i teorin under planeringsfasen, men på genomförandefasen så genomförs det på riktigt (Gustavsson 2013).

❖ Avslut – Avslutsfasen handlar enligt Gustavsson (2013) att resurser ska återlämnas samt att ett avslutande dokument ska skrivas på.

16 3.2.2 Roller

Inom ett projekt så finns det ett antal roller med varierande ansvar och uppgifter. Rollerna i ett vanligt projekt eller ett IT-projekt kan vara samma samt att beskrivningen av rollerna är generisk. Jansson och Ljung (2004) förklarar att vilka roller som ingår i ett visst projekt

varierar mellan projektets karaktär, projektets storlek samt organisationen. I vissa så fall så kan en person inneha flera roller i ett projekt eller även i flera olika projekt (Jansson & Ljung 2004). Håkansson (2010) belyser att det är viktigt att innan ett projekt startas att reda ut vem som ansvarar för vad. Vidare förklara Håkansson (2010) att ju tydligare och klarare rollerna är desto enklare blir det att arbeta eftersom att det underlättar både för beställaren samt den som ska leda projektet.

Att jobba i ett projekt handlar om att alla har det gemensamma ansvaret att tillsammans nå det satta målet, vid en eventuell brist av en rolls ansvarstagande så får det effekter på projektet som helhet.

❖ Beställare - Beställare är uppdragsgivaren som efterfrågar projektets resultat.

Beställare är enligt Håkansson (2010) den fysiska personen som beslutar att uppstart samt avslutning av ett projekt. Det är beställarens roll att sätta mål för projektet,

säkerställer finansieringen, utser en projektledare samt en styrgrupp (Håkansson 2010).

Jansson och Ljung (2010) beskriver beställare som en chef eller grupp av chefer i exempelvis en styrgrupp som beslutat att projektet ska genomföras samt som tilldelat uppdraget till projektledaren.

❖ Styrgrupp - Enligt Jansson och Ljung (2004) så är styrgruppen en sammanslutning, som består av chefer eller ledning i verksamheten samt som har ansvaret att ta besluter gällande projektet. Detta bekräftas av Håkansson (2010) som belyser att styrgruppen fattar de avgörande besluten i ett projekt samt att styrgruppen ska ses som

projektledaren och arbetsgruppens styrelse. Beställaren kan vara ensam styrgrupp, detta sker framförallt i mindre projekt. Ifall det skulle ske att beställaren inte ingår i styrgruppen så är det ordförarens ansvar att göra avstämningar med beställaren

(Håkansson 2010). Styrgruppen ska utöver detta agera stöd till projektledaren (Jansson

& Ljung 2010).

❖ Projektledare - Håkansson (2010) och Jansson och Ljung (2004) båda anser att projektledarens uppgift är att leda projektet från start till slut med ansvar för att projektet når de uppsatta målen. Projektledarens uppgift är att skriva projektplanen utifrån projektbeställningen eller förstudien, dock finns det vissa fall då en projektplan redan finns innan en projektledare blir tillsatt. Projektledarens uppgift blir då att stämma av planen med beställaren samt säkerställa att man har förståelse för vad som ska göras samt vid behov revidera projektplanen (Håkansson 2010). Balic och

Ottersten (2010) nämner att det är projektledaren som tar beslut om projektets genomförande. Håkansson (2010) förklarar att när en projektledare plockas in kan varierar från fall till fall, det behöver inte nödvändigtvis vara den tänkta projektledaren som gör förstudien men det är en fördel om projektledaren är den som leder

projektplaneringen. Projektledaren ska enligt Jansson och Ljung (2004) rapportera till en projektbeställare eller styrgrupp.

❖ Delprojektledare - Vid projekt som är för stor, komplext eller för att det är mer praktiskt att dela upp ansvaret så kan man dela upp projektet i mindre delprojekt

17 (Håkansson 2010). Håkansson (2010) förklarar vidare att en delprojektledare ansvarar för att driva delprojekt enligt projektplan från beställning till avslut samt att

delprojektet uppnår sina mål. Delprojektledaren rapporterar till projektledaren och inte direkt till styrgruppen.

❖ Projektdeltagare - Projektdeltagarna eller projektmedlemmarna som de även kallas är de som under ledning av projektledaren utför arbetet i projekt (Håkansson 2010). Deras ansvar är att de ska se till att överenskommet arbete utförs enligt tidplanen (Håkansson 2010). Eriksson (2008) förklarar att projektdeltagare är de personer som är involverade i projektet, dessa kan exempelvis vara testare, utvecklare, testledare. Projektgruppen består enligt Tonnquist (2014) av personer som ska utföra aktiviteterna inom ett projekt 3.3 Krav

Eriksson (2008) belyser att ordet krav kanske egentligen inte är det bästa ordet att använda sig av eftersom ordet krav betyder att det är något som krävs samt att det måste uppfyllas

ovillkorligen. Vidare förklarar Eriksson (2008) att ett de flesta krav är förhandlingsbara samt att det finns några faktorer som bestämmer om kraven är genomförbara. Ottersen och

Berndtsson (2002) definierar krav som uttalade och outtalade förväntningar på en produkts attribut. Wiktorin (2003) beskriver krav som en önskvärd egenskap eller funktion hos ett IT- system, men att denna definition antyder att krav är något som måste uppfyllas helt, delvis eller inte alls. Computer Sweden (2014) anser att krav kan 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 kund. Ett krav förklarar vad ett system ska utföra, tjänsterna som erbjuds samt begränsningarna (Sommerville 2010). Han anser dessutom att krav återspeglar kundernas behov på ett system.

Krav kategoriseras vanligtvis i funktionella och icke-funktionella krav.

Funktionella krav handlar om något som systemet kan utföra (Dennis, Wixom & Roth 2010).

Pohl och Rupp (2011) anser att funktionella krav handlar om det som behövs för att systemet ska fungera på ett speciellt sätt, alltså vad systemet skall kunna göra. De funktionella kraven ska beskriva vad systemet eller funktionerna ska göra, dessa beskrivs oftast genom in- och utdata, alltså förklaring om vad som tas in samt vad som förväntas komma ut (Eriksson 2008).

De funktionella kraven benämns även som beteendemässiga krav enligt Eriksson (2008) eftersom de skall beskriva vad systemet ska göra. De funktionella kraven ska beskriva tjänster som systemet ska erbjuda, hur systemet ska reagera på indata samt hur systemet ska bete sig under vissa situationer (Sommerville 2010). I vissa situationer så kan funktionella krav även beskriva vad systemet inte ska göra.

Icke-funktionella krav däremot handlar om hur systemet ska fungera, vilka valmöjligheter det finns till att använda systemet (Dennis, Wixom & Roth 2010). De icke-funktionella beskriver bland annat användbarheten och prestandan för systemet kommer därmed att påverka hur nöja användarna blir med systemet (Eriksson 2008). Icke-funktionella kraven handlar om att precisera vad systemet måste vara för att användaren skall vilja använda det. Vidare förtydligar Chung och Nixon (2000) att icke-funktionella krav kan vara hur

användargränssnittet ska se ut eller hur många användare som ska använda systemet.

Sommerville (2009) belyser att icke-funktionella krav gäller ofta för systemet som helhet, i stället för enskilda systemfunktioner eller tjänster.

3.4 Kravhanteringsprocessen

Nuseibeh och Easterbrook (2000) anser att kravhantering är en samlings ord som används för

18 att beskriva insamling, modellering, analysering, kommunicering, validering samt

underhållning av krav inom ett systemutvecklingsprojekt. Kravhanteringen inom ett

systemutvecklingsprojekt handlar om att ta fram den nytta som ett nytt system skall infria hos en organisation samt vilka funktioner och begränsningar som detta system skall inneha (Nuseibeh & Easterbrook, 2000; De Lucia & Qusef, 2010).

Sommerville (2011) anser att innan en utveckling ska påbörjas så måste man först förstå vad systemet ska göra samt hur användningen av systemet kommer att stödja målen för de

personer eller företag som ska betala för systemet. Sommerville (2011) belyser att det handlar om att förstå systemets operativa begränsningar, de specifika funktionaliteter som

intressenterna behöver samt de väsentliga systemegenskaperna såsom prestanda, säkerhet och pålitlighet. Kravhantering är namnet på en strukturerad uppsättning aktiviteter som bidrar till att utveckla denna förståelse och att dokumentera systemets specifikation för intressenter och utvecklare som är involverade i systemutvecklingen (Sommerville 2011).

Sommerville (2009) beskriver kravhantering som en process därigenom man ska upptäcka, dokumentera och hantera kraven för ett system. Målet med kravhantering är att skapa en uppsättning systemkrav som, så långt det är möjligt, är fullständigt, konsekvent, relevant och återspeglar vad kunden faktiskt vill ha.

Kravhanteringsprocessen varierar beroende på vad som ska utvecklas, storleken på det som ska utvecklas samt kulturen hos de berörda företagen; alltså hur de tidigare gått tillväga för kravhantering. Vid framställning av en kravspecifikation så bildar ett antal olika aktiviteter en kravhanteringsprocess, genom denna process framställs en kravspecifikation (Wiktorin 2003).

I kravhanteringsprocesser ingår flera olika aktiviteter och tillvägagångssätt beroende på författaren, oavsett vilken process som används för kravhantering, så är vissa aktiviteter grundläggande för alla kravhanteringsprocesser, nämligen: Insamling, analysera, validera samt dokumentera.

De ovan nämnda aktiviteterna tillsammans skapar en kravhanteringsprocess för ett projekt Wiktorin (2003) belyser att de tidigare nämnda aktiviteterna ska finnas med i en

kravhanteringsprocess men process inte behöver ske i den ordningen de är uppstaplade ovan.

Men vissa aktiviteter måste dock ske i ordning, t.ex. att dokumentering av krav inte ske förens man samlat in de. Aktiviteterna utförs iterativt, vilket innebär att man utför stegen upprepade gånger i etapper (Eriksson 2008). 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. Det iterativa arbetet medför även ett stöd för att driva andra aktiviteter parallellt, exempelvis testning. (Rouse 2011). Liu och Yuliani (2016) anser att kravhantering lägger grunden för hur framgångsrikt ett projekt blir, otydliga krav eller missförstånd av kraven leder till att kravprocessen måste omarbetas vilket resulterar i att både tid och budget påverkas. Kunden tillsammans med systemleverantören måste ägna tillräckligt med tid vid kravhanteringen.

Alexander och Stevens (2003) belyser att utvecklingsprojekt oftast strävar efter att ha ett minimum av ändringar under ett projekts gång. Dock så anser de att misstag som görs tidigt i ett projekt är billigare att ändra än när de är långt gången i utvecklingsprocessen. Ändringar uppkommer dessvärre alltid i ett projekt och måste därmed hanteras på ett strukturellt sätt (Alexander & Stevens 2003). Sommerville och Sawyer (1997) anser att det finns olika infallsvinklar som påverkar kravändring i ett projekt t.ex. misstag under insamling av krav, design samt implementation det kan även innehålla infallsvinklar såsom ändringar i strategier, ekonomiska situationer osv. Ahlin et al (2011) belyser att alla projekt är i förväg fastställda för

19 förändringar, samt att ändringarna kan påverka projektets resurser som är betydande för

projektet såsom tidplan, projektbudget, personal eller projektresultat.

”Kravhanteringsarbetet är i många fall mycket omfattande, och att göra allt i en sekvens är som att försöka äta en hel elefant på endaste måltid. Det är istället mycket bättre att stycka upp elefanten i många små delar och att äta en bit i taget.” (Eriksson, 2008, s. 31).

Eriksson (2008) presenterar en sex stegs process som heter stjärnan som kan användas vid kravhantering. Stjärnan består av att samla in, strukturera, prioritera, dokumentera, kvalitetssäkra samt förvalta.

Denna studie fokuserar på de inledande faserna i kravhanteringsprocesserna därför kommer jag inte ta upp förvalta eftersom det ligger utanför ramen för min studie. Strukturering kommer inte heller att tas upp eftersom det enligt Eriksson (2008) är en kontinuerlig process som pågår genom alla aktiviteter under kravhanteringsprocessen.

3.4.1 Samla in

Insamling av krav aktiviteten handlar om att fånga de övergripande kraven som utgör underlaget för allt kommande arbete (Eriksson 2008). Detta sker från intressenter som är representativa från olika delar av verksamheten. När det kommer till kravinsamling, så finns det oräkneliga metoder att använda sig av. Olika forskare har kommit fram till olika metoder att använda sig vid kravinsamling. Eriksson (2008) och Sommerville (2010) nämner självklara tekniker som kan användas vid kravinsamling, såsom intervjuer, enkäter, observationer och workshops. Valet av metod måste dock göras utifrån intressenterna som är involverade samt vilka behov och mål de har. Beynon-Davies (2013) anser att krav ska samlas in från olika intressentgrupper, de som beslutar om resurser till projektet, de som är slutanvändare av systemet samt externa intressenter t.ex. kunder är tre viktiga intressentgrupper. Vidare förklarar Beynon-Davies (2013) att kombinationen av flera tekniker vid kravinsamling är en bra fördel till att få en heltäckande bild av situationen. Det finns enligt Eriksson (2008) inte en metod som alltid går att använda, olika metoder används beroende på situationen samt att alla metoder har olika användningsområden och svårighetsgrad. Det finns ingen metod som är bäst lämpad i alla situationer, svagheter i en metod kan vägas upp genom att använda en annan metod som komplement. Olika metoder kan dessutom användas för att komplettera varandra (Yousuf & Asger 2015).

▪ Intervjuer är en väldigt traditionell och effektiv teknik för att använda sig av vid insamling av krav, detta görs genom att kravansvarige från leverantörens sida intervjuar kunden för att fånga vad målet med produkten/tjänsten är samt reda ut eventuella problem (Escalona & Koch 2004). Enligt Roubah och Al-Rafee (2008) studie där 98% använde sig utav intervjuer, så är intervjuer den vanligaste sättet att använda sig av vid insamling av krav. Intervjuer är ett arbetssätt som används för att kunna identifiera åsikter och fakta från potentiella intressenter till

systemutvecklingsprocessen (Eriksson 2008). De Lucia och Qusef (2010) anser att intervjuer är bra för att få en övergripande förståelse över användarens påverkan på systemet dock är dem mindre bra för att lyckas identifiera specifika krav.

▪ Enkät enligt Eriksson (2008) är det arbetssättet som kan användas för att hitta krav som användaren inte är medveten om att den har samt även för att få en överblick och utvärdering av det nuvarande systemet. Han menar även att detta är ett bra sätt att få