Modelos Concepuales en Proyectos Agiles

Received 22 September 2022, accepted 31 October 2022, date of publication 10 November 2022,
date of current version 17 November 2022.

Digital Object Identifier 10.1109/ACCESS.2022.3221428
Using Conceptual Models in Agile Software

Development: A Possible Solution to
Requirements Engineering Challenges
in Agile Projects
ABHIMANYU GUPTA 1, GEERT POELS 1,2 , AND PALASH BERA3
1 Department of Business Informatics and Operations Management, Faculty of Economics and Business Administration, Ghent University, 9000 Ghent, Belgium
2 Core Laboratory CVAMO, FlandersMake@UGent, 9000 Ghent, Belgium
3 Operations and ITM Department, Chaifetz School of Business, Saint Louis University, Saint Louis, MO 63108, USA
Corresponding author: Abhimanyu Gupta ([email protected])

This work was supported by the Fund for Scientific Research—Flanders (FWO) under Grant G.0101.16N-39515.
ABSTRACT Studies on requirements engineering with Agile methods for software development have shown
difficulties in managing the quality of the requirements and communicating with users. Some of these studies
have proposed conceptual modeling as a solution to these problems. However, the effort that is required
to create conceptual models conflicts with Agile values. In this paper, we propose an approach for using
conceptual models in projects while adhering to Agile principles. This approach focuses on projects in
which requirements are expressed as user stories that are the main artifacts of the requirements used for
software development with Agile methods. First, the paper presents a literature review in which we have
systematically searched for the challenges to requirements engineering with Agile methods. Next, we report
on a survey study in which we interviewed 16 experts in the Agile methodology to confirm the identified
challenges and find new ones that are not covered in the literature. Based on a thematic analysis of the
challenges, we argue that most of them map to the two main purposes of using conceptual models in software
development: improving communication and understanding requirements. To effectively use conceptual
models in projects that use the Agile methodology, several conditions must be met, which we make explicit
in the paper. The paper ends by illustrating how these conditions can be met demonstrating the models that
can be automatically generated from a given set of user stories. This demonstration was subsequently used to
obtain feedback from the experts on the perceived benefits of conceptual models in addressing the challenges
of requirements engineering.
INDEX TERMS Agile software development, user stories, conceptual models.
I. INTRODUCTION Based on these values, Agile methods like Extreme Pro-

The purpose of the manifesto for Agile Software Develop- gramming, Scrum, Kanban, and SAFe, prescribe shorter and
ment [1] was to uncover better ways of developing software. more incremental development iterations than other method-
The manifesto proposed the following values: individuals ologies for software development do. After each iteration the
and interactions over processes and tools; working software requirements can be modified [2]. Therefore, developers have
over comprehensive documentation; customer collaboration adopted Agile methods in practice for their ability to embrace
over contract negotiation; and responding to change over change rather than to avoid it and to respond efficiently and
following a plan. effectively to changing requirements [3].
The main artifact of requirements in the Agile method-
The associate editor coordinating the review of this manuscript and ology is the user story [4]. A user story is a simple textual
approving it for publication was Antonio Piccinno . description of a desired feature of the working software
This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 10, 2022 119745
A. Gupta et al.: Using Conceptual Models in Agile Software Development
that is written from the user’s perspective and is typically (e.g., offshore premises) [16]. In our investigation, we focus
formulated using a standardized text template [5], [6] (see specifically on the challenges related to the documentation of
Table 8 in Section 7 for examples). In the Agile methodology, user stories as an artifact for requirements.
developers most often use user stories to describe functional Next, through a thematic analysis of the identified chal-
requirements [7] (as in Table 8). Note that the nonfunctional lenges, we show that most challenges can be mapped to
requirements are out of the scope of this paper. Although user the main purposes for using conceptual models: improving
stories provide an easy-to-use mechanism for documenting communication among project stakeholders and improving
and communicating the desired system features, user stories the understanding of the requirements.
as used in practice are prone to ambiguity that leads to risks Subsequently, to further explore how conceptual models
of the imprecision, inconsistency, incompleteness, and redun- can be used without conflicting with Agile values, we identify
dancy of the requirements [8]. the conditions that need to be met for the use of conceptual
Other software development methodologies, for instance models in projects that document user stories for require-
the rational unified process (RUP) or that follow an object- ments. We also demonstrate an example in which we are able
oriented methodology to software development, use concep- to meet these conditions when models can be automatically
tual models such as use case diagrams in the unified modeling generated from the information captured by the user stories.
language (UML), activity diagrams, state machine diagrams, Finally, to evaluate the usefulness of conceptual models
and class diagrams (see Figures 1 and 2 in Section 7 for in addressing the challenges to requirements engineering in
examples) to conceptualize the domain that the system sup- the Agile methodology for software development, we demon-
ports and to visually represent the functionality expected from strate a set of models to experts that we interviewed to seek
the system. Conceptual models support requirements analysis their opinion on how these models could benefit requirements
and system design [9]. As visual representations, they facil- analysis in the Agile methodology. We also map these ben-
itate communication among the project team members and efits to the challenges of requirements engineering that we
help create a shared understanding of how a system should identified.
support a domain [10]. To summarize, this paper contributes to the state-of-the-
In the Agile methodology, the use of conceptual models art by providing an up-to-date overview of the challenges
is not common as the effort required to create the models to requirements engineering that are observed in the current
conflicts with Agile values. Instead, the focus of requirements practice of the Agile methodology for software development:
engineering in the Agile methodology is to efficiently and we identify those challenges that can potentially be addressed
flexibly transfer ideas from the customer to the development by using conceptual models; identify the conditions that need
team but without creating excessive documentation of the to be met for adopting conceptual models in the practices of
requirements [11]. the Agile methodology; and we demonstrate that it is possible
In practice, however, requirements engineering in the Agile to meet these conditions in projects that use user stories to
methodology is challenging, as many surveys and literature document requirements. With these novel contributions, our
reviews have reported [11], [14]. So, while visual models explorative research provides a basis from which researchers
have proven their effectiveness in supporting requirements can further investigate the use of conceptual models in the
engineering, their use is not advocated by Agile proponents. Agile methodology to support requirements engineering.
Therefore, we explore in the following question: how can In Section 2, we provide a background on requirements
conceptual models address the challenges of requirements engineering in the Agile methodology for software devel-
engineering in the Agile methodology for software develop- opment. In Section 3, we describe the methodology of our
ment without conflicting with its values? Recently, studies explorative study. Section 4 presents the literature review
have suggested that the use of conceptual models to under- of the challenges to requirements engineering for the Agile
stand and analyze requirements that developers have formu- methodology. Section 5 presents the results of interviews with
lated as a set of related user stories (e.g., a theme or epic 16 experts in the Agile methodology for software develop-
in Scrum) is a research opportunity [8]. We not only inves- ment. In Section 6, we synthesize the results of the literature
tigate this broad research opportunity but also explore a more review and the interviews. In this section, we also map the
focused one: how can conceptual models address the chal- identified challenges to the purposes of using conceptual
lenges of requirements engineering in the Agile methodology models to explore how the use of conceptual models can
for software development that are related to user stories? address them. Following this mapping, in Section 7 we iden-
To investigate these research questions, we first reviewed tify conditions for using conceptual models without compro-
the recent literature and conducted expert interviews to iden- mising adherence to Agile values. We also demonstrate in this
tify these challenges. In doing so, we have updated existing section how these conditions can be met for projects using
surveys and review studies (e.g., [11] and [14]) as the Agile user stories, and we report on the perceived benefits of models
methodology for software development is a rapidly chang- generated from user stories after being shown to our experts.
ing area [15] that has become more complex with projects Section 8 presents our conclusion and suggestions for further
involving multiple team members in multiple locations research.
119746 VOLUME 10, 2022

II. REQUIREMENTS ENGINEERING IN THE acquiring knowledge of the business processes. This knowl-
AGILE METHODOLOGY edge is usually reflected in business process models.
One of the most difficult tasks in developing software is Related to user stories, Kannan et al. [23] have proposed
requirements engineering [16]. As a result, software develop- the use of use case diagrams in the UML that are obtained
ment has used the Agile methodology as a management tool. from user stories where each user story is represented as a use
The Agile methodology comprises a set of principles that val- case. Based on a survey of the use of models, Schön et al. [15]
ues individuals and interactions over processes and similarly, finds that some organizations that use the Agile methodology
prefers working software over documentation [1]. The Agile are using use case diagrams, story cards (i.e. details of user
methodology prescribes an iterative and incremental develop- stories), and mind maps to create shared understanding and
ment process in which the Agile team works closely with the getting potential users involved in the development process.
customer [16]. The Agile methodology focuses on continuous Along a similar vein, Helmy et al. [24] argue that developing
and iterative improvement of the software development as high-level domain models as part of the initial efforts at archi-
driven by the actual experience of using the software [17]. tectural modeling can guide both the design of the physical
Each iteration has phases of design, implementation, and data model and class design. Trkman et al. [25] suggest that
testing as well as an requirements analysis [17]. using business process models leads to a better understanding
To organize the Agile process, the team uses several meth- of the dependencies among user stories. In their systematic
ods such as Extreme Programming, Kanban, SAFe, and literature review, Amna and Poels [8] find 13 studies that
Scrum; Scrum is generally recognized as the most adopted propose the use of models for tackling problems related to
method [16]. Scrum defines three roles for project teams: the ambiguity in user stories. They also find that the literature
product owner, developer, and scrum master [16]. The scrum has only validated a few of these proposed solutions. Further,
master guides and coaches the team to the proper understand- the question of how to develop and use the models within an
ing and use of Scrum. The product owner is responsible for Agile project is still an open one.
managing the requirements and identifying the features to be
implemented in the iterative development phases, also known III. METHODOLOGY
as sprints [16], [18]. The implementation of the features is the We conducted an exploratory study to investigate our research
responsibility of the developer. questions. Our study consisted of three steps. First, we con-
In combination with methods such as Scrum, teams use ducted a literature review to identify current challenges to
several techniques such as behavior-driven development requirements engineering in Agile projects. The literature
(BDD) and test-driven development (TDD) in the Agile reviews and surveys [11], [14] indicated that in spite of the
methodology to organize the activities in requirements engi- popularity of applying the Agile methodology to software
neering. BDD comprises the use of user stories and accep- development, there were key challenges in eliciting, docu-
tance criteria to specify a system’s requirements [19]. In the menting, analyzing, verifying, and validating requirements
TDD, the team writes tests before the developers produce the in these projects. Some of these studies reviewed research
actual code, and this test writing is considered as part of papers published in the early development of Agile when its
the requirements engineering [4]. use was not yet common. As of today, the Agile methodology
Using conceptual models in the Agile methodology is by is used extensively in software development which is an
itself not a novel idea. Recker and Green [20] have pointed area that has increased in complexity (e.g., global software
out that although the Agile methodology has gained popu- development) [16]. Therefore, the verification of whether
larity recently, the use of conceptual models has not disap- the challenges to requirements engineering that these past
peared from software development. Some researchers suggest reviews and surveys have identified are still relevant and
using even more documentation (including visual models) whether studies or practitioners have found new challenges
and tools in the Agile methodology. For instance, contrary in the development of Agile.
to Agile practices, researchers have found that tacit knowl- As a second step we conducted semi-structured interviews
edge is not sufficient and formal documentation is therefore with experienced practitioners of the Agile methodology to
necessary [21]. Vithana [16] argues that since formal doc- validate the challenges identified by the literature and to iden-
umentation is missing, verification of requirements might tify new ones it had not uncovered. In these interviews we also
not be adequately addressed. To alleviate the communication focused specifically on the practice of describing require-
problems in Agile projects, Sundararajan et al. [21] suggest ments with user stories. The synthesized list of literature-
the creation of design documents for the overall architecture based and interview-based challenges was then mapped for
of the systems, the design of the database, and the inter- the purpose of using conceptual models to provide some
facing needs of the systems. Daneva et al. [22] conduct a initial insights into the answers to the research questions.
survey and find that the sharing of domain knowledge is an As a third and last step, we reflected on the conditions that
important characteristic for prioritizing requirements in Agile needed to be met for using conceptual models in the Agile
projects. Consequently, they suggest the introduction of the methodology. To further explore the answers to our research
role of domain owner to the Agile team that is responsible for questions, we then demonstrated how the information
VOLUME 10, 2022 119747

captured in user stories could be used to generate concep- 8 challenges in each of the previously mentioned reviews
tual models, and how these models could then be useful [11], [14], we decided to group challenges into several themes
for addressing the identified challenges. To evaluate whether in our analysis. The thematic analysis [26] is a qualitative
expert practitioners of the Agile methodology would also data method that relies on coding techniques to make sense
perceive this process as useful, we continued some of the of the data and discover underlying themes. Although these
interviews of the second step by showing the example set of coding techniques are like those used in the grounded theory
related user stories and the models generated from them and method [27], the thematic analysis does not aim at con-
asking the participants how they thought these models could structing hypotheses about phenomena observed in the data.
benefit the analysis of requirements. We took a reflexive and inductive approach to the thematic
analysis by using the open coding technique that has no a pri-
A. LITERATURE REVIEW ori theoretical definition of the themes to guide the coding
To update the current knowledge of the challenges that Agile and summarization process.
faces in requirements engineering, we performed a systematic
search of papers published in the academic journals in the B. INTERVIEWS
Elsevier and Science Direct libraries. These libraries include Practitioners of the Agile methodology were interviewed to
numerous field journals that frequently publish peer-reviewed validate the identified challenges to requirements engineer-
papers related to software development (e.g., Journal of Sys- ing found in the literature and to identify any new ones
tems and Software, Information and Software Technology, not mentioned in the papers that were reviewed. We looked
IEEE Software, and Software Quality Journal). They also for practitioners that should be knowledgeable about these
contain the flagship journals of the broader field of software challenges due to their expertise and experience. To get
engineering and information systems (e.g., MIS Quarterly access to these practitioners, we used a convenience sampling
and Information Systems Research). method. We searched for members of the Agile community
To manage the scope of the literature review and effort on LinkedIn and based on their profiles, selected members
required to analyze papers, we searched for those that explic- that had at least five years of experience working with Agile,
itly discussed the challenges to requirements engineering for described themselves as a senior business analyst or a tech-
the Agile methodology. In other words, we did not intend to nologist, and that had served on Agile teams in different roles.
review all published work on the Agile but to look ourselves Interviews were conducted using a semi-structured inter-
for elements that could be interpreted as challenges to engi- view protocol. The first guiding question was: ‘‘What chal-
neering and managing requirements that could also introduce lenges do you face with requirements in terms of using Agile
a certain degree of subjectivity. To search for papers, we built for software development?’’ Based on our second research
search strings that contained the words ‘‘agile’’, ‘‘require- question, as the use of user stories is the most popular require-
ment(s)’’, and ‘‘challenge(s)’’. The ‘‘challenges’’ searches ments artifact in the Agile methodology, we introduced a
used three synonyms ‘‘difficulties’’, ‘‘obstacles’’, and ‘‘hin- second question on user stories: ‘‘What challenges do you
drances’’ (and the singular version of these plural words) as face with the development and management of user stories in
alternates. As agile is a term also used in other domains, the Agile methodology?’’ Finally, we demonstrated a set of
we added ‘‘software’’ or ‘‘information systems’’ to these models generated from an example set of user stories to 11 of
search strings to focus exclusively on papers related to the the interview participants (F1 to F11) – we did not consider
development of software or information systems. doing this in the five first interviews which was the reason
Our searches were performed at the end of 2020 and were why we only got 11 expert opinions. We then asked them
limited to the most recent 11 full years from 2009-2019. The to comment on the benefits such models would add to the
automated search returned 865 papers. Our inclusion criteria requirements analysis in Agile if they were available. In total
for the review were ‘‘peer-reviewed papers’’ (e.g., exclud- we recruited 16 participants to interview (Table 2). The first
ing book reviews and editorials) and ‘‘relevancy’’. The lat- five interviewees (who were not shown the models generated
ter criterion was evaluated by reading the papers’ abstracts for the demonstration) were coded with IDs E1 to E5, and the
and verifying whether the term ‘‘agile’’ referred to software later 11 interviewees were coded with IDs F1 to F11.
development and its challenges (or difficulties, obstacles, The average length of for the first half of the interviews
etc.) while also referring to requirements engineering related was 20 minutes (i.e., Agile challenges) and 22 minutes
activities or concerns. The exclusion criteria used language for the second half of the interviews (i.e., model benefits).
(only papers in English) and when the full text of the paper All interviews were recorded, and transcripts were generated.
was not available. After verifying these criteria, 57 papers For each statement, words or phrases related to what could be
were selected for further analysis (see Table 1 for the full identified as challenges or benefits were identified.
references of these papers).
The analysis itself involved extracting the challenges to IV. RESULTS OF THE LITERATURE REVIEW
requirements engineering discussed in the papers. Next, a uni- Table 3 contains the list of 22 challenges to requirements
fied list of these challenges was compiled. As we ended engineering and the papers that mention them. Some chal-
up with a list of 22 challenges, much longer than the lenges were found in just one or a few papers but often
119748 VOLUME 10, 2022

TABLE 1. List of references used in Table 3.
VOLUME 10, 2022 119749

TABLE 1. (Continued.) List of references used in Table 3.
119750 VOLUME 10, 2022

TABLE 2. Participant profiles. Two challenges, (21) external visibility on project tasks,
and (22) inadequate or inappropriate architecture and inter-
faces could not be categorized in these themes as they seemed
to be stand-alone challenges that were not related to the other
challenges. All the challenges are summarized in Table 4.
The 22 challenges presented here are neither mutually
exclusive nor independent from each other. One challenge
might be the effect or a cause of another challenge.
A. CHALLENGES RELATED TO THE PROJECT TEAM

1) TEAM’S LACK OF INVOLVEMENT AND MOTIVATION
Project management needs to motivate team members to
respond reasonably quickly to changes in requirements and
with enough detail and understanding of the situation [28].
This motivation is reflected by team members’ willingness
to commit to a decision [29], [30] and take risks [31]; there-
fore, the members rely on the Scrum master’s decisions [32].
Developers are less likely to adopt the Agile methodology
if it is not made mandatory [33]. Tessem [34] shows that
empowering and rewarding developers in decision-making
drives the success of projects. McHugh et al. [35] find that the
trust between developers and product owners is important for
project success. Schön et al. [15] find that involving end users
is crucial to the success of Agile for software development.
2) BREAKDOWN OF TEAM COMMUNICATION

AND COORDINATION
The lack of open communication is the root cause for
many project failures [36]. A lack of detailed documentation
can also lead to communication issues. Ramesh et al. [11]
point out that when there is a breakdown in communication
there were several papers mentioning the same challenge, (e.g., turnover of personnel) then lack of documentation leads
up to a maximum of 11. The thematic analysis resulted in to the inability to scale the software, evolve the application
five overarching themes: project team, customer involvement, over time, and to add new members to the development team.
requirements quality, user stories, and testing. As Agile projects do not scale well, it requires much more
If a challenge was associated with requirements engineer- effort in team coordination [37], [38]. This coordination is
ing or management issues that related to project teams, their particularly difficult when the developer uses the outsourcing
management, or any specific role within the team (e.g., Scrum model [21], [39] or disperses the project team [4], [40], [41].
master, product owner); then this challenge was categorized Heck and Zaidman [42] argue that using collaborative tools
in the project team theme. There were five challenges identi- facilitates team coordination.
fied in this theme (1-5).
If a challenge related to the involvement of customers 3) DIFFICULTY IN MANAGING DISPERSED TEAMS
in requirements processes, then it was categorized in the Due to the globalization of software-intensive, high-
customer theme. We found two challenges under this technology businesses, developers are building Agile projects
theme (6-7). that involve teams in different geographic locations and time
Challenges related to analyzing or verifying requirements zones [43]. In a survey, Misra et al. [44] find that the use
were categorized in the requirements quality theme. These of dispersed teams creates problems for project success.
challenges (8-15) referred to the specific problems of manag- Communication and team coordination among the mem-
ing requirements in Agile projects or using them for purposes bers is particularly challenging in these teams [45], [46].
like estimation or prioritization. Iqbal et al. [41] use a Delphi study to understand the chal-
The fourth theme was user stories and contained those lenges to requirements engineering in outsourced software
challenges that referred specifically to this requirements development projects and find that the most common chal-
artifact (16-18). lenge is related to the communication among project teams,
The final theme was about the role of requirements during stakeholders, and customers. An example of such challenges
testing in Agile projects (19-20). is when stakeholders are unable to express the requirements
VOLUME 10, 2022 119751

TABLE 3. List of requirements engineering challenges and the IDs of the papers in which they occur (see Table 1).
119752 VOLUME 10, 2022

TABLE 4. Thematic analysis of challenges to requirements in the missing. Gregory et al. [54] find that project teams struggle
reviewed papers.
to communicate the progress of development to the manage-
ment team. On the other hand, support from top management
improves the team’s acceptance of the Agile methodology
[33], [55], particularly if the management team promotes the
perceived benefits of using that methodology [56].
B. CHALLENGES RELATED TO CUSTOMER INVOLVEMENT

1) DIFFICULTY IN CUSTOMER INTERACTION
Interaction with the customer in each iteration of the Agile
methodology for software development is difficult [13]. This
is because customers are busy and are typically not available
in each iteration [11], [57]. Moreover, it takes more effort to
negotiate the requirements with multiple representatives of
the customer as it is challenging to unify the perspectives
of these representatives [58], and at times customers are
unaware of their own requirements [43], [59]. Also a very
high level of customer interaction can cause conflicts [60].
2) CUSTOMER INABILITY AND DISAGREEMENT

Customer inability refers to the incompetence of customers in
terms of decision-making and complete domain knowledge,
and customer disagreement is about the lack of consensus
among more than one customer group involved in a project
[12], [13], [16]. In this respect, Drury et al. [32] find that
customers cannot always communicate accurately what they
want to the project team. As Hess et al. [57] point out, the
communication gap happens due to a lack of documentation.
The disagreement between customer groups affects the team
performance [11].
clearly among themselves and to the team. Llyod et al. [47] C. CHALLENGES RELATED TO REQUIREMENTS QUALITY
argue that communication between the onshore and off- 1) DIFFICULTY IN ESTIMATING TIME AND COSTS
shore sites is a key challenge to Agile projects for software It is often difficult to estimate an accurate cost at the begin-
development. ning of the project [11], [13], [59]. Several researchers [13],
[61], [62] have shown that costs, resources, and time estima-
4) SHARING OF KNOWLEDGE tions are key challenges to Agile projects. A primary reason
Spreading the knowledge across the project team is a chal- for these challenges is that the initial estimation is based on
lenge [48]. Drury et al. [32] find that decisions are made on the set of user stories known at that time [13]. However, over
the incomplete understanding of functionality by the team. time the team adds new user stories that affect the resources,
Minimal documentation often reduces effective knowledge costs, and time required for the project. McHugh et al. [35]
transfer [3], [48], and the team members often lack motivation find that teams have difficulties in accurately estimating
to share their knowledge [49]. The use of short iterations, unknown tasks.
daily stand-up meetings, and the presence of customers onsite
reduces the amount of time for sharing ideas outside the 2) MINIMAL DOCUMENTATION
team [48]. In this context, Serrador and Pinto [50] show that Creating documentation is a challenge that many projects
having a clear goal of the project helps in successful project face [15], [54]. Ramesh et al. [11] mention that minimal
implementations. Yang et al. [51] argue that project teams documentation is a vital challenge that the Agile method-
often depend on tacit architectural knowledge, which is a ology poses to project teams. Lack of documentation raises
challenge. communication gaps, and the gaps are exacerbated by large
and global projects [22]. This is particularly acute in situ-
5) LACK OF MANAGEMENT INVOLVEMENT ations such as dispersed teams, large teams, and complex
Identifying and engaging managers in projects is a challenge projects [12]. Because of incomplete, inaccurate, or non-
[48], [52]. Dikert et al. [53] argue that due to a lack of existing documentation, teams often make decisions based
management involvement, high-level requirements are often on poor intelligence [32], [57]. Drury-Grogan et. al [63]
VOLUME 10, 2022 119753

find that the lack of documentation results in poor decisions 7) PRIORITIZING REQUIREMENTS
as teams have an incomplete understanding of the system’s In Agile projects, priorities change very fast, and these
functionalities. Similarly, using case studies, Saito et al. [64] changes affect software development [69], [70]. Prioritizing
suggest that undocumented knowledge in Agile projects the list of requirements is challenging as the list itself has to
for software development is an important long-term be flexible to reflect changing customer needs [37].
challenge.
8) INADEQUATE REQUIREMENTS VERIFICATION
3) INCOMPLETE NONFUNCTIONAL REQUIREMENTS
Consistency checking or formal inspections are seldom per-
Capturing nonfunctional requirements (NFRs) is a key chal-
formed during requirements engineering in Agile projects,
lenge to the use of the Agile methodology for software
which makes software development based on requirements
development [12], [14], [24], [45]. Inayat et al. [12] argue
lacking verification risky [11].
that user stories generally focus on system or product fea-
tures that ignore NFRs such as security and scalability.
Ramesh et al. [11] also mention this as a key challenge to D. CHALLENGES RELATED TO USER STORIES
producing requirements. 1) DETAILED USER STORIES NOT CREATED
Teams usually do not describe user stories in much detail.
4) INCOMPLETE AND MISSING REQUIREMENTS User stories may not be detailed enough to capture vulnera-
When the iterations are in large numbers, there is the pos- bilities, bugs, unexpected termination, and undefined behav-
sibility of missing important requirements [14]. High-level ior [62]. This is especially a problem when new members join
requirements are generally missing in Agile projects [53]. the project team [16].
This omission usually happens because of a lack of access to
all stakeholders and stakeholders’ inability to communicate
2) USER STORIES ARE NOT INTEGRATED
the requirements clearly [41].
Managing user stories is a challenge when their number is
large. Drury-Grogan et al. [63] find that linkages between
5) AMBIGUOUS REQUIREMENTS
user stories are difficult to maintain. Trkman et al. [25]
Dikert, Paasivaara, and Lassenius [53] argue that Agile suggest using business process models to better understand
projects for software development are especially complicated the dependencies among user stories as the models can
because of ambiguous requirements. They also find that the provide the missing context to better understanding those
tester often struggles to breakdown ambiguous requirements dependencies.
for testing. Torrecilla-Salinas et al. [65] show that the uncer-
tainty in definitions of requirements is a hindrance to projects.
3) DIFFICULTY IN DECOMPOSING USER STORIES
6) REQUIREMENTS VOLATILITY Teams often struggle to break down user stories to a size
Although changes in requirements are an inherent part of the that facilitates estimation [53], [65]. Those studies also show
Agile methodology, frequent changes can cause trouble for that such a task is especially complicated with ambiguous
the development team [12], [14]. These changes can increase requirements.
costs that thus lead to failure [22]. The teams generally strug-
gle to adapt to changes as there is a lack of tracking mech- E. CHALLENGES RELATED TO TESTING
anisms for change management [32]. Any documents that 1) AVAILABILITY OF TESTING RESOURCES
the team produces in the initial stages can quickly become The Agile methodology assumes that there is plenty of fast
irrelevant because the Agile principles encourage changes testing resources available in each iteration but this is gener-
in requirements [66]. Hess et al. [57] find that a sudden ally not true [62]. Although many projects have adopted TDD
change in requirements results in communication lapses. methods [71], the testing team often struggles to breakdown
Inayat et al. [12] find that increased communication and clear ambiguous requirements for testing [53].
specifications of requirements can resolve this issue. When a
new change affects the existing design, the user stories and
unit tests should be sufficient to address the change [67]. 2) REDUCING TESTING AND TEST COVERAGE
But Knauss [67] claims that as user stories represent a delta Getting the developers and testers to verify and to val-
of the requirements, collapsing all the deltas is insufficient idate the code is difficult. In this respect, Petersen and
for understanding the overall features of the system. He also Wohlin [37] find that the lack of independent verification
argues that this lack of understanding has a negative effect on affects the test coverage. They provide an example where
testing. In dispersed global software development projects, designers can influence testers to only focus on parts of the
management of changes in requirements is particularly system by arguing that the other parts do not need to be tested
challenging [47], [68]. as they did not touch those parts.
119754 VOLUME 10, 2022

F. OTHER CHALLENGES new challenge was added to the list of 22. In this analysis, the
1) INADEQUATE OR INAPPROPRIATE ARCHITECTURE interviewed practitioners identified three new challenges that
AND INTERFACES were not discussed in the literature review. They were lack
Architecture receives little attention in the Agile method- of vision in planning sprints, lack of domain and application
ology for software development that leads to bad design knowledge, and waterfall mindset in Agile. Thus, we ended
decisions [37]. Architectural decisions by the project team in up with 25 challenges in total. The interviews also confirmed
the early cycles often becomes redundant as they identify new the presence of 20 challenges (out of 22) that were identified
requirements and thus reworking the architecture increases in our literature review. For challenges 4 and 22, we did not
the project cost significantly [11], [16]. Also, the overall find support for in the interviews. The theme column for
architecture is hard to envision as understanding the depen- challenges 21, 22, and 25 was empty as these challenges
dencies of the parts of the system is difficult [37]. Because could not be grouped or categorized under a theme. The
eliciting the complete requirements upfront is a problem, then newly identified challenges 23 and 24 were categorized in
it becomes a considerable rework to design the interfaces of the project team theme.
the application at the later stages of development [24].
VI. DISCUSSION
2) EXTERNAL VISIBILITY ON PROJECT TASKS The previously mentioned literature review and survey stud-
McHugh et al. [35] find that making the project’s progress ies [11], [13] were published between 2010 and 2017.
visible to organizational members is difficult if they are All these studies identified challenges related to our themes
not part of the Agile team. The non-team members lack of customer involvement and requirements quality.
visibility of the statuses of the project tasks, and thus non- To investigate our general research question (i.e., How
team members are unaware of the reasons for their delays. can conceptual models address the challenges of require-
Fagerholm et al. [30] show that having clear communication ments engineering in the Agile methodology for software
with non-team members is important for project success. development without conflicting with its values?), we further
categorized the five themes that we had identified in the lit-
V. RESULTS OF THE INTERVIEWS erature review and confirmed through the interviews into two
Table 5 gives examples of the coding done on the inter- broad high-level themes: challenges to requirements engi-
view transcripts to identify the challenges to requirements neering related to human communication and collaboration
engineering. and challenges related to understanding and clarifying the
requirements.
TABLE 5. Samples of the coding of the challenges to requirements Challenges 1 to 5 and 23 to 24 are related to the project
engineering in the Agile methodology for software engineering. team theme, and challenges 6 and 7 are related to the cus-
tomer involvement theme. These challenges refer to obsta-
cles to effective requirements engineering that can be traced
back to problems in human communication and collaboration
that were observed in Agile projects. Challenges 8 to 15
are related to the requirements quality theme, and chal-
lenges 16 to 18 are related to the user stories theme. These
challenges are different as they refer directly to problems
with the requirements or their analysis or the user story tech-
nique as an artifact. We broadly categorized these challenges
as related to understanding and clarifying the requirements.
Further, we recognized the challenges related to testing
(i.e., 19 and 20) and the challenges not categorized by a theme
(i.e., 21, 22 and 25) as referring to other problems or obstacles
than those categorized by the two broad themes.
These two broad themes are also explicitly discussed in
the literature on the Agile methodology for software develop-
ment. Based on a qualitative survey, Schön et al. [15] find that
In Table 6, the theme column categorizes each challenge. enhancing collaboration between the stakeholders, develop-
The practitioner reference column identifies the interviewee ers, and end users is important, while building a shared under-
that made a statement related to that challenge – statements standing of requirements from the users’ perspective is not
are identified by the time passed since the start of the inter- very well established in Agile projects. Collaboration [4] and
view (e.g., E1 (6:56)). Note that several challenges were shared understanding [15] are essential to developing Agile
alluded to by more than one expert. projects. Too much collaboration is harmful while too little
If a statement by an interviewee indicated a challenge that is insufficient [4], [36]. The issue of collaboration becomes
was not already identified in the literature review, then that more critical when stakeholders including potential users are
VOLUME 10, 2022 119755

TABLE 6. Final list of challenges to requirements engineering in the Agile TABLE 6. (Continued.) Final list of challenges to requirements
methodology for software engineering. engineering in the Agile methodology for software engineering.
119756 VOLUME 10, 2022

TABLE 6. (Continued.) Final list of challenges to requirements TABLE 7. Linking the purpose of using conceptual models to the
engineering in the Agile methodology for software engineering. identified challenges to requirements engineering in the Agile
methodology for software development.
actively involved in developing Agile projects [15]. A lack

of collaborative tools was observed to be a hindrance for
sustained use of the Agile methodology [55].
In a case study on the Agile methodology, Moe et al. [72]
find that the project team lacked a shared mental model on
what the outcome of the project should be. Knowledge of the
big picture from project goals could be wrongly understood
by the stakeholders and the development teams [49]. As a
system consists of components which in turn change rapidly,
understanding the state of the system at any point of time can
be difficult [67]. Thus a deep understanding of the domain
and sharing that knowledge are crucial factors for the suc-
cess of Agile projects [22]. Managing requirements for inter-
dependent project teams is a challenge as it relates to the over-
all understanding and dependencies of the requirements [67].
When the domain knowledge is tacit and therefore difficult
to articulate and share with others, requirements may appear
unanalyzable and unstable [39]. Drury-Grogan et al. [63]
find that in Agile projects, poor decisions are made because
of an incomplete understanding of functionality. They argue
that these poor decisions happen because the necessary data
is lost, and decisions are forgotten because of the lack of
documentation. Insufficient and inappropriate understanding
of the requirements and quick changes in requirements are
the leading reasons for the failure of global Agile projects for
software development [41].
Coming back to the research question, conceptual models
facilitate communication between users and analysts and sup- address the challenges related to communication and domain
port the analysts’ understanding of the domain [73]. These understanding, the recommendations of how to incorporate
two model purposes directly refer to the two higher level conceptual modeling in Agile practices are quite varied and
themes that we identified in our analysis of the challenges inconsistent (e.g., ranging from informal models like mind
to requirements engineering in the Agile methodology for maps to more formal models like the use case diagrams in
software development, that is, human communication and UML). The literature review and the expert interviews did
collaboration and understanding and clarifying the require- not indicate that conceptual models were widely practiced
ments. Table 7 shows that potentially, 20 of the identified in Agile. Despite little priority in documenting the Agile
challenges (i.e., those related to the project team (1 – 5, 23, methodology, studies have discovered that Agile practitioners
24) customer involvement (6 - 7), requirements quality (8 – rate documentation as important and that too little docu-
15), and user stories (16 – 18) themes) can be addressed using mentation is available in their own projects [64]. Further,
conceptual models. the software documentation that is available is often incom-
plete, inconsistent, difficult to maintain, and in practice out
VII. HOW TO USE CONCEPTUAL MODELS IN of date [75]. Williams [17] reports that overall not much
THE AGILE METHODOLOGY? documentation is prepared in the Agile methodology. Given
The above discussion points out that although the research has that limited effort is spent on this documentation, for project
recognized the opportunities that conceptual models offer to team members to develop, maintain, and update conceptual
VOLUME 10, 2022 119757

models when sprints last only about two weeks is unrealistic, segments – ‘‘Given <precondition>, when <triggering
despite the potential benefits of using those models. event>, then <postcondition>’’ [19]. Using not just user
So, the question rises, how to use conceptual models in stories but also their associated BDD scenarios facili-
the Agile methodology? In this section we explore a vision tates the generation of a wider set of conceptual models,
on how to use conceptual models to address the challenges as we will illustrate in what follows. We focused on mul-
related to requirements engineering and management in the tiple types of conceptual models as a recent survey by
Agile methodology without contradicting its values. In our van der Linden et al. [74] has shown that different types of
exploration, we focus on our more specific research question UML diagrams and business process model and notation
(i.e., How can conceptual models address the challenges (BPMN) diagrams are the most common conceptual models
to requirements engineering in the Agile methodology for used in practice. Surveys also indicate that practitioners use
software development that are related to user stories?) by more than one conceptual model for different types of tasks
developing a tentative answer through a demonstration exper- [20]. This is because information systems are getting more
iment. We next present the feedback on this demonstration complex and interrelated models can be used to offer different
that were given by interview participants F1 to F11. We end perspectives of the system and represent different aspects
the section by reflecting on what is needed to provide more of it [76].
definite answers to the research questions that we investigated In our demonstration we focused on four types of concep-
in this explorative study. tual models whose information could be identified in user sto-
ries and their associated BDD scenarios. These four types of
A. GENERATING CONCEPTUAL MODELS FROM USER models were a use case model, domain model, state machine,
STORIES – A DEMONSTRATION EXPERIMENT and a process model. Using the concepts of actor and use
We believe some conditions need to be fulfilled to introduce case, a use case model provides a description of the users’
the use of conceptual models to the Agile methodology. This possible interactions with the system [77]. These interactions
methodology prefers using working software over documen- involve actions on objects that are described in a domain
tation, if conceptual models are created then they should model. The domain model thus shows the concepts that a
be created within the current framework of requirements system needs to process and store data on their relationships
engineering and not as an additional activity requiring extra and properties [78]. A state machine is a model that shows
effort. Simply, team members cannot be forced to create the different states that a single object, as an instance of
conceptual models as an additional activity. Therefore, the a domain concept described in the domain model, passes
creation of conceptual models must be automated to the through during its life in response to events [79]. A process
largest possible extent. As the Agile methodology promotes model has a description of the possible orderings of these
continuous development of the software, the conceptual mod- events and how they trigger actions on objects [80].
els should also be continuously updated such that they always For our demonstration, we used the set of related user
codify the most current domain knowledge as reflected by the stories in Table 8 as our example and consider them as written
requirements. for a software system that handles service requests.
In what follows, we demonstrate an example of the ele- Moreover, these segments of the user stories in
ments needed to construct conceptual models already being Table 8 were annotated with numbers so that these numbers
present in user stories. We also illustrate how conceptual could be used to trace the mapping from user stories to
models generated from user stories could be of use in Agile conceptual models.
projects. Also, other researchers have suggested that organiz- Figure 1 shows a use case model and a domain model that
ing user stories and extracting information from them can are based only on the information contained in the standard
be useful: ‘‘As a succinct, readily understandable descrip- user story template. The use case model shows that customer
tion, a user story could promote shared understanding of a and support assistant are the only two actors (i.e., roles in the
newly proposed CDS [Clinical Decision System] tool among user stories), and the actions that these two actors perform
diverse clinical and nonclinical stakeholders, resolving a (i.e., use cases) are the features specified in the user stories.
common challenge’’ (pp. 1346) [23]. Daneva et al. [22] find Thus, a use case model provides an overview of the roles and
that understanding the dependencies of the user stories is very related features described in a related set of user stories and
important in the Agile methodology. They suggest maintain- allows a visual grouping of user stories per role.
ing traceability between user stories all the time that facili- The domain model distinguishes among the objects to
tates the vision of how a high-level business process translates which the actions of the use case model are applied – in
into small chunks that are represented as user stories. our case this is just the service request. The different roles
User stories represent the bird’s eye view of how every- are related via their actions to the objects, clearly showing
thing fits together [63] in terms of requirements. The standard which role wants to perform which action on which object.
user story template is ‘‘As a <role>, I want <feature> so Like the use case model, the domain model only relies on
that <benefit>’’ [6]. We extend this template with behavior- the information captured by the role and features segments of
driven development (BDD) scenarios that consist of a feature the user stories but provides a clear visual overview of this
title, a user story, and a scenario that is defined by three information.
119758 VOLUME 10, 2022

TABLE 8. An example set of related user stories. cancel it before the support assistants have done their work.
Based on the use case model, a further discussion can be held
on which type of user can cancel service requests. Is only the
customer allowed to cancel service requests or is a support
assistant also allowed to cancel based on certain conditions
(e.g., when a customer repeatedly rejects the work performed
to resolve the service request as is clearly shown by the
resolve-reject loop in the state machine)?
Therefore, when the number of user stories increases, such
insights on the user expectations and hence system require-
ments can be difficult to obtain purely based on the textual
user stories themselves. Although the stakeholders might
have developed individual mental models of the domain to
be supported by the system, structured visual representations
(such as Figures 1 and 2) can help to align these mental
models consistently for all stakeholders. Further, the models
can also be used to obtain an overall understanding of the
requirements for members of the Agile team who join the
project in later stages.
B. FEEDBACK FROM EXPERTS

In this subsection, we also evaluate whether the usefulness
of conceptual models is acknowledged by expert practition-
ers of the Agile methodology. To understand the perceived
usefulness, interview participants F1 to F11 were asked how
the conceptual models could benefit the project team under
the assumption that these models would be made available
without the team having to invest effort in creating and
updating them. Specifically, we asked what benefits were
available from which type of conceptual model and whether a
particular role in the project team benefited more than the rest
Like Figure 1, the models in Figure 2 can be traced to of the team. The participants were shown the set of models
the user stories in Table 8. For example, the state machine (Figures 1 and 2) and the user stories (Table 8) but without
shows that the ‘‘accept action’’ changes the state of the service explaining to them how the models were obtained from the
request from submitted to open, and the ‘‘approve action’’ user stories.
changes the state of the service request from fixed to closed. Table 9 shows the analysis of the perceived benefits of
Similarly, the process model shows that the prerequisite of the the models as mentioned by the participants. We mapped
accept action is the ‘‘create action’’ (by the customer), and the these benefits to the challenges to requirements engineer-
prerequisite of the approve action is the ‘‘resolve action’’ (by ing that we identified earlier in the literature review and
the support assistant). To generate these two models, we also interviews. As most benefits could be mapped to challenges
need to document the pre- and postconditions in the BDD for which we proposed that conceptual models could help
scenarios of the user stories. (i.e., challenges 3, 4, 9, 11, 15, 16, 17, 18, 24; see Table 7), the
How can these models now help in improving communica- expert opinions provided empirical support for our proposed
tion and domain understanding? Let’s consider the following approach.
situation. It might not be clear to the project team when a
customer is allowed to cancel a service request (i.e., user C. REFLECTION
story 6). The state machine can provide a basis for discussion User stories are more than just an artifact of requirements.
among the team members and with the customer to clarify In the Agile methodology, teams plan and allocate user stories
what the actual expectation of the system is. The current for implementation (e.g., in Scrum they are a key element
interpretation obtained from the understanding of the state in composing the product/spring backlogs that detail the
machine is that cancellation of a service request is only implementation work to be performed). User stories thus
allowed before the service request is approved, however not decompose the system design into units whose implementa-
in the state of ‘‘open’’. So, in a state of open, cancellation is tion can be managed individually [8]. The conceptual models
not allowed, while it is in states of ‘‘submitted’’ and ‘‘fixed’’. generated from user stories do not focus on the individual user
Also, the process model shows that once the service request story but span a set of related user stories. These models are
is accepted, it needs to be resolved and the customer cannot not used for managing the implementation of each desired
VOLUME 10, 2022 119759

TABLE 9. Mapping of potential benefits of conceptual models.
119760 VOLUME 10, 2022

TABLE 9. (Continued.) Mapping of potential benefits of conceptual models.
system feature individually but provide a visual overview BDD scenarios, the completeness and consistency of the user
of dependencies and relationships between individual user stories is important. Quality problems with the user stories
stories which is hard to obtain just based on the text which will probably come to surface when the models are generated,
user stories basically comprise. The use case model and hence hidden quality problems might be discovered when
process model are types of conceptual models useful for analyzing the models (e.g., when the graph shown in the
analyzing requirements as we illustrated with the ‘‘cancel state machine is not connected or when an end event in the
service request’’ scenario that was sketched in the demon- process model cannot be reached from a start event). Third,
stration experiment. Other types of conceptual model, like the we demonstrated that four types of conceptual models can be
state machine and especially the domain model, can also be constructed using the information that is present in the user
useful for software design [9]. For instance, the business logic stories. We did not use other types of conceptual models, but
captured by user stories provides the basis for the domain they could certainly be explored in the future. For instance,
model that can, during software design activities, be fur- future studies could investigate if a goal model could be con-
ther extended to a class diagram. Here the advantage is that structed using the information in the benefit segment of the
software classes can be implemented with functionality that user stories. Fourth, if we had only used the original standard
relates to more than one user story that ensures an adequate template of user stories (without the BDD scenarios), then
modularization of the software. We did not explore this use it would not have been possible to construct the models that
of conceptual models in the demonstration experiment but, show and allow analyzing dependencies between user stories
for instance, referred to [81] who proposed a mapping of (i.e., the state machine and the process model).
user stories into agent-oriented and object-oriented software Regarding the example scenario for the validation and pos-
architectures. sibly further elicitation of the ‘‘cancel service request’’ user
Regarding the demonstration experiment, Figures 1 and 2 story, we note that this scenario illustrates how visual concep-
illustrate some things about the models. First, these models tual models like process models and use case models can help
are solely based on the information that is present in the address some of the challenges to requirements engineering
user stories and their associated BDD scenarios. Therefore, for the Agile methodology that were mapped to the purposes
some constructs that are usually found in these types of of using conceptual models in Table 7, like sharing of knowl-
conceptual models are absent (e.g., attributes in the domain edge, incomplete and missing requirements, and inadequate
model, extends and adds relationships between use cases in requirements verification. Mapping the purposes for using
the use case model). Second, to be an effective aid to commu- conceptual models to the high-level themes of the challenges
nication and domain understanding, the conceptual models to requirements engineering does not mean that the use of
must be syntactically correct and semantically accurate as conceptual models is equally useful for all challenges that are
well as provide a pragmatically relevant and understandable categorized in these themes. The benefits mentioned by the
representation of the domain. As these conceptual models are experts did not cover all those challenges. For instance, for
solely based on information captured in the user stories and challenges like lack of management involvement, difficulty
VOLUME 10, 2022 119761

FIGURE 1. Use Case Model and Domain Model based on the user stories.
in estimating time and costs, and incomplete nonfunctional Considering the conditions for using conceptual models
requirements, it would be harder to demonstrate the use- in the Agile methodology for software development that we
fulness of conceptual models. This usefulness also depends mentioned before, and as we now have demonstrated that
on the type of conceptual model generated from the user the information captured by a set of related user stories
stories. For instance, in our demonstration experiment, all six and BDD scenarios is sufficient to create different types of
user stories articulated desired system features that could be conceptual models that are used in other methods to develop
classified as functional requirements. In the case of nonfunc- software (e.g., RUP), a natural direction for future research
tional requirements (e.g., ‘‘As a customer, I want to have 90% is to recommend the automatic extraction of the conceptual
of my service requests resolved within 2 working days.’’), models from the set of user stories. For this purpose, appro-
whether the generation and use of other types of models are priate algorithms and tools need to be developed. Natural
possible could be explored (e.g., the NFR Framework for goal language processing (NLP) techniques could be a good fit
modeling and goal-oriented requirements engineering [82] for this purpose. Using this support, any time user stories
may help address the challenge incomplete nonfunctional change, the extraction and model generation could easily
requirements). be repeated to update the conceptual models. This way, the
119762 VOLUME 10, 2022

FIGURE 2. State Machine and Process Model based on the user stories.
members of the team could focus on writing user stories, from user stories (e.g., the visual narrator shows the concepts
while the conceptual models would be available to them to and relationships extracted from user stories [85]). A recent
support requirements engineering. The models could not only systematic literature review analyzed 38 different studies on
provide a basic documentation of the requirements to foster the application of NLP techniques to user stories, including
communication and shared domain understanding but could research on generating models from user stories [85], [86].
also help improve the completeness and consistency of the To the best of our knowledge, current NLP-based solutions
user stories and help verifying them. An early elaboration of for generating conceptual models from user stories apply
these ideas to demonstrate their feasibility is found in [83]. the original version of the user story template and not the
We note that some tools have already been developed version with BDD scenarios. We believe that the information
to generate conceptual models from textual descriptions of provided by the pre- and postconditions as captured in the
requirements (e.g., [84]). There are also a couple of tools BDD scenarios is essential for identifying, understanding,
that automatically extract specific types of conceptual models and analyzing the dependencies between user stories, as we
VOLUME 10, 2022 119763

showed with our demonstration. We have yet to come across document pre- and postconditions for the actions described
research on generating process models or state machines from in the user stories. This demonstration of the feasibility of
user stories. generating conceptual models from user stories, particularly
for models that allow understanding and analyzing dependen-
VIII. CONCLUSION cies between user stories, is another contribution of this paper.
In this paper, we have explored the use of conceptual models To the best of our knowledge, the generation of models using
to address the challenges to requirements engineering and information of BDD scenarios is novel.
management in software development. We started with a To automate now the generation of models, we suggest
literature review to update the current understanding of the relying on NLP techniques. The application of NLP tech-
challenges to requirements engineering for the Agile method- niques to user stories is not new (see [86] for a recently
ology. We also interviewed 16 seasoned practitioners of this published exhaustive review), and we experimented ourselves
methodology to validate and possibly extend the challenges with the idea in [83]. We suggest the further elaboration and
documented in the literature. In total, we identified 25 dif- exploration of that approach that could be guided by the
ferent challenges, which we discussed in the paper. This insights provided in our paper as a valuable and viable avenue
up-to-date overview is more extensive and detailed than the for further research on requirements engineering within the
challenges to requirements engineering discussed in other Agile context for software development.
studies [11], [14], which is the first contribution of our paper.
Next, to investigate our main research question, how can REFERENCES
conceptual models address the challenges of requirements [1] W. Cunningham. (2001). Manifesto for Agile Software Development.
engineering in the Agile methodology for software develop- [Online]. Available: http://agilemanifesto.org/
[2] L. Cao and I. Ramesh, ‘‘Agile requirements engineering practices: An
ment without conflicting with its values?, we performed a empirical study,’’ IEEE Software, vol. 25, no. 1, pp. 60–67, Jan. 2008.
thematic analysis of the challenges grouping 22 of them first [3] K. Conboy, ‘‘Agility from first principles: Reconstructing the concept
into 5 categories (i.e., project team, customer involvement, of agility in information systems development,’’ Inf. Syst. Res., vol. 20,
pp. 329–354, Sep. 2009.
requirements quality, user stories, testing) and next in one of [4] I. Inayat and S. S. Salim, ‘‘A framework to study requirements-driven col-
two higher order themes: challenges related to human com- laboration among agile teams: Findings from two case studies,’’ Comput.
munication and collaboration (i.e., project team and customer Hum. Behav., vol. 51, pp. 1367–1379, Oct. 2015.
[5] D. Leffingwell, Agile Software Requirements: Lean Requirements Prac-
involvement categories) and challenges related to understand- tices for Teams, Programs, and the Enterprise (Agile Software Develop-
ing and clarifying requirements (i.e., requirements quality ment Series). Boston, MA, USA: Addision-Wesley, 2011.
and user stories categories) that covered a total of 20 of [6] M. Cohn, User Stories Applied: For Agile Software Development. Boston,
MA, USA: Addison-Wesley, 2004.
the 25 identified challenges. For both types of challenges, [7] M. Murtazina and T. V. Avdeenko, ‘‘An ontology-based approach to sup-
the literature suggests that conceptual models can be helpful port for requirements traceability in agile development,’’ Proc. Comput.
as they promote both communication and collaboration, and Sci., vol. 50, pp. 628–635, Jan. 2019.
[8] A. R. Amna and G. Poels, ‘‘Ambiguity in user stories: A systematic litera-
shared domain understanding. ture review,’’ Inf. Softw. Technol., vol. 145, May 2022, Art. no. 106824.
The potential benefits of using conceptual models in the [9] J. A. Hoffer, J. F. George, and J. S. Valacich, Modern Systems Analysis and
Agile methodology are no guarantee that they will be adopted Design, 6th ed. London, U.K.: Pearson, 2011.
[10] Y. Wand and R. Weber, ‘‘Information systems and conceptual modeling:
by practitioners as the effort involved in creating models may A research agenda,’’ Inf. Syst. Res., vol. 13, no. 4, pp. 363–376, 2002.
contradict Agile values and principles. Therefore, we con- [11] B. Ramesh, L. Cao, and R. Baskerville, ‘‘Agile requirements engineering
tinued outlining the conditions for adoption of models – the practices and challenges: An empirical study,’’ Inf. Syst. J., vol. 20, no. 5,
pp. 449–480, Nov. 2007.
creation of models should fit within current requirements [12] I. Inayat, S. S. Salim, S. Marczak, M. Daneva, and S. Shamshirband,
engineering and management related activities in Agile ‘‘A systematic literature review on agile requirements engineering prac-
projects, should be automated, and models should be updated tices and challenges,’’ Comput. Hum. Behav., vol. 51, pp. 915–929,
Oct. 2015.
whenever requirements change.
[13] H. Elshandidy and S. Mazen, ‘‘Agile and traditional requirements engi-
To investigate how these conditions could be fulfilled, neering: A survey,’’ Int. J. Sci. Eng. Res., vol. 4, no. 9, pp. 473–482, 2013.
we focused on a second research question, how can con- [14] S. Alam, S. Nazir, S. Asim, and D. Amr, ‘‘Impact and challenges of
ceptual models address the challenges of requirements engi- requirement engineering in agile methodologies: A systematic review,’’ Int.
J. Adv. Comput. Sci. Appl., vol. 8, no. 4, pp. 411–420, 2017.
neering in the Agile methodology for software development [15] E. M. Schön, J. Thomaschewski, and M. J. Escalona, ‘‘Agile requirements
that are related to user stories?, considering that the user engineering: A systematic literature review,’’ Comput. Stand. Interface,
story is the main artifact used in the Agile methodology vol. 49, pp. 79–91, Jan. 2017.
[16] V. N. Vithana, ‘‘Scrum requirements engineering practices and challenges
and that the literature has shown the problems with using in offshore software development,’’ Int. J. Comput. Appl., vol. 116, no. 22,
and managing user stories (i.e., our challenges in the user pp. 43–49, Apr. 2015.
stories category). By means of a demonstration experiment, [17] L. Williams, ‘‘Agile software development methodologies and practices,’’
in Advances in Computers. Amsterdam, The Netherlands: Elsevier, 2010.
we showed that four types of conceptual model (i.e., use case [18] F. Anwer, S. Aftab, S. M. Shah, and U. Waheed, ‘‘Comparative analysis of
model, domain model, state machine, process model) can be two popular agile process models: Extreme programming and scrum,’’ Int.
constructed solely based on the information captured by a set J. Comput. Sci. Telecommun., vol. 8, no. 2, pp. 1–7, 2017.
[19] J. F. Smart, BDD in Action: Behavior-Driven Development for the Whole
of related user stories (e.g., epic or theme in Scrum) provided Software Lifecycle. Shelter Island, NY, USA: Manning Publications Com-
that the user stories are extended with BDD scenarios that pany, 2014.
119764 VOLUME 10, 2022

[20] J. Recker and P. F. Green, ‘‘How do individuals interpret multiple concep- [43] S. V. Shrivastava and U. Rathod, ‘‘Risks in distributed agile develop-
tual models? A theory of combined ontological completeness and overlap,’’ ment: A review,’’ Proc. Social Behav. Sci., Article, vol. 133, pp. 417–424,
J. Assoc. Inf. Syst., vol. 8, no. 8, pp. 1210–1241, 2019. May 2014.
[21] S. Sundararajan, M. Bhasi, and P. K. Vijayaraghavan, ‘‘Case study on [44] S. C. Misra, V. Kumar, and U. Kumar, ‘‘Identifying some important success
risk management practice in large offshore-outsourced agile software factors in adopting agile software development practices,’’ J. Syst. Softw.,
projects,’’ IET Softw., vol. 8, no. 6, pp. 245–257, 2014. vol. 82, no. 11, pp. 1869–1890, Nov. 2009.
[22] M. Daneva, E. van der Veen, C. Amrit, S. Ghaisas, K. Sikkel, R. Kumar, [45] M. Brhel, H. Meth, A. Maedche, and K. Werder, ‘‘Exploring principles of
N. Ajmeri, U. Ramteerthkar, and R. Wieringa, ‘‘Agile requirements prior- user-centered agile software development: A literature review,’’ Inf. Softw.
itization in large-scale outsourced system projects: An empirical study,’’ Technol., vol. 61, pp. 163–181, May 2015.
J. Syst. Softw., vol. 86, no. 5, pp. 1333–1353, May 2013. [46] W. Alsaqaf, M. Daneva, and R. Wieringa, ‘‘Quality requirements chal-
[23] V. Kannan, M. A. Basit, P. Bajaj, A. R. Carrington, I. B. Donahue, lenges in the context of large-scale distributed agile: An empirical study,’’
E. L. Flahaven, R. Medford, T. Melaku, B. A. Moran, L. E. Saldana, Inf. Softw. Technol., vol. 110, pp. 39–55, Jun. 2019.
D. L. Willett, J. E. Youngblood, and S. M. Toomay, ‘‘User stories as [47] D. Lloyd, R. Moawad, and M. Kadry, ‘‘A supporting tool for requirements
lightweight requirements for agile clinical decision support development,’’ change management in distributed agile development,’’ Future Comput.
J. Amer. Med. Inform. Assoc., vol. 26, no. 11, pp. 1344–1354, 2019. Informat. J., vol. 2, no. 1, pp. 1–9, 2017.
[24] W. Helmy, A. Kamel, and O. Hegazy, ‘‘Requirements engineering method- [48] K. Conboy and L. Morgan, ‘‘Beyond the customer: Opening the agile
ology in agile environment,’’ Int. J. Comput. Sci., vol. 9, no. 5, pp. 293–300, systems development process,’’ Inf. Softw. Technol., vol. 53, no. 5,
2012. pp. 535–542, May 2011.
[25] M. Trkman, J. Mendling, and M. Krisper, ‘‘Using business process models [49] R. P. Ghozali, H. Saputra, M. A. Nuriawan, Suharjito, D. N. Utama, and
to better understand the dependencies among user stories,’’ Inf. Softw. A. Nugroho, ‘‘Systematic literature review on decision-making of require-
Technol., vol. 71, pp. 58–76, Mar. 2016. ment engineering from agile software development,’’ Proc. Comput. Sci.,
[26] V. Braun and V. Clarke, ‘‘Using thematic analysis in psychology,’’ Quali- vol. 157, pp. 274–281, Jan. 2019.
tative Res. Psychol., vol. 3, no. 2, pp. 77–101, 2006. [50] P. Serrador and J. K. Pinto, ‘‘Does agile work?—A quantitative anal-
[27] A. L. Strauss and J. Corbin, Basics of Qualitative Research: Grounded ysis of agile project success,’’ Int. J. Project Manage., vol. 33, no. 5,
Theory Procedures and Techniques. Thousand Oaks, CA, USA: SAGE, pp. 1040–1051, Jul. 2015.
1990. [51] C. Yang, P. Liang, and P. Avgeriou, ‘‘A systematic mapping study on
[28] J. Recker, R. Holten, M. Hummel, and C. Rosenkranz, ‘‘How agile prac- the combination of software architecture and agile development,’’ J. Syst.
tices impact customer responsiveness and development success: A field Softw., vol. 111, pp. 157–184, Jan. 2016.
study,’’ Project Manage. J., vol. 48, no. 2, pp. 99–121, Apr. 2017. [52] G. K. Hanssen, ‘‘A longitudinal case study of an emerging software ecosys-
[29] K. Conboy, S. Coyle, X. Wang, and M. Pikkarainen, ‘‘People over pro- tem: Implications for practice and theory,’’ J. Syst. Softw., vol. 85, no. 7,
cess: Key challenges in agile development,’’ IEEE Softw., vol. 28, no. 4, pp. 1455–1466, Jul. 2012.
pp. 48–57, Jul. 2011.
[53] K. Dikert, M. Paasivaara, and C. Lassenius, ‘‘Challenges and success fac-
[30] F. Fagerholm, M. Ikonen, P. Kettunen, J. Münch, V. Roto, and
tors for large-scale agile transformations: A systematic literature review,’’
P. Abrahamsson, ‘‘Performance alignment work: How software developers
J. Syst. Softw., vol. 119, pp. 87–108, Sep. 2016.
experience the continuous adaptation of team performance in lean and agile
[54] P. Gregory, L. Barroca, H. Sharp, A. Deshpande, and K. Taylor, ‘‘The chal-
environments,’’ Inf. Softw. Technol., vol. 64, pp. 132–147, Aug. 2015.
lenges that challenge: Engaging with agile practitioners’ concern,’’ Inf.
[31] G. Alaa and G. Fitzgerald, ‘‘Re-conceptualizing agile information systems
Softw. Technol., vol. 77, pp. 92–104, Sep. 2016.
development using complex adaptive systems theory,’’ Emergence, Com-
[55] M. Senapathi and M. L. Drury-Grogan, ‘‘Refining a model for sustained
plex. Org., vol. 15, no. 3, pp. 1–23, 2013.
usage of agile methodologies,’’ J. Syst. Softw., vol. 132, pp. 298–316,
[32] M. Drury, K. Conboy, and K. Power, ‘‘Obstacles to decision making in
Oct. 2017.
agile software development teams,’’ J. Syst. Softw., vol. 85, pp. 1239–1254,
[56] L. Vijayasarathy and D. Turk, ‘‘Drivers of agile software development use:
Jun. 2012.
Dialectic interplay between benefits and hindrances,’’ Inf. Softw. Technol.,
[33] F. K. Y. Chan and J. Y. L. Thong, ‘‘Acceptance of agile methodologies: A
vol. 54, no. 2, pp. 137–148, Feb. 2012.
critical review and conceptual framework,’’ Decis. Support Syst., vol. 46,
no. 4, pp. 803–814, Mar. 2009. [57] A. Hess, P. Diebold, and N. Seyff, ‘‘Understanding information needs of
[34] B. Tessem, ‘‘Individual empowerment of agile and non-agile software agile teams to improve requirements communication,’’ J. Ind. Inf. Integr.,
developers in small teams,’’ Inf. Softw. Technol., vol. 56, pp. 873–889, vol. 14, pp. 3–15, Jun. 2019.
Aug. 2014. [58] S. Jayatilleke and R. Lai, ‘‘A systematic review of requirements change
[35] O. McHugh, K. Conboy, and M. Lang, ‘‘Agile practices: The impact on management,’’ Inf. Softw. Technol., vol. 93, pp. 163–185, Jan. 2018.
trust in software project teams,’’ IEEE Softw., vol. 29, no. 3, pp. 71–76, [59] D. Dönmez and G. Grote, ‘‘Two sides of the same coin–how agile software
May 2012. development teams approach uncertainty as threats and opportunities,’’ Inf.
[36] S. Adolph, P. Kruchten, and W. Hall, ‘‘Reconciling perspectives: Softw. Technol., vol. 93, pp. 94–111, Jan. 2018.
A grounded theory of how people manage the process of software devel- [60] N. Ramasubbu, A. Bharadwaj, and G. K. Tayi, ‘‘Software process diver-
opment,’’ J. Syst. Softw., vol. 85, no. 6, pp. 1269–1286, Jun. 2012. sity: Conceptualization, measurement, and analysis of impact on project
[37] K. Petersen and C. Wohlin, ‘‘A comparison of issues and advantages perfromance,’’ SSRN Electron. J., pp. 787–807, 2015.
in agile and incremental development between state of the art and an [61] A. S. Campanelli and F. S. Parreiras, ‘‘Agile methods tailoring—A system-
industrial case,’’ J. Syst. Softw., vol. 82, no. 9, pp. 1479–1490, Sep. 2009. atic literature review,’’ J. Syst. Softw., vol. 110, pp. 85–100, Dec. 2015.
[38] Y. Lindsjørn, D. I. K. Sjøberg, T. Dingsøyr, G. R. Bergersen, and T. Dybå, [62] R. Chapman, N. White, and J. Woodcock, ‘‘What can agile methods
‘‘Teamwork quality and project success in software development: A sur- bring to high-integrity software development? Considering the issues and
vey of agile development teams,’’ J. Syst. Softw., vol. 122, pp. 274–286, opportunities raised by agile practices in the development of high-integrity
Dec. 2016. software,’’ Commun. ACM, vol. 60, no. 10, pp. 38–41, 2017.
[39] S. Kudaravalli, H. Paris, S. Faraj, and S. L. Johnson, ‘‘A configural [63] M. L. Drury-Grogan, K. Conboy, and T. Acton, ‘‘Examining decision
approach to coordinating expertise in software development teams,’’ MIS characteristics & challenges for agile software development,’’ J. Syst.
Quart., vol. 41, no. 1, pp. 43–64, Jan. 2017. Softw., vol. 131, pp. 248–265, Sep. 2017.
[40] S. Sarker and S. Sarker, ‘‘Exploring agility in distributed information sys- [64] S. Saito, Y. Iimura, A. K. Massey, and A. I. Antón, ‘‘Discovering undoc-
tems development teams: An interpretive study in an offshoring context,’’ umented knowledge through visualization of agile software development
Inf. Syst. Res., vol. 20, no. 3, pp. 440–461, Sep. 2009. activities,’’ Requirements Eng., vol. 23, no. 3, pp. 381–399, Sep. 2018.
[41] J. Iqbal, R. B. Ahmad, M. Khan, S. Alyahya, M. H. N. Nasir, A. Akhun- [65] C. J. Torrecilla-Salinas, J. Sedeño, M. J. Escalona, and M. Mejías, ‘‘Esti-
zada, and M. Shoaib, ‘‘Requirements engineering issues causing software mating, planning and managing agile web development projects under
development outsourcing failure,’’ PLoS ONE, vol. 15, no. 4, Apr. 2020, a value-based perspective,’’ Inf. Softw. Technol., vol. 61, pp. 124–144,
Art. no. e0229785. May 2015.
[42] P. Heck and A. Zaidman, ‘‘A systematic literature review on quality criteria [66] A. De Lucia and A. Qusef, ‘‘Requirements engineering in agile software
for agile requirements specifications,’’ Softw. Quality J., vol. 26, no. 1, development,’’ J. Emerg. Technol. Web Intell., vol. 2, no. 3, pp. 212–220,
pp. 127–160, Mar. 2018. 2010.
VOLUME 10, 2022 119765

[67] E. Knauss, ‘‘The missing requirements perspective in large-scale agile [84] R. Mesquita, A. Jacqueira, C. Agra, M. Lucena, and F. Alencar,
system development,’’ IEEE Softw., vol. 36, no. 3, pp. 9–13, May 2019. ‘‘US2StarTool: Generation i∗ models from user stories,’’ in Proc. Int.
[68] T. Kamal, Q. Zhang, and M. A. Akbar, ‘‘Toward successful agile require- Workshop (iStar), 2015, pp. 1–6.
ments change management process in global software development: A [85] G. Lucassen, F. Dalpiaz, M. van der Werf, and S. Brinkkemper, ‘‘Visual-
client–vendor analysis,’’ IET Softw., vol. 14, no. 3, pp. 265–274, Jun. 2020. izing user story requirements at multiple granularity levels via semantic
[69] E. Bjarnason, K. Wnuk, and B. Regnell, ‘‘Are you biting off more than you relatedness,’’ in Conceptual Modeling ER, vol. 9974. Springer, 2016.
can chew? A case study on causes and effects of overscoping in large-scale [86] I. K. Raharjana, D. Siahaan, and C. Fatichah, ‘‘User stories and natural
software engineering,’’ Inf. Softw. Technol., vol. 54, no. 10, pp. 1107–1124, language processing: A systematic literature review,’’ IEEE Access, vol. 9,
Oct. 2012. pp. 53811–53826, 2021.
[70] A. Henriksen and S. A. R. Pedersen, ‘‘A qualitative case study on agile
practice and project success in agile software projects,’’ J. Mod. Project
Manag., vol. 5, no. 1, pp. 62–73, 2017.
[71] I. Nurdiani, J. Börstler, and S. A. Fricker, ‘‘The impacts of agile and lean
practices on project constraints: A tertiary study,’’ J. Syst. Softw., vol. 119, ABHIMANYU GUPTA is currently a full-time
pp. 162–183, Sep. 2016. Instructor at the Operations and IT Management
[72] N. B. Moe, T. Dingsøyr, and T. Dybå, ‘‘A teamwork model for understand- Department, Chaifetz School of Business, Saint
ing an agile team: A case study of a scrum project,’’ Inf. Softw. Technol., Louis University, and the Ph.D. degree with Ghent
vol. 52, no. 5, pp. 480–491, May 2010.
University. His research interests include con-
[73] C. H. Kung and A. Solvberg, ‘‘Activity modelling and behavior modelling
ceptual modeling, agile methodologies, and data
of information systems,’’ in Information Systems Design Methodologies:
Improving the Practice, T. W. Olle, H. G. Sol, and A. A. Verrijn-Stuart, analytics. He has over 17 years of corporate IT
Eds. Amsterdam, The Netherlands: North-Holland, 1986, pp. 145–171. experience.
[74] D. van der Linden, I. Hadar, and A. Zamansky, ‘‘What practitioners really
want: Requirements for visual notations in conceptual modeling,’’ Softw.
Syst. Model., vol. 18, no. 3, pp. 1813–1831, Jun. 2019.
[75] G. Garousi, V. Garousi-Yusifoğlu, G. Ruhe, J. Zhi, M. Moussavi, and
B. Smith, ‘‘Usage and usefulness of technical software documentation: An
industrial case study,’’ Inf. Softw. Technol., vol. 57, pp. 664–682, Jan. 2015. GEERT POELS is currently a Full Professor with
[76] M. A. J. Sabegh and J. Recker, ‘‘Combined use of conceptual models the Faculty of Economics and Business Admin-
in practice: An exploratory study,’’ J. Database Manage., vol. 28, no. 2, istration, Ghent University. His research interests
pp. 56–88, Apr. 2017. include the quality of conceptual models, concep-
[77] K. E. Kendall and J. E. Kendall, Systems Analysis and Design, 10th ed. tual modeling of service systems, and business
London, U.K.: Pearson, 2019. process architecture. He has published, such as
[78] K. M. Markham, J. J. Mintzes, and M. G. Jones, ‘‘The concept map as European Journal of IS, IEEE TRANSACTIONS ON
a research and evaluation tool: Further evidence of validity,’’ J. Res. Sci. SOFTWARE ENGINEERING, and other information sys-
Teaching, vol. 31, no. 1, pp. 91–101, Jan. 1994.
tems journals.
[79] A. Dennis, B. H. Wixom, D. Tegarden, and A. Dennis, Systems Analysis
and Design: An Object-Oriented Approach With UML, 5th ed. Hoboken,
NJ, USA: Wiley, 2015.
[80] J. Mendling and J. Recker, ‘‘Towards systematic usage of labels and icons
in business process models,’’ in Proc. 12th Int. Workshop Exploring Model.
Methods Syst. Anal. Design, Montpellier, France: CEUR, 2008, pp. 1–13.
PALASH BERA is currently an Associate Profes-
[81] S. Heng, M. Snoeck, and K. Tsilionis, ‘‘Generating a software architecture
out of user stories and BDD scenarios: Research agenda,’’ in Proc. 1st Int. sor at the Operations and IT Management Depart-
Workshop Agile Methods Inf. Syst. Eng. Leuven, Belgium: CEUR, 2022. ment, Chaifetz School of Business, Saint Louis
[82] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, Non-Functional Require- University. His research interests include empir-
ments in Software Engineering. Dordrecht, The Netherlands: Kluwer Aca- ical studies of information systems analysis, use
demic, 2000. of eye tracking, and design thinking. He has pub-
[83] A. Gupta, G. Poels, and P. Bera, ‘‘Creation of multiple models from lished in reputed journals, such as MIS Quarterly
user stories—A natural language processing approach,’’ in Proc. Entity and Information Systems Research.
Relationship (ER) Conf., in Lecture Notes in Computer Science, Salvador,
Bahia, Brazil, vol. 11787, 2019, pp. 47–57.
119766 VOLUME 10, 2022

Modelos Concepuales en Proyectos Agiles

Uploaded by

Copyright:

Available Formats

Modelos Concepuales en Proyectos Agiles

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelos Concepuales en Proyectos Agiles

Uploaded by

Copyright:

Available Formats

Received 22 September 2022, accepted 31 October 2022, date of publication 10 November 2022,

date of current version 17 November 2022.

Using Conceptual Models in Agile Software

Corresponding author: Abhimanyu Gupta ([email protected])

INDEX TERMS Agile software development, user stories, conceptual models.

I. INTRODUCTION Based on these values, Agile methods like Extreme Pro-

119746 VOLUME 10, 2022

VOLUME 10, 2022 119747

119748 VOLUME 10, 2022

TABLE 1. List of references used in Table 3.

VOLUME 10, 2022 119749

TABLE 1. (Continued.) List of references used in Table 3.

119750 VOLUME 10, 2022

A. CHALLENGES RELATED TO THE PROJECT TEAM

2) BREAKDOWN OF TEAM COMMUNICATION

VOLUME 10, 2022 119751

119752 VOLUME 10, 2022

B. CHALLENGES RELATED TO CUSTOMER INVOLVEMENT

2) CUSTOMER INABILITY AND DISAGREEMENT

VOLUME 10, 2022 119753

119754 VOLUME 10, 2022

VOLUME 10, 2022 119755

119756 VOLUME 10, 2022

actively involved in developing Agile projects [15]. A lack

VOLUME 10, 2022 119757

119758 VOLUME 10, 2022

B. FEEDBACK FROM EXPERTS

VOLUME 10, 2022 119759

TABLE 9. Mapping of potential benefits of conceptual models.

119760 VOLUME 10, 2022

TABLE 9. (Continued.) Mapping of potential benefits of conceptual models.

VOLUME 10, 2022 119761

119762 VOLUME 10, 2022

VOLUME 10, 2022 119763

119764 VOLUME 10, 2022

VOLUME 10, 2022 119765

119766 VOLUME 10, 2022

You might also like