Kraveliciteringstekniker och tillhörande problem: En kvalitativ studie där kraveliciteringstekniker och tillhörande problem identifieras hos tre IT-företag

EXAMENSARBETE

Kraveliciteringstekniker och tillhörande

problem

En kvalitativ studie där kraveliciteringstekniker och tillhörande problem

identifieras hos tre IT-företag

Tobias Axelsson

2016

Teknologie kandidatexamen Industriell ekonomi

Luleå tekniska universitet

Kraveliciteringstekniker och tillhörande problem

En kvalitativ studie där kraveliciteringstekniker och tillhörande problem identifieras hos tre IT-företag

Requirements elicitation techniques and associated problems

A qualitative study in which requirements elicitation techniques and associated problems are identified in three IT companies

Kandidatuppsats utfört inom ämnesområdet kvalitetsteknik vid Luleå tekniska universitet.

av

Tobias Axelsson Luleå 2015-11-16 Handledare:

Sammanfattning

Kravelicitering handlar om processen att förstå, hämta och bestämma en programvaras funktionalitet och begränsningar i en programvaruutvecklingsprocess. Kraveliciteringsprocessen är viktig för att kunder skall veta vad som kan förväntas av programvaran samt att överenskomna krav blir rätt från början så att dyra omarbetningar kan undvikas. För att uppnå en väl fungerande kraveliciteringsprocess används ett flertal olika kraveliciteringstekniker av leverantörer.

I studien studeras kraveliciteringstekniker hos tre olika programvaruutvecklingsföretag. Studien utförs med semi-strukturerade intervjuer där två saker skall identifieras:

 Vad använder leverantören för kraveliciteringsteknik?  Vilka problem uppstår med vald teknik?

Resultatet tyder på att två av leverantörerna använder sig av Intervju, en klassisk kraveliciteringsteknik, där sex olika problem uttrycks. De två mest sannolika problemen för Intervju som kraveliciteringsteknik är att användare inte vet vad de vill ha samt bristande data/IT-kunskaper hos användare.

För den tredje leverantören identifierades en kombination av två samarbetande tekniker: JAD och Evolutionary prototype. Kombinationen av dessa två tekniker gav upphov till endast ett problem: fel person på plats.

Abstract

Requirements elicitation is the process of understanding, retrieving and deciding the requirements and limitations of a software system in a software development process. The requirements elicitation process is important so that customers know what to expect from the software, and to avoid misunderstandings and expensive maintenance costs. Different requirements elicitation techniques are used to achieve better results in this process.

Requirements elicitation techniques are studied in three different software development companies. The study is conducted using semi-structured interviews in which two things are identified:

 What requirements elicitation technique is the company using?  What associated problems exist using this technique?

The result indicates that two of the companies use Interview, a classic requirements elicitation technique. With this technique there are six problems mentioned out of which two have a higher probability to occur: Users do not know what they want, and a lack of knowledge with computers and IT from users. A combination of two collaborating techniques is found in the third company: JAD and Evolutionary prototype. The combination of these two techniques resulted in one problem alone: The wrong person attends the meeting.

Innehållsförteckning

2.1 Programvaruutvecklingsprocess enligt vattenfallsmodellen... 6

2.2 Gap modellen ... 6

2.3 Kraveliciteringstekniker ... 7

2.4 Problem inom en kraveliciteringsprocess ... 9

3. Metod ... 10

3.1 Inledande möten och studieriktning ...10

3.2 Inledande litteraturstudie ...10

3.3 Slutgiltig studieriktning och löpande informationssökning ...11

3.4 Studiens upplägg ...12

3.5 Datainsamlingsmetoder ...13

3.6 Beskrivning av analysprocessen ...15

4. Datainsamling ... 16

5. Analys ... 17

5.1 Analys av empiri med teoretisk förankring ...17

6. Resultat ... 18

6.1 Vattenfallsmodellen ...18

6.2 Kraveliciteringstekniker och tillhörande problem ...19

7. Slutsatser ... 21

8. Diskussion och förslag till fortsatta studier ... 22

1

1. Introduktion

1.1 Bakgrund 1.1.1 Programvara

I dagligt tal benämns programvara eller mjukvara som datorprogram. Till skillnad från en fysisk produkt är programvara en uppsättning av villkor och funktioner med mera som utvecklas i ett programmeringsspråk. Detta innebär att själva produkten är programvarans utformning som sedan interagerar med diverse operativsystem i datorer för att utföra en viss funktion. Datorprogram förekommer inte endast i vad vi kanske uppfattar som ”vanliga” datorer, utan även som applikationer i smartphones med mera.

Med ett datorprogram är det exempelvis möjligt att upprätta tredimensionella visualiseringar av ett hus i så kallade Computer Aided Design program, istället för att behöva skissa för hand eller göra modeller av fysiska ting. Användning av datorprogram som verktyg ses kanske idag som en självklarhet för många företag. En utredning av Statistiska centralbyrån [SCB] (2014) visar att totala utgifter från inköp av programvara och andra IT-relaterade tjänster för företag uppgick till nära 54 miljarder kronor år 2014 i Sverige.

1.1.2 Programvaruutvecklingsprocessen

Olika ramverk för att strukturera en programvaruutvecklingsprocess har utvecklats genom åren, dessa kallas metodologier. En och samma metodologi passar nödvändigtvis inte bäst på varje unik programvaruutvecklingsprocess. Vattenfallsmodellen är en av dessa metodologier som togs fram av Winston W. Royce (CMS, 2014). Vattenfallsmodellen används för att systematiskt genomföra stora programvaruutvecklingsprojekt. Enligt författarens modell delas en programvaruutvecklingsprocess upp i ett antal delprocesser som är seriellt kopplade till varandra (se Figur 2 i avsnitt 6.1 Vattenfallsmodellen). I Royces modell ger varje delprocess i sin tur en output som antingen blir en input till nästa delprocess i serien, eller som återkoppling till en föregående delprocess vid ett icke-tillfredsställande resultat (Royce, 1987). De olika delprocesserna beskrivs i avsnitt 2.1 Programvaruutvecklingsprocess enligt vattenfallsmodellen. De leverantörer som medverkar i denna studie använder sig inte nödvändigtvis av vattenfallsmodellen eller någon liknande metodologi för att genomföra sina programvaruutvecklingsprojekt. Vattenfallsmodellen beskrivs eftersom den är enligt egen informationssökning (se avsnitt 3.3 Slutgiltig studieriktning och löpande informationssökning) ett ”skolboksexempel” på hur en programvaruutvecklingsprocess ser ut.

Utöver olika metodologier anpassas även programvaruutvecklingsprocesser efter standardiserad eller anpassad programvara. Anpassad programvara innebär enligt Kuo (2012) att både kund och leverantör delar ansvar för programmets funktion. Kunden lägger fram egna krav och önskemål till hur programmet skall utformas för att uppfylla egna behov (Kuo, 2012). Det är då extra viktigt att etablera en god kommunikation mellan kunden och leverantören under

2 programvaruutvecklingsprocessen för att skapa en gemensam uppfattning om hur programmet skall utformas.

1.1.3 Kravelicitering

I första steget för en programvaruutvecklingsprocess (se kravanalys i avsnitt 2.1 Programvaruutvecklingsprocess enligt vattenfallsmodellen) bestäms vad programvaran skall kunna göra. Saiedian & Dale (1999) definierar kravanalys som en fas vars aktiviteter syftar till att:

 Identifiera kundbehov.

 Analysera behov och möjligen föreslå alternativa eller bättre lösningar på de problem som kunden har uttryckt.



 Dokumentation av behov till en kravspecifikation. 

 Jämförelse av kravspecifikation mot det faktiska behov som kunden har uttryckt.

Som resultat från dessa aktiviteter fås en kravspecifikation vars syfte är att skapa en gemensam uppfattning om vad programvaran skall kunna göra (kravspecifikation, 2015). Alshazly, Elfatatry & Abougabal (2014) påstår att kravanalys är den viktigaste fasen i en programvaruutvecklingsprocess. Saeidian & Dale (1999) menar att utan en bra kravspecifikation finns inga goda förutsättningar att bygga en komplett och korrekt programvara. Artikeln betonar även att det är viktigt med en bra kravspecifikation för att utvecklare skall veta exakt vad de skall konstruera, och för att kunder skall veta vad de kan förvänta sig. En bra kravspecifikation är enligt Davis et al. (1993) stöd till skapandet av en kostnadseffektiv och lyckad programvara som bidrar till att lösa riktiga användarproblem.

För att komma fram till vad kravspecifikationen skall innehålla, etableras en kontakt mellan leverantör och kund. Kontakten omfattar enligt Saiedian & Dale (1999) de aktiviteter som innebär att förstå, hämta, och bestämma funktionalitet och begränsningar på en programvara, något som kallas kravelicitering. Författarna hävdar att en bra kraveliciteringsprocess bidrar till att skapa en god förståelse för användaren om egna behov och begränsningar samt en tydlig specifikation av den programvara som skall utvecklas av leverantören. Det är alltså kraveliciteringsprocessen som lägger grunden för vad en programvara skall kunna göra, hur utvecklare skall arbeta och vad kunder kan förvänta sig av programvaran.

3 1.2 Problembeskrivning

1.2.1 Kvalitetsutveckling och omarbetningskostnader

Bergman & Klefsjö (2012) skriver om offensiv kvalitetsutveckling; att tidigt och aktivt förebygga och förändra icke-önskvärda resultat i en produktionsprocess, istället för att kontrollera och reparera en produkt som gått genom en hel produktionsprocess, med en strävan att ständigt förbättra denna process. Kravanalysfasen i vattenfallsmodellen är ett viktigt moment att beakta om

offensiv kvalitetsutveckling kan appliceras på en

programvaruuutvecklingsprocess (se avsnitt 2.1

Programvaruutvecklingsprocess enligt vattenfallsmodellen och Figur 2 i avsnitt 6.1 Vattenfallsmodellen). Windows 7 är ett operativsystem som släpptes år 2009 som har cirka 40 miljoner rader programkod (Lines of code, 2015). Med en så pass komplicerad produkt uppenbaras svårigheter att utföra ändringar i senare skeden i programvaruutvecklingsprocessen.

Kostnaden för omarbetningar ökar i takt med den fas en produkt befinner sig i produktionen. Dessutom får ändringar en allt större inverkan på slutprodukten om de görs tidigt under produktionen (Reichelstein & Rohlfing-Bastian, 2015). I programvaruutvecklingsbranschen där produkten i sig är väldigt komplicerad kan detta ge upphov till ännu större omarbetningskostnader. Banker, Datar, Kemerer & Zweig (1993) undersökte hur komplexiteten påverkar kostnader i underhållsfasen. Deras slutsats visar att beroende på komplexiteten hos programvaran, kan en hög komplexitet orsaka så mycket som 25 % av den totala underhållskostnaden. En studie av Javed, Maqsood & Durrani (2004) där programvarufel relaterat till fel i kravspecifikationens utformande undersöktes. Författarnas slutsatser tyder på att ändringar gjorda i designfasen eller senare faser i en programvaruutvecklingsprocess har större sannolikhet att ge upphov till omfattande defekter i programvaran. Med anpassad programvara innebär omarbetningar dessutom att ändringar och uppdateringar kan behöva anpassas efter varje unik kund.

Hur är det då med tidsåtgång? En studie av Javed, Maqsood & Durrani (2004) visar att i genomsnitt 23 % av tiden förvaltas till kravanalysfasen. Trots den tid som läggs ned är missar i kravanalysfasen, och därmed en felaktig kravspecifikation, något som kan ge upphov till allvarliga programvarufel och därmed dyra omarbetningar (Javed, Maqsood & Durrani, 2004).

1.2.2 Kraveliciteringsprocessen

Bergman & Klefsjö (2012) skriver om missförstånd mellan leverantör och kund och hur detta kan leda till kundmissnöjdhet. Dessa missförstånd finns på flera plan hos både leverantör och kund och benämns som gap-modellen (Bergman & Klefsjö, 2012).

4 En effektiv kraveliciteringsprocess kan minska det första gapet (se avsnitt 2.2 Gap modellen). En minskning som enligt Bergman & Klefsjö (2012) är ett kritiskt steg om leverantören skall utforma ett erbjudande som uppfyller, och helst överträffar kundens förväntningar, vilket liknar den definition av kvalitet som ges av Bergman & Klefsjö (2012). Det kan då ses som en stor fördel att jobba med anpassad programvaruutveckling där kunden själv får precisiera sina behov, men för att minska det första gapet krävs det enligt Bergman & Klefsjö (2012) en förståelse från leverantörens sida för kundens behov och förväntningar. Med den expertis leverantören besitter kan en bra kraveliciteringsprocess även leda till att leverantören överträffar kundens behov och förväntningar. Detta i form av exempelvis effektiva lösningar på outtalade organisationsspecifika problem. I kraveliciteringsprocessen är det människor som är involverade, ibland flera från både kund och leverantör, då spelar sociala faktorer en större roll än rent tekniska (Tiwari et al., 2012). Med Tiwaris resonemang blir det svårt att standardisera kraveliciteringsprocessen för samtliga programvaruutvecklingsprojekt. Till hjälp finns det så kallade kraveliciteringstekniker vars syfte är att minska osäkerheten i kraveliciteringsprocessen och minimera sannolikheten för kvalitetsbrister i kravspecifikationen, och därmed produkten i slutändan (se avsnitt 2.3 Kraveliciteringstekniker). Baserat på egen informationssökning i avsnitt 3.3 Slutgiltig studieriktning och löpande informationssökning är en kraveliciteringsprocess något som involverar både kund och leverantör, en kraveliciteringsteknik däremot är något som används endast av leverantören för att förbättra denna process.

Kraveliciteringsteknikerna som beskrivs i avsnitt 2.3 Kraveliciteringstekniker har olika tillvägagångssätt och användningsområden. Det finns däremot få eller inga undersökningar gjorda för att utvärdera kvaliteten på kraveliciteringstekniker genom att koppla problem (Se avsnitt 2.4 Problem inom en kraveliciteringsprocess) som uppstår i en kraveliciteringsprocess till olika kraveliciteringstekniker som används i praktiken.

1.3 Syfte

Det ursprungliga syftet med undersökningen var att utvärdera kvaliteten på kravspecifikationer som svenska programvaruutvecklingsföretag använder sig av. En utvärderingsmall var avsedd att användas som beskrivs i avsnitt 3.2 Inledande litteraturstudie för att analysera kravspecifikationer. Vidare skulle en leverantör och en kund som tillsammans var involverade i en affärsuppgörelse kontaktas för frågor om den kravspecifikation som togs fram. Varför detta ströks beskrivs i avsnitt 3.3 Slutgiltig studieriktning och löpande informationssökning.

Syftet med undersökningen är att identifiera olika kraveliciteringstekniker som svenska programvaruutvecklingsföretag använder sig av och sammanställa de problem som uppstår i kraveliciteringsprocessen för respektive leverantör med valda kraveliciteringstekniker.

5 1.4 Avgränsningar

För en neutral ståndpunkt i studien bör information samlas in från både kund och leverantör som är inblandade i samma kraveliciteringsprocess. Identifiering av kraveliciteringsteknik må vara effektivt att göra via en leverantör eftersom tekniken endast används av leverantören. För att göra en komplett sammanställning av de problem som uppstår i en kraveliciteringsprocess bör ett neutral ställningstagande tas. Baserat på den information som samlades in från ett anonymt programvaruutvecklingsföretag i avsnitt 3.3 Slutgiltig studieriktning och löpande informationssökning gjordes en avgränsning att endast inkludera leverantörer i undersökningen, och därmed utgå från ett leverantörsperspektiv. 1.5 Rapportens struktur

I början av rapporten tas det först upp bakgrund, problembeskrivning och syfte för studien. I nästa kapitel beskrivs teorival för studien. Vidare förklaras hur det praktiska arbetet har gått till och hur det empiriska materialet samlades in följt av en sammanställning av den empiriska undersökningen. Slutligen beskrivs en analys av det empiriska materialet i förhållande till relevant teori följt av diskussion, samt slutsats och rekommendationer.

6

2. Teoretisk referensram

2.1 Programvaruutvecklingsprocess enligt vattenfallsmodellen

Som utgångspunkt för hur en programvaruutvecklingsprocess typiskt ser ut används en egen version av vattenfallsmodellen (se Figur 2 i avsnitt 6.1 Vattenfallsmodellen för illustration av vattenfallsmodellen). De olika delprocesserna eller stegen från Figur 2 beskrivs i detalj nedan (IEEE, 1990): Steg 1. Kravanalys: Systemets funktioner och begränsningar bestäms i detta steg. Krav insamlas från kunden, som sedan analyseras för prioriteringar och genomförbarhet. Slutligen skrivs en kravspecifikation, en dokumentation av de funktioner och begränsningar som programvaran skall ha.

Steg 2. Design: I detta steg skapas, utifrån kravspecifikationen, en design av hur programmet skall se ut och fungera. Designdokumentationen definierar bland annat systemarkitekturen för hur programmet skall vara uppbyggt.

Steg 3. Implementation: Utifrån designdokumentationen delas arbetet upp och programmeringen börjar. Programmet är uppdelat som designdokumentationen specificerar det. Varje del testas var för sig i något som kallas enhetstestning. Slutligen ges det fullständiga programmet som output till nästa steg.

Steg 4. Testning: I testfasen testas det fullständiga programmets funktionalitet och begränsningar. Resultatet jämförs med det som står i kravspecifikationen. Steg 5. Användning: Programvaran levereras till kunden för installation, eventuella konfigurationer görs från kundens sida i avtalet. Potentiella avvikelser från villkoren och begränsningar som skrivits ned i kravspecifikationen rapporteras till leverantören.

Steg 6. Underhåll: Utifrån de avvikelser som har uppstått, underhålls systemet för att möta de krav och begränsningar enligt den överenskommelse som återfinnes i kravspecifikationen.

2.2 Gap modellen

Från Bergman & Klefsjö (2012):

Gap 1: Mellan kundens förväntningar och leverantörens uppfattning om dessa. Gap 2: Mellan leverantörens uppfattning och erbjudandets utformning.



Gap 3: Mellan det utformade och det utförda erbjudandet. 

Gap 4: Mellan det utförda erbjudandet och det som förespeglats kunden. 

7 2.3 Kraveliciteringstekniker

Tiwari, Rathore & Gupta (2012) kategoriserar ett antal kraveliciteringstekniker (A-D i kommande avsnitt) som används av programvaruutvecklingsföretag med tillhörande beskrivning.

2.3.1 A: Traditionella tekniker

Intervju (Interview): Ett möte vars syfte är att identifiera fakta och åsikter hos användare och andra intressenter. Två typer:

 Sluten: Antalet frågor och vad de omfattar är förbestämt.  Öppen: Öppen diskussion och frågeställning.

Frågeformulär (Questionnaire): En kostnadseffektiv och tidsbesparande teknik för identifiera kundbehov i större utsträckning. Intressenter svarar på ett förbestämt antal frågor som syftar till att identifiera intressenternas behov. Detta analyseras sedan av utvecklaren.

Undersökning (Survey): En teknik för att samla ett generellt omdöme från kunder och användare. Används oftast för standardiserad programvara.

2.3.2 B: Samarbetande tekniker

Fokusgrupp (Focus Group): En teknik där 4-9 användare med olikartad expertis samlas för att öppet diskutera programmets funktionalitet.

Brainstorming: En öppen miljö där användare först uttrycker sina behov och

förväntningar på systemet. Dessa diskuteras sedan i en grupp där olika arbetsroller från både kund och leverantör närvarar.

JAD (joint application development): En teknik där intressenter, användare, områdesexperter och mjukvaruutvecklare reder ut systemets funktionalitet på detaljnivå. Denna metod tar snarare rot i kundens organisatoriska problem än det tekniska.

Prototyp (Prototyping): Ett system byggs upp som testmodell för kunden som demonstration av systemet. Detta görs i två ändamål:

 Throw away prototypes om leverantören enbart vill påvisa svårt genomförbara krav i en kravspecifikation, något som inte används i ett senare skede.



 Evolutionary prototypes demonstrera ett fungerande system för att validera systemets funktionalitet. Dessa prototyper används oftast sedan i slutprodukten.

Work shop: Ett flertal möten hålls mellan leverantör och intressenter för att förstå

intressenternas behov. Effektivt i stora och komplicerade projekt.

Modeller (Models): En teknik där UML- och DFD-diagram demonstrerar systemets funktioner och hur allt hänger ihop rent logiskt. Kan vara effektivt för att förstå kundbehov och för att lösa konflikter mellan intressenter.

8 2.3.3 C: Kognitiva tekniker

Dokumentsanalys (Document Analysis): En teknik där leverantören granskar dokument från kunden om problemområdet. Tekniken ger leverantören en bra förståelse för kundens problem.

Card sorting: En teknik med ett antal övningar som intressenter från

kundföretaget får genomföra för att leverantören skall veta hur samspelet fungerar inom kundens organisation.

Protokollsanalys (Protocol Analysis): Ett möte hålls mellan leverantör och intressenter för att diskutera systemets krav. Metoden ger ett komplett stöd för att uppfylla kundens behov med hjälp av logik.

Laddering: En strukturerad intervju där ett antal förbestämda frågor ställs till

intressenter. Hur bra denna teknik lyckas beror på intressenternas kunskaper inom mjukvarudesign.

Repository grid: En teknik där en matris fylls i av kundönskemål och rangordnas

av intressenter.

2.3.4 D: Observerande tekniker

Observation: Användarens arbete observeras och noteras av en person från

leverantörssidan. Tekniken ger en god bild av vad användaren faktiskt går igenom på sin arbetsplats och därmed en bra uppfattning om vad användaren har för behov.

Etnografi/Social analys (Ethnography/Social analysis): En teknik där leverantören interagerar med intressenter och användare med skilda bakgrunder för att analysera den hierarkiska ordning som råder på kundens företag och förstå arbets- och kulturell omgivning.

9 2.4 Problem inom en kraveliciteringsprocess

Enligt Christel & Kang (1992) medför kraveliciteringsprocesser ett visst antal problem. Dessa delas in i tre kategorier.

2.4.1 Problems of scope

Problem där kraven antingen redogör för mycket eller för lite information om systemets uppbyggnad. Det kan vara att:

 Systemets gränser är dåligt definierade.  Överflödig information om design är given. 2.4.2 Problems of understanding

Förståelsesvårigheter både internt hos kund, leverantör och mellan båda parter:  Användare har ofullständig förståelse för egna behov.



 Användare har otillräcklig kunskap om gränser för datorers prestationsförmåga.



 Analytiker har dålig uppfattning om problemområdet hos kunden.  Analytiker och användare ”talar olika språk”.



 Tendens att utelämna uppenbar information.  Användare har inte samma ändamål.



 Krav är otydligt definierade och inte testbara. 2.4.3 Problems of volatility

10

3. Metod

3.1 Inledande möten och studieriktning

Initialt fördes kontakt med en kontaktperson på ett mindre programvaruutvecklingsföretag i Luleå för att eventuellt genomföra ett arbete eller en studie där. Detta gjordes inte, dels på grund brist på egen kunskap om den bransch som företaget befinner sig i, och att en tidsram på tio veckor ansågs vara otillräckligt med tid. Kontaktpersonen fungerade istället som ett ”bollplank” för att svara på mina frågor. Två semi-strukturerade intervjuer låg till grund för att diskutera programvaruutvecklingsbranschen och mer specifikt; vad kontaktpersonens företag utvecklar och vilka svårigheter de stöter på. Vidare utvecklades en problematisering fram från kontaktpersonens perspektiv med tvister om kravspecifikationer och kundkrav när de säljer kundanpassade mjukvarusystem till företagskunder.

Efter kontakt med programvaruutvecklingsföretaget har olika ämnesområden inom IT, undersökningsmetoder och rapportskrivning diskuterats med min handledare på Luleå tekniska universitet; Rickard Garvare. Intervjuerna med min kontaktperson och min handledare låg som grund för studiens ursprungliga riktning; att undersöka mer om kravspecifikationer för programvaruutvecklingsföretag.

3.2 Inledande litteraturstudie

Initialt fördes en litteraturstudie för att få en bättre förståelse dels om kravspecifikationer i programvaruutvecklingsbranchen, och allmänt om programvaruutvecklingsprocessen och kundanpassad programvara. Idén var att se om den problematisering som togs upp i inledande möten var något som kunde återfinnas i vetenskapliga artiklar och därmed i ett bredare perspektiv. Följande databaser har använts för att finna relevanta vetenskapliga artiklar:

 IEEE Xplore 

 Scopus 

 Business Source Premier 

 Google

 Google Scholar

För att styra informationssökningen mot att hitta relevanta vetenskapliga artiklar om kravspecifikationer, programvaruutveckling och kundanpassad programvara valdes ett antal nyckelord:

 Software development  Customer Software   Custom software   Requirements engineering

 Software requirements specification 

 Requirements specification quality

Inom området hittades ett antal artiklar som var tänkt att användas som teoretiskt förankring för studiens ursprungliga syfte; att utvärdera kvaliteten på

11 kravspecifikationer hos olika programvaruutvecklingsföretag. Några artiklar som uteblev att användas i denna studie:

 Kekre, Krishnan & Srinivasan (1995) undersökte vilka faktorer i programvara som påverkade kundnöjdhet.



 Belfo (2012) analyserade tre problemområden som hör ihop med kravspecifikationer; människor, organisatoriska och tekniska problem. 

 Pearl (2004) betonar vikten av ett bra förhållande mellan kund och leverantör i mjukvarubranschen och hur detta uppnås.

Den utvärderingsmetod som ges av Davis et al. (1993) för att utvärdera kvaliteten på kravspecifikationer var avsedd att användas. Metoden innebär att 23 olika faktorer i kravspecifikationens olika krav studeras.

3.3 Slutgiltig studieriktning och löpande informationssökning

Det uppenbarades en del svårigheter med att utvärdera kvaliteten på kravspecifikationer enligt den metod som ges av Davis et al. (1993). Egen slutsats drogs att erfarenhet och god kunskap om programvaruutvecklingsbranschen och kravspecifikationer var nödvändigt för att genomföra kvalitetsutvärderingar på kravspecifikationer. Dessutom erhölls ingen tillåtelse av programvaruutvecklingsföretaget i avsnitt 3.1 Inledande möten att intervjua leverantörens kunder, något som ansågs nödvändigt för att utvärdera kvaliteten på kravspecifikationer. Leverantören deltog förvisso inte i studien men samma förfrågan förväntades bli nekad av andra leverantörer också. Det gjordes istället ett val att från ett leverantörsperspektiv undersöka kraveliciteringsprocesser, och närmare bestämt tekniker som används för att förbättra kraveliciteringsprocesser samt vilka problem uppstår. Den inledande litteraturstudien inspirerade den slutgiltiga studieriktningen.

Följande databaser användes löpande i arbetets gång:  IEEE Xplore

 Scopus  Google

 Google Scholar

För att finna relevanta vetenskapliga artiklar om kravelicitering, kraveliciteringstekniker, kravanalys och problem med kraveliciteringsprocesser användes följande nyckelord:

 Requirements elicitation

 Requirements elicitation issues  Requirements elicitation problems 

 Requirements elicitation techniques  Requirements engineering

 Requirements gathering 

För att finna mer information om hur en programvaruutvecklingsprocess går till, vilka problem som kan uppstå och om programvarukvalitet användes följande

12 nyckelord:

 Software

 Software development life cycle  SDLC  Software development  Waterfall model  Software cost   Software quality  Quality management 

Grundat av egen sökning på programvaruutveckling och vattenfallsmodellen förefaller antalet delprocesser som används i modellen och vad de omfattar variera (se avsnitt 1.1.2 Programvaruutvecklingsprocessen och avsnitt 2.1 Programvaruutvecklingsprocess enligt vattenfallsmodellen). Därför presenteras ett eget exempel av vattenfallsmodellen i avsnitt 6.1 Vattenfallsmodellen för att illustrera hur modellen ser ut och beskriva sex moment som typiskt ingår i vattenfallsmodellen.

För att finna vetenskapliga artiklar om datainsamling och undersökningsmetoder användes följande nyckelord:

 Research methodology  Research methods  Qualitative study  Qualitative data

 Research data collection  Semi-structured interview  Interview  Primary data  Data collection  Non-response  Bias

 Non-response qualitative study

Som teoretisk förankring används en artikel av Tiwari, Rathore & Gupta (2012) där författarna presenterar olika kraveliciteringstekniker, hur de bör användas och hur en passande teknik väljs. En artikel av Christel & Kang (1992) används också som stöd där de listar och kategoriserar en samling vanliga problem inom kravelicitering (se avsnitt 2. Teoretisk referensram).

3.4 Studiens upplägg

Studien har genomförts genom att först söka fram relevanta programvaruutvecklingsföretag för att ingå i urvalsprocessen. Vidare kontaktades leverantörerna för att se om en eventuell medverkan var möjlig. Ett antal krav sattes för att medverka i studien. Medverkande leverantörer kontaktades över telefon och primärdata insamlades i form av primärdata genom semi-strukturerade intervjuer (se avsnitt 3.5.3 Intervjuer). Datamaterialet

13 sammanställdes sedan och jämfördes mot teori från avsnitt 2. Teoretisk referensram.

3.5 Datainsamlingsmetoder 3.5.1 Datakällor

En studie kan klassas antingen som kvalitativ eller kvantitativ. I en kvalitativ studie ger respondenter data i form av tolkningar och uppfattningar. Med en kvantitativ studie ges information istället som siffror och mängder (Swift, 2006). Intervjuer ligger till grund för att bilda en uppfattning om vilken kraveliciteringsteknik en medverkande leverantör i studien använder sig av och upplevda problem i kraveliciteringsprocessen. Informationen fås i form av tolkningar och uppfattningar på grund av frågornas innehåll i intervjuerna (se Bilagor), vilket innebär att studien är en kvalitativ sådan med kvalitativ data. Data finns i två typer: primär- och sekundärdata. Primärdata är information som observeras eller upplevs nära den källa som söks. Information som bygger på tolkningar av primärdata kallas sekundärdata. Primärdata har dessutom en tendens att vara mer pålitlig än sekundärdata (Walliman, 2011). Den nischade riktningen för denna studie ger upphov till svårigheter att finna sekundärdata kring kraveliciteringstekniker och upplevda problem. För studien valdes det därför att samla in och använda primärdata.

3.5.2 Urvalsprocess

Enligt avgränsningar av syftet (se avsnitt 1.4 Avgränsningar) inkluderas endast programvaruutvecklingsföretag, det vill säga leverantörer i urvalet.

Följande krav fastställdes för att ingå i den empiriska undersökningen:  Leverantören utvecklar programvara.

 Leverantören utvecklar i viss mån anpassad programvara till företagskunder.



 Leverantören är en aktör i Sverige. 

 Leverantören har mellan åtta och 500 anställda. 

 Respondenten har någorlunda bra insikt i hur kraveliciteringsprocessen går till på företaget.



Kravet att leverantören skall ha mellan åtta och 500 anställda grundades av egen spekulation att leverantörer med fler antal anställda innebär komplicerade produkter och programvaruutvecklingsprocesser. Dessutom ansågs det bli enklare att hitta en respondent som uppfyller det sista kravet enligt ovan om urvalet begränsas till små och medelstora företag. Leverantörer med färre än åtta anställda uteslöts från urvalet grundat av egen uppfattning att mindre företag innebär färre nischade arbetsroller och arbetsuppgifter per anställd medarbetare. Det är viktigt att respondenten har goda kunskaper om hur kraveliciteringsprocessen går till på dess företag. Enligt egen uppfattning är det inte nödvändigtvis många som jobbar med kraveliciteringprocessen på ett företag. Spekulationer och felaktig information riskerar att ge en icke-informativ eller felaktig beskrivning om hur kraveliciteringsprocessen faktiskt ser ut och vilka problem leverantören upplever.

14 Programvaruutvecklingsföretag söktes upp med hjälp av databasen Google. Målet var att finna programvaruutvecklingsföretag på olika platser i Sverige. Sökningen riktades sedan mot större städer på egen motivering att större städer innebär större marknader och det i sin tur större sannolikhet att finna programvaruutvecklingsföretag som möter de krav som satts för att ingå i studien. Följande sökord användes:

 Programvaruutveckling företag  IT utveckling företag  Mjukvaruutveckling företag   IT-företag Stockholm   IT-företag Göteborg   IT-företag Luleå  IT-företag Malmö

I urvalet ingick 15 leverantörer som arbetar med programvaruutveckling på olika platser i Sverige. Antalet leverantörer som ingick i urvalet var en metodsavgränsning med anledning av den tid som fanns kvar att genomföra den empiriska undersökningen. Leverantörerna kontaktades under två arbetsdagar på dagtid över telefon, om de inte svarade på första försöket gjordes ytterligare ett försök nästa dag. Av dessa femton leverantör valde tre att medverka i undersökningen, övriga är bortfall. Se statistik för urvalsprocessen i Figur 1.

Figur 1. Urvalsprocessen med statistik.

Bortfall leder till en försämrad kvalitet på resultaten då uteblivna observationer leder till en större varians. Det allvarligaste problemet med ett stort bortfall är ett snedvridet resultat. Resultatet underskattar eller överskattar vissa parametrar i studien, detta kallas skevhet eller bias. (Japec et al., 1997). I urvalsprocessen för denna studie erhålls en bortfallsfrekvens på 80 % vilket har en negativ effekt på kvaliteten på denna studie ty det faktum att det finns så pass många olika kraveliciteringstekniker och kombinationer av dessa att studera (se avsnitt 8. Diskussion och förslag till fortsatta studier).

15 3.5.3 Intervjuer

Semi-strukturerade intervjuer är en kombination av strukturerade och ostrukturerade intervjuer. Tekniken bygger på att ha en formell struktur för vilka frågor som skall ställas, men beroende på vilka svar respondenten ger eller vilken fokus som önskas av intervjuaren, kan ytterligare frågor ställas likt en öppen diskussion (Kumar, 2010). Semi-strukturerade intervjuer valdes som teknik för att uppnå en så informationsrik datainsamling som möjligt. Teorikunskaper kring kraveliciteringstekniker må vara bristfällig hos respondenter och för att få en uppfattning om valda kraveliciteringstekniker och upplevda problem i kraveliciteringsprocessen bör frågor formuleras beroende på de svar som ges. Frågorna är uppbyggda så att kraveliciteringsprocessen undersöks som helhet från leverantörens perspektiv. Frågorna undersöker om leverantören använder sig av en eller flera kraveliciteringstekniker, om de anpassar tekniker efter olika kunder och projekt, och slutligen vad de stöter på för problem i kraveliciteringsprocessen. Stängda frågor används för att verifiera fakta och påståenden, öppna frågor används för att ta reda på mer djupgående information i enighet med studiens syfte. För att dokumentera den information som fås från intervjuerna spelades dessa in efter godkännande från respondenter.

Intervjuerna gjordes över telefon från Luleå tekniska universitet den 18-19 maj 2015. Vid uppringning söktes en projektansvarig eller någon som har övergripande insikt i företagets kraveliciteringsprocess. Vid eventuell kontakt ställdes ett antal inledande frågor för att säkerställa att respondenten platsar inom kraven för deltagande. Vid deltagande spelades intervjun in efter respondentens godkännande, detta för att dokumentera informationen för studien. Tre medarbetare på respektive företag har intervjuats. För att underlätta ett medverkande i studien har företagens och individernas identitet anonymiserats. Företagen namnges som leverantör A, B, C. Leverantör A är en IT-konsultfirma som gör cirka 90 % konsultarbete och 10 % utveckling. Leverantör B är en IT-och telekommunikationsleverantör som utvecklar all sorts programvara som ligger inom ramen för deras verksamhet. Leverantör C utvecklar standardiserade fastighetssystem med möjlighet till anpassning.

3.6 Beskrivning av analysprocessen

Primärdata från inspelade telefonsamtal antecknades och sammanställdes i Tabell 1 med relevant information om hur kraveliciteringsprocessen går till på respektive företag. Informationen används för att identifiera vilken eller vilka kraveliciteringstekniker som används och vilka problem som uppstår i kraveliciteringsprocessen, och under vilka kategorier dessa hamnar. Empirin analyseras med hjälp av teori från avsnitt 2. Teoretisk referensram.

16

4. Datainsamling

I Tabell 1 ges en sammanställning av intervjuerna (för fullständiga intervjuer se Bilagor).

Tabell 1. Sammanställning av empirisk undersökning.

Företags-

benämning Typ av leverantör Utvecklar Kraveliciteringsprocess Problem

Leverantör A IT-konsultfirma

Hemsidor, applikationer till smartphones med

mera efter kundönskemål.

Utvecklare möter kontaktperson på kundföretaget på ett flertal möten där kraven diskuteras och reflekteras. Leverantören börjar med övergripande krav och ser om nya krav dyker upp allteftersom. Viktigt att

veta varför de behöver systemet.  Bristande kompetens om IT-processer hos kunden.  Svårt att förklara för kund att processen att utveckla är föränderlig.  Fel person på plats

från kundföretaget. Personen har otillräcklig kännedom om vad användaren har för behov. Leverantör B

IT- och tele-

kommunikations-leverantör

Utvecklar anpassade system efter kundönskemål.

Inledningsvis håller utvecklare ett möte med ett flertal

användare och andra intressenter från kundföretaget för att samla

information om tidigare erfarenheter inom IT och behov för det nya systemet.

Sedan görs en prototyp av systemet som användarna får

testa. Möten och prototypdemonstreringar görs iterativt så att inte något missas. Till slut ligger detta till

grund för en kravspecifikation. Viktigt att involvera så många användare

som möjligt i processen.

 Kunden har inte användare närvarande på möten. Leverantör C Fastighets-system- och programvaru-leverantör Utvecklar standardiserade fastighetssystem, med möjlighet att anpassas till viss mån för att ingå i

avsatt modul.

För komplexa system håller utvecklingschefen ibland

möten med kund där kundönskemål diskuteras. Vanligast är att kundönskemål

skickas på e-post, sedan skickar leverantören ett bekräftelsemail på hur de har

uppfattat kundens behov. I senare skede skrivs en kravspecifikation, varpå ett

prisförslag ges.

 Kunskapsbrist hos kunden, svårt att uttrycka vad de vill ha.

 Ogenomförbara krav.

17

5. Analys

5.1 Analys av empiri med teoretisk förankring

Leverantör A och B har möten som ett initialt steg i sina kraveliciteringsprocesser. Leverantör A håller ett möte med en person från kundföretaget och Leverantör B vill involvera ett flertal användare och andra intressenter. Leverantör C håller också möten med en person från kundföretaget för mer komplicerade lösningar. Vidare itereras processen med möten för Leverantör A tills en tillräckligt god grund finns för en kravspecifikation. Leverantör B itererar processerna som involverar att hålla möten och skapa en prototyp för användarna. Leverantör C gör ingen iteration, inledande möte ligger till grund för kravspecifikationen (se Tabell 1).

Med teori kring kraveliciteringstekniker som beskrivs i avsnitt 2.3 Kraveliciteringstekniker analyseras Leverantör A:s kraveliciteringsteknik som intervju, som går under traditionell teknik. Leverantör B tycks använda två metoder ur samarbetande tekniker, nämligen JAD (Joint Application Development) och Evolutionary prototype. Leverantör C tycks även de använda intervju som kraveliciteringsteknik.

Leverantör A och C förefaller stöta på samma problem med bristande data/IT-kunskaper hos användare. Leverantör A tillägger att detta leder till att kunden inte har förståelse för en föränderlig kraveliciteringsprocess. För Leverantör C däremot leder detta till att kunden har svårt att uttrycka vad dem vill ha och att ogenomförbara krav läggs fram. Gemensamt för både Leverantör A och B är problemet med fel person på plats. Leverantör A vill ha någon som har bättre kontroll på kundföretagets behov närvarande och Leverantör B vill ha användare på plats (se Tabell 1).

Att en kraveliciteringsprocess är föränderlig är enligt Christel & Kang (1992) ett problem. Leverantör A har i den meningen ett problem att dess kraveliciteringsprocess är föränderlig under kategorin problems of volatility (Christel & Kang, 1992).

Problemet att fel person är på plats återfinns inte i avsnitt 2.4 Problem inom en kraveliciteringsprocess. Resten av leverantörernas problem går under kategorin problems of understanding (Christel & Kang, 1992).

18

6. Resultat

6.1 Vattenfallsmodellen

Grundat av egen informationssökning i avsnitt 3.3 Slutgiltig studieriktning och löpande informationssökning är dessa sex moment i Figur 2 de som mest troligt förekommer bland olika versioner av vattenfallsmodellen. Se avsnitt 2.1 Programvaruutvecklingsprocess enligt vattenfallsmodellen för en komplett beskrivning av de olika delprocesserna.

Figur 2. En programvaruutvecklingsprocess enligt vattenfallsmodellen. (egen version). Kravanalys Design Implementation Testning Användning Underhåll

19 6.2 Kraveliciteringstekniker och tillhörande problem

En sammanställning av de olika kraveliciteringsteknikerna med tillhörande kategori inom parantes ges i Tabell 2. Tabellen visar även de problem som uppstår i vardera kraveliciteringsprocess.

Tabell 2. Sammanställning av de olika kraveliciteringsteknikerna med tillhörande problem.

Leverantör Kraveliciteringsteknik (Kategori)

Problems of

understanding Problems of volatility

Problem som ej återfinns i

teorin

A Intervju (Traditionell)

 Användare vet inte vad de vill ha.  Bristande data/IT kunskaper hos användare.  Krav uppkommer allteftersom.  Fel person på plats. B JAD (Samarbetande) och Evolutionary prototype (Samarbetande)  Fel person på plats. C Intervju (Traditionell)  Användare vet inte vad de vill ha.  Bristande data/IT kunskaper hos användare.  Otydliga krav.  Användare och analytiker ”talar olika språk”.

20 Från Tabell 2 framgår ett samband mellan Leverantör A och C som båda

använder intervju som kraveliciteringsteknik. Båda leverantörerna upplever problem vad gäller användare som inte vet vad de vill ha samt bristande data/IT-kunskaper hos användare. Det finns även ett samband mellan Leverantör A och B, de har förvisso olika kraveliciteringstekniker men de delar problemet att fel person är på plats. Förutom detta har Leverantör A ett problem att krav uppkommer allteftersom, något som inte delas av de andra leverantörerna. Leverantör C har två unika problem med otydliga krav och att användare och analytiker ”talar olika språk”.

De olika problem som har specificerats av Leverantörer A-C benämns i Tabell 3: Tabell 3. Benämningar på förekommande problem bland studerade leverantörer.

Problems of understanding Problems of _volatility

Problem som ej återfinns i

teorin

Problem 1 Problem 2 Problem 3 Problem 4 Problem 5 Problem 6

Användare vet inte vad de vill ha Bristande data/IT kunskaper Otydliga krav Användare och analytiker ”talar olika språk” Krav uppkommer

allteftersom Fel person på plats

Tabell 4 visar de kraveliciteringstekniker som används av Leverantörer A-C i denna studie och frekvensen av de problem som uttrycks av Leverantörer A-C:

Tabell 4. Förekomsten av de problem som beskrivs av Leverantörer A-C indelade i kraveliciteringstekniker. Kraveliciterings- teknik Antal uttryckta problem Andel problem 1: Andel problem 2: Andel problem 3: Andel problem 4: Andel problem 5: Andel problem 6: Intervju (Traditionell) 8 2 (25%) 2 (25%) 1 (12,5%) 1 (12,5%) 1 (12,5%) 1 (12,5%) JAD (Samarbetande) och Evolutionary prototype (Samarbetande) 1 0 (0%) 0 (0%) 0 (0%) 0 (0%) 0 (0%) 1 (100%)

21

7. Slutsatser

Resultatet i avsnitt 5.2 Sammanställning och resultat tyder på att Leverantör A och C använder sig av en traditionell kraveliciteringsteknik:

 Intervju

Leverantör B använder sig av en blandning av två samarbetande kraveliciteringstekniker:

 JAD

 Evolutionary prototype

Tabell 4 i avsnitt 6.2 Kraveliciteringstekniker och tillhörande problem visar hur dessa kraveliciteringstekniker, eller kombination av tekniker, ger upphov till ett antal problem i kraveliciteringsprocesserna. Resultatet tyder på att användandet av Intervju, en traditionell kraveliciteringsteknik, leder mest sannolikt i dessa fall till problem 1 och 2 och mindre sannolikt, problem 3, 4, 5 och 6 (se Tabell 3 och Tabell 4).

Användning av de två samarbetande teknikerna JAD och Evolutionary prototype som kraveliciteringstekniker ger troligtvis i detta fall upphov till problem 6 (se Tabell 3 och Tabell 4).

22

8. Diskussion och förslag till fortsatta studier

I studien deltog tre av totalt 15 leverantörer vilket gav en bortfallsfrekvens på 80 %. Detta i sig medförde problem på grund av att endast två instanser av en kraveliciteringsteknik och en instans av en kombination av kraveliciteringstekniker utgjorde hela studien. Jag rekommenderar att ha ytterligare en datainsamlingsmetod som exempelvis fokusgrupp för att erhålla ett högre antal deltagande. Varför leverantörerna skall delta i en sådan grupp kan motiveras med att studien gör stor nytta för leverantörerna då de kan lära sig av varandras tillvägagångssätt vad gäller kravelicitering.

Det finns så pass många olika kraveliciteringstekniker eller kombinationer av kraveliciteringstekniker att testa. Från avsnitt 6.2 Kraveliciteringstekniker och tillhörande problem ses tre olika leverantörer där två använder sig av samma kraveliciteringsteknik och den tredje leverantören använder en kombination av två andra tekniker. Detta exempel påvisar möjligheten för väldigt många utfall, vilket kan göra det svårt att hitta gemensamma nämnare för att dra en generell slutsats. För att minska antalet utfall rekommenderar jag att sätta ytterligare krav enligt de krav som specifieras i avsnitt 3.5.2 Urvalsprocess att medverkande leverantörer endast använder sig av en kraveliciteringsteknik. Kraveliciteringsteknikerna kan förslagsvis identifieras i förväg som ett inledande steg. Sedan görs ett nytt urval från de som avser att delta i studien så att samtliga kraveliciteringstekniker studeras, och varje teknik används av minst två eller fler leverantörer.

På grund av den höga bortfallsfrekvensen i kombination med det höga antal utfall av kraveliciteringstekniker som finns, bör studiens validitet inte vara stark nog för att slutsatser skall användas för att stödja påståenden i andra studier. Den bör istället användas som en intressant observation och för att väcka intresse för framtida studier kring kraveliciteringstekniker.

Jag anser att semi-strukturerade intervjuer fungerade bra på så sätt att det gav en möjlighet att styra diskussionen mot kraveliciteringstekniker utan att behöva ställa stängda frågor om detta, jag skulle dock gärna ha lagt ned mer tid på att formulera frågorna så att de ger leder till mer informativa svar mot studiens syfte. Jag anser att informationen som erhålls från intervjuerna har hög trovärdighet eftersom respondenternas identiteter och företag hölls anonyma, något som majoriteten av respondenterna var noga med. Det är även viktigt med ett så litet område som detta att intervjua rätt personer som har någorlunda bra insikt i företagets kraveliciteringsprocess. Enligt mig kan detta styras bra med att hitta en utvald anställd på ett företag att intervjua. Vad gäller datatyper var primärdata ett bra val då jag ville ha kraveliciteringsprocessen beskriven av den person som är delaktig i processen.

23

9. Litteraturförteckning

Alshazly, A. A., Elfatatry, A. M. & Abougabal, M. S. (2014). Detecting defects in software requirements specification. Alexandria Engineering Journal, 53(3), 513-527.

Banker, R. D., Datar, S. M., Kemerer, C. F. & Zweig, D. (1993) Software complexity and maintenance costs. Communications of the ACM, 36(11), 81-94.

Belfo, F. (2012). People, Organizational and Technologicical Dimensions of Software Requirements Specification. Procedia Technology, 5(nr), 310-318. Bergman, B. & Klefsjö, B. (2012). Kvalitet från behov till användning (5:e uppl). Lund: Studentlitteratur.

Christel, M. G., Kang, K. C. (1992). Issues in Requirements Elicitation. (SEI-92-TR-012). Pittsburg, Pennsylvania: Software Engineering Institute.

CMS. (2005). Choosing an Appropriate System Development Methdology. CMS. Davis, A., Overmyer, S., Jordan, K., Caruso, J., Dandashi, F., Dinh, A., Kincaid, G., Ledeboer, G., Reynolds, P., Sitaram, P., Ta, A. & Theofanos, M. (1993). Identifying and measuring quality in software requirements specification. Software Metrics Symposium, 141-152. doi:10.1109/METRIC.1993.263792

ISO/IEC. (2011). ISO/IEC 25010:2011.

Japec, L., Ahtiainen, A., Hörngren, J., Lindén, H., Lyberg, L. & Nilsson, P. (1997). Minska bortfallet. Örebro: Statistiska centralbyrån.

Javed, T., Maqsood, M. E. & Durrani, Q. S. (2004) A study to investigate the impact of requirements instability on software defects. ACM SIGSOFT Software Engineering Notes. 29(3), 1-7.

Kravspecifikation. (u,å). kravspecifikation. Hämtad 11 maj, 2015, från http://www.kravspecifikation.se/

Kekre, S., Krishnan, M. S. & Srinivasan, K. (1995). Drivers of Customer Satisfaction for Software Products: Implications for Design and Service Support.

Management Science. 41(9), 1456-1470.

Kumar, R. (2010). Research Methodology: A Step-by-Step Guide for Beginners. 3e uppl. London: SAGE Publications Ltd.

Kuo, T.C. (2012). Mass customization and personalization software development: a case study eco-design product service system. Journal of intelligent manufacturing, 24(5), 1019-1031. doi: 10.1007/s10845-012-0643-8

Lines of code. (u,å). Informationisbeautiful. Hämtad 12 april, 2015, från

24 Pearl, B. (2004). THE SOFTWARE CUSTOMER/SUPPLIER RELATIONSHIP. Communications of the ACM, 47(2), 77-81.

Reichelstein, S., & Rohling-Bastian, A. (2015). Levelized Product Cost: Concept and Decision Relevance. Accounting Review, 90(4), 1653-1682. doi:10.2308/accr-51009

Royce. W. W. (1987). Managing the development of large software systems: concepts and techniques. ICSE: International Conference On Software Engineering, 328.

Saiedian, H. & Dale, B. (1999) Requirements engineering: making the connection between the developer and customer. Information and Software Technology, 42(6), 419-428.

Swift, B. 2006. Preparing Numerical Data. In R. Sapsford, & V. Jupp (Eds.), Data Collection and Analysis. (2nded. pp. 154-184). London, England: Sage Publications Ltd. doi: http://dx.doi.org.proxy.lib.ltu.se/10.4135/9781849208802.n7

Tavloato, P. & Vincena, K. (1984). A Prototyping Methodology and its Tool, Springer-Verlag, 434-446.

Tiwari, S., Rathore, S. S. & Gupta, A. (2012). Selecting requirement elicitation techniques for software projects. Software Engineering (CONSEG), 2012 CSI Sixth International Conference on, 1-10. doi: 10.1109/CONSEG.2012.6349486

Utgifter för köp av it-tjänster efter typ av utgift, storleksklass och år. År 2014. (2008). Statistiska centralbyrån. Hämtad 10 november, 2016, från http://www.statistikdatabasen.scb.se/sq/9355

Walliman, N. (2011). Research Methods [Elektronisk resurs] : the basics. London: Routledge.

25

Bilagor

Bilaga 1: Intervjumall

- Vad utvecklar ni för något på företaget? - Vilken befattning har du på företaget?

- Utvecklar ni anpassade/skräddarsydda mjukvarusystem?

- Hur gör ni för att samla in kundönskemål för dessa projekt? Använder ni någon särskild teknik? Eller är det olika beroende på fall till fall? (ex intervju, prototyping, fokusgrupper)

- Vilka personer(roller) från er och kundens sida är oftast involverade i dessa interaktioner mellan er och era kunder?

- Hur brukar processen se ut för er från kundkontakt till färdig kravspecifikation?

- Vilka är de vanligaste problemen för er i kravinsamlingsprocessen? Bilaga 2: Intervju med företag A: IT-konsult firma

- Vad utvecklar ni för något på företaget?

- Till 90% gör vi konsultuppdrag men en mindre del i vår verksamhet

innebär att vi utvecklar hemsidor, appar med mera.

- Är det ok om vi lägger fokus på just den delen att ni utvecklar, har du någorlunda bra översikt där?

- Ja jag har lite koll, jag är mest ute som resurskonsult och har hand om

rekrytering.

- Vilken befattning har du på företaget?

- Jag är testledare och platschef för ett nystartat kontor i Luleå. - Utvecklar ni anpassade eller skräddarsydda system?

- Ja vi utvecklar system efter kundönskemål.

- När ni utvecklar anpassade system, hur gör ni för att samla in kundönskemål för dessa projekt? Använder ni någon särskild teknik eller beror det från fall till fall?

- Nu har jag inte varit med i dessa projekt rakt av. Det jag vet är att

kunden har oftast ganska klara krav på vad de vill ha. Det man får göra är att diskutera med kunden varför de vill ha just det de vill ha. Om kunden vill ha ett nytt bokningssystem – varför? ”jo för att det skall gå snabbare att beställa” Och vidare fråga varför. Det är viktigt att veta varför de behöver det.

- Så ni ger er in mer lite i vad kundens problem faktiskt är?

- Precis, Oftast vet de kunden inte riktigt vad de egentligen vill ha i

slutändan. Man får brottas ett tag med denna process innan man kan sätta sig ned och börja koda.

- Vilka personer eller roller är oftast involverade i interaktioner mellan er och era kunder?

- Från vår sida har vi oftast utvecklaren som pratar med deras

projektledare. En utvecklare är oftast mer kompetent inom det specifika ärendet som det gäller.

- Hur brukar processen se ut för er från kundkontakt till färdig kravspecifikation?

- Oftast brukar vi träffas för ett möte, det beror på om befinner oss

relativt nära varandra i samma stad. Sitter man på plats då träffas man ett antal möten och skriver upp krav, man funderar sedan över

26

kraven och tar med reflektioner till nästa möte. I vissa projekt ritar man upp några krav efter ett möte och efterhand får man skriva om programmet. Det är svårt att övertyga en kund om att processen att uveckla är väldigt föränderlig. Istället för att börja med 100 krav kan man börja med några övergripande sen får man se om det dyker upp några nya under projektets gång.

- Vilka är de vanligaste problemen ni har i kravinsamlingsprocessen? - Dels så är det ett problem att de inte vet riktigt vad de vill ha, oftast på

grund av att fel person dyker upp på dessa möten. Den vi vill ha på plats är egentligen någon högre upp som har koll på varför de behöver systemet, detta dirigeras ibland nedåt till någon som inte har så bra koll. Att utveckla för någon som inte är värst bekant med processer inom IT kan bli svårt. Vi vill gärna ha ett löpande projekt, vi kan inte säga med en gång att projektet skall kosta en viss summa. Vi vill hellre utgå från några första krav, sedan allteftersom kan vi komma med nya idéer. Från början har man vanligtvis ingen bra uppfattning om vad de vill ha och hur kraven skall sättas upp – ett projekt är aldrig likadant i slutet som man skrev det från början kravmässigt. Det tillkommer alltid nya krav.

- Det är alltså en iterativ process där det tillkommer krav och kunden får ökad förståelse för processen?

- Precis och det påverkar priset också. Då vill de ibland sätta in nya

funktioner och ta bort sådant som vi kanske redan har kodat klart.

Bilaga 3: Intervju med företag B: IT- och telekommunikationsleverantör. - Vad utvecklar ni för något på företaget?

- Vi utvecklar skräddarsydda system, det kan vara vad som helst

egentligen. Allt från e-handel, frakthantering o.s.v. Vad som än passar kundens verksamhet.

- Vilken befattning har du på företaget?

- Jag är delägare och försäljningschef och projektledare.

- Ni utvecklar då anpassade eller skräddarsydda mjukvarusystem? - Ja.

- Hur gör ni för att samla in kundönskemål för dessa projekt? Använder ni någon särskild teknik eller är det lite olika beroende på fall till fall?

- Det beror på hur komplext systemet är. Är det en komplex lösning och

kunden inte har gjort någonting själv innan brukar en user-story göras innan och sedan göra en mock-up som beskriver användargränssnittet mot systemet. Dessa två moment; user-story och mock-up itereras tills kunden godkänner.

- Du nämnde mock-up, är det någon form av metod?

- Det är ett ”dumt” system för att visa kunden gränssnittet, det är väldigt

bra för dom att testa det för att säkerställa att användarna blir nöjda. Skriver man en kravspecifikation på 40 sidor i word som man gjorde förr så kan den alltid tolkas på olika sätt. Det är en väldigt träffsäker metod för låta ett större antal användare känna på gränssnittet lite.

27 - Ja det kan man säga, den blir dessutom användbar sen i produktion, tar

det 100 timmar att göra den så har man det tillgodo sen.

- Vilka personer eller roller är oftast involverade i dessa interaktioner mellan er och era kunder?

- Det är vanligtvis en affärsansvarig som är med och stödjer processen,

en gränssnittsutvecklare och en utvecklare. Vi är inte så stort företag så vi tar oftast en erfaren utvecklare från vårt håll som kan göra i princip allt.

- Hur ser processen ut för er från kundkontakt till färdig kravspecifikation? - Först är det ett möte där man samlar så mycket information och

eventuellt sådant som kunden har gjort innan. Man försöker få med flera roller från kunden som skall använda sig av systemet. Sedan börjar man skriva en user-story för att göra en mock-up. Sedan itereras detta, man kanske har 5-6 möten med kunden när man stämmer av detta kontinuerligt så man inte missar någonting. Detta blir sedan underlag för systemets kravspecifikation. Sedan prissätts och tidsestimeras detta, då kan kunden eventuellt välja bort funktioner som de inte behöver.

- Vad är de vanligaste problemen ni stöter på i kravinsamlingsprocessen? - Det svåraste är om kunden inte skickar rätt personer för möten, om de

inte skickar de som kommer använda systemet. Det är viktigt, det måste vara rätt människor. Annars är det inte så mycket konstigheter, det är en väldigt träffsäker metod.

Bilaga 4: Intervju med företag C: Fastighetssystem – och programvaruleverantör

- Vad utvecklar ni för något på företaget?

- Vi utvecklar standardiserade fastighetssystem. - Vilken befattning har du på företaget?

- Jag är en utav två delägare.

- Ni utvecklar standardiserade system sa du, ni utvecklar inte något anpassat eller skräddarsytt system?

- Det händer att vi gör anpassningar på systemet, på beställning från

kunden. Det kommer i så fall ingå i standardsystemet i den modul som kunden har valt att göra anpassningar i.

- Hur gör ni då för att samla in kundönskemål när de vill ha anpassningar i systemet? Använder ni någon särskild teknik eller är det lite beroende från fall till fall?

- Alla kunder skickar in sina önskemål via e-post, dessa analyseras sedan

av oss för att se om det finns andra önskemål som är likartade. Sedan kontaktar vi kunderna och då får vi lite mer noggrant deras specifikation. Då ger de mer en teknisk beskrivning av vad kunden vill ha, det framgår inte alltid så tydligt från ett önskemål.

- Ni har ett möte med kunden då eller?

- Det kan vara ett möte men det kan också vara att vi skickar en

beskrivning på hur vi har uppfattat önskemålet. Är det väldigt specifik lösning som krävs sätter vi ett pris på det så får kunden bestämma om de vill genomföra det.

28 - Ja, för större komplexa system krävs ibland ett möte men det kanske är

var tionde fall. I vanligaste fallet skickas ett bekräftande mail och en omfattande beskrivning av deras behov.

- Vilka personer eller roller är oftast involverade i interaktioner mellan er och kund från respektive sida?

- Det är i första hand utvecklingschefen som har kundkontakten när det

gäller teknik och genomförande, inledande kontakten sker oftast via mig.

- Hur ser processen ut för er från kundkontakt till färdig kravspecifikation? - Två vägar in; Antingen skickas kundönskemål in på mail där de

beskriver exakt vad de vill ha för funktion, annars förs telefonsamtal eller personligt möte med kund där önskemål diskuteras. Det blir inte mycket mer än så när man jobbar med standardiserade system.

- Vilka är dom vanligaste problemen ni stöter på när ni hanterar dessa ärenden?

- Det vanligaste problemet är kunskapsbrist hos kunden. De har väldigt

svårt att uttrycka vad de vill, det blir väldigt flytande. Jag kan ge ett strålande exempel: Jag var hos en kund igår som hade ett önskemål om rapportexporter till excel, varpå jag frågade vad det är exakt som ni vill åstadkomma, då sa de ”vi skall bara ha en rapport där”. Och det är inte lätt att genomföra. Man måste få en beskrivning av vad kunden vill ha, det går nästan inte att bygga en rapport på det sättet kunderna förväntar sig. Denna brist på förståelse är vårt största problem generellt.

- Blir det då att ni ofta får iterera denna process?

- Jag tycker det är beställarens sak att uttrycka sina önskemål på ett

visuellt sätt. En så enkel sak som att göra en exempellista över den information som man vill ha ut. Det skulle hjälpa till oerhört mycket, istället för att tro att vi förstå alla önskemål.