Prioritisation of software requirements is a critical part of the development of software. Whichrequirements and in which order they will be developed is one of the main tasks that requirementprioritisation supports.There are different ways that a requirement prioritisation can be used, for example alone or in agroup and with different methods.The purpose of this report is to map out how you can carry out a requirement prioritisation alonewith different types of prioritisation methods and how you solve the problems that can arise whenprioritisting requirements. This is done by documenting the use of three different types of methodsthat can be execute alone. The methods are "100-dollar test", "Ranking" and "Top-tenrequirements".To be able to prioritise requirements, you need to establish which requirements you shall prioritise.The paper retrieves this information by interviewing stakeholders in the system and analysing theresult of the interviews and the execution of the requirement prioritisation.Three problems arose during that work and I present solutions on these problems. The problemswere 1) equivalent requirements when using the "100-dollar test", 2) low differentiation gradebetween the prioritised requirements in the "100-dollar test" and 3) that the requirements that wereprioritised weren't classified before the prioritisation, which leads to inaccuracies in the resultingprioritisation.The solution to the problems that the paper presents is to increase the amount of distributable unitsin the "100-dollar test" to 1000 per requirement, suggestions of classes of the requirements andthe combination of the methods "100-dollar test" and "ranking" to bypass the equivalentrequirements.The report is written in Swedish.Nyckelord: GoTRIS, requirements retrieval, requirements analysis, Viktoria Swedish ICT,requirements prioritisation, requirements, 100-dollar test, ranking, top 10 requirements..

??I ett systemutvecklingsprojekt är kravspecifikation en av de främsta nyckelfaktorerna för att åstadkomma ett system som samtliga inblandade aktörer känner sig tillfredsställda med. Teorin innehåller ett stort antal riktlinjer och tekniker som hjälpmedel i arbetet med att ta fram komplett kravspecifikation.  När ett system väl har implementerats och sats i drift är vidareutveckling, anpassning samt underhåll av stor betydelse för hur väl systemet kommer att fungera i framtiden, som präglas av förändring. Trots detta förekommer det betydligt färre rekommendationer angående hur receptet för ett lyckat systemförvaltningsarbete kan uppnås. Syftet med denna uppsats är att undersöka hur processen för att samla in krav under systemförvaltningsfasen och med vilka tekniker krav detta sker och påvisa likheter och skillnader teori och praktik emellan.

Denna rapport behandlar den marknadsinriktade Requirements Engineering (RE) processen. Allt fler företag väljer idag att implementera standardsystem i sina verksamheter. Den situation som ett standardsystem utvecklas i är annorlunda jämfört med den som ett kundspecifikt system utvecklas i. Detta innebär att den traditionella RE-processen inte är anpassad till dessa nya förhållanden.Syftet med denna rapport är därför att utreda vad som kännetecknar en marknadsinriktad RE-process som stödjer kravhanteringsarbetet vid utvecklingen av ett standardsystem. Rapporten avser även att undersöka hur RE tillämpas av marknadsinriktade systemtillverkare i praktiken.