Uppsala universitet
Institutionen för informatik och media
Rollens inverkan vid kravidentifiering
En jämförande studie om hur olika hierarkiska roller identifierar samt värderar krav på intranät
Christoffer Keisu Nelson Christensen
Kurs: Examensarbete Nivå: C
Termin: HT-18 Datum: 2019-01-11
Sammanfattning
I denna uppsats jämför vi genom en Design Science- ansats krav på ett intranät utifrån två olika hierarkiska rollers - chef kontra medarbetare - synvinklar. Artefakten jämförelsen grundar sig på är en kravspecifikation vi tog fram åt ett medelstort IT-företag. Vi jämför och analyserar kraven och försöker påvisa om någon av de två olika grupperna kan identifiera krav som den andra gruppen hade svårare att se, eller om någon grupp värderar vissa krav mer. Slutsatserna av arbetet är att chefer tenderar ha färre krav samt att de värderar krav högre som tillåter större kontroll av innehållet i ett intranät. Medarbetare har fler krav och värdesätter icke-arbetsrelaterad information på intranätet högre. Vad gäller de flesta krav håller chefer och medarbetare på det här företaget dock med varandra.
Nyckelord: Kravelicitering, hierarki, roller, kravspecifikation, informationssystem, intranät, volere, kravanalys
Innehållsförteckning
Innehållsförteckning 2
1. Inledning 4
1.1 Bakgrund 4
1.2 Problemformulering 5
1.3 Syfte och frågeställning 6
1.4 Avgränsning 7
1.5 Kunskapsintressenter 7
2. Teori 8
2.1 Rollens inverkan på krav 8
2.2 Problem vid framtagning av kravspecifikationer 8
2.2.1 Klienter ställer ibland krav som organisationen inte behöver 8 2.2.2 Klienten kan inte svara på vad verksamheten behöver 9 2.2.3 Vissa klienter vill inte hjälpa dig med projektet 9
2.2.4 Tidigare forskning om kravelicitering 10
3. Metod 11
3.1 Forskningsansats 11
3.2 Metodval 12
3.2.1 Grounded Theory Approach 13
3.2.2 Metod för datainsamling 13
3.2.3 Fastställande av intressenter 14
3.2.4 Utveckling av intervjumanus 14
3.2.5 Kompletterande frågor 14
3.2.6 Metod för dataanalys 15
3.2.7 Volere-kravmodell 15
3.2.8 Numerisk viktning av krav 16
4. Empiri 19
5. Analys 26
5.1 Skillnader i krav 26
5.2 Likheter med hög varians 29
6. Sammanfattning 32
6.1 Slutsats 32
6.2 Generaliserbarhet 33
6.3 Diskussion 33
6.3.1 Slutsatsdiskussion 33
6.3.2 Metoddiskussion och DSR-utvärdering 34
6.4 Vidare forskning 35
7. Källförteckning 37
8. Bilagor 39
8.1 Sammanfattad lista på insamlade krav 39
8.2 Lista på alla insamlade krav 42
8.3 Jämförande Kravspecifikationer 43
Medarbetare 43
Chef 43
High priority requirements (undisputed or strong demand) 43
Nice-to-haves (disputed or weak requirements) 46
Rejected Requirements (highly disputed requirements) 47
High priority requirements (undisputed or strong demand) 43
Nice-to-haves (disputed or weak requirements) 45
Rejected Requirements (highly disputed requirements) 46
8.4 Intervjumanus 47
1. Inledning
1.1 Bakgrund
Kravinsamling är ett centralt begrepp som återkommer när nya informationssystem skall designas. Det innebär att man tar fram de krav som användare har på ett system som skall konstrueras. Det optimala är givetvis att få en så komplett bild som möjligt av de krav som ställs på systemet, men det är mycket man måste ta hänsyn till för att dessa krav skall leda till ett bra system. Är alla krav rimliga utifrån till exempel budget, tidsplanering, arbetsuppgifter eller komplexitet? Vems krav är viktigast? Bidrar kravet till att systemet uppfyller
verksamhetens mål? För att bidra till kunskap inom detta område har vi utfört en kravinsamling och skapat en kravspecifikation för ett nytt intranät åt ett medelstort
internationellt företag. Med stöd av Design Science Research, som förenklat innebär att man skapar ny kunskap genom designprocessen har vi samlat in krav, eller kraveliciterat som det också heter, genom intervjuer på företaget för att sedan utifrån kravinsamlingen analyserat hur intervjuobjektens syn på krav varierar huruvida de är chefer eller medarbetare. (Hevner et. al. 2004)
Vår uppdragsgivare är ett globalt IT-företag baserat i Uppsala som uppgav att de har svårigheter med sitt intranät och kommunikationen internt inom företaget och söker olika alternativ till hur man kan förbättra detta. I nuläget har företaget ett intranät uppe och
fungerande, dock används det inte mycket bland medarbetarna eftersom det bland annat inte uppdateras särskilt ofta. Företaget driver en global verksamhet inom IT-utveckling och har ca 200 anställda om man inkluderar ett dotterbolag på 30 anställda. För att ta reda på de
svårigheter samt de möjligheter en implementation av ett väl fungerande intranät inom ett etablerat företag kan innebära har vi därför åt företaget tagit fram en kravspecifikation som beskriver de krav som finns på ett nytt intranät utifrån personalens behov.
Informationssystem innefattar system som är involverade i insamlande, behandling, distribuering eller användning av information (Beynon-Davies, 2013, s.15).
Informationssystem kan vara analoga system eller digitala system såsom till exempel ett intranät.
Ett intranät är en intern kommunikationsplattform som i detta fall främst hanteras med hjälp av http och därmed genom ett webb-gränssnitt. Intranätet fungerar alltså som en hemsida som enbart går att komma åt via företagets interna nätverk eller genom Virtual Private Network (VPN). Bilden av intranätet har ändrats i samband med internets utveckling och i dagsläget används begreppet för att beskriva hemsidor som används inom företag för att förmedla intern information (Wikipedia). Dessa behöver inte nödvändigtvis vara på företagsnätverket, utan kan vara molnbaserade eller driftas av en extern part, där informationen hålls säker genom inloggning för att förhindra att personer utanför företaget får tillgång till
informationen (Microsoft, 2018).
Företaget har inte gjort någon djupare kravelicitering genom att utföra intervjuer tidigare och vår uppgift har varit att samla in så detaljerade krav som möjligt för att få en bild av vad de anställda inom företaget ser som användbart i ett nytt intranät. Kraven har samlats in från många olika roller i företaget och något som är intressant för oss är hur kraven kan skilja mellan ledningen på företaget och medarbetarna. I utvecklingsprocessen av ett nytt system är det viktigt att man ser till de verkliga behoven på systemet och förstår hur olika intressenters krav kan skilja sig åt. (Davey och Parker, 2015)
1.2 Problemformulering
En av de centrala processerna i utvecklingen av ett nytt IT-system är kravelicitering och genom det skapandet av en kravspecifikation. Denna kravspecifikation ska innehålla kraven som intressenterna - i detta fall medarbetare från olika verksamhetsskikt inom företaget - ställer på det planerade systemet. I kraveliciteringsarbetet finns det en mängd olika potentiella problem som vi bör undvika. Davey och Parker (2015, s. 75) tar upp följande kategorier (fritt översatt från engelska):
● Det mänskliga språket går inte alltid bra ihop med en teknisk lösning.
● Krav förändras alltefter ett projekt fortlöper.
● Klienter ställer ibland krav som organisationen inte behöver.
● Klienten kan inte svara på vad verksamheten behöver
● Vissa klienter vill inte hjälpa dig med projektet.
● Kraveliciteringen misslyckades för att den inte utfördes ordentligt.
● Symptom som inte är problem beskrivs ofta.
● Kravelicitering är inte deterministisk.
Figur 1. Problem vid kravelicitering
Utav dessa väljer vi att fokusera på “Klienter ställer ibland krav som organisationen inte behöver”, “Klienten kan inte svara på vad verksamheten behöver” samt “Vissa klienter vill inte hjälpa dig med projektet” . Dessa problem kan uppstå på grund av att respondenten i en intervju kan ha krav på systemet som inte är relevanta, antingen beroende på okunskap om delar av verksamheten eller på grund av man inte förstår syftet med det planerade systemet.
Detta ställer krav på att vi som skapar kravspecifikationen förstår verksamheten och kan identifiera vilka krav som är relevanta.
Standish Group skriver i sin CHAOS-rapport att de flesta IT-projekt misslyckas redan vid insamlingen av kraven. Detta på grund av svagheter i kravprocessen och närmare bestämt misslyckandet av att fastställa intressenter och deras behov. För att undvika detta menar de att man måste använda kraveliciteringstekniker anpassade för kunden och hitta en balans mellan alla intressenters intressen (Pacheco et. al., 2018, s. 373 ff).
Problemen kan även uppstå på grund av underförstådda krav som respondenten i en intervju inte delar med sig av, eftersom de ses som självklara för personen i fråga. Om alla
respondenter har väldigt nischad kunskap inom ett speciellt område av verksamheten och en helhetsbild inte framträder kan även kravspecifikationen bli vinklad (Davey och Parker, 2015).
Davey och Parker (2015) nämner även att ett stort problem inom IT-projekt är att man inte beaktar hur systemet påverkar alla involverade intressenter och att man kanske utgår från styrelsens eller chefernas åsikter på hur systemet ska se ut och fungera, snarare än de som faktiskt kommer att använda systemet. Vi ser därför en stor vikt av att i vårt arbete undersöka hur kravspecifikationerna utvecklas baserat på information från olika roller inom
verksamheten och sedan försöka analysera hur verksamheten förhåller sig till de olika modellerna.
1.3 Syfte och frågeställning
Det huvudsakliga forskningsbidraget vi vill tillföra med detta arbete är att skapa förståelse för hur chefer och medarbetare i en verksamhet skiljer sig i hur de identifierar krav och hur detta skulle kunna generera helt olika kravspecifikationer och systemförslag. Anledningen till varför vi vill kolla på detta är för att se om dessa olika roller kan identifiera systemkrav utifrån ett utomstående perspektiv, alltså kunna se systemets helhet och därmed även identifiera andra rollers krav.
Med detta arbete vill vi i även skapa kunskap om de krav som ställs på ett ICT-system (Information and Communications Technology) vars syfte är att användas som ett
kommunikationsverktyg internt inom ett företag för att hantera information såsom nyheter, policies, kontaktuppgifter och mallar - ett intranät.
Syftet uppfylls genom en Design Science Research-process, som vi beskriver mer i metoden, vilken innebär att vi skapar en artefakt, en produkt, i form av en kravspecifikation åt
företaget. Kraven som tas fram för denna kravspecifikation används sedan för att undersöka frågeställningen som beskrivs nedan. Genom denna process avses ny kunskap skapas och tillföras forskningsämnet (Hevner et. al. 2004).
Kunskapen som skapats i samband med detta arbete är tänkt att användas för att få en bättre förståelse för om chefer eller medarbetare har olika krav på intranät. Detta för att utveckla kunskaper om kravelicitering. Då åtskilliga verksamheter behöver samla in krav eller använder sig utav intranät är förhoppningen att denna kunskap skall vara dem till nytta.
Frågeställningen lyder: Hur skiljer sig kraven på ett intranät mellan personer med och utan en chefsroll i en organisation och vilken roll kan ha mer eller mindre realistiska krav?
1.4 Avgränsning
Då frågeställningen rör skillnader i krav mellan chefer och medarbetare väljer vi att bortse från skillnader i krav mellan andra roller, som till exempel mjukvaruutvecklare eller säljare.
En chef definierar vi som en person med personalansvar och ansvar över en avdelning. En medarbetare kan ha ansvar för ett team, men ej personalansvar. Personalansvar innebär ett juridiskt ansvar för medarbetarna man är chef över.
Avgränsningar i hur mycket av personalens tid vi kunde ta bestämdes tillsammans med våra närmaste uppdragsgivare (IT-chefen och kontorschefen). Det bestämdes till en timmes intervju av varje anställd vi skulle hinna med att intervjua under ca. tre veckors tid. Hur många anställda vi skulle intervjua bestämdes inledningsvis till 13 personer men kunde utökas av oss efter behov. Det slutade med att vi intervjuade 16 personer eftersom vi skulle fortsätta till vi nådde teoretisk mättnad (se metod 3.2). Vi valde intervjuobjekt inledningsvis med hjälp av våra uppdragsgivare. Målet var att få spridning i olika roller för att täcka in så många olika krav som möjligt. Vi tog även förslag på nya intervjuobjekt under själva intervjuerna.
1.5 Kunskapsintressenter
Kunskapen som arbetet är tänkt att generera riktar sig mot alla som behöver utforma
kravspecifikationer för IT-system i små- eller medelstora IT-företag. Uppsatsen syftar att ge en bredare förståelse för hur chefer och medarbetare kan ha olika krav och kan genom det hjälpa vid framtagning av kravspecifikationer för dessa verksamheter, särskilt relaterat till intranät.
2. Teori
Här tar vi upp den teori vi lutat oss på som relaterar till vår frågeställning. Framför allt handlar det om roller och krav, samt hinder som vanligen finns inom kravelicitering.
2.1 Rollens inverkan på krav
Davidson (2002) utforskar i sin text hur makt inom olika roller påverkar hur utformningen av kraven utspelar sig. Texten utforskar skillnader mellan systemutvecklare och användare av systemet. Till skillnad från att utforska hur de olika grupperna identifierar och värderar olika krav har fokus på texten varit hur de baserat på olika maktpositioner har haft möjlighet att påverka kravbildningen av systemet. Samt hur kravanalytikern måste vara medveten om hur rollernas makt kan förändra hur starka deras krav uppfattas.
2.2 Problem vid framtagning av kravspecifikationer
Davey och Parker (2015) genomförde en litteratursstudie där de lutade sig på tidigare forskning för att bland annat förklara att den viktigaste orsaken till att IT-projekt misslyckas är problem i kraveliciteringen och kravanalysen. Vi går igenom lite av den tidigare
forskningen i punkt 2.2.4. Som tidigare nämnts i avsnitt 1.2 så kommer denna text att analysera de insamlade kraven utifrån tre av de problem som de identifierar. I detta avsnitt kommer dessa tre problem att undersökas djupare och kopplingar till vår frågeställning utforskas. Se figur 1 i avsnitt 1.2 för Davey och Parkers lista över problem.
2.2.1 Klienter ställer ibland krav som organisationen inte behöver
Davey och Parker (2015, s. 77) beskriver detta som ett problem som uppstår när man låter klienten, eller uppdragsgivaren, generera kraven genom konversation på olika sätt
(exempelvis intervjuer). Risken finns alltid att klienten ställer krav som inte är nödvändiga för verksamheten. Till exempel krav som personligen skulle gynna dem eller deras roll, men som inte ökar produktiviteten eller på annat vis gynnar verksamheten. Det är därför viktigt att man analyserar och försöker identifiera vad syftet med kravet är.
Problem kan även uppstå när klienten ställer krav på saker som de inte är involverade i. Detta är en av de aspekter som troligtvis kan påverkas baserat på individens roll.
Utifrån denna teori vill vi undersöka följande aspekter:
Cheferna som har ett större ansvar, men även en bredare kunskap om verksamheten som helhet kanske har en större tendens att ställa krav utanför det egna området, dels för att den har bättre förståelse för de andra arbetsområdena, men även för att det större ansvaret gör att man vill ge en så stor helhetsbild av systemets krav som möjligt.
Medarbetarna har troligtvis inte lika bra förståelse för verksamheten som helhet, utan har mera detaljkunskap inom sitt egna område. Detta gör att de troligtvis är mest insatta i vissa ämnen och därmed har kunskap om vad för krav som systemet måste uppfylla just inom deras område. Risken finns dock att medarbetarna inte är lika insatta i andra områden som de ändå försöker identifiera krav till. Detta kan göra att felaktiga krav skapas.
Ett exempel på hur vi vill undersöka detta problem är om chefer, baserat på att de vill
identifiera fler krav, även försöker formulera krav till delar av systemet som de inte är insatta i.
2.2.2 Klienten kan inte svara på vad verksamheten behöver
Problem kan uppstå när klienten tror sig ha en komplett bild av verksamhetens krav på systemet, vilket sedan visar sig vara felaktig. Som tidigare nämnt uppstår problem när klienten enbart har förståelse för en specifik del av verksamheten. Detta leder då till att klienten inte lyckas identifiera krav relaterade till andra områden. Problem uppstår även när klienten har kunskap som för denne är underförstådd och därmed inte kommuniceras till kravanalytikern (Davey och Parker, 2015, s. 77).
Denna teori ämnar vi undersöka bland annat genom följande antagande:
Detta problem kan troligtvis uppkomma på grund av att systemet som kraveliciteras skapas som en ersättning av ett liknande system. Risken finns då att klienterna gör ett antagande att all funktionalitet från föregående system kommer att finnas med i det nya systemet.
2.2.3 Vissa klienter vill inte hjälpa dig med projektet
Davey och Parker (2015, s. 77) tar upp tre anledningar till varför klienten inte vill hjälpa till med projektet:
● Klienten har intressen som motsäger projektets mål, eller som går emot andra inom projektet.
● Vissa personer kommer använda motståndstaktik för att undvika att kraveliciteringen når ett resultat.
● Klienten ser det nya systemet som ett potentiellt upphov till maktskifte inom verksamheten.
Av dessa tre anledningar så är det i vårt fall extra intressant att analysera om man kan se tecken på att den tredje anledningen kan påverka de olika rollerna. Vi vill alltså utifrån detta undersöka följande tes:
Baserat på detta så finns det en risk att cheferna blir mindre benägna att identifiera och värdera krav som skulle ge medarbetarna mera makt att kontrollera och sprida information inom företaget, då chefernas makt då förminskas eftersom medarbetarna inte blir lika beroende av chefen. Utifrån detta så kan man på samma vis anta att medarbetarna undviker
att ta upp krav som skulle göra deras arbeta mer kontrollerat och därmed minska deras egna makt över hur de väljer att arbeta.
2.2.4 Tidigare forskning om kravelicitering
Standish Group är en fristående forskningsrådgivande firma som främst försöker förklara orsakerna till varför IT-projekt misslyckas och hur man kan förbättra dessa (Standish Group).
Flera av våra källor (bland annat Pacheco et. al., Davey och Parker samt en till vi går igenom snart) nämner Standish Groups CHAOS-rapport som Standish Group publicerar årligen för att redogöra för sin forskning. Standish Groups forskning också har blivit replikerad av flertalet andra forskare (Davey & Parker 2015, s. 72).
En av källorna Davey och Parker förlitar sig på är Axel van Lamsweerde år 2000 publicerade en sammanfattande forskningsrapport om det dåvarande läget i IS-forskningen kring
kravelicitering. Redan då kom han fram till det som Davey och Parker tar upp i sin artikel om att det verkar vara på grund av bristfällig kravelicitering som problemen uppstår
(Lamsweerde, 2000). Grundorsaken till varför vi använt Davey och Parker som huvudkälla är att deras litteraturanalys ger en oerhört komplett - och nyligen utförd - sammanfattning av många andra forskares arbete. I deras lista av problem som kan uppstå i kraveliciteringen går de igenom för varje punkt vilka forskare som ligger bakom identifikationen av problemet.
3. Metod
I denna ganska omfattande del redogör vi för forskningsansatsen och den forskningsprocess som den ger upphov till. Tonvikten i uppsatsen ligger i metod då det är en central del av Design Science. Först redogör vi för ansatsen och Design Science Research och sedan går vi igenom de metoder vi använt för kravinsamling och dataanalys.
3.1 Forskningsansats
Vi har använt oss utav Design Science Research (DSR) som forskningsmetod. Anledningen till detta är för att vi genom detta projekt skapat en artefakt i form av en kravspecifikation.
Skapandet av designartefakten är en central del i DSR. Syftet är genom detta att skapa ny kunskap som kan appliceras på verkliga problem. Till skillnad från traditionell forskning där fokus ligger på att utforska, beskriva och förklara, vill vi med detta arbete skapa kunskap som bland annat är praktiskt applicerbar och kan användas vid framtagandet av krav och design av ett intranät. Hevner et. al. (2004) ritar upp i sin artikel, Design Science in information systems research, följande modell som beskriver DSR:
Figur 2. En grafisk representation över hur DSR kan fungera. Genom att relevanta (relevance) verksamhetsbehov beaktas och rigorösa (rigor) teorier, modeller och
metodologier används, produceras en artefakt som sedan utvärderas och valideras. Från
denna process skall sedan verksamhetsbehoven uppfyllas och ny kunskap återföras (Hevner et. al. 2004).
Hevner et. al. (2004) tar i samma artikel också upp sju olika riktlinjer för hur DSR kan gå till i en DSR-process. I tabell 1 sammanfattar vi (fritt översatt) de sju riktlinjerna:
Design genom att utveckla en artefakt:
DSR måste utveckla en artifakt - slutprodukt(er) - i form av en konstruktion, modell, metod eller instantiering.
Problemrelevans: Målet med DSR är att utveckla teknologibaserade lösningar på relevanta verksamhetsproblem.
Utvärdering av design:
Nyttan, kvaliteten och påverkan av artefakten måste tydligt demonstreras genom väl utförda utvärderingsmetoder.
Forskningsbidrag: Väl genomförd DSR måste kunna ge tydliga och verifierbara bidrag till forskningsområdet för designartefakten, designunderlaget och/eller designmetodologin.
Rigorös eller noggrann forskning:
DSR bygger på att rigorösa metoder används både för att konstruera och utvärdera designartefakten.
Design som en sökprocess:
DSR handlar om att söka efter en effektiv artefakt utifrån tillgängliga resurser, som både genererar relevant kunskap utifrån
verksamhetsbehov, samt följer de riktlinjer uppdragsgivaren har på artefaktens syfte.
Kommunikationen av kunskapen:
DSR måste presenteras effektivt både för tekniskt kunniga personer och för mer de management-orienterade.
Tabell 1: Hevners 7 riktlinjer (Hevner et. al. 2004).
Vår forskningsansats handlar om att producera en kravspecifikation utifrån de två olika gruppernas krav som en leverabel produkt till företaget. Denna kravspecifikation samt resultatet på vår frågeställning har vi fått fram med hjälp av den datainsamling (se 3.2.1) och dataanalys (se 3.2.2) beskriven nedan. De eliciterade kraven och kravspecifikationen ligger sedan till grund för resultatet på vår frågeställning om huruvida chefer och medarbetare har olika krav eller olika realistiska krav.
3.2 Metodval
Metodvalet definierar sökprocessen som är en del av DSR (se tabell 1 ovan). I denna uppsats använder vi oss av kvalitativa metoder. Uppdragsgivarna uttryckte att de ville att vi skulle utföra kraveliciteringen utan bias (förutfattade meningar) så långt som möjligt och det tillsammans med avgränsningarna vi hade bestämde vilka metoder vi valde. För att undvika
bias gick vi inledningsvis in i intervjuerna med ganska breda frågor och utvecklade intervjufrågorna i senare intervjuer efter det vi lärt oss - något som liknar metoden i
Grounded Theory Approach som vi går igenom i detta avsnitt. Nedan går vi även igenom de metoder vi använt för datainsamling och dataanalys. För inledande intervjumanus se bilaga 8.4. Risken med breda frågor och en utveckling av intervjumanus allt eftersom är att materialet kan bli svårt att jämföra, vilket gör det viktigt att återvända till de personer som tidigare intervjuats för att fråga dem om saker som tagits upp senare. Detta beskriver vi mer i 3.2.2. (Oates, Briony J., 2006).
3.2.1 Grounded Theory Approach
Grounded Theory Approach (GTA) är en metod som ämnar att skapa generaliserbar och abstrakt kunskap och innehåller rigorösa metoder för att uppnå detta, bland annat förespråkar GTA omfattande kodning av intervjuer. I vår datainsamling tar vi inspiration från några - för oss - användbara delar i GTA. Ett centralt begrepp i GTA är att man strävar mot saturation, eller teoretisk mättnad. Först ska man angripa intervjuerna med så lite bias, så få förutfattade meningar, som möjligt. På detta vis är man öppen för nya och unika behov. Sedan skall man dokumentera dessa intervjuer och fortsätta hålla intervjuer tills man ser att man inte längre får några, för verksamheten relevanta, krav som kan konceptualiseras. Man börjar alltså med en induktiv metod för att sedan fortsätta att arbeta mer deduktivt. När detta skett har man nått saturation. Man kan då förvänta sig att den data som upprepar sig oftast är viktig för verksamheten (Oates, Briony J., 2006).
3.2.2 Metod för datainsamling
Grounded Theory Approach har inspirerat men ligger inte till grund för datainsamlingen. Vi använde oss utav semistrukturerade intervjuer, till skillnad från ostrukturerade intervjuer som används i GTA. Till skillnad från GTA gjorde vi också en förstudie för att kunna konstruera vårt inledande intervjumanus. Semistrukturerade intervjuer möjliggjorde följdfrågor på de krav som dök upp under intervjuerna, något som exempelvis en enkät eller strukturerad intervju inte skulle ha gjort. Intervjuobjekt tenderar även att vara mer utförliga i sina svar då de intervjuas (Oates, Briony J., 2006).
Det som liknade GTA i vår datainsamling är sökandet efter teoretisk mättnad i
datainsamlingen; alltså den fortsatta insamlingen av data tills ingen ny, för ämnet, relevant data erhålls. Vi utvecklade intervjufrågorna till att begära synpunkter på krav framförda av tidigare intervjuobjekt samt refererade till vad vi diskuterat i tidigare samtal. I sökandet efter teoretisk mättnad var vi även öppna för att intervjuobjekten hade förslag på ytterligare personer att intervjua som kunde ha mer intresse i ett nytt intranät samt mycket kunskap. Tre personer till bokades in för intervju på detta sätt. Datainsamlingen utfördes iterativt genom att ställa följdfrågor via mejlutskick efter vi sammanfattat kraven från intervjuerna (Oates, Briony J., 2006).
3.2.3 Fastställande av intressenter
Med hjälp av kontorschefen och IT-chefen (våra huvudsakliga uppdragsgivare) fastställde vi i en liten förstudie tillsammans med dem en lista med intervjuobjekt. Dessa chefer var våra huvudsakliga uppdragsgivare samt kontaktpersoner och hade god kunskap över
tillgängligheten på personal och förberedde intervjuobjekten på att vi skulle kontakta dem för tidsbokning. Vi utgick ifrån deras kunskap samt en förteckning över anställda och deras arbetsuppgifter som finns i det nuvarande intranätet, kallad staff gallery. I första hand valde vi ut samtliga personer som hade publiceringsrättigheter (fyra personer), eftersom dessa använder det nuvarande intranätet mest och har störst intresse av att vara involverade i hur ett nytt intranät skall se ut. Efter publicister valde vi utifrån olika roller ut chefer och
medarbetare för att få en jämn spridning över företagets affärsområden. En jämn spridning är viktigt för att verksamhetskraven skall kunna anses representera hela verksamheten. Eftersom företaget också har kontor på andra orter runtom i världen så var det även viktigt att vi fick med deras krav på intranätet, då deras behov kring den interna kommunikationen troligtvis skiljer sig från huvudkontoret i Uppsala (Davey och Parker, 2015, s. 77).
Enligt CHAOS-rapporten från Standish Group misslyckas de flesta IT-projekt på grund av svagheter i kravprocessen och närmare bestämt misslyckandet av att fastställa intressenter och deras behov (Pachecho et. al., 2018, s. 373 ff). För att undvika detta ville vi att alla avdelningar skulle få möjlighet att föra fram sina krav på intranätet men också få chansen att föreslå andra kollegor att intervjua. Tre personer till utöver den första gruppen bokades in för intervjuer på detta sätt och kunde bidra med mycket värdefulla insikter om verksamhetens behov. Fler än tre behövdes dock inte då vi bedömde att vi hade nått teoretisk mättnad (se avsnitt 3.2.1 för vad vi avser med teoretisk mättnad).
3.2.4 Utveckling av intervjumanus
I förstudien som också bestod av att titta på det nuvarande intranätet hos företaget och att skapa ett första intervjumanus utifrån den information vi fått av IT-chefen och kontorschefen om de olika avdelningarna. Eftersom personer från olika avdelningar intervjuades anpassades vissa frågor till dem. Till exempel säljare och personal på marknadsavdelningen använder sig utav programmet Salesforce som vi då bad dem beskriva vilken roll det spelade i deras dagliga arbete. I grunden utgick dock manuset från stora öppna frågor och intervjuobjektet tilläts svara fritt på dessa och sporrades vid behov med följdfrågor på ny information. Se bilaga 8.4 för intervjumanus (Oates, Briony J., 2006).
3.2.5 Kompletterande frågor
Efter att intervjuerna var klara såg vi ett behov av att få in mer data om de krav som ett fåtal personer hade nämnt eller som tidigare intervjuobjekt inte hade haft möjlighet att
kommentera. Ytterligare iterationer av intervjuer med samma personer, som vanligtvis görs i GTA (se avsnitt 3.2.1), låg utanför projektets avgränsningar. Vi skickade ut kompletterande
frågor genom mejl till intervjuobjekten för höra deras åsikter om krav som inte kommit upp vid första intervjutillfället. Frågor som om man kunde tänka sig att använda intranätet för icke-jobbrelaterad information eller om man kunde tänka sig att använda intranätet för att fylla i formulär såsom ledighetsansökningar. Frågorna som ställdes till varje intervjuobjekt varierade med vad som inte hade behandlats vid just deras intervju. Denna andra
kravinsamling var viktig för att öka styrkan i motiveringen av kravens relevans för intranätet och för att nå teoretisk mättnad.
3.2.6 Metod för dataanalys
Den kvalitativa dataanalysen inleddes genom att undersöka och kategorisera intervjumaterial i form av anteckningar och inspelningar. Denna analys skulle identifiera de nyckelord och teser vi sökte efter för att underlätta utformningen av kravspecifikationen. Vi producerade först en kravspecifikation som leverabel produkt till företaget och sedan har vi producerat två kravspecifikationer för att demonstrera skillnader i hur de skulle se ut om hänsyn togs till medarbetare eller chefer för sig. Alla krav viktades numeriskt efter intervjuobjektens värdering av dem. Dataanalysen av intervjumaterialet är baserad på Volere-metoden.
3.2.7 Volere-kravmodell
Vi har kollat på ett flertal olika metoder för att generera, sammanställa och formulera, samt presentera krav. Då inga av de olika tillvägagångssätten har som syfte att erbjuda en tydlig jämförelse av olika uppsättningar krav har vi valt att inte följa någon av dem helt och hållet, utan snarare formulera krav på ett sätt som erbjuder möjligheter för tydliga jämförelser. Vi har dock tagit inspiration av framförallt Volere-kravmodellen när det gäller vår egna modell.
Volere är en samling av olika tekniker för att formulera och hantera krav som utvecklades med syftet att inkludera och tydliggöra kravprocessen och presentationen för discipliner som inte nödvändigtvis kommer i kontakt med kravhantering i sitt egna arbete (Robertson, 2017).
Voleremetoden kategoriserar kraven till en av sex olika kategorier av krav, vilka är följande (fritt sammanfattat och översatt):
Funktionella krav, vilket beskriver vad produkten måste göra.
Icke-funktionella krav, vilket beskriver egenskaper som produkten måste besitta.
Projektbegränsningar, vilket är krav som begränsar produkten i form av budget eller projektets tidsbegränsning.
Designbegränsningar beskriver de begränsningar i hur produkten måste utformas, till exempel. om den måste förhålla sig till en viss plattform eller om det ska integreras med ett annat system.
Projektdrivare är de drivkrafter som för projektet framåt. Syftet med projektet är den huvudsakliga drivkraften.
Projektproblem är de hinder som identifierats som problem med projektet. Även lösningar på dessa problem hamnar under denna kategori (Robertson, 2017).
Volere är ett väldigt genomgående ramverk för hur man tar fram krav för en produkt, där de funktionella samt icke-funktionella kraven skrivs ut på ett kort med all information för kravet (Robertson, 2017).
Figur 3. Exempel på hur ett Volere krav kan se ut. (Robertson, 2017)
En del av Volere metoden som vi delvis har inkorporerat i våran egna modell är priority-egenskapen. Detta gör vi genom att likt volere-modellen tilldela ett värde
(prioritering) till varje krav utifrån varje individs värdering av kravet. För att tydligare kunna se hur de olika kraven jämför sig mellan de olika grupperna så kombineras dessa värden ihop inom varje grupp för att ge ett genomsnittsvärde på kravet för varje grupp.
Vi har även valt att ta med dependencies, alltså om ett krav är beroende av andra krav. Detta för att öka förståelsen av kraven och hur de relaterar till varandra.
För att kunna koppla kraven till varandra så har vi även gett varje krav ett unikt krav ID i kravlistan, likt man gör med Volere.
För själva kravspecifikationerna väljer vi att ge vissa krav en beskrivning, dock gör vi detta endast för de kraven som inte är självbeskrivande eller som vi anser går att missuppfatta.
3.2.8 Numerisk viktning av krav
För att underlätta sammanställningen och jämförelsen av datamaterialet krävdes att vi representerade intervjuobjektens värdering av kraven. Istället för att jobba med kort som Volere-modellen förespråkar använde vi oss istället av ett datablad (se bilaga 8.1). Detta gjorde det möjligt för oss att numeriskt tolka värderingen av kraven från intervjuobjekten i relation till varandra och sedan enkelt beräkna medelvärde och differens. Vi gick igenom inspelningarna och anteckningarna av intervjuerna och gjorde en bedömning på en skala från
-5 till 5 hur viktigt intervjuobjektet värderade att kravet var. Den numeriska värderingen beskrivs i tabellen nedan:
5 Mest positiv - Anser att det är mycket bra för verksamheten 4 Mycket positiv - Höll starkt med om kravet
3 Positiv - Tyckte det var bra
2 Försiktigt positiv - Positivt men inte tydligt bra 1 Något positiv - Vag positiv indikation
0 Ingen åsikt - Vill/kan inte värdera eller bryr sig inte -1 Något negativ - Vag negativ indikation
-2 Försiktigt negativ - Negativt men tydligt dåligt -3 Negativ - Tycker inte det vore bra
-4 Mycket negativ - Starkt emot
-5 Mest negativ - Anser att det vore mycket dåligt för verksamheten Tabell 2.
Vi gjorde skalan fem steg åt båda riktningarna från noll för att kunna ha utrymme att värdera krav i relation till andra intervjuobjekt. För att värderingen i relation till varje intervjuobjekt skulle kunna göras så korrekt som möjligt gick vi igenom ett krav i taget. Det viktiga för att kunna identifiera skillnader för frågeställningen var att den inbördes ordningen var korrekt.
Vi gick båda igenom materialet var för sig för och jämförde våra viktningar och tog medelvärdet av dem i de fall där tolkningen inte var likadan.
Intervjuobjekten delades inledningsvis upp i tre grupper utifrån vår identifiering av ansvar.
Senare sammanfogades medarbetare och ansvariga för att anpassas till vår frågeställning. Det kan vara intressant att jämföra olika nivåer av ansvar i en vidare studie, då vi sett en del skillnader. Se tabellen nedan:
Benämning Beskrivning Förkortning
Medarbetare Utan personalansvar eller teamansvar M Ansvariga Ansvar för team men ej personalansvar A
Chefer Personalansvar och chef över avdelning C
Medarbetare + Ansvariga All personal förutom chefer. Refereras till som medarbetare i texten.
Medelvärdet (se tabell 4) för denna kategori avser medelvärdet viktat på antalet intervjuobjekt.
M + A
Tabell 3. Beskrivning av förkortningar för roller
Gruppen ansvariga identifierades inledningsvis eftersom begreppet chef kunde avgränsas på olika sätt. Vi gjorde jämförelsen enligt definitionen att chef var en person med personalansvar och grupperade medelvärdet av M och A med varandra. Detta jämförde vi med medelvärdet för C för varje krav. Vi räknade ut differens och varians för varje krav mellan M + A och C för att ha fler mått att basera jämförelsen på.
4. Empiri
När intervjuprocessen var över sammanställde vi alla identifierade krav i en lista (se bilaga 8.1). I en del fall var vi tvungna att sammanfoga liknande krav till ett övergripande krav, till exempel om två olika personer hade identifierat liknande krav men formulerat sig på olika sätt. Detta gjorde vi för att överskådligheten skulle förbättras och att vi lättare skulle kunna göra en bedömning huruvida kravet skulle inkluderas i kravspecifikationen. Fördelen för oss med att slå ihop kraven till ett ensamt krav är att det underlättar jämförelsen, samt att det gör att listan blir mera överskådlig och inte innehåller flera varianter av samma krav. Nackdelen med att slå ihop kraven kan dock bli att vi i listan förlorar lite av detaljrikedomen av kraven, då vi sammanfattar mer specifika krav till ett mer öppna krav, eller specificerar det till något som kanske inte helt och hållet stämmer med alla personers syn på kravet.
Utöver de kraven vi samlat från intervjuerna så finns det även en del självklara krav på systemet, baserat på vad det nuvarande systemet har för funktionalitet och vad som förväntas av ett intranät likt Davey och Parker (2015) tar upp om klienten kan inte formulera
verksamhetens behov baserat på underförstådd kunskap. Därför har vi registrerat krav på systemet som inte togs upp i den insamlade kravlistan (se bifogat 8.1), men snarare krav som implicit togs upp under intervjuerna baserat på nuvarande systemet. Baserat på datan från de insamlade kraven, annan information från intervjuerna, samt krav utöver de insamlade från intervjuerna har vi sammanställt följande två kravspecifikationer (se bifogat 8.3 Jämförande kravspecifikationer).
Av de insamlade kraven så väljer vi att fokusera på krav där skilda meningar kan uppstå, alltså att någon värderar kravet negativt och andra positivt. Vi vill också studera krav där differensen mellan Chefer och medarbetare med/utan ansvar, detta då det direkt kan kopplas till vår frågeställning hur chefer och medarbetare värderar krav olika. Utöver det så ämnar vi analysera krav där variansen på kravet är högt, vare sig chefer och medarbetare värderar det olika eller inte. De kraven vi väljer att analysera är de vi markerat med ljusgul färg i listan med insamlade krav (bilaga 8.1). Dessa presenteras även här, där värden som anses värda att analysera djupare är markerade i ljusgul färg.
Benämning Beskrivning Förkortning
Average (Genomsnitt) Beräknat medelvärde inom grupp. avg Difference (Skillnad) Skillnad mellan Chefernas genomsnitt
och resterande personals genomsnitt
Diff
Count (Antal) Antal respondenter som värderade kravet (negativt eller positivt)
Variance (Varians) Hur stor spridningen hela
respondentgruppens svarsvärden har.
Var
Tabell 4. Beskrivning av förkortningar för beräkningar.
Kravnamn: Clearly structured navigation
C avg: 4.75 M+A avg: 3.50 Diff: -1.25 Count: 8 Var. 0.98 Kommentarer: Detta krav utgår från implicit kunskap om det nuvarande systemet. I
kravspecifikationen så står det mer detaljerat exakt vad detta innebär, men sammanfattat så uppstod kravet på grund av att vissa förlitar sig helt på sidnavigering, snarare än
sökfunktionen för att hitta information, och det nuvarande systemet hade inte en logiskt uppbyggd navigeringsstruktur.
Kravnamn: Ability to view/subscribe to other departments/offices
C avg: 2.50 M+A avg: 4.20 Diff: 1.70 Count: 14 Var: 2.37 Kommentarer: En stor del av intervjurespondenterna lyckades identifiera detta krav. Detta krav skulle innebära att användarna kan ta del av information som främst är relevant för de andra avdelningarna eller kontoren. Många som värderade detta högt gjorde det på grund av. att de ansåg att det skulle kunna öka samhörighetskänslan på företaget om man fick möjlighet att se vad som hände på de andra kontoren. De nämnde även att det skulle ge en bredare förståelse för företaget om man kunde ta del av information angående vad de andra avdelningarna höll på med. De som värderade detta krav lägre såg ingen nytta med att erbjuda personalen möjlighet att kolla upp information som inte är direkt relevant till deras arbete och ansåg det snarare vara en onödig säkerhetsrisk att låta alla inom företaget ta del av så mycket information utan någon tydlig anledning.
Kravnamn: Limited Publishing Access
C avg: 5.00 M+A avg: 3.71 Diff: -1.29 Count: 10 Var: 1.43 Kommentarer: Detta krav innebär att man på något sätt ville begränsa vilka som kunde lägga ut information på intranätet. Denna begränsning var främst på de fasta sidorna samt nyheterna, och innefattade alltså inte kommentarer eller inlägg i potentiella
diskussionsgrupper. Ett exempel på vad någon som värderat detta högt sade under intervjun var att alla användare skulle vara behöriga att publicera inom deras avdelning samt kontorsgrupp. I andra grupper så skulle till exempel. en Field-Application Engineer som reser mycket få tillgång till att publicera i en custom group för tradeshows.
Kravnamn: Custom Groups
C avg: 3.00 M+A avg: 2.67 Diff: -0.33 Count: 10 Var: 5.51
Kommentarer: Av de tio respondenterna som svarade så var det enbart en som värderade detta med ett negativt värde, vilket var -3. Anledningen till varför respondenten valde att ge kravet ett negativt värde var då personen i fråga ansåg att det inte var lämpligt att ha arbetsgrupper på intranätet, och med denna funktion så fanns det risk att det skulle skapas.
De som värderade detta krav högt nämnde att det skulle underlätta grupp-kommunikation, och att det skulle ersätta många externa tjänster som används inom verksamheten idag.
Kravnamn: Integration with other systems
C avg: 5.00 M+A avg: 2.13 Diff: -2.88 Count: 9 Var: 4.53 Kommentarer: Detta krav är en sammanslagning av flera andra mindre krav. Utöver integrering med outlook genom kalendern (vilket vi har separerat in i andra krav), så identifierade vi genom intervjuerna krav på integrering med Salesforce, Hogia, Jira,
Twitter, samt deras externa hemsida. Av dessa olika system så har de flesta respondenterna nämnt Salesforce som det system som de skulle vilja integrera med intranätet, då i form av att viss säljdata plockas ut från Salesforce och visas på intranätet.
Kravnamn: Fun personal information
C avg: 1.50 M+A avg: 4.00 Diff: 2.50 Count: 3 Var: 4.33 Kommentarer: Detta krav skulle innebära att användarna skulle kunna lägga till lite personlig information kopplat till sin profil, så att de andra användarna skulle kunna se detta när de bläddrade igenom staff gallery. Detta krav togs bara upp av tre respondenter, varav en gav det 0 i värde, baserat på det resultatet så är det svårt att analysera.
Kravnamn: Fileserver
C avg: 3.60 M+A avg: 1.73 Diff: -1.87 Count: 16 Var: 5.56 Kommentarer: I dagsläget så har företaget möjlighet att dela filer genom ett privat
filnätverk. Vissa anser dock att detta system inte är intuitivt för fildelning då det är svårt att navigera genom filnätverket, samt att det är svårt att kontrollera behörighet till filerna. På grund av den höga variansen samt hur stor inverkan detta krav skulle ha på det nya systemet så var detta en av de krav vi skickade kompletterande frågor kring, vilket är anledningen till varför vi har 16 av 17 intervjurespondenters åsikter kring detta krav. Alla respondenter identifierade ett behov av fildelning inom företaget, dock ansåg vissa att nuvarande lösning med ett privat filnätverk var tillräcklig, medans andra ansåg att en extern fildelningstjänst var mer lämplig att använda. De flesta som har problem med det privata filnätverket använder sig av egna fildelningstjänster utan officiellt stöd från IT-avdelningen i dagsläget, vilket gör att de värderade detta krav högt, då det skulle
underlätta om hela verksamheten använde ett gemensamt verktyg för att hantera fildelning.
De som värderade kravet lågt ansåg att man inte bör utveckla eller implementera
fildelningsfunktionalitet i intranätet då det isåfall blir mer av en arbetsplattform, vilket det inte bör användas som, samt att det troligen inte skulle användas och att det då finns
externa tjänster som är mer lämpliga för detta.
Kravnamn: Event
C avg: 2.00 M+A avg: 3.80 Diff: 1.80 Count: 7 Var: 2.24 Kommentarer: Detta krav skulle innebära att det fanns en dedikerad yta på intranätet där arbets-relaterade event listats upp. Motivering till detta krav var framförallt att det skulle förenkla för personalen att hålla koll på event genom att samla dem på en gemensam yta på intranätet. De använder idag outlook kalendern som ett officiellt stött verktyg för att
hantera planering och liknande, dock så förs inte företagsevent in i kalendern automatiskt i dagsläget, vilket gör att folk tenderar att glömma bort event. Av de 7 som svarade på detta krav så gav alla kravet ett positivt värde, dock så gav en av cheferna kravet endast +1, vilket motiverades baserat på att de som sagt använder egna personliga kalendrar i
dagsläget och det är enklare att föra in information i den snarare än att behöva kolla på två olika kalendrar.
Kravnamn: Non-work related information
C avg: 1.00 M+A avg: 2.80 Diff: 1.80 Count: 16 Var: 8.12 Kommentarer: Detta var en av de krav som vi skickade ut kompletterande frågor kring.
Anledningen till detta var på grund av. att kravet hade så hög varians och det fanns flera intervjurespondenter som gav detta krav ett negativt värde.
Kravnamn: Management Space
C avg: 3.00 M+A avg: 5.00 Diff: 2.00 Count: 2 Var: 2.00 Kommentarer: Detta krav identifierades enbart av två intervjurespondenter, vilket gör att vi inte kan göra någon värdefull analys på denna data.
Kravnamn: Replace wiki on intranet
C avg: -2.50 M+A avg: 0.00 Diff: 2.50 Count: 7 Var: 5.57 Kommentarer: Utifrån intervjuerna så vet vi att det fanns tre olika avdelningar med wiki-sidor. Dessa var Utvecklar, support, samt IT-avdelningarna. Av de sju svaren vi fick så var två medarbetare från Supportavdelningen, och de värdesatte kravet 1 båda två, med kommentarer om att support-wiki inte var intuitivt. Av de fem andra respondenterna så var fyra från utvecklingsavdelningen, och tillsammans värderade de detta krav med -1 i
genomnsnitt. Vilket betyder att alla respondenter från utveckling-savdelningen och
Support-avdelningen tog upp detta krav under intervjun, vare sig de värderade det positivt eller negativt. Den sista som tog upp detta krav var chefen för IT-avdelningen, som gav detta krav ett -3 då denna person ansåg att det skulle krävas för mycket resurser för att
flytta om all information från wikin till en ny plattform.
Kravnamn: Chat
C avg: 1.00 M+A avg: 1.20 Diff: 0.20 Count: 16 Var: 4.78 Kommentarer: En stor svårighet inom företaget idag som tagits upp redan innan intervjuerna påbörjats var just att det inte fanns några officiellt stödda verktyg för att kommunicera inom företaget, annat än mail. Mailen ansåg flera av respondenterna vara problematisk då det fanns en stor risk att man missar viktig information när så mycket mail skickas och därmed fyller upp inkorgen. Många tog upp att mail kändes för formellt och officiellt för att hantera mindre kommunikation via, till exempel mindre frågor eller bekräftelser.
På grund av detta så ville vi undersöka hur personalen stod sig till någon form av chatt funktionalitet på intranätet, då det börjar bli vanligare och vanligare att intranät används som en social arbetsplattform (Wikipedia, 2019). De flesta verkade inte sakna möjligheten att kommunicera via chatt i dagsläget, och de som ansåg att det fanns ett behov för det tyckte att detta var något som skulle ligga utanför intranätet. En av anledningarna till varför folk svarade att det bör hanteras utanför intranätet genom en extern tjänst var framförallt för att det skulle underlätta att ha denna funktionalitet via en app så att chatten även går att komma åt smidigt från mobilenheter. De som identifierade ett potentiellt behov av detta ansåg att det skulle underlätta kommunikationen mellan de olika kontoren framförallt, då mycket av kommunikationen inom kontoren kan ske direkt “face-to-face”.
Syftet med chatt funktionaliteten skulle vara att erbjuda personalen att få direkt respons på en fråga eller få ut information snabbt till annan personal inom verksamheten. Ett problem inom företaget är dock att det inte nödvändigtvis skulle resultera i direkt-kommunikation eftersom företaget finns etablerat på flera orter runtom i världen och därmed jobbar i olika tidszoner.
Kravnamn: Open Group Discussions
C avg: 1.80 M+A avg: 2.82 Diff: 1.02 Count: 16 Var: 8.27 Kommentarer: Likt chatt funktionen så är detta krav ämnat att underlätta kommunikationen mellan personal inom företaget. Diskussionsforumet skulle vara kopplat till en specifik grupp och därmed erbjuda användarna i gruppen att föra diskussion och dela kunskap med varandra. Då företaget är branschledande och innehar väldigt mycket spetskunskap så ansåg vi att detta skulle kunna vara en väldigt givande funktion att ha inom företaget då det skulle uppmuntra kunskapsspridning inom företaget. På grund av detta så försökte vi ta upp detta krav under intervjuerna, vilket också är anledningen till varför 16 av 17
respondenter har svarat på detta krav. Av 16 respondenter så var det 3 som gav detta krav ett negativt värde, anledningen till värderingen var att de ansåg likt chatt funktionen att detta bör hanteras genom en extern tjänst utanför intranätet. De som värderade kravet högt motiverade detta baserat på att det skulle underlätta när man till exempel. behövde hela kontorets feedback kring något att kunna samla in åsikter från ett diskussionsforum. Andra ansåg även att det skulle öka samhörigheten inom företaget att öka
kommunikationsmöjligheterna inom företaget.
Kravnamn: Internal Hosting
C avg: 4.00 M+A avg: 1.00 Diff: -3.00 Count: 6 Var: 4.30
Kommentarer: Detta var ett krav som vi ville få synpunkter kring, även om resultatet av det kanske inte hamnar i kravspecifikationen, då man inte nödvändigtvis bör ta beslut kring hur systemet ska underhållas baserat på vad personalstyrkan tycker. Vi ville dock ta med detta för att höra olika anledningar till varför man ska eller inte ska underhålla systemet lokalt. Utav de sex respondenterna som svarade så var det ingen som kände att något av alternativen var uteslutna, dock värderade den enda chefen detta 4. Motiveringen till detta värde var att man hade mer kontroll över informationen, samt att man genom att “hosta”
systemet externt inte kunde garantera att systemet skulle ha samma “up-time”, alltså att det fanns en större risk att intranätet skulle vara offline vissa perioder.
Kravnamn: Two-factor authentication
C avg: 2.80 M+A avg: 2.43 Diff: -0.37 Count: 12 Var: 6.27 Kommentarer: Två-faktors autentisering innebär att användaren måste autentisera sig via två olika metoder för att få tillgång till systemet. Ett exempel på detta är att man får ett sms med en kod till sitt registrerade telefonnummer och sedan ska skriva in denna kod i
samband med inloggningen till systemet för att verifiera sig från två olika källor (telefonnummer, samt lösenord).
Likt föregående krav så bör dessa värden inte användas direkt till kravspecifikationen då det finns andra faktorer som bör tas i beaktning snarare än företagets genomsnittliga åsikt kring detta. Säkerhetskrav i allmänhet bör inte baseras enbart på medarbetarnas åsikter, utan snarare utifrån säkerhetsklassificeringar av informationen som hanteras på systemet.
De flesta som svarade på detta krav uttryckte att de tyckte att det skulle vara accepterat så länge det endast skulle krävas att man utförde en två-faktors autentisering på nya enheter som inte loggat in på intranätet tidigare. De som värderade detta krav med ett negativt värde ansåg att informationen som fanns på intranätet inte var värd att genomgå en
två-faktors autentisering för att få tillgång till och därmed skulle detta krav leda till minskat användande av systemet.
Kravnamn: VPN requirement
C avg: 2.80 M+A avg: 0.86 Diff: -1.98 Count: 13 Var: 3.86 Kommentarer: I dagsläget för att komma åt intranätet utanför kontoret så krävs det att man använder sig utav en VPN-anslutning, detta var något vi ville undersöka hur personalen förhöll sig till. På samma sätt som kravet på två-faktors autentisering så styrs denna typ av krav snarare av säkerhetsklassificeringen av information samt vart systemet underhålls, snarare än personalens gemensamma åsikt. Likt kravet på två-faktors autentisering så ansåg de flesta att detta skulle vara ett accepterat krav, även om de skulle föredra att det
inte var ett krav för att få tillgång till intranätet. Vissa tog upp att detta skulle kunna bli ett besvär för de som jobbar utanför kontoret, och därmed alltid skulle behöva logga in via en VPN-anslutning.
5. Analys
För att underlätta analysen av skillnader i krav mellan chefer och medarbetare producerade vi två kravspecifikationer; en för varje grupp. Detta gjorde det direkt tydligt att cheferna hade en mindre mängd krav de värderade högt. Värt notera är dock skillnaden i antalet intervjuobjekt inom varje grupp, där medarbetar-gruppen var elva, gentemot chef-gruppen som innehöll sex respondenter. De två kravspecifikationerna som vi producerade liknade varandra till en stor del. I de flesta krav var medarbetare och chefer i samråd. Det fanns inte särskilt många krav där chefer och medarbetare var i direkt motsats till varandra. Däremot kunde de båda grupperna mer eller mindre starkt tala för vissa krav.
Vi har plockat ut vissa krav som vi ansåg intressanta att analysera utifrån de tre problem som kan uppstå vid kravframställning utifrån Davey och Parker (2015). Anledningen till varför vi vill analysera dessa krav är för att (1) de antingen skiljde sig i hur de olika grupperna
värderade kraven eller lyckades identifiera kraven, (2) eller att kraven hade hög varians, vilket betyder att intervjuobjekten hade väldigt delade åsikter om kravet, vare sig det skiljer sig mellan grupperna eller inte. (3) Utifrån intervjuerna så har vi identifierat olika
motiveringar till kravet utifrån perspektiven i varje grupp, vilket vi vill undersöka kopplat till vad som kan vara motiverande faktorer för de olika grupperna.
5.1 Skillnader i krav
De främsta skillnaderna vi observerat utifrån intervjuerna samt de kompletterande frågorna är följande:
Avg avser beräknat genomsnitt. Kursivt avser det ställda kravet (på företagets verksamhetsspråk engelska).
Ability to view/subscribe to other departments/offices - Medarbetare avg 4.2 (10 svar) | Chef avg 2.5 (4 svar)
Medarbetarna var mer benägna att låta intranätet erbjuda användaren möjlighet att ta del av nyheter och information utanför den egna användarens område. Detta resultat baseras mycket på att enbart en av de intervjuade cheferna svarade negativt till detta krav, som menade att det var en onödig risk att öppna upp till en större informationsspridning inom företaget gällande information som inte är relevant för användarens egna arbete.
Skillnaden visad här kan även till en stor del bero på just en individs arbetsområde, mer än den hierarkiska rollen. Vi har ingen annan från samma avdelning som den chefen bland våra intervjuobjekt, varken från chef eller medarbetargruppen, vilket gör det svårt att säga om liknande svar skulle kunna finnas från andra inom avdelningen.
