See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/318436016

A Requirements Engineering Techniques Review in Agile Software Development

Methods

Conference Paper  in  Lecture Notes in Computer Science · July 2017

DOI: 10.1007/978-3-319-62404-4_50

CITATION READS
1 2,049

4 authors, including:

José Alfonso Aguilar Carolina Tripp-Barba

Universidad Autónoma de Sinaloa Universidad Autónoma de Sinaloa
42 PUBLICATIONS   153 CITATIONS    59 PUBLICATIONS   322 CITATIONS   

SEE PROFILE SEE PROFILE

Sanjay Misra
Covenant University Ota Ogun State, Nigeria
413 PUBLICATIONS   1,648 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Evaluating Capabilities of Rootkits Tools View project

Software Design Defects View project

All content following this page was uploaded by Sanjay Misra on 09 February 2018.

The user has requested enhancement of the downloaded file.

A Requirements Engineering Techniques Review
in Agile Software Development Methods

Lizbeth Zamudio1 , José Alfonso Aguilar2 , Carolina Tripp2 , and Sanjay Misra3
1
Posgrado en Ciencias de la Información, Facultad de Informática Culiacán
Universidad Autónoma de Sinaloa, México
82120 Mazatlán, Mexico
2
Señales y Sistemas (SESIS) Facultad de Informática Mazatlán
Universidad Autónoma de Sinaloa, México
82120 Mazatlán, Mexico
3
Covenant University, Nigeria
{e.zamudio,ja.aguilar,ctripp}@uas.edu.mx
ssopam@gmail.com
http://sesis.maz.uasnet.mx

Abstract. The first phase in the software development process is the

Requirements Engineering (RE). Several methods for software develop-
ment and RE techniques have been used to extract these users’ needs
depending on the software complexity. Our goal is to map the evidence
available about requirements engineering techniques adopted and chal-
lenges faced by agile methods in order to understand how traditional
requirements engineering issues are resolved using agile requirements en-
gineering. The agile methods considered for this work are: SCRUM, Dy-
namic Systems Development Method (DSDM), Adaptive Software De-
velopment (ASD) and Crystal Family. The present work is based on the
Systematic Literature Review (SLR) method proposed by Kitchenham;
we have reviewed publications from ACM, IEEE, Science Direct, DBLP
and World Wide Web. From a population of 34 papers, we identified 15
primary studies, which provide information concerning RE used in Agile
Software Development Processes.

Keywords: Requirements Enginneering, Systematic Literature Review,

Re Techniques

1 Introduction
Many companies nowadays do not use formal methodologies in their software de-
velopment projects [1], they uses intead common sense and its team experience.
This issue originates low quality software, which is not allowed in an environment
in which the technological and business environment changes rapidly. Method-
ologies have proven too cumbersome to meet the rapidly changing requirements
and short product cycles demanded by business today. To meet these rapidly
changing requirements, software developers have developed agile software devel-
opment methodologies utilizing iterative development, prototyping, templates,
and minimal documentation requirements [2].
 This is the reason why software engineering projects requires the use of
methodologies and dynamic processes to develop products and services quickly
and reliably. A clear fact is, however, that there is no single methodology that is
suitable for any project. This is why it is very important to know the different
methodologies that may be applicable to the projects, as well as to manage the
tools that will allow them to be selected, adapted or even formulated. These new
approaches focus mainly on iterative and incremental development, customer col-
laboration, and frequent delivery through a light and fast development cycle [3].
Many researchers have reported that agile methods have the potential to provide
a higher level of customer satisfaction, lower bug rates, a shorter development
cycle, and a quicker adaptation to rapidly changing business requirements.
In this sense, one of the most important facts to achieve a successfull software
is the first phase in the software development process: the Requirements Engi-
neering (RE). The main goal of RE is to attempt to fully satisfy users’ needs [4].
Therefore, several methods for software development and RE techniques have
been used to extract these users’ needs depending on the software complexity.
Although claimed to be beneficial, the software development community as a
whole is still unfamiliar with the role of the RE practices in agile methods. The
term “agile requirements engineering” or ARE is used to define the agile form of
planning, executing and reasoning about RE activities. Moreover, not much is
known about the challenges posed by collaboration-oriented agile way of dealing
with RE activities [5]. Agile methods offer a viable solution when the software
to be developed has fuzzy or changing requirements, being able to cope with
changing requirements throughout the life cycle of a project. Adoption of agile
software development methods enables a software developer to be more flexible
and responsive to the changing environments and customer demands [6] .
Agile software development processes were developed primarily to support timely
and economical development of high-quality software that meets customer needs
at the time of delivery. It is claimed by agile process advocates that this can
be accomplished by using development processes that continuously adapt and
adjust to (1) collective experience and skills of the developers, including ex-
perience and skills gained thus far in the development project, (2) changes in
softw requirements and (3) changes in the development and targeted operating
environments [7].
This paper presents a Systematic Literature Review (SLR) in order to ana-
lyze the current state-of-the-art with regard to Requirements Engineering (RE)
techniques used in ASD, specifically in agile requirements engineering (ARE),
thus revealing the activities that are implemented, such as elicitation, analysis,
specification, validation and management. A SLR is a means of identifying, eval-
uating and interpreting all the available research that is relevant to a particular
research question, topic area or phenomenon of interest. It originated in the field
of medical research and was successfully adapted to Software Engineering (SE)
by Kitchenham [8].
This paper is structured as follows: Section 2 presents some background. The
SLR is detailed in Section 3. The research Questions are answered in Section 4,
in which and analysis and discussion of this work are also presented. Finally, our
conclusions are provided in Section 5.

2 Background

This section presents an introduction about the agile methods considered for this
work and the Requirements Engineering Concepts for the analysis of Section 4.
The agile software development methods analyzed are: SCRUM, Dynamic
Systems Development Method (DSDM), Adaptive Software Development (ASD)
and Crystal Family. SCRUM is a methodology for the management and control
of projects, focused on the construction of software that satisfies the needs of the
customer, meets the objectives of the business and the development team that
product. Scrum does not require or provide any specific software development
methods/practices to be used. Instead, it requires certain management practices
and tools in different phases of Scrum to avoid the chaos by unpredictability and
complexity [9].
In [10], the author defines SCRUM, as a collection of processes for the man-
agement of projects, which in delivering value to the customer and the power- of
the equipment to achieve maximum efficiency, within of a continuous improve-
ment scheme. The fundamental idea behind DSDM is that instead of fixing the
amount of functionality in a product, and then adjusting time and resources to
reach that functionality, it is preferred to fix time and resources, and then adjust
the amount of functionality accordingly. Also, the roles defined in that approach
were combined and adapted, according to the team structure of the company.
Because of its simplicity and being more test-driven, allowing close collabora-
tion and communication[6]. In [11] the author define This is heavier than XP
and Scrum. It provides a technique-independent process and is flexible in terms
of requirement evolution. It is efficient in terms of budget and time. but It is
based on user involvement which is not possible in every project.
Adaptive Software Development (ASD) is a framework for the iterative devel-
opment of large, complex systems. The method encourages incremental, iterative
development with constant prototyping [12]. ASD highlights that a sequential
waterfall approach only works in well-understood and well-defined environments.
But as changes occur frequently in software development, it is important to use
a change-tolerant method. The first cycles of an ASD project should be short,
ensure that the customer is strongly involved and confirm the project’s viability.
ASD focuses more on results and their quality than the tasks or the process used
for producing the results [9].
Crystal Family method is based on the concept Rational Unified Process
[RUP] and is composed by Crystal Clear, Crystal Yellow, Crystal orange and
Crystal Red, improtant, the level of color opacity in the name indicates a greater
number of people involved and the size of the project , therefore, the need for
greater control in the process [13]. The values shared by members of the Crystal
family are focused on people and communication, its principles indicate that:
the team can reduce intermediate work to the extent that it produces code with
greater frequency and uses better channels of communication between people.
On the other hand, there are interesting works about reviews in agile software
developments methods such as [14], [15], [16],[9], [11], [7] and [17], but these works
regrettably does not point out the gaps regarding to requirements engineering
techniques applied on each method and how to address their limitations in order
to improve software development. In this sense, Requirements Engineering (RE)
is the process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed [18]. Various
approaches have been used to define RE activities, such as those proposed in
[19], and these activities widely differ from each other for several reasons, e.g.,
depending on the application domain, the people involved and the organization
developing the requirements. Requirements Engineering (RE) is concerned with
the elicitation, analysis, specification, validation and management of software
requirements [20]. These are detailed as follows:

– Elicitation, whose goal is to discover what problems need to be solved [21],

and to identify the stakeholders, and the objectives that a software system
must attain. It is carried out through the application of various techniques
[22], such as questionnaires, brainstorming, prototyping and modeling tech-
niques, e.g., goal oriented based methods [23].
– Analysis, which includes the creation of conceptual models or prototypes
with which to achieve the completeness of the requirements and deals with
understanding an organizations structure, its business rules, goals and tasks,
and the data that is needed.
– Specification, which is an integral description of the behavior of the system
to be developed. The most widely used techniques are templates, scenarios,
use case modeling, and natural language [24].
– Validation. The aim of this phase is to establish whether the requirements
elicited provide an accurate representation of the actual stakeholder require-
ments. Some of the techniques employed are reviews and traceability [25].
– Management, which consists of recognizing changes through the use of con-
tinuous requirements elicitation, and includes techniques for configuration
management and version control [26].

With regard to RE techniques, we have Interviews, Documentation Study,

On-site observation, Use Cases, Scenarios, Focus Groups, Brainstorming, Proto-
typing, Questionnaire, Natural Language and Form of contract, thse are detailed
next.

– Interviews. Interviewing is a method for discovering facts and opinions held

by potential users and other stakeholders of the system under develop-
ment.There are two different kinds of interviews: i) the closed interview,
where the requirements engineer has a pre-defined set of questions and is
looking for answers and ii) the open interview, without any pre-defined ques-
tions the requirements engineer and stakeholders discuss in an open-ended
 way what they expect from a system.The advantage of interviews is that
they help the developer to get a rich collection of information. Their disad-
vantage is that this amount of qualitative data can be hard to analyze and
different stakeholders may provide conflicting information [25].
– Documentation study. The documentation study consists of an in-depth
reading based on documents on the domain of the problem of the system
to be developed. These documents will deal with aspects related to the busi-
ness objectives of the organization or its professional practices. Some of the
main documents that can be consulted and analysed are: manuals of pro-
cedures and functions, reports generated by the current system, regulations
and legislations, user manuals of the current system, etc.
– On-site observation. The in situ observation consists of the direct observation
of the professional practices that are usually carried out in the organization
for which the software will be developed. Before conducting an on-site obser-
vation session, a set of practices representative of the rest should be chosen,
which are carried out relatively often or have a certain complexity of under-
standing.
– Use cases: This technique intends at defining the requirements by portraying
complete flow of events to the stakeholders in the form of a story telling
style. Use cases are informal and easy to use that help understanding the
requirements and validating them with stakeholders [27]
– Scenarios. Scenarios are common ly used after collecting the initial require-
ments. Scenarios also define the actions and interactions between user and
the system. Scenarios are useful to validate requirements and develop test
cases [27].
– Focus Groups. This technique is effective to elicit requirements and resolving
conflicts among the stakeholders by discussing all aspect of requirements
with proper suggestions by the group members in a cooperative environ
ment. However, it requires a lot of effort to conduct such meeting as it is
always difficult to get hold of all the stakeholders at the same time [27].
– Brainstorming. Brainstorming is a technique of group meetings whose pur-
pose is to generate ideas in an environment free of criticism or judgment. As
a technique for collecting requirements information, brainstorming can help
generate a wide variety of views of the problem and formulate it in different
ways, especially at the beginning of the requirements engineering process,
when the requirements are still very diffuse [28].The key disadvantage of
brainstorming is that it cannot be effectively used to resolve major issues
[27].
– Prototyping. Prototyping is a useful technique to develop novel applicat
ions and to build GUI interface. This technique is used with the combina-
tion of other requirement engineering techniques like interviews and JAD.
Conversely, potential hazards in prototyping are that the user often resist
changes if they had become used to a specific kind of the system as well as
it is also expensive in terms of time and cost [27].
– Questionnaire. The questionnaire is a method of requirement elicitation wh
ich is simple and requires lesser time and cost. To get precise results, the
 questionnaire should be clear, concise and structured to obtain genuine user
requirements, objective and constraints However, this technique lacks in the
mechanism to seek users clarification on the topic [27].
– Form of contract. Consists of filling forms or contracts indicating the require-
ments. It can be extensive according to the size of the Project and therefore
tends to be tedious its use within software development [29].
– Natural Language. Natural language is an important source of information,
because in most domains it is the most common mode of knowledge repre-
sentation. There are two categories: direct interaction with the user using
natural language and elicitation of requirements from a natural language
document.
The greatest appeal of natural language lies in its preexisting vocabulary,
informality and syntax. The existence of a vocabulary of thousands of pre-
defined words used to describe any possible concept makes natural language
an efficient means of communication. It is familiar to both the user and the
analyst and does not require learning time. However, there are two clear
limitations: natural language is very complex and ambiguous [30].

Summarizing, the use of techniques in the RE process is important since this

helps software engineers to avoid errors in the definition of the requirements due
to it can be very expensive to correct once the system has been developed. In
this paper the traditional techniques that are used in the RE applied by the
traditional methodologies are mentioned adding to this the process with which
each method counts helps to strengthen and in this way to obtain products to
develop with a higher quality. Agile methods are the solution to the problems
that can be caused by traditional methodologies. These methodologies emphasize
that responsiveness to change is more important than strict adherence to a plan.

3 The Systematic Literature Review

The goal of this SLR is to analyze the current state-of-the-art with regard to Re-
quirements Engineering (RE) techniques [21] used in ASD, specifically in agile
requirements engineering (ARE), thus revealing the activities that are imple-
mented, such as elicitation [22], analysis [19], specification [31], validation [24]
and management [25] in order to detect avenues for future research.

3.1 Research questions

According to [8], the question structure is divided into four aspects known as
PICO (Population, Intervention, Comparison and Outcomes). The term Popu-
lation refers to the people, projects and application types affected by the inter-
vention. Intervention concerns the software technology, tool or procedure that
generates the outcomes. Comparison refers to another type of intervention – if
applicable – while Outcomes are the technological impact on relevant informa-
tion terms for practical professionals. This PICO strategy has been used as the
basis for our research and is use in this context is described as follows:
 – Population: the population is composed of developers who request a method
in order to obtain more robust process support.
– Intervention: this review must search for indications that the development of
software can be fully supported by an agile method supporting requirements
engineering techniques.
– Comparison: not applicable.
– Outcomes: the objective is to demonstrate how a systematic process supports
the development software and whether or not the process is fully supported
with RE techniques.

Our research questions (RQ), which are based on the aforementioned strategy,
are:

– RQ1.- What agile approaches exist applying traditional RE techniques in

their agile development processes?
– RQ2.- Which RE techniques are commonly used to obtain the users’ needs
in their agile development processes?

3.2 Search Strategy

The search strategy should be systematic. According to [8], it is necessary to use

search engines by applying a combination of search terms (keywords) extracted
from RQ’s. Experts should then verify and review the search results. Once the
steps to be followed in the search process have been defined, it is necessary to
state the resources that are available to conduct the review of primary stud-
ies (individual studies contributing to an SLR). The research sources used are
repositories with restricted access such as: ACM, IEEE, Science Direct, DBLP
Computer Science Bibliography, World Wide Web: Google Scholar. In accor-
dance with Brereton [32], these libraries were chosen because they are some of
the most relevant sources in SE. Furthermore, Google Scholar was selected to
complete the set of conferences and workshops searched and to seek grey litera-
ture in the field (white papers, PhD theses), and the results obtained were then
compared with the works found using the search strings.

3.3 Inclusion and Exclusion Criteria

Essentially, only those publications from the RE literature regarding the RE ac-
tivities for specific use in the ASD field were considered. Although our research
questions are related only to techniques, this SLR includes the primary studies
related to the RE in the agile methods field and we therefore deemed that at least
the part related to the use of one of the RE activities in ASD must be present in
each primary study, since we assumed that not all methods implement another
RE phase. We chose the following inclusion criteria in order to select the rele-
vant publications required to answer our research questions: i) Publication date
between 01/01/2006 – 01/01/2016, ii) Requirements phase of the development
process, iii) Explicit mention of agile software development and iv) Relevance
with regard to research questions. The exclusion criteria were: i) Topics that do
not match the RE activities implemented in ASD methods and ii) Duplicated
documents from the same study.

3.4 Study Quality Assessment

The place of publication and the diffusion of the papers were used as indica-
tors when performing the quality assessment. The place of publication refers to
the journals and conferences in which the primary studies were published (this
applies to Google–Scholar which searches for a wider spectrum of papers such
as white papers). The diffusion of the methods corresponds to the academic or
industrial application of the method. The first search, during which no exclusion
criteria were applied, returned a total of 34 documents of which 2 documents
were duplicated. After applying the exclusion criteria (a further review round),
15 documents were eventually considered. It is important to mention that the
activity during which publications were searched for was checked by two individ-
ual authors of this work in order to verify the quality of the place of publication.
The quality assessment was then performed separately to verify the information
extracted.

3.5 Data Extraction

The goal of this phase is to design data extraction forms with which to accurately
record the information obtained from the primary studies. We used a form to
store the information extracted from the search results, storing the publication
title, the journal or conference/workshop in which the paper was published,
the publication date and the main author. After quality assessment, the data
synthesis was performed. This was done by collating and summarizing the results
of the primary studies, 15 total which are shown in annex 1 (table 2).

4 Data Analysis

This section presents and analyzes the results obtained after subjecting the pri-
mary studies to the extraction and data synthesis activities. The agile methods
considered for this work are: SCRUM, Dynamic Systems Development Method
(DSDM), Adaptive Software Development (ASD) and Crystal Family. The se-
lected studies provided relevant evidence with which to satisfactorily answer the
four RQs, as described below:

4.1 RQ1.- What agile approaches exist applying traditional RE

techniques in their agile development processes?

For eXtreme Programming (XP), Scrum and Crystal methods applying tradi-
tional RE techniques in their development processes, the authors use different
traditional techniques. In the work presented by [29], the authors use the combi-
nation of several techniques in the requirements elicitation process as: interviews,
brainstorming, prioritization, analysis, modeling, use case. In [33], the authors
propose in the Scrum method some techniques according to the the software en-
gineering process as it is, in elicitation the techniques to be used are: use cases,
scenarios, interviews; In the analysis phase the proposed techniques integrates
the UML diagrams and for the design phase only use cases. For the methodology
called Crystal, they suggest interviews, reflection workshops and meetings. The
author [16], in his research work, propose other techniques for the Crystal method
as use cases implementing UML and brainstorming, for Scrum recommend pro-
totypes, for XP scenarios and for the Dynamic Systems Development Method
(DSDM) workshops . In the research presented in , the author contemplates the
technique of prototypes in the method Adaptive Software Development (ASD).
In [12] the authors include other techniques for the ASD method such as reviews
and Joint Application Development (JAD) sessions, for the Crystal and DSDM
methods the techniques proposed are documentation, revisions and suggest that
observation and social analysis can be used to.
The agile methodologies considered for the elaboration of this paper are:
SCRUM, DSDM, Adaptive Software Development (ASD) and Crystal Family,
but we find other agile methods that use traditional techniques, such as Ag-
ile Unified Process (AUP), Kanban and Lean Software Development [29], these
approaches use interviews, brainstorming, prioritization, analysis meetings, mod-
eling, requirements documentation and use cases. In the research carried out by
[12], the authors focuses on the Agile Modeling (AM) method, which uses the
techniques of modeling and brainstorming, another method that includes in their
work is Feature Driven Development (FDD), which includes class diagrams and
meetings , for the DSDM method uses JAD sessions and prototypes. In [34], the
authors present in their work for the AUP method the modeling in the elicita-
tion phase, in the Iconix method the use cases using UML. Finally, in [35], the
authors include in addition to the methods already mentioned the Agile Project
Management (APM) with the technique of daily meetings.

4.2 RQ2.- Which RE techniques are commonly used to obtain the

users’ needs in their agile development processes?
As for the requirements engineering techniques applied in agile development
methods we find the work of [13] in which the authors describe other non-
traditional techniques that use the Scrum method which are: Backlog, Sprint,
Sprint planning, Daily Scrum, Sprint Review, for the XP method the use of User
Stories. The author [18] mentions in addition that the core practice in Scrum is
the use of daily 15-minute team meetings for coordination and integration, face-
to-face communication and review meetings In [16], the authors remarks that
for the XP method in addition to the user stories he also applies the story cards,
list of tasks in paper or chalkboard and visible graphs in a wall. The author [36]
establishes tahta before the stories can be written on the cards customers have
to think about what they expect the system do to and what functionality is
needed. In the Crystal staging method, standing meetings, methodology tuning
technique and user views; for the Scrum method the author also state the ef-
fort estimation, burn-down chart, burn-up chart and planning poker. In [12] are
proposed other techniques for Crystal method, which contemplates time-boxed,
workshops for product.
The following table mentions the techniques of the traditional methods and
which are used in the agile methodologies:

RE Techniques in RE Techniques in ASD

Tradicional SDP
Software requeri- Backlog in Scrum
ments especification
Interview In Scrum, Xp, Crystal
Brainstorming In Scrum,Crystal,points of view in XP
Use cases In Crystal,story uses in XP
Scenarios In Scrum, Xp
Meeting In Xp,Crystal
Prototypes In Scrum,time-boxed in Crystal and ASD
Priorization In Scrum, Xp, Crystal, Kanban
Modeling In Scrum, Xp, Crystal,Kanban
Analysis meetings In AUP,Kanban, Planning Poker in Scrum
Observation In Scrum, Xp, ASD,DSDM,Crystal
Social analysis In Scrum, Xp, ASD,DSDM, Crystal
Documentation Burn-down and burn-up in Scrum
Reviews In ASD Reviews Sprint in Scrum
Table 1. Tradicional techniques in techniques agil methods

4.3 An Agile Methods Analysis

One of the critical points within software development is requirements satis-
faction. It has been shown that most of the errors in software products occur
in the RE phase. It should also be considered that within the SE, the require-
ments are within the early phases of software development process and the cost
associated with the correction of an error, once the project is delivered, is signifi-
cantly higher. Given these reasons, it is necessary that organizations implements
software development process ad-hoc to its development team, to do this, is fun-
damental the adaptation of the RE process according to its team capacity if
they wish to make their development process more efficient, i.e.,the implementa-
tion of CMMI (Capability Maturity Model Integration), which in the first levels
requires a documented and formalized RE within the organization [37] . The
research should be oriented to the use of new techniques and approaches that
strengthen characteristics such as agility in the treatment of requirements, reduc-
tion of conflicts between participants, timely recognition of errors or problems
in the identification and specification of requirements and the establishment of
controls in its evolution in different phases of the life cycle [38] since, even today,
most software projects are considered to fail in one form or another, presenting
a series of common symptoms such as:
– Inadequate understanding of the end user’s needs.
– Inability to meet changing requirements.
– Modules that can not be coupled to work together.
– Software difficult to maintain or expand.
– Late detection of critical faults.
– Software of low quality.
– Unacceptable software performance.
Next, a set of deficiencies extracted from primary studies are detailed:
1. Not all methodologies can be used in any software development project, this
depends on the size of the project, i. e., in the case of very small projects may
be enough to use rapid development methodologies such as XP. In projects
of much larger scale it will be desirable, on the contrary, to minimize risks
by supporting development with project management methodologies that
facilitate the handling of aspects such as procurement, third party contracts,
risk management, human resources, and In general, aspects that are beyond
the scope of simple software development [1].
2. The emphasis that agile methods place on communication can also make
it difficult for international teams to work together in an agile way. The
transfer of knowledge becomes more difficult when people are not working
on the same site or even speaking the same language. In such a case, the
use of documentation is necessary, but this often leads to missinterpretation
[39].
3. Despite the fact that the use of agile methods offers a number of benefits
and has been a widely used adopted by software development teams, agile
methods does not offer the same benefits when it comes to medium and
large software projects. Some of the reasons for this are the weakness of
the documentation, the lack of ignorance to the risk awareness during the
development of the software [40].
4. Productivity measured in lines of code also increases if agile methods are
used. With regard to product quality, the work presented in [41] indicates
that the quality of the product may increase, but it is not conclusive.
5. The main problem for the management of agile methods is the correct quan-
tification and evaluation of the real state of the project. There are not many
clear and generalizable conclusions, but we can say that no evidence has
been detected against the use of these agile methodologies. Perhaps the most
delicate point would be to make the concepts of ”software architecture” com-
patible with that of ”agility”. The software architecture, defined according
to the Rational Unified Process, is defined as the set of decisions about the
organization of a software system, the selection of the structural elements
and the interfaces of which the system will be composed, along with the
behavior that specify those elements [41].
 On the other hand, there are a set of benefits of the implementation of agile
methods in software development, i. e., it has been found that XP has been more
difficult to introduce into complex organizations and that it was more suitable
for small groups than for larger projects. The adoption of agile methods is easy
in many cases and benefits are found in the collaboration with the client, in the
treatment of errors and in some aspects of management and even in estimation.
There is also some improvement in the perception of the clients on the effects
of communication, although if the contact is very continuous it is perceived
tiredness [41].
The success factors with quantitative evidences in the implementation of this
type of methods are: i) the use of a correct strategy of product delivery, ii) the
use of an adequate practice of agile SE techniques, the integration of a group
of high qualification work together with a high involvement of the client and an
adequate management process. Software architecture is not only concerned with
structure and behavior, but also with its use, functionality, performance, reuse,
comprehensibility, and economic and technological constraints. Next are listed a
set of strengths for the agile methods studied in this review:

– XP. Extreme Programming (XP) is the most popular agile methodology and
is based on a series of concepts that include: having the business customer
on-site, pair programming, collective code ownership, continuous code inte-
gration, small releases, designing test before writing code, standup meetings,
refactoring and 40-h work weeks [6].
– SCRUM. Scrum is an iterative, incremental process for developing any prod-
uct or managing any work. Scrum concentrates on how the team members
should function in order to produce the system flexibility in a constantly
changing environment [9].
– ASD. The objectives and schedules are set in the initiation phase of the
Project. In the collaboration phase, several components are under concurrent
development since components are constantly refining the planning cycle is
a part of the iterative process. The final phase Reflects on the work that has
been done, including project status and client input, and how the process
could be improved [39].
– Crystal. Crystal methods focus on security, efficiency and usability (devel-
opers should methodology). This method has a number of principles in com-
mon, the most important is the delivery of products, comments on improve-
ments and good communication between team members [39].Focuses on com-
munication in small teams developing software that is not life-critical [11].
– DSDM. There are nine practices that define the ideology and the basis for all
activity in DSDM. Some of the underlying principles include active user in-
teraction, frequent deliveries, empowered teams, and testing throughout the
cycle. There is an emphasis on high quality and adaptivity towards chang-
ing requirements. Like other agile methods, DSDM approaches iterations as
short time-boxed cycles of between two and six weeks [9].
5 Conclusion and Future Work
In this SLR, we formulated and applied specific inclusion and exclusion crite-
ria to determine the most relevant studies for our research questions (RQ1 and
RQ2 in Section 3). The agile methods considered for this work were SCRUM, Dy-
namic Systems Development Method (DSDM), Adaptive Software Development
(ASD) and Crystal Family. Our findings identified 15 works related with ARE,
and we conclude that suggest that agile requirements engineering, as a research
context, needs additional attention and more empirical results are required to
better understand the impact of agile requirements engineering practices e.g.
dealing with non-functional requirements and self-organizing teams. Moreover,
systematic approaches related to the application of RE techniques in person-
alized software development methods are not studied in current literature. We
suggest, as a future work, that empirical studies should be performed with suffi-
cient rigor to enhance the body of evidence in RE within ASD. In this context,
there is a clear need for conducting studies comparing alternative methods com-
bining RE techniques used in agile software development and traditional software
development.
In order to address scalability and popularization of the approaches, future
research should be invested in tool support and in addressing combined RE tra-
ditional adoption strategies. Finally, we conclude our work stating that agile
methods assume that it is very hard to elicit all the requirements from the user
upfront, at the beginning of a development project. They also assume that such
requirements evolve in time as the customer may change its mind or the overall
technical and socio-economical environment may evolve. Therefore, software fac-
tories are aware that changes are inevitable and they include the management
of variability into the development process. Agile methods are fundamented in
that i) requirements are not well known at the beginning of the software devel-
opment project, ii) requirements change, always do, and iii) making changes is
not expensive if you have a RE process well-defined.

Acknowledgments. This work has been partially supported by: Universidad

Autónoma de Sinaloa (México) through the Programa de Fomento y Apoyo a
Proyectos de Investigación (PROFAPI2015/002).

References
1. Bastardo Ordaz, M.A., Giménez, O.: Selección de una metodologı́a para la gerencia
de proyectos de desarrollo de software. Master’s thesis, Caracas (2006)
2. Livermore, J.A.: Factors that significantly impact the implementation of an agile
software development methodology. JSW 3(4) (2008) 31–36
3. Cho, J., Huff, R., Olsen, D.: Management guidelines for scrum agile software
development process. Issues in Information Systems 12(1) (2011) 213–223
4. Aguilar, J.A., Garrigós, I., Mazón, J.N., Trujillo, J.: An MDA Approach for Goal-
oriented Requirement Analysis in Web Engineering. J. UCS 16(17) (September
2010) 2475–2494
 5. Inayat, I., Salim, S.S., Marczak, S., Daneva, M., Shamshirband, S.: A system-
atic literature review on agile requirements engineering practices and challenges.
Computers in Human Behavior 51, Part B (2015) 915 – 929
6. Mishra, D., Mishra, A.: Complex software project development: agile methods
adoption. Journal of Software Maintenance and Evolution: Research and Practice,
volume=23 (8) (2011) 549–564
7. Turk, D., France, R., Rumpe, B.: Assumptions underlying agile software develop-
ment processes. arXiv preprint arXiv:1409.6610 (2014)
8. Kitchenham, B.: Procedures for performing systematic reviews. Keele, UK, Keele
University 33(2004) (2004) 1–26
9. Awad, M.: A comparison between agile and traditional software development
methodologies. University of Western Australia (2005)
10. Dı́az, J.R.: Las metodologı́as ágiles como garantı́a de calidad del software. REICIS.
Revista Española de Innovación, Calidad e Ingenierı́a del Software 5(3) (2009) 40–
43
11. Rao, K.N., Naidu, G.K., Chakka, P.: A study of the agile software development
methods, applicability and implications in industry. International Journal of Soft-
ware Engineering and its applications 5(2) (2011) 35–45
12. Paetsch, F., Eberlein, A., Maurer, F.: Requirements engineering and agile software
development. In: Enabling Technologies: Infrastructure for Collaborative Enter-
prises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops
on, IEEE (2003) 308–313
13. Navarro, A.é., Fern ández, J., Morales, J.: Revisi ón de metodologı́as ágiles para
el desarrollo de software. Prospect 11(2) (2013) 30–39
14. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J., et al.: Agile software devel-
opment methods: Review and analysis. In: Proceedings of the Conference on the
Future of Software Engineering, VTT Finland (2002)
15. Patel, A., Seyfi, A., Taghavi, M., Wills, C., Na, L., Latih, R., Misra, S.: A com-
parative study of agile, component-based, aspect-oriented and mashup software
development methods. Tehnicki Vjesnik 19(1) (2012) 175–189
16. Rivadeneira, S., Vilanova, G., Miranda, M., Cruz, D.: El modelado de requerim-
ientos en las metodologı́as ágiles. In: XV Workshops de Investigadores en Ciencias
de la Computación. (2013) 383–387
17. Stapleton, J.: Dynamic systems development method. Addison Wesley (1997)
18. De Lucia, A., Qusef, A.: Requirements engineering in agile software development.
Journal of emerging technologies in web intelligence 2(3) (2010) 212–220
19. Hull, E., Jackson, K., Dick, J.: Requirements engineering. Springer Science &
Business Media (2010)
20. Dieste Tubio, O., López, M., Ramos, F.: Updating a systematic review about
selection of software requirements elicitation techniques. (2009)
21. Nuseibeh, B., Easterbrook, S.: Requirements engineering: a roadmap. In: Pro-
ceedings of the Conference on the Future of Software Engineering, ACM (2000)
35–46
22. Maiden, N.A., Rugg, G.: Acre: selecting methods for requirements acquisition.
Software Engineering Journal 11(3) (1996) 183–192
23. Yu, E.: Modelling Strategic Relationships for Process Reenginering. PhD thesis,
University of Toronto, Canada (1995)
24. Bass, L., Bergey, J.K., Clements, P.C., Merson, P.F., Ozkaya, I., Sangwan, R.:
A comparison of requirements specification methods from a software architecture
perspective. (2006)
25. Chrissis, M.B., Konrad, M., Shrum, S.: CMMI for development: guidelines for
process integration and product improvement. Pearson Education (2011)
26. Estublier, J.: Software configuration management: a roadmap. In: Proceedings of
the Conference on the Future of Software Engineering, ACM (2000) 279–289
27. urRehman, T., Khan, M.N.A., Riaz, N.: Analysis of requirement engineering pro-
cesses, tools techniques and methodologies. International Journal of Information
Technology and Computer Science (IJITCS) 5(3) (2013) 40
28. Sommerville, I., Sawyer, P.: Requirements engineering: a good practice guide. John
Wiley & Sons, Inc. (1997)
29. Andres Gonz ález, Diego Anduquia, type=B.S. thesis, y.: La ingenierı́a de requisitos
en las metodologı́as ágiles: Requisitos ágiles. Master’s thesis
30. Thomas, P.J.: Definición de un Proceso de Elicitación de Objetivos. PhD thesis,
Facultad de Informática (2005)
31. Yu, E.: Towards modeling and reasoning support for early-phase requirements
engineering. In: RE. (1997) 226–235
32. Brereton, P., Kitchenham, B.A., Budgen, D., Turner, M., Khalil, M.: Lessons from
applying the systematic literature review process within the software engineering
domain. Journal of systems and software 80(4) (2007) 571–583
33. Orjuela, A., Rojas, M.: Las metodologı́as de desarrollo ágil como una oportu-
nidad para la ingenierı́a del software educativo. Revista Avances en Sistemas e
Informática 5(2) (2008) 159–171
34. Figueroa, R., Solis, C., Cabrera, A.: Metodologı́as ágiles vs metodologı́as tradi-
cionales. Informe Cientı́fico Técnico UNPA 5(1) (2013) 1–29
35. Izarraulde, M.: Caracterización de especificación de requerimientos en entornos
ágiles: Historias de ususarios. B.S. thesis (2013)
36. Koerner, E., Eberlein, A.: Requirements engineering in agile software development
37. Diéguez, M., Sepúlveda, S., Canullan, D.: Diseño de un documento para la elic-
itación y especificación de requerimientos: Caso práctico. In: WorkShop Interna-
tional EIG. Volume 11. (2010)
38. Londoño, L.F., Anaya, R., Tabares, M.S.: Análisis de la ingenierı́a de requisitos
orientada por aspectos según la industria del software. Revista EIA (9) (2008)
43–52
39. Verdiesen, B.: Agile user experience (2014)
40. Jameel, R.: Agile software development methodology for medium and large
projects. Ágile software development methodology for medium and large projects
6 (2011) 358–363
41. Dolado, J., rodrı́guez, D.: Utilidad de los procesos ágiles en el desarrollo de software.
Novática. Revista de Asociación de Técnicos de Informática–España 209 (2011)
73–74
 Table 2. Annexed 1

Article Publication Year

A systematic literature review on agile require- Computers in Human Behavior 2015
ments engineering practices and challenges
Assumptions underlying agile software develop- arXiv preprint arXiv:1409.6610 2014
ment processes
Analysis of requirement engineering pro- International Journal of Information Technology
cesses,tools/techniques and methodologies
and Computer Science (IJIT CS) 2013
Metodologı́as ágiles enfocadas al modelado de re- Informe Cientı́fico Técnico UNPA 2013
querimientos
A comparative study of agile, component-based, Tehnicki Vjesnik 2012
aspect-oriented and mashup software develop-
ment methods
Agile software development methodology for Ágile software development methodology for medium
medium and large projects
and large projects 2011
Complex software project development: agile Journal of Software Maintenance and Evolution:
methods adoption
Research and P ractice 2011
A study of the Agile software development meth- International Journal of Software Engineering and
ods, applicability and implications in industry
its applications 2011
Management guidelines for scrum agile software Issues in Information Systems 2011
development process
Requirements engineering in agile software devel- Journal of emerging technologies in web intelligence 2010
opment
An MDA Approach for Goal-oriented Require- J. UCS 2010
ment Analysis in Web Engineering
Las metodologı́as ágiles como garantı́a de calidad J. REICIS. Revista Española de Innovación, Calidad
del software
e Ingenierı́a del Sof tware 2009
Las Metodologı́as de Desarrollo ágil como una Revista Avances en Sistemas e Informática 2008
Oportunidad para la Ingenierı́a del Software Ed-
ucativo
Factors that Significantly Impact the Implemen- JSW 2008
tation of an Agile Software Development Method-
ology
engineering and agile software development Enabling Technologies: Infrastructure for Collaborative
Enterprises, 2003 W ET ICE 2003. P roceedings. T welf th
IEEE International W orkshops on 2003

View publication stats