Adamma Sallah
Att fastställa metod för effektiv behovs-
och kravhantering i IT-projekt
En fallstudie på Ninetech
Establishing 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å
20
många användare att ge sin bild av vilka behov som de har då många intressenter kan
nås med liten ansträngning (Eriksson, 2008). Frågorna i en enkät kan vara öppna eller
ha bestämda svarsalternativ som skall fyllas i, Eriksson (2008) skriver att öppna frågor
tar betydligt längre tid att administrera men kan ge infallsvinklar som annars inte skulle
upptäckas. Dock ser Eriksson (2008) att det även finns nackdelar med användningen av
enkäter, en av dessa är att för att få ut användbar information krävs det en stor
ansträngning av den som skriver frågorna. I rapporten som Roubah och Al-Rafee
(2008) skrivit visas det att 89 % av de utvecklingsprojekt som ingick i undersökningen
använts sig av någon form av enkäter.
▪ Workshops är enligt Eriksson (2008) en generell teknik som kan tillämpas på både
stora och små projekt genom att ett möte utförs mellan en workshopledare tillsammans
med ett antal intressenter för att komma fram till vilka behov som finns för det nya
systemet. Vidare förklarar Eriksson (2008) att workshop är en effektiv metod som kan
användas för att på reducerad tid samla in, prioritera samt strukturera de insamlade
kraven. Roubah och Al-Rafee (2008) samt Eriksson (2008) anser att det effektivaste
sättet att samla in kraven under workshop är att de som är med på workshopen skriver
ner sina krav på post-it-lappar som sedan sätts upp på en tavla därefter diskuterar de
idéerna på post-it-lapparna för det kommande projektet.
▪ Observation De Lucia och Qusef (2010) anser att observationer används för att
utvärdera samt öka förståelsen för de sociala och organisatoriska krav som bör tas
hänsyn till. Vidare förklara De Lucia och Qusef (2010) att arbetssättet är effektivt inom
de systemutvecklingsmetoderna då framtagning av krav kring hur processerna inom
verksamheten ser ut eller samverkan mellan medarbetarna skall analyseras. Yousuf och
Asger (2015) förklarar att kravhanteraren observerar användarens verksamhet utan att
störa deras arbete. Observations tekniken används när kunden inte kan förklara vad de
vill ha med systemet, hur de arbetar samt när vissa pågående processer ska övervakas
(Yousuf & Asger 2015). Yousuf och Asger (2015) förklarar även att observations
teknik vanligtvis används i kombination med andra tekniker. Eriksson (2008) beskriver
observationer som ett tillfälle då kravhanteraren observerar användarna i deras miljö
för att förstå hur de arbetar, vilket kan leda till en förbättrad förståelse för hur
verksamhetens arbete ser ut. Eriksson (2008) förklarar att fördelarna med observationer
är att inga direkta förberedelser behöver ta plats innan arbetet börjar samt att
kravhanteraren själv kan upptäcka processer som är onödiga vilket användaren själv
inte tänker på (Eriksson, 2008). Nackdelarna är att det kan vara svårt att få tillåtelse att
genomföra observationer, då kunden kan se det som onödig tid som slösas på att
”praktisera” (Eriksson, 2008). Observationer är inte heller enligt De Lucia och Qusef
(2010) ett komplett arbetssätt utan bör kombineras med andra utvärderingsmetoder,
exempelvis användarfall.
3.4.2 Prioritera
Eriksson (2008) anser att under prioriterings aktiviteten så är syftet att utvärdera de krav som
samlats under insamlings för att se vilka krav som förbinds med störst risker kontra ger mest
värde för pengarna. Kravanalytikern ska tillsammans med intressenterna utföra prioriteringen
av de insamlade kraven, dock så kan det ske att olika intressenter har olika prioritet på kraven
(Sommerville och Sawyer 2004). Vidare förklarar de att ha många intressenter kan leda till
konflikter vilket innebär att förhandling måste ske för att kompromissa på så sätt göra så att
alla involverade blir nöjda. Att prioritera kraven underlättar för projektets ledning genom att
21
det klargör vilka krav som ska ingå samt fördela resurserna rätt i projektet, utvecklarna och
leverantörerna vet då också vilka krav det är de ska fokusera på (Eriksson 2008). För att kunna
bestämma vilka krav som ska implementeras först så är prioritering viktigt, eftersom genom
kravprioritering så kan man både leverera affärsnytta så tidigt som möjligt samt implementera
de krav som har hög prioritering först (Paetsch, Eberlein & Maurer 2003). Vidare förklarar de
att det är viktigt att prioriteringen hålls uppdaterad under hela utvecklingsprocessen och att det
inte är en process som bara sker i början.
Eriksson (2008) antyder att vid prioritering så är det vanligt att värdeskalor används t.ex., hög-
, medel-, och lågprioritet eller måste/bör prioriteras, detta bekräftas även av Paetsch, Eberlein
och Maurer (2003) som anger samma värdeskalor. Eriksson (2008) tillägger att kraven även
bör prioriteras mot parametrarna tid, kostnad och risk.
▪ Fyrgradig skala innebär att varje krav prioriteras enligt en fyrgradig skala (Eriksson
2008). Fyrgradig skalan kan användas på så sätt att varje person bara får använda en
siffra per krav, detta kan genomföras genom t.ex. att ha en stor konferenstavla som är
uppdelat i fyra delar där man kan använda sig av post-it-lappar som flyttas runt i de
olika delarna (Eriksson 2008).
▪ Skall, bör, bra att ha går ut på att kraven antingen prioriteras enligt om de är absolut
nödvändiga, om de bör finnas eller om de bara är krav som är bra att ha (Eriksson
2008).
▪ Hög, medel, låg gäller när man använder sig av en tavla tillsammans med post-it-lappar
(Eriksson 2008). Prioriteringen genomförs genom att det bara är en person som ska
flytta lapparna på tavlan dock så sker det en diskussion deltagarna sinsemellan där dom
tillsammans kommer fram till vilka kravens grad. De krav som har högst prioritet
ligger längst upp på tavlan, de minst viktiga kraven hamnar längst ner samt i mitten
återfinns de krav som är medelprioriterade och de krav som gruppen hade svårt att
prioritera (Eriksson 2008).
▪ MoSCoW är en prioriterings teknik som är en förkortning på de engelska orden, Must,
Should, Could och Won’t, på svenska översätts de till Måste, Borde, Kunde samt Inte
(Eriksson 2008). Denna prioriterings metod antyder att Måste-kraven måste uppfyllas
för att projektet ska räknas som ett lyckat projekt, Borde-kraven bör uppfyllas men det
tynger inte ner projektet om de inte uppfylls. Kunde-kraven kan förbigås utan att det
påverkar projektet samt att Inte-kraven antyder att de inte ska realiseras vid tillfället
men kan komma att realiseras vid ett senare tillfälle (Eriksson 2008).
3.4.3 Dokumentera
Eriksson (2008) anser att kravdokumentation kan ses som ett kontrakt mellan beställare och
utvecklare/leverantör samt en överenskommelse mellan användare och utvecklare. Krav kan
dokumentera genom användningsfall, användarberättelser eller kravspecifikationer eller
genom en kombination av teknikerna. Kravdokumentation bör enligt Eriksson (2008)
innehålla funktionella samt icke-funktionella krav. Vidare anser han att systemets funktioner,
in- och utdata till varje funktion, flöden inom systemet, flöden mellan systemet och andra
system, hur systemet är relaterat till andra system, händelser i systemet, bildskärmsutseende,
verksamhetsregler samt icke-funktionella krav bör beskrivas så detaljerat som tänkbart.
Följande dokument anser (Eriksson 2008) vara vanligt förekommande för att dokumentera
olika slags krav i beroende på situation:
22
▪ Förstudie är enligt (Eriksson 2008) en utredning som genomförs på verksamheten för
att förstå hur verksamheten fungerar vilket i sin tur leder till att en bra
kravspecifikation, uppdragsbeskrivning samt en eller flera användningsfall kan
utformas.
▪ Visionsdokument avser att beskriva vad visionen med systemet är (Eriksson 2008).
▪ Kravspecifikation är det dokument där man hittar alla krav det är även ett dokument
som kan få namnet uppdragsbeskrivning ifall det avser en eller flera mindre ändringar
(Eriksson 2008). Sommerville (1998) beskriver kravdokumentet som ett dokument som
innehåller det utvecklarna ska implementera samt att kravdokumentet ska skrivas på en
begriplig nivå för att vara som stöd för alla verksamhetsaktörer. Vidare förklarar han
att kravdokumentet kan vara mer begriplig om det finns diagram modellerade som
överensstämmer med dokumentets innehåll.
▪ Användningsfall innehåller illustrationer av hur aktörer interagerar med ett system,
samt att de används mestadels vid utveckling av ett nytt system (Eriksson 2008).
Användningsfall kan enligt Eriksson (2008) antingen ersätta en kravspecifikation eller
användas för att komplettera kravspecifikationen.
▪ Användarberättelser så uttrycks kraven väldigt kortfattat, skriven med vardagligt språk
samt att den ska skrivas utifrån användarens perspektiv utan tekniska detaljer (Eriksson
2008). Fördelen med användarberättelser är att det är ett snabbt samt enkelt sätt att
dokumentera kraven på, nackdelen däremot är eftersom kraven ska vara kortfattade så
ökar chansen att viktiga information går förlorad (Eriksson 2008).
3.4.4 Kvalitetssäkra
Sommerville och Sawyer (2004) förklarar att kvalitetssäkring handlar om att säkerställa sig att
kraven följer de kvalitetsstandard som är satt. De anser att kraven som är dokumenterade
måste valideras för att hitta krav som missats, eventuella konflikter mellan krav och/eller
otydliga krav. När kvalitetssäkring genomförs så är det rekommenderat att alla intressenter
som var med vid insamling av krav att vara med för att eventuellt förtydliga oklarheter
(Sommerville & Sawyer 2004). Eriksson (2008) anser att kvalitetssäkring är en återkommande
aktivitet som sker genom hela utvecklingen och inte något som ska göras i slutet av
utvecklingen.
▪ Granskning är en effektiv metod att använda sig av kvalitetssäkring av kraven
(Eriksson 2008). Granskningsprocessen går ut på att en grupp bestående av olika roller
som tillsammans går igenom kravdokumenten för att hitta fel och reda ut eventuella
oklarheter. Rollerna i gruppen kan bestå av kravställaren, testaren,
systemutvecklare/IT-arkitekt, användarrepresentant samt projektledare eller
systemägare (Eriksson 2008).
o Kravställare är antingen den som har skrivit dokumentet som ska granskas eller
är en av de personerna som tillsammans tagit fram kravdokumentet.
Kravställaren ska svara på eventuella frågor som granskarna ställer angående
kraven (Eriksson 2008).
o Testare ska enligt Eriksson (2008) representeras av testledare och/eller en eller
flera testare. Testplan och testfall är två dokument som testgruppen ska ta fram
för att granska kraven, uppgifterna på testplan samt testfallen ska vara baserat
på kravdokumentet så det gäller att testgruppen förstår kraven samt har chansen
under granskningen att gå igenom kravdokumentet.
o Systemutvecklare/IT-arkitekt är med under granskningsprocessen precis som
testaren för att granska kraven, förstå vad det är de ska bygga (Eriksson 2008).
23
o Användarrepresentant är möjligtvis den person som ursprungligen kommit med
önskemålet (Eriksson 2008).
o Projektledare eller systemägare är den person som har ansvar för projektets
ramar. Eriksson (2008) förklarar att möjligheten finns att projektledaren inte
har tid att närvara vid granskningsmötet men att denne bör delta vid granskning
av dokumentation som är mest kritiska för att systemet ska uppnå en hög
kvalité. Projektledaren ska även säkerställa att dokumentationen inte innehåller
några kommunikationsproblem samt att kraven är av hög kvalité (Eriksson
2008).
▪ Användningstester handlar till stor del enligt Eriksson (2008) att analysera systemets
användbarhet samt för att identifiera vilka krav som finns för utformningen av systemet
ur användbarhetssynpunkt. Ottersten och Berndtsson (2002) förklarar att
användningstester är ännu ett annat sätt att använda sig av för att kvalitetssäkra kraven.
Tidigt under utvecklingsprojektet så är det pappersprototyper som är bäst lämpad för
att sedan när utvecklingsprojektet väl kommit igång utföra körbara prototyper.
24
3.5 Analysmodell
Analysmodellen illustrerad i figur 2 är konstruerad av författaren själv. Analysmodellen har
skapats utifrån den insamlade teorin. Björklund och Paulsson (2003) anser att det är väsentligt
att belysa sambandet mellan olika faktorer i en analysmodell. Analysmodellen hjälper för
utifrån uppsatsens syfte åskådliggöra det mest relevanta delarna av teorin (Patel & Davidson
2011). Miles och Huberman (1994) belyser att analysmodeller kan vara baserat på teori,
beskrivande eller illustrera vad som avses att behandlas.
Figur 2: Analysmodell över en metod för behovs- och kravhantering
Källa: Författaren
Analysmodellen illustrerad i figur 2 visar på hur en framgångsrik metod för behov- och
kravhantering bedrivs genom att en verksamhet har en fastställd kravstrategi. De 3 understa
delarna behovsanalys, kravhantering samt kravspecifikation påverkas/bestäms av den översta
delen som är kravstrategi.
Analysmodellen utgår från att verksamheten har en fastställd kravstrategi. En fastställd
kravstrategi handlar om att en verksamhet övergripande beskriver vilka tekniker, metoder och
verktyg som finns på företaget gällande krav. Inför varje projekt tas en projektplan fram där
man med stöd från kravstrategin kommer fram till hur kravarbetet kommer bedrivas i just det
enskilda projektet.
När kravplanen har tagits fram så är det dags att börja med insamling av behoven. Här gäller
det sätta intressenternas behov i fokus. Om en verksamhet har en fastställd kravstrategi, så
underlättar det framtida projekt eftersom att man inför varje projekt inte behöver planera allt
från start.
Pilarna från kravstrategin till behovsanalys, kravhantering och kravspecifikation innebär att
det är genom kravstrategi fasen man bestämmer hur behovsanalysen, kommer att genomföras,
vilka kravinsamlingstekniker man ska använda sig av under kravhanteringen samt hur
kravspecifikationen ska dokumenteras. Pilen från behovsanalys till kravhantering samt
kravhantering till kravspecifikation innebär att output från föregående fas är input till nästa.
25
3.5.1 Kravstrategi
En kravstrategi ska vara övergripande och beskriva vilka tekniker, metoder, verktyg som finns
generellt på ett företag gällande krav, när det sedan är dags för ett projekt eller en sprint så går
man djupare ner för att förklarar hur man ska använda vad.
Mattson och Lööw (2012) anser att ett strukturerat och hög-kvalitativt utvecklings-och
testarbete börjar med en lika strukturerat samt hög-kvalitativ kravhantering. Att ha en
fastställd kravstrategi underlättar att man under kravhanteringsarbetet sätter förutsättningarna
för att bygga rätt system på rätt sätt vilket i sin tur leder till att vid varje enskild uppdrag att
kravplanen ska innehålla en beskrivning om hur planering av kravanalysen ska utföras samt
vilka resurser som kommer att användas (Mattson & Lööw 2012).
Hauksdóttir och Nielsen (2014) beskriver kravstrategi som en hög nivå strategisk plan för
kravhanteringsprocessen. Kravstrategin innehåller en strategi för riktning, mål samt långsiktig
plan för verksamheten.
Eriksson (2013) skriver att en kravstrategi skall finnas samt att denna ska gälla för hela
organisationen. Det är väldigt vanligt att när leverantören arbetar med test att en teststrategi
finns men det är väldigt sällan en kravstrategi finns samt att detta kan bero på kravmognaden i
organisationen (Eriksson 2013).
Mattson och Lööw (2012) anser att kravstrategi är en beskrivning av hur man ska arbeta med
kraven inom ett projekt, förvaltningar samt andra typer av uppdrag i företaget för att sätta rätt
ambitionsnivå. Kravstrategin är underlag till samt avlastning av kravplanen, därmed ska
kravstrategin innehålla en beskrivning av vilka arbetsuppgifter som det enskilda företaget
anser ingår i kravledningen, hur kravutvecklingen ska ske samt hur dokumentation och
uppföljning av kravarbetet ska ske (Mattson & Lööw 2012).
Eriksson (2013) förklarar att en kravstrategi är ett hjälpmedel för både leverantören samt
beställaren att veta på vilket sätt dokumentationen kommer att utföras, samt att den tillåter
leverantören att veta vilka verktyg och tekniker som används samt om användarberättelser
eller användningsfall används. Vid uppstart av projekt i en verksamhet, så plockar
leverantören tillsammans med beställaren bitar ur kravstrategin som infogas i kravplanen, detta
medför att arbetet blir mycket enklare eftersom det finns något att luta sig mot (Eriksson
2013). Kravplanen anses vara ett projekt som sedan blir ett godkännande på hur arbetet skall
gå tillväga, brist på en kravplan innebär problem med förankringen.
Kravledning
Mattson och Lööw (2012) anser att under kravledningen på kravstrategin så beskrivs de
arbetsuppgifter som en kravledare eller den som har planeringsansvar, ansvarar för. Vidare
förklarar Mattson och Lööw (2012) att kravledningen vanligtvis innehåller områden som
beskriver hur planering av kravarbetet ska ske, hur riskanalysen ska genomföras samt hur
kraven och kravdokumenten versionshanteras.
Jaafari (1999), Jansson och Ljung (2004) samt Holmberg och Nassén (1995) delar in risker i
interna och externa risker. Interna/externa risker kan bland annat vara sammansättning av
gruppen, lagar, ledningsstil, resurser, leverantörer, marknad och konkurrens, beställaren samt
nyckelvariablerna som är tid, kostnad samt kvalitét.
Hagberg och Ljung (2000) belyser att det är under projektets inledning som de interna riskerna
är som störst samt att riskerna minskar allt eftersom projektets plan blir tydligare samt att
projektgruppen blir allt mer samspelt. De externa riskerna däremot är större vid slutet av
26
projektets gång eftersom att det är omöjligt för ett projekt att ha en uppfattning om vad
marknaden önskar långt in i framtiden.
Riskanalyser är väldigt viktiga enligt Hamilton (1996) eftersom att dagens samhälle är ett
risksamhälle där risker blivit allt svårare att upptäcka och tolka. Hamiltons (1996) anser att
riskanalys kan genomföras antingen via ett formellt eller ett intuitivt sätt. Formell riskanalys
handlar enligt Hamilton (1996) om att man använder sig av modeller medans intuitivt handlar
om att använda sig av ens egna erfarenheter samt vilka risker som eventuellt kan förekomma.
Jansson och Ljung (2004) definierar riskanalys som ett verktyg som är till för att hjälpa
projektledaren att använda sig av för att identifiera samt värdera osäkerheter i projektet.
Riskanalys innebär en systematisk kartläggning av riskerna i ett system eller en verksamhet
samt en bedömning av sannolikheten för att de ska inträffa och de konsekvenser det skulle
medföra (Arvidsson, Engvall & Süld 2006).
Dessutom innehåller det beskrivning av spårbarhet mellan krav, testfall och felrapporter, hur
kraven ska prioriteras och valideras samt hur godkännandeprocess och ändringshantering för
krav ska gå till (Mattson & Lööw 2012).
Nordström och Welander (2007) definierar ändringshantering som en del av
systemförvaltningen där syftet syftar på processen som en kund går igenom från att de gör en
ändringsförfrågan till att den är slutförd.
Kravutveckling
Under kravutvecklingen beskrivs vanligen företagets kravprocess, hur verksamhetsanalys
genomförs samt på vilka områden som den bör göras på (Mattson & Lööw 2012).
Sommerville (2007) förklarar att kravutveckling handlar om hur kraven ska prioriteras samt
specificeras.
Beskrivningar av vilka insamlingstekniker som finns samt när de lämpar sig bäst finns också
under kravutvecklingen samt hur man detaljerar krav på olika nivåer (Mattson & Lööw 2012).
Uppföljning & dokumentation av kravarbetet
Uppföljning och dokumentation av kravarbetet innefattar hur kravarbetet ska dokumenteras,
vilka mallar och verktyg som används på verksamheten (Mattson & Lööw 2012). Lind (2001)
förklarar att en verksamhetsanalys innebär att skapa en överblick över verksamheten.
Verksamheter kan därmed vara svåra att överblicka, vilket innebär att en prioritering måste
göras av vilka olika delar av verksamheten som ska analyseras samt vilka det är som ska
bortses (Lind 2001). Vid val av vilka delar av verksamheten som ska analyseras så måste stor
fokus läggas på det som anses vara viktigt. Christiansson och Christiansson (2005) definierar
verksamhetsanalys enligt följande:
” Verksamhetsanalys betraktas traditionellt som det arbete som föregår initieringen av en
systemutveckling eller är initieringen av en systemutveckling”.
3.5.2 Behovsanalys
Behovsanalys handlar om att identifiera och analysera behov. Sommerville och Sawyer (2004)
belyser att behov ofta förväxlas med krav, behov handlar om något som någon kan använda
samt att ett krav beskriver vad något ska uppfylla samt indirekt vad det inte ska uppfylla.
Kravplan
Kravplan handlar enligt Eriksson (2013) om att förklara i detalj hur kravhantering ska utföras i
en viss situation. För varje projekt uppstart så gäller det att ta fram en kravplan som
27
kompletterar kravstrategin just för det specifika projektet. Kravstrategi är en beskrivning på
generell nivå som förklarar vem som gör vad, hur, när och varför, medans en kravplan är mer
detaljerad och beskriver bara en situation (Eriksson 2013).
Identifiera och prioritera intressenterna
Eriksson (2008) förklarar att intressenter kan finnas både inom och utanför organisationen
samt att ett system har olika intressenter som påverkas antingen direkt eller indirekt av
systemet. Olika intressenter kan ställa olika typer av krav på systemet, exempel på intressenter
kan vara: användare, myndigheter, IT-arkitekt, IT-ledning, testare, utvecklare driftorganisation
samt andra system (Eriksson 2008). Mattson (2014) anser precis som Eriksson (2008) att
intressenter kan vara interna och externa samt att de kan vara direkta eller indirekta, detta leder
till att intressenterna kan vara väldigt många samt att det blir svårt att komma fram till vilka
intressenter som är av intresse eller att man enkelt kan missa vissa viktiga intressenter. Ferrary
(2009) anser att ett företag bör beakta tre punkter gällande intressenter:
❖ Nödvändigheten att veta vilka intressenterna är
❖ Veta vad intressenterna vill ha
❖ Veta hur intressenterna kommer att försöka nå dit
Prioritering av intressenter kan vara en fördel eftersom möjligheten finns att tid inte kommer
finnas för att hinna med samtliga intressenter, vilket även innebär att arbetet kan planeras
bättre (Mattson 2014). Vissa intressentgrupper bör prioriteras över andra eftersom att det oftast
är omöjligt att tillgodose alla intressenter (Andersson 2009). Genom att prioritera samt
eventuellt gruppera intressenter så bör man överväga hur arbetet kommer ske med de olika
grupperna, t.ex. att skicka enkätundersökning till en viss grupp, genomföra intervjuer med
annat, utföra workshop med en tredje (Mattson 2014).
Samla in och bearbeta intressenternas behov
Efter att ha skapat en plan av hur intressent arbetet kommer bedrivas för att samla in behov så
är det dags att förbereda eventuella intervjufrågor, workshops möten, enkätundersökningar för
att arbeta med de olika intressenter (Mattson 2014). Al-Rawas och Easterbrook (1996) belyser
att det perfekta teamet består av intressenter från alla olika delar av verksamheten, dock så är
fallet oftast omöjligt att en sådan grupp sammanställs. Insamling av behov innebär att
kommunikation med flera intressenter bör ske genom att den som samlar in behov
kontinuerligt interagera med de olika intressenterna (Hadar et. Al., 2014). Via kommunikation
med alla olika intressenter så bidrar det till att kunskap effektiv kan genereras eftersom
enskilda individer mestadels omöjligtvis kan inneha all kunskap själv (Al-Rawas och
Easterbrook 1996). Intressenterna uttalar oftast behoven i olika termer, användarna använder
sig av vardagliga termer medans utvecklare använder sig av tekniska termer.
Bearbetning av intressenternas behov ska göras efter att de har samlats in. Mattson (2014)
belyser att bearbetning av behoven innebär att skapa en sammanställning av behoven så att de
är förståeligt för alla involverade samt att de ska förstå vad det är som kommer att behöva
göras.
3.5.3 Kravhantering
Inom IT-världen så är det väldig vanligt att ett begrepp har olika definitioner beroende på vem
författaren är. Kravhantering är precis ett sånt ord som har många olika definitioner, men det
alla de olika definitioner har gemensamt är att kravhantering handlar om att ta reda på vad
användaren vill ha från ett system, förstå deras behov för att sedan översätta det till design.
28
Sommerville och Sawyer (2004) anser att kravhantering täcker in alla aktiviteter som handlar
om att hitta, dokumentera samt underhålla krav för ett IT-system. Kravhantering relaterar till
systemutveckling eftersom kravhantering handlar om att ”designa den rätta saken” samt att
utvecklingen handlar om att ”design saken rätt” (Sutcliffe 2002).
Sutcliffe (2002) samt Sommerville och Sawyer (2004) anser att det inte finns någon kokbok
med ett korrekt tillvägagångssätt för hur en kravhanteringsprocess ska genomföras. De olika
aktiviteterna inom kravhanteringsprocessen kan flexibelt ordnas så att de passar in i ett
sammanhang samt i en utvecklingsmetod. Vidare anser de att det inte går att föreslå en
kravhanteringsprocess som ska passa alla verksamhet och projekt samt att möjligheterna för att
organisera aktiviteterna är många.
Framtagning, analys och förhandling samt validering är enligt Sutcliffe (2002) samt
Sommerville och Sawyer (2004) de aktiviteter som bör ingå i en kravhanteringsprocess,
Sutcliffe (2002) tillägger utöver de tidigare nämnda aktiviteterna även aktiviteten modellering.
Eriksson (2008) anser att kravhanteringsprocessen bör inneha följande aktiviteter; insamling,
dokumentation, prioritering, strukturering, kvalitetssäkring samt förvaltning av krav. Alla de
tidigare nämnda aktiviteterna har en samlingsterm enligt Eriksson (2008) som är stjärnan.
Kravinsamling
Kravinsamling är det första steget under kravhanteringsprocessen. Gorschek och Telje (2002)
anser att kravframbringande är ett bättre ordval att använda sig av eftersom krav tas fram
genom flera olika tekniker så handlar det inte enbart om att samla in krav. Det är under detta
steg som utvecklarna med hjälp av intressenterna som framtagits under behovsanalysen
tillsammans med ett urval av metoder/tekniker fångar det tilltänkta systemets krav. Insamling
av krav från beställare och användare är en stor del av kravhanteringsprocessen dock så har
kunder och användare oftast inte någon om vad de egentligen vill ha. Det är då kravinsamlings
aktiviteten kommer in som syftar till att identifiera kunder samt användarnas uttalade såväl
som deras förväntade behov och önskemål (Eriksson 2008).
Nuseibeh och Easterbrook (2000), Eriksson (2008) samt Wiegers (2003) anser att insamling av
krav sker genom olika tekniker som involverar intressenter, därmed måste intressenter ha
analyserats och identifierats. För att på bästa sätt samla in alla nödvändiga krav så är det bästa
tillvägagångsättet att använda sig av en mix av flera insamlingstekniker (Sutcliffe 2002).
Sommerville och Sawyer (2004) förklarar att framtagningen av krav inte bara handlar om att
fråga de berörda vad de vill ha utan att det krävs även att en verksamhetsanalys görs. Vidare
förklarar de att det inte alltid är rätt att hitta de rätta kraven eftersom att det ofta finns många
intressenter som direkt eller indirekt påverkas av systemet samt att de berörda intressenterna
mestadels accepterar systemet utifrån olika kriterier. Kravinsamling kan ske genom flera olika
metoder, t.ex. intervjuer, observationer, prototyping, brainstorming (Eriksson 2008). Kort
beskrivning av de olika kravinsamlingsmetoderna återfinns under kapitel 3.5.
Analys & Förhandling av krav
I syfte att sortera och analysera de krav som framkommit under insamlingsfasen så genomförs
analysering och förhandling av krav (Kotonya & Sommerville 2003). Vidare belyser de att
genom att sortera samt analysera kraven så leder det till att kraven som känns mest angelägna
prioriteras.
Syftet med analys och förhandling är att tolka krav på ett entydigt sätt, komma överens med
kunden om vilka kraven är samt att komma i underfund med vilka krav som ska vara med
samt vilka som saknas. Sommerville och Sawyer (2004) anger att analys av kraven syftar till
att se överlappningar, utelämningar, konflikter samt inre motsägelser. Krav på ett system med
29
flertalet intressenter kan ofta leda till att konflikter uppstår eftersom alla vill just att deras krav
ska realiseras. Detta kan undvikas genom att ha en förhandling av kraven där intressenterna får
kompromissa vilket bidrar till att alla involverade blir nöjda (Sommerville & Sawyer 2004).
3.5.4 Kravspecifikation
Dokumentation
Att skriva ner de kraven som man kommit fram till underlättar för både beställaren och
utvecklaren. Andersson och Aderud (2014) förklarar att det finns två typer av dokumentation,
nämligen kravspecifikation och användardokumentation. Enligt Nuseibeh och Easterbrook
(2000) samt De Lucia och Qusef (2010) så innebär dokumentering att kraven ska
dokumenteras av utvecklingsteamet på ett så tydligt sätt för att lätt kunna kommunicera med
kunderna. En viktig detalj för utvecklarna att lägga fokus på under dokumentationen är att
använda sig av ett språk eller notation som användarna kan ta till sig (Nuseibeh &
Easterbrook, 2000). Dokumentation som tas fram kan ses som ett kontrakt mellan leverantör
och beställare eftersom dokumentationen är underlaget som beställaren godkänt samt som
leverantören följer (Eriksson 2008). Groscheck och Tejle (2002) samt Eriksson (2008) belyser
vikten av spårbarhets aktiviteten under dokumentation, eftersom att man ska kunna spåra var
ändringarna kommer ifrån. Vidare förklarar de att genom spårbarhet så ska man kunna se
konsekvenser av ändringar, samt ifall att en ändring var felaktig så finns möjligheten att återgå
till den tidigare versionen.
Validering
Validerings aktiviteten handlar om att validera kraven. Det som ska göras under aktiviteten är
att läsa dokumentet noga, hålla intervjuer använda sig av checklistor, prototyper skriva
scenarier och användningsfall. Nuseibeh och Easterbrook (2000) förklarar att validera kraven
kan vara en svår process eftersom olika intressenter har motsägande mål med utvecklingen
vilket kan resultera i konflikter. Under validering av kravs processen så skall utvecklarna och
intressenterna komma överens med varandra om att rätt krav har samlats in samt att dessa
stämmer överens med de mål som satts upp med projektet (Nuseibeh & Easterbrook 2000; De
Lucia & Qusef 2010). Sommerville (2010) anser att validering är processen då man
kontrollerar att kraven faktiskt definierar det kunden verkligen vill ha. Vidare förklarar
Sommerville (2010) att validering överlappar med analysering av krav eftersom det berör
processen att hitta problem med kraven. Krav validering är en viktig process eftersom fel i
kravdokumentet kan leda till omfattande omarbetnings kostnader när problemen upptäcks
under utveckling eller efter att systemet är i drift (Sommerville 2010). Wiktorin (2003) anser
att även med den bästa av arbetsgrupper kommer den resulterande specifikationen att vara
förknippad med fel och andra ofullkomligheter, detta är anledningen till att kraven behöver
utsättas för någon form av granskning eller provning. Verifiering och validering är två begrepp
som används som komplettering för att identifiera felaktigheter, det är dessutom två begrepp
som ofta beblandas (Wiktorin 2003). Verifiering handlar om korrekthet alltså om systemet gör
saker på rätt sätt medans validering handlar om rimlighet det vill säga om systemet gör rätt
saker (Wiktorin 2003).
30
4 ANALYS I följande avsnitt ställs insamlad empiri mot den teori som presenteras från de litterära
studierna. Analyskapitlet följer analysmodellens struktur, ändamål är att ge svar på syftet som
tagits fram för uppsatsen.
4.1 Kravstrategi
Kravstrategi är enligt Mattson och Lööw (2012) en beskrivning av hur kravarbetet bör
bedrivas inom ett projekt för att sätta rätt ambitionsnivå. Samtliga respondenter anser att en
kravstrategi skulle underlätta hur kravarbetet bedrivs inom ett projekt på Ninetech. Strategen
förklarar vidare att det skulle underlätta eftersom att de i dagsläget är väldigt personberoende
vad gäller kravfångsten samt att den ser så otroligt annorlunda ut beroende på vilken eller
vilka personer det är som gör jobbet. Han anser att det skulle kunna bli lite bättre och se lite
mer lika ut och kanske blir en totaltsett högre kvalité på kravarbetet om de faktiskt hade
nånting mer att utgå ifrån. Lösningsarkitekt 1 förklarar att om man inte väljer en kravstrategi
eller inte funderar kring det överhuvudtaget så missar man förmodligen någonting eller så tar
man inte hänsyn till det unika fallet vilket gör att man kanske väljer en strategi av gammal
vana eller att man missar krav.
Testaren anser att en kravstrategi är ett underlag för att underlätta en testares arbete eftersom
att det leder till att man slipper projekt där de frågar om hon kan utföra tester i ett projekt som
saknar dokumentation men att hon istället ska fråga någon deltagare i gruppen som ska
uppdatera henne om projektet. Mattson och Lööw (2012) anser att ett strukturerat och hög-
kvalitativt utvecklings-och testarbete börjar med en lika strukturerat samt hög-kvalitativ
kravhantering. Patesch, Eberlein och Maurer (2013) anser att det är viktigt att prioriteringen av
kraven hålls uppdaterad genom hela utvecklingsprocessen och inte bara i början. Testaren
förklarar att hon hoppas slippa projekt där man kommer in lite i efterhand och så finns det
några gamla krav kvar som inte är aktuella längre kvar i dokumentet. Hon förklarar att krav
ska ju vara föränderliga, alla lär ju sig längs vägen även kunden men med en kravstrategi
hoppas hon att man kommer tillrätta med ett sätt att hålla ordning på saker och ting också
eftersom hon anser att det är ogjort arbete om man bara skriver ner massa saker i början som
man vet inte kommer att användas.
4.1.1 Kravledning
Lösningsarkitekt 1 förklarar att planering av projekt/arbete beror oftast på vilken roll som har
hand om det, det kan t.ex. vara en verksamhetsarkitekt, verksamhetskonsult eller
lösningsarkitekt. Är det ett jättestort projekt så är det oftast en projektledare med och kanske
en eller flera arkitekter som gör det tillsammans, alternativ är det en som gör själva jobbet och
så är det minst en arkitekt som är med som gör överlämningen till lösningsfasen. Mattson och
Lööw (2012) anser att under kravledningen på kravstrategin så beskrivs de arbetsuppgifter
som en kravledare eller den som har planeringsansvar, ansvarar för. Strategen däremot anser
att planering av arbetet görs oftast av den som är strateg tillsammans med lösningsarkitekten.
Strategen förklarar vidare att det är inte alltid som de kan göra det tillsammans, då är det nån
person som det hamnar på mer eller mindre själv så egentligen kan man säga att det görs
utifrån den eller de personerna som ska göra jobbet, finns ingen struktur för hur det går till det
görs olika beroende på vad det är för person.
Riskanalyser är väldigt viktiga enligt Hamilton (1996) eftersom att dagens samhälle är ett
risksamhälle där risker blivit allt svårare att upptäcka och tolka. Samtliga respondenter anser
31
att det är projektledarens uppgift att genomföra en riskanalys. Strategen förklarar att en
riskanalys kan göras enligt någon av modellerna som finns i PRINCE2 delarna.
Jansson och Ljung (2004) definierar riskanalys som ett verktyg som är till för att hjälpa
projektledaren att använda sig av för att identifiera samt värdera osäkerheter i projektet.
Lösningsarkitekt 2 anger att på Ninetech så har de olika typer av riskanalys, det finns en
riskmatris som de fyller i deras projektmetodik där de försöker identifiera alla risker runt och i
projektet, behöver inte vara nåt tekniskt, det kan vara att någon nyckelperson i projektet redan
har fått beviljad tjänstledighet i ett halvår så att de kan bara utnyttja personen under en kort tid.
En risk kan vara att någon slutar, att de har en tredjeparts som de inte har arbetat med förut och
inte känner till, att de har missbedömt komplexiteten i nånting. Riskanalys innebär en
systematisk kartläggning av riskerna i ett system eller en verksamhet samt en bedömning av
sannolikheten för att de ska inträffa och de konsekvenser det skulle medföra (Arvidsson,
Engvall & Süld 2006). Enligt Lösningsarkitekt 2 så är det lite olika typer av risker som de
bedömer på olika nivåer, projektrisker samt risker i utvecklingsfasen. Riskanalysen kan sedan
göras om med hjälp av alla andra, att man utvärderar de, det kanske har uppstått nån ny risk
eller nån risk kanske har försvunnit eller ändrats i sannolikhetsgrad.
Testaren förklarar vidare att även projektrisker kan genomföras som har egentligen med vad
risken är för att leveransen inte kommer ske i tid samt vilka faktorer som kan påverka det.
Utifrån en testares synvinkel så vill man även ha ett produktriskanalys som handlar om vad
skulle kunna gå fel i lösningen samt hur det påverkar kundens. Sen ska man göra en
riskbaserad testning utifrån den analysen för att försöka undvika att det händer när lösningen
väl har levererats.
Groscheck och Tejle (2002) samt Eriksson (2008) belyser vikten av spårbarhets aktiviteten
under dokumentation, eftersom att man ska kunna spåra var ändringarna kommer ifrån.
Testaren anser att spårbarhet ska finnas genom att kraven är numrerade, att de har nån form av
ID, det är då själva nyckeln till att man kopplar själva krav ID till testfallen och till
buggrapporterna.
Lösningsarkitekt 1 förklarar att kraven översätts i tasks eller arbetspaket och därifrån så brukar
det oftast finnas spårbarhet mellan testfall och felrapporter. Strategen förklarar precis som
lösningsarkitekt 1 att kraven omvandlas till utvecklingsaktiviteter i jira det stödsystemet som
de använder. Där finns alla Aktiviteter som ska realisera kraven samt att det då är väldigt
sällan det finns en skriven koppling där, däremot om man tar de och så tittar på kravunderlaget
så ser man vilken aktivitet som matchar emot kraven. Genom spårbarhet så ska man enligt
Groscheck och Tejle (2002) samt Eriksson (2008) kunna se konsekvenser av ändringar, samt
ifall att en ändring var felaktig så finns möjligheten att återgå till den tidigare versionen.
Eriksson (2008) anser att prioritering syftar till att utvärdera de krav som samlats under
insamlings-fasen för att se vilka krav som förbinds med störst risker kontra ger mest värde för
pengarna. Samtliga respondenter anser att prioritering och validering av krav ligger på
projektledaren och strateg i samband med kunden. Lösningsarkitekt 1 förtydligar att
prioritering och validering görs tillsammans med kunden i bästa världar. Vidare förklarar han
att i många fall i mindre projekt så är det oftast projektledaren som gör det direkt. Om det är de
på Ninetech själva som skriver kravspecifikationen så använder de oftast MoSCoW osv men
han anser att den beskrivningen inte är så levande. oftast är det ju en löpande diskussion med
kunden, det beror på vilken fas man är i. I kravfasen så är det definitivt att det görs med
kunden.
För att kunna bestämma vilka krav som ska implementeras först så är prioritering viktigt,
eftersom genom kravprioritering så kan man både leverera affärsnytta så tidigt som möjligt
samt implementera de krav som har hög prioritering först (Paetsch, Eberlein & Maurer 2003).
Strategen förklarar att prioritering och validering av krav görs i diskussion med kund utifrån
32
deras affärsperspektiv. Han förklarar ytterligare att det blir en mix av vilka saker som tekniskt
är bäst att de realiseras tillsammans, t.ex. att kunden kan tjäna väldigt mycket på att
implementera vissa krav samtidigt samt att det blir effektivare om de gör två eller tre av
kraven tillsammans.
Mattson och Lööw (2012) anser att kravledning bör innehålla en beskrivning av hur
godkännandeprocess för krav ska gå till. Lösningsarkitekt 1 och strategen förklarar att vid
godkännandeprocess för krav så gäller det att dokumentera kraven, sammanställa de i nån typ
av form oftast i dokument form, skickar de till kunden och säger att de ska kolla, om deras
behov och krav har dokumenterats korrekt detta genom att kunden får ett offertsvar eller ett
lösningsförslag från Ninetech som kunden ska godkänna eller inte.
Ändringshantering av krav tidigt i fasen är välkommet enligt både lösningsarkitekt 1 och
strategen. Lösningsarkitekt1 förklarar att tillsdess att ett lösningsförslag är gjort så är ju inte
kraven skrivna i sten så då kan man ändra på de i dialog. Tillskillnad av det som
lösningsarkitekt 1 och strategen förklarade om ändringshantering så anser Alexander och
Stevens (2003) 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 samt att ändringar uppkommer
dessvärre alltid i ett projekt och måste därmed hanteras på ett strukturellt sätt (Alexander &
Stevens 2003). Tonnqvist (2012) stärker projektledarensroll vid ändringshantering och anser
att denne bör se till att dokument för ändringen finns. Strategen anser att när det gäller
ändringshantering så ligger kraven som grund för nån typ av offert som de har lämnat på
jobbet de ska göra på projektet och då är det projektledarna som hanterar den. Kommer det in
nånting som inte fanns i ursprungskraven så är det projektledarnas ansvar att lyfta den med
kunden och säga det har tillkommit eller om det är krav som har ändrats väsentligt på nåt sätt
så är det projektledarens ansvar också och lyfta det. Projektledaren ska även säkerställa att
dokumentationen inte innehåller några kommunikationsproblem samt att kraven är av hög
kvalité (Eriksson 2008).
4.1.2 Kravutveckling
Sommerville (2007) förklarar att kravutveckling handlar om hur kraven ska prioriteras samt
specificeras. Testaren förklarar att de precis börjat jobba enligt PRINCE2 projektmetodiken
anpassat efter varje projekt. Lösningsarkitekt 1 förklarar att enligt Ninetechs
utvecklingsmodell så har de en mall för hur kravutvecklingen ska ske så det är den som de
följer, men där använder man skall krav, bör krav osv vilket är en av prioriterings
värdeskalorna som Eriksson (2008) nämner. Prioritering av kraven stäms sedan den av med
kund så att kunden kan verifiera att den stämmer överens med det de har pratat om och gärna
tillsammans med någon till så att man är fler än en som kan verifiera det jobbet för att kunna
få en kvalitetssäkring enlig lösningsarkitekt 2. Lösningsarkitekt 2 anser vid kravutveckling att
användningsfall är en bra metod att använda sig av. Att man egentligen försöker definiera
vilka roller och andra system som ingår i lösningen. Eriksson (2008) förklarar att
användningsfall innehåller illustrationer av hur användare interagerar med ett system.
Enligt Lind (2001) så handlar verksamhetsanalys om att få en överblick över verksamheten.
Strategen samt lösningsarkitekt 1 & 2 belyser att verksamhetsanalys görs via en mix av
workshops och arbetsmöten tillsammans med kund. När de gör det som bäst så gör de det
tillsammans 2–3 personer och då är det oftast projektledare, lösningsarkitekt och digital
strateg, oftast droppar projektledaren bort. I slutändan så är det arkitekten och digital strategen
som gör jobbet samt att de eventuellt även några utvecklare med specialist vana som ibland är
med som kommer in i den processen.
33
Strategen samt lösningsarkitekt 1 & 2 förklarar vidare att en verksamhetsanalys börjar oftast
med en eller två gemensamma workshoppar tillsammans med kunden, där man börjar går
igenom alla bitarna verksamhetsmässigt och sen utifrån det så hittar de ett antal områden som
de behöver fördjupa sig i och då gör de det oftast i form av gemensamma arbetsmöten med
kunden. Lind (2001) anser att det kan vara svårt att få en överblick över en verksamhet och att
det därmed är viktigt att en prioritering måste göras för att kunna komma fram till vilka delar
av verksamheten som ska analyseras kontra vilka som ska bortses ifrån. Lösningsarkitekt 2
tillägger att de träffar kunden och så många intressenter som möjligt och ber de förklarar vad
de behöver ha hjälp med, hur deras problemställning ser ut.
Det finns ingen metod som är bäst lämpad i alla situationer för att använda sig av insamling av
krav. Svagheter i en metod kan vägas upp genom att använda en annan metod som
komplement. (Yousuf & Asger 2015). Strategen klarlägger att de insamlingstekniker som
används kan antingen vara workshops, arbetsmöten och/eller intervjuer med folk och så blir
det en kravbild i slutändan. Under workshops form t.ex. så används metoder som effekt
kartläggningar vilket är en metod som används för att prioritera krav, business modell används
också för att få kunden och komma fram till sitt behov. Detta intygas av Sommerville (2010)
som nämner självklara insamlingstekniker såsom intervjuer, enkäter, observationer, workshops
osv.
4.1.3 Uppföljning och dokumentation av kravarbetet
Samtliga respondenter förklarade att kraven dokumenteras antingen i en Excel eller Word
dokument som sedan överförs in i jira. De förklarar vidare att den som har till uppgift att
dokumentera kravarbetet är den person som leder jobbet t.ex. projektledaren. Strategen samt
lösningsarkitekterna förklarar att antingen så är det strategen eller lösningsarkitekten som
dokumenterar kravarbetet, ibland kan det även vara en projektledare som gör det men då har
den projektledaren egentligen strateg eller lösningsarkitekt rollen just i det jobbet. Uppföljning
och dokumentation av kravarbetet innefattar hur kravarbetet ska dokumenteras, vilka mallar
och verktyg som används på verksamheten (Mattson & Lööw 2012).
4.2 Behovsanalys
Eriksson (2008) förtydligar att olika intressenter kan ställa olika typer av krav på systemet.
Strategen förklarar att de använder sig av intressenter vid behovsanalys samt att de har ganska
bra koll på vilka intressenter det finns, dessutom använder de intressenterna för att samla in
krav dock så förklarade han att de inte har så stor spårbarhet angående vilken intressentgrupp
som vissa krav kommer ifrån. Lösningsarkitekt 2 anser att de använder sig av intressenter
varken de vill eller inte då hans uppfattning av intressenter är alla är de som är med vid ett
första möte med kunden.
4.2.1 Kravplan
Kravplan handlar enligt Eriksson (2013) om att förklara i detalj hur kravhantering ska utföras i
en viss situation. När det gäller en kravstrategi på Ninetech så anser alla respondenter att det är
en fördel om den finns eftersom det skulle leda till att kravarbetet skulle göras mer lika och att
de som kanske inte är så fullt så seniora skulle ha lättare att komma in och göra bättre krav
jobb. För varje projekt uppstart så gäller det att ta fram en kravplan som kompletterar
kravstrategin just för det specifika projektet. Kravstrategi är en beskrivning på generell nivå
som förklarar vem som gör vad, hur, när och varför, medans en kravplan är mer detaljerad och
beskriver bara en situation (Eriksson 2013). Ännu en fördel är att det är lättare om man har en
uttalad strategi för hur man ska gå tillväga för då är det lättare att planera inför ett projekt
tillskillnad från om man bara hittar på nåt så är det lättare att missa nåt.
34
Lösningsarkitekt 1 anser att det inte är någon skillnad på kravplanen mot resten av projektet
egentligen det är ju bara en annan fas av projektet så den planeras ju precis som alla andra
delar av ett projekt med resurser, tid osv men skillnaden är att tyngdpunkten vad gäller
kundens närvaro är ju oftast högre här så det kräver ju mera att man ordentligt stämmer av
med kunden så att de har resurser tillgängliga.
4.2.2 Identifiera samt Prioritering av intressenter
Strategen klargör att identifiering av vilka intressenter som ska användas vid insamling av
behov är genom den första verksamhetsanalysen, de första workshopparna som man kör
tillsammans med kunden det är de som visar på vilka intressenter det är som finns sen om man
måste välja bland de så blir det ju inte så för man är ganska klar på vad det är för behov som
finns som ska lösas och då finns det en grupp intressenter runtomkring det och då är det de
som ska med in i arbetet. Ferrary (2009) konstaterar att det finns 3 punkter som ett företag bör
hålla i åtanke gällande intressenter, alltså att veta vilka intressenterna är, vad intressenterna vill
ha samt hur intressenterna kommer försöka att nå dit. Lösningsarkitekt 1 & 2 förklarar att det
är upp till kunden att bestämma vilka intressenterna är eftersom kunden vet vilka som finns.
Olika intressenter kan ställa olika typer av krav på systemet, exempel på intressenter kan vara:
användare, myndigheter, IT-arkitekt, IT-ledning, testare, utvecklare driftorganisation samt
andra system (Eriksson 2008).
Testaren belyser att det är lätt att välja de som alltid är framme och hörs samt syns mest men
man kanske ska kolla med personalchefer vilka som finns där också som inte hörs och syns
mest men som antagligen har jättebra information att komma med. De anser hon är viktigare
än de som anser sig självskrivna. En bra kontakt med en bra personalchef kan vara en bra
början.
4.2.3 Insamling och bearbetning av intressenternas behov
Al-Rawas och Easterbrook (1996) belyser att det perfekta teamet består av intressenter från
alla olika delar av verksamheten, dock så är fallet oftast omöjligt att en sådan grupp
sammanställs. Strategen anser att ju högre upp i management kedjan man kommer så måste
man jobba med mer kreativa tekniker för att samla in behoven. Testaren anser att det kan vara
bra att vara flexibel nog och tänka att det kan behövas olika metoder när man upptäcker hur de
olika grupperna är.
Insamling av behov innebär att kommunikation med flera intressenter bör ske genom att den
som samlar in behov kontinuerligt interagera med de olika intressenterna (Hadar et. Al., 2014).
Lösningsarkitekt 2 anser att man omöjligtvis kan ha workshop med mer än 25 personer
eftersom det blir jobbigt samt att samtliga deltagare inte blir hörda. Om det är alltför många
intressenter och alla inte kan vara med på workshopen så kan det leda till att kunden väljer de
som ska vara med på workshopen för att sedan intervjua de resterande en och en eller i mindre
grupper enligt lösningsarkitekt 2.
Bearbetning av intressenternas behov ska göras efter att de har samlats in. Mattson (2014)
belyser att bearbetning av behoven innebär att skapa en sammanställning av behoven så att de
är förståeligt för alla involverade samt att de ska förstå vad det är som kommer att behöva
göras. Strategen förklarar att det i grund och botten är lösningsarkitekterna och utvecklarna
som jobbar med kraven och behoven, anledningen till att det görs just av de rollerna är för att
kunna bygga lösningsförslag och även tidsuppskattningar som de jobbar väldigt mycket med
utifrån kraven och väldigt stor av det ansvaret ligger till stor del på lösningsarkitekterna.
Lösningsarkitekten förklarar att de insamlade behoven sammanfattas i nån form av krav form,
samt att det sedan måste stämmas av med beställaren för att försäkra sig att kraven är
relevanta.
35
4.3 Kravhantering Sommerville och Sawyer (2004) belyser att behov ofta förväxlas med krav, behov handlar om
något som någon kan använda samt att ett krav beskriver vad något ska uppfylla samt indirekt
vad det inte ska uppfylla. Strategen förklarar att de bygger hela jobbet runtomkring det behov
som finns, alltså att först ha en behovsanalys som sen resulterar i en mängd med krav då
fortsätter det precis igenom hela projektet för Ninetech vilket enligt honom gör att de slutar
aldrig någonsin med att samla in kraven.
Sommerville och Sawyer (2004) anser att kravhantering täcker in alla aktiviteter som handlar
om att hitta, dokumentera samt underhålla krav för ett IT-system. Detta intygas av
lösningsarkitekt 2 som anser att i kravhantering så ingår det kravinsamling, kravanalys och
kravdokumentation som är de då tre viktigaste huvuddelarna men som även innehåller
underdelar.
Lösningsarkitekt 1, strategen samt testaren anser att det vore jättebra ifall testare är med och
granskar kraven ifrån början. Testaren anser att man definitivt måste granska och se om de är
testbara ofta blir ju kraven lite för luddiga att det kan se bra ut men sen när de hamnar på
testaren så vet man egentligen inte vad kraven säger. Detta bekräftas av Eriksson (2008) som
anser att testaren bör granska kraven för att hitta eventuella oklarheter samt säkerställa att
kraven är testbara.
Lösningsarkitekt 2 anser däremot att testaren inte behöver granska kraven vid kravanalys-
fasen då han tycker att lösningsarkitekterna eller strategen kan fastslå om kraven är
mätbara/testbara dock anser han att granskningen kan ske när testplan ska tas fram. När
granskningen ska genomföras så är det enligt lösningsarkitekt 2 inte bara testaren som ska gå
igenom kraven utan alla involverade ska granska de tillsammans. Eriksson (2008) belyser
granskningsprocessen som en effektiv metod att använda sig av för att kvalitetssäkra kraven
genom att en grupp bestående av olika roller tillsammans går igenom dokumenten för att hitta
fel samt reda ut eventuella oklarheter.
För att kunna bestämma vilka krav som ska implementeras först så är prioritering viktigt,
eftersom genom kravprioritering så kan man både leverera affärsnytta så tidigt som möjligt
samt implementera de krav som har hög prioritering först (Paetsch, Eberlein & Maurer 2003).
Eriksson (2008) anser att under prioriterings aktiviteten så är syftet att utvärdera de krav som
samlats under insamlings-fasen för att se vilka krav som förbinds med störst risker kontra ger
mest värde för pengarna. Strategen belyser att prioritering av kraven är olika från projekt till
projekt. De projekten som går bra har de prioriterat genom hela projektet, de projekt som går
dåligt prioriterats det bara i början enligt Strategen. Men han anser att det bör prioriteras
genom hela projektet. Paetsch, Eberlein och Maurer (2003) förklarar de att det är viktigt att
prioriteringen hålls uppdaterad under hela utvecklingsprocessen och att det inte är en process
som bara sker i början.
Lösningsarkitekt 2förklarar att prioritering av krav oftast inte sker genom hela projektet. Han
anser att om man kör enligt MoSCoW metoden, då är det att vissa krav är måste-krav och de
måste med. Om ett enda krav av måste-kraven inte är uppfyllt då anser han att de inte uppfyllt
leveransen. Eriksson (2008) bekräftar detta då han anser att måste-kraven måste uppfyllas för
att projektet ska räknas som ett lyckat projekt. Strategen anser att det är kundernas affärsnytta i
kombination av kostnaden för att implementera det och effektivitet för att göra vissa krav
tillsammans, det är de tre parametrarna som finns för en prioritering. Kunden vet vad de vill ha
och kunderna kan med hjälp av ansvariga på Ninetech prioritera sina krav utifrån det de tjänar
mest pengar på att göra först.
Lösningsarkitekt 2 belyser att på Ninetech så är MoSCoW metoden den enda uttalade
prioriteringstekniken. Han förklarar att det även finns de som använder sig av skall,
36
bör metoden. Paetsch, Eberlein och Maurer (2003) anger att man kan använda sig av
värdeskalor vid prioritering, t.ex. hög, medel-, och lågprioritet eller skall/bör prioriteras.
4.3.1 Insamling
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 insamlade krav 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. Lösningsarkitekt 1
anser att det är viktigt att alla förstår kraven på samma sätt, hur pass andra förstår kraven har
med kommunikation att göra, att den som har hand om att förmedla kraven kan kommunicera
de kraven till andra.
Testaren granskar kraven genom att tänka mycket på språket, om det går att förstå vad som är
dokumenterat, finns det några motsägelser till och börja med, är kraven testbara verkar de
rimliga, är de superdetaljerade eller jättesvävande. Eriksson (2008) belyser att en testares
uppgift är att säkerställa att kraven går att testas samt att kravdokumentet är förståeligt.
Samtliga respondenter anser att behovskraven oftast översätts under insamlings-fasen till
systemkrav. Strategen förklarar att det är väl det på nåt sätt och viss som sker när utvecklare
och lösningsarkitekter tar kravbilden och faktiskt bygger upp projektet och strukturen i jira då
blir det ju översatt mer eller mindre till aktiviteter och systemkrav.
4.3.2 Analys och förhandling
I syfte att sortera och analysera de krav som framkommit under insamlingsfasen så genomförs
analysering och förhandling av krav (Kotonya & Sommerville 2003). Vidare belyser de att
genom att sortera samt analysera kraven så leder det till att kraven som känns mest angelägna
prioriteras. Strategen anser att om man får en lump med krav så går det inte att jobba med de
då eftersom att det alltid kommer att gå dåligt. Strategen att utan kunskap om kunden, kundens
organisation eller vetskap om deras verksamhet, hur de tjänar deras pengar, så ska de sätta sig
och titta på en Excel fil med krav och försöka göra nånting, det enda man kan göra det är att
titta på kravet och anta vad tror att de menar med kraven. Med 100% sannolikhet så får kunden
en lösning i slutet som de inte vill ha som dessutom inte är så bra. Detta kan undvikas enligt
Sommerville & Sawyer (2004) genom att ha en förhandling av kraven där intressenterna får
kompromissa vilket bidrar till att alla involverade blir nöjda. Att analyser kraven innebär att
granska kraven. Lösningsarkitekt 1 belyser att kraven analyseras i samband med att ett
lösningsförslag tas fram. Lösningsarkitekt 2 anser att analys och förhandling av krav påbörjas
med att man först sätter sig själv för att göra den första gallringen, hitta dubbletter detta
bekräftas av Sommerville och Sawyer (2004) som anger att analys av kraven syftar till att se
överlappningar, utelämningar, konflikter samt inre motsägelser. Lösningsarkitekt 2 förklarar
att man inte bör gå in i dokumentet och stryker krav själv men däremot så identifierar man de
så när man sätter sig med kunden så kan man ställa frågor om oklarheterna som uppstod vid
analysen. Eriksson (2008) nämner detta där han förklarar att när kraven granskas av en grupp
bestående av olika roller som på nåt sätt har nån koppling till kraven att de tillsammans går
igenom kraven för att hitta fel samt reda ut eventuella oklarheter. Analysen görs i två steg
enligt lösningsarkitekt 2, först själv och så sen med kund.
Groscheck och Tejle (2002) lägger stor vikt på spårbarhet aktiviteten eftersom de anser att
man ska kunna spåra var ändringarna kommer ifrån samt att kunna se konsekvenserna av
ändringar. Samtliga respondenter anser att en koppling mellan huvudsyftet, kravhantering samt
test är en självklarhet. Lösningsarkitekt 2 tillägger att man testar kraven för att se om de har
37
uppfyllts. Dock anser han att man får oftast gå via ett lösningsförslag för att kunna se hur man
ska uppfylla ett krav för att sedan testa den funktionen och säkerställa att kraven är uppfyllt.
Testaren anser att kopplingen mellan test och kravhantering kan genomföras genom att
testaren får vara delaktig i kravhanteringsprocessen för då är det mycket lättare att dels förstå
vad lösningen handlar om från början och direkt kunna planera testningen på ett
kontextbaserat sätt så det passar just den lösningen. Strategen anser precis som testaren att en
testare måste vara med från början för att förstå syftet, därigenom förstå vad kraven är för att
kunna utföra tester. Det ska finnas en tanke på när man definierar kraven att man faktiskt ska
kunna testa det också menar strategen.
4.4 Kravspecifikation
Wiktorin (2003) belyser att vid tillverkning av en kravspecifikation så bildar ett antal olika
aktiviteter en kravhanteringsprocess, genom denna process framställs en kravspecifikation.
Samtliga anser att kravspecifikation bara är en del av kravhanteringen samt att kunden ska ha
tillgång till kravspecifikationen efter att den är klar. Däremot så anser även samtliga att
kunden självt oftast inte har tillåtelse att göra ändringar i kravspecifikationen självt.
Sommerville (1998) beskriver kravdokumentet som ett dokument som innehåller det
utvecklarna ska implementera samt att kravdokumentet ska skrivas på en begriplig nivå för att
vara som stöd för alla verksamhetsaktörer. Enligt testaren så är de viktigaste uppgifterna som
ska finnas med i kravspecifikations-dokumentet följande; Krav ID, versionsnummer, datum
samt ändringshistorik.
4.4.1 Dokumentation & validering
Det som ska göras under validerings aktiviteten är att läsa dokumentet noga, hålla intervjuer
använda sig av checklistor, prototyper skriva scenarier och användningsfall. Nuseibeh och
Easterbrook (2000) förklarar att validera kraven kan vara en svår process eftersom olika
intressenter har motsägande mål med utvecklingen vilket kan resultera i konflikter.
Lösningsarkitekt 2 förklarar att på Ninetech så har de en egen mall för kravspecifikation där
kraven dokumenteras. Han anser att den är väldigt simple och lätt förståeligt då det bara är
lite tabeller där man uppmanas att gruppera kraven i först och främst två sektioner funktionella
och icke-funktionella krav. Därefter ska det ytterligare grupperas på vilken kategori kravet hör
hemma i t.ex. användarvänlighet, affärslogik, det kanske ska vara nån typ av transaktions
spårning, man sätter in det i logiska sektioner för att sedan avsluta med att använda sig av
MoSCoW metoden för att rangordna och även sätta ett nummer på alla krav. MoSCoW är en
prioriterings teknik som är en förkortning på de engelska orden, Must, Should, Could och
Won’t, på svenska översätts de till Måste, Borde, Kunde samt Inte (Eriksson 2008).
Lösningsarkitekt 1 tycker att i de bästa världar så dokumenteras kraven i en kravspecifikation
med tillhörande testfall, för att verifiera de så har de manuella testprotokoll där de går igenom
att kraven är uppfyllda, alternativ om man inte har gjort en sån översättning i testfall under
kravanalysen. Då tar man fram acceptanstest eller testfall under senare fas som då kunden går
igenom för att verifiera efter att vi också har gjort det och i vissa fall gör kunden egna testfall.
Eriksson (2008) anser att kvalitetssäkring är en återkommande aktivitet som sker genom hela
utvecklingen och inte något som ska göras i slutet av utvecklingen.
Lösningsarkitekt 2 anger att vid dokumentation och validering av krav så är de viktigaste
rollerna kravinsamlaren från Ninetech först och främst, sen är det lösningsarkitekt, strateg
samt så bollar de den sedan med kunden. Men han skulle säga att de tar fram dokumentet och
kommer fram med ett förslag och så sen så skickar de det till kunden eller sätter sig med
kunden går igenom den, eventuellt få lite synpunkter och så går man hem fixar det och sen är
det färdigt. Granskning är en effektiv metod att använda sig av kvalitetssäkring av kraven
(Eriksson 2008). Granskningsprocessen går ut på att en grupp bestående av olika roller som
38
tillsammans går igenom kravdokumenten för att hitta fel och reda ut eventuella oklarheter.
Rollerna i gruppen kan bestå av kravställaren, testaren, systemutvecklare/IT-arkitekt,
användarrepresentant samt projektledare eller systemägare (Eriksson 2008). Kunden är ju med
i dokumentationen i och med att man måste säkerställa alla krav med kunden att det här kravet
är rimligt och korrekt. Men det gör man mer i kravanalysen, så man ser det från kravanalysen
att denna analysen spottar ur sig korrekta krav liksom. Om man då ser det lite stelbent nästa
stege efter analysen som man har ju fått en hel hög med krav som är korrekta och analysera de
så att säga och bara få in det i dokumentet och sätta nummer på de och liksom sätta rätt
prioritering.
Det gör nog oftast Ninetech själva och sen tar det med kunden när det är gjort.
Strateg Hos Ninetech är de roller vi redan pratat om, hos kunden vi gör väl oftast så att vi helt
enkelt bara dumpar det på den kontakt personen som är hos kunden och så får faktiskt de
bemanna upp på det sätt de själva tycker är lämpligt. Däremot så tycker jag att det ör de
personer som har varit med hos kunden och jobbat fram kravbilden som också ska vara med
och validera den
Lösningsarkitekt 1 förklarar att dokumentation och validering är två olika saker vid frågan om
vilka roller som bör vara med vid dokumentation och validering av krav. För dokumentation
av krav så anser han att det oftast är en lösningsarkitekt eller en verksamhetskonsult samt att
en testare eller testledare bör vara med redan då för att skriva testfallen. För validering så anser
han att det nån form av testare och kunden som genomför de.
Strategen anser att bristen med dokumentering av kraven är att det är ju svårt o samla in det
dokumenterade krav. Strategen förklarar vidare att om man kan jobba lite mer enhetligt och
lite mer formellt med kravdelen, så skulle det underlätta för all involverade. Han anser att det
är väldigt svårt för utvecklarna framförallt och även lösningsarkitekter att kraven som kommer
in är på så otroligt olika nivå. Det är olika nivå på kraven som går in i projekten så det kan
vara en och samma utvecklare som övertydligt jobbar med tre olika projekt och tre helt olika
förutsättningar liksom och lyckas med och göra det som de ska göra. En större enhetlighet tror
jag liksom skulle gynna oss och brista blir ju då att men är det en person som inte är lika
duktig på att definiera, dokumentera samt uttrycka krav då blir det sämre kvalité på de och då
blir det bristen
Lösningsarkitekt 1 anser att det är jättevanligt att man misstolkar varann eller att man
översätter i text till nånting som inte riktigt så man inte får ner det i text till det som man
egentligen hade tänkt. Det är därför det är så viktig att man återkopplar och man går igenom
kraven så att man menar att båda har förstått vad den andra menade och att de som är
nedskrivet på bästa sätt återspeglar de som man menar
Genom att man stämmer av de ordentligt. Skriver ner de läst igenom de. Processen är
komplext på så sätt att man försöker beskriva ett krav på flera sätt, så ingenting missas där.
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. Strategen anser att det
viktigaste med funktionella krav är att de dokumenteras, samt att det är ännu bättre om de
dokumenteras i det sammanhang de ska användas. Alltså stuket som user-stories får, det
behöver dock inte vara dokumenterad via user storie, men det är bra att veta för vem man gör
kravet och vad det är som är viktigt på det. 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 2009).
39
Sommerville (1998) beskriver kravdokumentet som ett dokument som innehåller det
utvecklarna ska implementera samt att kravdokumentet ska skrivas på en begriplig nivå för att
vara som stöd för alla verksamhetsaktörer. Lösningsarkitekt 1 förklarar att funktionella krav
ska dokumenteras i kravspecifikationen i ett eget kapitel, nedbrutet på skall krav, bör krav osv,
gärna med exempel om det är tillämpbart.
Testaren klarlägger att om det är en större lösning med kanske fler än 20 krav eller så då
underlättar det ju ganska mycket om man grupperar kraven även funktionellt, mest
grundläggande är om man ska ha ett användargränssnitt och ett admingränssnitt. Då är de två
indelningar. Sommerville (1998) anser därmed att kravdokumentet kan vara mer begriplig om
det finns diagram modellerade som överensstämmer med dokumentets innehåll.
Brister vid dokumentation av funktionella krav är jättevanligt, t.ex. att man missar saker är det
vanligaste enligt lösningsarkitekt 1. Att man inte uttrycker sig tillräckligt bra så att alla
intressenter riktigt förstår vad man menar snarare att de olika intressenterna tolkar det som
olika saker är jättevanligt. Därför är det superviktig att man har en dialog kring det och inte
bara läser/löser. Annars uppkommer det i slutet av projektet att det var inte alls det som
kunden ville ha.
Sommerville och Sawyer (2004) förklarar att kvalitetssäkring handlar om att säkerställa sig att
kraven följer de kvalitetsstandard som är satt. De anser att kraven som är dokumenterade
måste valideras för att hitta krav som missats, eventuella konflikter mellan krav och/eller
otydliga krav Testaren anser att dokumentationen av kraven kan bli mycket bättre eftersom
hon skulle vilja lita på kravdokumentet som hon får i handen, om det nu inte är meningen att
hon ska vara med under kravhanteringen. Testaren förklarar att de brister som förekommer vid
dokumentation av funktionella krav kan undvikas genom att ha folk som har rollen ”krav”,
man kanske inte behöver jobba enbart med krav men man behöver ha det på folk att de jobbar
med krav.
Enligt lösningsarkitekt 2 så är de vanligt förkommande med brister vid dokumentation av
funktionella samt icke-funktionella krav men att det är väldigt lätt att missa nåt område särskilt
vid dokumentation av icke-funktionella krav. Sommerville och Sawyer (2004) anser därmed
att när kvalitetssäkring genomförs så är det rekommenderat att alla intressenter som var med
vid insamling av krav att vara med för att eventuellt förtydliga oklarheter.
Icke-funktionella krav
Icke-funktionella krav handlar om hur systemet ska fungera samt vilka valmöjligheter det
finns till att använda systemet (Dennis, Wixom & Roth 2010). Samtliga respondenter anser att
de icke-funktionella kraven ska dokumenteras på samma sätt som de funktionella kraven samt
att de mest vanliga bristerna med icke-funktionella kraven är att de oftast är otydligt
definierade och att de som skriver de oftast tar lite för lätt på de.
Lösningsarkitekt 1 förklarar att de icke-funktionella kraven gärna kan dokumenteras med
exempel samt att det är ännu viktigare med exempel eller mätbara mått om det är möjligt så
det inte är nåt flummigt som man kan tolka hur man vill, eller att olika personer tolkar på olika
sätt. Chung och Nixon (2000) anser att icke-funktionella krav kan vara hur
användargränssnittet ska se ut eller hur många användare som ska använda systemet.
Testaren anser att de icke-funktionella kraven behöver ofta specificeras mycket mer än de
funktionella kraven, icke-funktionella krav kan handla om lite prestanda eller att lösningen ska
fungera på både mobila plattformar och pc osv. Testaren anser bristerna kan undvikas genom
att man blir mer medveten om att en lösning inte bara är ett gäng funktioner utan att en lösning
ska vara svaret på ett problem som kunden har.
40
Strategen anser att bristerna med de icke-funktionella kraven beror på den/de personen som
gör jobbet. Kvalitén på kraven beror helt och hållet hur de som samlar in kraven gör
insamlingen. Han tycker däremot att det hade hjälpt att ha en tydligare metod på hur de ska
göra det. I och med att det på Ninetech görs på olika sätt beroende på vem som gör det så blir
det väldigt spretigt.
4.4.4 Övrig dokumentation
Eriksson (2008) anser att kravdokumentation kan dokumenteras genom användningsfall,
användarberättelser eller kravspecifikationer eller genom en kombination av teknikerna. När
det kommer till övriga dokumentation vad gäller krav så anser lösningsarkitekt 2 att när det
kommer till kravhanteringen så räcker det med en kravspecifikation. Från själva kravdelen så
anser han att när man fått fram en kravspecifikation så är de nöjda. Kravspecifikationen för
med sig en massa dokument och att man utifrån den gör ett lösningsförslag, utifrån det gör
man ett estimat och i samband med det gör man en riskbedömning osv.
Kravspecifikationen hänger enligt strategen väldigt mycket ihop med lösningsförslaget, i
mångt och mycket så blir lösningsförslaget det som gör det tydligt för kunden att Ninetech har
uppfattat deras uppgift korrekt. Han klargör dock det att lösningsförslaget inte är en del av
kravinsamlingen och kravhanteringen egentligen, men för Ninetech så hänger de bitarna ihop.
Lösningsarkitekt 1 anser att när det kommer till vilka övriga dokument som ska finnas
tillsammans med kravspecifikationen så beror det på, men han anser att det är bra om det finns
en testplan och ett testfallsdokument även om det kanske inte är jättenoggrann. Han förklarar
vidare att testfallen beskriver mer noggrant hur man ska testa. Men testfall på en högre nivå
utifrån kraven är ju jättebra, det är ju en del av kommunikation samt gör att intressenterna kan
förstå och vara överens om att det är samma sak man menar på samma sätt än om man bara
beskriver i text. 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.
.
41
5 SLUTDISKUSSION I detta kapitel redogörs resultat utifrån syftet från uppsatsen. Inledningsvis presenteras mina
slutsatser baserad på analysen som genomförts. Avslutningsvis presenteras en modifiering av
analysmodellen, fortsatta studier samt brister som upptäckts med uppsatsen
5.1 Slutsatser
Syftet med denna C-uppsats är att kartlägga 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.
Behov och förstudiefasen är de två första faserna inom ett projekt, eftersom denna studies
fokus ligger på framtagning av krav så ska fokus ligga på de faser där kravhantering
genomförs. Studien började med att jag skulle ta fram en kravfångstmetod för Ninetech. Efter
all litteraturundersökning samt empiri insamling så ansåg jag att syftet skulle riktas in på att ta
fram en metod för både behov och kravhantering. Det är viktigt att man genomför båda faserna
ytterst noga.
Min största överraskning vid intervju av respondenterna var att utifrån allt jag frågade de
under intervjun så fanns det tillfällen då svaren var snarlika men det fanns även frågor där
svaren var otroligt olika. Ytterligare en sak som överraskade mig var hur ett begrepp kunde
betyda två helt olika saker beroende på vem man frågade. Jag anser att det är viktigt i
verksamheten att ett begrepp ska ha samma betydelse för alla, en teknik/metod ska användas
på samma sätt oberoende på vem som gör det. Det som jag anser vara allra viktigast är
dokumentation, t.ex. vid testarens fall så anser jag att om de inte är med vid behov och
kravinsamlingen att de ska ha kompletta dokument så att de inte behöver ifrågasätta hela
dokumentets innehåll på grund av att de får veta att det är några krav som inte längre är
aktuella eller att dokumenteringen sker på flera olika sätt för en och samma projekt.
Kravstrategi Efter mina intervjuer med samtliga respondenter på Ninetech insåg jag att mestadels av jobben
utfördes genom erfarenhet. Att använda sig av erfarenhet anser jag är väldigt bra då alla lär sig
med tiden men tyvär så leder det till att ifall det skulle komma in nya människorna när ett
projekt redan startats så leder det till att de inte kommer att hänga med eftersom att
dokumentation saknas eller även om det finns så är de så utspridda att det är svårt att veta var
man ska börja läsa för att komma ikapp. Slutsatsen jag drar angående kravstrategi är att den
ska finnas till för att verka som ett stöd samt att det är en avlastning till kravplanen som är
unik för varje projekt. Samtliga respondenter var väldigt positivt inställda till en kravstrategi
då de anser att det kommer att underlätta arbetet genom att arbeten kommer att se likadana ut.
Kravplan
Respondenterna förklarade att de vill ha struktur i hur arbete/projekt genomförs på Ninetech.
En kravplan inom ett projekt underlättar för alla involverade eftersom att det förklarar i detalj
hur kravhanteringen ska genomföras samt vilka roller som ska vara med. Kravplanen avser att
belysa i det specifika projektet vad som har gjorts samt när det har gjorts. En kravplan är unikt
för varje projekt. Utifrån analysen samt den empiriska undersökningen kan jag dra slutsatsen
att en kravplan är en absolut fördel att ta fram vid varje projekt eftersom kravplanen hjälper
alla att hålla sig uppdaterade om projektet. Alla vet vilken metod som kommer att användas
för behov- och kravhantering, vilken prioriteringsteknik som kommer att användas, hur
dokumentation av arbetet kommer att dokumenteras. Utifall någon roll faller bort eller att
42
någon ny kommer in i projekt så kan de lätt hålla sig uppdaterad och komma ikapp alla andra
genom att ta en titt på kravplanen.
Behovsanalys
Utifrån min studie så kan jag dra slutsatsen att en behovsanalys är en grundläggande
förutsättning för ett framgångsrikt resultat. Att hoppa över behovsanalysen för att direkt börja
med förstudien är inte att rekommenderas eftersom att de flesta projekt som anses vara
misslyckade är just de projekt som hoppat över behovsanalysen. Att inte utföra en
behovsanalys innan en förstudie leder till att ett projekt startas på fel antaganden på grund av
att det faktiska behovet inte har undersökts noggrant. Projekt som inte utför behovsanalys, kan
definitivt uppnå de tilltänkta målen, men om de målen inte är vad som efterfrågades så leder
det till slut att systemet/projektresultatet inte används.
Ännu en slutsats som jag kan dra utifrån studierna är vikten av att involvera en testare så tidigt
som möjligt i processen. Det är viktigt att försäkra sig om att behoven som översätts till krav
är testbara, för om ett krav inte är testbart så innebär det att det inte är uppfyllt.
5.2 Fortsatta Studier
En brist med C-uppsatsen är att det endast intervjuats representanter från leverantörens sida.
Fortsatta studier utifrån denna uppsatsstudie kan genomföras genom att intervjua
kunder/beställare för att få en uppfattning om deras syn på hur behovs- och kravhanteringen
genomförs. Ytterligare en rekommendation för fortsatta studier är att undersöka hur
kommunikationen bibehållas under hela utvecklingsarbetet mellan alla olika roller.
5.3 Modifiering av analysmodellen
Modellen har modifierats enligt följande utifrån den empiriska undersökningen:
❖ Den mellersta delen i figur 2 vars begrepp var kravhantering har bytts ut till
kravelicitering. Begreppet har ändrats efter att jag visat analysmodellen till
respondenterna så konstaterade en respondent att behovsanalys, kravelicitering samt
kravdokumentation är aktiviteter som sker under kravhanteringen.
Ramen som omringar behovsanalys, kravelicitering samt kravdokumentation blev
tillagd för att påvisa att de tre aktiviteterna tillsammans utgör kravhantering.
Figur 3: Föreslagen modifierad analysmodell över en metod för behovs- och kravhantering
Källa: Författaren
43
44
KÄLLFÖRTECKNING
Skriftliga källor
Andersen, E. S., Grude, K. V. & Haug, T. 1994: Målinriktad projektstyrning. Lund:
Studentlitteratur.
Arvidson, K. Engvall, K. Süld, K. (2006) Riskanalys och handlingsplan för krishantering på
bibliotek
Asztalos, R. & Giertz, M. (2010). Organisatorisk kunskapshantering: En fallstudie hos
polisens verksamhetsstöd. KTH Industriell teknik och management.
Al-Rawes, Amer och Easterbrook, Steve (1996). Communication Problems In Requirements
Engineering: A field study, London.
Alvehus, J. (2013). Skriva uppsats med kvalitativ metod: En handbok. Stockholm: Liber AB.
Ahlin, A, Arnesson, K & Marcusson, L. (2011). Råd om projekt – Erfarenheter från
projektarbete och projektledning. Kalmar: Tento förlag.
Alvesson, M. & Söderberg, K. (2008). Tolkning och reflektion – vetenskapsfilosofi och
kvalitativ metod. 2. uppl., Lund: Studentlitteratur
Andersson, G. (2009) Kalkyler som beslutsunderlag. Lund: Studentlitteratur
Andersson, A. & Aderud. J (2014). Kravhantering - brister och lösningar. Örebro:
Handelshögskolan Informatik, Örebro Universitet.
Björklund, M., & Paulsson, U. (2003) Seminarieboken –att skriva, presentera och oppone1ra.
Lund: Studentlitteratur
Bryman, A., & Bell, E. (2013). Företagsekonomiska forskningsmetoder. Stockholm: Liber AB
Carlson, H., Nilsson, A. (2012), Arbeta i projekt: Verktygslåda för projektarbetare, Upplaga 1,
Bokförelaget komlitt, Helsingborg
Chung, L, Nixon B, Yu E, Mylopoulos, J (2000). Software Engineering. [Elektronisk].
Tillgänglig: http://www.utd.edu/~chung/RE/NFR-18-4-on-1.pdf [2017-05-16]
Christiansson, B. & Christiansson, M-T. (2006). Mötet mellan process och komponent: mot ett
ramverk för en verksamhetsnära kravspecifikation vid anskaffning av komponentbaserade
informationssystem. Linköpings universitet: Institutionen för datavetenskap, VITS -
Laboratoriet för verksamhetsinriktad systemutveckling. Linköpings universitet, Filosofiska
fakulteten
Computer Sweden (2014). Språkrådet. [Elektronisk]. Tillgänglig:
http://it-ord.idg.se/ord/vattenfallsmetoden/ [2017-05-02]
Denscombe. M (2014). Forskningshandboken: för småskaliga forskningsprojekt inom
samhällsvetenskaperna. Studentlitteratur AB, Lund.
Dennis, A., Wixom, B.H. & Roth, R.M. 2010, Systems analysis and design, Wiley, New York.
De Lucia, A., Qusef, A. (2010) Requirements Engineering in Agile Software Development.
Journal of Emerging Technologies in Web Intelligence, vol.2, no.3, ss. 212-220
45
Eklund, S. (2011), Arbeta i projekt - individen, gruppen, ledaren, Upplaga 4, Studentlitteratur,
lund
Eriksson, B. (2013). Ett arbetssätt för agil kravhantering. Kandidatuppsats i informatik.
Eriksson. U (2008). Kravhantering för IT-system. Studentlitteratur, Lund AB.
Escalona, M. J., & Koch, N. (2004). Requirements engineering for web applications-a
comparative study. Journal of Web Engineering, 2, 193-212.
Ferrary, M. (2009). A Stakeholder’s Perspective on Human Resource Management. Journal of
Business Ethics, 87(1), 31-43.
Gorschek T. & Tejle K. (2002) A Method for Assessing Requirements Engineering Process
Maturity in Software Projects. Blekinge Institute of Technology
Gustavsson, T (2013). Agil projektledning. Stockholm: Sanoma Utbildning
Görling. S (2009). Att arbeta med IT-projekt. Studentlitteratur AB, Lund
Hagberg, B., och Ljung, A. (2000). Projekt ar manniskor: Hur du driver framgangsrika projekt
genom att skapa goda relationer i projektgruppen (1. uppl. ed.). Uppsala: Konsultförl
Hauksdóttir,D. & Nielsen,P.E. (2014). Requirement Management Strategy. International
Journal of Machine Learning and Computing, Vol. 4, No. 3
Håkansson. L (2010). Handbok i Kungsbackas kommungemensamma projektmodell.
[Elektronisk]. Tillgänglig: https://www.kungsbacka.se/Global/Kommun
Jansson, T. och Ljung, L. (2004) Projektledningsmeodik, Lund: Studentlitteratur.
Järvensivu, T. and Törnroos, J.(2010)‖ Case study research with moderate constructionism:
Conceptualization and practical illustration‖, Journal of Industrial Marketing
Management,Vol.39.pp.100-108
Kotonya, G. & Sommerville, I. (2003) ” Requirements engineering - processes and
techniques”, Wiley.
Lind, M. (2001). Från system till process – kriterier för processbestämning vid
verksamhetsanalys.
Liu, J.Y.C. & Yuliani, A.R. (2016). Differences Between Clients' and Vendors' Perceptions of
IT Outsourcing Risks: Project Partnering as the Mitigation Approach. Project Management
Journal, 47 (1), 45-58.
Macheridis, Nikos(2005) Projektaspekter – kunskapsområden för ledning och styrning av
projekt Lind: studentlitteratur
Marttala, A., Karlsson, Å. (2011), Projektboken: metod och styrning för lyckade projekt,
Upplaga 3, Studentlitteratur AB, Lund
Mattson. C & Lööw.L (2012). Från kravstrategi till förvaltning av krav
Mattson. C (2014). Intressenternas behov ger kraven på IT-systemen
Miles, M.B. & Huberman, A.M. (1994). Qualitative data analysis: an expanded sourcebook.
Thousand Oaks, CA: Sage Publications
46
Naz, H., Khokhar, M.N. (2009) Critical Requirements Engineering Issues and their Solution.
2009 International Conference on Computer Modeling and Simulation, 218-222
Nordberg, K. (2008), Projekthandboken - planera, leda och värdera projekt, Upplaga 5,
Björnen, Borlänge
Nordström, M. & Welander, T. (2007), Mera Affärsmässig Förvaltningsstyrning,
Dataföreningen i Sverige, Stockholm.
Nuseibeh, B., Easterbrook, S. (2000) Requirements engineering: a roadmap. Proceedings of
the Conference on the Future of Software Engineering
Ottersten, I., och Berndtsson, J. (2002). Användbarhet i praktiken: praktiska handgrepp,
grundbegrepp och tankemodeller. Lund: Studentlitteratur
Ottersten, I., & Balic, M. (2010). Effektivitet av IT - Nyttan uppstår i användningen (2:1 ed.).
Malmö: Liber.
Paetsch, F., Eberlein, A. & Maurer, F. (2003). Requirements engineering and agile software
development. Proceedings of the Twelfth IEEE International Workshops on Enabling
Technologies: Infrastructure for Collaborative Enterprises (WETICE’03). Johannes Kepler
University of Linz, Austria. 9-11juni 2003, ss. 308-313.
Patel. R & Davidsson. B (2011). Forskningsmetodikens grunder: att planera, genomföra och
rapportera en undersökning. Författarna och studentlitteratur AB, Lund.
Pohl, K. & Rupp, C. (2011). Requirements Engineering Fundamental. Santa Barbara, CA:
Rocky Nook
Polit, D.F. & Beck, C.T. (2012). Nursing Research: Generating and Assessing Evidence for
Nursing Practice. Philadephia: Wolters Kluwer Health | Lippincott Williams & Wilkins.
Saiedian, H., Daleb, R. (2000). Requirements engineering: making the connection between the
software developer and customer. Information and Software Technology, vol. 42, no.6, ss.
419–428.
Soares, M. d. S., Vrancken, J., Verbraeck, A. (2011). User requirements modeling and analysis
of software-intensive systems. Journal of Systems and Software, vol. 84, no.2, ss. 328–339
Sommerville, I. (2011). Software engineering. (9. ed., International ed.) Harlow: Addison-
Wesley
Sommerville, I. och Sawyer, P. (1997). Requirements engineering: a good practice guide.
Chichester: Wiley
Tonnquist, Bo. (2014). Projektledning. 5. uppl. Stockholm: Sanoma Utbildning AB.
Vetenskapsrådet (2002). Forskningsetiska principer inom humanistisk-samhällsvetenskaplig
forskning. Stockholm: Vetenskapsrådet.
Wiegers, K. (2003) Software requirements, Redmond: Microsoft Press
Wiktorin, L. (2003). Systemutveckling på 2000-talet. Studentlitteratur.
Yousuf,M & Asger,M. "Comparison of Various Requirements Elicitation Techniques,"
International Journal of Computer Applications , vol. 116 (4), no. 0975- 8887, pp. 8-15, 2015.
Yin, R., K. (2014). Fallstudier: design och genomförande. Stockholm: Liber AB
47
Muntliga källor
Ninetech, Tina Lungström, Testare, Personlig intervju, 2017-05-08
Ninetech, Mattias Berglund, Strateg, Personlig intervju, 2017-05-01
Ninetech, Rickard Nilsson, Lösningsarkitekt & utvecklare, Personlig intervju, 2017-05-08
Ninetech, Anders Bergström, Lösningsarkitekt, Personlig intervju, 2017-05-12
48
BILAGOR BILAGA 1: INTERVJUGUIDE
Inledande frågor
- Vad heter du?
- Vilken roll har du på Ninetech?
- Hur länge har du jobbat på Ninetech?
- Vad har du för bakgrund?
- Hur ser en vanlig arbetsdag ut för dig?
o Beskriv dina arbetsuppgifter (huvudsysslor på Ninetech)
Kravstrategi - En kravstrategi är en beskrivning av hur kravarbetet ska bedrivas inom
program, projekt, förvaltningar och andra typer av uppdrag på ditt företag för att sätta
rätt ambitionsnivå
- Anser du att en kravstrategi underlättar kravarbetet för hur projekt bedrivs i Ninetech?
o Varför/varför inte?
- Hur underlättar kravstrategin ditt arbete som testare?
Kravledning – Med kravledning brukar man i en kravstrategi beskriva de arbetsuppgifter som
en kravledare, eller den som har planeringsansvar, ansvarar för.
- Hur sker planering av arbete/projekt i Ninetech?
- Hur genomförs riskanalys?
- Hur går ni på Ninetech tillväga med Spårbarhet mellan krav, testfall och felrapporter?
- Hur gå ni på Ninetech tillväga med prioritering och validering av krav?
- Hur går ni på Ninetech tillväga med Godkännandeprocess för krav?
- Hur går ni på Ninetech tillväga med Ändringshantering?
Kravutveckling – hur kravutvecklingen sker
- Hur ser Ninetechs kravprocess ut?
- Hur genomför ni på Ninetech verksamhetsanalys?
o Vilka områden bör en verksamhetsanalys göras på?
- Vilka insamlingstekniker finns?
o Hur väljer du vilka insamlingstekniker du använder dig av vid ett projekt?
- Hur utvecklar och detaljerar ni på Ninetech krav på olika nivåer?
Uppföljning och dokumentation av kravarbetet – hur man följer upp och dokumenterar
kravarbetet
- Hur dokumenterar ni på Ninetech kravarbetet?
o Vems uppgift är det att dokumentera kravarbetet?
▪ Varför?
- Vilka mallar/verktyg finns och används på Ninetech?
Behovsanalys - Syftet är att tydliggöra beställarens förväntningar och för dokumentation
av projektets bakgrund.
- Hur identifierar ni på Ninetech kundernas verksamhetsbehov?
- Använder ni er av intressenter?
o Varför/varför inte?
Kravplan – I det enskilda arbetet gör en kravplan som beskriver hur vi planerar att utföra
kravanalysen och med vilka resurser vi kommer att göra det.
- Om Ninetech har en fastställd kravstrategi, anser du att det underlättar kravplanen inför
ett projekt?
49
- Hur ser en kravplan ut hos Ninetech?
Identifiera + prioritera intressenter
- Hur anser du att identifiering av vilka intressenter som ska användas vid insamling av
behov ska identifieras?
o Är det viktig att intressenter prioritera
- Grupperas intressenterna i olika fokusgrupper?
Samla in + bearbeta intressenternas behov
- Används olika metoder för att samla in behov från olika intressent-grupper?
- Hur bearbetas de insamlade behoven hos Ninetech?
o Vilka roller hos Ninetech bearbetar de insamlade behoven?
Kravhantering
- Upplever du att behovsanalysen skulle vara ett underlag för kravhanteringsarbetet?
- Vilka processer anser du är ett måste att de är med under kravhanteringsfasen?
o Varför?
- Ska testare granska kraven?
o Varför?/Varför inte?
▪ Hur underlättas testarens arbete genom att de granskar kraven?
- Anser du att gruppering av krav underlättar testplaneringen?
o Hur då?
- Hur använder ni på Ninetech spårbarhet mellan krav och test
- Prioritering av kraven, Är det en process som pågår genom hela projektet?
o Vilka metoder används för att prioritera kraven?
▪ Varför?
▪ Vems uppgift är det att prioritera kraven?
• Varför?
Insamling – Förstå kundens egentliga behov
- Vad är viktigast enligt din roll att du gör vid denna fas?
- Vilka processer/metoder använder du för att samla in/granska krav?
- Översätts behovskraven till systemkrav under denna fas?
Analys och förhandling
- Hur analyserar ni på Ninetech de insamlade kraven?
- Anser du att huvudsyften, kravhantering och test ska kopplas ihop?
o Varför?/Varför inte?
▪ Hur ska kopplingen i så fall göras?
Kravspecifikation
- Vilka roller anser du ska vara med under kravspecifikations-fasen och varför?
- Anser du att kravspecifikations aktivitet är kravhantering eller bara en del av
kravhanteringen?
- Har kunden tillgång till kravspecifikationen?
o Har kunden tillåtelse att självt göra ändringar i kravspecifikationen?
- Hur sker ändringshanteringen utav kravspecifikationen?
- Vilka kolumner ska finnas på kravspecifikation-dokumentet?
Dokumentation & Validering
- Hur dokumenteras och valideras kraven hos Ninetech?
o Vilka roller både från Ninetech och Kundens sida, ska vara med vid
dokumentation och validering av krav?
- Vems uppgift är det att dokumentera och validera kraven?
50
- Vilka brister anser du uppkommer vid dokumentering och validering av kraven?
o Hur kan dessa undvikas?
Funktionella och icke-funktionella krav
- Hur ska funktionella och icke-funktionella krav dokumenteras enligt dig?
- Vilka brister anser du uppkommer vid dokumentering av funktionella och icke-
funktionella krav?
o Hur kan de nämnda bristerna undvikas?
Övrig dokumentation
- Vilka andra dokument ska finnas tillsammans med kravspecifikationen anser du?
o Varför?
o Vilken relation har dessa andra dokument till kravspecifikationen?
51
