In most software engineering project, users are only involved in the beginning of the project as a help to design the requirements specification but users can be involved after this phase too, but is it effective to do so? With this report we would like to investigate how effective it is to involve users after the requirements specification has been written and approved. To find out how effective it is to involve the users we try some fast and simple involvement techniques on a quite far gone project. These techniques include ethnographic studies, prototypes and surveys. We also interviewed a couple of people who work with usability and finally delivered a report with our results to them to find out if they found our result relevant. By also documenting how much time we spent involving users we will show to which degree user involvement is effective. We found out that a couple of fast techniques could get very much result in the form of usability enhancing suggestions to the developers.

There are several methods and models within the areas of software engineering on how to proceed during a software development process. For each of these methods and models there are benefits and drawbacks, depending on how you choose to look at them. A difference of principle between the different models is that they either advocate iterative development or not. In parts of software engineering one makes use of different methods depending on which is most fitting in a specific situation. There are several methods on how to recieve more qualitative data from the end-users during the requirement collection, but the reappearing pattern is still user centric participation, which means that the user participates more actively in part of or the entire development process.

Abstrakt Social Engineering är konsten att manipulera människor, för att på så sätt vinna deras förtroende. Med hjälp av detta förtroende kan attackeraren sedan kringgå säkerhetssystem och få tillgång till organisationers information. Vi har i denna uppsats genomfört elva intervjuer på tre stora organisationer med både IT-chefer och övrig personal. Med dessa intervjuer har vi sedan försökt få en bild av hur medvetenheten ser ut samt vilka åtgärder organisationerna tar för att förhindra Social Engineering. Med denna uppsats vill vi belysa den ovisshet som råder kring Social Engineering, men även farorna och hur effektiv en attack av denna typ kan vara.

Abstract The purpose of this essay is to find difficulties and risks in the re-engineering process when restructuring to Model-View-Controller (MVC). A thoroughly theory study has been conducted to be able to understand the important steps in the re-engineering process. The methods and concepts of this essay are re-engineering, UML, system development life cycle, design patterns and MVC. The science approach used is design science where the artifact being developed are a set of models.In the analysis phase of the process the system is analyzed. The result of the analysis is notes of difficulties found and models showing the structure of the system.

Examensarbetets problemområde återfinns i den tidiga delen inom informationssystemutveckling. Denna utvecklingsfas, kallad Requirements Engineering (RE), innefattar aktiviteter för att förstå, dokumentera och validera de behov och krav som föreligger för ett framtida informationssystem. RE är en avgörande aktivitet i processen att utveckla ett informationssystem som tillfredsställer användare och kunders förväntningar och behov.De olika intressenterna som är involverade i RE-processen har olika roller, bakgrund och kunskaper. Av denna anledning föreligger olika problem och möjligheter med avseende på intressenterna. I examensarbetet utreds vilka dessa möjligheter och problem kan vara.

In most software engineering project, users are only involved in the beginning of the project as a help to design the requirements specification but users can be involved after this phase too, but is it effective to do so? With this report we would like to investigate how effective it is to involve users after the requirements specification has been written and approved. To find out how effective it is to involve the users we try some fast and simple involvement techniques on a quite far gone project. These techniques include ethnographic studies, prototypes and surveys. We also interviewed a couple of people who work with usability and finally delivered a report with our results to them to find out if they found our result relevant.

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.

Failed system development projects are a common sight within the IT-industry. During the last ten years we have seen several more or less disastrous high profile projects being reported in the news. One aspect that might hold some of the responsibility for these failures is the fact that more organisations are knowledge intensive which makes their work processes difficult to capture in computer systems. How Requirements Engineering is handled becomes even more important in these cases, where processes are unpredictable and rely on individual judgement and knowledge. In this study we have examined the challenges of developing systems for knowledge intensive businesses through a method of qualitative case study of a university laboratory.

This final year project is dedicated to investigate the problem domain of system maintenance management. The purpose is to find problems in the system maintenance management of today. Whether there is any problem that can be elicitated in the Requirements Engineering?s phase that could help to obtain more maintenance management friendly systems and if it is not possible to obtain more maintenance management friendly, what else can be done?It has been learned that there are many problems today in the problem domain and the most great ones are the system documentation, stress and a systemknowledge lack among developers, system managers and system users.The requirements that have been found for this problem is good documentation, and use of simple solutions in the creating of the system..

There are several methods and models within the areas of software engineering on how to proceed during a software development process. For each of these methods and models there are benefits and drawbacks, depending on how you choose to look at them. A difference of principle between the different models is that they either advocate iterative development or not. In parts of software engineering one makes use of different methods depending on which is most fitting in a specific situation. There are several methods on how to recieve more qualitative data from the end-users during the requirement collection, but the reappearing pattern is still user centric participation, which means that the user participates more actively in part of or the entire development process.

Det problemområde som behandlas i arbetet är den del av systemutvecklarens arbete avsett att hantera förändringar i kravbilden under systemutvecklingens hela livscykel, kallat Requirements Management (RM). Arbetet fokuseras på detaljer kring spårbarhet inom förändringshantering.För att lyckas i spårbarhetsarbetet gäller det för systemutvecklaren att se hur de olika krav som finns i kravbilden är relaterade till varandra och var kraven har sitt ursprung. Det skiljs inom spårbarhetsområdet mellan framåt- och bakåtriktad spårbarhet. Vardera spårbarhetsriktningen delas sedan in i två steg från kravursprung framåt via kravdokumentation till realisering då det gäller den framåtriktade och från realisering via kravdokumentation till kravursprung då det gäller den bakåtriktade.En studie har genomförts där litteraturens syn har jämförts med ett antal respondenters då det gäller att dels kartlägga vilka typer av spårbarhet som behövs inom systemutvecklingsprojekt och dels vilket stöd som behövs för att etablera och underhålla denna spårbarhet..

This is a report for our thesis that was conducted as a conclusion of our bachelor degree in Business engineering at the Royal Institute of Technology (KTH). The work is done in cooperation with the firm Navigate Consulting Business Solutions AB.They have their leading expertise in Oracle E-Business Suite and has previously chosen to implement Oracle EBS R12. The modules that are planned to be implemented are general ledger (GL), accounts payable (AP), accounts receivable (AR), project module (PA), purchases, and CRM. For a consulting company like Navigate, it is particularly important to have a simple and effective time reporting process. We were therefore asked to provide new tabs with a decision-making process to determine if Oracle Time & Labor (OTL) is a useful time tracking system for their business.In order to achieve the company´s aim and objective we decided to follow a development method with five different phases.

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

Uppsatsen undersöker inledningsvis om FOI:s principer för kravformulering kan anses behöva kompletteras mot bakgrund av Försvarsmaktens behov och undersöker därefter kvalitén i några av flygvapnets kravunderlag relativt principerna för kravformulering. Av resultatet framgår att principerna kan behöva kompletteras med principerna prioritering och kontextuell beskrivning. Av fallstudiernas resultat framgår att kvalitén i flygvapnets kravunderlag relativt principerna för kravformulering generellt är låg, att den varierar mellan underlagen och att den i vissa fall är mycket låg i fråga om uppfyllnad av principerna. Uppsatsen rekommenderar att FOI:s principer för kravformulering utökas med principerna prioritering och kontextuell beskrivning. Vidare rekommenderas flygvapnet att öka kvalitén i framtida kravformuleringarna så att den militära nyttan av arbete med kravformulering även kan öka.

Alstom Power Sweden AB in Norrköping isexpanding their business in the presentsituation and has implemented aprocedure for reverse engineering as apart of this work. Reverse engineeringat Alstom is an extensive procedurethat is calculated to be performedunder very time demanding conditions.This thesis is a continued exertion ofthe implementation process in order toidentify and describe the mostimportant process steps in purpose to beable to manage and improve theprocess.This thesis was written with twoprimary objectives. The first was todescribe and map out the procedure torecreate technical data of a turbineblade, based on a validation of thereverse engineering process that hasbeen performed at Alstom in Norrköping.The second purpose was to describe thekey factors to achieve successful usageof reverse engineering that have beennoticed in the literature study.The work is based on a literature studyon the subject reverse engineeringwhich produced the theoreticalknowledge of the method to reproducetechnical data to a product. Theliterature study has also led to adescription of reverse engineering froma legal perspective to clarify how farit is allowed to apply the methodaccording to the patent laws. With theliterature study as support and furtherhelp and guidance from individualswithin the reverse engineering unit atAlstom, a complete picture andunderstanding of the process has beenproduced and documented..