DEAR: DEtecting Ambiguous Requirements as a Way to Develop Skills in Requirement Specifications

Abstract

To improve requirement specification skills, it is vital to detect ambiguous requirements in order to correct them later. Thus, to help software engineering students improve their capacity to identify ambiguous user requirements (requirements that do not use technical words) while providing them with a valuable and engaging educational experience, the current study proposes a serious game called DEAR. It consists of a didactic exercise in which participants must move different requirements left or right to indicate whether they are ambiguous or unambiguous. To assess the improvement in students’ abilities in requirement specification and perceptions about the training class when using the DEAR game, we conducted an experiment with 62 participants, splitting them into two groups: one that used the DEAR game and the other that underwent a conventional training session. It was found that, during the training sessions, both groups became more adept at identifying unambiguous user requirements, but there was no discernible difference in performance between them. However, the game group expressed a stronger preference for the training session’s engagement and quality, as well as a stronger sense of having learned how to clearly define user requirements. Overall, the experiment shows that the suggested serious game DEAR may be a helpful teaching tool that yields learning outcomes comparable to those of a chalkboard class while encouraging students to identify unambiguous user requirements in an interactive manner.

1. Introduction

The University of Guayaquil’s software engineering degree program seeks to produce highly skilled individuals in the software development process [1]. In order to successfully design and create computer programs, one of the essential components of this process is to help students acquire the capacity to specify user requirements in a clear and concise manner [2,3]. Moreover, this is one of the initial steps in the software development process [4]. Because of this, the University of Guayaquil [1] offers the requirements engineering course as part of the introductory curriculum for those interested in a career in software engineering.

Natural language (NL) is widely used to specify requirements [5]. This makes them simple and understandable to stakeholders and software developers [6]. Because poor requirement definitions in NL entails fixing software design, line codes, testing, and deployment, among other things, the mistakes and misunderstandings (ambiguities) that occur during this process will be expensive to fix later in the software development process [7,8]. Additionally, this shortcoming may result in a lack of communication among members of the development team and, eventually, in the delivery of software products that fall short of end customers’ expectations and needs [8]. At the University of Guayaquil, software engineering students face difficulties in specifying unambiguous functional requirements [2]. To address the problem, it is vital for them to develop their skills in detecting ambiguous requirements in order to correct them later [5].

Additionally, the conventional teaching approach, consisting of theoretical classes and practical activities, has been shown to have limits in terms of student engagement and motivation [9]. These approaches do not always capture student attention. Furthermore, it does not provide an engaging learning environment or immediate feedback [10].

As in other fields [11,12,13,14,15,16,17], we can make use of information and communication technologies to improve the situation. In our case, this would involve the creation of a serious game that provides students with a joyful and engaging educational environment that promotes participation, continuous practice, and the acquisition of skills relevant to their future professional performance [18]. Serious games are defined as games that have a purpose other than entertainment [19]. They are intended for a variety of serious purposes [20], ranging from the development of skills in medicine [21], engineering [10], to raising awareness about relevant issues such as bullying and cyberbullying [22]. In the education field, serious games can support and complement traditional education schemes by increasing the participation and involvement of students [10].

Because of the aforementioned issues, this work covers the creation and use of a serious game called DEAR (available in [23]), which is intended to enhance student abilities to identify ambiguous user requirements. Detecting ambiguous requirements enables students to correct them later. To do this, DEAR provides feedback that indicates which aspects make a given requirement ambiguous.

The remaining sections of this paper are structured as follows: In Section 2, prior research relevant to this investigation is provided. Section 3 offers a concise overview of the proposed serious game DEAR. The results and discussion of using DEAR to develop the skill of detecting unambiguous user requirements in students are detailed in Section 4. Lastly, Section 5 encompasses the concluding remarks.

2. Related Works

It is well known that a requirement can be specified in the following ways [2]:

• User requirement: a requirement statement written in NL that is easy for stakeholders to comprehend and without the use of technical words.
• System requirement: a description of the technical requirements that are useful to the development team.

In this work, we will focus on the detection of ambiguity in user requirements (URs).

The importance of understanding how to specify clear URs is highlighted by the growing complexity of software systems. Support tools have been created by educators and researchers [8,18,24] in order to improve that ability. These provide a range of features to tackle diverse issues. To address the enhancement of that capacity to specify unambiguous URs [25], it is unclear what functionality should be supplied.

The approaches to enhance engineering education requirements in the context of teaching requirement specifications will be discussed in the lines that follow, along with the benefits of taking serious games into account.

2.1. Strategies for Teaching the Specification Requirements

This section will explore the instructional strategies utilized to help software students become more proficient in UR specifications. We shall consider the variety of teaching techniques and approaches applied in various academic environments.

The authors of the work [26] stressed the value of a hands-on approach while instructing students in UR specification. They advocated using hands-on activities and exercises that have students create and analyze actual URs. This enables them to obtain first-hand experience and put the learned theoretical principles into practice.

In [27], the authors provided a mechanism for eliciting URs. It takes into account the creation of user protocols and the application of manual techniques. They also provided a series of procedures for characterizing URs. Its approach, however, does not provide a reproducible framework for documentation. A procedural paradigm that permits the definition of functional needs was assumed in that work. Members of this technique define functional software requirements by working in teams. Members of the team gain good communication and collaborative work skills through teamwork, which helps to improve the comprehension and implementation of UR-related topics. This method promotes teamwork, critical thinking, and the application of theoretical information in real-world settings.

A different approach was suggested in [28]. That study employed a case study-based methodology that entails UR analysis in actual software projects. Students can benefit from the real-world experiences of other experts and obtain an understanding of typical issues by studying instances of success and failure in establishing requirements. This method encourages critical thinking and the application of information to novel contexts.

Three structures have been proposed recently in [2] for the clear expression of quantitative non-functional requirements (qt-NFRs) and functional requirements (FRs). Their initial suggested format, called “SURE”, was divided into three main parts: a title, a short definition, and a detailed description. The title and description of FRs may be defined with the use of the second suggested structure as a guide. Its basis is the application of CRUD operations to a particular object, known as the “CRUDE” structure. Finally, employing their third suggested structure as a model will make defining the descriptions and titles of qt-NFRs easier. The way system attributes are applied to computer events or operations is known as the “PROSE” structure. Giving the stakeholder the metric values they desire or anticipate is essential in this situation. The value of the three frameworks for helping students define clear criteria is highlighted by their evaluation scores.

In conclusion, several approaches have been put up to educate software students on how to describe URs. These methods include using visual modeling tools, project-based techniques, and hands-on approaches. These techniques include teaching through case studies, teaching through prototypes, problem-based learning, and teaching through structures (templates). The most suitable approach will be selected based on the learning objectives, student characteristics, and educational environment.

2.2. Utilizing Serious Games to Instruct Requirement Engineering

In an immersive setting, serious games provide students the chance to practice certain skills, encounter real-world scenarios, and receive quick feedback [29]. Even while serious games are nothing new when it comes to education, technology advancements have also prompted the creation of educational games that are digital and fit into a cultural context [30]. The usage of serious games as useful teaching aids for interactive engineering education requirements will be discussed in this part.

The authors of [31] suggested a serious game named “BARA” to lessen the effects of not including realistic stakeholders in the demand elicitation process. For assessment purposes and a comprehensive knowledge of the students’ performance and the efficacy of instruction, BARA automatically captures learner actions and mimics the behaviors of hypothetical stakeholders.

A proposed serious game named “EvacSIM” used virtual reality in [32] to help practice requirement elicitation on an Agent-Based Simulation (ABS). In order to ascertain and collect the requirements for an evacuation, the player takes on the role of a software engineer who interacts with relevant parties. The gathered data suggest that EvacSIM might be a feasible substitute for practicing requirement elicitation on ABSs.

In [33], the “EPC” Camshaft Game was proposed for working the preliminary identification of needs that are identified during early project meetings with the end users. In it, the player is required to build a camshaft that is able to work until the year 2050 with the lowest possible level of costs. The optimal evaluation manufacturing method and data integration strategy must be selected by the participant. The life duration and cost of the camshaft being produced are directly influenced by the production expenses represented by both options.

In [34], the authors proposed a serious game for the teaching of requirement elicitation and analysis, improving student understanding of the topic by applying the knowledge gained from lectures to several real-life scenarios provided in the game. It assigns to the player the task of gathering the requirements for a system that has to be created for the player who takes on the role of a requirement analyst. The player will ask non-player characters (NPCs) for the criteria.

In [35], a serious game called “RE-O-Poly” was proposed to raise awareness of RE best practices and to lay the groundwork for developing RE expertise. It had the advantage of reducing the time needed for game design and providing players with a familiar interface to reduce the start-up time for every gameplay session because it was based on the well-known board game Monopoly.

The creators of [36] suggested a serious game named “Requengin” to offer an interactive learning environment that would help students understand and apply the IEEE 29148-2011 standard [37]. This standard describes the steps used in the engineering process requirements and establishes guidelines for the related documentation. Enhancing the comprehension and execution of the standard’s core processes and some related engineering approach requirements was the main objective of the game.

The authors of [38] described a requirement elicitation technique that gathers the needs from stakeholders in a distributed software by using serious online games. Their main objective was to ascertain the beneficial effects of playing serious online games on the requirement elicitation work in distributed software projects. According to their findings, serious games make it easier for those with less experience to recognize a large number of requirements. These results also demonstrate that most participants—including those with less technical expertise—thought this approach was a convenient and pleasurable way to participate in requirement elicitation.

In summary, several studies have looked at the use of serious games to enhance knowledge of the requirements in documentation standards and to receive feedback from stakeholders. To the best of our knowledge, though, there is not a meaningful game that helps software engineering students become better at defining clear URs.

3. Research Questions and Hypothesis

Our primary research goal is to provide students with a valuable and engaging educational experience and to help them become more adept at identifying unclear URs so they can rewrite them later.

This paper concentrates on two main questions in addressing the primary research goal:

• R1. Does the DEAR game improve student ability to specify clear requirements compared to conventional training?
• R2. Will the DEAR game improve a student’s perception of the following: (A) the interactivity of the training session, (B) the ability to detect and specify unambiguous URs, and (C) the training session quality?

We handled two hypotheses:

• H1: The DEAR game significantly improves student ability to specify clear requirements compared to traditional methods.
• H2: The DEAR game improves a student’s perception of (A) the interactivity of the training session, (B) the ability to detect and specify unambiguous URs, and (C) the training session quality.

We will answer our research questions and examine whether our hypotheses are true in Section 5.

4. Materials and Methods

4.1. System Description

In this section, the technologies and the design of the proposed serious game DEAR, available in [23], is described. It helps the student acquire the ability to detect unambiguous URs and, in this way, to be able to correct them later.

4.1.1. Development Technologies

Unity was chosen over other platforms and languages such as Java FX and Python for several key reasons supported by the literature. According to [39], Unity significantly stands out in the development of serious games due to its cross-platform capability, allowing the creation of web and desktop applications, and its potential expansion to mobile platforms and consoles without the need to rewrite code. This is crucial for our project, which initially focuses on web and desktop implementations but could evolve to other devices.

In addition, Unity offers an integrated development environment with advanced visual tools and a powerful graphics engine, facilitating the creation of immersive and engaging environments, essential for an effective learning experience [40]. This platform also stands out for its active community of developers and its extensive documentation, providing solid technical support and the ability to integrate additional components according to the needs of the project [41].

In contrast, Java FX, which is limited primarily to desktop applications, and Python, although powerful for rapid development, are not optimized for creating games with advanced graphics and complex interactive experiences. Unity not only facilitates the integration of artificial intelligence elements that improve interaction and decision making within a game [41], but it also offers a standard interface and common controls that are easy to learn for any user, thus improving the accessibility and learning to use the Unity 3D engine [41].

4.1.2. Component Diagram

The component design for the proposed serious game DEAR is shown in Figure 1.

The descriptions of each component seen in Figure 1 are below.

• Requirement Reader: This is the component in charge of reading and processing the requirements that will be evaluated in the game. Its main function is to load the requirements from a csv file and validate the format.
• Game UI: This component is responsible for displaying the requirements to the player, providing visual and auditory feedback based on the player’s actions, as well as allowing navigation through different parts of the game, such as menus and settings.
• Game Manager: This is the core component that manages the logic and flow of the game. Its responsibilities include controlling the sequence of events and game states, implementing the rules of the game, validating player responses, and managing the scoring and progress throughout the game. Additionally, it coordinates communication between the Requirement Reader, the Game UI, and the Game Controller.
• Game Controller: This handles the player’s interactions with the game. This component captures and processes player input.

4.1.3. Serious Game Design

The serious game proposed in this work is called DEAR. The game consists of moving cards left or right. Each card contains a UR. Moving the card to the left will mark the requirement as ambiguous, while moving it to the right will mark it as unambiguous. If there is an error in the card classification, the game will present a feedback indicating the reasons why the requirement is incorrectly classified. The goal of the game is to classify cards as ambiguous or unambiguous with the minimum number of errors.

As can be seen in Figure 2, DEAR starts with a welcome screen where you can also change the language before starting the serious game. To change the language you must click on the “Change language” option and select Spanish or English. Spanish is loaded by default since DEAR is used by software engineering students at the University of Guayaquil, Ecuador. To start the game, just click on the “Play” option.

Once you have clicked on “Play”, you will see the screen presented in Figure 3. It gives instructions on how to play and what the objective of the game is. To continue you must click on the screen.

DEAR then presents cards located in the central area of the screen, as shown in Figure 4. Each of them contains a user requirement that must be classified as ambiguous or unambiguous. In addition, the score is shown in the upper left corner, while a help message about using the serious game is provided in the upper right corner. Finally, in the lower right corner there is a red button that allows you to close the serious game DEAR at any time.

To classify a user requirement as ambiguous, simply drag and drop it to the left, as shown in Figure 5. In this case, the letters of the word “ambiguous” in the left block will change color to yellow to give feedback on that movement.

Additionally, to classify a user requirement as unambiguous you will have to drag and drop it to the right, as shown in Figure 6. In this case, the letters of the word “unambiguous” in the right block will change color to yellow to give feedback on that movement.

If the user requirement represented in the card has been correctly classified, then the word “correct” will immediately appear in green text in the top center of the screen, as shown in Figure 7.

However, if the user requirement represented by the letter has been classified incorrectly, a whiteboard screen will appear to explain why it has been classified incorrectly, as shown in Figure 8.

Once all the cards have been classified, the number of cards classified correctly and incorrectly are presented, as shown in Figure 9. In addition, below the results, two buttons are presented, the one on the left allows you to play again while the on the right allows you to close the serious game DEAR.

4.1.4. Adding User Requirements to the Serious Game DEAR

The user requirements shown in the video game can be modified or added by the teacher. To do this, you must access the “requirements.csv” file located in the root directory of the unzipped serious game DEAR folder, as shown in Figure 10.

Within the “requirements.csv” file, we find a list of requirements to be used by the serious game DEAR. It follows a three-column structure, as shown in Figure 11. In the first column, the letter A is marked if the requirement is ambiguous and N if it is unambiguous. The second describes the requirement to be presented as a card within the serious game DEAR. Finally, the third column describes the feedback that is provided to the student in the event that the user requirement is incorrectly classified.

4.2. Experimental Design

To evaluate whether the ability to specify unambiguous URs was acquired by the software engineer students thanks to the use of the serious game DEAR, an experiment following the design described in Figure 12 was performed in a Requirements in Engineering class with the presence of a moderator who provided the initial instructions and guided the experiment.

Regarding the students, the selected sample corresponded to 62 students enrolled in two groups of RE courses offered at the University of Guayaquil in the first semester of 2024. The RE course is taught in the second year of the Software Engineering degree. Normally, six to eight RE groups are opened each semester, each with a maximum of 35 students. Seven RE groups were opened in the first semester of 2024. Thus, the selected sample ranged from 28.57% of the RE courses offered during that period. Furthermore, the majority of students were between the ages of 19–22. The distribution of men and women was 65% and 35% of the sample, respectively.

All sixty-two students had finished secondary education and were in the third semester of their Software Engineering degree at the University of Guayaquil. All students had also previously had substantial involvement with information and communication technology, both in the usage of electronic devices and programs such as Messenger, Whatsapp, etc. In addition, 15 students came from other cities, constituting 24.19% of the sample (62 students). It is significant to note that, in order to prevent survivorship bias—which happens when a survey is restricted to people who have been with the interviewers for an extended period of time—these groups did not have the authors of this manuscript as teachers.

Finally, among the limitations of this research we have the following: (1) the previous familiarity of the sixty-two students with similar games, and (2) the voluntary participation of the participants, given that all the students were selected from two groups of the RE courses taught in the software engineering degree program from the University of Guayaquil.

Regarding the experts, five specialists from the fields of software development and business management assessed the ambiguity in the URs specified by the students. To determine if any UR was ambiguous, the following points were checked by them:

• Does it generate a double interpretation?
• Does it define the application of any single task on the system?

For example, the UR “The system must send notifications quickly after an event occurs” is ambiguous because it does not define what events are considered “rapidly”, nor does it specify the type of notifications or what trigger the notifications. On the contrary, the UR “The system should send a confirmation email to users within 5 min of completing registration” is unambiguous because it defines the action of sending a confirmation email, specifies that it will be within 5 min of completing registration, and identifies the receivers.

It is enough that a UR does not comply with a criterion for it to be marked as ambiguous. A UR is classified as ambiguous if three or more experts have indicated it as ambiguous.

The steps represented in Figure 12 are detailed below.

• The student volunteers were divided into two groups, Group A and Group B, both with 31 students. Group A worked with DEAR while Group B learned through a blackboard class. In the blackboard class, 10 min was allocated to explain, using examples, those words and aspects that make a requirement ambiguous. Then, in the next 10 min, the students were asked if the requirements shown on the board were ambiguous or not.
• A diagnostic test (pre-test) was carried out in Groups A and B for 20 min. It consisted of describing 4 URs for a system that manage the distribution of drivers to vehicles to transport material from supplier warehouses to customers and managing payments.
• This was followed by training sessions for both groups. Group A use dthe serious game DEAR to train their skills in detecting ambiguous URs. Instructions for using the video game lasted 20 min. On the other hand, Group B received a 20 min lesson where they will be taught how to detect ambiguous URs.
• Then, Group A was subjected to a 20 min session with the serious game DEAR while Group B was subjected to a 20 min session of practical exercises for the detection of ambiguous URs. During this time, the students in both groups classified 50 URs as ambiguous or unambiguous. The feedback for each exercise was given by the video game in the case of Group A and by an answer and explanation sheet in the case of Group B.
• After training sessions, both groups were evaluated again with a second diagnostic test (post-test) for 20 min. It is important to mention that the results of both diagnostic tests were not shared with the students at any time.
• Finally, both groups were asked to fill out a survey to find out their perception of the training sessions.

5. Results and Discussion

The results of the experiment described in Section 4.2 and its subsequent analysis are presented below.

5.1. First Diagnostic Test

Figure 13 shows the outcomes of analyzing the URs specified by the selected sample of students before introducing the serious game DEAR (Group A) or the detection of ambiguous URs in a blackboard class (Group B) to them. It demonstrated that the majority of experts have regarded more than 110 URs—or more than 88% of the requirements specified by students—to be ambiguous, while they have deemed less than 10 URs to be clear (less than 8%).

As mentioned previously, the diagnostic test was collected by both students in Groups A and B. Some ambiguous URs, such as inserting data, managing accounts, generating reports, managing vehicles, and the main menu, were specified by the students. According to the results, we can conclude that the students of both groups started with a similar level of knowledge because a similar number of URs were specified in an ambiguous way according to the experts (119 for Group A and 115 for Group B). As a consequence, a similar number of uFRs were marked as unambiguous by experts (5 for Group A and 9 for Group B).

5.2. Second Diagnostic Test

After the training sessions, the students of both groups were required to complete the same task considered before training sessions, namely write 4 uFRs for a system that manages the distribution of drivers to vehicles to transport material from supplier warehouses to customers and managing payments.

Figure 14 shows the outcomes of analyzing the URs specified by the selected sample of students after interacting with the serious game DEAR (Group A) or the blackboard class (Group B). It demonstrates that the majority of experts have regarded more than 115 URs—or more than 92% of the requirements specified by the students—to be unambiguous, while they have deemed less than 10 uFRs to be unclear (less than 8%).

According to the results, a similar number of URs were marked as ambiguous by experts (9 for Group A and 5 for Group B). As a consequence, a similar number of URs were marked as unambiguous by experts (115 for Group A and 117 for Group B).

Answering the First Research Question (R1)

The first question (R1) was posed in Section 3. To answer it, we will analyze the improvement in the ability to specify URs in an unambiguous way in both groups (A and B). For it, we will compare the results obtained before and after the training sessions, which have been presented in Figure 13 and Figure 14. We see that, for the students in Group A, the number of ambiguous URs decreased from 119 to 9, while it decreased from 115 to 7 in Group B. In relative terms, Group A decreased the number of URs marked as ambiguous by experts by 92.43%, while Group B decreased it by 93.91%. We can conclude that the improvements obtained after the training sessions with and without the use of DEAR was similar, rejecting our first hypothesis (H1) of Section 3 about the existence of a significant improvement in student ability to specify clear requirements compared to traditional methods.

5.3. Student Perceptions on Their Training Session

With the purpose of evaluating the students’ perceptions regarding their acquired abilities to specify unambiguous URs and the training session’s interactivity and quality, a survey was carried out on the 62 students of the software career program at the University of Guayaquil (who voluntarily collaborated with the experiment) described at the beginning of this section. In it, five items ranging from 1 to 5 were scored on a Likert scale. The following values were represented by the numerals 1 through 5 (in that order): extremely dissatisfied, disappointed, acceptable, adequate, and excellent. When a certain attribute receives a score of three or above, it is deemed accepted. Understanding of the topic (A), Training session interactivity (B), Acquired ability to detect ambiguity (C), Acquired ability to specify unambiguous requirements (D), and Training session quality (E) were all assessed. The results of the survey conducted with the students are presented in Figure 15 and Figure 16. In both figures, we can see that they are populations with asymmetries in the same direction.

Answering the Second Research Question (R2)

The second question (R2) was posed in Section 3. To answer it, we validated whether there were significant differences between the perception results of both groups, and this was achieved via the Wilcoxon rank sum test, which was executed for each of the attributes (A–E) collected in the survey. These results are presented in

Table 1. Wilcoxon rank sum test with the results of the perception survey.

Evaluated Attribute	W Value	p-Value
(A) Understanding of the topic	525.5	0.4029
(B) Training session interactivity	716.5	0.00000226
(C) Acquired ability to detect ambiguity in URs	628	0.01072
(D) Acquired ability to specify unambiguous URs	715.5	0.000101
(E) Training session quality	606.5	0.01007

.

According to the results of the Wilcoxon test, there was a significant difference (a p-value less than 0.05) in attributes B, C, D, and E. These attributes refer to the student perceptions of the interactivity of the training session, their ability to detect and specify unambiguous URs, and the training session quality. Therefore, we can conclude that, according to the survey carried out, the students showed a greater preference regarding the use of the serious game DEAR as a teaching tool to make a learning session more interactive while showing a greater perception of having learned to specify unambiguous URs.

All in all, we can conclude that the students had a good perception of the use of serious game DEAR as an interactive learning tool for acquiring an ability to specify unambiguous URs, accepting our second hypothesis (H2) about an improvement in the students’ perception of the following: (A) the interactivity of the training session, (B) the ability to detect and specify unambiguous URs, and (C) the training session quality.

6. Conclusions

The main study objective of this work was to give students a worthwhile and interesting educational experience while improving their ability to recognize ambiguous URs so they may revise them later. For achieving this, the serious game DEAR was proposed. It is available at [23]. It consists of moving cards left or right to mark the requirement as ambiguous or as unambiguous, respectively. If there is an error in the card classification, the game presents feedback indicating the reasons why the requirement is incorrectly classified and facilitating the learning of requirement specification skills.

The core research objective gives rise to two fundamental questions: R1. When compared to traditional training, can the DEAR game help students become more adept at articulating unambiguous requirements?; and R2. Will the DEAR game enhance students’ perceptions of the following? (A) the training session’s interactivity, (B) their capacity to identify and describe clear URs, and (C) the training session’s quality.

To answer both questions, the application was evaluated from a qualitative and quantitative perspective by measuring the errors in the specification of functional user requirements and the perception of students when using the serious game DEAR to improve their skills in requirement specifications.

The set of results demonstrated a improvement by students when recognizing ambiguous requirements after exposing them to a game session and when the students underwent a blackboard class. The difference between the improvements obtained when detecting unambiguous requirements with and without the use of the serious game DEAR for their training session was not significant. However, significant differences were found in their perceptions of the interactivity of the training class and in their acquired abilities to detect and specify unambiguous user requirements. All in all, the results demonstrate that the proposed serious game DEAR can be useful when promoting software engineering students’ ability to specify unambiguous functional user requirements while adding interactivity to their training sessions.

As limitations, we wish to mention that the DEAR game was evaluated in only two of the seven requirements engineering groups, so we consider evaluating it on many more students as future work. Furthermore, in the future, we will consider extending DEAR to a multi-level game where other gamified activities are considered within the field of requirements in engineering.