Dissertations / Theses: 'Agile Requirements'

1

Soundararajan, Shvetha. "Agile Requirements Generation Model: A Soft-structured Approach to Agile Requirements Engineering." Thesis, Virginia Tech, 2008. http://hdl.handle.net/10919/34511.

Full text

Abstract:

The agile principles applied to software engineering include iterative and incremental development, frequent releases of software, direct stakeholder involvement, minimal documentation and welcome changing requirements even late in the development cycle. The Agile Requirements Engineering applies the above mentioned principles to the Requirements Engineering process. Agile Requirements Engineering welcomes changing requirements even late in the development cycle. This is achieved by using the agile practice of evolutionary requirements which suggests that requirements should evolve over the course of many iterations rather than being gathered and specified upfront. Hence, changes to requirements even late in the development cycle can be accommodated easily. There is however, no real process to the agile approach to Requirements Engineering. In order to overcome this disadvantage, we propose to adapt the Requirements Generation Model (a plan-driven Requirements Engineering model) to an agile environment in order to structure the Agile Requirements Engineering process. The hybrid model named the Agile Requirements Generation Model is a soft-structured process that supports the intents of the agile approach. This model combines the best features of the Requirements Generation Model and Agile Software Development.
Master of Science

APA, Harvard, Vancouver, ISO, and other styles

2

Kola, Abhinav Ram. "Customer communication challenges in Agile Requirements Engineering." Thesis, Blekinge Tekniska Högskola, Institutionen för programvaruteknik, 2020. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-20645.

Full text

Abstract:

Context and background: Requirements engineering(RE) is a first and a very important phase in any software development which helps in building a suitable and customer satisfactory product. In the past few years, the use of Agile software development has become popular in the industry. Customer communication plays an important role in any software development life cycle. Customers state the requirements needed to develop a product in the Requirements Engineering phase. A project is likely to fail due to problems in customer communication during the RE phase. Objective: This thesis aims to study the Customer communication challenges in Agile requirements engineering, prioritize these challenges, and also find out the mitigation strategies to overcome these challenges. Research Method: A systematic mapping study is conducted to find out the customer communication challenges. Based on the data collected from the systematic mapping study, a survey is conducted to find out the mitigation strategies to overcome the customer communication challenges faced in the RE phase and also prioritize these challenges. Results: Based on the data collected from the systematic mapping study, a total of 18 customer communication challenges are identified. In the second step, a survey is conducted based on the identified challenges. The prioritization of these challenges is done by calculating the risk analysis of the challenges from the survey data. And finally, mitigation strategies are mentioned to overcome all the identified 18 challenges.

APA, Harvard, Vancouver, ISO, and other styles

3

Zhu, Yunyun. "Requirements Engineering in an Agile Environment." Thesis, Uppsala University, Department of Information Technology, 2009. http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-108027.

Full text

Abstract:

The Requirements Engineering (RE) process often dominates the quality of a project.The requirement practices in a project team are supposed to be an important part ofthe whole software development process. Today lean and agile development isbecoming more and more popular in industry. Many project teams work in an agileenvironment in order to have rapid delivery of high-quality software. Usually the workof the teams adopting an agile methodology is flexible and changeable. This indicatesthat the requirements of the projects might also be frequently changed, which is avariation to the traditional RE that relies on long and detailed documentation.

This thesis investigates how to conduct a RE process under an agile environment – sothat there exist relatively formal but agile and changeable requirements within aproject. The methods planned to be used are literature study, a case study carriedout in two software development teams in the Test Tool & Support Section at SonyEricsson Mobile Communications AB, and one pilot in each team based on the casestudy. There were 11 employees interviewed, including eight developers, two productowners and one scrum master. The evaluation on the pilots was mainly based on thefeedback from the interviewees on the pilot.

The outcome of the evaluation was that one of the teams (BRAT team) should adoptuser stories for user-related requirements, “done criteria” and non-functionalrequirements, and have the product owner to do the demonstration during the sprintreview in the future. Also, when budget allows, they should have one or morefull-time testers in the team and formal documentation of the requirements. Besidesthe suggestion for the BRAT team, QC team was suggested to have a glossary,formalize the defect description and have the product owner to ask the customersfor the feedbacks on the developers’ thoughts about the uncertain requirements.

APA, Harvard, Vancouver, ISO, and other styles

4

Rantanen, E. (Eetu). "Requirements engineering in agile software projects." Bachelor's thesis, University of Oulu, 2017. http://urn.fi/URN:NBN:fi:oulu-201705091721.

Full text

Abstract:

Many software projects are failed due to the delivery decisions that were made without adequate requirements information. In addition, the project management process including agile-oriented requirement management process has been identified as one of the four success factors in the agile software projects. Having the clear rules for requirements engineering is, therefore, an important thing for agile software projects from their success point of view. In this study, the objective is to analyze agile requirements engineering and to find out practices that are used in it. The goal is to define a continuous process to identify customer needs and translate them into software requirements in the agile software development. This goal is going to be achieved by a systematic literature review on the agile requirements engineering. For the agile software development and the traditional requirements engineering, the theory has been gathered from some basic books of the theme. The primary research question for this study is: How the customer needs will be translated into requirements in the agile software project as a continuous process? There are also two secondary research questions: 1. What are the customer needs and how can they be identified? 2. What kind of practices are used in the agile requirements engineering? Generally, the requirements engineering process includes four separate steps. First, the business usefulness of the system should be evaluated (feasibility study). After that, the requirements are discovered (elicitation and analysis)and converted into some standard form (specification). Last phase includes checking that the requirements define the system as customer wants (validation). Agile requirements engineering includes four major practices. The high-level interaction between the development team and the customer, iterative approach for the requirements engineering, prioritizing the requirements based on their business value for the customer, and eliciting also the non-functional requirements. In addition, the documentation of requirements is minimalistic in agile approaches. Results of this study can generally be applied and the model created can be utilized as a guideline when doing requirements engineering in the agile software projects
Monet ohjelmistoprojektit epäonnistuvat, koska tieto vaatimuksista on riittämätöntä toimituspäätöksiä tehdessä. Lisäksi projektinhallinnan prosessi, johon sisältyy ketterä vaatimustenhallinnan prosessi, on tunnistettu yhdeksi neljästä ketterien ohjelmistoprojektien menestystekijästä. Tämän takia ketterien ohjelmistoprojektien onnistumiseksi on tärkeää, että vaatimusmäärittelylle on selkeät ohjeet. Tämän tutkimuksen tarkoituksena on analysoida ketterää vaatimusmäärittelyä ja löytää siinä yleisesti käytettyjä tapoja. Tavoitteena on määrittää jatkuva prosessi, jossa asiakkaan tarpeet tunnistetaan ja käännetään ohjelmiston vaatimuksiksi ketterässä ohjelmistokehityksessä. Tavoitteeseen pyritään tekemällä systemaattinen kirjallisuuskatsaus ketterään vaatimusmäärittelyyn. Ketterää ohjelmistokehitystä sekä perinteistä vaatimusmäärittelyä käsitellään muutaman perusteoksen pohjalta. Tutkimuksen ylätason tutkimuskysymys on: Kuinka asiakkaan tarpeet käännetään vaatimuksiksi jatkuvana prosessina ketterissä ohjelmistoprojekteissa? Lisäksi tutkimuksella on kaksi alatason tutkimuskysymystä: 1. Mitä asiakkaan tarpeet ovat ja kuinka ne tunnistetaan? 2. Minkälaisia tapoja ketterässä vaatimusmäärittelyssä käytetään? Yleinen vaatimusmäärittelyprosessi sisältää neljä vaihetta. Ensin arvioidaan järjestelmän liiketoiminnallinen tarpeellisuus (kannattavuusselvitys). Tämän jälkeen etsitään vaatimuksia (selvitys ja analyysi) ja käännetään ne johonkin standardimuotoon (spesifikaatio). Viimeisessä vaiheessa tarkistetaan, että vaatimukset määrittävät järjestelmän juuri asiakkaan haluamalla tavalla (validointi). Ketterässä vaatimusmäärittelyssä on neljä yleistä käytäntöä. Korkean tason kanssakäyminen asiakkaan ja kehitystiimin välillä, iteratiivinen eli toistava lähestymistapa vaatimusmäärittelyyn, vaatimusten priorisointi perustuen asiakkaalle syntyvään arvoon ja myös ei-funktionaalisten vaatimusten tunnistus. Lisäksi voidaan sanoa, että vaatimusten dokumentointi ketterissä menetelmissä on vähäistä. Tämän tutkimuksen tuloksia voidaan yleisesti ottaen hyödyntää ja kehitettyä mallia voidaan käyttää vaatimusmäärittelyn ohjenuorana ketterissä ohjelmistoprojekteissa

APA, Harvard, Vancouver, ISO, and other styles

5

Lagré, Mårten. "Varför arbetar vissa utvecklingsteam agilt med kravhantering och vissa inte? : En fallstudie på Lantmäteriet." Thesis, Högskolan Dalarna, Informatik, 2017. http://urn.kb.se/resolve?urn=urn:nbn:se:du-25514.

Full text

Abstract:

Kravhantering inom systemutveckling utgör basen för vad som ska utvecklas. Agila systemutvecklingsmetoder blir vanligare för varje dag som går. Det har dock ofta visat sig finnas utmaningar med hur man anpassar just kravhanteringen till de agila metoderna. Verksamheter har olika förutsättningar för att arbeta agilt. Lantmäteriet i Gävle uttryckte ett behov att undersöka varför den agila praxis man hade inte följdes av alla utvecklingsteam i samband med kravhanteringen. Syftet med denna uppsats var därför att undersöka varför vissa utvecklingteam i en verksamhet arbetade agilt med sin kravhantering medan vissa inte gjorde det. För att undersöka detta utförde jag en fallstudie där jag med hjälp av enkäter och intervjuer samlade in data från både utvecklare och personer på verksamhetssidan som var inblandade i kravhanteringen. Resultaten visade att orsakerna till att en agil kravhantering fungerade så olika var flera. Genom att använda en tematisk analys kunde jag urskilja några framträdande orsaker. Kommunikation och flexibilitet samt kunskap och förståelse för olika perspektiv var teman som utgjorde positiva faktorer. De teman som istället utgjorde negativa faktorer var bland andra otydliga roller, brist på direktiv, en övertro till metoder och processer, osynk mellan verksamhet och IT, prioriteringsproblem, förvaltningsplaner, attityder och IT-arkitektur.
Requirements engineering within software development is the foundation of what needs to be developed. Agile methods in software development become more common every day. It has however often been shown that there are certain challenges with how to adopt the requirements engineering to the agile methodology. Businesses have different preconditions for agile methods. Lantmäteriet in Gävle had a need to examine why not all the developing teams followed agile methods within the requirements engineering process. The purpose with this thesis was thus to examine why some developing teams in an organization worked in an agile manner with the requirements engineering, and some did not. To do this I performed a case study where I collected data through questionnaires and interviews from both developers and people from the business side. The results showed that the reasons for these differences were multiple. Communication and flexibility, and knowledge and understanding for different perspectives were the positive factors. The themes that hindered an agile way of working were, among others, unclear roles, lack of direction, too much reliance on methods and processes, discrepancy between business and IT, prioritizing issues, management plans, attitudes and IT architecture.

APA, Harvard, Vancouver, ISO, and other styles

6

Robles, Luna Esteban. "Agile managing of web requirements with WebSpec." Tesis, Universidad de Alicante, 2011. http://hdl.handle.net/10915/4197.

Full text

Abstract:

Web application development is a complex and time consuming process that involves di erent stakeholders (ranging from customers to developers); these applications have some unique characteristics like navigational access to information, sophisticated interaction features, etc. However, there have been few proposals to represent those requirements that are speci c to Web applications. Consequently, validation of requirements (e.g. in acceptance tests) is usually informal, and as a result troublesome. To overcome these problems, this PhD Thesis proposes WebSpec, a domain speci c language for specifying the most relevant and characteristic requirements of Web applications: those involving interaction and navigation. We describe WebSpec diagrams, discussing their abstraction and expressive power. As part of this work, we have created a test driven model based approach called WebTDD that gives a good framework for the language. Using the language with this approach we have test several of its features such as automatic test generation, management of changes in requirements, and improving the understanding of the diagrams through application simulation. This PhD Thesis is composed of a set of published and submitted papers. In order to write this PhD Thesis as a collection of papers, several requirements must be taken into account as stated by the University of Alicante. With regard to the content of the PhD Thesis, it must speci cally include a summary which is devoted to the description of initial hypotheses, research objectives, and the collection of publications itself, thus justifying its coherence. It should be underlined that this summary of the PhD Thesis must also include research results and nal conclusions. This summary corresponds to part I of this PhD Thesis (chapter 1 has been written in Spanish while chapter 2 is in English). This work has been partially supported by the following projects: MANTRA (GV/2011/035) from Valencia Ministry, MANTRA (GRE09-17) from the University of Alicante and by the MESOLAP (TIN2010-14860) project from the Spanish Ministry of Education and Science.
Este trabajo ha sido parcialmente financiado por los siguientes proyectos: Mantra (GV/2011/035), Ministerio de Valencia, MANTRA (GRE09-17) de la Universidad de Alicante y por el MESOLAP (TIN2010-14860) proyecto del Ministerio de Educación y Ciencia de España.

APA, Harvard, Vancouver, ISO, and other styles

7

Al-kfairy, Mousa. "Toward Agile development methods & Non-functional requirements." Thesis, Linköpings universitet, Institutionen för datavetenskap, 2009. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-54656.

Full text

Abstract:

In this thesis, we tried to solve those problems by adapting agile development methods with Non-functional requirements-framework (NFR-Framework). In this thesis, we have inspected many research papers, and we have met industrial experts for feedback regarding our theoretical results. As a result of the inspection, we have been able to adapt agile development methods (extreme programming (XP)) with NFR-framework. We use XP since it is more practically oriented process than other agile development methods. In the first try for this process model, we got three alternatives for applying it. The first one is based on collecting all NFRs from the beginning of the development process. The second one is based on updating the SIG (software interdependency graph) every time we have new functional requirements (FR) and the third one is based on the incremental nature of agile development methods. Each one of these alternatives has it is own advantages and disadvantages. We tried to extract those advantages and disadvantages by brainstorming and reading research papers. The most important issue in all of the three alternatives is the applicability. Finally we got industrial feedback regarding all of them. As a result of the industrial feedback, we were able to find another alternative of how to apply the process model which is presented in 7.2.

APA, Harvard, Vancouver, ISO, and other styles

8

Karlsson, Josefine. "Agile in a small project : A refinement of a framework for agile requirements engineering." Thesis, Örebro universitet, Handelshögskolan vid Örebro Universitet, 2014. http://urn.kb.se/resolve?urn=urn:nbn:se:oru:diva-37681.

Full text

APA, Harvard, Vancouver, ISO, and other styles

9

Farid, Weam Mohamed. "The NORMAP Methodology: Non-functional Requirements Modeling for Agile Processes." NSUWorks, 2011. http://nsuworks.nova.edu/gscis_etd/147.

Full text

Abstract:

Agile software development methodologies, such as Scrum, have gained tremendous popularity and proven successful in quickly delivering quality Functional Requirements (FRs). However, agile methodologies have not adequately identified, modeled, and linked Non-Functional Requirements (NFRs) with FRs in early development phases. Researchers agree that NFRs have been generally ignored in conventional methodologies, especially ignored in agile environments. This dissertation develops a conceptual framework for NFR modeling in agile processes. The proposed Non-functional Requirements Modeling for Agile Processes (NORMAP) Methodology investigated the feasibility of identifying, linking, and modeling Agile Loose Cases (ALCs) with Agile Use Cases (AUCs) and Agile Choose Cases (ACCs). AUCs are newly proposed hybrid of use cases and agile user stories. ALCs are proposed—loosely—defined agile NFRs. ACCs are proposed potential solutions (operationalizations) for ALCs. A lightweight adapted version of the NFR Framework was developed including 25 important NFRs selected out of 161 for this study. Further, an enhanced risk-driven agile requirements implementation sequence (NORPLAN) was developed and visualized as a tree-like view (NORVIEW). The NORMAP Methodology was validated through developing NORMATIC--a Java-based agile visual modeling simulation tool and two case studies. NORMATIC utilized Natural Language Processing (NLP) tools to parse requirement sentences and identify potential ALCs. The first case study utilized the Predictor Models in Software Engineering (PROMISE) dataset used in NFRs classification. NORMAP successfully parsed and classified ALCs for 529 out of 607 (87.15%) independent user requirements. The second case study utilized the European Union eProcurement System’s 26 functional requirements. NORMAP successfully parsed and classified ALCs for 50 out of 57 sentences that included possible ALCs (87.71%). Furthermore, requirements quality and project management metrics were used to calculate a risk-driven requirements implementation sequence using three priority schemes. Results showed that Riskiest-Requirements-First priority scheme planned requirements in 17 sprints--two months earlier than the Highest-Business-Value-First scheme (21 sprints) and one month earlier than the Riskiest-Requirements-Last scheme (19 sprints). Agile communities can potentially benefit from the NORMAP Methodology by utilizing a systematic and risk-driven lightweight engineering process to visually model and plan NFRs as first-class artifacts in agile environments.

APA, Harvard, Vancouver, ISO, and other styles

10

Knudsen, Anders Nordli. "Agile Security Requirements : A master study into their application." Thesis, Norges teknisk-naturvitenskapelige universitet, Institutt for datateknikk og informasjonsvitenskap, 2014. http://urn.kb.se/resolve?urn=urn:nbn:no:ntnu:diva-26763.

Full text

Abstract:

Agile is the contemporary development practice of choice but security has been claimed as a challenge for it. This thesis investigates whether agile methods can be used for security-critical software and if the reason why the majority of Norwegian companies deviate from the agile methodology in their development is linked to security, by looking at the security requirements. A questionnaire and interviews of Norwegian companies were undertaken, and while the questionnaire did not yield any results the data from the interview indicate that the reasons for not conforming to the methodology appear to be related to security work and assurance. Agile is implied by the limited sample size to not only be useable for security-critical software but may be the best option in projects with uncertainty to the system and changing security requirements.

APA, Harvard, Vancouver, ISO, and other styles

11

Lindström, Erik. "Agile requirements engineering in globally distributed software development projects." Thesis, KTH, Industriell ekonomi och organisation (Inst.), 2020. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-281885.

Full text

Abstract:

Requirements engineering remains an important discipline to reduce costs, development times and improve quality in software engineering projects. With Agile methods gaining prominence in a rapidly globalized world, many requirements engineering efforts are today made in distributed contexts, with both teams and stakeholders being separated by physical and organisational distances. At the same time, it is not well understood how agile methods for requirements engineering apply to distributed contexts. This thesis investigates the implementation and use of agile methods for requirements engineering in distributed software engineering contexts. Observations made over a three-month study of the CHAMP project, a joint IT and process development effort between major European truck manufacturers Scania and MAN, are used to assess how commonly practices agile methods perform when implemented over distances. The case study of the CHAMP study suggests that the implementation of agile methods is highly context-sensitive, with limited current opportunities to formulate general heuristics for successful applications. The results of the CHAMP study indicate that distributed contexts hamper team communications when compared to co-located efforts, making it more difficult to implement an overall agile project model. However, individual methods, particularly the use of work backlogs, are found to offer increased structural flexibility beneficial to distributed workflows. Additionally, the CHAMP observations suggest implementing agile methods in new contexts requires an organisational mandate, as agile workflows are less predictable than linear models and can expose the surrounding organisation to higher uncertainty.
Kravhantering är fortsatt ett viktigt verktyg för att reducera kostnader, utvecklingstider och öka leveranskvalitet i mjukvaruutveklingsprojekt. Då agila metoder har blivit allt vanligare i en snabbt globaliserad värld, genomförs idag många kravhanteringsprocesser i utspridda sammanhang, där både projektets personal och intressenter är separerade av fysiska och organisatoriska avstånd. Samtidigt är det inte väl förstått hur agila metoder för kravhantering applicerar i utspridda sammanhang. Detta examensarbete undersöker hur agila metoder han implementeras och användas för kravhanteringsprocesser i utspridda mjukvaruutvecklingsprocesser. Observationer insamlade under en tremånadersstudie av CHAMP-projektet, ett gemensamt IT- och affärsutvecklingsprojekt mellan de stora europeiska lastbilstillverkarna Scania och MAN, används för att bedöma hur vanligt förekommande agila metoder fungerar när de tillämpas i agila sammanhang. Fallstudien av CHAMP-projektet indikerar att den specifika kontexten kan kraftigt påverka implementationen ag agila metoder, vilket för närvarande begränsar möjligheten att formulera generella tumregler för hur de framgångsrikt kan lanseras. CHAMP-studiens resultat påvisar att utspridda projekt har svårare att kommunicera jämför med samlokaliserade grupper, vilket gör det svårare att implementera sammanhållet agila projektmodeller. Samtidigt kan enskilda agila metoder, särskilt användningen av backlogs, hjälpa till att öka flexibiliteten i projekt, vilket är värdefullt i utspridda arbetsprocesser. Slutligen påvisar observationerna från CHAMP-projektet att det är viktigt med ett organisatoriskt mandat vid implementationen av agila metoder, då de är mindre förutsägbara än linjära processer och kan utsätta omkringliggande organisationer för högre osäkerhet.

APA, Harvard, Vancouver, ISO, and other styles

12

Alotaibi, Minahi. "Modelling security requirements through extending Scrum agile development framework." Thesis, De Montfort University, 2016. http://hdl.handle.net/2086/12491.

Full text

Abstract:

Security is today considered as a basic foundation in software development and therefore, the modelling and implementation of security requirements is an essential part of the production of secure software systems. Information technology organisations are moving towards agile development methods in order to satisfy customers' changing requirements in light of accelerated evolution and time restrictions with their competitors in software production. Security engineering is considered difficult in these incremental and iterative methods due to the frequency of change, integration and refactoring. The objective of this work is to identify and implement practices to extend and improve agile methods to better address challenges presented by security requirements consideration and management. A major practices is security requirements capture mechanisms such as UMLsec for agile development processes. This thesis proposes an extension to the popular Scrum framework by adopting UMLsec security requirements modelling techniques with the introduction of a Security Owner role in the Scrum framework to facilitate such modelling and security requirements considerations generally. The methodology involved experimentation of the inclusion of UMLsec and the Security Owner role to determine their impact on security considerations in the software development process. The results showed that overall security requirements consideration improved and that there was a need for an additional role that has the skills and knowledge to facilitate and realise the benefits of the addition of UMLsec.

APA, Harvard, Vancouver, ISO, and other styles

13

PINTO, THIAGO DELGADO. "UNIFYING AGILE REQUIREMENTS SPECIFICATION QUALITY CONTROL AND IMPLEMENTATION CONFORMANCE ASSURANCE." PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO, 2018. http://www.maxwell.vrac.puc-rio.br/Busca_etds.php?strSecao=resultado&nrSeq=35867@1.

Full text

Abstract:

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO
COORDENAÇÃO DE APERFEIÇOAMENTO DO PESSOAL DE ENSINO SUPERIOR
PROGRAMA DE EXCELENCIA ACADEMICA
Práticas de engenharia de requisitos ágeis estão se tornando mais comuns em equipes de desenvolvimento de software. Contudo, as práticas relacionadas ao controle de qualidade ainda dependem fortemente do conhecimento, da experiência e do trabalho manual de testadores, em adição as especificações de requisitos produzidas são frequentemente imprecisas e difíceis de verificar estaticamente por interessados ou por algum computador. Essa tese ataca conjuntamente o problema de verificar estaticamente especificações de requisitos ágeis e de gerar casos de teste e scripts de teste automatizados completos a partir delas. Suas contribuições principais incluem: (1) uma nova metalinguagem, chamada Concordia, que permite escrever especificações de requisitos ágeis que podem ser usadas para atividades de verificação e validação (V e V); (2) uma nova abordagem para gerar casos de teste e scripts de teste automatizado completos, a partir de requisitos especificados com a metalinguagem; (3) a medição, em contexto industrial, da capacidade da abordagem em reduzir o risco de defeitos e custos de V e V.
Agile requirements engineering practices are being used more commonly by software development teams. However, practices related to quality control still depend heavily on testers expertise and manual labor, whilst produced require-ments specifications are often imprecise and hard to verify statically by both stake-holders and computers. This thesis jointly tackles the problem of verifying statically agile requirements specifications and generating full-featured test cases and auto-mated test scripts from them. Its main contributions include: (1) a new metalan-guage, called Concordia, for writing agile requirement specifications that can be used for both verification and validation (V and V) activities involving stakeholders; (2) a novel approach to generate full-featured ready to use test cases and automated test scripts from the requirements specified with the metalanguage; (3) the assess-ment in industrial context of the approaches ability to reduce risk of remaining defects and the costs of V and V.

APA, Harvard, Vancouver, ISO, and other styles

14

Omair, Muhammad. "Challenges in understanding software requirements in agile based offshore development." Thesis, Blekinge Tekniska Högskola, Avdelningen för programvarusystem, 2008. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-3740.

Full text

Abstract:

Agile based development seems to become a favorable model for offshore development. It allows both on and offshore team to work in small iterations minimizing the effect of change in software requirements and at the same time developing regular communication between them. However different factors such as physical distance and lack of communication between on and offshore team becomes a hurdle between them leading to misunderstandings about software requirements. This research work gives an insight about these challenges from the software industry by presenting and discussing the responses of four software companies located in different countries, collected through an online questionnaire. The authors found that lack of communication between on and offshore site is seen as a major challenge for better understanding of software requirements. Shorter iterations at the offshore site require more communication with the onshore site. The language problem seems to exist only when both on and offshore site who are non-English speakers communicate in English. Regular long distance meetings would help in better understanding of software requirements. Previous domain and product knowledge is helpful in better understanding of software requirements. This research work would allow different stakeholders within agile based on/offshore setting to better understand these challenges and deal accordingly with them.

APA, Harvard, Vancouver, ISO, and other styles

15

Andrei, Arratia-Falcon. "Prioritering av icke-funktionella krav i praktiken : Ur ett agilt perspektiv." Thesis, Uppsala universitet, Institutionen för informatik och media, 2013. http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-210354.

Full text

Abstract:

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.

APA, Harvard, Vancouver, ISO, and other styles

16

MEDEIROS, Juliana Dantas Ribeiro Viana de. "An approach to support the requirements specification in agile software development." Universidade Federal de Pernambuco, 2017. https://repositorio.ufpe.br/handle/123456789/25327.

Full text

Abstract:

SCHUENEMANN, Carla Taciana Lima Lourenco Silva, também é conhecida em citações bibliográficas por: SILVA, Carla
Submitted by Fernanda Rodrigues de Lima (fernanda.rlima@ufpe.br) on 2018-07-31T22:18:30Z No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5)
Approved for entry into archive by Alice Araujo (alice.caraujo@ufpe.br) on 2018-08-01T22:34:12Z (GMT) No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5)
Made available in DSpace on 2018-08-01T22:34:12Z (GMT). No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5) Previous issue date: 2017-03-13
Although Agile Software Development (ASD) has grown in recent years, research evidence points out several limitations concerning its requirements engineering activities. It was observed that an inadequate specification acts as a catalyst to others problems, such as low productivity of the team and difficulty in maintaining software. Improving the quality of Software Requirements Specifications (SRS) may help gaining a competitive advantage in the software industry. The goal of this study is to investigate the phenomenon of the requirements specification activity in ASD, discuss relevant findings of this phenomenon to industrial practice, and propose practices to write a SRS targeted to development team. First, a Systematic Mapping (SM) study was conducted to characterize the landscape of requirements engineering in ASD. The thematic synthesis method was used to code and synthesize the data collected from the primary studies selected. After that, some of the challenges pointed out in the SM were investigated in more depth in six industrial case studies. Data collected from documents, observations, and interviews with software engineers were triangulated, analyzed, and synthesized using techniques of grounded theory and metaethnography. The analysis and cross-synthesis of the case studies resulted in a model that defines the simplicity and objectivity as essential quality factors of SRS in ASD. The main factors that affect the quality are related to the customer-driven nature that tends to leave the prolix SRS, hindering the understanding of the software engineers, as they are, at the same time, insufficient to support coding, testing and maintenance tasks. One approach was proposed to provide a SRS closer to the development needs, addressing some of the quality factors of the model. Empirical studies that evaluated the approach show that the design practices used in the proposed approach have the potential to reduce the gap between the problem and the solution domains, producing an objective SRS that is team-driven and closer to that will be implemented.
Embora o Desenvolvimento Ágil de Software (DAS) tenha crescido nos últimos anos, estudos empíricos apontam vários problemas relacionados com as atividades de engenharia de requisitos. Observou-se que a especificação inadequada age como um catalizador para outros problemas, como por exemplo, baixa produtividade da equipe e dificuldades na manutenção do software. Melhorar a qualidade da Especificação de Requisitos de Software (ERS) pode ajudar a ganhar uma vantagem competitiva na indústria de software. O objetivo deste estudo é investigar o fenômeno da especificação de requisitos no DAS, discutir relevantes implicações desse fenômeno para a indústria, e propor práticas para escrever ERS voltadas para a equipe de desenvolvimento. Primeiro, um Mapeamento Sistemático (MS) foi realizado para caracterizar o panorama da engenharia de requisitos no DAS. O método de síntese temática foi utilizado para codificar e sintetizar os dados coletados a partir dos estudos primários selecionados. Em seguida, alguns dos desafios apontados no MS foram investigados com mais profundidade em seis estudos de caso industriais. Os dados coletados a partir de documentos, observações e entrevistas com engenheiros de software foram triangulados, analisados e sintetizados usando técnicas de teoria fundamentada e meta-etnografia. A análise e síntese cruzada dos estudos de caso resultaram em um modelo de qualidade que define a simplicidade e objetividade como fatores essenciais na ERS no DAS. Os principais fatores que afetam a qualidade estão relacionados à natureza orientada para o cliente que tende a deixar a ERS prolixa, dificultando a compreensão do engenheiro de software, ao mesmo tempo que é insuficiente para a codificação, testes e manutenção. Uma abordagem foi proposta para fornecer uma especificação de requisitos mais próxima das necessidades de desenvolvimento, atendendo alguns dos fatores de qualidade do modelo. Os estudos empíricos que avaliaram a abordagem demonstram que as práticas de design utilizadas pela abordagem tem o potencial de reduzir a distância entre o domínio do problema e o da solução, produzindo uma ERS objetiva, voltada para o desenvolvedor, e próxima do que vai ser implementado.

APA, Harvard, Vancouver, ISO, and other styles

17

Andersson, Lucas, and Martin Berglin. "Problematiken med estimering i projekt inom agil systemutveckling : Analys och undersökning av agil systemutveckling hos SDC." Thesis, Mittuniversitetet, Avdelningen för informations- och kommunikationssystem, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:miun:diva-28049.

Full text

Abstract:

In today’s society, IT-Companies often have a hard time estimating changed requirements. This leads to that the clients’ confidence is negatively affected and is one of the main reasons why this has to be improved. The goal with this study was to find out what the most common problems regarding this issue are in IT-companies that works with agile software development. By analyzing one IT-company through a SWOT- and pareto-analysis the most common problems have been ascertained. The SWOT analysis have been created through interviews with selected employees to get a better understanding of the problems that the IT-company is facing. Furthermore was the pareto-analysis based on a survey that was sent out to many different employees to prioritize the problems. The reason why the survey was sent to different employees was to get a more objective input. The study showed that there was many different problems that needed attention. The most important problems was that the communication towards the client regarding requirements needed to be improved, better communication internally between different departments needed to be established, a method to quickly adapt and estimate change in requirements needed to be implemented and finally a method regarding witch key employees whom need to attend the planning of the program backlog. These problems have then been studied through interviews with other IT-companies and through a literature study. The conclusions that where drawn was that the client needs to be involved and updated through the whole project. Constant monitoring and communication regarding changed requirements needs to be processed and mediated. High standards needs to be set early towards the client in order to obtain as clear an image of the requirements as possible. Many different parties need to attend to the planning process for the program backlog before the start of the project. The client needs to be aware of that changed requirements will arise and that this will lead to that the first estimation may not necessarily be absolute. As long as the client is held up to date as well as participant through the whole project and problems are detected and mediated early, change in requirements should not be a huge problem. This is after all the purpose of being agile.
I dagens läge har IT-företag svårt med att estimera förändrade krav vilket medför att förtroendet hos beställaren påverkas negativt och är en av hu-vudanledningarna till att det måste förbättras. Målet med studien har varit att försöka ta reda på de vanligaste problemområdena inom agil systemut-veckling bland IT-företag med hjälp av en SWOT- och pareto-analys. SWOT-analys konstruerades av intervjuer med anställda på ett IT-företag och an-vändes för att ta reda på problemområden. Pareto-analysen användes med hjälp av en enkät som skickades ut till anställda på samma IT-företag för att prioritera problemområdena. Enkätens svar bygger på anställda från de flesta avdelningar, vilket resulterar i en objektivare syn på resultatet. Under-sökningen har visat att det finns många områden som kan förbättras. De huvudsakliga områdena som behövde förbättras var tydligare kommunikat-ion gällande kravhantering gentemot kunden, bättre kommunikation mellan avdelningarna internt i företaget, införa en metod för att snabbt estimera samt anpassa sig till förändrade krav behövde implementeras och slutligen skapa struktur gällande vilka personer som bör delta i planeringen inför program backlog. De fyra största problemområdena har sedan undersökts med hjälp av intervjuer med andra företag och genom en litteraturstudie. Slutsatsen som drogs var att kunden behöver vara involverad och uppdate-rad genom hela projektet. Konstant uppföljning och kommunikation gäl-lande förändrade krav behöver bearbetas och förmedlas. Höga krav måste sättas på kunden i början för att få en tydlig och genomarbetad förståelse för kravspecifikationen som möjligt. Många olika parter bör vara med på planeringen inför program backlog innan projektets uppstart. Kunden bör vara medveten om att förändrade krav kommer att uppstå och att detta kommer att leda till att den första estimeringen inte nödvändigtvis kommer vara absolut. Så länge kunden är uppdaterad och delaktig genom hela pro-jektet och problem upptäcks samt förmedlas tidigt bör förändrade krav inte vara ett stort problem. Det är syftet med att vara agil.

APA, Harvard, Vancouver, ISO, and other styles

18

Qasaimeh, Malik. "Auditing for ISO 9001 requirements in the context of agile software processes." Mémoire, École de technologie supérieure, 2012. http://espace.etsmtl.ca/1056/1/QASAIMEH_Malik.pdf.

Full text

Abstract:

ISO 9001 exige des organisations une démonstration rigoureuse de la mise en oeuvre de leurs processus logiciels et un suivi d’un ensemble de lignes directrices à différents niveaux d'abstraction. En d'autres termes, ce que ces organisations ont besoin de démontrer c'est que leurs processus logiciels ont été conçus et mis en oeuvre d'une manière qui permette un niveau de configuration et de fonctionnement qui est conforme à la norme ISO 9001. Pour les organisations de logiciels qui ont besoin de la certification ISO 9001, il est important d'établir un processus de cycle de vie logiciel qui permet de gérer les exigences imposées par la présente norme de certification. Toutefois, les organisations de logiciels qui développent leurs produits logiciels en utilisant les processus logiciels agiles comme l'Extreme Programming (XP-agile) font face à un certain nombre de défis dans leurs efforts pour démontrer que leurs activités de processus sont conformes aux exigences d’ISO 9001. Les plus importants exigences ISO 9001 sont reliées à la construction du produit logiciel, la traçabilité et la mesure. Les processus dits Agile doivent fournir la preuve de la conformité ISO 9001, et ils doivent développer leurs propres procédures, outils et méthodologies pour ce faire. Pour l'instant, il n'y a pas de consensus sur la façon de vérifier les organisations de type agile pour s'assurer que leurs processus logiciels ont été conçus et mis en oeuvre en conformité avec les exigences ISO 9001. Il est donc difficile de prendre en compte des méthodologies de documentation du processus légers (par exemple logiciel agile agile-XP) pour démontrer que les exigences ISO 9001 ont été rencontrées. La motivation de cette recherche est d'aider les organisations de logiciels qui suivent des processus logiciels agiles à répondre aux exigences de certification ISO 9001. Ce projet de recherche vise également à aider les vérificateurs logiciels pour extraire des preuves d'audit qui démontrent la conformité aux exigences ISO 9001 des organisations de logiciels agiles. Extreme programming (XP-agile) a été choisi pour être amélioré comme un processus agile candidat. La sélection est basée sur la littérature indiquant une plus grande adoption de agile- XP parmi les autres processus de développement logiciel agile. Le but de ce projet de recherche est d'améliorer le processus Agile-XP pour rencontrer les exigences de vérification de la norme ISO 9001. L'objectif de la recherche vise également à aider les organisations de logiciels agiles dans leurs efforts pour devenir certifié ISO 9001. Un premier objectif de ce projet de recherche est de concevoir un modèle d'audit qui couvre l'exigence de mesure et de traçabilité de l'ISO 9001. Le modèle de vérification devrait fournir aux auditeurs des preuves d'audit que les projets de logiciels développés avec agilité-XP processus ont rempli les exigences de la norme ISO 9001. Le second objectif vise à proposer plusieurs sous-processus pour améliorer les activités de planification au début de agile-XP et selon les exigences ISO 9001. Pour atteindre ces objectifs, les principales phases de la méthodologie de recherche sont: Etude de la capacité de agile-XP pour atteindre les exigences de la certification ISO 9001 des processus logiciels; Modification de la phase précoce de agile-XP (i.e. la phase de planification) à l'aide du modèle CMMI-DEV; conception d'un modèle d'audit ISO 9001 pour rencontrer les exigences de traçabilité et de mesure. Le principal résultat de cette étude est un modèle d’audit qui est aligné avec les principes de souplesse-XP et se concentre sur la norme ISO 9001, et en particulier sur la traçabilité et les exigences de mesure de fournir des auditeurs est une approche méthodologique pour le processus de vérification. Le résultat de cette recherche a été évalué sur la base de neuf études de cas identifiées dans la littérature.

APA, Harvard, Vancouver, ISO, and other styles

19

Rane, Prerana Pradeepkumar. "Automatic Generation of Test Cases for Agile using Natural Language Processing." Thesis, Virginia Tech, 2017. http://hdl.handle.net/10919/76680.

Full text

Abstract:

Test case design and generation is a tedious manual process that requires 40-70% of the software test life cycle. The test cases written manually by inexperienced testers may not offer a complete coverage of the requirements. Frequent changes in requirements reduce the reusability of the manually written test cases costing more time and effort. Most projects in the industry follow a Behavior-Driven software development approach to capturing requirements from the business stakeholders through user stories written in natural language. Instead of writing test cases manually, this thesis investigates a practical solution for automatically generating test cases within an Agile software development workflow using natural language-based user stories and acceptance criteria. However, the information provided by the user story is insufficient to create test cases using natural language processing (NLP), so we have introduced two new input parameters, Test Scenario Description and Dictionary, to improve the test case generation process. To establish the feasibility, we developed a tool that uses NLP techniques to generate functional test cases from the free-form test scenario description automatically. The tool reduces the effort required to create the test cases while improving the test coverage and quality of the test suite. Results from the feasibility study are presented in this thesis.
Master of Science

APA, Harvard, Vancouver, ISO, and other styles

20

Domah, Darshan. "The NERV Methodology: Non-Functional Requirements Elicitation, Reasoning, and Validation in Agile Processes." NSUWorks, 2013. http://nsuworks.nova.edu/gscis_etd/137.

Full text

Abstract:

Agile software development has become very popular around the world in recent years, with methods such as Scrum and Extreme Programming (XP). Literature suggests that functionality is the primary focus in Agile processes while non-functional requirements (NFR) are either ignored or ill-defined. However, for software to be of good quality both functional requirements (FR) and NFR need to be taken into consideration; lack of attention to NFR has been documented to be the cause of failure for many software projects. Hence special attention needs to be focused on NFR in Agile software development. By its very nature Agile processes require frequent changes but these changes are often not well documented. This is especially true of NFR in Agile processes. While functional requirements are carefully identified, NFR are often not properly elicited. Once NFR are identified they become the basis for reasoning and facilitation of design and development decisions. NFR also need to be validated through proper testing to ensure their quality attributes have been met in the final software product. This dissertation aimed at developing a methodology for addressing NFR in Agile processes. As such, the "NERV Methodology: Non-Functional Requirements Elicitation, Reasoning, and Validation in Agile Processes" was proposed. Several artifacts were created as part of this methodology and included: the NFR Elicitation Taxonomy, the NFR Reasoning Taxonomy, the NFR Quantification Taxonomy, and the Non-Functional Requirements User Story Companion (NFRusCOM) Card. Additionally the NERV Agility Index (NAI) was developed using the Agile Manifesto and its twelve principles. The NERV Methodology was validated using the 26 requirements of the European Union (EU) eProcurement Online System. Additionally the results obtained by the NORMAP Methodology in previous research, were used as baseline. Results show that the NERV Methodology was successful in identifying NFR, for 55 out of 57 requirements sentences that contained implicit NFR, compared to 50 for the baseline. This represented a 96.49% success rate compared to 87.71% for the baseline; an improvement of 8.78%. Furthermore the NERV Methodology was successful in eliciting 82 out of 88 NFR compared to 75 for the baseline. The elicitation success rate was 93.18% compared to 85.24% for the baseline; an improvement of 7.94%. Agility was validated using the same data set as above. Two experiments investigated project durations measured in 2-week sprint iterations, commonly used in Scrum. Results show that the first experiment, using the "FR and NFR Simultaneous Scheme" completed all FR and NFR scope in 24 sprints. The second experiment, using the "FR First Then NFR Scheme" consumed 26 sprints. The first agile scheduling scheme delivered all scope two sprints earlier than the second scheme; representing a saving of almost one month. Validation results showed that the NERV Methodology and its artifacts can potentially be beneficial for software development organizations for eliciting, reasoning about, and validating NFR in Agile processes.

APA, Harvard, Vancouver, ISO, and other styles

21

Nilsson, Emil, and Eddie Andersson. "Agil kravhantering i praktiken : Efterföljs det som formuleras i litteraturen verkligen i praktiken?" Thesis, Linköpings universitet, Informatik, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-131468.

Full text

Abstract:

Att arbeta agilt är idag vanligt förekommande inom IT-branschen där företag ständigt måste anpassa sig till förändringar. Scrum är idag den främst tillämpade agila metoden och har stark koppling till utvecklingsprojekt och kravhantering. Trots detta finns det få empiriska studier om Scrum och det finns även en brist på jämförande studier som ställer kravhantering i praktiken mot det som finns formulerat i litteraturen. Vi har därför i denna studie undersökt hur arbetet med kravhantering i utvecklingsprojekt bedrivs i praktiken hos en organisation som arbetar efter Scrum och jämfört om arbetet utförs i enlighet med det som står i litteraturen. Vi har även tittat på vilka problem och svårigheter som kan uppkomma i kravhanteringsarbetet samt vilka aspekter som utövarna i praktiken betraktar som viktigast. För att ta reda på hur arbetet faktiskt genomförs intervjuade vi fyra personer på företaget Arris, alla med olika befattningar och kopplingar till kravhantering. Slutsatsen av undersökningen visar att kravhanteringsarbetet i praktiken i de flesta aspekter överensstämmer med det som formuleras i litteraturen. Det finns dock områden som ej går helt i linje, dokumentation av krav är ett sådant.
Working agile is nowadays common within the IT industry where companies constantly have to cope and adapt to change. Scrum is today the most applied agile method and is strongly linked to development projects and requirements engineering. Despite this, there are few empirical studies on Scrum and it also lacks comparative studies where requirements engineering in practice are compared to what is formulated in the literature. As a result of this, we have in this survey, examined how requirements engineering in an organization that is using Scrum is conducted in practice in accordance to what is formulated in the literature. We also identified problems and difficulties that may arise in the work with requirements engineering and also which aspects practitioners considers as most important. In order to be able to realize this study we interviewed four practitioners from Arris, all with different positions and connections to requirements engineering. The conclusion of this study shows that the requirements engineering in practice in most aspects is consistent with what the literature advocates. However, there are areas that not fully correspond to what is written in the literature, documentation of requirements is one such area.

APA, Harvard, Vancouver, ISO, and other styles

22

Walden, Alice. "Decision traceability in agile software projects : Enabling alignment between changing requirements and product goals." Thesis, Linköpings universitet, Informatik, 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-159199.

Full text

Abstract:

Agile project management emphasizes flexibility and adapting to change. Embracing change often means that specified requirements get changed, removed or replaced under the course of a software project. Another consequence of the nature of agile projects is that everything that does not directly contribute to the working software gets dropped from the product lifecycle. Traceability – the ability to trace requirements back to their origins and forward to design artifacts, code, and testcases – is one such thing that may be overlooked. At the same time, traceability may be crucial to making sure that the delivered product meets the product goals. This thesis investigates the concept of decision traceability – the ability to trace decisions that relate to the evolution of a software product, as well as the fulfillment of product goals. The purpose of this thesis is to understand the importance of decision traceability in relation to product goals and changing requirements in agile software projects. For this purpose, two research questions were developed. (1) What are the challenges of achieving decision traceability in agile projects? And (2) What are important aspects of achieving decision traceability in agile projects? An interpretive qualitative case study was conducted at an IT-consultancy firm. In the case study, two of the organization’s in-house projects were observed, and six informants were interviewed. In answer to the research questions, seven challenges and six important aspects of achieving decision traceability were identified. A conclusion that can be made from the findings is that other aspects than just well-defined processes– such as team engagement, value perception, and communication – may be essential to achieving decision traceability in agile software projects.

APA, Harvard, Vancouver, ISO, and other styles

23

Hedberg, Mikael. "Competences in Agile Development : Exploring the social, functional and cognitive requirements of a systems developer." Thesis, Umeå universitet, Institutionen för informatik, 2015. http://urn.kb.se/resolve?urn=urn:nbn:se:umu:diva-101220.

Full text

Abstract:

Agile methodologies are becoming increasingly more popular among developers. However, there is little known research regarding the competences of working in development projects. This led me to my research question, what competences are considered important for working in agile projects? I narrowed down my research to three categories of competence; social, functional and cognitive. In order to gather the information needed for the study, I interviewed developers with and extensive knowledge and experience from working in agile development projects. The results from the study revealed that there is a need for a broad set of competences for working in agile development projects. This study is intended to contribute to the literature on competences is systems development by exploring the competence requirements for systems developers working in agile methods.

APA, Harvard, Vancouver, ISO, and other styles

24

Abrahamsson, Linn, and Wenström Peter Melin. "Användning av prototyper som verktyg för kravhantering i agil mjukvaruutveckling : - En fallstudie." Thesis, Linköpings universitet, Programvara och system, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-150528.

Full text

Abstract:

Kravhantering vid agil mjukvaruutveckling är en utmaning som allt fler företag ställs inför.Prototyper, modeller som liknar tilltänkta slutprodukter, kan användas för att inhämtaviktig information om det som ska utvecklas. För att beskriva hur lik en prototyp är dentilltänkta slutprodukten används begreppet verklighetsfaktor. Studiens syfte är dels attöka kunskapen kring prototypanvändning i agil mjukvaruutveckling, dels att undersökavilken effekt en prototyps verklighetsfaktor har då prototyper används i diskussioner inomkravhantering. En fallstudie görs på företaget Exsitec där personal intervjuas angående prototypanvändning i mjukvaruprojekt. Två prototyper utvecklas sedan med låg respekti-ve hög verklighetsfaktor och används som diskussionsunderlag i intervjuer. Studien visar att användning av prototyper i mjukvaruprojekt kan bidra till ökat förtroende hos kun-der, förbättrad kommunikation med kunder och kan förenkla att uppnå konsensus mellan olika intressenter. Vidare kan de, beroende av hur de används, bidra till helhetsbilden avprodukten och fungera som dokumentation. Studien påvisar även några, om än subtila, skillnader i den information som samlas in med hjälp av prototyper med låg respekti-ve hög verklighetsfaktor. Hög verklighetsfaktor tycks medföra att fler krav samlas in, men göra respondenter mindre benägna att vilja komma med förslag på mer omfattandeförändringar.
Requirements Engineering (RE) in Agile Software Development (ASD) is a challenge thatmany face and several techniques exist when doing so. One such technique is prototyping, when a model of a product is used to gather important information in software develop-ment. To describe how much a prototype resembles the product the notion of fidelity is used. The aim of this study is to contribute to research regarding prototyping in ASD,and to examine the effect of a prototype’s fidelity when using prototypes in discussionsduring RE. A case study is performed at the company Exsitec where staff are interviewedregarding prototyping in software development. Thereafter, two prototypes of low andhigh fidelity are developed and used in interviews as a basis for discussion. Based on thisstudy, the use of prototypes in software projects can help customers trust the process,improve communication with customers, and facilitate when trying to reach consensusamong different stakeholders. Furthermore, depending on how they are used, prototypescan contribute to understanding the big picture of the requirements and can also serve asdocumentation. The study also shows some, albeit subtle, differences in the informationcollected using prototypes with low and high fidelity. The use of a high fidelity prototypeseems to generate more requirements, but makes interviewees less likely to come up withlarger, more comprehensive requirement changes.

APA, Harvard, Vancouver, ISO, and other styles

25

Gislén, Mikael. "Achieving Agile Quality : An Action Research Study." Thesis, Blekinge Tekniska Högskola, Institutionen för kreativa teknologier, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-13732.

Full text

APA, Harvard, Vancouver, ISO, and other styles

26

Auer, Sören, Thomas Riechert, and Klaus-Peter Fähnrich. "SoftWiki - Agiles Requirements-Engineering für Softwareprojekte mit einer großen Anzahl verteilter Stakeholder." Saechsische Landesbibliothek- Staats- und Universitaetsbibliothek Dresden, 2014. http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-139759.

Full text

Abstract:

In den 80er und 90er Jahren hatten große Anwendungssysteme in Unternehmen einige hundert bis tausend Anwender. Der Software-Entwicklungsprozess für diese Anwendungen war innerhalb der Unternehmen relativ klar geregelt. Fachinformatiker und Fachabteilungen standen einander dabei gegenüber. Oft wurden auch externe Fachleute und Komponentenlieferanten integriert. Entwicklungsmethoden und Werkzeuge waren auf diese Situation ausgelegt. Seit dieser Zeit haben wesentliche Veränderungen stattgefunden. Internettechnologien haben neue Klassen von Applikationen ermöglicht, die wie folgt charakterisiert werden können: - Die Applikationen sind kooperativ (unternehmensübergreifend). Nicht selten sind 20-50 oder mehr Unternehmen z. B. bei Zulieferketten beteiligt. - Eine eigene Klasse bilden mandantenfähige Systeme sowie Business-to-Consumer Systeme (B2C) bei denen sehr große Nutzerzahlen konnektiert werden. - Die Entwicklungszeiten liegen im Bereich von Monaten statt Jahren für eine erste Bereitstellung einer Basislösung. - Die Systeme werden inkrementell unter starker Anwenderbeteiligung bis hin zur Endbenutzerbeteiligung weiterentwickelt. (...)

APA, Harvard, Vancouver, ISO, and other styles

27

Maiti, Richard Rabin. "Capturing, Eliciting, and Prioritizing (CEP) Non-Functional Requirements Metadata during the Early Stages of Agile Software Development." NSUWorks, 2016. http://nsuworks.nova.edu/gscis_etd/968.

Full text

Abstract:

Agile software engineering has been a popular methodology to develop software rapidly and efficiently. However, the Agile methodology often favors Functional Requirements (FRs) due to the nature of agile software development, and strongly neglects Non-Functional Requirements (NFRs). Neglecting NFRs has negative impacts on software products that have resulted in poor quality and higher cost to fix problems in later stages of software development. This research developed the CEP “Capture Elicit Prioritize” methodology to effectively gather NFRs metadata from software requirement artifacts such as documents and images. Artifact included the Optical Character Recognition (OCR) artifact which gathered metadata from images. The other artifacts included: Database Artifact, NFR Locator Plus, NFR Priority Artifact, and Visualization Artifact. The NFRs metadata gathered reduced false positives to include NFRs in the early stages of software requirements gathering along with FRs. Furthermore, NFRs were prioritized using existing FRs methodologies which are important to stakeholders as well as software engineers in delivering quality software. This research built on prior studies by specifically focusing on NFRs during the early stages of agile software development. Validation of the CEP methodology was accomplished by using the 26 requirements of the European Union (EU) eProcurement System. The NORMAP methodology was used as a baseline. In addition, the NERV methodology baseline results were used for comparison. The research results show that the CEP methodology successfully identified NFRs in 56 out of 57 requirement sentences that contained NFRs compared to 50 of the baseline and 55 of the NERV methodology. The results showed that the CEP methodology was successful in eliciting 98.24% of the baseline compared to the NORMAP methodology of 87.71%. This represents an improvement of 10.53% compared to the baseline results. of The NERV methodology result was 96.49% which represents an improvement of 1.75% for CEP. The CEP methodology successfully elicited 86 out of 88 NFR compared to the baseline NORMAP methodology of 75 and NERV methodology of 82. The NFR count elicitation success for the CEP methodology was 97.73 % compared to NORMAP methodology of 85.24 %which is an improvement of 12.49%. Comparison to the NERV methodology of 93.18%, CEP has an improvement of 4.55%. CEP methodology utilized the associated NFR Metadata (NFRM)/Figures/images and linked them to the related requirements to improve over the NORMAP and NERV methodologies. There were 29 baseline NFRs that were found in the associated Figures/images (NFRM) and 129 NFRs were both in the requirement sentence and the associated Figure/images (NFRM). Another goal of this study was to improve the prioritization of NFRs compared to prior studies. This research provided effective techniques to prioritize NFRs during the early stages of agile software development and the impacts that NFRs have on the software development process. The CEP methodology effectively prioritized NFRs by utilizing the αβγ-framework in a similarly way to FRs. The sub-process of the αβγ-framework was modified in a way that provided a very attractive feature to agile team members. Modification allowed the replacement of parts of the αβγ-framework to suit the team’s specific needs in prioritizing NFRs. The top five requirements based on NFR prioritization were the following: 12.3, 24.5, 15.3, 7.5, and 7.1. The prioritization of NFRs fit the agile software development cycle and allows agile developers and members to plan accordingly to accommodate time and budget constraints.

APA, Harvard, Vancouver, ISO, and other styles

28

Auer, Sören, Thomas Riechert, and Klaus-Peter Fähnrich. "SoftWiki - Agiles Requirements-Engineering für Softwareprojekte mit einer großen Anzahl verteilter Stakeholder." Technische Universität Dresden, 2006. https://tud.qucosa.de/id/qucosa%3A27838.

Full text

Abstract:

In den 80er und 90er Jahren hatten große Anwendungssysteme in Unternehmen einige hundert bis tausend Anwender. Der Software-Entwicklungsprozess für diese Anwendungen war innerhalb der Unternehmen relativ klar geregelt. Fachinformatiker und Fachabteilungen standen einander dabei gegenüber. Oft wurden auch externe Fachleute und Komponentenlieferanten integriert. Entwicklungsmethoden und Werkzeuge waren auf diese Situation ausgelegt. Seit dieser Zeit haben wesentliche Veränderungen stattgefunden. Internettechnologien haben neue Klassen von Applikationen ermöglicht, die wie folgt charakterisiert werden können: - Die Applikationen sind kooperativ (unternehmensübergreifend). Nicht selten sind 20-50 oder mehr Unternehmen z. B. bei Zulieferketten beteiligt. - Eine eigene Klasse bilden mandantenfähige Systeme sowie Business-to-Consumer Systeme (B2C) bei denen sehr große Nutzerzahlen konnektiert werden. - Die Entwicklungszeiten liegen im Bereich von Monaten statt Jahren für eine erste Bereitstellung einer Basislösung. - Die Systeme werden inkrementell unter starker Anwenderbeteiligung bis hin zur Endbenutzerbeteiligung weiterentwickelt. (...)

APA, Harvard, Vancouver, ISO, and other styles

29

Aalbers, Anouschka, and Linn Öberg. "Agil Kravprioritering : En kvalitativ studie om prioriteringsprocesser inom agil mjukvaruutveckling hos Monitor ERP System AB." Thesis, Högskolan i Gävle, Datavetenskap, 2021. http://urn.kb.se/resolve?urn=urn:nbn:se:hig:diva-36402.

Full text

Abstract:

Kravprioritering är ett av de viktigaste och mest inflytelserika stegen vid tillverkning av en mjukvaruprodukt. Processen är iterativ; den sker under hela produktens agila mjukvaruutvecklingsprocess. Genom kravprioritering beslutas det om vilka krav som ska utvecklas, i vilken ordning och varför. Målet med denna studie är att undersöka hur mjukvaruutvecklande företag gör för att kravprioritera, samt identifiera vilka prioriteringsmetoder de eventuellt använder sig av. Studiens syfte är att få en förståelse för varför en väl avvägd prioritering är viktig, vilka särskilda prioriteringsfaktorer som ger värde till en produkt och att se hur dessa faktorer är relaterade till resultatet. Syftet är även att undersöka vilka svårigheter som finns i en prioriteringsprocess, samt att skapa en översikt över några av de mest vedertagna prioriteringsmetoderna inom agil mjukvaruutveckling. Studien utförs i samarbete med mjukvaruföretaget Monitor ERP för att analysera företagets prioriteringsprocesser som används för att utveckla deras affärssystem Monitor. Metoden som används är en kvalitativ undersökning som består av observationer av möten kring prioriteringsarbete och semi-strukturerade intervjuer. Bearbetning av insamlat material skedde genom att organisera, analysera och sammanställa resultat enligt begrepp och kategorier som framkom utifrån litteraturstudien. Resultatet redovisar arbetsprocesser, gemensamma mål, prioriteringsaspekter och utmaningar i prioriteringsarbetet hos Monitor ERP. En väl avvägd prioritering visade sig vara viktigt för att kunna leverera rätt funktionalitet i tid, för att kunna ge trovärdiga estimeringar om utvecklingen och det i sin tur leder till att kunder får förtroende för både produkten och företaget. En rad olika prioriteringsfaktorer som ger värde till programvaran Monitor identifierades, varav många bidrar till att öka kundnöjdheten och kvaliteten på produkten. Monitor ERP använder inte några särskilda prioriteringsmetoder, utan utvecklingsfilosofin Minimum Viable Product används som grund till deras prioriteringsval. Under prioriteringsarbetet upplevdes utmaningar såsom begränsade resurser, oförutsägbara uppgifter, svårigheter med tidsestimering och en utmaning i balansen mellan kundnytta och kundfokus.
Prioritizing requirements is one of the most important and influential steps in the creation of a software product. The process is iterative; it takes place during the entire agile software development. Through prioritizing requirements, it is decided which requirements are to be developed, in which order, and why. The aim of this study is to investigate how companies that design software prioritize requirements and to identify which prioritization methods they might use during this process. The purpose of this study is to gain an understanding for why a well-balanced prioritization is important, which specific prioritization factors give value to a product, as well as identifying how these factors are related to the result. The purpose is also to investigate the difficulties that exist in a prioritization process, and to create an overview of some of the most used prioritization methods in agile software development. This study is conducted in collaboration with the software company Monitor ERP in order to analyze the company's prioritization processes used to develop their business management system Monitor. The method used is a qualitative study that consists of observations of meetings about prioritization processes, and semi-structured interviews. Processing of collected material was done by organizing, analyzing, and compiling results according to concepts and categories that emerged from the literature study. The results documents work processes, common goals, prioritization aspects and challenges in the requirements prioritization at Monitor ERP. A well-balanced prioritization proved to be important to be able to deliver the right functionality on time and to be able to provide dependable estimates of development, which in turn leads to customers gaining confidence in both the product and the company. A number of prioritization factors that give value to the Monitor software were identified, many of which contribute to increasing customer satisfaction and product quality. Monitor ERP does not use any specific prioritization methods, but the development philosophy Minimum Viable Product is used as a basis for their prioritization choices. During the prioritization process, challenges such as limited resources, unpredictable tasks, difficulties with time estimation, and a challenge in balancing customer value and customer focus were experienced.

APA, Harvard, Vancouver, ISO, and other styles

30

Abu, Baker Mohamed. "Agile Prototyping : A combination of different approaches into one main process." Thesis, Linköping University, PELAB - Programming Environment Laboratory, 2009. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-56463.

Full text

Abstract:

Software prototyping is considered to be one of the most important tools that are used by software engineersnowadays to be able to understand the customer’s requirements, and develop software products that are efficient,reliable, and acceptable economically. Software engineers can choose any of the available prototyping approaches tobe used, based on the software that they intend to develop and how fast they would like to go during the softwaredevelopment. But generally speaking all prototyping approaches are aimed to help the engineers to understand thecustomer’s true needs, examine different software solutions and quality aspect, verification activities…etc, that mightaffect the quality of the software underdevelopment, as well as avoiding any potential development risks.A combination of several prototyping approaches, and brainstorming techniques which have fulfilled the aim of theknowledge extraction approach, have resulted in developing a prototyping approach that the engineers will use todevelop one and only one throwaway prototype to extract more knowledge than expected, in order to improve thequality of the software underdevelopment by spending more time studying it from different points of view.The knowledge extraction approach, then, was applied to the developed prototyping approach in which thedeveloped model was treated as software prototype, in order to gain more knowledge out of it. This activity hasresulted in several points of view, and improvements that were implemented to the developed model and as a resultAgile Prototyping AP, was developed. AP integrated more development approaches to the first developedprototyping model, such as: agile, documentation, software configuration management, and fractional factorialdesign, in which the main aim of developing one, and only one prototype, to help the engineers gaining moreknowledge, and reducing effort, time, and cost of development was accomplished but still developing softwareproducts with satisfying quality is done by developing an evolutionary prototyping and building throwawayprototypes on top of it.

APA, Harvard, Vancouver, ISO, and other styles

31

Ittner, Jan. "Software assisted tailoring of process descriptions." Saarbrücken VDM Verlag Dr. Müller, 2006. http://d-nb.info/987892932/04.

Full text

APA, Harvard, Vancouver, ISO, and other styles

32

Andrén, Samuel. "Categorizing and managing difficulties in interorganizational requirements engineering." Thesis, KTH, Industriell ekonomi och organisation (Inst.), 2020. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-273975.

Full text

Abstract:

As globalisation is now a reality for most large organizations, and the competition for most businesses moving faster and becoming tougher, there is a need for engineering projects to deliver results faster in a more complex environment than ever, but also for companies to collaborate to utilize a wider array of competencies and to reach new markets with their products. This case study analyses which difficulties arise in interorganizational requirements engineering, and what organizations can do to alleviate the effects of those difficulties, as well as suggest which actions are most effective to focus on. The conclusion of this study is that the difficulties can be divided into three categories, namely interpersonal, structural and processual. Each category concerns a different set of people and require different actions for increased effectiveness. For the interpersonal category, prioritized efforts should be to establish a shared vocabulary and use techniques to build shared contextual understanding. For structural difficulties, evaluating management and control structures and the implementation of the project’s strategy should be prioritized. In the processual category, codifying existing processes to enable improvements, defining information artefacts and aligning information flows should be of high priority
Globaliseringens effekter är idag en verklighet för de flesta stora organisationer, och konkurrensen för företag blir hårdare och förändrar sig allt snabbare. Därför blir det allt viktigare för utvecklingsprojekt att anpassa sig till en allt mer komplex miljö och leverera resultat snabbare än tidigare, men också att samarbeta mer med andra företag för att såväl utnyttja bredare kompetens som att nå nya marknader. Den här studien undersöker utmaningarna i interorganisatoriskt kravställningsarbete, vad företag kan göra för att möta de utmaningarna, såväl som att föreslå vilka handlingar som ger mest effekt för ett bättre kravställningsarbete. Slutsatsen av studien är att utmaningarna kan delas in i tre kategorier, nämligen personorienterade, strukturella och processorienterade. Varje kategori rör en viss mängd deltagare i projektet och kräver olika handlingar för ökad effektivitet. För att minska utmaningar i den personorienterade kategorin bör ett projekt prioritera att använda tekniker för att skapa ett gemensamt språkbruk och att använda tekniker för att bygga upp gemensam kontextuell förståelse. För strukturella utmaningar bör det prioriteras att utvärdera styrnings- och kontrollstrukturer, samt hur projektets strategi har implementerats och förankrats bland deltagarna. I den processorienterade kategorin bör det prioriteras att kodifiera existerande processer för att möjliggöra förbättringsarbete, definiera informationsartefakter och att försäkra sig om att informationsflöden är i linje med varandra mellan företagen, så att rätt information möts vid rätt tillfällen.

APA, Harvard, Vancouver, ISO, and other styles

33

Khan, Hassan Mahmood, and Ibrar Arshad. "Test-lists Utilization in Test Driven Development : The Role of test-lists in Requirements Traceability." Thesis, Blekinge Tekniska Högskola, Sektionen för datavetenskap och kommunikation, 2012. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-4782.

Full text

Abstract:

Context: In recent times, many organizations have started using agile software development methodologies instead of using traditional methodologies. The main reason for this shift is the ability of agile approaches to cope with changes in the requirements, customer satisfaction and assurance of on-time delivery of quality products [19]. Test-Driven Development (TDD) is a software development methodology that is considered to be one of the most prominent practices of eXtreme Programming (XP) (an agile methodology) [1][9][10]. Test-list in TDD is considered as a temporary repository in which test items are stored and later by using those items test cases are developed. Requirements Traceability is also a major problem in agile development mainly because of lack of formal requirements specification and frequent requirements change. Objectives: This study explores the utilization of test-list and possibility of using test-list for requirements traceability in TDD. This study describes concept of test-list, its formation and exploring its utilization in TDD. Methods for implementing requirements traceability in and identification of possibility of utilizing test-list for requirements traceability in TDD is also explored. Methods: Methods used in this study are systematic literature review, surveys and interviews. Systematic literature review was done using seven electronic databases, including Inspec, IEEE Xplore, ACM Digital Library, Springer, Science Direct and Scopus. Studies were selected on the bases of preliminary, basic and advanced developed criteria. Survey was conducted using online questionnaire from TDD practitioners. Findings from literature review and surveys were used to develop interview questionnaires. Interviews were conducted from the same practitioners that were involved in surveys. Results: Based on the findings of literature review, questionnaire and interviews, we obtained TDD practices for test-list development and requirements traceability. Analysis was performed on results of SLR and questionnaire and possibility of using test-list for requirements traceability was identified. Based on the analysis of literature review and surveys, interview questionnaire were developed to further investigate the area of interest. We have found that in literature there is no defined method to develop test-list. and survey participants also confirms it. Majority of survey participants create test-list temporarily and informal. On question of whether test-list can be use for requirements traceability around 70% of participants are agree for its use. Interview respondents also confirm the findings of survey. Conclusions: Literature has not provided any test-list development method and practitioners also have no clear guideline to develop test-list prior to Test development. Systematic literature review and practitioner’s survey and interviews confirm it. Literature is also silent for any specific requirements change management or requirements traceability method in TDD. We identified requirements traceability practices in agile and management through literature and survey. After analysis of gathered data we found TDD lacks in test-list formalization, none of the study focuses on requirements traceability in TDD. In this study our contribution is exploration of test-list creation and utilization through literature and state of the practice; after practitioners feedback we also explored that test-list can be used for requirements traceability.
hasmkh@gmail.com, ibrararshad@gmail.com

APA, Harvard, Vancouver, ISO, and other styles

34

Hamed, Amirzadeh, and Khalaf Beigi Reza. "Agil Systemutveckling : En studie av kravhantering och beställarroll i agila angreppsätt." Thesis, Högskolan Väst, Institutionen för ekonomi och it, 2013. http://urn.kb.se/resolve?urn=urn:nbn:se:hv:diva-5510.

Full text

Abstract:

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. Requirements change during IT projects and to manage requirements, agile principles apply. Specification and planning in the waterfall model is time consuming. Working agile means to have close contact with the client. This minimizes the risk of project failure. With agile methods, functions can be developed at a faster rate and the customer receives prompt delivery. There are currently several different methods for systems development and project management. Some are based on research, others are new and some have been around a long time in the IT world. This work has identified customer involvement; Risk Reduction and Delivery which contribute to several projects fail under traditional systems. Agile methods are flexible, agile and welcome change and the customer will be able to steer the project. Agile methods have however provided the opportunity for developers to more quickly deliver functionality to the customer.
Detta arbete är ett examensarbete på C-nivå, 15 poäng vid Högskolan Väst, Institutionen för ekonomi och IT avd. informatik. Denna studie handlar om agila metodiken och dess inverkan på IT-projekt. Kravhantering är en process inom ett IT-projekt, där kund har vissa krav som måste uppfyllas av ett IT-system. Skillnaden mellan det traditionella och agila utvecklingsmetoder ligger i kravhantering process och det kan orsaka problem i ett projekt. Krav förändras under IT-projekt och för att hantera kraven bör agila principer tillämpas. Kravspecifikation och planering inom vattenfallsmodellen är tidskrävande. Att jobba agilt innebär att ha nära kontakt med beställaren. Därmed minimerar det risken för projektets misslyckande. Med agila metoder, kan funktionerna utvecklas i en snabbare takt och kunden får snabb leverans. Det finns idag flera olika metoder för systemutveckling och projektledning. Vissa är baserade på forskning, andra är nya och vissa har funnits en lång tid i IT-världen. Arbetet har identifierat kundinvolvering, Riskreducering och Leveranstid vilka bidra till att flera projekt misslyckas under traditionell systemutveckling. Agila metoder är flexibla, smidiga och välkomnar förändring och kunden kommer att kunna styra projektet. Agila metoder har däremot gett möjlighet för utvecklarna att på ett snabbare sätt leverera funktioner till kunden.

APA, Harvard, Vancouver, ISO, and other styles

35

Matheson, Dan McKay [Verfasser]. "SAMEM: A Methodology for the Elicitation and Specification of Requirements for Agile Model-driven Engineering of Large Software Solutions / Dan McKay Matheson." Aachen : Shaker, 2019. http://d-nb.info/1188552244/34.

Full text

APA, Harvard, Vancouver, ISO, and other styles

36

Gomez, Arturo, and Gema Rueda. "DIM : A systematic and lightweight method for identifying dependencies between requirements." Thesis, Blekinge Tekniska Högskola, Sektionen för datavetenskap och kommunikation, 2010. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-3280.

Full text

Abstract:

Dependencies between requirements are a crucial factor for any software development since they impact many project areas. Nevertheless, their identification remains a challenge. Some methods have been proposed but none of them are really applicable to real projects due to their high cost or low accuracy. DIM is a lightweight method for identifying dependencies proposed on a previous paper. This paper presents an experiment comparing the sets of dependencies found by DIM and a method based on pair-wise comparison. The experiment was executed using a requirement specification for an open source project. These requirements were extracted by reverse engineering. Our results have provided evidence confirming that DIM finds more dependencies and its results (the dependencies identified) do not depend on the profile of the practitioner applying it. Another important result is that DIM requires fewer resources when applied, since it does not rely on pair-wise comparisons and it can be easily automated.
Avda. Espana 101 P6 Bj-E 28341, Madrid, Spain. Telephone number: +34627770492

APA, Harvard, Vancouver, ISO, and other styles

37

Cintra, Caroline Carbonell. "A implementação de um processo de engenharia de requisitos baseado no Processo Unificado da Rational (RUP) alcançando nível 3 de Maturidade da Integração de Modelos de Capacidade e Maturidade (CMMI) incluindo a utilização de práticas de métodos ágeis." reponame:Biblioteca Digital de Teses e Dissertações da UFRGS, 2006. http://hdl.handle.net/10183/8128.

Full text

Abstract:

Este trabalho descreve a definição e institucionalização de um processo de engenharia de requisitos que está em conformidade com as áreas de processo do CMMI (Capability Maturity Model) de Gerência de Requisitos e Desenvolvimento de Requisitos e cujos componentes (atividades, papéis, produtos de trabalho) são baseados em RUP (Rational Unified Process). A principal contribuição deste estudo é a definição de um processo de engenharia de requisitos baseado em abordagens de desenvolvimento diferenciadas, que foi implantado em uma organização específica, com foco em praticidade, eficiência e retorno do investimento. A implantação do processo em projetos reais permitiu sua experimentação, avaliação e refinamento, validando as alternativas de integração utilizadas para empregar as abordagens de desenvolvimento escolhidas. Complementando o processo proposto, como decorrência do foco em eficiência, são consideradas possibilidades de emprego de práticas de métodos ágeis na execução do processo, com o intuito de aumentar a produtividade do mesmo, sustentando sua garantia de qualidade. O processo proposto é descrito, do método de concepção aos passos envolvidos e artefatos gerados em cada atividade. Também são comentadas as etapas e áreas de trabalho envolvidas na institucionalização do trabalho.
This research depicts the definition and institutionalization of a requirements engineering process which is in conformance to CMMI (Capability Maturity Model) Requirements Management and Requirements Development process areas. The proposed process components (activities, roles, work products) are based on Rational Unified Process (RUP) process framework. The proposed process main contribution is the definition of a requirements engineering process, leveraging such diverse development approaches, which was implemented in a specific organization, focusing on practicality, efficiency and return on investment. Implementing such process in real projects has promoted its experimentation, evaluation and refinement, validating the integration alternatives used to bring together the chosen development approaches. The possibility of employing agile methods practices through the process execution is discussed, aiming at increasing the process productivity, while assuring product quality. The proposed process details are described, from method conception to each activity steps and generated artifacts. The process institutionalization phases and work areas are also commented.

APA, Harvard, Vancouver, ISO, and other styles

38

Lebeaupin, Benoit. "Vers un langage de haut niveau pour une ingénierie des exigences agile dans le domaine des systèmes embarqués avioniques." Thesis, Université Paris-Saclay (ComUE), 2017. http://www.theses.fr/2017SACLC078/document.

Full text

Abstract:

La complexité des systèmes conçus actuellement devient de plus en plus importante. En effet,afin de rester compétitives, les entreprises concevant des systèmes cherchent à leur rajouter de plus en plusde fonctionnalités. Cette compétitivité introduit aussi une demande de réactivité lors de la conception desystèmes, pour que le système puisse évoluer lors de sa conception et suivre les demandes du marché.Un des éléments identifiés comme empêchant ou diminuant cette capacité à concevoir de manière flexibledes systèmes complexes concerne les spécifications des systèmes, et en particulier l’utilisation de la languenaturelle pour spécifier les systèmes. Tout d’abord, la langue naturelle est intrinsèquement ambiguë et celarisque donc de créer des non-conformités si client et fournisseur d’un système ne sont pas d’accord sur lesens de sa spécification. De plus, la langue naturelle est difficile à traiter automatiquement, par exemple, onpeut difficilement déterminer avec un programme informatique que deux exigences en langue naturelle secontredisent. Cependant, la langue naturelle reste indispensable dans les spécifications que nous étudions,car elle reste un moyen de communication pratique et très répandu.Nous cherchons à compléter ces exigences en langue naturelle avec des éléments permettant à la fois de lesrendre moins ambiguës et de faciliter les traitements automatiques. Ces éléments peuvent faire partie demodèles (d’architecture par exemple) et permettent de définir le lexique et la syntaxe utilisés dans lesexigences. Nous avons testé les principes proposés sur des spécifications industrielles réelles et développéun prototype logiciel permettant de réaliser des tests sur une spécification dotée de ces éléments de syntaxeet de lexique
Systems are becoming more and more complex, because to stay competitive, companies whichdesign systems search to add more and more functionalities to them. Additionally, this competition impliesthat the design of systems needs to be reactive, so that the system is able to evolve during its conception andfollow the needs of the market.This capacity to design flexibly complex systems is hindered or even prevented by various variouselements, with one of them being the system specifications. In particular, the use of natural language tospecify systems have several drawbacks. First, natural language is inherently ambiguous and this can leadsto non-conformity if customer and supplier of a system disagree on the meaning of its specification.Additionally, natural language is hard to process automatically : for example, it is hard to determine, usingonly a computer program, that two natural language requirements contradict each other. However, naturallanguage is currently unavoidable in the specifications we studied, because it remains very practical, and itis the most common way to communicate.We aim to complete these natural language requirements with elements which allow to make them lessambiguous and facilitate automatic processing. These elements can be parts of models (architectural modelsfor example) and allow to define the vocabulary and the syntax of the requirements. We experimented theproposed principles on real industrial specifications and we developped a software prototype allowing totest a specification enhanced with these vocabulary and syntax elements

APA, Harvard, Vancouver, ISO, and other styles

39

ALVES, Daniela de Castro Pereira. "Engenharia de requisitos em projetos ágeis: um mapeamento sistemático baseado em evidências da indústria." Universidade Federal de Pernambuco, 2015. https://repositorio.ufpe.br/handle/123456789/17233.

Full text

Abstract:

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-07-01T11:40:55Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) dissertacao biblioteca revisado.pdf: 2828757 bytes, checksum: 94e8f0f95ebbe83536b00d9b18b31d8c (MD5)
Made available in DSpace on 2016-07-01T11:40:55Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) dissertacao biblioteca revisado.pdf: 2828757 bytes, checksum: 94e8f0f95ebbe83536b00d9b18b31d8c (MD5) Previous issue date: 2015-08-19
Nos últimos anos, percebe-se um interesse crescente na utilização de metodologias ágeis como estratégia para minimizar os problemas no desenvolvimento de software. Apesar disso, pouco ainda se sabe sobre como a engenharia de requisitos está sendo conduzida em conjunto com essas metodologias. Neste contexto, o objetivo desta pesquisa é investigar como a engenharia de requisitos e as metodologias ágeis vêm sendo utilizadas conjuntamente na prática em projetos de desenvolvimento de software aplicados na indústria. Para isso, foi realizado um mapeamento sistemático da literatura que encontrou 24 estudos primários relevantes, cujos dados foram extraídos e sintetizados. Esse mapeamento identificou as técnicas e processos de engenharia de requisitos que estão sendo mais utilizados no contexto de desenvolvimento ágil e quais os principais problemas e limitações encontradas. Após a execução do mapeamento, verificou-se que a falta de envolvimento do usuário associada às características das atuais técnicas utilizadas para especificar requisitos e suas constantes mudanças são os principais desafios a serem superados.
In recent years, we can see a growing interest in using agile methodologies as a strategy to minimize the problems in software development. Nevertheless, little is known as requirements engineering is being conducted in conjunction with these methodologies. In this context, the objective of this research is to investigate how the requirements engineering and agile methodologies have been used jointly in practice in software development projects applied in the industry. For this, it was conducted a systematic literature mapping that found 24 relevant primary studies, whose data were extracted and synthesized. This mapping identified the most used techniques and process of requirements engineering and what are the main problems and limitations encountered in the context of agile development. After the execution of the mapping, it was found that lack of user involvement associated with the characteristics of current techniques used to specify requirements and their constant changes are the main challenges to overcome.

APA, Harvard, Vancouver, ISO, and other styles

40

Louis, Harriet. "Towards agile requirement engineering." Thesis, Stellenbosch : Stellenbosch University, 2015. http://hdl.handle.net/10019.1/97337.

Full text

Abstract:

Thesis (MBA)--Stellenbosch University, 2015.
ENGLISH ABSTRACT: Software development is a relatively young science and involves certain tools, techniques, documentation aids and processes that are applied to deliver a software project. As hardware, software and business needs advanced, so did the processes used in managing software development. It is a dynamic and complex process and each development environment or project has its own unique characteristics. For this reason the methodologies followed during the development process is very often debated. Software development teams have a wide array of methodologies to choose from. The development team usually decides what the key success factors are to deliver a software product, and then examines each one within the framework of a list of potential methodologies. This way the team can compare which methodology would best suit their needs. Factors used to evaluate which methodology to follow, includes the size of the project team, rate of expected changes, the primary goal of the project, how requirements will be managed, communication structures that will be followed, the nature of the relationship with the customer, and the organisational culture in the customer organisation. This research report takes a comparative look at Waterfall methods versus Agile methods.

APA, Harvard, Vancouver, ISO, and other styles

41

Sheikh, Bilal Tahir. "Interdisciplinary Requirement Engineering for Hardware and Software Development - A Software Development Perspective." Thesis, Linköpings universitet, Institutionen för datavetenskap, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-147886.

Full text

Abstract:

The software and hardware industries are growing day by day, which makes their development environments more complex. This situation has a huge impact on the companies which have interdisciplinary development environments. To handle this situation, a common platform is required which can be acted as a bridge between hardware and software development to ease their tasks in an organized way. The research questions of the thesis aim to get information about differences and similarities in requirements handling, and their integration in current and future prospectives. The future prospect of integration is considered as a focused area. Interviews were conducted to get feedback from four different companies having complex development environments.

APA, Harvard, Vancouver, ISO, and other styles

42

Čížek, Pavel. "Sociální aspekty agilních metodik vývoje softwaru." Master's thesis, Vysoká škola ekonomická v Praze, 2008. http://www.nusl.cz/ntk/nusl-10500.

Full text

Abstract:

Traditional methodologies of software development are burdened with number of problems, especially its complexity, bureaucracy and sticking on detailed processes defined in advance. This all often mean overtiming and overpricing the project as well as other negative effects. Agile methodologies of software development pursue solving such problems. They are built on principles of team-work, communication and developers' relations and sharing their knowledge. These values are one of the most important in agile development concept. This thesis's target is to identify and describe those principles of agile software development which impact development team functioning, working motivation of developers and focus on the project goals. Reader is first shortly familiarized with general theory of working motivation, team-working and leading to achieve the target. Then particular agile development principles are analyzed and the impact on developers' motivation, whole team functioning and focusing on the project goals is described. Another target of the thesis is to identify requirements on agile software developers, to explain what the need of them lies in and how the absence of these personal characteristics would impact whole team's productivity and the development progress. The last target of this thesis is to examine agile development as a whole. A SWOT analysis is used to achieve this. It states the strengths, weaknesses, opportunities (advantages) and risks of agile development. There is a list of 11 serious mistakes that can take place in the agile development process and heighten the risk of the project fail stated at the end of the thesis.

APA, Harvard, Vancouver, ISO, and other styles

43

Broinizi, Marcos Eduardo Bolelli. "Validação ágil e precisa de projetos conceituais de banco de dados." Universidade de São Paulo, 2006. http://www.teses.usp.br/teses/disponiveis/45/45134/tde-01062007-161947/.

Full text

Abstract:

A criação do projeto conceitual de um bancos de dados que represente adequadamente um determinado domínio de aplicação continua sendo um dos principais desafios da área de banco de dados. Por outro lado, a discussão sobre métodos ágeis de desenvolvimento de software alcançou, recentemente, a comunidade de banco de dados. Este trabalho apresenta o projeto conceitual de bancos de dados sob a luz de métodos ágeis de desenvolvimento. Desenvolvemos uma extensão do arcabouço Naked Objects que permite uma validação ágil e precisa do projeto conceitual junto ao especialista do domínio. Em nossa abordagem, o projeto conceitual de bancos de dados é descrito por meio de anotações que representam as abstrações de dados em um ambiente dinâmico de validação.
Creating a conceptual database design that adequately represents a specific application domain continues to be one of the main challenges in the database research. On the other hand, the discussion regarding agile methods of software development has recently become a subject of interest to the database community. This work presents a new approach to create a conceptual database design according to agile methods. We have created an extension of the Naked Objects framework that allows an agile and precise validation of the conceptual database design by the domain specialist. In our approach, the conceptual database design is described through annotations that represent data abstractions in a dynamic validation environment.

APA, Harvard, Vancouver, ISO, and other styles

44

Jaqueira, Aline de Oliveira Prata. "Uso de modelos i* para enriquecer requisitos em m?todos ?geis." Universidade Federal do Rio Grande do Norte, 2013. http://repositorio.ufrn.br:8080/jspui/handle/123456789/18077.

Full text

Abstract:

Made available in DSpace on 2014-12-17T15:48:06Z (GMT). No. of bitstreams: 1 AlineOPJ_DISSERT.pdf: 1977050 bytes, checksum: f61ea891da8fcdd8f7fc75d704edb944 (MD5) Previous issue date: 2013-03-01
The activity of requirements engineering is seen in agile methods as bureaucratic activity making the process less agile. However, the lack of documentation in agile development environment is identified as one of the main challenges of the methodology. Thus, it is observed that there is a contradiction between what agile methodology claims and the result, which occurs in the real environment. For example, in agile methods the user stories are widely used to describe requirements. However, this way of describing requirements is still not enough, because the user stories is an artifact too narrow to represent and detail the requirements. The activities of verifying issues like software context and dependencies between stories are also limited with the use of only this artifact. In the context of requirements engineering there are goal oriented approaches that bring benefits to the requirements documentation, including, completeness of requirements, analysis of alternatives and support to the rationalization of requirements. Among these approaches, it excels the i * modeling technique that provides a graphical view of the actors involved in the system and their dependencies. This work is in the context of proposing an additional resource that aims to reduce this lack of existing documentation in agile methods. Therefore, the objective of this work is to provide a graphical view of the software requirements and their relationships through i * models, thus enriching the requirements in agile methods. In order to do so, we propose a set of heuristics to perform the mapping of the requirements presented as user stories in i * models. These models can be used as a form of documentation in agile environment, because by mapping to i * models, the requirements will be viewed more broadly and with their proper relationships according to the business environment that they will meet
A atividade de engenharia de requisitos ? vista nos m?todos ?geis como atividade burocr?tica tornando o processo menos ?gil. No entanto, a falta de documenta??o no ambiente de desenvolvimento ?gil ? apontada como um dos principais desafios da metodologia. Assim, observa-se a exist?ncia de um contrassenso entre o que a metodologia ?gil defende e o resultado que ocorre no ambiente real. Por exemplo, nos m?todos ?geis as hist?rias de usu?rio s?o a forma mais usual para descrever requisitos. No entanto, essa maneira de descrever requisitos ainda n?o ? suficiente, pois as hist?rias de usu?rio constituem um artefato muito restrito para representar e detalhar os requisitos. As atividades de verificar quest?es como o contexto do software e depend?ncias entre as hist?rias tamb?m s?o limitadas com o uso somente desse artefato. No contexto de engenharia de requisitos existem as abordagens orientadas a metas que trazem vantagens para a documenta??o de requisitos, entre elas, completude dos requisitos, an?lise de alternativas e suporte ? racionaliza??o de requisitos. Dentre essas abordagens destaca-se a t?cnica de modelagem i* que fornece uma vis?o gr?fica dos atores envolvidos no sistema e suas depend?ncias. Esta disserta??o prop?e um recurso complementar para diminuir essa car?ncia de documenta??o existente nos m?todos ?geis. Assim, o objetivo deste trabalho ? fornecer uma vis?o gr?fica dos requisitos do software e seus relacionamentos atrav?s de modelos i*, enriquecendo assim os requisitos nos m?todos ?geis. Para isso prop?e-se um conjunto de heur?sticas para realizar o mapeamento dos requisitos representados como hist?rias de usu?rio em modelos i*. Esses modelos poder?o ser utilizados como uma forma de documenta??o dos requisitos no ambiente ?gil, pois atrav?s do mapeamento para os modelos i*, os requisitos ser?o visualizados de maneira mais abrangente e com seus devidos relacionamentos de acordo com o ambiente de neg?cio que v?o atender

APA, Harvard, Vancouver, ISO, and other styles

45

Nyström, Matilda. "En jämförande studie mellan agila modellen och vattenfallsmodellen : Skillnaden mellan kraven i de båda modellerna." Thesis, Mittuniversitetet, Institutionen för informationssystem och –teknologi, 2021. http://urn.kb.se/resolve?urn=urn:nbn:se:miun:diva-40893.

Full text

Abstract:

Studien består av en jämförelse av det traditionella arbetssättet,vattenfallsmodellen, och den agila modellen. Studiens fokus ligger påatt undersöka skillnaderna som finns mellan modellerna när detkommer till kravhanteringen och hur man arbetar med att uppfyllakraven. Fokus ligger också på att undersöka varför vissa projektföredrar att arbeta efter vattenfallsmodellen, istället för att använda denagila modellen.Undersökningen består av en litteraturförstudie och semistruktureradeintervjuer med personer som har erfarenhet av båda modellerna.Resultatet av de semistrukturerade intervjuerna sammanställs ochjämförs med resultatet från undersökningen, detta för att kunna besvarafrågeställningarna.Resultatet visar att de skiljer sig markant i kravhanteringen och hur manarbetar med att uppfylla kraven i det olika modellerna.Detta bidrar till att det skiljer sig mycket vilken modell som föredras.Ett exempel som kom fram under intervjuerna är att inom vissa delar avmedicinbranschen så krävs det ett omfattade förarbete då det är olikalagar i olika länder.Det visa sig att statliga och privata verksamheter inte spelar in i valet avmodell utan att det som avgör vilken modell som föredras är vilken typav projekt. Vilken typ av miljö som projektet utförs i spelar också en storroll.Vattenfallsmodellen föredras i projekt som styrs av lagar och regelverkeller om det är väldigt specifika krav. Agila modellen föredras då det ärfriare projekt där lagar och regler inte måste tas i hänsyn på samma sätt.
The study consists of a comparison on the traditional way of working,the waterfall model, and the agile model. The focus of the study is toexamine the differences that exist between the models when it comes torequirements management and how to work to meet the requirements.The focus will also be on examine why some projects prefer to workaccording to the waterfall model, instead of switching to the agilemodel.The survey consists of a literature pre-study and semi-structuredinterviews with people who have experience of both models. The resultsthat where collected from the semi-structured interviews have beencompiled and compared whit the results which were collected from thesurvey in order to be able to answer the questions.The results show that they differ markedly in the requirementsmanagement and how to work with meeting the requirements in thedifferent models. This contributes to the fact that there is a lot ofdifference in which model that is preferred. An example that emergedduring the interviews was that in certain parts of the medical industry,extensive preparatory work is required as there are different laws indifferent countries.It turned out that government and private activities do not play a role inthe choice of model, but that what determines which model is preferredis the type of project. The type of environment in which the projectconsists also plays a major role.The waterfall model will be preferred in projects governed by laws andregulations or if there are very specific requirements. The agile model ispreferred when the projects is freer and where laws and regulations donot have to be taken into account in the same way.

APA, Harvard, Vancouver, ISO, and other styles

46

Hussain, Dostdar, and Muhammad Ismail. "Requirement Engineering : A comparision between Traditional requirement elicitation techniqes with user story." Thesis, Linköpings universitet, Institutionen för datavetenskap, 2011. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-70174.

Full text

Abstract:

Requirements are features or attributes which we discover at the initial stage of building a product. Requirements describe the system functionality that satisfies customer needs. An incomplete and inconsistent requirement of the project leads to exceeding cost or devastating the project. So there should be a process for obtaining sufficient, accurate and refining requirements such a process is known as requirement elicitation. Software requirement elicitation process is regarded as one of the most important parts of software development. During this stage it is decided precisely what should be built. There are many requirements elicitation techniques however selecting the appropriate technique according to the nature of the project is important for the successful development of the project. Traditional software development and agile approaches to requirements elicitation are suitable in their own context. With agile approaches a high-level, low formal form of requirement specification is produced and the team is fully prepared to respond unavoidable changes in these requirements. On the other hand in traditional approach project could be done more satisfactory with a plan driven well documented specification. Agile processes introduced their most broadly applicable technique with user stories to express the requirements of the project. A user story is a simple and short written description of desired functionality from the perspective of user or owner. User stories play an effective role on all time constrained projects and a good way to introducing a bit of agility to the projects. Personas can be used to fill the gap of user stories.

APA, Harvard, Vancouver, ISO, and other styles

47

Hedlund, Johan, and Joel Lundberg. "Intressentanalys & kravhantering inom agil metod : med stöd av soft systems methodology." Thesis, Luleå tekniska universitet, Digitala tjänster och system, 2020. http://urn.kb.se/resolve?urn=urn:nbn:se:ltu:diva-79556.

Full text

Abstract:

This study explores stakeholder analysis and requirements engineering within an agile project at a system development company requesting a case management system. Stakeholder analysis is commonly explored in traditional project planning studies, such as the waterfall model. In agile projects, on the other hand, it is not common to have a project-planning phase or to carry out a stakeholder analysis, often due to that a stakeholder analysis entail a long and extensive documentation. Our study explores how Soft Systems Methodology can be used in an agile project-planning phase as well as how rich pictures from the SSM support requirements engineering. The study is based on an agile method in which the project-planning phase is expected to deliver a product log, and hence a requirements list. Requirements are collected, modelled and validated together with users in the form of user stories where role, goals and purpose are expressed in a sentence. Stakeholders and roles are identified and analyzed using methods in Soft Systems Methodology, like "finding-out" analyses. The result is then presented in so called rich pictures of the current situation and in a future desired situation. The data collection is carried out together with informants at the case company in the form of observations and semi-structured interviews. The result of the study indicates how rich pictures from SSM can support the start-up of an agile project.
Denna studie utforskar intressentanalys och kravinsamling inom ett agilt projekt på ett systemutvecklingsföretag som efterfrågar ett ärendehanteringssystem. Intressentanalyser är vanligt förekommande och utforskade i traditionella förstudier så som enligt vattenfallsmodellen. I agila projekt är det däremot vanligt att en förstudie inte utförs eller att förstudien inte innehåller en intressentanalys, ofta på grund av att intressentanalyser innebär lång och omfattande dokumentation. Vår studie utforskar hur Soft Systems Methodology kan användas i en agil förstudie samt hur rika bilder från SSM stöttar kravhantering. Studien utgår från an agil metod där förstudien förväntas leverera en produktlogg, där studiens fysiska bidrag blir en kravlista. Krav samlas in, modelleras samt valideras tillsammans med användare i formen av användarhistorier där roll, mål och syfte uttrycks i en mening. Intressenter och roller identifieras och analyseras med hjälp av metoder inom Soft Systems Methodology, som exempelvis ”finding out”-analys. Resultatet presenteras därefter i så kallade rika bilder över nuvarande situation samt i en framtida önskad situation. Datainsamlingen görs tillsammans med informanter på ett fallföretag i form av observationer och semistrukturerade intervjuer. Utfallet av studien visar hur den rika bilden från SSM kan stödja uppstarten av ett agilt projekt.

APA, Harvard, Vancouver, ISO, and other styles

48

Rzyman, Daniel. "Nástroj pro podporu neformální specifikace pro mobilní zařízení." Master's thesis, Vysoké učení technické v Brně. Fakulta informačních technologií, 2013. http://www.nusl.cz/ntk/nusl-236357.

Full text

Abstract:

This thesis aims to design an effective solution of supportive tool in field of the informal specification. Solution is based on the application for mobile devices with touch screens, Apple iPad. Design of the final product is supported by many studies, in particular those analyzing field of the informal specification, technical features, user interfaces, implementation methods and user experience testing. Thesis defines functional requirements for application development accompanied by design and the implementation of three different graphical user interfaces. Important in this thesis is the evaluation of the user experience testing, which defines future development.

APA, Harvard, Vancouver, ISO, and other styles

49

Chalfoun, Imad. "Conception et déploiement des Systèmes de Production Reconfigurables et Agiles (SPRA)." Thesis, Clermont-Ferrand 2, 2014. http://www.theses.fr/2014CLF22488/document.

Full text

Abstract:

L'industrie est aujourd'hui, comme elle a toujours été, une pierre angulaire de l'économie pour chaque pays développé. Avoir une base solide en entreprises industrielles est très important parce qu’elles poussent et stimulent tous les autres secteurs de l'économie, et offrent également une grande variété d'emplois qui apporte des bonnes conditions de vie dans de nombreux secteurs de la société. L’augmentation de la concurrence mondiale, l’évolution rapide du marché, la nécessité de créer des entreprises stables avec des usines rentables obligent la mise en oeuvre d’une démarche globale prenant en compte à la fois les aspects techniques, économiques, logistiques et sociétaux lors de la conception d’un système de production innovant. L’objectif de cette thèse est de contribuer au développement d’un concept innovant de Systèmes de Production Reconfigurables et Agiles (SPRA) permettant de s'adapter rapidement et efficacement aux exigences imposées du marché, des clients, de la technologie des procédés, de l’environnement et de la société afin que l’entreprise soit dynamique, compétitive et rentable. Dans ces travaux de thèse, la proposition d'un modèle générique et la caractérisation de ce nouveau type de système de production ont été décrits en utilisant le langage de modélisation des systèmes complexes (SysML : Systems Modeling Language). Ensuite, nous avons développé un processus de reconfiguration qui représente une démarche à suivre pour concevoir et implanter une nouvelle configuration. De plus, un pilotage opérationnel adapté au SPRA a été introduit. Enfin, quelques travaux développés au cours de cette thèse ont été partiellement déployés sur un démonstrateur industriel au sein de la plate-forme AIP-PRIMECA Auvergne
Industry is, today as it has always been, a cornerstone of the economy for any developed country. Having a strong manufacturing base is very important because it impels and stimulates all the other sectors of the economy. It provides a wide variety of job, which bring higher standards of living to many sectors of society, and builds a strong middle class. Increasing global competition, rapid changes in the marketplace and the need to create stable companies with profitable plants require the implementation of a global approach, taking into account technical, economic, logistic and societal aspects in the design of an innovative manufacturing system. The aim of this dissertation is to contribute to the development of an innovative concept of Reconfigurable and Agile Manufacturing Systems (RAMS) to adapt quickly and effectively to the requirements imposed by markets, customers, technology processes, the environment and society, to ensure that the enterprise is dynamic, competitive and profitable. In this thesis work, the characterization and proposal of a generic model for this new type of manufacturing system have been described using the language of complex systems modeling (SysML: Systems Modeling Language). We have developed a reconfiguration process that represents the approach to follow in the design and implementation of a new configuration. In addition, the operational control of a RAMS has been introduced. Finally, some works developed in this thesis have been partially deployed on an industrial demonstrator within the AIP-PRIMECA Auvergne organisation

APA, Harvard, Vancouver, ISO, and other styles

50

Sebega, Yanda. "Exploring issues in agile requirements engineering in the South African industry." Diss., 2017. http://hdl.handle.net/10500/26212.

Full text

Abstract:

The agile manifesto has certainly changed the way software is produced in the Information Communications Technology (ICT) industry. However, many persistent challenges cripple agile software development. One challenge is that the constant change in technology makes the requirements hard to implement. Another is that issues of the agile requirements engineering (ARE) process are abundant and pervasive throughout software projects. The aim of this study is to determine common issues in agile requirements engineering in the South African software industry and identify tools and frameworks to mitigate risks emanating from such problems. This includes finding out how much value software practitioners put in the agile principles. This study was essentially quantitative, based on a cross-sectional survey. Self-administered questionnaires were used to collect required data which was then subjected to exploratory data analysis using SPSS (Statistical Package for the Social Sciences), a tool for statistical analysis. The results show that software practitioners have a strong penchant for principles of the Agile Manifesto. Major issues in agile requirements engineering include lack of proper validation tools and techniques, scope problems, lack of proper documentation, issues of prioritisation, as well as unavailability of customer representative. A detailed baseline of issues in agile requirements engineering was created along with a set of recommended tools and techniques used in the software industry. As for the recommendation, it is suggested that companies invest more on validation tools and techniques and consider non-functional requirements integration during software development.
School of Computing
M. Sc. (Computing)

APA, Harvard, Vancouver, ISO, and other styles

Dissertations / Theses on the topic 'Agile Requirements'

Create a spot-on reference in APA, MLA, Chicago, Harvard, and other styles