Inglés (pdf)
Articulo en XML
Referencias del artículo
Traducción automática
Enviar articulo por email
Citado por SciELO 
Citado por Google 
Similares en
SciELO 
Similares en Google 
Permalink
I. INTRODUCTION
One of the critical phases in the software development life cycle, responsible for identifying, documenting, and developing the captured requirements, is known as Requirements Engineering (RE) [1]. In that sense, the correct elicitation of requirements is one of the most critical aspects of a software project, regardless of the type of project [2], since failing to do so can be the cause of the most common problems that arise throughout the life cycle of software development such as: misunderstandings between the analyst and the client, ambiguity in the documentation, poor time estimation, lack of business domain, incomplete requirements, among others [3]. Furthermore, as mentioned by Brooks in [4], no other part of the work performed in the life cycle affects the final product/service more negatively than if it is performed incorrectly. For example, a modification in the requirements once the product has been delivered can cost between 60 and 100 times higher than requesting the same modification during the initial phases of development [1]. In this sense, RE is crucial not only from the point of view of the technical knowledge required but from an organizational and economic perspective [5]. However, specifying high-quality functional requirements is not easy since organizations/customers often do not know exactly what they want, and, in many cases, the requirements may not reflect their real needs [5], which results in team members not adequately incorporating the objectives of other interested parties or stakeholders. This indicates that the current functional requirements analysis process is not sufficient to identify and represent the existence of multiple stakeholders [6]. In this scenario, it is common that requirements are incomplete, inconsistent and ambiguous, and although different proposals have been developed, they do not completely solve the weaknesses mentioned above. In this sense, to provide a broader view of the system as a whole, it is still necessary to work on the design of solutions to improve the activities related to the functional requirements modeling and the analysis of the interests and stakeholder needs [7].
In order to address the problem associated with the requirements specification, it is necessary to perform the present systemic mapping to know the existing research on goal-oriented modeling and the existing frameworks in front of the modeling of agile functional requirements, which has received special attention in the research of areas such as: Requirements Engineering (RE), Software Engineering (SE) [1], Information Systems (IS), Conceptual Modeling (CM) [8], and Enterprise Modeling (EM) [9].
Goal-oriented models have proven to be useful in supporting the capture, understanding and communication of requirements during the early stages of software development. However, their usefulness is greatly enhanced when they can be applied during the later stages of the requirements analysis process. The objectives are the raison d'être of the requirements, they can be used as part of the entire system life cycle, and they provide the appropriate level of abstraction in which decision-makers can participate to validate decisions made or suggest alternatives that have been overlooked.
When RE uses the goal-oriented model is known as Goal-Oriented Requirement Engineering (also known as GORE), which is an approach that deals with intentionality according to the relationships between the different actors in a system. Some of the most widely used frameworks for the treatment of requirements according to the GORE approach are KAOS [10] and i* (also known as i-star, hereafter referred to as i*) [11], [7].
In addition to the present introduction, this article is organized as follows: Section 2 describes the research protocol followed for the system-thematic mapping. Section 3 contains the results obtained from the response to the research questions. Section 4 presents a discussion of the main observations of the results, limitations, and implications of the study. Finally, Section 5 presents the conclusions and future work.
II. METHODOLOGY
This System Mapping (SM) study was performed according to the guidelines recommended by Petersen et al. [12], which states that an SM study aims to build a classification scheme and structure a field of interest in Software Engineering. Taking into account the mentioned protocol, the SM was performed following three stages: (i) planning, (ii) execution, and (iii) documentation.
A. Planning Stage
Six steps were followed in this stage: (i) definition of the research questions, which were established according to the main objectives of the study; (ii) definition of the search strategy; (iii) definition of the criteria for selecting the primary studies; (iv) definition of the quality evaluation criteria; (v) definition of the data extraction strategy; and (vi) selection of the synthesis method. These steps are described below.
The main objective of this study was to identify existing research on the specification of agile functional requirements through the use of GORE. For this purpose, five research questions were established. They are presented in https://bit.ly/3V5E8mK, where each question is related to its corresponding motivation. In order to present the state of the art in this area, the questions allowed to categorize the information found about GORE and modeling of agile functional requirements in software development and to identify new gaps for exploration.
Five databases were used to perform the automated information search, among them: IEEE Xplorer, Scopus, Google Scholar, ScienceDirect, and SpringerLink, in which a search string divided into two parts was introduced (see https://bit.ly/3EKvmVR), which represents the GORE approach and the agile requirements. A Boolean OR was used to join the terms and synonyms in each of the parts, and the Boolean AND to join the two parts together. In addition, the search was performed by applying the search string on the title of each article. All information published after 2013 was considered since it was validated during the execution of the systemic mapping that most relevant publications about GORE are found in the period 2013 - 2022. The period starts from 2013 because the first queries in the last 20 years did not yield results, and solutions applied to GORE in the context of agile requirements were only identified until 2013.
The study selection process was carried out considering three review filters: the title of the studies; the abstract, introduction and conclusions; and the full text, to determine whether the study would be included as a Primary Study (PS) or not. Moreover, we included studies that met at least one of the following Inclusion Criteria (IC): (i) English-language studies related to the specification of agile functional requirements using GORE, (ii) complete studies published between 2013 and 2022, (iii) complete studies published in peer-reviewed journals, (vi) complete studies published in conferences, (v) complete studies published in congresses, and (vi) complete studies published in workshops of prestige. On the other hand, studies that met any of the following Exclusion Criteria (EC) were not considered: (i) duplicate papers (for those articles repeated in different databases, the decision was made to leave the count of the article found in the column “Primary selected” only in the database where it was found first, for the other databases the count was made only in the column “Repeated Relevants”); (ii) papers where the topic is covered superficially, i.e., articles where there is no clearly defined application, solution, direct solution proposal on the topic of interest, e.g., articles that mention some of the keywords, but only mention them and do not address them in-depth; and (iii) studies of debate, or available only in the form of abstracts or presentations. Furthermore, the references of each article were not evaluated, i.e., we did not consider the backward and forward snowball effect.
To measure the quality of the selected studies and to determine the relevant studies about the use of GORE in the specification of agile functional requirements, the questionnaire used a three-value scoring system between -1, 0 and +1 [14]. The questions considered for the evaluation of each study and the score assigned according to the possible answers can be consulted at https://bit.ly/3UXW2bG. Likewise, the criterion of relevance was used, which was represented, according to [15] by the academic relevance, which can be evaluated through the publication of articles in the subject and the citations obtained by each one of them and the industry, through the application of the proposed solutions in the industrial context. The results of the evaluation of the studies according to the quality evaluation criteria can be consulted at https://bit.ly/3ENwFDL. The final score of the studies was determined by the total score of each (obtaining a value between -8 and +8). These ratings allowed us to find more relevant studies for future research but were not used to remove studies from systematic mapping. The following link https://bit.ly/3tJ1pzf lists the selected primary studies; a convention was defined for each to facilitate the distinction between the studies used in the introduction and those identified in the mapping. To ensure the use of the same data extraction criteria for all the selected studies, the following link https://bit.ly/3XtC2PR presents the research questions and their possible answers. The synthesis of the selected primary studies was based on the identification of the article considering the title and the year of publication, later, the abstract, introduction and conclusions, and finally, considering the full text according to their possible answers in each one of the research questions. The mapping had a time window between August 2021 and May 2022.
B. Execution Stage
Five iterations were carried out in total, one iteration for each established search source. The following link https://bit.ly/3EKZZe1 presents the total number of studies (found, relevant, repeated, and primary) found in Scopus, Google Scholar, SpringerLink, ScienceDirect, and IEEE Xplore.
C. Documentation Stage
The information collected from the beginning of the systematic mapping to its end was documented transversally and parallel to each of the activities carried out during the investigation (https://bit.ly/3i0v1Ws).
III. RESULTS
The results obtained for each of the defined research questions are shown below.
A. Is there a Consensus on Using GORE with the Agile Functional Requirements Specification?
After analyzing the selected primary studies, it was possible to appreciate an interest by researchers in developing techniques to help in the process of modeling and specification of agile functional requirements. In addition, it was also possible to see that, although the number of studies is low, it is possible to find efforts related to the use of GORE approaches and the interpretation of requirements. Likewise, it was possible to observe that GORE defines metamodels and languages that contribute to increasing the level of coverage and systematization of the requirements modeling process, among them: i* [S3], [S7], Tropos [S5], KAOS [S4], GRL [S5], AOM [S2] and Goal Net [S1]. Something important to highlight is that given that goal-oriented modeling is versatile and adaptive, it can be applied in conjunction with different models, methodologies, approaches or solutions for software development. Additionally, it is important to highlight the integration of the i* model and the user story to be able to represent a system graphically, relating the structure of the user story with i* elements, which improves consistency in the representation of the requirements. This is a novel field that is beginning to gain more and more popularity.
B. What Domains are Used to Illustrate the Application of the Topic of Interest?
Among the primary studies, it was found that 77.8% ([S1], [S2], [S4], [S5], [S6], [S7], [S8]) present basic and varied examples such as: method based on Goal Net to model requirements [S1], approach to the use of agent-oriented modeling in agile requirements engineering [S2], implementation of a tool to obtain i* models from user stories [S3], among others. However, its application in a real domain is not reflected; for example: study [S4] presents a goal-based requirements modeling language and methodology to understand needs and requirements and represent them in a much clearer way to improve the quality of the written requirements for the project. Additionally, the application of the proposal was carried out in an example of objective modeling, which is about developing a platform capable of showing the life cycle of systems engineering based on simulation for an aircraft, adopting real elements and aspects. However, the application in a real/industrial context is not observed.
On the other hand, of the remaining 22.2% ([S3] and [S9]), it was found that study [S3] presents the implementation of an automated solution as a tool to map user stories in i* models, called US2StarTool, using real data in 2 industrial projects, where the tool was tested and allowed to obtain i* models from user stories. Furthermore, the study presents the proposed method, and in future works, it contemplates presenting the projects’ findings as detailed case studies. Finally, study [S9] proposes an approach to map user stories to i* models and vice versa and applied its proposal in a small software company, where 13 volunteers with experience in agile development participated (6 requirements engineers and 7 developers). The results obtained are: (i) the integration of the user stories with the i* models, (ii) an improved understanding of the context as a way of considering the two phases of requirements engineering: the early and late phases, (iii) easier access to requirements information through the visual model, and (iv) an improvement in the decision-making process based on the analysis of the requirements described in the i* models.
C. What Results were Achieved?
The collection of studies clarified the research on the application of GORE to agile functional requirements. The literature on goal-oriented model generation for requirements interpretation, modeling, and specification has been reviewed and synthesized in this SM. On the other hand, although few related studies have been found, it has been possible to observe interesting advances in this line, for example: the use of Goal Net diagrams [S1] evaluated in educational and industrial contexts, the implementation of a tool (US2StarTool) that allows automating the transformation of user stories into i* models [S3]. Likewise, in [S6], GORE is applied to add value to the business, which has allowed to improve the planning of iterations and monitoring of the progress of software projects at multiple levels. On the other hand, [S7] presents an overview of how to transform i* models into user stories, and the artifact (specification) generated is an understandable document for business analysts and stakeholders, and some of the benefits related to the transformation approach based on scenarios or acceptance criteria are mentioned in this study. In the same way, the result of the work done in [S9] presents the integration of user stories with i* models to deliver the benefits provided by the i* approach with respect to the visualization and analysis of the system as a whole through its models, contributing to the understanding of the context as a way to consider both phases of requirements engineering: the early and the late phase. In addition, it facilitates the understanding of the requirements through visual models.
D. What Research Topics can be Identified from the Selected Studies?
In the analysis of the studies, it was found that the efforts are mainly focused on the transformation of GORE models to user stories, for example, the transformation of user stories to models based on Goal Net [S1], transformation of user stories to i* models using a software tool [S3], transformation of user stories to i models * and vice versa, i.e., from i* models to stories to user [S9], transformation of a set of user stories to UML class diagrams with a goal-based approach [S6] and transformation of user stories to an i* model through a set of guidelines [S7]. Other proposals related to transformation are the combination of goal-oriented modeling and user stories using a case tool [S2].
E. What GORE Solutions are Used and what is the Trend in the Last 10 Years?
The methods or processes that have been used indicate that there is no single accepted solution in the GORE context or in related areas of knowledge, instead there are different branches with different nuances of orientation, for example: there are proposals of goal-oriented modeling languages as i* used in 50% of the studies found, among them: implementation of tools to obtain models i* [S3], transformation of i* models to user stories [S7], integration of user stories with models to map the system through its models [S9], likewise, some authors have found in UML, i* and AOM a basis for requirements modeling, arising proposals related to the transformation of user stories to a goal-oriented model through the use of templates of a unified model [S6]. In the same way, [S1] proposes the Goal Net goal-oriented method, which allows modeling user stories in the software development process and AOM [S2], which through the use of goal-oriented models, contributes to identifying, tracking, and documenting requirements with goal-oriented models. On the other hand, 77.8% of the studies ([S1], [S2], [S3], [S4], [S4], [S7], [S8], [S9]) focus on the analysis of solutions for requirements specification using notation languages other than UML such as i*, Tropos, KAOS and GRL, AOM and Goal Net, because they tend to be too complex for non-technical parties to express and communicate clearly to the agile team, noting that goal-oriented models allow a better understanding of the requirements for both technical and non-technical parts of the team. Furthermore, of the 77.8% of the studies analyzed in this SM, it was found that 42.8% ([S1], [S3], [57]) focus their efforts on supporting user story transformations to i* models, 28.6% ([S1], [S2]) towards user story transformations with goal-oriented models and agents, and 28.6% ([S1], [S6]) on UML models or other goal-oriented modeling methods, noting that goal-oriented models allow a better understanding of requirements for both technical and non-technical parts of the team.
VI. DISCUSSION
This section presents an analysis of the results obtained from the SM to identify the improvements that can be made to the proposals found.
A. Main Observations
The objective of this systematic mapping was to determine the existing research related to the specification of agile functional requirements using GORE. In this sense, after analyzing the results, the following observations could be deduced, but due to space limitations, these are detailed in: https://bit.ly/3tPxSnr.
B. Limitations of Systematic Mapping
The search only considered articles in English, and despite being a universal language, it could exclude important articles written in other languages. However, this research has shown relevant results that can serve as a starting point to carry out the update of this mapping in a later version. In addition, considering only agile functional requirements could have meant the loss of review proposals that have requirements specifications using GORE. However, it was decided to investigate only agile requirements since they are the most used by the industry today [18].
C. Significance for Research and Practice
The observations of the present systematic mapping are of great importance for those researchers who are planning to investigate the specification of agile functional requirements using GORE in software development projects. For researchers, it is an interesting area since it is a new topic in which there are still different areas that can be addressed.
D. Threats to Validity
It was managed in an objective manner where each of the steps was reviewed according to an established working group, which is made up of the three main authors. The first two authors were in charge of executing the search chain and carrying out the steps of the protocol established by Petersen. The third author, the member with the most experience carrying out this type of study, carried out the traceability of the activities, thus trying to reduce subjectivity in the identification, selection, and elimination of the articles being analyzed. Likewise, each activity was previously reviewed to reduce subjectivity in its execution.
VI. CONCLUSIONS AND FUTURE WORK
In the last 10 years, agile approaches have become one of the most used approaches by organizations. However, the use of agile requirements continues to generate ambiguities in their interpretation, evaluation, and specification, among others; for this reason, it is necessary to explore solutions that support and facilitate the transition from tacit to explicit knowledge and mitigate the loss of information. In this regard, the proposed goal-oriented requirements models could contribute since they identify the actors and their goals through simple, straightforward, and effective specifications, they could help improve aspects inherent to the requirements, such as clarity, correctness, consistency, coherence, understanding, modifiability, verifiability, among others. However, to date, some needs need to be addressed, including the standardization of proposed stereotypes and languages, because there are currently several solutions. This could generate confusion or ambiguity for companies interested in their application. Likewise, the existing models do not make their application clear in agile contexts where teams are geographically distributed and aspects such as managing various requirements over time can be complex. On the other hand, few studies show the benefits achieved in industrial settings, perhaps because it is a new topic. However, more related works are expected to be identified over time. In the same way, one of the main challenges is reducing the complexity of integrating tools in the activities developed in agile approaches such as Scrum. The idea is not to reduce agility by including new artifacts but to provide greater control in the design stage and consider aspects such as the modifiability of requirements in software projects.
For future work, we are working on extending the stereotypes of the i* modeling language to model user stories and some characteristics of their acceptance criteria., and transforming the models obtained into the specification of the requirements of a project, and in this way, partially automate this task, contributing to the reduction of ambiguity, time and effort, clarity, consistency, coherence, understanding, among others.
