Krav är nödvändiga egenskaper hos en produkt för att på bästa sätt tillfredställa en slutanvändare. I takt med att antalet kunder ökar, ökar även mängden krav. I dagens samhälle är det inte helt ovanligt att ett system har en koppling till internet och därför även dess applikationer. Vidare får internet en allt större inverkan på vår vardag, vilket gör att krav och behov behöver tillfredställas för en allt bredare publik. Detta ställer högre krav på en fungerande och tillförlitlig webbutveckling samt en förmåga att kunna se till alla intressenters behov och önskningar i takt med att dessa bara blir fler och fler.    Behovet av en fungerande och tillförlitlig kravhantering har ökat. I och med att dagens webbutvecklingsföretag inte tycks lägga tillräckligt med tid och fokus på behov har det medfört problem. Webbutvecklingsföretagen ser oftast främst till designen av produkten och inte till de bakomliggande kraven. Den ”riktiga” målgruppen tycks alltså inte vara i fokus. Det bidrar till att problem inom kravelicitering existerar. Trots vetskapen om dessa problem läggs inte tillräckligt med tid och resurser på forskning för att minimera dem.   Vårt syfte med studien är därför att undersöka vilka problem som förekommer i dagens kravinsamlingsmetoder samt se till hur dessa hanteras. Vi vill sedan verklighetsförankra detta genom en empirisk studie av två olika webbyråer i Linköping. Verklighetsförankringen innebär att vi ska analysera hur dessa företag hanterar de problem som den genomförda litteraturstudien visar finns.   Utifrån resultatet av denna studie kan vi konstatera att det idag inte finns någon problemhanteringsmetod inom kraveliciteringsfasen som alltid fungerar. Att det i dagsläget inte finns någon sådan metod beror på att webbutveckling är en alldeles för oförutsägbar bransch där varje projekt är unikt.   Det kvarstår dock många problem och det är av stor vikt att påvisa dessa. Studiens resultat visar att en förstudie, i många fall, minimerar dessa problem samt att ett iterativt arbetssätt kan fungera för att hantera dem.   Avslutningsvis ges ett förslag till vidare studier då kravelicitering, främst inom webbutvecklingsprojekt, är relativt outforskat och dynamiskt. Det innebär att vidare forskning kommer att behövas.

Teracom ansvarar för underhåll, drift och kundstöd för Rakelnätet sedan 30 mars 2015. RAKEL är ett kommunikationssystem som används av medarbetare inom samhällsviktiga verksamheter. Teracom har ett system som tar emot data av trafiken över RAKEL. Datan används av Teracom för att skapa grafiska presentationer för att presentera för kund hur trafikbelastningen i Rakelnätet visat sig vid en speciell händelse. En speciell händelse kan exempelvis vara ett sportevenemang eller en bilolycka där olika samhällsviktiga verksamheter samverkar. Om den grafiska presentationen visar oväntad hög trafikbelastning, undersöker Teracom om allt gick som det skulle i Rakelnätet. Den grafiska presentationen används också om Teracom fått indikation på att det kan ha varit ett allvarligt fel någonstans, presentationen används då som en del i processen att reda ut vad som är fel. Den grafiska presentationen kan i skrivandes stund skapas med det inbyggda systemet som tar emot data eller med hjälp av Excel och Excels pivottabell vilket anses vara tidsförödande och krångligt. I den här studien redogörs för det nuvarande sättet att framställa en grafisk presentation för att reda ut vad Teracom ställer för krav på ett nytt verktyg som ska underlätta tillvägagångssättet att skapa den grafiska presentationen. Syftet med uppsatsen är att identifiera Teracoms behov av och krav på, ett nytt verktyg för visualisering av normal trafikbelastning och trafikbelastning vid speciella händelser i Rakelnätet. Uppsatsen skall fungera som vägledning för Teracom vid anskaffning av rekommenderat verktyg. Studien har uppfyllt syftet genom en fallstudie på Teracom där data samlats in genom en kravinsamlingsintervju, en telefonintervju och prototyper. Studien har resulterat i följande centrala krav som Teracom ställer på den här typen av verktyg. • Enkelhet att skapa standardgrafen • Optimala grafer skapade för att detektera mönster • Dynamiska grafer för att underlätta analys Vid utformning av visualisering för att mottagaren enkelt ska tolka och förstå denna har studien kommit fram till följande punkter. • Välja rätt graf • Visa trender • Undvika överflödighet • Omfattande och informativ Resultatet av studien är att Tableau är det verktyget som är det mest lämpliga utifrån Teracoms krav och behov på ett nytt verktyg för visualisering av trafikbelastning.

Att arbeta agilt är idag vanligt förekommande inom IT-branschen där företag ständigt måste anpassa sig till förändringar. Scrum är idag den främst tillämpade agila metoden och har stark koppling till utvecklingsprojekt och kravhantering. Trots detta finns det få empiriska studier om Scrum och det finns även en brist på jämförande studier som ställer kravhantering i praktiken mot det som finns formulerat i litteraturen. Vi har därför i denna studie undersökt hur arbetet med kravhantering i utvecklingsprojekt bedrivs i praktiken hos en organisation som arbetar efter Scrum och jämfört om arbetet utförs i enlighet med det som står i litteraturen. Vi har även tittat på vilka problem och svårigheter som kan uppkomma i kravhanteringsarbetet samt vilka aspekter som utövarna i praktiken betraktar som viktigast. För att ta reda på hur arbetet faktiskt genomförs intervjuade vi fyra personer på företaget Arris, alla med olika befattningar och kopplingar till kravhantering.   Slutsatsen av undersökningen visar att kravhanteringsarbetet i praktiken i de flesta aspekter överensstämmer med det som formuleras i litteraturen. Det finns dock områden som ej går helt i linje, dokumentation av krav är ett sådant. / Working agile is nowadays common within the IT industry where companies constantly have to cope and adapt to change. Scrum is today the most applied agile method and is strongly linked to development projects and requirements engineering. Despite this, there are few empirical studies on Scrum and it also lacks comparative studies where requirements engineering in practice are compared to what is formulated in the literature. As a result of this, we have in this survey, examined how requirements engineering in an organization that is using Scrum is conducted in practice in accordance to what is formulated in the literature. We also identified problems and difficulties that may arise in the work with requirements engineering and also which aspects practitioners considers as most important. In order to be able to realize this study we interviewed four practitioners from Arris, all with different positions and connections to requirements engineering. The conclusion of this study shows that the requirements engineering in practice in most aspects is consistent with what the literature advocates. However, there are areas that not fully correspond to what is written in the literature, documentation of requirements is one such area.

No description available.

Bakgrund: Arbetsrelaterad stress kan definieras som obalans mellan de förväntade kraven som ställs på individen samt dennes förmåga att hantera de ställda kraven. Forskningen har hittills visat att stressproblematiken har ökat både i Sverige och omvärlden. Det är ett växande fenomen som påverkar negativ individens arbetssätt och privatliv. Arbetsrelaterad stress har ökat särskilt bland socialarbetare jämfört med andra yrken. De senaste åren har det skett stora förändringar inom välfärdssektorn. På grund av omstrukturering inom välfärden ställs högre krav på socialarbetare. Konsekvenserna av dessa krav främjar ohälsan, vilket leder till flera sjukskrivningar, utbrändhet samt stress. Syftet: Syftet med denna studie är att undersöka socialarbetares upplevelser av arbetsrelaterad stress i förhållande till deras arbete vid Socialtjänsten i en mellanstor stad i Sverige. Metoden: Är en kvalitativ intervjustudie. Individuella intervjuer anses vara mest lämpliga för att på bästa sättet besvara studiens syfte och frågeställningar. Resultat: I denna studie visar att ökning av arbetsbelastning, komplexitet av arbetsuppgifterna, tidsbrist samt missnöje är några bidragande faktorer till arbetsrelaterad stress. Vidare visar studien att sådan stress påverkar negativ hälsan och gör att arbetskvalitet blir sämre. Dessutom visar studie att kollegialt stöd och färre antal arbetstimmar kan minska arbetsrelaterad stress. Slutsats: Baserade på de erhålla resultaten kan man dra en slutsats att socialtjänsten är underbemannad. Arbetsrelaterad stress är vanligt förekommande och nästintill accepterad som ett faktum bland socialarbetare. För övrigt en annan slutsats som kan dras av denna studie är att det i nuläget råder ett tillfredställande kollegialt stöd i den organisationen där studien utfördes. Kollegialt stöd verkar vara en skyddande faktor gällande uppkomsten av arbetsrelaterad stress. / <p>2018-01-19</p>

Det problemområde som behandlas i arbetet är den del av systemutvecklarens arbete avsett att hantera förändringar i kravbilden under systemutvecklingens hela livscykel, kallat Requirements Management (RM). Arbetet fokuseras på detaljer kring spårbarhet inom förändringshantering. För att lyckas i spårbarhetsarbetet gäller det för systemutvecklaren att se hur de olika krav som finns i kravbilden är relaterade till varandra och var kraven har sitt ursprung. Det skiljs inom spårbarhetsområdet mellan framåt- och bakåtriktad spårbarhet. Vardera spårbarhetsriktningen delas sedan in i två steg från kravursprung framåt via kravdokumentation till realisering då det gäller den framåtriktade och från realisering via kravdokumentation till kravursprung då det gäller den bakåtriktade. En studie har genomförts där litteraturens syn har jämförts med ett antal respondenters då det gäller att dels kartlägga vilka typer av spårbarhet som behövs inom systemutvecklingsprojekt och dels vilket stöd som behövs för att etablera och underhålla denna spårbarhet.

Det är idag fortfarande en stor del av alla IT-projekt som misslyckas och kravhanteringen har fått en större betydelse för om ett IT-projekt ska lyckas eller inte. För att en större möjlighet till att ett IT-projekt ska lyckas används kravinsamlingsmetoder, dock är det viktigt att rätt kravinsamlingsmetod väljs till det specifika projektet. Om fel kravinsamlingsmetod väljs från början kan detta ledda till en misslyckad systemimplementation. Därför har författaren av rapporten valt följande huvudproblemfråga att undersöka i denna uppsats: Vilka råd rörande metodval kan ges till organisationer som ska implementera och välja en kravinsamlingsmetod? Med hjälp av enkäter och djupare intervjuer har författaren samlat in tillräckligt med material för att spegla de svar som framkommit i slutet av rapporten. Undersökningen ledde till att författaren skapade en ram som speglade ett antal punkter som är viktiga att tänka på vid valet av kravinsamlingsmetod.

Testning av programvara utgör i många fall en stor del av den totala utvecklingstiden. Då testning drar mycket resurser finns det en önskan om att testningen ska kunna utföras så effektivt som möjligt. Ett steg mot en effektivare testning är automatisering, då detta, om korrekt utfört, medför att fler fel kan identifieras på kortare tid. Det finns däremot risker och fallgropar på vägen mot automatiserad testning. I det här arbetet ges en översikt av 21 krav som forskning och litteratur ställer på en utvecklingsprocess för att automatiserad testning ska kunna genomföras lyckat. Därefter presenteras en metodik som tagits fram för hur översikten kan användas i en organisation för att få en lägesbild av möjligheterna till automatisering. Denna metodik har validerats i en fallstudie, som påvisat att kraven tillsammans med metodiken kan användas för att diskutera en organisations möjligheter till automatiserad testning.

I detta arbete har vanligt förekommande krav på IP-telefonilösningar identifierats via litteraturstudier. Därefter har en testmiljö skapats där ett urval av mjukvaror har utvärderats med avseende på funktionalitet och dokumentation. Kraven som ställts relaterar till säkerhet och kvalitet samt den funktionalitet som krävs för att motsvara den hos det vanliga telefonnätet. Mjukvarorna som presenteras är 3CX, Asterisk, sipXecs och Switchvox. Urvalet av mjukvaror är baserade på antingen öppen källkod eller proprietära motsvarigheter. Faktorer som möjlighet till support och användarvänlighet har också belysts. De mjukvaror som presterar bäst utifrån givna parametrar är 3CX och Asterisk. Arkitekturen mellan de två mjukvarorna olika och båda kan ha fördelar beroende på struktur och kompetens hos det specifika företaget.

Allt för ofta händer det att systemutvecklingsprojekt misslyckas. Ofta beror dessa misslyckanden på att systemutvecklingsprocessens tidiga faser utförs bristfälligt. Genom att ta tillvara och återanvända information som uppkommit under tidigare utförda informationssystemutvecklingsprojekt, ökas chansen att nästa informationssystemutvecklingsprocess får ett bra resultat. En kravspecifikation som endast innehåller krav som måste uppfyllas av alla informationssystem inom en specifik domän, går att tillämpa vid all informationssystemsutveckling inom denna specifika domän. För att denna kravspecifikation skall kunna användas på detta vis, krävs det att uppdateringar sker i denna allt eftersom aktuell domän förändras. Huvudsyftet med denna rapport är att presentera ett möjligt tillvägagångssätt för att skapa en kravspecifikation som endast innehåller krav som måste uppfyllas av alla informationssystem inom en specifik domän. Denna rapport syftar även till att förklara vilka problem som kan uppkomma under framtagandet av en sådan kravspecifikation samt hur dessa problem kan reduceras. För att kunna framställa denna information, har bland annat en fallstudie på ett stort företag som egenutvecklar informationssystem utförts. I slutet av denna rapport presenteras en modell över ett rekommenderat tillvägagångssätt vid skapande av en kravspecifikation som endast innehåller krav som måste uppfyllas av alla informationssystem inom en specifik domän. Denna modell är framställd med erfarenheter från den utförda fallstudien som grund.