Ett effektivt användande av ett informationssystem förbättrar informationshanteringen inom en verksamhet. För att ett informationssystem ska kunna fungera effektivt krävs att det motsvarar de krav som ställts på informationssystemet av olika intressenter. Requirements Engineering (RE) är en viktig del av systemutvecklingsprocessen för att kunna säkerställa en väl fungerande kravhantering. Use case är en teknik som kan användas som hjälpmedel i RE-processen för att identifiera och dokumentera krav. Syftet med detta examensarbete är att undersöka om use case är tillräcklig som enda teknik för att identifiera och dokumentera krav samt vilka eventuella kompletterande tekniker som används bland systemutvecklare. Resultatet av undersökningen visar att use case-tekniken inte är tillräcklig utan måste kompletteras med andra tekniker för att möjliggöra att samtliga krav kan identifieras och dokumenteras.

Systemutveckling gentemot försvarsindustrin kan i många fall bli komplext och innefatta väldigt stora projekt. Samtidigt har utvecklingen av modelleringsverktyg fortsatt och användningen av modellering har blivit ett potentiellt verktyg för att garantera kvalitativa kravdokument.Studien har studerat vilka för- och nackdelar det finns med att arbeta modell- respektive dokumentbaserat i projekt gentemot försvarsindustrin. Modellbaserat refereras i rapporten som användning av modeller för att skapa kravdokument medan dokumentbaserad utveckling innebär en mer traditionell syn på utvecklingen där krav formuleras i fritext och sedan lämnas över till ansvariga för implementering.Studien har med hjälp av intervjuer som främsta datainsamlingsmetod med projekt involverade i utveckling av system gentemot försvarsindustrin identifierat fördelar och nackdelar med de båda respektive metoderna. Studien har kommit fram till att arbeta modellbaserat garanterar en hög kvalitet och har en förmåga att hantera en hög komplexitet, däremot är metoden mer beroende av verktyg och kompetens jämfört med dokumentbaserad utveckling. Den dokumentbaserade utvecklingsmetoden karaktäriseras av att vara en enkel metod utan något specifikt verktygsberoende, däremot har metoden visat sig vara olämplig för komplexa och stora projekt där spårbarhet i kraven är kritisk.

En produktkonfigurator är en typ av informationssystem som skall stötta konfigurationsprocessen, det vill säga sammansättning av komponenter till en kundanpassad produkt. Ett sådant system har till uppgift att hitta en giltig och komplett specificerad produkt bland alla möjliga alternativ som matchar kundens behov. Flera produktkonfiguratorer finns tillgängliga på marknaden idag. Svårigheten med dessa är att de alla tillhandahåller olika modelleringsansatser och funktioner som gör det svårt för företag att välja det system som matchar bäst. Trots de uttryckta svårigheterna tycks det saknas tydliga riktlinjer för hur en tillverkande industri som står inför valet av produktkonfigurator kan få insikt i detta. Syftet med denna studie är därför att, via samarbete med företaget SOMAS Instrument AB, föreslå en modell som kan användas för att tydliggöra de behov och krav som bör styra valet av produktkonfigurator, samt identifiera de aspekter som behöver tas i beaktning i samband med detta. Studien är en aktionsbaserad fallstudie som tillämpat en modell, baserad på tre teoretiska perspektiv, hos företaget SOMAS Instrument AB. SOMAS utvecklar, producerar och marknadsför regler- och avstängningsventiler. Företaget jobbar till stor del med kundanpassning av sina produkter och skulle därför kunna anses ha ett stort behov av en produktkonfigurator. Studien har resulterat i en förstudierapport och kravspecifikation över SOMAS behov och krav på en produktkonfigurator, samt resulterat i intervjusvar från systemleverantörer inriktade på produktkonfigurering. Utifrån insamlade resultat och erhållna erfarenheter har ett förslag på en modell bearbetats fram, som kan tydliggöra de behov och krav som bör styra valet av produktkonfigurator. Denna modell innefattar en lista med aspekter att särskilt ta i beaktning inför valet. Studien visar bland annat att leverantörens kunskap och erfarenhet inom företagets verksamhetsområde samt företagets produktionsstrategi är av stor relevans att beakta.

Kravhantering är en väsentlig del i systemutvecklingsprojekt och något som teori förespråkar att stor vikt bör läggas på om projekt ska lyckas. Statistik och undersökningar påpekar emellertid att kravhantering länge varit bristfällig och att den troligtvis fortfarande är det, samt att för lite resurser läggs på kravhantering. Syftet med uppsatsen är att granska kravhantering i praktiken på företag inom systemutvecklingsbranschen och se hur det förhåller sig till teorin. Målet är att kartlägga hur man idag ser på kravhantering, hur man arbetar med det, samt uppmärksamma förekommande brister och svårigheter.   För undersökningen som uppsatsen bygger kring har positivistisk deduktiv ansats anammats. Målet är att granska verkligheten utan att söka svar, försöka förstå eller undersöka orsakssamband. Syftet är att jämföra resultatet med påståenden från teori och tidigare fakta. Metod som använts för datainsamling är kvalitativ undersökning i form av personliga semistrukturerade intervjuer. Resultatet av undersökningen tyder mångfalt att kravhantering är så pass viktigt som det påstås och att medvetenhet gällande detta existerar. Satsningar och genomföranden är emellertid ändå ofta bristfälliga. Agil projektmetodik verkar förekomma allt mer, men generella tillvägagångssätt för själva kravhanteringen förekommer sällan, utan anpassas efter projekten. UseCase används ofta som kravspecifikation, men utformningen på dessa är projektanpassade. Brister och svårigheter i kravarbete är flera och hänger inte sällan ihop med varandra.   I förhållande till den kravproblematik som uppmärksammats i teorin visade sig 68 % finnas representerade i undersökningsobjekten. Målet med uppsatsen är att bidra till ökad medvetenhet om vikten av kravhantering och problematiken kring dess brister. / Requirements management is an essential part of systems development and something that theory favor should have great emphasis for projects to be successful. However, statistics and surveys indicates that requirements management have been inadequate for a long time and that it probably still is, and that insufficient resources are devoted to requirements management. The purpose of this paper is to review how the requirements management is approached in practice at companies within the systems development industry to see how it relates to theory. The goal is to identify the way one look at and work with requirements management today, and try to identify deficiencies and difficulties. The underlying survey which this essay is based on has a positivist deductive approach. Goal for this paper is to examine the reality without looking for answers, trying to understand or explain the causality. The aim is to compare the result with claims from theory and previous facts. The method for data collection is qualitative research in the term of personal semi-structured interviews. The survey results clearly show that requirements management is as important as it is claimed to be, and that awareness of the problem exists. Investments and realizations is however still often inadequate. Agile project methodology appears to be increasing, but having a general approach for handling the requirements management is rare and it’s often tailored for each project. UseCase is often used for requirements specifications, but the design is mostly adjusted for each project. Shortcomings and difficulties in the work with requirements are many and they are often linked to each other. In relation to the problems with requirements highlighted in theory, it turned out to be 68 percent that was represented within the survey objects. The overall goal with this paper is to contribute to the increased awareness of the importance of requirements management and the issues related to its shortcomings.

Det är en utmaning att möta de olika behov och krav som finns vid utvecklingen av intranätsom kan vara ett stort och komplext IT-system. Intranät har ofta många olika typer avanvändare med olika behov. Användare vill ofta vara med och bidra till utvecklingen av ITsystemmen har inte alltid tid eller tror att de inte har tillräcklig kompetens för att bidra mednågot konstruktivt. För att lyckas med utvecklingen av intranätet behöver IT-avdelningen haeller skaffa sig ett brett perspektiv över problemsituationen samt reda ut vilka behov somfinns. Syftet med denna studie är att ta reda på vilken typ av utmaningar som finns vidutveckling av ett intranät. / It is a challenge to meet the different needs and requirements that exist in the development ofintranets. Intranets often have many different types of users with different needs and this isone reason why intranets can be complex IT-systems. Users want to be part of thedevelopment but do not always have the time or think that they do not have the right skills tocontribute something to the development. To succeed in the development of the intranet, theIT department needs to have or acquire a broad perspective on the problem situation and sortout what the users needs are. The purpose of this study is to find out what kind of challengesexist in the development of an intranet.

Idag är det mycket vanligt att företag och organisationer använder sig av affärssystem för att kunna underlätta och stödja sina affärsprocesser. Affärssystemet fungerar som ett slags kärna i företaget eller organisationen, och det huvudsakliga syftet är att stödja alla huvudfunktioner och integrera flödet av data. Det händer än idag att IT-projekt misslyckas i hög grad, och de största orsakerna till det anses vara bland annat att företaget får prioriterade förändringar, dålig kommunikation, och inkorrekt kravinsamling. Orsaker som leder till en inkorrekt kravinsamling kan vara bland annat att det uppstår missförstånd och tvetydigheter i kraven. Missförstånd och tvetydigheter kan uppstå genom bland annat en sämre förmåga att kommunicera hos de involverade parterna, att båda parter inte har en samsyn i språket eller de begrepp som används, eller att rätt kompetens eller rätt personer inte finns tillgängliga i projektet. Uppsatsens syfte är att identifiera och beskriva framgångsfaktorer för att minska risken för missförstånd och tvetydigheter i kravinsamlingsprocessen, ur ett kund–systemleverantörsperspektiv. Kravinsamlingsprocessen syftar på den kravinsamlingsprocess som genomförs i systemutvecklingsprojekt. Den metod som har använts i denna uppsats är fallstudiemetoden. Två fall, i form av kund-projekt, har studerats hos fallföretaget och skarpa intervjuer med semi-strukturerade intervjuguider som underlag har genomförts. Intervjuerna gjordes med två systemleverantörsföretag och ett kundföretag till respektive systemleverantörsföretag. De viktigaste slutsatserna från uppsatsstudien för att kunna minska risken för missförstånd är att kommunikationen är A och O, det behövs en samsyn i språk och begrepp, det är viktigt med kompetensbredd och tillgång till rätt kompetens, samt att kunna avsätta tid. Kommunikationen är helt avgörande när det handlar om att kunna minska risken för missförstånd och tvetydigheter. Båda parter i ett kund- och systemleverantörssamarbete behöver ha förmågan att kunna kommunicera, och även göra det på ett sätt som passar båda parter. Förutom att kunna kommunicera är det också viktigt att båda parter har en samsyn i språk och begrepp. Ett begrepp hos kunden kan betyda något helt annat för systemleverantören, och begrepp kan också ha flera olika betydelser, vilket är viktigt att reda ut tidigt i kravinsamlingsprocessen. Eftersom kunden besitter mer verksamhetsmässig kompetens och systemleverantören mer teknisk kompetens finns det också en stor risk att de talar olika språk, eftersom systemleverantören tenderar att använda mer tekniska begrepp och kunden använder dennes verksamhetsbegrepp. Även kompetensbredd och tillgång till rätt kompetens är viktigt, därför att ett system ofta påverkar i stort sätt hela verksamheten, men det är inte alltid personer från verksamhetens alla delar som deltar i projektet. Därmed är det viktigt att kunna ha tillgång till personer från de olika delarna, för att till exempel ta reda på arbetssätt. Det är också viktigt, för båda parter, att kunna avsätta tid. Det är viktigt att hålla kravspecifikationen uppdaterad med de aktuella kraven, för att inte riskera att utvecklingen tar en annan väg än mot den gemensamma målbilden.

Cloud services and solutions have served as a shift in the computer industry and create new opportunities for users. Clouds have been described as easily usable and fluid in terms of expansion and contraction depending on the real-time needs. Although the cloud is promoted with several benefits, it is not always apparent for the users that this is the case. Understanding both the benefits and challenges that exist is substantial for a successful adoption to cloud. This master’s thesis is conducted in collaboration with Exsitec ABand aims to investigate how the adoption of the cloud service Microsoft Azure will affect the development process. Also, it aims to provide a best practice for potentially needed updated working procedures, in terms of satisfaction and learnability. The investigation was performed through interviews and the System Usability Scale, to assess how the end users experienced development in a cloud environment. The thesis revealed that the Azure portal has low overall usability, but that there also exists an inconsistency of that perception. Two major factors that contributed to the satisfaction and learnability was the lack of documentation and that the Azure portal was considered hard to master. The SUS score revealed that the mean value was below an acceptable level, and thus changes in the company’s working procedures need to be implemented. Internal documentation regarding how the company should use both cloud in general, as well as the portal in particular, are required in order to increase the learnability and subjective satisfaction.

Syftet med denna uppsats är att undersöka vilka nya krav som kan tänkas uppstå i och med det nya dataskyddsdirektivet, och hur uppfyllandet av dessa krav kan underlättas, i form av riktlinjer utformade för att säkerställa en systemutveckling i enlighet med de säkerhets- och integritetskrav som ställs i och med GDPR. De behov och kravområden som identifierats, har sedan kategoriserats och konkretiserats i form av riktlinjer som skall kunna användas då personuppgifter hanteras. För att belysa hur GDPR kan förändra kravbilden har främst “Privacy by Design”, kravspecificering, samt de allmänna juridiska förändringar GDPR kommer att innebära studerats. För att besvara uppsatsens syfte och frågeställningar har en studie baserad på främst semistrukturerade intervjuer utförts. Detta för att identifiera potentiella nya krav som kan tänkas uppstå i och med det nya dataskyddsdirektivet. Med avstamp i teorin, samt intervjuunderlaget har sex stycken kategorier tagits fram. Dessa är samtycke, Privacy by Design, rätten att bli meddelad om intrång, rätten att bli glömd, dataportabilitet samt rätten till åtkomst. Dessa kategorier har sedan legat till grund för de riktlinjer som utgör resultatet av detta arbete.

I alla systemutvecklingsprojekt har kravhanteringen en stor inverkan på projektets framgång. Hela 56 procent av källor till fel inom informationssystem kommer från brister i kravhanteringen. Trots att de finns många metoder för kravhantering används inte dessa i speciellt stor utsträckning och vidare pekar forskningen på flera orsaker varför de inte används. En orsak är att systemutvecklare tenderar att lägga större vikt på tekniska funktioner och begränsningar än sociala aspekter, vilket ses som en orsak till att traditionella kravanalysmetoderna misslyckas. Det ses även som allmänt känt att grunden till en lyckad systemutveckling ligger i att förstå de sociala och organisatoriska aspekterna. För att åstadkomma ett så användbart system som möjligt är det därmed viktigt att involvera användare i utvecklingsprocessen. Statistik visar dock att en stor del av användare inte får vara med och påverka arbetet alls. Studien syftar till att utforska och beskriva kravhantering i praktiken med särskilt fokus på användarinverkan. Metoden för studien har varit kvalitativ och datainsamlingen har skett med semistrukturerade intervjuer med respondenter från tre företag. Respondenterna utgjordes av fyra praktiker som arbetar med kravhantering inom systemutvecklingsprojekt och de resterande tre respondenterna är användare för dessa system. Empirianalysen redogör för studiens resultat som jämförs med teorin för att belysa intresseväckande eller viktiga kopplingar till hur praktiker anammar kravhantering i praktiken och hur användare involveras i denna process. Empirianalysen visar att praktiker mer tenderar att inspireras av kravhanteringsmetoder än att anamma dessa helt och hållet. Analysen visar även att standarder för kravhantering är bristfälliga i praktiken. Vidare visar studien att så kallade superusers har större möjlighet än andra användare att påverka kraven och att kommuniceringen av krav från utvecklare till användare kan förbättras. Det finns helt klart utvecklingspotential när det gäller att involvera fler användare för att undvika misstolkade eller uteblivna krav. / In every project within systems development, managing requirements in a proper way has a major impact on a project’s success. A total of 56 percent of sources of errors in information systems is a result of shortcomings in requirements engineering (RE). Although there are many methods for managing requirements, these methods are not used to a large extent, and furthermore research results within requirements engineering points to several reasons why they are not used. A reason is that system developers tend to focus on technical features and constraints, which is seen as a reason for the failure of traditional RE-methods. It is also widely known that the foundation of successful system development lies in understanding the social and organizational aspects. In order to provide a useful system, it is therefore important to involve users in the development process. However, there are statistics that shows that a large proportion of users are not involved within the process of requirements engineering. The study aims to explore and describe requirements engineering in practise with particular focus on user impact. The methodology for the study has been qualitative and data collection has been performed with semi structured interviews with respondents from three companies. The respondents consisted of four practitioners who work with requirements engineering in system development projects and the remaining three respondents are users of these systems. The empirical analysis presents the result of the study and is compared to the theory to highlight interesting or important links between how practitioners apply requirements engineering in practice and how users are involved in this process. The empirical analysis shows that practitioners more likely tend to be inspired by requirements engineering methods than to embrace them entirely. The analysis also shows that requirements engineering standards are inadequate in practice. Additionally, results of the study indicate that super users have greater potential to influence the requirements than other users and that the communication of requirements between system developers and users can be improved. It is clear that there are a lot of potential when it comes to involve users in order to avoid misinterpretation or missing requirements.

Studien består av en jämförelse av det traditionella arbetssättet,vattenfallsmodellen, och den agila modellen. Studiens fokus ligger påatt undersöka skillnaderna som finns mellan modellerna när detkommer till kravhanteringen och hur man arbetar med att uppfyllakraven. Fokus ligger också på att undersöka varför vissa projektföredrar att arbeta efter vattenfallsmodellen, istället för att använda denagila modellen.Undersökningen består av en litteraturförstudie och semistruktureradeintervjuer med personer som har erfarenhet av båda modellerna.Resultatet av de semistrukturerade intervjuerna sammanställs ochjämförs med resultatet från undersökningen, detta för att kunna besvarafrågeställningarna.Resultatet visar att de skiljer sig markant i kravhanteringen och hur manarbetar med att uppfylla kraven i det olika modellerna.Detta bidrar till att det skiljer sig mycket vilken modell som föredras.Ett exempel som kom fram under intervjuerna är att inom vissa delar avmedicinbranschen så krävs det ett omfattade förarbete då det är olikalagar i olika länder.Det visa sig att statliga och privata verksamheter inte spelar in i valet avmodell utan att det som avgör vilken modell som föredras är vilken typav projekt. Vilken typ av miljö som projektet utförs i spelar också en storroll.Vattenfallsmodellen föredras i projekt som styrs av lagar och regelverkeller om det är väldigt specifika krav. Agila modellen föredras då det ärfriare projekt där lagar och regler inte måste tas i hänsyn på samma sätt. / The study consists of a comparison on the traditional way of working,the waterfall model, and the agile model. The focus of the study is toexamine the differences that exist between the models when it comes torequirements management and how to work to meet the requirements.The focus will also be on examine why some projects prefer to workaccording to the waterfall model, instead of switching to the agilemodel.The survey consists of a literature pre-study and semi-structuredinterviews with people who have experience of both models. The resultsthat where collected from the semi-structured interviews have beencompiled and compared whit the results which were collected from thesurvey in order to be able to answer the questions.The results show that they differ markedly in the requirementsmanagement and how to work with meeting the requirements in thedifferent models. This contributes to the fact that there is a lot ofdifference in which model that is preferred. An example that emergedduring the interviews was that in certain parts of the medical industry,extensive preparatory work is required as there are different laws indifferent countries.It turned out that government and private activities do not play a role inthe choice of model, but that what determines which model is preferredis the type of project. The type of environment in which the projectconsists also plays a major role.The waterfall model will be preferred in projects governed by laws andregulations or if there are very specific requirements. The agile model ispreferred when the projects is freer and where laws and regulations donot have to be taken into account in the same way.