<p>Programvaruutveckling lider idag av stora problem och många av problemen är kopplade till hur krav samlas in och hanteras. Ett sätt att underlätta kravinsamlingen och att öka kommunikation med kund är att ta fram en prototyp, vilket är en konkret representation av programvaran som ska tas fram. När kravutvinningen har kommit tillräckligt långt kan denna prototyp användas som en del av en kravspecifikation. En vanlig form av kravspecifikation är ett dokument, men även en (exekverbar) prototyp kan vara en effektiv representation av programvaran som ska tas fram.</p><p>I detta arbete undersöks det vilka problem som kan uppstå då en prototyp används som en del av en kravspecifikation. Problem identifieras i litteraturen och intervjuer utförs för att undersöka vilka problem som finns i praktiken. Det visar sig att flera av de problem som litteraturen tar upp inte ses som reella av de respondenter som tillfrågas. Vidare visar det sig att många problem som "borde" uppstå inte gör det på grund av att de tillfrågade organisationerna ofta tillämpar ett mer pragmatiskt än formellt arbetssätt.</p>

Abstract The purpose of writing this thesis was to improve methods during requirements engineering phase. Usercentred system engineering has some problem areas, which are examined and verified to create a new guideline for developers. This guideline tends to make requirements engineering more effective and help developers create more concrete requirements. It is not uncommon that system development projects ends up with unsatisfied users or delay in deliveries. The reasons are different kinds of communication problems between users and developers during verification of requirements. There is a therapy model, called solution-focused therapy, used in family and individual therapy. The model focuses on solutions for the future instead of problems in the past. This method has never been used in system developing until today. Based on literature studies and scenarios we have shown that it is possible to transfer this pedagogy into the system developing branch especially in requirements engineering. During our investigation we have shown that the pedagogy refute the difficulties within usercentred design. The pedagogy model can be used in four kinds of methods for capturing requirements; questionnaires, interviews, workshops and observations. The model activates and makes the user more implicated. To show this, we have applied the pedagogy model on scenarios taken from earlier experiences of requirements engineering. The outcome of this investigation is that developers can create a more pleasant communication atmosphere with this pedagogy. A result of this is that users becomes more willing and helpful to create a new system and therefore makes it easier for developers and users to cooperate. You can avoid many communication problems if you know how to go around them.

Requirements engineering is essential to succeed in developing IT systems that meet the client's expectations and maintaining the budget, which should be considered the goal for an IT-project. Poor requirements engineering is one of the main reasons why IT projects fail. A poorly conducted requirements engineering process can result in several negative consequences, which is common. A well-functioning requirements engineering process can save a lot of money and facilitate achieving good results.In this qualitative case study, we examine how the system providers are using requirements engineering and the problems they experience with this. The aim is to contribute with knowledge about the problems in requirements engineering, what the consequences are and how these can be countered.This qualitative case study was conducted abductivly where empirical data were collected through interviews in two different organizations. The studied organizations are system suppliers within different areas and are in this study anonymous. The empirical data was analyzed and discussed based on relevant theories of requirements engineering and the problems that previous research surveyed. We have found problems and decided to categorize them under the headings; quality of requirements, change, traceability, communication, knowledge, methodology and resources. The results indicate that requirements engineering is a complex subject due to its inconsistent iterative nature and because it involves many different processes and actors. This makes it difficult, but not impossible to succeed in.When problem occurs, they lead to additional costs and delays. To avoid the pitfalls the study has identified, the key is awareness, experience and to follow the ways of work, adapting to situations and constantly try to improve the ways of working.The study's findings does confirm in many cases the difficulties mentioned in previous research, but also points to that there are ways to prevent, deter and prevent these. The importance of following work methods, processes and use appropriate tools becomes clear when the studied organizations emphasize that it is when they depart from these that the problems arise. The study shows that it is possible to achieve a good result with requirements engineering which both previous research and the studied organizations proves.

Denna rapport är skapad som syfte till att redovisa det erhållna resultatet av examensarbete vid Affärssystemprogrammet vid Kungliga Tekniska Högskolan (KTH). Arbetet har utförts som uppdrag för det serbiska företaget Soprex som är en underleverantör till ett svenskt företag. Rapporten är uppbyggd efter IMRAD metoden (Introduktion, Metod, Resultat och Diskussion). Uppdraget var att skapa en kravspecifikation för en modul som är en del av applikationen för hantering av olika kontrakt och prisberäkningar för Soprexs kunds olika kunder. Detta arbete fokuserad på kontrakt modulen. Arbetet har varit uppdelat i tre olika steg, syftet med detta har varit att successivt slussas in i företagets sätt att arbeta och lära känna deras standarder. De tre arbetsstegen har skett oberoende av varandra och har setts som tre skilda uppdrag. Arbetet bygger på den iterativa arbetsmetoden, vilket innebär att varje del har delats upp i mindre delar och slutförts en i taget. Steg ett innehöll arbete med så kallade ”Issues” (problem) som har identifierats och ännu inte dokumenterats i Software Requirement Specification dokument (SRS dokument), resultatet av steg ett blev att dokumentera och placera ut ”Issues” på rätt ställe i SRS dokumentet. Steg två var att skapa ett dokument, en så kallad ”change request”(CR) där skulle kundens krav på förändring av befintligt system dokumenteras. CR dokumentet finns i förenklad version som bilaga (Bilaga 2). Steg tre som var huvuduppgiften, var att skapa en kravspecifikation. Kravspecifikationen som utformades är själva resultatet med arbetet och finns som förenklad version i bilaga (Bilaga 3). Arbetet har inneburit att titta närmare på hur ett företag bygger sina kravspecifikationer, vilka standarder och arbetsmetoder de använder sig av. Arbetet har skett i samarbete med ett utländskt företag, vilket också har medfört att andra skillnader och problem har kunnat identifieras, exempelvis kulturella och geografiska.

In today’s society, IT-Companies often have a hard time estimating changed requirements. This leads to that the clients’ confidence is negatively affected and is one of the main reasons why this has to be improved. The goal with this study was to find out what the most common problems regarding this issue are in IT-companies that works with agile software development. By analyzing one IT-company through a SWOT- and pareto-analysis the most common problems have been ascertained. The SWOT analysis have been created through interviews with selected employees to get a better understanding of the problems that the IT-company is facing. Furthermore was the pareto-analysis based on a survey that was sent out to many different employees to prioritize the problems. The reason why the survey was sent to different employees was to get a more objective input. The study showed that there was many different problems that needed attention. The most important problems was that the communication towards the client regarding requirements needed to be improved, better communication internally between different departments needed to be established, a method to quickly adapt and estimate change in requirements needed to be implemented and finally a method regarding witch key employees whom need to attend the planning of the program backlog. These problems have then been studied through interviews with other IT-companies and through a literature study. The conclusions that where drawn was that the client needs to be involved and updated through the whole project. Constant monitoring and communication regarding changed requirements needs to be processed and mediated. High standards needs to be set early towards the client in order to obtain as clear an image of the requirements as possible. Many different parties need to attend to the planning process for the program backlog before the start of the project. The client needs to be aware of that changed requirements will arise and that this will lead to that the first estimation may not necessarily be absolute. As long as the client is held up to date as well as participant through the whole project and problems are detected and mediated early, change in requirements should not be a huge problem. This is after all the purpose of being agile. / I dagens läge har IT-företag svårt med att estimera förändrade krav vilket medför att förtroendet hos beställaren påverkas negativt och är en av hu-vudanledningarna till att det måste förbättras. Målet med studien har varit att försöka ta reda på de vanligaste problemområdena inom agil systemut-veckling bland IT-företag med hjälp av en SWOT- och pareto-analys. SWOT-analys konstruerades av intervjuer med anställda på ett IT-företag och an-vändes för att ta reda på problemområden. Pareto-analysen användes med hjälp av en enkät som skickades ut till anställda på samma IT-företag för att prioritera problemområdena. Enkätens svar bygger på anställda från de flesta avdelningar, vilket resulterar i en objektivare syn på resultatet. Under-sökningen har visat att det finns många områden som kan förbättras. De huvudsakliga områdena som behövde förbättras var tydligare kommunikat-ion gällande kravhantering gentemot kunden, bättre kommunikation mellan avdelningarna internt i företaget, införa en metod för att snabbt estimera samt anpassa sig till förändrade krav behövde implementeras och slutligen skapa struktur gällande vilka personer som bör delta i planeringen inför program backlog. De fyra största problemområdena har sedan undersökts med hjälp av intervjuer med andra företag och genom en litteraturstudie. Slutsatsen som drogs var att kunden behöver vara involverad och uppdate-rad genom hela projektet. Konstant uppföljning och kommunikation gäl-lande förändrade krav behöver bearbetas och förmedlas. Höga krav måste sättas på kunden i början för att få en tydlig och genomarbetad förståelse för kravspecifikationen som möjligt. Många olika parter bör vara med på planeringen inför program backlog innan projektets uppstart. Kunden bör vara medveten om att förändrade krav kommer att uppstå och att detta kommer att leda till att den första estimeringen inte nödvändigtvis kommer vara absolut. Så länge kunden är uppdaterad och delaktig genom hela pro-jektet och problem upptäcks samt förmedlas tidigt bör förändrade krav inte vara ett stort problem. Det är syftet med att vara agil.

<p>According to statistics, requirements management is identified as a major source of error to failed IT-projects. Moreover communication is identified as a factor affecting the require-ments management and can lead to deficiencies in the requirements. The requirements analyst is responsible for managing the requirements from the different stakeholders, act as a com-munication accommodator and to translate abstract requirements expressed by users to more specific requirements that developers can implement. The purpose of this thesis is to study the role of the requirements analyst to investigate the problems that may arise in working with requirements management.  To achieve the purpose we have performed a requirements management process in which we ourselves took the role as the requirements analysts. The requirements management process consisted of three phases: gather requirements, document requirements and validate require-ments. The result of this study indicates that requirements management is complex because it in-volves different stakeholders with different perspectives and backgrounds. The result of the study is conclusions of the problems we experienced as a requirements analyst and some rec-ommendations on how these problems can be improved.</p> / <p>Enligt statistik identifieras kravhantering som en stor felkälla till misslyckade IT-projekt. Vi-dare identifieras kommunikation som en faktor som påverkar kravhantering och som kan leda till brister i kraven. Kravanalytikern är den som har till uppgift att hantera kraven från de oli-ka intressenterna i ett kravarbete, fungera som en kommunikationsförmedlare och översätta abstrakta krav från användare till mer specifika krav som utvecklare kan implementera.  Syftet med denna uppsats är att studera kravanalytikerns roll för att undersöka de problem som kan uppstå i samband med ett kravarbete.  För att uppnå syftet har vi utfört ett kravarbete där vi själva tagit rollen som kravanalytiker. Kravarbetet bestod i tre faser som syftade till att samla in krav, sammanställa krav och kvali-tetssäkra krav.  Resultatet av denna studie visar att kravhantering är komplext eftersom det innefattar olika intressenter med olika perspektiv och bakgrund. Resultatet av studien är slutsatser vi dragit utifrån våra erfarenheter som kravanalytiker och några rekommendationer på hur dessa pro-blem kan förbättras.</p>

<p>I detta arbete har en undersökning genomförts angående hur spårbarhet upprätthålls vid användning av användarfall. Rapporten behandlar spårbarhet och användarfall separat för att belysa viktiga fakta inom båda områdena. Syftet med arbetet var att ta reda på hur olika tillvägagångssätt för att representera användarfall upprätthöll spårbarhet mellan olika krav, och mellan krav och dess ursprung. Informationen inom problemområdet samlades in genom en litteraturstudie. I undersökningen identifierades flera olika typer av spårbarhet, vilka sedan låg till underlag för identifiering av spårbarhet i användarfall. Undersökningen visade också att det finns flera olika sätt att representera användarfall, i allt från naturligt språk till formella diagram. Resultatet av undersökningen visade även att användningen av ett modelleringsspråk som Unified Modeling Language (UML), med inbyggda relationer och namnkonventioner, gjorde att spårbarhet kunde upprätthållas mellan olika krav, och mellan krav och dess ursprung. En begränsad spåbarhet identifierades i samband med att mindre formella representationer av användarfall använts.</p>

<p>I dagens samhälle spelar informationssystem en viktig roll i de flesta företag och organisationer. Informationssystemets uppgift är att tillgodose och hjälpa användarna med information och informationshantering samt att leda till en effektivisering.</p><p>Arbetet med att utveckla databaserade informationssystem är problematiskt och systemutvecklingsprojekt överstiger ofta budget både vad gäller tid och pengar. Återkommande problem är att systemen inte gör vad användaren vill samt att systemen inte utnyttjas till full kapacitet. Svårigheten med kravhanteringen är något som anses vara en orsak till misslyckandena.</p><p>Den viktigaste informationskällan för systemutvecklarna då det gäller att ta reda på systemkraven är användarna. Då användarna spelar en viktig roll i kravhanteringen, vilken i sin tur spelar en viktig roll i systemutvecklingsprocessen, är detta ett intressant problemområde.</p><p>Denna rapports fokus ligger på hur användarna ser på kravhanteringsprocessen. Syftet med rapporten är att ur ett användarperspektiv utvärdera användarmedverkan i systemutvecklingsprocessens samt att försöka finna om det finns ett samband mellan användares erfarenheter ifrån systemutvecklingsprocessen och deras åsikter kring det färdiga systemet.</p>

Försvarets Materielverk (FMV) är en civil myndighet som sköter all anskaffning av materiel och tjänster åt Försvarsmakten (FM). Vid anskaffning måste de rätta sig efter de upphandlingslagar som gäller i Sverige, bland annat Lag (2007:1091) om offentlig upphandling (LOU) samt Lag (2011:1029) om upphandling på försvars- och säkerhetsområdet (LUFS). För att anskaffningsprocessen ska bli lyckad krävs att FM tydligt definierar det behov de har gällande anskaffning av varor och tjänster. Än viktigare är att FMV bryter ner behoven i väldefinierade och tydliga krav. Detta för att undvika missförstånd och tolkningar som kan leda till att den vara eller tjänst som levereras inte motsvarar behovet. Felaktigheter i krav kan leda till felaktigheter i kontrakt, vilket i sin tur leder till att kontrakten ibland behöver ändras för att den vara eller tjänst det avser ska gå att använda på ett effektivt sätt. Denna ändring i kontrakt kallas av FMV för kravglidning. Syftet med denna rapport är att identifiera förekomsten av kravglidning vid anskaffningar genomförda av FMV sedan november 2011.

According to statistics, requirements management is identified as a major source of error to failed IT-projects. Moreover communication is identified as a factor affecting the require-ments management and can lead to deficiencies in the requirements. The requirements analyst is responsible for managing the requirements from the different stakeholders, act as a com-munication accommodator and to translate abstract requirements expressed by users to more specific requirements that developers can implement. The purpose of this thesis is to study the role of the requirements analyst to investigate the problems that may arise in working with requirements management.  To achieve the purpose we have performed a requirements management process in which we ourselves took the role as the requirements analysts. The requirements management process consisted of three phases: gather requirements, document requirements and validate require-ments. The result of this study indicates that requirements management is complex because it in-volves different stakeholders with different perspectives and backgrounds. The result of the study is conclusions of the problems we experienced as a requirements analyst and some rec-ommendations on how these problems can be improved. / Enligt statistik identifieras kravhantering som en stor felkälla till misslyckade IT-projekt. Vi-dare identifieras kommunikation som en faktor som påverkar kravhantering och som kan leda till brister i kraven. Kravanalytikern är den som har till uppgift att hantera kraven från de oli-ka intressenterna i ett kravarbete, fungera som en kommunikationsförmedlare och översätta abstrakta krav från användare till mer specifika krav som utvecklare kan implementera.  Syftet med denna uppsats är att studera kravanalytikerns roll för att undersöka de problem som kan uppstå i samband med ett kravarbete.  För att uppnå syftet har vi utfört ett kravarbete där vi själva tagit rollen som kravanalytiker. Kravarbetet bestod i tre faser som syftade till att samla in krav, sammanställa krav och kvali-tetssäkra krav.  Resultatet av denna studie visar att kravhantering är komplext eftersom det innefattar olika intressenter med olika perspektiv och bakgrund. Resultatet av studien är slutsatser vi dragit utifrån våra erfarenheter som kravanalytiker och några rekommendationer på hur dessa pro-blem kan förbättras.