Systemutveckling handlar om processen för att underhålla, anpassa eller utveckla befintliga program och system. Systemutveckling är en komplex aktivitet som är påverkad av ett antal faktorer, ofta tid, budget och eskalerande problem. För att kunna hantera detta i en värld där tekniken utvecklas med snabba steg har systemutvecklingsprojekt börjat använda sig av agila metoder. Agila metoder syftar till att arbete sker iterativt, repeterande processer. Dessa metoder anses flexibla och rörliga inom projekt och målet är att kunna leverera en liten del av slutprodukten efter varje iteration.  Löpande kravhantering syftar till kravarbetet som sker löpande under ett helt projekt, detta är en del av den agila metodiken som används för att kunna vara mer flexibel och anpassningsbar vid arbete i projektform. Istället för att kravlistan ska vara helt färdig och svår att ändra innan projektet drar igång ska löpande kravhantering underlätta dagens snabbt svängande systemutvecklingsprojekt. Mätningar av projektresultat syftar till mätningar som kan genomföras för att få en bild av hur projektet har gått. Kritik har riktats mot hur mätningar sker och att resultat blir missvisande, även att kravhanteringen, trots medvetenheten hos företag, fortfarande försummas och skapar problem med bristfälliga kravställningar. Syftet med uppsatsen är att identifiera riktlinjer för löpande kravhantering och mätning av projektresultat, samt undersöka hur relationen mellan dessa ser ut. Detta kan bidra till att fler företag kan undvika missförstånd mellan leverantör och kund, samt även skapa en fortsatt förståelse för vikten av kravinsamlingsarbetet för att kunna genomföra trovärdiga mätningar. Studiens metod bygger på en kvalitativt inriktad insamlingsform, empiri samlas in med hjälp av semistrukturerade intervjuer. Fyra personer, samtliga konsulter, med bred erfarenhet från branschen har deltagit i studien och intervjuats. Studien resulterade i en analys om hur löpande kravhantering kan påverka mätningar av projektresultat och vilka effekter detta kan leda till. Även en diskussion kring utmaningar, samt lösningar och verktyg för att hantera detta stod i centrum. Slutsatsen beskriver hur relationen mellan löpande kravhantering och mätning av projektresultat ser ut, samt presenterar i punktform utmaningar och riktlinjer kopplade till denna relation.

Many IT-projects becomes complicated to an unnecessary level since the requirements hasn´t been worked through correctly. In fact, bad requirements engineering is one of the most expensive errors within IT-projects. This thesis presents a qualitative study on the challenges associated with requirements engineering in the context of agile software development. The reason for that, is because challenges in the requirement process in traditional IT-projects are well-known. But they are less known within agile IT-projects. The purpose is therefore to gain knowledge so that the study can help and inspire upcoming IT-projects so that success is easier to achieve in the future. The study is performed together with an IT-consultant company which seeks to find answers and solutions to this complex process. The methods used to collect data in order to create more ground for the subject is done through qualitative interviews and through one observation.  Today we can display the evidence of what kind of challenges that exists and potentially how to avoid them during the beginning-face of a project. The result show tendencies of challenges that stands in the way for successful end-results within the requirement engineering area in agile IT-projects. The main findings are three major categories of challenges in agile IT-projects that are enriched with earlier research within the subject of the study. These challenges can cause even bigger issues if not considered correctly in the planning process before the start of a project. The project will demand more resources in order to reach completion and a successful product for the customer.   The knowledge gained from this study can be critical to the future of requirement engineering in agile projects.

Att den värld som dagens företag existerar i blir mer och mer dynamisk och komplex är något de blivit tvungna att förlika sig med. För att möta denna mer rörliga verklighet har systemutvecklingsprojekten gått från att använda sig av sekventiella metoder till de som är mer iterativa. Att ett stort antal IT-projekt fortfarande misslyckas är ett känt faktum, men spekulationerna om varför det går fel är åtskilliga. Ett ämne som upprepade gånger hämnar högt upp på listan över anledningar till varför projekten misslyckas är kraven. I de agila metodbeskrivningar lämnas dock kraven utanför beskrivning av tillvägagångssättet för projektet, kraven kommer in under hela utvecklingsperioden men beskrivningarna av hur detta sker är reducerad. Detta är då grunden till vår frågeställning, kraven kommer åtskilliga gånger på en pallplats över anledningar till att projekten misslyckas och de agila metoderna som tagits fram för att främja den komplexa världen men inte beskriver hur dessa skall tas in. Vår frågeställning för studien är därför; Hur hanteras kravinsamlingen inom de agila systemutvecklingsprojekten? För att söka svaret på frågeställningen inleddes arbetet med att skapa en bred teoretisk grund, detta dels för att förbättra vår kunskap samt för att inneha så mycket kunskap som möjligt för nästkommande steg i arbetet, den empiriska studien. Den empiriska studien gjordes då vi anser att svaret kräver inblick utifrån yrkesaktiva som dagligen arbetar med fenomenet. Denna studie bestod av sju semi-strukturerade intervjuer där samtliga personer besitter en gedigen bakgrund inom yrket. Det insamlade materialet utgjorde ett underlag för analysen där tolkningar stod till grund för slutsatsen vilken besvarar frågeställningen. Resultatet av studien visar på att en rad av olika arbetssätt används i praktiken för insamlingen av krav. Något som påvisades av de som intervjuades under den empiriska studien var att i dagens utvecklingsprojekt är det en oerhört viktig aspekt för kravinsamlarna att förstå kundens processer. Både för att veta vilka frågor de skall ställa men även för att själva få klarhet i hur de skall kunna hjälpa kunden. Att merparten av de agila systemutvecklingsprojekten startas med en fast budget samt en fast tidsplan skalar av leverantörernas möjligheter att vara flexibla gentemot kundens nya önskemål i form av löpande krav. / Program: Dataekonomutbildningen

Inom IT-projekt beskrivs kravhantering som en av de inledande aktiviteterna i systemutveckling som syftar till att specificera beställarens behov. Kravhantering har länge brottats med många problem. Ett är att krav blir låsta tidigt i ett projekt och kan därefter inte förändras, detta minskar beställarens flexibilitet. Användning av agila metoder har blivit allt vanligare bland IT-leverantörer. Agila metoder förespråkar att IT-leverantör och beställare har ett nära samarbete. Eftersom beställaren ansvar ökar under kravhantering i agila projekt fann vi det intressant att undersöka vilka faktorer som är viktiga för beställaren att beakta under kravhantering i agila projekt. I litteratur finns mycket beskrivet om agila metoder generellt, men väldigt lite kring beställarens roll, varför vi ville undersöka detta närmare. Studien genomfördes med en kvalitativ ansats. För att undersöka hur IT-leverantören ser på beställarens roll under kravhantering i agila projekt har vi intervjuat fem respondenter från fyra olika IT-företag som använder agila metoder. Intervjuerna var semistrukturerade eftersom vi sökte respondenternas uppfattningar och tolkning av kravhanteringen. Intervjumaterialet analyserades sedan med en tematisk analys. Datainsamlingen visade att det fanns flera faktorer som är viktiga för beställaren att beakta under kravhanteringen. Engagemang är viktigt för att beställaren ska ha möjlighet att påverka och ha åsikter om kraven under projektets gång. Inledningsvis samlas kraven in på en övergripande nivå och det blir därför viktigt med en kontinuerlig kommunikation mellan IT-leverantör och beställare för att detaljera kraven under projektet. För att kunna ha ett nära samarbete med IT-leverantören krävs det att beställaren är delaktig i projektet i allt större utsträckning. Det har också visat sig att IT-leverantörens användning av agila metoder inte ställer orimliga krav på beställaren. Tvärtom är de väldigt flexibla gentemot beställaren och anpassar metoden på ett sätt som passar beställaren. Studien visar att det ibland är känsligt för IT-leverantören att ställa allt för höga krav på beställaren, eftersom beställaren är en kund. Studiens resultat indikerar att när IT-företagen använder agila metoder under kravhanteringen krävs det att beställaren är engagerad under merparten av projektet, eftersom kraven samlas inledningsvis in på en övergripande nivå och detaljeras sedan. Beställarna är inte vana vid att så höga krav ställs på deras engagemang. Det har också visat sig vara svårt att motivera beställarna att vara delaktiga i projektet, beställarens måste själv inse vikten av engagemang och delaktighet. Det krävs att båda parter tar sitt ansvar under kravhanteringen för att beställaren ska kunna få det system de vill ha och betalar för. / Program: Interaktions- och kommunikationsdesignerutbildningen

<p>Att använda någon slags projektmodell ses för många projektledare som ett stöd och någotatt använda sig av för att projektet ska uppnå ett bra resultat. På TotalförsvaretsForskningsinstitut (FOI) har de valt att inte använda sig av någon projektmodell. Deanpassar istället projektet löpande efter hur det utvecklas. Detta har vi valt att kalla förFOI:s grundmodell.Studiens syfte är att skapa oss en förståelse för hur styrningen i ett projekt utanprojektmodell fungerar. Syftet är även att jämföra denna projektmodell med den agilamodellen Scrum. Fem intervjuer har utförts och utgör grunden för vårt empiriska material.Det empiriska materialet i sin tur har hjälpt oss att besvara vår huvudfråga som lyder, hurstyrande är ett projekt utan projektmodell för projektmedlemmarna på FOI med avseendepå utförande av arbete?Vår studie visar att FOI:s grundmodell och Scrum har fler skillnader än likheter, trots attbåda projektmodellerna lätt kan anpassas efter projektets utveckling. Vi har dock upptäcktatt FOI använder sig av någon slags informell projektmodell då det finns ett fåtal riktlinjeratt följa. Dessa riktlinjer påverkar styrningen av de projektdeltagare som utför arbetet iprojektet, men har liten inverkan på projektets olika projektledare. Under arbetets gångupptäckte vi även att det fanns intressanta gruppsociologiska fenomen att undersöka, tillexempel maktförhållanden och normer. Detta gjorde vi för att närmare undersökastyrningens inverkan och konsekvenserAtt använda någon slags projektmodell ses för många projektledare som ett stöd och någotatt använda sig av för att projektet ska uppnå ett bra resultat. På TotalförsvaretsForskningsinstitut (FOI) har de valt att inte använda sig av någon projektmodell. Deanpassar istället projektet löpande efter hur det utvecklas. Detta har vi valt att kalla förFOI:s grundmodell.Studiens syfte är att skapa oss en förståelse för hur styrningen i ett projekt utanprojektmodell fungerar. Syftet är även att jämföra denna projektmodell med den agilamodellen Scrum. Fem intervjuer har utförts och utgör grunden för vårt empiriska material.Det empiriska materialet i sin tur har hjälpt oss att besvara vår huvudfråga som lyder, hurstyrande är ett projekt utan projektmodell för projektmedlemmarna på FOI med avseendepå utförande av arbete?Vår studie visar att FOI:s grundmodell och Scrum har fler skillnader än likheter, trots attbåda projektmodellerna lätt kan anpassas efter projektets utveckling. Vi har dock upptäcktatt FOI använder sig av någon slags informell projektmodell då det finns ett fåtal riktlinjeratt följa. Dessa riktlinjer påverkar styrningen av de projektdeltagare som utför arbetet iprojektet, men har liten inverkan på projektets olika projektledare. Under arbetets gångupptäckte vi även att det fanns intressanta gruppsociologiska fenomen att undersöka, tillexempel maktförhållanden och normer. Detta gjorde vi för att närmare undersökastyrningens inverkan och konsekvenser.</p>

Att använda någon slags projektmodell ses för många projektledare som ett stöd och någotatt använda sig av för att projektet ska uppnå ett bra resultat. På TotalförsvaretsForskningsinstitut (FOI) har de valt att inte använda sig av någon projektmodell. Deanpassar istället projektet löpande efter hur det utvecklas. Detta har vi valt att kalla förFOI:s grundmodell.Studiens syfte är att skapa oss en förståelse för hur styrningen i ett projekt utanprojektmodell fungerar. Syftet är även att jämföra denna projektmodell med den agilamodellen Scrum. Fem intervjuer har utförts och utgör grunden för vårt empiriska material.Det empiriska materialet i sin tur har hjälpt oss att besvara vår huvudfråga som lyder, hurstyrande är ett projekt utan projektmodell för projektmedlemmarna på FOI med avseendepå utförande av arbete?Vår studie visar att FOI:s grundmodell och Scrum har fler skillnader än likheter, trots attbåda projektmodellerna lätt kan anpassas efter projektets utveckling. Vi har dock upptäcktatt FOI använder sig av någon slags informell projektmodell då det finns ett fåtal riktlinjeratt följa. Dessa riktlinjer påverkar styrningen av de projektdeltagare som utför arbetet iprojektet, men har liten inverkan på projektets olika projektledare. Under arbetets gångupptäckte vi även att det fanns intressanta gruppsociologiska fenomen att undersöka, tillexempel maktförhållanden och normer. Detta gjorde vi för att närmare undersökastyrningens inverkan och konsekvenserAtt använda någon slags projektmodell ses för många projektledare som ett stöd och någotatt använda sig av för att projektet ska uppnå ett bra resultat. På TotalförsvaretsForskningsinstitut (FOI) har de valt att inte använda sig av någon projektmodell. Deanpassar istället projektet löpande efter hur det utvecklas. Detta har vi valt att kalla förFOI:s grundmodell.Studiens syfte är att skapa oss en förståelse för hur styrningen i ett projekt utanprojektmodell fungerar. Syftet är även att jämföra denna projektmodell med den agilamodellen Scrum. Fem intervjuer har utförts och utgör grunden för vårt empiriska material.Det empiriska materialet i sin tur har hjälpt oss att besvara vår huvudfråga som lyder, hurstyrande är ett projekt utan projektmodell för projektmedlemmarna på FOI med avseendepå utförande av arbete?Vår studie visar att FOI:s grundmodell och Scrum har fler skillnader än likheter, trots attbåda projektmodellerna lätt kan anpassas efter projektets utveckling. Vi har dock upptäcktatt FOI använder sig av någon slags informell projektmodell då det finns ett fåtal riktlinjeratt följa. Dessa riktlinjer påverkar styrningen av de projektdeltagare som utför arbetet iprojektet, men har liten inverkan på projektets olika projektledare. Under arbetets gångupptäckte vi även att det fanns intressanta gruppsociologiska fenomen att undersöka, tillexempel maktförhållanden och normer. Detta gjorde vi för att närmare undersökastyrningens inverkan och konsekvenser.

Internal communication is an important factor in organisations today. For many system development teams it’s critical that the communication works well. Without communication, success would be impossible. This study aims to highlight the effect communication has on the members of agile project teams. The theoretical data is gathered from a literature study in the fields of relevance. The empirical data in this study is gathered from interviews and observations at three different companies, all working with agile development methods. The results from the interviews and observations presents that all respondents were affected by the internal communication in their work. Our analysis show a clear resemblance between the empirical data and the data gathered in our theoretical study. Our conclusion show that internal communication has an effect on the agile project teams. A factor that became very clear is that the project teams feel more effective because of the communication. But our conclusion also shows that the internal communication improved relations, work became more fun, and the atmosphere in the project teams got more familiar. Communication helped the project teams spread their knowledge between each other in the project teams. The communication also created a common language for the system developers which meant they could understand the requirements better and easier, which leads to more effective communication.

Websites today only offer simpler form of technical analysis and are not fun to use, therefore student decided to build a website that makes technical analysis a bit more fun by giving user possibility to experiment with settings for technical indicators and also see clear visible results from analysis. Student decided to build website in ASP.NET. Technical indicators for this project only consist of those who give buy and sell-signals via cross-over, no divergence or pattern finding.This project has three questions that define this project. It’s important that there is good functionality so that performing an analysis is perceived as simple, one question is therefore; what functionality for website is needed in order for analysis to be perceived as more simple?Technical analysis is a pretty complex subject and demands an interface that is perceived as easy to understand and easy to use, it’s therefore important that the interface is well designed, second question is therefore; how should the interface be designed to be user-friendly?When systems grow large they often become hard to develop and later on unmaintainable because of the accumulated complexity and dependency between classes, the code is a mess, the last question is therefore; how can the systems complexity be eased with object-oriented design principles?Jakob Nielsens ten heuristics for User Interface Design were used as inspiration for designing the interface for the website. The system design follows SOLID principles, some pattern-design were also used because pattern-design often fulfills SOLID principles or makes for pretty good solutions in regular code-problems.At the beginning of the project the student did a small research to find out what was needed in order to complete project. Work-method for project follows agile development where decisions were made on a weekly basis. The project was divided into three phases where each phase was strongly coupled to a specific area of responsibility. Prototypes for interface were made and used as a basis for the resulting interface.The project led to a working website with good functionality. Filter was considered as important in order to ease shaping of analysis because the user could more easily sort and pick stock. The student assumed that the user would want fast and easy access to their stock so portfolio management were implemented so that user could more easily get to stock that was considered as favorites. The interface follows to a big extent Jakob Nielsens ten heuristics for User Interface Design and is proven by comparing interface with principles. The same goes for design of the system, design is proven by comparing with principles, still to this day system is considered easy to continue development.Student made the conclusion that SOLID principles were very important in order for the system to maintain its health and took experience from these principles. Student became happy with the interface but more focus could’ve been given for a more interactive interface because it might’ve been perceived as more intuitive.

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. I investigate prioritization of non-functional requirements and possibilities for agile project development. The results contribute to developing an overall understanding of the agile way of working. The methodology of this report follows a qualitative approach. It is based on secondary data from literature and documents, but also on data collected via interviews. The results are acknowledging earlier findings from the literature and illustrate with examples actual prioritization of non-functional requirements, and how and why prioritization is a complex activity at a company. However, according to one of the most important findings of this study, the strict use of prioritization techniques is not the most urgent necessity for the success of a project. / Kravhanteringen är en viktig del av systemutvecklingsprocessen. Ett projekts framgång kan kopplas till hur detta genomförs. Även om flera studier pekar på att mer uppmärksamhet bör läggas på icke-funktionella krav är den primära fokusen i flera projekt fortfarande att identifiera funktionella krav. Speciellt prioriteringen av de icke-funktionella kraven har visat sig vara av stor betydelse för ett lyckat projekt.  Den här rapporten undersöker grunderna i den agila kravhanteringen som involverar åsikter från experter i ett företag inom mjukvaruutveckling. Detta görs med hjälp av befintlig litteratur samt intervjuer med nyckelaktörer involverade i prioriteringen hos företaget. Jag undersöker prioriteringen av icke-funktionella krav och möjligheter för agil projektutveckling hos företaget. Följaktligen kommer resultatet bidra till att ge läsaren en allmän förståelse om det agila arbetssättet. Metodologin för den här rapporten följer ett kvalitativt tillvägagångssätt. Den baseras på sekundär data från litteratur och dokument, men även data insamlat via intervjuer. Resultaten medger tidigare upptäckter från litteraturen och visar med exempel verklig prioritering av icke-funktionella krav samt hur och varför prioriteringen är en komplex aktivitet hos ett företag. Dock är, enligt en av de viktigaste upptäckterna i den här rapporten, ett strikt användande av prioriteringstekniker inte den viktigaste nödvändigheten för ett lyckat projekt.

ja