<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>Rational unified process är en systemutvecklingsmetod som ofta används som ramverk och stöd vid utveckling. RUP kan även användas i sin helhet, vilket detta arbete handlar om. Metoden består av 5 itererande faser och har detaljerade beskrivningar på hur varje fas ska genomföras vid en utvecklingsprocess. RUP är dock väldigt komplext i sin helhet och innehåller många aktörer samt iterationer som tar tid och kostar pengar. Trots allt så är RUP en metod som blir allt mer vanligare att använda vid utveckling idag. I RUP så försäkrar man användarens behov via s.k. användarfall. För att ta reda på alla användares behov förespråkar Krutchen (2003) att man träffar användarna och gemensamt ritar upp användarfallsmodeller som täcker in behoven. På detta sätt så försäkrar man sedan att behoven är täckta innan man går vidare till nästa fas i utvecklingen. Användarfall är något som även används i andra metoder. Detta arbete beskriver dock enbart hur det används i metoden RUP. Detta arbete ska undersöka användarmedverkan i teori och praktik vid skapandet av användarfall i RUP. Frågeställningen besvarades genom litteraturstudier samt genom intervjuer av utvecklare angående ämnet. Resultatet visade bland annat att det inte alls existerar användarmedverkan i det omfång som det skulle behövas för att försäkra att man får ett användbart system. Det visar även en skillnad mellan teori och praktik vid användandet av RUP.</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.

Rational unified process är en systemutvecklingsmetod som ofta används som ramverk och stöd vid utveckling. RUP kan även användas i sin helhet, vilket detta arbete handlar om. Metoden består av 5 itererande faser och har detaljerade beskrivningar på hur varje fas ska genomföras vid en utvecklingsprocess. RUP är dock väldigt komplext i sin helhet och innehåller många aktörer samt iterationer som tar tid och kostar pengar. Trots allt så är RUP en metod som blir allt mer vanligare att använda vid utveckling idag. I RUP så försäkrar man användarens behov via s.k. användarfall. För att ta reda på alla användares behov förespråkar Krutchen (2003) att man träffar användarna och gemensamt ritar upp användarfallsmodeller som täcker in behoven. På detta sätt så försäkrar man sedan att behoven är täckta innan man går vidare till nästa fas i utvecklingen. Användarfall är något som även används i andra metoder. Detta arbete beskriver dock enbart hur det används i metoden RUP. Detta arbete ska undersöka användarmedverkan i teori och praktik vid skapandet av användarfall i RUP. Frågeställningen besvarades genom litteraturstudier samt genom intervjuer av utvecklare angående ämnet. Resultatet visade bland annat att det inte alls existerar användarmedverkan i det omfång som det skulle behövas för att försäkra att man får ett användbart system. Det visar även en skillnad mellan teori och praktik vid användandet av RUP.

There are many different details to consider for developers when creating a new product. Many believe that the functions is the most important. However the question about how the products User Experience should be handled gets more and more important. Because of that there are lots of tests before every launch to ensure that the product gets a better welcoming with the customers. The purpose with this study was to create a overview for how to create a better User Experience. We have created a guideline in this topical subject through creating a methodology to follow. This was done because of the difficulty to follow the current guidelines, and especially from those who really don´t know the subject. This study was based on previous research with a qualitative data collection method. We did our study from the eyes of a case business where we had interviews to get their opinions about User Experience and methodologies that already exists. The information that were used as method for the selection of informants because it was important for us that the informants knew what they were talking about. The purpose of the empirical data was to conclude which parts that were necessary to include in a methodology to get a more advanced User Experience but also why it is important. With this information we could give our version of a methodology to create a User Experience that fit in different projects. The results of the study contain the parts that we thought was important for creating a methodology that the developers could use. These were Design, UX-design, User Behavior, Usability and Human Computer Interaction that we later compiled to different phases in our methodology for User Experience. Furthermore when we concluded the phases for our methodology and these were Understanding where the developers shall create an understanding about what the user really wants. Research where you research what techniques that should be a part of a modern product. Sketch where you work from what the customer wants to get prototypes and test them to get their opinion. Design where you confirms which of the prototypes you will use in a completed design. Implementation where you create the product. The last phase is Evaluate where you do usability testings continuously to know that it is really working.

<p>Vem avgör vad som är bra användbarhet? Och hur lyckas man bibehålla det genom ett helt program? Dessa frågor och många fler ställdes när arbetet med utformningen av den nya designen startades. Meningen var att ta reda på vad som gäller idag och vad som är intressant för framtiden i frågan om användbarhet.</p><p>Genom en grundlig analys av designen i programmet SEBS (System Economy Business System) tillsammans med ett flertal andra liknande program har flera problemområden identifierats och motiverats med hjälp av teorier från författare och ISO standarder (International Organisation for Standardization).</p><p>Uppgiften har en ganska abstrakt natur och ger inte självmant upphov till gedigna praktikfall som lätt presenteras. Trots det blev ett nytt gränssnitt och nya riktlinjer framtagna och arbetssättet och tankarna bakom finns väl dokumenterade. Resultatet måste analyseras av någon som förstår större delen av innebörden i den teoretiska bakgrunden som är presenterad.</p><p>Resultaten som arbetet skapade gav en djup insikt i svårigheten att framställa programvara som är tilltalande och effektiv. Det är en utmaning många skulle backa för att ta om de visste vad den innebar. Arbetet det innebär kämpar precis som alla projekt där flera människor deltar med att få alla att dra åt samma håll. Det finns inget konkret att satsa på utan alla måste lyssna och försöka samlas kring en vision som symboliserar det kommande resultatet. Hjälpmedel för detta presenteras i rapporten, för det finns fler poänger med att låta verktygen få finnas till hands för mer än bara sammanhållningen. De kan även väcka nya sätt att prata om slutanvändare och hur man ska förhålla sig till dem.</p> / <p>Who decides whether a design is user friendly or not? And what is the trick to maintain that type of design throughout the whole program? These and many more questions were asked when the work with the report were about to begin. The plan is to find out what is relevant for design today and what will be interesting to know about in a present future. Through a fundamentally analysis of the design in the program SEBS (System Economy Business System) together with a number of similar programs, several problem areas has been discovered and motivated by references to different authors and ISO standards(International Organisation for Standardization).</p><p>Since this task has an abstract nature it does not provide the authors with good case studies that easily can be presented and discussed. Despite that, a new user design has been created and new guidelines for future design have been drawn. The work gained a deep understanding for the difficulties that comes with software manufacturing and a belief that most people would back of if they knew what was waiting down the line in this type of work. As always when project includes several people problems with communications and the ability to struggle at the same direction occurs. Tools to lighten this work are presented and they are not just effective to keep the group together. They can also help to find new ways to talk about the actual user of the developing program.</p>

Vem avgör vad som är bra användbarhet? Och hur lyckas man bibehålla det genom ett helt program? Dessa frågor och många fler ställdes när arbetet med utformningen av den nya designen startades. Meningen var att ta reda på vad som gäller idag och vad som är intressant för framtiden i frågan om användbarhet. Genom en grundlig analys av designen i programmet SEBS (System Economy Business System) tillsammans med ett flertal andra liknande program har flera problemområden identifierats och motiverats med hjälp av teorier från författare och ISO standarder (International Organisation for Standardization). Uppgiften har en ganska abstrakt natur och ger inte självmant upphov till gedigna praktikfall som lätt presenteras. Trots det blev ett nytt gränssnitt och nya riktlinjer framtagna och arbetssättet och tankarna bakom finns väl dokumenterade. Resultatet måste analyseras av någon som förstår större delen av innebörden i den teoretiska bakgrunden som är presenterad. Resultaten som arbetet skapade gav en djup insikt i svårigheten att framställa programvara som är tilltalande och effektiv. Det är en utmaning många skulle backa för att ta om de visste vad den innebar. Arbetet det innebär kämpar precis som alla projekt där flera människor deltar med att få alla att dra åt samma håll. Det finns inget konkret att satsa på utan alla måste lyssna och försöka samlas kring en vision som symboliserar det kommande resultatet. Hjälpmedel för detta presenteras i rapporten, för det finns fler poänger med att låta verktygen få finnas till hands för mer än bara sammanhållningen. De kan även väcka nya sätt att prata om slutanvändare och hur man ska förhålla sig till dem. / Who decides whether a design is user friendly or not? And what is the trick to maintain that type of design throughout the whole program? These and many more questions were asked when the work with the report were about to begin. The plan is to find out what is relevant for design today and what will be interesting to know about in a present future. Through a fundamentally analysis of the design in the program SEBS (System Economy Business System) together with a number of similar programs, several problem areas has been discovered and motivated by references to different authors and ISO standards(International Organisation for Standardization). Since this task has an abstract nature it does not provide the authors with good case studies that easily can be presented and discussed. Despite that, a new user design has been created and new guidelines for future design have been drawn. The work gained a deep understanding for the difficulties that comes with software manufacturing and a belief that most people would back of if they knew what was waiting down the line in this type of work. As always when project includes several people problems with communications and the ability to struggle at the same direction occurs. Tools to lighten this work are presented and they are not just effective to keep the group together. They can also help to find new ways to talk about the actual user of the developing program.

Målet med examensarbetet var att ta fram en kravspecifikation till KTH:s och ICT:s webbportal avseende utökning av tjänster för förmedling av sommarjobb, mentorskap, studiebesök och projektidéer. Syftet är att beskriva hur de fyra tjänsterna kan fungera i interaktionen mellan användaren och webbportalen. Det hela sammanställdes i en kravspecifikation med hjälp av användarfall. Metoden som valdes för att genomföra arbetet var aktionsforskning. Första steget i metoden var att studera webbportalen och sedan genom intervjuer och diskussioner ta fram användarfallen. Analysen av resultaten visar att ingenting saknas gällande funktionaliteten hos tjänsterna, men det skulle vara bra med ytterligare validering genom att diskutera kravspecifikationen med någon kunnig inom användarfall. / The goal of this paper was to produce a requirements specification for KTH:s and ICT:s web portal regarding the extension of the services intermediation of summer job, mentoring, study visits and project ideas. The purpose of the paper is to describe how the four services can function in the interaction between the user and the web portal. This was compiled into a requirements specification consisting of a number of use cases. The method chosen to conduct the research was action research. The first step of the method was to study the web portal and then through interviews and discussions create the use cases. The analysis of the results shows that nothing is missing regarding the functionality of the services, but it would be good with further validation by discussing the requirements specification with someone knowledgeable in the field of use cases.