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 from Requirements Engineering is a Requirements Specification. Characteristics of a good Requirements Specification are unambiguity, completeness, verifiability, consistency, modifiability, traceability, correctness and ranked for importance and/or stability.This work defines these quality attributes and answers the questions how to reach these attributes and the diffuculties which exist in this area.This work should be read to get an overwiew of the area Requirements Engineering and Requirements Specification..

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..

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of Requirements documentation and how it is perceived. The same applies for how Requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and Requirements analyst experience the lack of Requirements documentation and how Requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of Requirements documentation and how it is perceived. The same applies for how Requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and Requirements analyst experience the lack of Requirements documentation and how Requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of Requirements documentation and how it is perceived. The same applies for how Requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and Requirements analyst experience the lack of Requirements documentation and how Requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of Requirements documentation and how it is perceived. The same applies for how Requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and Requirements analyst experience the lack of Requirements documentation and how Requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

The building and plant sectors represent a large part of Sweden?s energy use. Putting energy Requirements in public procurement as a tool for reducing energy consumption in the building and plant sectors is therefor an opportunity that operators can take advantage of. The aim of this thesis was to map the energy Requirements in procurement that operators in the public sector use today in building and plant projects. The analysis was made with respect to if the energy Requirements corresponded to the parts with large energy use in building and plant projects and also in which way energy Requirements in procurement are written in the contract.

Requirements management is an important part of the software development process. The success of a project may depend on how this is handled. Even though several research studies indicates that more attention should be paid on non-functional Requirements, the primary focus in practical projects still regards identifying functional Requirements. Especially the prioritization of the non-functional Requirements has been proven to be of great importance for the success of a project.This report investigates basics in agile Requirements management involving opinions from experts from a software development company. This is done with help of existing literature and interviews with key actors involved in prioritization at the company.

The education sector can be seen as a cornerstone of today's society, an organization that is under constant change and evolve as society. The compulsory school system is of significant role in society that places high demands on its management. The following study investigates the Requirements for documentation in primary school organization and operations, and how these Requirements are perceived and affect the school's organization and activities of the study carried out at different levels of the organization so as to get an overall picture of its impact. In order to analyze and create understanding of the results, the study applies the theory of New Public Management and various reforms that can be linked to the increased documentation Requirements and its influence in the public administration. Study results show that there is a mixed picture of the documentation impact on the school system. Shown are both positive and negative effects of the documentation Requirements.

This report has a purpose to identify the payment methods available for e-commerce, tosee if they fulfill certain Requirements. By investigating thirty of the most popular webshops, a few primary services have been found and revised. Security Requirements fore-payment systems include authentication, non-repudiation, integrity and confidentiality.Other Requirements considered to be important are usability, flexibility, affordability,reliability, availability, speed of transaction and interoperability. Advantages and disadvantageshave been identified to see if the services fulfill the Requirements. Also surveysof consumer payment habits have been investigated to identify the factors of decisive importanceto the usage of payment services.

Grid codes are becoming more demanding on power generating units due to the factthat the complexity of the power grid is increasing. The penetration of wind powerhas grown over the last years and it is clear that wind farms need to be addressedwith the same type of grid codes as conventional generation units. There is howeveran undeniable difference between the technology in conventional synchronousgeneration units, and the asynchronous generation units in wind farms.This thesis has reviewed the current grid code in Sweden and compared it to the newcode proposed by ENTSO-E, ?the Requirements for Generators?, in the aspect ofwind farms with an installed power of 30 MW or more. The comparison has beencomplemented by an analysis of how wind farms of two different technologies(Doubly fed induction generators and full power converters) can meet theRequirements and technical proposals have been given on how to be able to meetcompliance with the new grid codes.The Requirements for Generators contains many non-exhaustive and optionalRequirements, because of this it has been difficult to, at this stage, exactly point outthe technical impact on the grid connection of future wind farms in Sweden.

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.

This paper is a degree project on the C-level, 15 points at University West, Department of Business and IT dept. Informatics. This study is about agile methodology and its impact on IT projects. Requirements management is a process within an IT project, where customer has certain Requirements that must be met by an IT system. The difference between the traditional and agile development is in the Requirements management process and it can cause problems in a project.

This thesis is closely related to the Dynamically Self-Configuring Automotive System(DySCAS) project. DySCAS is a middleware for electronics in an automotive system. Thethesis work has been performed in cooperation with ENEA. Parts of the demonstrationplatform Self configurable High Availability and Policy based platform for Embeddedsystem (SHAPE) developed for the DySCAS project by ENEA have been used in theimplementation phase of this master thesis.The goal of this thesis was to evaluate how the Meteor MW, an offspring of the DySCASmiddleware, should handle QoS and to design a Quality of Service Manager (QoSM) for theMeteor MW that fulfilled hard real-time Requirements. The thesis also had the objectiveof analysing and identifying the Requirements on such a QoSM from a QoS perspective.Specifically the Requirements to guarantee real-time support for applications running onthe MW.