Using Conceptual Models in Agile Software Development: A Possible Solution to Requirements Engineering Challenges in Agile Projects

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.


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

II. REQUIREMENTS ENGINEERING IN THE AGILE METHODOLOGY
One of the most difficult tasks in developing software is requirements engineering [16]. As a result, software development has used the Agile methodology as a management tool. The Agile methodology comprises a set of principles that values individuals and interactions over processes and similarly, prefers working software over documentation [1]. The Agile methodology prescribes an iterative and incremental development process in which the Agile team works closely with the customer [16]. The Agile methodology focuses on continuous and iterative improvement of the software development as driven by the actual experience of using the software [17]. Each iteration has phases of design, implementation, and testing as well as an requirements analysis [17].
To organize the Agile process, the team uses several methods such as Extreme Programming, Kanban, SAFe, and Scrum; Scrum is generally recognized as the most adopted method [16]. Scrum defines three roles for project teams: product owner, developer, and scrum master [16]. The scrum master guides and coaches the team to the proper understanding and use of Scrum. The product owner is responsible for managing the requirements and identifying the features to be implemented in the iterative development phases, also known as sprints [16], [18]. The implementation of the features is the responsibility of the developer.
In combination with methods such as Scrum, teams use several techniques such as behavior-driven development (BDD) and test-driven development (TDD) in the Agile methodology to organize the activities in requirements engineering. BDD comprises the use of user stories and acceptance criteria to specify a system's requirements [19]. In the TDD, the team writes tests before the developers produce the actual code, and this test writing is considered as part of the requirements engineering [4].
Using conceptual models in the Agile methodology is by itself not a novel idea. Recker and Green [20] have pointed out that although the Agile methodology has gained popularity recently, the use of conceptual models has not disappeared from software development. Some researchers suggest using even more documentation (including visual models) and tools in the Agile methodology. For instance, contrary to Agile practices, researchers have found that tacit knowledge is not sufficient and formal documentation is therefore necessary [21]. Vithana [16] argues that since formal documentation is missing, verification of requirements might not be adequately addressed. To alleviate the communication problems in Agile projects, Sundararajan et al. [21] suggest the creation of design documents for the overall architecture of the systems, the design of the database, and the interfacing needs of the systems. Daneva et al. [22] conduct a survey and find that the sharing of domain knowledge is an important characteristic for prioritizing requirements in Agile projects. Consequently, they suggest the introduction of the role of domain owner to the Agile team that is responsible for acquiring knowledge of the business processes. This knowledge is usually reflected in business process models.
Related to user stories, Kannan et al. [23] have proposed the use of use case diagrams in the UML that are obtained from user stories where each user story is represented as a use case. Based on a survey of the use of models, Schön et al. [15] finds that some organizations that use the Agile methodology are using use case diagrams, story cards (i.e. details of user stories), and mind maps to create shared understanding and getting potential users involved in the development process. Along a similar vein, Helmy et al. [24] argue that developing high-level domain models as part of the initial efforts at architectural modeling can guide both the design of the physical data model and class design. Trkman et al. [25] suggest that using business process models leads to a better understanding of the dependencies among user stories. In their systematic literature review, Amna and Poels [8] find 13 studies that propose the use of models for tackling problems related to the ambiguity in user stories. They also find that the literature has only validated a few of these proposed solutions. Further, the question of how to develop and use the models within an Agile project is still an open one.

III. METHODOLOGY
We conducted an exploratory study to investigate our research questions. Our study consisted of three steps. First, we conducted a literature review to identify current challenges to requirements engineering in Agile projects. The literature reviews and surveys [11], [14] indicated that in spite of the popularity of applying the Agile methodology to software development, there were key challenges in eliciting, documenting, analyzing, verifying, and validating requirements in these projects. Some of these studies reviewed research papers published in the early development of Agile when its use was not yet common. As of today, the Agile methodology is used extensively in software development which is an area that has increased in complexity (e.g., global software development) [16]. Therefore, the verification of whether the challenges to requirements engineering that these past reviews and surveys have identified are still relevant and whether studies or practitioners have found new challenges in the development of Agile.
As a second step we conducted semi-structured interviews with experienced practitioners of the Agile methodology to validate the challenges identified by the literature and to identify new ones it had not uncovered. In these interviews we also focused specifically on the practice of describing requirements with user stories. The synthesized list of literaturebased and interview-based challenges was then mapped for the purpose of using conceptual models to provide some initial insights into the answers to the research questions.
As a third and last step, we reflected on the conditions that needed to be met for using conceptual models in the Agile methodology. To further explore the answers to our research questions, we then demonstrated how the information captured in user stories could be used to generate conceptual models, and how these models could then be useful for addressing the identified challenges. To evaluate whether expert practitioners of the Agile methodology would also perceive this process as useful, we continued some of the interviews of the second step by showing the example set of related user stories and the models generated from them and asking the participants how they thought these models could benefit the analysis of requirements.

A. LITERATURE REVIEW
To update the current knowledge of the challenges that Agile faces in requirements engineering, we performed a systematic search of papers published in the academic journals in the Elsevier and Science Direct libraries. These libraries include numerous field journals that frequently publish peer-reviewed papers related to software development (e.g., Journal of Systems and Software, Information and Software Technology, IEEE Software, and Software Quality Journal). They also contain the flagship journals of the broader field of software engineering and information systems (e.g., MIS Quarterly and Information Systems Research).
To manage the scope of the literature review and effort required to analyze papers, we searched for those that explicitly discussed the challenges to requirements engineering for the Agile methodology. In other words, we did not intend to review all published work on the Agile but to look ourselves for elements that could be interpreted as challenges to engineering and managing requirements that could also introduce a certain degree of subjectivity. To search for papers, we built search strings that contained the words ''agile'', ''requirement(s)'', and ''challenge(s)''. The ''challenges'' searches used three synonyms ''difficulties'', ''obstacles'', and ''hindrances'' (and the singular version of these plural words) as alternates. As agile is a term also used in other domains, we added ''software'' or ''information systems'' to these search strings to focus exclusively on papers related to the development of software or information systems.
Our searches were performed at the end of 2020 and were limited to the most recent 11 full years from 2009-2019. The automated search returned 865 papers. Our inclusion criteria for the review were ''peer-reviewed papers'' (e.g., excluding book reviews and editorials) and ''relevancy''. The latter criterion was evaluated by reading the papers' abstracts and verifying whether the term ''agile'' referred to software development and its challenges (or difficulties, obstacles, etc.) while also referring to requirements engineering related activities or concerns. The exclusion criteria used language (only papers in English) and when the full text of the paper was not available. After verifying these criteria, 57 papers were selected for further analysis (see Table 1 for the full references of these papers).
The analysis itself involved extracting the challenges to requirements engineering discussed in the papers. Next, a unified list of these challenges was compiled. As we ended up with a list of 22 challenges, much longer than the 8 challenges in each of the previously mentioned reviews [11], [14], we decided to group challenges into several themes in our analysis. The thematic analysis [26] is a qualitative data method that relies on coding techniques to make sense of the data and discover underlying themes. Although these coding techniques are like those used in the grounded theory method [27], the thematic analysis does not aim at constructing hypotheses about phenomena observed in the data. We took a reflexive and inductive approach to the thematic analysis by using the open coding technique that has no a priori theoretical definition of the themes to guide the coding and summarization process.

B. INTERVIEWS
Practitioners of the Agile methodology were interviewed to validate the identified challenges to requirements engineering found in the literature and to identify any new ones not mentioned in the papers that were reviewed. We looked for practitioners that should be knowledgeable about these challenges due to their expertise and experience. To get access to these practitioners, we used a convenience sampling method. We searched for members of the Agile community on LinkedIn and based on their profiles, selected members that had at least five years of experience working with Agile, described themselves as a senior business analyst or a technologist, and that had served on Agile teams in different roles.
Interviews were conducted using a semi-structured interview protocol. The first guiding question was: ''What challenges do you face with requirements in terms of using Agile for software development?'' Based on our second research question, as the use of user stories is the most popular requirements artifact in the Agile methodology, we introduced a second question on user stories: ''What challenges do you face with the development and management of user stories in the Agile methodology?'' Finally, we demonstrated a set of models generated from an example set of user stories to 11 of the interview participants (F1 to F11) -we did not consider doing this in the five first interviews which was the reason why we only got 11 expert opinions. We then asked them to comment on the benefits such models would add to the requirements analysis in Agile if they were available. In total we recruited 16 participants to interview ( Table 2). The first five interviewees (who were not shown the models generated for the demonstration) were coded with IDs E1 to E5, and the later 11 interviewees were coded with IDs F1 to F11.
The average length of for the first half of the interviews was 20 minutes (i.e., Agile challenges) and 22 minutes for the second half of the interviews (i.e., model benefits). All interviews were recorded, and transcripts were generated. For each statement, words or phrases related to what could be identified as challenges or benefits were identified. Table 3 contains the list of 22 challenges to requirements engineering and the papers that mention them. Some challenges were found in just one or a few papers but often   there were several papers mentioning the same challenge, up to a maximum of 11. The thematic analysis resulted in five overarching themes: project team, customer involvement, requirements quality, user stories, and testing.

IV. RESULTS OF THE LITERATURE REVIEW
If a challenge was associated with requirements engineering or management issues that related to project teams, their management, or any specific role within the team (e.g., Scrum master, product owner); then this challenge was categorized in the project team theme. There were five challenges identified in this theme (1)(2)(3)(4)(5).
If a challenge related to the involvement of customers in requirements processes, then it was categorized in the customer theme. We found two challenges under this theme (6)(7).
Challenges related to analyzing or verifying requirements were categorized in the requirements quality theme. These challenges (8)(9)(10)(11)(12)(13)(14)(15) referred to the specific problems of managing requirements in Agile projects or using them for purposes like estimation or prioritization.
The fourth theme was user stories and contained those challenges that referred specifically to this requirements artifact (16)(17)(18).
The final theme was about the role of requirements during testing in Agile projects (19)(20).
Two challenges, (21) external visibility on project tasks, and (22) inadequate or inappropriate architecture and interfaces 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]; therefore, 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 (e.g., turnover of personnel) then lack of documentation leads to the inability to scale the software, evolve the application over time, and to add new members to the development team. As Agile projects do not scale well, it requires much more effort in team coordination [37], [38]. This coordination is particularly difficult when the developer uses the outsourcing model [21], [39] or disperses the project team [4], [40], [41]. Heck and Zaidman [42] argue that using collaborative tools facilitates team coordination.

3) DIFFICULTY IN MANAGING DISPERSED TEAMS
Due to the globalization of software-intensive, hightechnology businesses, developers are building Agile projects that involve teams in different geographic locations and time zones [43]. In a survey, Misra et al. [44] find that the use of dispersed teams creates problems for project success. Communication and team coordination among the members is particularly challenging in these teams [45], [46]. Iqbal et al. [41] use a Delphi study to understand the challenges to requirements engineering in outsourced software development projects and find that the most common challenge is related to the communication among project teams, stakeholders, and customers. An example of such challenges is when stakeholders are unable to express the requirements TABLE 3. List of requirements engineering challenges and the IDs of the papers in which they occur (see Table 1). 119752 VOLUME 10, 2022 clearly among themselves and to the team. Llyod et al. [47] argue that communication between the onshore and offshore sites is a key challenge to Agile projects for software development.

4) SHARING OF KNOWLEDGE
Spreading the knowledge across the project team is a challenge [48]. Drury et al. [32] find that decisions are made on the incomplete understanding of functionality by the team. Minimal documentation often reduces effective knowledge transfer [3], [48], and the team members often lack motivation to share their knowledge [49]. The use of short iterations, daily stand-up meetings, and the presence of customers onsite reduces the amount of time for sharing ideas outside the team [48]. In this context, Serrador and Pinto [50] show that having a clear goal of the project helps in successful project implementations. Yang et al. [51] argue that project teams often depend on tacit architectural knowledge, which is a challenge.

5) LACK OF MANAGEMENT INVOLVEMENT
Identifying and engaging managers in projects is a challenge [48], [52]. Dikert et al. [53] argue that due to a lack of management involvement, high-level requirements are often missing. Gregory et al. [54] find that project teams struggle to communicate the progress of development to the management 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].

C. CHALLENGES RELATED TO REQUIREMENTS QUALITY 1) DIFFICULTY IN ESTIMATING TIME AND COSTS
It is often difficult to estimate an accurate cost at the beginning of the project [11], [13], [59]. Several researchers [13], [61], [62] have shown that costs, resources, and time estimations are key challenges to Agile projects. A primary reason for these challenges is that the initial estimation is based on the set of user stories known at that time [13]. However, over time the team adds new user stories that affect the resources, costs, and time required for the project. McHugh et al. [35] find that teams have difficulties in accurately estimating unknown tasks.

2) MINIMAL DOCUMENTATION
Creating documentation is a challenge that many projects face [15], [54]. Ramesh et al. [11] mention that minimal documentation is a vital challenge that the Agile methodology poses to project teams. Lack of documentation raises communication gaps, and the gaps are exacerbated by large and global projects [22]. This is particularly acute in situations such as dispersed teams, large teams, and complex projects [12]. Because of incomplete, inaccurate, or nonexisting documentation, teams often make decisions based on poor intelligence [32], [57]. Drury-Grogan et. al [63] VOLUME 10,2022 find that the lack of documentation results in poor decisions as teams have an incomplete understanding of the system's functionalities. Similarly, using case studies, Saito et al. [64] suggest that undocumented knowledge in Agile projects for software development is an important long-term challenge.

3) INCOMPLETE NONFUNCTIONAL REQUIREMENTS
Capturing nonfunctional requirements (NFRs) is a key challenge to the use of the Agile methodology for software development [12], [14], [24], [45]. Inayat et al. [12] argue that user stories generally focus on system or product features that ignore NFRs such as security and scalability. Ramesh et al. [11] also mention this as a key challenge to producing requirements.

4) INCOMPLETE AND MISSING REQUIREMENTS
When the iterations are in large numbers, there is the possibility of missing important requirements [14]. High-level requirements are generally missing in Agile projects [53]. This omission usually happens because of a lack of access to all stakeholders and stakeholders' inability to communicate the requirements clearly [41].

5) AMBIGUOUS REQUIREMENTS
Dikert, Paasivaara, and Lassenius [53] argue that Agile projects for software development are especially complicated because of ambiguous requirements. They also find that the tester often struggles to breakdown ambiguous requirements for testing. Torrecilla-Salinas et al. [65] show that the uncertainty in definitions of requirements is a hindrance to projects.

6) REQUIREMENTS VOLATILITY
Although changes in requirements are an inherent part of the Agile methodology, frequent changes can cause trouble for the development team [12], [14]. These changes can increase costs that thus lead to failure [22]. The teams generally struggle to adapt to changes as there is a lack of tracking mechanisms for change management [32]. Any documents that the team produces in the initial stages can quickly become irrelevant because the Agile principles encourage changes in requirements [66]. Hess et al. [57] find that a sudden change in requirements results in communication lapses. Inayat et al. [12] find that increased communication and clear 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]. But Knauss [67] claims that as user stories represent a delta of the requirements, collapsing all the deltas is insufficient for understanding the overall features of the system. He also argues that this lack of understanding has a negative effect on testing. In dispersed global software development projects, management of changes in requirements is particularly challenging [47], [68].

7) PRIORITIZING REQUIREMENTS
In Agile projects, priorities change very fast, and these changes affect software development [69], [70]. Prioritizing the list of requirements is challenging as the list itself has to be flexible to reflect changing customer needs [37].

8) INADEQUATE REQUIREMENTS VERIFICATION
Consistency checking or formal inspections are seldom performed during requirements engineering in Agile projects, which makes software development based on requirements lacking verification risky [11].

D. CHALLENGES RELATED TO USER STORIES 1) DETAILED USER STORIES NOT CREATED
Teams usually do not describe user stories in much detail. User stories may not be detailed enough to capture vulnerabilities, bugs, unexpected termination, and undefined behavior [62]. This is especially a problem when new members join the project team [16].

2) USER STORIES ARE NOT INTEGRATED
Managing user stories is a challenge when their number is large. Drury-Grogan et al. [63] find that linkages between user stories are difficult to maintain. Trkman et al. [25] suggest using business process models to better understand the dependencies among user stories as the models can provide the missing context to better understanding those dependencies.

3) DIFFICULTY IN DECOMPOSING USER STORIES
Teams often struggle to break down user stories to a size that facilitates estimation [53], [65]. Those studies also show that such a task is especially complicated with ambiguous requirements.

E. CHALLENGES RELATED TO TESTING 1) AVAILABILITY OF TESTING RESOURCES
The Agile methodology assumes that there is plenty of fast testing resources available in each iteration but this is generally not true [62]. Although many projects have adopted TDD methods [71], the testing team often struggles to breakdown ambiguous requirements for testing [53].

2) REDUCING TESTING AND TEST COVERAGE
Getting the developers and testers to verify and to validate the code is difficult. In this respect, Petersen and Wohlin [37] find that the lack of independent verification affects the test coverage. They provide an example where designers can influence testers to only focus on parts of the system by arguing that the other parts do not need to be tested as they did not touch those parts.

F. OTHER CHALLENGES 1) INADEQUATE OR INAPPROPRIATE ARCHITECTURE AND INTERFACES
Architecture receives little attention in the Agile methodology for software development that leads to bad design decisions [37]. Architectural decisions by the project team in the early cycles often becomes redundant as they identify new requirements and thus reworking the architecture increases the project cost significantly [11], [16]. Also, the overall architecture is hard to envision as understanding the dependencies of the parts of the system is difficult [37]. Because eliciting the complete requirements upfront is a problem, then it becomes a considerable rework to design the interfaces of the application at the later stages of development [24].

2) EXTERNAL VISIBILITY ON PROJECT TASKS
McHugh et al. [35] find that making the project's progress visible to organizational members is difficult if they are not part of the Agile team. The non-team members lack visibility of the statuses of the project tasks, and thus nonteam members are unaware of the reasons for their delays. Fagerholm et al. [30] show that having clear communication with non-team members is important for project success. Table 5 gives examples of the coding done on the interview transcripts to identify the challenges to requirements engineering. In Table 6, the theme column categorizes each challenge. The practitioner reference column identifies the interviewee that made a statement related to that challenge -statements are identified by the time passed since the start of the interview (e.g., E1 (6:56)). Note that several challenges were alluded to by more than one expert.

V. RESULTS OF THE INTERVIEWS
If a statement by an interviewee indicated a challenge that was not already identified in the literature review, then that new challenge was added to the list of 22. In this analysis, the interviewed practitioners identified three new challenges that were not discussed in the literature review. They were lack of vision in planning sprints, lack of domain and application knowledge, and waterfall mindset in Agile. Thus, we ended up with 25 challenges in total. The interviews also confirmed the presence of 20 challenges (out of 22) that were identified in our literature review. For challenges 4 and 22, we did not find support for in the interviews. The theme column for challenges 21, 22, and 25 was empty as these challenges could not be grouped or categorized under a theme. The newly identified challenges 23 and 24 were categorized in the project team theme.

VI. DISCUSSION
The previously mentioned literature review and survey studies [11], [13] were published between 2010 and 2017. All these studies identified challenges related to our themes of customer involvement and requirements quality.
To investigate our general research question (i.e., How can conceptual models address the challenges of requirements engineering in the Agile methodology for software development without conflicting with its values?), we further categorized the five themes that we had identified in the literature review and confirmed through the interviews into two broad high-level themes: challenges to requirements engineering related to human communication and collaboration and challenges related to understanding and clarifying the requirements.
Challenges 1 to 5 and 23 to 24 are related to the project team theme, and challenges 6 and 7 are related to the customer involvement theme. These challenges refer to obstacles 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 challenges 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 technique 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 development. Based on a qualitative survey, Schön et al. [15] find that enhancing collaboration between the stakeholders, developers, and end users is important, while building a shared understanding of requirements from the users' perspective is not very well established in Agile projects. Collaboration [4] and shared understanding [15] are essential to developing Agile projects. Too much collaboration is harmful while too little is insufficient [4], [36]. The issue of collaboration becomes more critical when stakeholders including potential users are VOLUME 10, 2022   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 success of Agile projects [22]. Managing requirements for interdependent project teams is a challenge as it relates to the overall 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 support the analysts' understanding of the domain [73]. These two model purposes directly refer to the two higher level themes that we identified in our analysis of the challenges to requirements engineering in the Agile methodology for software development, that is, human communication and collaboration and understanding and clarifying the requirements. Table 7 shows that potentially, 20 of the identified challenges (i.e., those related to the project team (1 -5, 23, 24) customer involvement (6 -7), requirements quality (8 -15), and user stories (16 -18) themes) can be addressed using conceptual models.

VII. HOW TO USE CONCEPTUAL MODELS IN THE AGILE METHODOLOGY?
The above discussion points out that although the research has recognized the opportunities that conceptual models offer to address the challenges related to communication and domain understanding, the recommendations of how to incorporate conceptual modeling in Agile practices are quite varied and inconsistent (e.g., ranging from informal models like mind maps to more formal models like the use case diagrams in UML). The literature review and the expert interviews did not indicate that conceptual models were widely practiced in Agile. Despite little priority in documenting the Agile methodology, studies have discovered that Agile practitioners rate documentation as important and that too little documentation is available in their own projects [64]. Further, the software documentation that is available is often incomplete, inconsistent, difficult to maintain, and in practice out of date [75]. Williams [17] reports that overall not much documentation is prepared in the Agile methodology. Given that limited effort is spent on this documentation, for project team members to develop, maintain, and update conceptual models when sprints last only about two weeks is unrealistic, despite the potential benefits of using those models.
So, the question rises, how to use conceptual models in the Agile methodology? In this section we explore a vision on how to use conceptual models to address the challenges related to requirements engineering and management in the Agile methodology without contradicting its values. In our exploration, we focus on our more specific research question (i.e., How can conceptual models address the challenges to requirements engineering in the Agile methodology for software development that are related to user stories?) by developing a tentative answer through a demonstration experiment. We next present the feedback on this demonstration that were given by interview participants F1 to F11. We end the section by reflecting on what is needed to provide more definite answers to the research questions that we investigated in this explorative study.

A. GENERATING CONCEPTUAL MODELS FROM USER STORIES -A DEMONSTRATION EXPERIMENT
We believe some conditions need to be fulfilled to introduce the use of conceptual models to the Agile methodology. This methodology prefers using working software over documentation, if conceptual models are created then they should be created within the current framework of requirements engineering and not as an additional activity requiring extra effort. Simply, team members cannot be forced to create conceptual models as an additional activity. Therefore, the creation of conceptual models must be automated to the largest possible extent. As the Agile methodology promotes continuous development of the software, the conceptual models should also be continuously updated such that they always codify the most current domain knowledge as reflected by the requirements.
In what follows, we demonstrate an example of the elements needed to construct conceptual models already being present in user stories. We also illustrate how conceptual models generated from user stories could be of use in Agile projects. Also, other researchers have suggested that organizing user stories and extracting information from them can be useful: ''As a succinct, readily understandable description, a user story could promote shared understanding of a newly proposed CDS [Clinical Decision System] tool among diverse clinical and nonclinical stakeholders, resolving a common challenge'' (pp. 1346) [23]. Daneva et al. [22] find that understanding the dependencies of the user stories is very important in the Agile methodology. They suggest maintaining traceability between user stories all the time that facilitates the vision of how a high-level business process translates into small chunks that are represented as user stories.
User stories represent the bird's eye view of how everything fits together [63] in terms of requirements. The standard user story template is ''As a <role>, I want <feature> so that <benefit>'' [6]. We extend this template with behaviordriven development (BDD) scenarios that consist of a feature title, a user story, and a scenario that is defined by three segments -''Given <precondition>, when <triggering event>, then <postcondition>'' [19]. Using not just user stories but also their associated BDD scenarios facilitates the generation of a wider set of conceptual models, as we will illustrate in what follows. We focused on multiple types of conceptual models as a recent survey by van der Linden et al. [74] has shown that different types of UML diagrams and business process model and notation (BPMN) diagrams are the most common conceptual models used in practice. Surveys also indicate that practitioners use more than one conceptual model for different types of tasks [20]. This is because information systems are getting more complex and interrelated models can be used to offer different perspectives of the system and represent different aspects of it [76].
In our demonstration we focused on four types of conceptual models whose information could be identified in user stories and their associated BDD scenarios. These four types of models were a use case model, domain model, state machine, and a process model. Using the concepts of actor and use case, a use case model provides a description of the users' possible interactions with the system [77]. These interactions involve actions on objects that are described in a domain model. The domain model thus shows the concepts that a system needs to process and store data on their relationships and properties [78]. A state machine is a model that shows the different states that a single object, as an instance of a domain concept described in the domain model, passes through during its life in response to events [79]. A process model has a description of the possible orderings of these events and how they trigger actions on objects [80].
For our demonstration, we used the set of related user stories in Table 8 as our example and consider them as written for a software system that handles service requests.
Moreover, these segments of the user stories in Table 8 were annotated with numbers so that these numbers could be used to trace the mapping from user stories to conceptual models. Figure 1 shows a use case model and a domain model that are based only on the information contained in the standard user story template. The use case model shows that customer and support assistant are the only two actors (i.e., roles in the user stories), and the actions that these two actors perform (i.e., use cases) are the features specified in the user stories. Thus, a use case model provides an overview of the roles and related features described in a related set of user stories and allows a visual grouping of user stories per role.
The domain model distinguishes among the objects to which the actions of the use case model are applied -in our case this is just the service request. The different roles are related via their actions to the objects, clearly showing which role wants to perform which action on which object. Like the use case model, the domain model only relies on the information captured by the role and features segments of the user stories but provides a clear visual overview of this information. Like Figure 1, the models in Figure 2 can be traced to the user stories in Table 8. For example, the state machine shows that the ''accept action'' changes the state of the service request from submitted to open, and the ''approve action'' changes the state of the service request from fixed to closed.
Similarly, the process model shows that the prerequisite of the accept action is the ''create action'' (by the customer), and the prerequisite of the approve action is the ''resolve action'' (by the support assistant). To generate these two models, we also need to document the pre-and postconditions in the BDD scenarios of the user stories.
How can these models now help in improving communication and domain understanding? Let's consider the following situation. It might not be clear to the project team when a customer is allowed to cancel a service request (i.e., user story 6). The state machine can provide a basis for discussion among the team members and with the customer to clarify what the actual expectation of the system is. The current interpretation obtained from the understanding of the state machine is that cancellation of a service request is only allowed before the service request is approved, however not in the state of ''open''. So, in a state of open, cancellation is not allowed, while it is in states of ''submitted'' and ''fixed''.
Also, the process model shows that once the service request is accepted, it needs to be resolved and the customer cannot 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 requirements 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 practitioners 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 of the team. The participants were shown the set of models (Figures 1 and 2) and the user stories (Table 8) but without explaining to them how the models were obtained from the user stories. Table 9 shows the analysis of the perceived benefits of the models as mentioned by the participants. We mapped these benefits to the challenges to requirements engineering that we identified earlier in the literature review and interviews. As most benefits could be mapped to challenges for which we proposed that conceptual models could help (i.e., challenges 3,4,9,11,15,16,17,18,24; see Table 7), the expert opinions provided empirical support for our proposed approach.

C. REFLECTION
User stories are more than just an artifact of requirements. In the Agile methodology, teams plan and allocate user stories for implementation (e.g., in Scrum they are a key element in composing the product/spring backlogs that detail the implementation work to be performed). User stories thus decompose the system design into units whose implementation can be managed individually [8]. The conceptual models generated from user stories do not focus on the individual user story but span a set of related user stories. These models are not used for managing the implementation of each desired  system feature individually but provide a visual overview of dependencies and relationships between individual user stories which is hard to obtain just based on the text which user stories basically comprise. The use case model and process model are types of conceptual models useful for analyzing requirements as we illustrated with the ''cancel service request'' scenario that was sketched in the demonstration experiment. Other types of conceptual model, like the state machine and especially the domain model, can also be useful for software design [9]. For instance, the business logic captured by user stories provides the basis for the domain model that can, during software design activities, be further extended to a class diagram. Here the advantage is that software classes can be implemented with functionality that relates to more than one user story that ensures an adequate modularization of the software. We did not explore this use of conceptual models in the demonstration experiment but, for instance, referred to [81] who proposed a mapping of user stories into agent-oriented and object-oriented software architectures.
Regarding the demonstration experiment, Figures 1 and 2 illustrate some things about the models. First, these models are solely based on the information that is present in the user stories and their associated BDD scenarios. Therefore, some constructs that are usually found in these types of conceptual models are absent (e.g., attributes in the domain model, extends and adds relationships between use cases in the use case model). Second, to be an effective aid to communication and domain understanding, the conceptual models must be syntactically correct and semantically accurate as well as provide a pragmatically relevant and understandable representation of the domain. As these conceptual models are solely based on information captured in the user stories and BDD scenarios, the completeness and consistency of the user stories is important. Quality problems with the user stories will probably come to surface when the models are generated, hence hidden quality problems might be discovered when analyzing the models (e.g., when the graph shown in the state machine is not connected or when an end event in the process model cannot be reached from a start event). Third, we demonstrated that four types of conceptual models can be constructed using the information that is present in the user stories. We did not use other types of conceptual models, but they could certainly be explored in the future. For instance, future studies could investigate if a goal model could be constructed using the information in the benefit segment of the user stories. Fourth, if we had only used the original standard template of user stories (without the BDD scenarios), then it would not have been possible to construct the models that show and allow analyzing dependencies between user stories (i.e., the state machine and the process model).
Regarding the example scenario for the validation and possibly further elicitation of the ''cancel service request'' user story, we note that this scenario illustrates how visual conceptual models like process models and use case models can help address some of the challenges to requirements engineering for the Agile methodology that were mapped to the purposes of using conceptual models in Table 7, like sharing of knowledge, incomplete and missing requirements, and inadequate requirements verification. Mapping the purposes for using conceptual models to the high-level themes of the challenges to requirements engineering does not mean that the use of conceptual models is equally useful for all challenges that are categorized in these themes. The benefits mentioned by the experts did not cover all those challenges. For instance, for challenges like lack of management involvement, difficulty in estimating time and costs, and incomplete nonfunctional requirements, it would be harder to demonstrate the usefulness of conceptual models. This usefulness also depends on the type of conceptual model generated from the user stories. For instance, in our demonstration experiment, all six user stories articulated desired system features that could be classified as functional requirements. In the case of nonfunctional requirements (e.g., ''As a customer, I want to have 90% of my service requests resolved within 2 working days.''), whether the generation and use of other types of models are possible could be explored (e.g., the NFR Framework for goal modeling and goal-oriented requirements engineering [82] may help address the challenge incomplete nonfunctional requirements).
Considering the conditions for using conceptual models in the Agile methodology for software development that we mentioned before, and as we now have demonstrated that the information captured by a set of related user stories and BDD scenarios is sufficient to create different types of conceptual models that are used in other methods to develop software (e.g., RUP), a natural direction for future research is to recommend the automatic extraction of the conceptual models from the set of user stories. For this purpose, appropriate algorithms and tools need to be developed. Natural language processing (NLP) techniques could be a good fit for this purpose. Using this support, any time user stories change, the extraction and model generation could easily be repeated to update the conceptual models. This way, the  members of the team could focus on writing user stories, while the conceptual models would be available to them to support requirements engineering. The models could not only provide a basic documentation of the requirements to foster communication and shared domain understanding but could also help improve the completeness and consistency of the user stories and help verifying them. An early elaboration of these ideas to demonstrate their feasibility is found in [83].
We note that some tools have already been developed to generate conceptual models from textual descriptions of requirements (e.g., [84]). There are also a couple of tools that automatically extract specific types of conceptual models from user stories (e.g., the visual narrator shows the concepts and relationships extracted from user stories [85]). A recent systematic literature review analyzed 38 different studies on the application of NLP techniques to user stories, including research on generating models from user stories [85], [86]. To the best of our knowledge, current NLP-based solutions for generating conceptual models from user stories apply the original version of the user story template and not the version with BDD scenarios. We believe that the information provided by the pre-and postconditions as captured in the BDD scenarios is essential for identifying, understanding, and analyzing the dependencies between user stories, as we showed with our demonstration. We have yet to come across research on generating process models or state machines from user stories.

VIII. CONCLUSION
In this paper, we have explored the use of conceptual models to address the challenges to requirements engineering and management in software development. We started with a literature review to update the current understanding of the challenges to requirements engineering for the Agile methodology. We also interviewed 16 seasoned practitioners of this methodology to validate and possibly extend the challenges documented in the literature. In total, we identified 25 different challenges, which we discussed in the paper. This up-to-date overview is more extensive and detailed than the challenges to requirements engineering discussed in other studies [11], [14], which is the first contribution of our paper.
Next, to investigate our main research question, how can conceptual models address the challenges of requirements engineering in the Agile methodology for software development without conflicting with its values?, we performed a thematic analysis of the challenges grouping 22 of them first into 5 categories (i.e., project team, customer involvement, requirements quality, user stories, testing) and next in one of two higher order themes: challenges related to human communication and collaboration (i.e., project team and customer involvement categories) and challenges related to understanding and clarifying requirements (i.e., requirements quality and user stories categories) that covered a total of 20 of the 25 identified challenges. For both types of challenges, the literature suggests that conceptual models can be helpful as they promote both communication and collaboration, and shared domain understanding.
The potential benefits of using conceptual models in the Agile methodology are no guarantee that they will be adopted by practitioners as the effort involved in creating models may contradict Agile values and principles. Therefore, we continued outlining the conditions for adoption of models -the creation of models should fit within current requirements engineering and management related activities in Agile projects, should be automated, and models should be updated whenever requirements change.
To investigate how these conditions could be fulfilled, we focused on a second research question, how can conceptual models address the challenges of requirements engineering in the Agile methodology for software development that are related to user stories?, considering that the user story is the main artifact used in the Agile methodology and that the literature has shown the problems with using and managing user stories (i.e., our challenges in the user stories category). By means of a demonstration experiment, we showed that four types of conceptual model (i.e., use case model, domain model, state machine, process model) can be constructed solely based on the information captured by a set of related user stories (e.g., epic or theme in Scrum) provided that the user stories are extended with BDD scenarios that document pre-and postconditions for the actions described in the user stories. This demonstration of the feasibility of generating conceptual models from user stories, particularly for models that allow understanding and analyzing dependencies between user stories, is another contribution of this paper. To the best of our knowledge, the generation of models using information of BDD scenarios is novel.
To automate now the generation of models, we suggest relying on NLP techniques. The application of NLP techniques to user stories is not new (see [86] for a recently published exhaustive review), and we experimented ourselves with the idea in [83]. We suggest the further elaboration and exploration of that approach that could be guided by the insights provided in our paper as a valuable and viable avenue for further research on requirements engineering within the Agile context for software development.