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.

Usability is an important aspect of product development that deals with the quality of interaction between the user and the product. Capturing requirements is aimed at understanding what the users expect the system to do. This report attempts to apply principles from both the Usability Engineering and the Requirements Engineering methodologies in the development of a subsystem for managing an e-commerce solution. The main focus is on the user interface design, which is developed by iterating the three phases of design, usability testing and evaluation, until the desired level of usability is achieved. Prototyping was central to the rapid development, but the use of software prototyping tools instead of paper-mockups would reasonably have improved the usefulness of the evaluations. The desired usability level was set to reach a specified fix point, instead of attempting to achieve some absolute usability metrics as is typically practiced. The former approach was apparently simpler to use without the broader experience otherwise needed to write reasonable requirements. The transition from the throw-away prototype to the implemented evolutionary prototype in ASP.NET posed some interesting problems that are further discussed.

Requirement engineering is the most significant part of the software development life cycle. Until now great emphasis has been put on the maturity of the functional requirements. But with the passage of time it reveals that the success of software development does not only pertain to the functional requirements rather non-functional requirements should also be taken into consideration. Among the non-functional requirements usability, performance, safety and security are considered important. Further it reveals that there exist so many modeling and testing techniques for functional requirements but the area of non-functional requirements is still deprived off. This is mainly due to difficulty, diversity in nature and hard to express for being domain-specific. Hence emphasis is put to the development of these models or testing techniques. While developing these models or testing techniques it is found that all the four areas of usability, performance, safety and security are not only closely related but rather depend on one another up to some extent. This meant that they all should be tackled while keeping into consideration of the related from among them. For the purpose it seemed necessary to collect in one artefact all the available modeling and testing techniques related to the four core areas of non-functional requirements may be collected and compared. This work at first provides an understanding of the problem domain while describing aspects of the non-functional requirements. Then possibly the available related models or testing techniques are collected and discussed. Finally in the last they are compared with respect to diversified aspects.

Requirements engineering (RE) is the primary task (process) that is done when agreed upon to develop a software product. The success of the software product is gauged on its ability to meet the intended needs of the stakeholders. There is abundant literature emphasizing the significance of RE and its influence on the entire software project, apart from its importance as the first step for a successful development endeavor. There are several established methodologies that are acknowledged to support the RE process and assist in creating a reliable structure of creating software. Despite the availability of such techniques and solutions, it was observed that umpteen number of software product failures are attributed to unsatisfactory RE practices. In this thesis, we have conducted a study with six organizations to emphasize the gap between the state of the art and the state of the practice, and consequently identify the factors that hinder the industrial community to implement state of the art RE. As a result of this empirical research we have found that to a great extent, state of the art practices are unpopular, more specifically in small organizations. Interestingly the majority of the problems associated with RE are associated to non technical issues.

Detta examensarbete ger en introduktion till området systemutveckling. Kravhantering har i alla tider varit en viktig del i systemutveckling. För att kunna lyckas med kravhanteringen under ett systemutvecklingsprojekt är det viktigt att använda sig av rätt teknik. En teknik som finns för att kunna hantera de krav som ställs på ett system är Use Case som härstammar från UML. Syftet med detta examensarbete var att ta reda på de för och nackdelar som har upplevts av användare som har arbetat med Use Case i samband med kravhantering. Presentation i detta examensarbete sker genom metoden intervju samt litteraturstudier. Det material som bearbetats fram via intervjuerna har analyserats med hjälp av olika litteraturer för att ge en klar bild av problemställningen. Resultatet visar att Use Case är en omtyckt teknik som innehar både fördelar och nackdelar där fördelarna överväger nackdelarna.

Examensarbetets frågeställning berör användarnas medverkan i Requirements Engineering (RE). Under RE-fasen skall samtliga krav på det kommande systemet tas fram från intressenterna. En viktig intressentgrupp i kravutvinningsarbetet är de kommande användarna av systemet. Resultatet av RE-fasen är en viktig faktor som påverkar hela den fortsatta utvecklingsprocessen samt hur lyckat det slutliga systemet blir. Detta examensarbete innebär en undersökning av vad användarrepresentanterna anser om use case-modelleringen i RE-processen. Undersökningen har påvisat att användarrepresentanterna är positiva till use case-modellering som arbetsmetod för att kartlägga kraven. För att besvara examensarbetets frågeställning har intervjuer med användarrepresentanter genomförts och de har givet vid handen att use case till viss del underlättar kommunikationen, men att det finns ett antal faktorer som försvårar och minskar användarens möjlighet att medverka i arbetet med use case-modelleringen. Undersökningen utförs genom en fallstudie inom Volvo Information Technology och de medverkande respondenterna kommer från tre olika projekt av varierande storlek.

Requirements Engineering (RE) is nowadays considered to be an activity, that aims at supporting the whole lifecycle of an information system by: eliciting, documenting, validating, and managing the requirements of the system. This thesis aims at providing an overview of the area of Requirements Management (RM) and to identify important and interesting issues or areas where further research is needed. RM includes two major areas; organising requirements and requirements change management. Organising requirements is concerned with structuring the requirements and storing additional relevant information about them e.g. attributes and traceability information. Requirements change management is concerned with dealing with changing requirement in a systematic way i.e. making informed decisions whether to implement a certain change or not, and support the implementation of approved changes. In order to provided a broader view of RM, the literature study were complemented by an interview study of how RM is conducted in practice. This interview study shows that the effort resources spent on RM differs substantially between different organisations. Various reasons for these discrepancies are elaborated in the work, but one of the main reasons are the type of software development that is conducted in the organisation. There is a tendency that organisations that develop software products and continuously releases new versions of there products are more likely to spend resources on RM, compared with organisations that develop customers specific solutions in one shoot projects. The need to reuse requirements and knowledge, as well as the maturity of the RE/RM process, are other factors that affects the resources spent on RM. The RM activities performed in practice are concordant with the activities found in literature. A number of areas where further research is needed were identified: requirements change management, dependencies between requirements, RM tools, and information management

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.

Detta examensarbete innehåller en introduktion till informationssystemutveckling och Requirements Engineering (RE). Vikten av att utföra RE på ett effektivt sätt är stor. Hela informationssystemet blir lidande om denna del inte utförs på ett tillfredställande sätt. För att utföra RE finns en rad tekniker och verktyg. Detta arbete behandlar en teknik i RE, nämligen Use Case-modellering. Arbetets syfte är att finna styrkor respektive svagheter med tekniken Use Case-modellering. Dessutom påvisar arbetet hur Use Case-modellering eventuellt kan förbättras. Det som framkommer i rapporten visar hur litteraturen ser på Use Case-modellering samt hur personer som praktiskt har använt sig av tekniken ser på den. Resultatet belyser att litteraturen och praktiken har ungefär samma syn på Use Case-modellerings styrkor och svagheter och att tekniken bör förbättras på olika sätt. Arbetet avslutas med en diskussion kring genomförandet av arbetet samt en diskussion kring det uppnådda resultatet.

Use Case-tekniken används för kravutvinning under RE-processen. Under RE-processen utvinns och dokumenteras krav på det nya systemet. I detta arbete undersöks vilka oklarheter systemutvecklare som använder Use Case-tekniken upplever med beskrivningen av denna teknik. Hur Use Case-tekniken utvecklats och vilken kritik som riktats mot tekniken beskrivs även detta i arbetet. Undersökningen utgår ifrån hur de systemutvecklare som använder tekniken upplever att denna är beskriven och utfördes med enkäter och intervjuer. Svaret på undersökningen är att de systemutvecklare som använder Use Case-tekniken upplever att denna som helhet är tydligt beskriven. På detaljnivå upplever dock de svarande att teknikens beskrivning: * saknar stöd för på vilken nivå Use Cases skall utformas, * saknar bra exempel, * inte har tillräckligt fokus på syftet med Use Cases, * saknar stöd för hur Use Cases skall utformas, * inte beskriver skillnaden mellan generalisering och <<extend>> * inte beskriver skillnaden mellan <<include>> och <<extend>> tillräckligt väl.