Next Article in Journal
Vision-Autocorrect: A Self-Adapting Approach towards Relieving Eye-Strain Using Facial-Expression Recognition
Previous Article in Journal
End-to-End Database Software Security
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Systematic Review

A Review to Find Elicitation Methods for Business Process Automation Software

by
Thiago Menezes
1,2,†
1
Sidia, Manaus 69075-155, Brazil
2
CESAR School, Recife 50030-390, Brazil
Current address: Darcy Vargas, 654, Parque Dez de Novembro, Manaus 69055-035, Brazil.
Software 2023, 2(2), 177-196; https://doi.org/10.3390/software2020008
Submission received: 22 February 2023 / Revised: 15 March 2023 / Accepted: 16 March 2023 / Published: 29 March 2023
(This article belongs to the Topic Software Engineering and Applications)

Abstract

:
Several organizations have invested in business process automation software to improve their processes. Unstandardized processes with high variance and unstructured data encumber the requirements elicitation for business process automation software. This study conducted a systematic literature review to discover methods to understand business processes and elicit requirements for business process automation software. The review revealed many methods used to understand business processes, but only one was employed to elicit requirements for business process automation software. In addition, the review identified some challenges and opportunities. The challenges of developing a business process automation software include dealing with business processes, meeting the needs of the organization, choosing the right approach, and adapting to changes in the process during the development. These challenges open opportunities for proposing specific approaches to elicit requirements in this context.

1. Introduction

Several organizations have increasingly invested in business process automation to improve their business processes [1,2,3,4,5]. Traditional business process automation, robotic process automation, and hyperautomation enable software to perform the labor of human beings in a digital environment. Such approaches have guided the digital transformation in organizations and improved business processes in auditing firms [6,7], banks [2,8], outsourcing providers [9,10], public entities [11], software industry [12,13,14,15], and telecommunication companies [16]. Figure 1 shows the investment in BPA in the last years according to [1,5].
Although processes are widely automated, developing automation for a business process is a challenge. A business process is far more complex than a few manual repetitive tasks performed in software by a single person. It involves several elements such as data (inputs and outputs), workflows (tasks, steps, flows, rules, and exceptions), stakeholders (professionals, teams, and departments), and technologies [4,17]. In addition, the real process typically lies in the minds of stakeholders since it is not fully documented or its documentation is deprecated as a result of several changes to the process [18,19,20]. Thus, understanding the real processes of an organization is crucial to the success of business process automation software. If the processes are misunderstood, the automation will not automate them appropriately.
Requirements engineering describes various approaches and techniques to elicit requirements for any given project. Refs.  [21,22] present an overview of elicitation approaches and techniques that can be employed to understand the domain and elicit requirements for developing software. Thus, these approaches and techniques can assist in understanding processes that define the scope of the business process automation software to meet the needs of the organization.
This paper investigates how elicitation approaches and techniques might be used to understand the real business processes of an organization and determine the requirements for software to automate them. This paper aims to answer the following questions:
 RQ1: 
What are the elicitation approaches and techniques cited in the literature?
 RQ2: 
What are the most suitable elicitation approaches and techniques cited in the literature to understand business processes?
 RQ3: 
What is the most appropriate way to elicit requirements for business process automation software?
Paper outline. The remaining parts of the paper are organized as follows: Section 2 describes the relevant background on business process automation and requirements engineering. Section 3 presents the protocol applied in the review, which includes the search strategy, selection criteria, snowball sampling, and data extraction. It also provides the results of the review and an overview of the studies conducted. Section 4 discusses the obtained results of the systematic review and presents the challenges and opportunities in requirements elicitation for business process automation software. Finally, Section 5 gives the conclusions.

2. Background

This section introduces the main concepts related to business process automation and requirements engineering.

2.1. Business Process Automation

Business process automation (BPA) refers to the technology to automate and optimize business processes, aiming to improve efficiency, reduce costs, and increase the performance of organizations [23,24]. BPA has become a widely adopted strategy in the current business environment as organizations look for ways to improve their operations and remain competitive [1,5].
An organization is a dynamic, invisible, and intangible organism formed by an arrangement of processes [25]. A process is a step-by-step way to solve a problem [26] that concerns a set of related tasks that receive one or more inputs and generate output for a specific purpose [27,28,29]. A business process refers to a process that performs within the digital ecosystem of an organization [17].
The terms automate, automation, system, and software are defined in [30]. Automate means to perform a task under predetermined conditions and functions without human intervention. Automation refers to the conversion of manual operations into automatic ones. A system consists of a collection of interrelated components organized to accomplish one or more functions within a particular environment. Software refers to all or part of the programs, procedures, rules, and associated documentation of an information processing system.
Business process automation software (BPAS) is software that automates a specific process or a set of processes within a particular digital ecosystem. In order to execute digital labor [17] and automate business processes, a BPAS must consider a variety of information systems and applications with different ages, features, compatibilities, interfaces, and data [4]. While general software is simply a collection of unrelated operations designed to assist users in performing tasks, business process automation software entails integrating several applications to carry out related tasks for one or more processes.
As with all software, the development of BPAS can be divided into several phases, starting with the requirements specification. This process is critical to ensuring that the BPAS meets the needs of the organization and achieves the desired objectives.
One of the main benefits of BPA is the ability to automate repetitive tasks such as data entry, document processing, and customer service [4,11,23,24]. This can lead to significant time and cost savings for organizations, as well as greater accuracy and consistency in performing these tasks [2,3,4,6,9,11,31,32,33,34,35,36,37,38,39]. In addition, BPA can also lead to better decision-making through the use of data analysis and business intelligence tools [4].
Despite the benefits of BPA, there are challenges to consider, such as lack of flexibility, as BPAS can be inflexible and unable to adapt to changes in business processes or requirements [6,9,11,40]. Another challenge is the integration with existing systems and processes. Organizations must ensure that BPAS is able to integrate seamlessly into their digital ecosystem without disrupting operations or causing an undue burden on resources [14,41,42], which requires careful planning and consideration of potential impacts on its ecosystem.
In summary, BPA is a widely adopted strategy to improve efficiency and reduce costs in organizations. It has the potential to bring significant benefits, such as automating repetitive tasks and improving decision-making. However, organizations must also consider challenges such as lack of flexibility and integration into the digital ecosystem.

2.1.1. Approaches to Develop Business Process Automation Software

Nowadays, there are three approaches to develop BPAS: traditional business process automation, robotic process automation, and hyperautomation.
Traditional business process automation (TBPA) is the traditional approach, which entails developing BPAS in a programming language for integrating the relevant applications in the digital ecosystem to execute a given process [14,41,42]. Application programming interfaces (APIs), services, databases, and automation tools such as Selenium, QTP, and WinAppDriver are typically employed to implement this integration.
Robotic process automation (RPA) uses software robots (also called agents, bots, or workers) to emulate human–computer interaction for executing a combination of processes, activities, transactions, and tasks in one or more unrelated software systems [3,4,17,24]. In 2022, there were more than 80 RPA vendors available in the market, such as UiPath, Automation Anywhere, Blue Prism, Samsung SDS, WorkFusion, IBM, Microsoft, SAP, Kryon, Nintex, etc. [43].
Hyperautomation (HA) is the next stage of RPA evolution. It combines robotic process automation and artificial intelligence to discover, validate, and execute organizational processes automatically with no or minimal human intervention [23,44].

2.1.2. Challenges to Develop Business Process Automation Software

Business processes are dynamic [18,19,20]. Developing BPAS requires significant effort and resources to understand and deal with their characteristics. According to [6,9,11,39,40], a business process is eligible for automation if: (1) it handles a high volume of transactions manually labor-intensively; (2) it requires access to multiple applications or systems; (3) the tasks are prone to human error due to manual labor; (4) the tasks are performed frequently. However, automation is not suitable for non-standardized processes with high variance and unstructured data [6,9,11,40].
Researchers also emphasized the difficulties in eliciting BPAS, including (1) lack of process standardization, (2) process variability, (3) deprecated documents that do not faithfully represent the process performed [6,9,11,40], (4) lack of knowledge of the vocabulary used by participants in the organization [18,45,46,47,48,49], and (5) lack of engagement of the stakeholders involved in the process [21,45,49,50,51,52,53,54,55,56,57].
Additionally, BPAS must satisfy the needs of the organization, taking into account the key performance indicator (KPI) goals [4,38], organizational capabilities [4], available budget [4], required time [4], privacy policies, legal regulations, user acceptance [58], etc.
The digital ecosystem, the BPAS approaches, the business processes, and the needs of the organization must be elicited as requirements. According to [30], a requirement is a documented representation of a condition or capability that must be met or possessed by a system to satisfy the needs, wants, and expectations of the stakeholders.

2.2. Requirements Engineering

Requirements engineering (RE) is the discipline that elicits, analyzes, documents, verifies, and manages requirements for a project [30]. It aids software engineering by establishing and maintaining the software scope along the software development cycle (SDC) [21]. This scope can be defined through various requirement-elicitation approaches and techniques, described by requirements engineering, to transfer knowledge and avoid communication gaps between the stakeholders.

2.2.1. Requirements

According to [30], a requirement is a documented representation of a condition or capability that must be met or possessed by a system to satisfy the needs, desires, and expectations of stakeholders. Requirements are fundamental for any project, as they define the scope and objectives to be achieved. Without a clear understanding of what is required, it is impossible to ensure that a project is successful [59,60,61,62,63].
Requirements must be specified and managed throughout the SDC of the [21] project. The requirement-specification process should involve all stakeholders of an organization as well as any external parties that will be impacted by the project [53]. This helps ensure that all necessary perspectives are taken into account and that the requirements are comprehensive and accurate.
Once the requirements are specified, they must be managed and tracked throughout the project. This includes ensuring that the requirements are prioritized and that any changes or additions to the requirements are approved and implemented in a controlled manner [21]. This helps ensure the project stays on track to meet the needs of all stakeholders.
Finally, it is important to note that requirements can change over time and that the requirement-specification and -management process must be ongoing [64]. This is particularly true in the case of software development, where new technologies and industry trends can rapidly change the landscape. Keeping an eye on the latest developments and being willing to adapt the requirements as needed can help ensure that a project remains relevant and competitive.
Therefore, requirements are a critical aspect of any project, especially software projects. They serve as the foundation upon which the project is built and are necessary to ensure the end result meets the needs of all stakeholders. Gathering and managing requirements throughout the SDC are essential to ensure that the project stays on track and that the end result is successful.

2.2.2. Requirement Specification

The SDC comprises phases that can overlap or be carried out iteratively based on the software development approach being used [30]. Each approach defines different quantities and names of phases. In general, an SDC consists of four main phases: planning, analysis, design and implementation, and testing.
The outcome of the planning phase is the requirement specification, which consists of a document that outlines the requirements of a software [30]. The specification involves defining the scope and the requirements of the project, identifying the stakeholders, and establishing a set of objectives and goals for the software.
To write a good specification, project managers and software developers will work closely with stakeholders to understand their needs and requirements. They also will conduct a detailed analysis of the requirements, eliciting information about the stakeholders, identifying their needs, and determining the requirements for the software [30].

2.2.3. Requirement Elicitation

Requirement elicitation is an interactive and investigative process that usually involves meetings with stakeholders [21,46,53]. It involves in-depth discussions and the collaboration of all participants from the beginning of product development so that all work together to build a successful product.
Several researchers agree that requirement elicitation is the most critical, time-consuming, and expensive activity in software development, since the elicitors do not know the domain of the stakeholders and the stakeholders do not transfer knowledge of the domain or their needs properly to the elicitors [21,22,47,48,50,51,53,60,65,66,67,68], which causes communication gaps and generates ambiguous, inconsistent, and incomplete requirements [52,60,68].
The requirement elicitation identifies the needs, risks, and assumptions related to any system. If the elicitation is managed poorly, one or more requirements can change, which results in failures, rework, and delays [59,60,61,62,63]. In the context of BPAS, ref. [13] reports an example of a BPAS that failed to meet UX requirements, making its users distrust the software and prefer to perform their tasks manually.
Requirements engineering describes several requirement-elicitation approaches and techniques [21,22]. The terms technique and approach are defined by [22]. A technique is a way of doing something or a practical procedure employed to accomplish some specific task. On the other hand, an approach is a systematic, phased arrangement of ideas or actions aimed at dealing with a problem or situation. This work uses the term method to refer to both the technique and the approach.

3. Systematic Review

This section describes the protocol used to carry out the systematic literature review and presents the results obtained to answer the research questions posed in Section 1.

3.1. Protocol

The protocol used to conduct the systematic review on the identification of elicitation methods in the context of business process automation software is depicted in Figure 2.
The review protocol, supported by Mendeley (available at mendeley.com) and Parsifal (available at parsif.al.) tools, is based on the guidelines described in [69]. The following steps make up the protocol: (1) search for relevant studies; (2) select studies according to the selection criteria; (3) search for more potential studies using the snowball sampling method; and (4) apply data extraction and perform data synthesis to answer the research questions.

3.1.1. Search Strategy

The following string was used to search studies and answer the three research questions reported in Section 1:
    requirement* AND elicit* AND
    (technique* OR method* OR approach*) AND
    ((business OR organizational) AND process)
The search was conducted in December 2021. The studies were collected in the following digital databases, with no restriction on the publication period: ACM Digital Library, IEEE Xplore, and Science Direct.

3.1.2. Selection Criteria

After systematically reading the titles and abstracts of the studies, the only ones that met the inclusion criteria were those that used elicitation methods to understand business processes. This criterion guided the search for studies that could answer the research questions directly. Studies that (1) were unavailable to download, (2) did not deal with software aspects, or (3) did not suggest a method that helps to elicit requirements were excluded.

3.1.3. Snowball Sampling

As a result of the previous step, an unsatisfying set of studies was obtained. Many elicitation methods were mentioned but poorly defined or discussed. For this reason, snowball sampling (which is a sampling technique in which primary studies indicate other potential studies according to some eligibility criteria to participate in the research [69]) was performed to fill these gaps and uncover other sources of potential primary data to be used in this research.
This review started with the obtained studies as seeds for snowball sampling to identify additional relevant studies. Three rounds of sampling were conducted using these seeds to explore citations and references that met the same criteria outlined in Section 3.1.2. This iterative process allowed the review to expand the pool of studies and increase the understanding of the research.

3.1.4. Data Extraction

After obtaining more studies from the snowball sampling method, data were extracted through a complete reading of the selected studies. An extraction form with the following questions was defined: (1) What were the elicitation methods considered in the study? (2) What is the automation approach considered in the study? (3) Does the study elicit requirements for business processes? (4) What is the main approach employed? (5) Does the study contribute to this research in any way?

3.2. Results

This section addresses the literature review conducted. First, the section presents an overview of the way the studies were obtained. Since it is interested in studies regarding the elicitation of requirements for BPAS, the research introduces the methods to elicit requirements, which ones are used to understand processes, and those used to elicit requirements for BPAS.

3.2.1. Overview of Studies

Table 1 summarizes the number of studies filtered after each step of the review protocol. First, a total of 14264 studies was obtained from ACM Digital Library (51%), Science Direct (47%), and IEEE Xplore (2%). Following repeated-studies removal and title and abstract analysis, 210 studies were retained, of which 100 came from IEEE Xplore (48%), 62 from Science Direct (29%), and 48 from ACM Digital Library (23%). The selection criteria (described in Section 3.1.2) removed 177 studies, leaving 33 to be inspected more closely. In order to improve the understanding of the research, snowball sampling was performed. As a result of this step, 75 studies were found. Finally, 108 primary studies were included in the synthesis.
It is important to note that several studies did not appear in the initial search because they were located in other sources or because they were indexed with other keywords not considered by the search string described in Section 3.1.1. These findings emphasize the limitations of relying solely on systematic searches and highlight the importance of supplementing search strategies with alternative methods to ensure comprehensive coverage of the relevant literature.
Figure 3 depicts the proportion of studies returned per source after performing the review protocol. Of the 108 included studies, 23 come from IEEE Xplore (21%), seven from Science Direct (7%), three from ACM Digital Library (3%), and 75 come after snowball sampling (69%).
These 108 studies were utilized for data extraction and synthesis in the interest of answering the research questions. The results of the data extraction are presented in the following subsections.

3.2.2. Elicitation Methods

There are several approaches and techniques to elicit requirements for software. Since each software has particular characteristics, researchers reject the idea that a single method works for any software [21,70,71].
Figure 4 shows a bar chart. The vertical axis represents the 46 elicitation methods found in this systematic review, of which 22 are techniques and 24 are approaches. The horizontal axis represents the quantity of different studies that cited a method.
Table 2 introduces the 22 techniques detected in the review. The most-cited ones are interviews with 53 citations, scenarios with 42, workshops with 29, viewpoints with 25, observation with 19, brainstorming and domain analysis with 17, and prototyping with 16. These techniques have numerous applications [21,22,67].
On the other hand, Table 3 presents the 24 approaches discovered during the review. The most-referenced ones are surveys with 44 citations, followed by i-Star (i*) with 14, Joint Application Design (JAD) with ten, Knowledge Acquisition in Automated Specification (KAOS) with eight, Problem Frames (PF) with seven, Global Software Development Requirements Elicitation (GSD-RE), Cooperative Requirements Engineering with Scenarios (CREWS) and Soft Systems Methodology (SSM) with four, MUST (a Danish acronym for initial design theories and methods) and StakeRare with three, and User-Led Requirements Construction (ULRC), Wizard-of-Oz, Method for Elicitation, Documentation and Validation of Software User Requirements (MEDoV), and Business-Oriented Requirements Engineering (BORE) with two citations.
Refs. [21,22] compiled the majority of the methods currently in use. Ref. [67] reviewed the methods concerned with developing mobile applications. Ref. [46] introduced some techniques to elicit requirements in the health care domain. Some researchers employed artificial intelligence (AI) techniques such as K-nearest neighbor (KNN) [51,72,73], data mining [74], and natural language processing (NLP) [74,75,76,77,78] to automate or improve the requirement elicitation, especially to support a crowdsourcing technique [56]. Other methods transcribed the domain documentation into requirements [98,103]. Process mining was employed to elicit requirements by extracting knowledge from logs [61,63,120,121].
Approaches such as KAOS and i* elicit functional and non-functional requirements based on goals [46,135]. Other goal-oriented approaches are Pedigreed Attribute Elicitation Method (PALM) and Multimedia Enhanced Goal-Oriented Requirement Elicitation (MEGORE). Ref. [104] proposed PALM to simplify the conversion of business goals into requirements by avoiding hierarchical goal structures, goal graphs, or other complex structures. Ref. [117] presented MEGORE to enhance scenarios by incorporating media (graphic, image, audio, video, and animation content) into the elicitation. Ref. [145] compared the communication among JAD, ULRC, MUST, and SSM. The former seeks to build consensus among stakeholders about the requirements [21,22,29,46,145]. ULRC focuses on training users to build the system requirement models themselves [145]. MUST is based on thorough participation with users and managers that combines ethnographic techniques and intervention [148]. SSM provides a set of rules to analyze chaotic requirements in order to plan and determine the appropriate changes for the systems [29].
In the mobile context, the review found two specific approaches. Ref. [87] employed user-centered design (UCD) to develop mobile user interfaces for the elderly. Refs. [152,153] used Wizard-of-Oz, a low-fidelity prototyping approach, to simulate how the requirements work in mobile applications. Ref. [149] developed problem frames to provide a detailed analysis of the problems and identify patterns that could point to viable solutions. Ref. [100] proposed Macro to Micro Level Requirements Elicitation (MAMIE), a viewpoint-based approach that employs use cases and sequence diagrams to represent understandable notations for acquiring, analyzing, and modeling requirements. GSD-RE elicits requirements for software development at geographically separate locations and asynchronous interactions [112,124,131,142]. StakeRare utilizes KNN to predict the requirements of the stakeholders [51,72,73].
Ref. [146] proposed MEDoV. Ref. [80] proposed BORE. Both approaches identify relevant business processes from which to derive requirements. Ref. [147] applied MEDoV in Agile projects. Ref. [81] enhanced BORE using business-driven development features to handle more complex processes. Ref. [122] proposed an approach to capture business process information in conceptual models from operatively involved people. Ref. [135] proposed Requirements Elicitation Oriented by Business Process Modeling for Enterprise Knowledge Development (REMO-EKD) to elicit functional and non-functional requirements as well as organizational rules based on EKD models. Ref. [123] introduced Requirements Elicitation for Adaptive Socio-Technical Systems Using Repertory Grid (REASSURE), a repertory-grid-based approach created to verify the accuracy of requirements from the diverse technical knowledge among stakeholders during elicitation. Unlike the above-cited researchers, ref. [89] uses Design Thinking Workshops (DTW) to understand the business processes and elicit the requirements.
Lastly, ref. [113] proposed Business Process oriented Collaborative Requirements Acquisition and Refining (BPCRAR), an approach based on narrative theory and argumentation theory that combines collaborative and communication techniques to reduce the the requirements dominance of analysts and promote the participation of stakeholders to elicit requirements.

3.2.3. Elicitation Methods to Understand Business Processes

The comprehension of business processes involves the approaches and techniques employed to understand the domain. This way, the review detected 24 elicitation methods. Table 4 lists these approaches and techniques.
According to [21,22], the proper methods to understand the domain of an organization are apprenticing, interviews, domain analysis, ethnography, i*, JAD, KAOS, observation, problem frames, protocol analysis, scenarios, task analysis, viewpoints, and workshops. In addition, several approaches were proposed by researchers to understand organizational processes, such as BPCRAR, BORE, DTW, MEDoV, REMO-EKD, and REASSURE.
Other methods not above-mentioned are AI techniques, card sorting, and process mining. Refs. [77,98] used NLP to extract knowledge from organizational documents for eliciting requirements. Ref. [122] utilized card sorting and viewpoints to capture a comprehensive representation of the overall business process. Refs. [61,63,120,121] employed process mining to discover the real processes from event logs in information systems.

3.2.4. Methods to Elicit Business Process Automation Software

Of all methods discovered in this review, only BORE was employed to elicit requirements for BPAS, but the review found only studies that applied BORE in academic contexts [80,81]. This review found no methods tailored or used to elicit BPAS in business or industrial contexts. However, Section 3.2.3 introduced potential methods to elicit requirements for BPAS.

4. Discussion

The main objective of this work is to present state-of-the-art studies regarding the identification of approaches and techniques to understand business processes and elicit requirements for BPAS. Despite the advances in requirements engineering, the selected studies allowed this work to detect existing problems and opportunities for research. In particular, the review found the following limitations:
 L1: 
Most studies introduced methods to elicit requirements for general software.
 L2: 
Only two studies elicited requirements for BPAS, but both were in academic contexts.
 L3: 
The methods ignored the changes in business processes during the BPAS development.
 L4: 
Most methods ignored the characteristics of business processes and the difficulties to develop BPAS.
 L5: 
Most methods did not properly regard the needs of the organization in an automation context.
 L6: 
The methods ignored the BPAS approaches and their development specificities.
The studies that elicited requirements for BPAS used BORE. Since the studies showed that the approach has never been employed in business or industrial contexts, there is no evidence about its efficiency and effectiveness. Like other methods, the approach ignores the characteristics of the business processes and the difficulties 1 and 2 mentioned in Section 2. BORE employs techniques such as document analysis, interviews, and workshops. The first may elicit incorrect requirements since it does not handle deprecated documents, difficulty 3. The remaining methods are challenging techniques in contrast with difficulties 4 and 5, since they need the vocabulary and participation of stakeholders to avoid communication gaps and, consequently, the elicitation of wrong requirements. In addition, the approach ignores changes in the business processes during the SDC, a difficult problem for all methods to deal with.
Although process mining was used to discover real business processes, the review did not find any approach that utilized the technique to elicit requirements for BPAS. Since 2018, few studies have explored process mining to elicit requirements. This corroborates [121] and shows that the synergy between them remains sparse.
The aforementioned limitations leave open opportunities for proposing specific approaches to elicit requirements for BPAS. The review provided studies that employed process mining to fill the gaps left by the other methods. Process mining may be used to discover, monitor, and improve real business processes (that is, processes as executed in reality and not as drawn in flowcharts or other supports) [20].
The main goal of future work will be the employment of process mining to propose a novel elicitation approach for BPAS that overcomes the limitations found in the detected methods. This way, future studies may further contribute to eliciting and developing better business process automation software.

5. Conclusions

This paper reviewed studies on the approaches and techniques for eliciting requirements. The review focused on elicitation methods for understanding business processes and developing BPAS.
The studies presented 46 methods employed to elicit requirements. From these methods, 24 were used to understand business processes, but only one was applied to elicit requirements for BPAS. Most methods did not consider or did not properly regard the characteristics of processes, the difficulties in developing BPAS, the needs of the organization, or the BPAS approaches. Such limitations are evident even in BORE, which was previously used to elicit requirements for BPAS.
The challenges faced include dealing with the characteristics of business processes, overcoming the difficulties inherent in BPAS elicitation, dealing with the needs of the organization, choosing the right BPAS approach, and dealing with changes in the processes during the development.
Finally, it was suggested that future work employ process mining to create a novel approach to eliciting requirements for BPAS, since the technique automatically models and documents the business processes and variants, reduces the risks arising from deprecated documentation, and reduces dependence on the engagement of stakeholders who master the process.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

Not applicable.

Acknowledgments

This research was supported by Samsung Eletrônica da Amazônia Ltda under Brazilian Federal Law 8.387/1991.

Conflicts of Interest

The author declares no conflict of interest.

References

  1. Gartner. Gartner Says Worldwide Spending on Robotic Process Automation Software to Reach $680 Million in 2018. 2018. Available online: https://www.gartner.com/en/newsroom/press-releases/2018-11-13-gartner-says-worldwide-spending-on-robotic-process-automation-software-to-reach-680-million-in-2018 (accessed on 3 December 2021).
  2. Lewicki, P.; Tochowicz, J.; van Genuchten, J. Are Robots Taking Our Jobs? A RoboPlatform at a Bank. IEEE Softw. 2019, 36, 101–104. [Google Scholar] [CrossRef]
  3. Axmann, B.; Harmoko, H. Robotic Process Automation: An Overview and Comparison to Other Technology in Industry 4.0. In Proceedings of the 2020 10th International Conference on Advanced Computer Information Technologies (ACIT), Deggendorf, Germany, 16–18 September 2020; pp. 559–562. [Google Scholar] [CrossRef]
  4. Hofmann, P.; Samp, C.; Urbach, N. Robotic process automation. Electron. Mark. 2020, 30, 99–106. [Google Scholar] [CrossRef] [Green Version]
  5. Gartner. Gartner Forecasts Worldwide Hyperautomation-Enabling Software Market to Reach Nearly $600 Billion by 2022. 2021. Available online: https://www.gartner.com/en/newsroom/press-releases/2021-04-28-gartner-forecasts-worldwide-hyperautomation-enabling-software-market-to-reach-nearly-600-billion-by-2022 (accessed on 1 March 2022).
  6. Huang, F.; Vasarhelyi, M.A. Applying robotic process automation (RPA) in auditing: A framework. Int. J. Account. Inf. Syst. 2019, 35, 100433. [Google Scholar] [CrossRef]
  7. Nunes, T.; Leite, J.; Pedrosa, I. Intelligent Process Automation: An Overview over the Future of Auditing. In Proceedings of the 2020 15th Iberian Conference on Information Systems and Technologies (CISTI), Sevilla, Spain, 24–27 June 2020; pp. 1–5. [Google Scholar] [CrossRef]
  8. Romao, M.; Costa, J.; Costa, C.J. Robotic Process Automation: A Case Study in the Banking Industry. In Proceedings of the 2019 14th Iberian Conference on Information Systems and Technologies (CISTI), Coimbra, Portugal, 19–22 June 2019; pp. 1–6. [Google Scholar] [CrossRef]
  9. Aguirre, S.; Rodriguez, A. Automation of a business process using robotic process automation (RPA): A case study. In Proceedings of the 4th Workshop on Engineering Applications (WEA 2017), Cartagena, Colombia, 27–29 September 2017; Volume 742, pp. 65–71. [Google Scholar] [CrossRef]
  10. Issac, R.; Muni, R.; Desai, K. Delineated Analysis of Robotic Process Automation Tools. In Proceedings of the 2018 Second International Conference on Advances in Electronics, Computers and Communications (ICAECC), Bangalore, India, 9–10 February 2018; pp. 1–5. [Google Scholar] [CrossRef] [Green Version]
  11. Uskenbayeva, R.; Kalpeyeva, Z.; Satybaldiyeva, R.; Moldagulova, A.; Kassymova, A. Applying of RPA in Administrative Processes of Public Administration. In Proceedings of the 2019 IEEE 21st Conference on Business Informatics (CBI), Moscow, Russia, 15–17 July 2019; Volume 2, pp. 9–12. [Google Scholar] [CrossRef]
  12. Barbosa, H.O.; Bonifácio, B.; Menezes, T.M.; Uebel, L.F.; Pires, F.B.; Neto, A.F. Uma Análise do Uso de Ferramentas em Desenvolvimento Distribuído de Software para Atualização da Plataforma Android. In Proceedings of the 18th International Conference WWW/Internet 2019, Cagliari, Italy, 7–9 November 2019; pp. 39–46. [Google Scholar]
  13. De Menezes, T.M. User Experience Evaluation for Automation Tools: An Industrial Experience. Int. J. Cybern. Inform. 2022, 11, 53–60. [Google Scholar] [CrossRef]
  14. Yatskiv, S.; Voytyuk, I.; Yatskiv, N.; Kushnir, O.; Trufanova, Y.; Panasyuk, V. Improved Method of Software Automation Testing Based on the Robotic Process Automation Technology. In Proceedings of the 2019 9th International Conference on Advanced Computer Information Technologies (ACIT), Ceske Budejovice, Czech Republic, 5–7 June 2019; pp. 293–296. [Google Scholar] [CrossRef]
  15. Yatskiv, N.; Yatskiv, S.; Vasylyk, A. Method of Robotic Process Automation in Software Testing Using Artificial Intelligence. In Proceedings of the 2020 10th International Conference on Advanced Computer Information Technologies (ACIT), Deggendorf, Germany, 16–18 September 2020; pp. 501–504. [Google Scholar] [CrossRef]
  16. Lacity, M.; Willcocks, L. Robotic process automation at telefónica O2. Mis Q. Exec. 2016, 15, 21–35. [Google Scholar]
  17. IEEE Guide for Terms and Concepts in Intelligent Process Automation. IEEE Std 2755-2017; IEEE: Piscataway, NJ, USA, 2017; pp. 1–16. [CrossRef]
  18. Van der Aalst, W.; Weijters, T.; Maruster, L. Workflow mining: Discovering process models from event logs. IEEE Trans. Knowl. Data Eng. 2004, 16, 1128–1142. [Google Scholar] [CrossRef]
  19. Van der Aalst, W.M. Challenges in Business Process Mining. Available online: http://bpmcenter.org/wp-content/uploads/reports/2010/BPM-10-01.pdf (accessed on 22 December 2021).
  20. Process Mining Manifesto. 2012. Available online: https://www.tf-pm.org/upload/1580738212409.pdf (accessed on 22 December 2021).
  21. Nuseibeh, B.; Easterbrook, S. Requirements engineering: A roadmap. In Proceedings of the Conference on the Future of Software Engineering, New York, NY, USA, 4–11 June 2000; pp. 35–46. [Google Scholar]
  22. Zowghi, D.; Coulin, C. Requirements elicitation: A survey of techniques, approaches, and tools. In Engineering and Managing Software Requirements; Springer: Berlin/Heidelberg, Germany, 2005; pp. 19–46. [Google Scholar]
  23. Gartner. Gartner Glossary. Available online: https://www.gartner.com/en/glossary (accessed on 8 February 2022).
  24. Van der Aalst, W.M.; Bichler, M.; Heinzl, A. Robotic Process Automation; Gabler Verlag: Wiesbaden, Germany, 2018; Volume 60, pp. 269–272. [Google Scholar] [CrossRef] [Green Version]
  25. Pride, W.; Hughes, R.; Kapoor, J. Business; Cengage Learning: Mason, OH, USA, 2009. [Google Scholar]
  26. Havey, M. Essential Business Process Modelling; O’Reilly: Sebastopol, CA, USA, 2005. [Google Scholar]
  27. Davenport, T.H. Process Innovation: Reengineering Work through Information Technology; Harvard Business School Press: Boston, MA, USA, 1993. [Google Scholar]
  28. Hammer, M.; Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution; Brealey: London, UK, 1993. [Google Scholar]
  29. Kiper, J.R. Eliciting user needs for a knowledge management system to align training programs with processes and policies in large organizations. In Proceedings of the 2015 48th Hawaii International Conference on System Sciences, Piscataway, NJ, USA, 5–8 January 2015; pp. 3970–3979. [Google Scholar]
  30. ISO/IEC/IEEE International Standard—Systems and Software Engineering—Vocabulary. Technical Report. ISO/IEC/IEEE 24765:2017; ISO: Geneva, Switzerland, 2017. [CrossRef]
  31. Gupta, S.; Rani, S.; Dixit, A. Recent Trends in Automation-A study of RPA Development Tools. In Proceedings of the 2019 3rd International Conference on Recent Developments in Control, Automation Power Engineering (RDCAPE), Noida, India, 10–11 October 2019; pp. 159–163. [Google Scholar] [CrossRef]
  32. Ma, Y.; Lin, D.; Chen, S.; Chu, H.; Chen, J. System Design and Development for Robotic Process Automation. In Proceedings of the 2019 IEEE International Conference on Smart Cloud (SmartCloud), Tokyo, Japan, 10–12 December 2019; pp. 187–189. [Google Scholar] [CrossRef]
  33. Maalla, A. Development Prospect and Application Feasibility Analysis of Robotic Process Automation. In Proceedings of the 2019 IEEE 4th Advanced Information Technology, Electronic and Automation Control Conference (IAEAC), Chengdu, China, 20–22 December 2019; Volume 1, pp. 2714–2717. [Google Scholar] [CrossRef]
  34. Ortiz, F.C.M.; Costa, C.J. RPA in Finance: Supporting portfolio management: Applying a software robot in a portfolio optimization problem. In Proceedings of the 2020 15th Iberian Conference on Information Systems and Technologies (CISTI), Sevilla, Spain, 24–27 June 2020; pp. 1–6. [Google Scholar] [CrossRef]
  35. Parchande, S.; Shahane, A.; Dhore, M. Contractual Employee Management System Using Machine Learning and Robotic Process Automation. In Proceedings of the 2019 5th International Conference On Computing, Communication, Control And Automation (ICCUBEA), Pune, India, 19–21 September 2019; pp. 1–5. [Google Scholar] [CrossRef]
  36. Robotic Process Automation: Contemporary themes and challenges. Comput. Ind. 2020, 115, 103162. [CrossRef]
  37. Timbadia, D.H.; Jigishu Shah, P.; Sudhanvan, S.; Agrawal, S. Robotic Process Automation Through Advance Process Analysis Model. In Proceedings of the 2020 International Conference on Inventive Computation Technologies (ICICT), Coimbatore, India, 26–28 February 2020; pp. 953–959. [Google Scholar] [CrossRef]
  38. Wewerka, J.; Reichert, M. Towards Quantifying the Effects of Robotic Process Automation. In Proceedings of the 2020 IEEE 24th International Enterprise Distributed Object Computing Workshop (EDOCW), Eindhoven, The Netherlands, 5–8 October 2020; pp. 11–19. [Google Scholar] [CrossRef]
  39. William, W.; William, L. Improving Corporate Secretary Productivity using Robotic Process Automation. In Proceedings of the 2019 International Conference on Technologies and Applications of Artificial Intelligence (TAAI), Kaohsiung, Taiwan, 21–23 November 2019; pp. 1–5. [Google Scholar] [CrossRef]
  40. Leshob, A.; Bourgouin, A.; Renard, L. Towards a Process Analysis Approach to Adopt Robotic Process Automation. In Proceedings of the 2018 IEEE 15th International Conference on e-Business Engineering (ICEBE), Xi’an, China, 12–14 October 2018; pp. 46–53. [Google Scholar] [CrossRef]
  41. Mohapatra, S. Business Process Automation; PHI Learning Pvt. Ltd.: Delhi, India, 2009. [Google Scholar]
  42. Jovanović, S.Z.; Đurić, J.S.; Šibalija, T.V. Robotic process automation: Overview and opportunities. Int. J. Adv. Qual. 2018, 46, 34–39. [Google Scholar]
  43. Dilmegani, C. RPA Market Size and Popular Vendors in 2022. 2022. Available online: https://research.aimultiple.com/rpa-market/#top-rpa-vendors-in-the-market (accessed on 27 November 2022).
  44. Bornet, P.; Barkin, I.; Wirtz, J. INTELLIGENT AUTOMATION: Welcome to the World of HYPERAUTOMATION: Learn How to Harness Artificial Intelligence to Boost Business & Make Our World More Human; World Scientific: Singapore, 2021. [Google Scholar]
  45. Cysneiros, L.M.; de Macedo-Soares, T.; do Prado Leite, J.C.S. Using ISO 9000 to elicit business rules. In Proceedings of the 4th IEEE International Software Engineering Standards Symposium and Forum (ISESS’99), ’Best Software Practices for the Internet Age’, Curitiba, Brazil, 17–21 May 1999; pp. 88–98. [Google Scholar]
  46. Cysneiros, L.M. Requirements engineering in the health care domain. In Proceedings of the IEEE Joint International Conference on Requirements Engineering, Essen, Germany, 9–13 September 2002; pp. 350–356. [Google Scholar]
  47. Cysneiros, L.; do Prado Leite, J. Nonfunctional requirements: From elicitation to conceptual models. IEEE Trans. Softw. Eng. 2004, 30, 328–350. [Google Scholar] [CrossRef] [Green Version]
  48. Gacitúa, R.; Ma, L.; Nuseibeh, B.; Piwek, P.; De Roeck, A.N.; Rouncefield, M.; Sawyer, P.; Willis, A.; Yang, H. Making tacit requirements explicit. In Proceedings of the 2009 Second International Workshop on Managing Requirements Knowledge, Atlanta, GA, USA, 1 September 2009; pp. 40–44. [Google Scholar]
  49. Pasquadibisceglie, V.; Appice, A.; Castellano, G.; Malerba, D. Predictive Process Mining Meets Computer Vision. In Proceedings of the Business Process Management Forum, Seville, Spain, 13–18 September 2020; pp. 176–192. [Google Scholar] [CrossRef]
  50. Nuseibeh, B.; Easterbrook, S.; Russo, A. Leveraging inconsistency in software development. Computer 2000, 33, 24–29. [Google Scholar] [CrossRef] [Green Version]
  51. Lim, S.L.; Finkelstein, A. StakeRare: Using social networks and collaborative filtering for large-scale requirements elicitation. IEEE Trans. Softw. Eng. 2011, 38, 707–735. [Google Scholar]
  52. Mendizabal, O.M.; Spier, M.; Saad, R. Log-based approach for performance requirements elicitation and prioritization. In Proceedings of the 2012 20th IEEE International Requirements Engineering Conference (RE), Chicago, IL, USA, 24–28 September 2012; pp. 297–302. [Google Scholar]
  53. Silva, A.R.d. Uma Abordagem para Definição de Guias de Elicitação de Requisitos Não-Funcionais. Ph.D. Thesis, Universidade de Fortaleza, Fortaleza, Brazil, 2016. [Google Scholar]
  54. Bennaceur, A.; McCormick, C.; García-Galán, J.; Perera, C.; Smith, A.; Zisman, A.; Nuseibeh, B. Feed Me, Feed Me: An Exemplar for Engineering Adaptive Software. In Proceedings of the 2016 IEEE/ACM 11th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), Austin, TX, USA, 16–17 May 2016; pp. 89–95. [Google Scholar] [CrossRef]
  55. Elrakaiby, Y.; Ferrari, A.; Spoletini, P.; Gnesi, S.; Nuseibeh, B. Using argumentation to explain ambiguity in requirements elicitation interviews. In Proceedings of the 2017 IEEE 25th International Requirements Engineering Conference (RE), Lisbon, Portugal, 4–8 September 2017; pp. 51–60. [Google Scholar]
  56. Groen, E.C.; Seyff, N.; Ali, R.; Dalpiaz, F.; Doerr, J.; Guzman, E.; Hosseini, M.; Marco, J.; Oriol, M.; Perini, A.; et al. The crowd in requirements engineering: The landscape and challenges. IEEE Softw. 2017, 34, 44–52. [Google Scholar] [CrossRef] [Green Version]
  57. Maalej, W.; Nayebi, M.; Ruhe, G. Data-Driven Requirements Engineering—An Update. In Proceedings of the 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), Montreal, QC, Canada, 25–31 May 2019; pp. 289–290. [Google Scholar] [CrossRef]
  58. Wewerka, J.; Dax, S.; Reichert, M. A User Acceptance Model for Robotic Process Automation. In Proceedings of the 2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC), Eindhoven, The Netherlands, 5–8 October 2020; pp. 97–106. [Google Scholar] [CrossRef]
  59. Menzies, T.; Easterbrook, S.; Nuseibeh, B.; Waugh, S. An empirical investigation of multiple viewpoint reasoning in requirements engineering. In Proceedings of the IEEE International Symposium on Requirements Engineering (Cat. No.PR00188), Limerick, Ireland, 11 June 1999; pp. 100–109. [Google Scholar] [CrossRef] [Green Version]
  60. Hussain, Z.M.; Sumari, P. WERT technique in requirements elicitation for web applications. In Proceedings of the 2016 International Conference on Electronics, Information and Communications (ICEIC), Danang, Vietnam, 27–30 January 2016; pp. 1–4. [Google Scholar]
  61. Dabrowski, J.; Kifetew, F.M.; Muñante, D.; Letier, E.; Siena, A.; Susi, A. Discovering Requirements through Goal-Driven Process Mining. In Proceedings of the 2017 IEEE 25th International Requirements Engineering Conference Workshops (REW), Lisbon, Portugal, 4–8 September 2017; pp. 199–203. [Google Scholar] [CrossRef] [Green Version]
  62. Caldeira, J.; Brito e Abreu, F.; Reis, J.; Cardoso, J. Assessing Software Development Teams’ Efficiency using Process Mining. In Proceedings of the 2019 International Conference on Process Mining (ICPM), Aachen, Germany, 24–26 June 2019; pp. 65–72. [Google Scholar] [CrossRef]
  63. Saito, S. Identifying and Understanding Stakeholders using Process Mining: Case Study on Discovering Business Processes that Involve Organizational Entities. In Proceedings of the 2019 IEEE 27th International Requirements Engineering Conference Workshops (REW), Jeju Island, Republic of Korea, 23–27 September 2019; pp. 216–219. [Google Scholar] [CrossRef]
  64. Jayatilleke, S.; Lai, R. A systematic review of requirements change management. Inf. Softw. Technol. 2018, 93, 163–185. [Google Scholar] [CrossRef]
  65. Haley, C.; Laney, R.; Moffett, J.; Nuseibeh, B. Security Requirements Engineering: A Framework for Representation and Analysis. IEEE Trans. Softw. Eng. 2008, 34, 133–153. [Google Scholar] [CrossRef] [Green Version]
  66. Zamansky, A.; Van Der Linden, D.; Baskin, S. Pushing boundaries of RE: Requirement elicitation for non-human users. In Proceedings of the 2017 IEEE 25th International Requirements Engineering Conference (RE), Lisbon, Portugal, 4–8 September 2017; pp. 406–411. [Google Scholar]
  67. Dar, H.; Lali, M.I.; Ashraf, H.; Ramzan, M.; Amjad, T.; Shahzad, B. A systematic study on software requirements elicitation techniques and its challenges in mobile application development. IEEE Access 2018, 6, 63859–63867. [Google Scholar] [CrossRef]
  68. Hu, X.; Liu, J.; Wang, Y. Researches on Software Requirements Elicitation Approach of the Aviation Electronics Systems based on Multi-ontology. In Proceedings of the 2020 22nd International Conference on Advanced Communication Technology (ICACT), Pyeong Chang, Republic of Korea, 16–19 February 2020; pp. 330–335. [Google Scholar]
  69. Kitchenham, B.A.; Budgen, D.; Brereton, P. Evidence-Based Software Engineering and Systematic Reviews; CRC Press: Boca Raton, FL, USA, 2016. [Google Scholar]
  70. Saiedian, H.; Dale, R. Requirements engineering: Making the connection between the software developer and customer. Inf. Softw. Technol. 2000, 42, 419–428. [Google Scholar] [CrossRef]
  71. Chakraborty, S.; Sarker, S.; Sarker, S. An exploration into the process of requirements elicitation: A grounded approach. J. Assoc. Inf. Syst. 2010, 11, 1. [Google Scholar] [CrossRef]
  72. Vijayan, J.; Raju, G.; Joseph, M. Collaborative requirements elicitation using elicitation tool for small projects. In Proceedings of the 2016 International Conference on Signal Processing, Communication, Power and Embedded System (SCOPES), Paralakhemundi, India, 3–5 October 2016; pp. 340–344. [Google Scholar]
  73. Dheepa, V.; Aravindhar, D.J.; Vijayalakshmi, C. A novel method for large scale requirement elicitation. Int. J. Eng. Innov. Technol. 2013, 2, 375–379. [Google Scholar]
  74. Kaiya, H.; Shimizu, Y.; Yasui, H.; Kaijiri, K.; Saeki, M. Enhancing domain knowledge for requirements elicitation with web mining. In Proceedings of the 2010 Asia Pacific Software Engineering Conference, Washington, DC, USA, 30 November 2010–3 December 2010; pp. 3–12. [Google Scholar]
  75. Sinha, A.; Paradkar, A. Use cases to process specifications in business process modeling notation. In Proceedings of the 2010 IEEE International Conference on Web Services, Miami, FL, USA, 5–10 July 2010; pp. 473–480. [Google Scholar]
  76. Yanuarifiani, A.P.; Chua, F.F.; Chan, G.Y. Automating business process model generation from ontology-based requirements. In Proceedings of the Proceedings of the 2019 8th International Conference on Software and Computer Applications; Penang, Malaysia, 19–21 February 2019, pp. 205–209.
  77. Zapata J., C.M.; Losada, B.M.; González-Calderón, G. An approach for using procedure manuals as a source for Requirements Elicitation. In Proceedings of the 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI), Medellin, Colombia, 1–5 October 2012; pp. 1–8. [Google Scholar]
  78. Rahmi Dewi, M.; Kharisma Raharjana, I.; Siahaan, D.; Fatichah, C. Software Requirement-Related Information Extraction from Online News using Domain Specificity for Requirements Elicitation: How the system analyst can get software requirements without constrained by time and stakeholder availability. In Proceedings of the 2021 10th International Conference on Software and Computer Applications, Kuala Lumpur, Malaysia, 23–26 February 2021; pp. 81–87. [Google Scholar]
  79. Robertson, S.; Robertson, J. Mastering the Requirements Process: Getting Requirements Right; Addison-Wesley: Boston, MA, USA, 2012. [Google Scholar]
  80. Przybylek, A. A business-oriented approach to requirements elicitation. In Proceedings of the 2014 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE), Lisbon, Portugal, 28–30 April 2014; pp. 1–12. [Google Scholar]
  81. Nosrati, M. Exact requirements engineering for developing business process models. In Proceedings of the 2017 3th International Conference on Web Research (ICWR), Tehran, Iran, 19–20 April 2017; pp. 140–147. [Google Scholar]
  82. Saeed, S.; Fatima, U.; Iqbal, F. A review of Requirement Elicitation techniques in OSSD. Int. J. Comput. Sci. Netw. Secur. 2018, 18, 86. [Google Scholar]
  83. Abeti, L.; Ciancarini, P.; Moretti, R. Wiki-based requirements management for business process reengineering. In Proceedings of the 2009 ICSE Workshop on Wikis for Software Engineering, Vancouver, BC, Canada, 19 May 2009; pp. 14–24. [Google Scholar]
  84. Chua, B.B.; Bernardo, D.V.; Verner, J. Understanding the use of elicitation approaches for effective requirements gathering. In Proceedings of the 2010 Fifth International Conference on Software Engineering Advances, Nice, France, 22–27 August 2010; pp. 325–330. [Google Scholar]
  85. Jaramillo, A.F. Non-functional requirements elicitation from business process models. In Proceedings of the 2011 Fifth International Conference on Research Challenges in Information Science, Gosier, France, 19–21 May 2011; pp. 1–7. [Google Scholar]
  86. Zhou, X.; Yi, L.; Liu, Y. A collaborative requirement elicitation technique for SaaS applications. In Proceedings of the Proceedings of 2011 IEEE International Conference on Service Operations, Logistics and Informatics; Beijing, China, 10–12 July 2011, pp. 83–88.
  87. Jakkaew, P.; Hongthong, T. Requirements elicitation to develop mobile application for elderly. In Proceedings of the 2017 International Conference on Digital Arts, Media and Technology (ICDAMT), Chiang Mai, Thailand, 1–4 March 2017; pp. 464–467. [Google Scholar]
  88. Bagheri, S.; Kusters, R.J.; Trienekens, J.J.; Grefen, P.W. A reference model-based user requirements elicitation process: Toward operational business-IT alignment in a co-creation value network. Inf. Softw. Technol. 2019, 111, 72–85. [Google Scholar] [CrossRef]
  89. Levy, M.; Huli, C. Design thinking in a nutshell for eliciting requirements of a business process: A case study of a design thinking workshop. In Proceedings of the 2019 IEEE 27th International Requirements Engineering Conference (RE), Jeju Island, Republic of Korea, 23–27 September 2019; pp. 351–356. [Google Scholar]
  90. Márquez, G.; Taramasco, C. Using dissemination and implementation strategies to evaluate requirement elicitation guidelines: A case study in a bed management system. IEEE Access 2020, 8, 145787–145802. [Google Scholar] [CrossRef]
  91. Bose, R.; Sugumaran, V. Knowledge-based approach to domain modeling: Organizational process modeling application. J. Netw. Comput. Appl. 1996, 19, 67–89. [Google Scholar] [CrossRef]
  92. Demirörs, O.; Gencel, Ç.; Tarhan, A. Utilizing Business Process Models for Requirements Elicitation. In Proceedings of the EUROMICRO, Porto, Portugal, 2–4 July 2003; pp. 409–412. [Google Scholar]
  93. Bowen, G.A. Document analysis as a qualitative research method. Qual. Res. J. 2009, 9, 27–40. [Google Scholar] [CrossRef] [Green Version]
  94. Muqeem, M.; Beg, M.R. Validation of requirement elicitation framework using finite state machine. In Proceedings of the 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT), Tamil Nadu, India, 10–11 July 2014; pp. 1210–1216. [Google Scholar]
  95. Hafidhoh, N.; Liem, I.; Azizah, F.N. Source code generator for automating business rule implementation. In Proceedings of the 2015 International Conference on Data and Software Engineering (ICoDSE), Yogyakarta, Indonesia, 25–26 November 2015; pp. 219–224. [Google Scholar]
  96. Cruz, E.F.; Machado, R.J.; Santos, M.Y. Deriving software design models from a set of business processes. In Proceedings of the 2016 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD), Rome, Italy, 19–21 February 2016; pp. 489–496. [Google Scholar]
  97. Zhou, Q.; Liu, L. Understanding Requirements for Online Services Based on Users’ Behavioural Data Analysis. In Proceedings of the 2013 IEEE 37th Annual Computer Software and Applications Conference Workshops, Kyoto, Japan, 22–26 July 2013; pp. 27–34. [Google Scholar]
  98. Aysolmaz, B.; Leopold, H.; Reijers, H.A.; Demirörs, O. A semi-automated approach for generating natural language requirements documents based on business process models. Inf. Softw. Technol. 2018, 93, 14–29. [Google Scholar] [CrossRef] [Green Version]
  99. Baloian, N.; Pino, J.A.; Reveco, C.; Zurita, G. Mobile collaboration for business process elicitation from an agile development methodology viewpoint. In Proceedings of the 2013 IEEE 10th International Conference on e-Business Engineering, Coventry, UK, 11–13 September 2013; pp. 306–311. [Google Scholar]
  100. Bendjenna, H.; Zarour, N.E.; Charrel, P.J. MAMIE: A methodology to elicit requirements in inter-company co-operative information systems. In Proceedings of the 2008 International Conference on Computational Intelligence for Modelling Control & Automation, Vienna, Austria, 10–12 December 2008; pp. 290–295. [Google Scholar]
  101. Buchanan, S.; McMenemy, D. Digital service analysis and design: The role of process modelling. Int. J. Inf. Manag. 2012, 32, 251–256. [Google Scholar] [CrossRef] [Green Version]
  102. Carrizo, D. Comparison of Research and Practice Regarding What We Mean by “The Right Software Requirements Elicitation Technique”. In Proceedings of the 2016 10th International Conference on the Quality of Information and Communications Technology (QUATIC), Lisbon, Portugal, 6–9 September 2016; pp. 79–82. [Google Scholar]
  103. Carvalho, E.A.; Escovedo, T.; Melo, R.N. Using business processes in system requirements definition. In Proceedings of the 2009 33rd Annual IEEE Software Engineering Workshop, Skovde, Sweden, 13–14 October 2009; pp. 125–130. [Google Scholar]
  104. Clements, P.; Bass, L. Using business goals to inform a software architecture. In Proceedings of the 2010 18th IEEE International Requirements Engineering Conference, Sydney, Australia, 27 September–1 October 2010; pp. 69–78. [Google Scholar]
  105. Cox, K.; Phalp, K.T.; Bleistein, S.J.; Verner, J.M. Deriving requirements from process models via the problem frames approach. Inf. Softw. Technol. 2005, 47, 319–337. [Google Scholar] [CrossRef]
  106. Davey, B.; Parker, K.R. Requirements elicitation problems: A literature analysis. Issues Informing Sci. Inf. Technol. 2015, 12, 71–82. [Google Scholar] [CrossRef] [PubMed]
  107. De Vasconcelos, A.M.; de la Vara, J.L.; Sánchez, J.; Pastor, Ó. Towards CMMI-compliant business process-driven requirements engineering. In Proceedings of the 2012 Eighth International Conference on the Quality of Information and Communications Technology, Lisbon, Portugal, 3–6 September 2012; pp. 193–198. [Google Scholar]
  108. Dengler, F.; Vrandečič, D.; Simperl, E. Comparison of wiki-based process modeling systems. In Proceedings of the 11th International Conference on Knowledge Management and Knowledge Technologies, Graz, Austria, 7–9 September 2011; pp. 1–4. [Google Scholar]
  109. Ge, C.; Yu, S.; Yang, G.; Wang, W. A collaborative requirements elicitation approach based on scenario. In Proceedings of the 2009 IEEE 10th International Conference on Computer-Aided Industrial Design & Conceptual Design, Wenzhou, China, 26–29 November 2009; pp. 2213–2216. [Google Scholar]
  110. Hayat, F.; Ali, S.; Ehsan, N.; Akhtar, A.; Bashir, M.; Mirza, E. Requirement elicitation barriers to software industry of Pakistan (impact of cultural and soft issues). In Proceedings of the 2010 IEEE International Conference on Management of Innovation & Technology, Singapore, 2–5 June 2010; pp. 1275–1278. [Google Scholar]
  111. Jackson, E.; Norta, A. Design of a Remote Emotional Requirement Elicitation Feedback Method. In Proceedings of the 2020 IEEE Third International Workshop on Affective Computing in Requirements Engineering (AffectRE), Zurich, Switzerland, 1 September 2020; pp. 3–8. [Google Scholar]
  112. Kumari, S.N.; Pillai, A.S. A survey on global requirements elicitation issues and proposed research framework. In Proceedings of the 2013 IEEE 4th International Conference on Software Engineering and Service Science, Beijing, China, 23–25 May 2013; pp. 554–557. [Google Scholar]
  113. Lai, H.; Peng, R.; Ni, Y. A collaborative method for business process oriented requirements acquisition and refining. In Proceedings of the 2014 International Conference on Software and System Process, Nanjing, China, 26–28 May 2014; pp. 84–93. [Google Scholar]
  114. Moinnereau, M.A.; de Oliveira, A.A.; Falk, T.H. Immersive media experience: A survey of existing methods and tools for human influential factors assessment. Qual. User Exp. 2022, 7, 1–23. [Google Scholar] [CrossRef] [PubMed]
  115. Pendergast, M.; Aytes, K.; Lee, J.D. Supporting the group creation of formal and informal graphics during business process modeling. Interact. Comput. 1999, 11, 355–373. [Google Scholar] [CrossRef]
  116. Riegel, N. Model-based prioritization in business-process-driven software development. In Proceedings of the 2012 20th IEEE International Requirements Engineering Conference (RE), Chicago, IL, USA, 24–28 September 2012; pp. 349–352. [Google Scholar]
  117. Shan, Y.; Liu, L.; Peng, F. MEGORE: Multimedia enhanced goal-oriented requirement elicitation experience in China. In Proceedings of the 2008 Third International Workshop on Multimedia and Enjoyable Requirements Engineering-Beyond Mere Descriptions and with More Fun and Games, Washington, DC, USA, 9 September 2008; pp. 37–41. [Google Scholar]
  118. Teixeira, L.; Ferreira, C.; Santos, B.S. Using task analysis to improve the requirements elicitation in health information system. In Proceedings of the 2007 29th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, Lyon, France, 22–26 August 2007; pp. 3669–3672. [Google Scholar]
  119. Zagajsek, B.; Separovic, K.; Car, Z. Requirements management process model for software development based on legacy system functionalities. In Proceedings of the 2007 9th International Conference on Telecommunications, Zagreb, Croatia, 13–15 June 2007; pp. 115–122. [Google Scholar]
  120. Ghasemi, M. Towards Goal-Oriented Process Mining. In Proceedings of the 2018 IEEE 26th International Requirements Engineering Conference (RE), Banff, AB, Canada, 20–24 August 2018; pp. 484–489. [Google Scholar] [CrossRef]
  121. Ghasemi, M. What Requirements Engineering can Learn from Process Mining. In Proceedings of the 2018 1st International Workshop on Learning from other Disciplines for Requirements Engineering (D4RE), Banff, AB, Canada, 21 August 2018; pp. 8–11. [Google Scholar] [CrossRef]
  122. Oppl, S. Articulation of subject-oriented business process models. In Proceedings of the Proceedings of the 7th International Conference on Subject-Oriented Business Process Management; Kiel, Germany, 23–24 April 2015, pp. 1–11.
  123. Dey, S.; Lee, S.W. REASSURE: Requirements elicitation for adaptive socio-technical systems using repertory grid. Inf. Softw. Technol. 2017, 87, 160–179. [Google Scholar] [CrossRef]
  124. Ali, N.; Lai, R. A method of requirements elicitation and analysis for Global Software Development. J. Software Evol. Process 2017, 29, e1830. [Google Scholar] [CrossRef]
  125. Colantonio, A.; Di Pietro, R.; Verde, N.V. A business-driven decomposition methodology for role mining. Comput. Secur. 2012, 31, 844–855. [Google Scholar] [CrossRef]
  126. Cysneiros, L.M.; Raffi, M.; Sampaio do Prado Leite, J.C. Software Transparency as a Key Requirement for Self-Driving Cars. In Proceedings of the 2018 IEEE 26th International Requirements Engineering Conference (RE), Banff, AB, Canada, 20–24 August 2018; pp. 382–387. [Google Scholar] [CrossRef]
  127. Lee, G.; Eastman, C.M.; Sacks, R. Eliciting information for product modeling using process modeling. Data Knowl. Eng. 2007, 62, 292–307. [Google Scholar] [CrossRef]
  128. Macasaet, R.; Chung, L.; Garrido, J.L.; Noguera, M.; Rodríguez, M.L. An agile requirements elicitation approach based on NFRs and business process models for micro-businesses. In Proceedings of the Proceedings of the 12th International Conference on Product Focused Software Development and Process Improvement; Torre Canne, Italy, 20–22 June 2011, pp. 50–56.
  129. Nistala, P.; Kummamuru, S.; Narayana, M. An approach to understand and elicit requirements using systemic models: Ensuring a connect from problem context to requirements. Procedia Comput. Sci. 2013, 16, 786–795. [Google Scholar] [CrossRef] [Green Version]
  130. Salgado, C.E.; Machado, R.J.; Maciel, R.S. Exploring a Three-Dimensional, Requirements-Based, Balanced Scorecard Business Model: On the Elicitation and Generation of a Business Model Canvas. In Proceedings of the 2015 IEEE 17th Conference on Business Informatics, Lisbon, Portugal, 13–16 July 2015; Volume 2, pp. 88–95. [Google Scholar] [CrossRef]
  131. Sevilla, G.; Zapata, S.; Torres, E.; Collazos, C.A. Using wikis as collaborative strategy to support software requirements elicitation. In Proceedings of the 2014 9th Computing Colombian Conference (9CCC), Pereira, Colombia, 3–5 September 2014; pp. 54–61. [Google Scholar]
  132. Veleda, R.; Cysneiros, L.M. Towards a Tool to Help Exploring Existing Non-functional Requirements Solution Patterns. In Proceedings of the 2017 IEEE 25th International Requirements Engineering Conference Workshops (REW), Lisbon, Portugal, 4–8 September 2017; pp. 232–239. [Google Scholar] [CrossRef]
  133. Vieira, S.R.C.; Viana, D.; do Nascimento, R.; Conte, T. Evaluating a technique for requirements extraction from business process diagrams through empirical studies. In Proceedings of the 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI), Medellin, Colombia, 1–5 October 2012; pp. 1–10. [Google Scholar]
  134. Yang-Turner, F.; Lau, L. A pragmatic strategy for creative requirements elicitation: From current work practice to future work practice. In Proceedings of the 2011 Workshop on Requirements Engineering for Systems, Services and Systems-of-Systems, Trento, Italy, 30 August 2011; pp. 28–31. [Google Scholar]
  135. De Oliveira, M.; Viana, D.; Conte, T.; Vieira, S.; Marczak, S. Evaluating the REMO-EKD technique: A technique for the elicitation of software requirements based on EKD organizational models. In Proceedings of the 2013 3rd International Workshop on Empirical Requirements Engineering (EmpiRE), Rio de Janeiro, Brazil, 15 July 2013; pp. 9–16. [Google Scholar]
  136. Uskenbayeva, R.; Kuandykov, A.; Bolshibayeva, A.; Rakhmetulayeva, S. An algorithm for creating an automated system based on platform of business process. Procedia Comput. Sci. 2020, 175, 253–260. [Google Scholar] [CrossRef]
  137. Wu, L.; Hung, C.Y. A strategy-based process for effectively determining system requirements in eCRM development. Inf. Softw. Technol. 2009, 51, 1308–1318. [Google Scholar] [CrossRef]
  138. Yuan, X.; Tripathi, S. Combining ontologies for requirements elicitation. In Proceedings of the 2015 IEEE International Model-Driven Requirements Engineering Workshop (MoDRE), Ottawa, ON, Canada, 24 August 2015; pp. 1–5. [Google Scholar]
  139. Navin, A.H.; Kiyani, F.; Kheyri, J.; Rad, H.T. Transforming business tasks to data flow models for decrease process in analysis systems. In Proceedings of the 2009 International Conference on Advanced Computer Control, Washington, DC, USA, 22–24 January 2009; pp. 706–710. [Google Scholar]
  140. Sorgatto, D.W.; Paiva, D.M.B.; Cagnin, M.I. Requirement Reuse in Business Processes Lines: Reutilização de Requisitos Em Linhas de Processos de Negócio. In Proceedings of the XV Brazilian Symposium on Information Systems (SBSI’19), Aracaju, Brazil, 20–24 May 2019. [Google Scholar] [CrossRef]
  141. Wan, J.p.; Huang, D.y.; Wan, D. Knowledge conversion in software requirement elicitation. In Proceedings of the 2009 First International Conference on Information Science and Engineering, Nanjing, China, 26–28 December 2009; pp. 2328–2331. [Google Scholar]
  142. Conchúir, E.Ó.; Ågerfalk, P.J.; Olsson, H.H.; Fitzgerald, B. Global software development: Where are the benefits? Commun. ACM 2009, 52, 127–131. [Google Scholar] [CrossRef]
  143. Cysneiros, L.; Kushniruk, A. Bringing usability to the early stages of software development. In Proceedings of the 11th IEEE International Requirements Engineering Conference, Monterey Bay, CA, USA, 8–12 September 2003; pp. 359–360. [Google Scholar] [CrossRef]
  144. Nagel, B.; Gerth, C.; Engels, G.; Post, J. Ensuring consistency among business goals and business process models. In Proceedings of the 2013 17th IEEE International Enterprise Distributed Object Computing Conference, Vancouver, BC, Canada, 9–13 September 2013; pp. 17–26. [Google Scholar]
  145. Coughlan, J.; Macredie, R.D. Effective communication in requirements elicitation: A comparison of methodologies. Requir. Eng. 2002, 7, 47–60. [Google Scholar] [CrossRef]
  146. Dragicevic, S.; Celar, S. Method for elicitation, documentation and validation of software user requirements (MEDoV). In Proceedings of the 2013 IEEE Symposium on Computers and Communications (ISCC), Split, Croatia, 7–10 July 2013; pp. 956–961. [Google Scholar]
  147. Dragicevic, S.; Celar, S.; Novak, L. Use of method for elicitation, documentation, and validation of software user requirements (MEDoV) in agile software development projects. In Proceedings of the 2014 Sixth International Conference on Computational Intelligence, Communication Systems and Networks, Austin, TX, USA, 16–17 May 2014; pp. 65–70. [Google Scholar]
  148. Kensing, F.; Simonsen, J.; Bodker, K. MUST: A method for participatory design. Hum.-Comput. Interact. 1998, 13, 167–198. [Google Scholar] [CrossRef] [Green Version]
  149. Jackson, M. Problem Frames: Analysing and Structuring Software Development Problems; Addison-Wesley: Boston, MA, USA, 2001. [Google Scholar]
  150. Lin, L.; Nuseibeh, B.; Ince, D.; Jackson, M. Using abuse frames to bound the scope of security problems. In Proceedings of the 12th IEEE International Requirements Engineering Conference, Washington, DC, USA, 6–10 September 2004; pp. 354–355. [Google Scholar] [CrossRef] [Green Version]
  151. Checkland, P.B. Soft systems methodology. Hum. Syst. Manag. 1989, 8, 273–289. [Google Scholar] [CrossRef]
  152. Islam, D.M.R.; Mazumder, T. Mobile application and its global impact. Int. J. Eng. Technol. 2010, 10, 72–78. [Google Scholar]
  153. Abad, Z.S.H.; Sims, S.D.; Cheema, A.; Nasir, M.B.; Harisinghani, P. Learn More, Pay Less! Lessons Learned from Applying the Wizard-of-Oz Technique for Exploring Mobile App Requirements. In Proceedings of the 2017 IEEE 25th International Requirements Engineering Conference Workshops (REW), Lisbon, Portugal, 4–8 September 2017; pp. 132–138. [Google Scholar] [CrossRef] [Green Version]
Figure 1. Investment in business process automation.
Figure 1. Investment in business process automation.
Software 02 00008 g001
Figure 2. Review protocol.
Figure 2. Review protocol.
Software 02 00008 g002
Figure 3. Portion of studies retrieved from each digital library considered in this research.
Figure 3. Portion of studies retrieved from each digital library considered in this research.
Software 02 00008 g003
Figure 4. Elicitation methods found in the studies.
Figure 4. Elicitation methods found in the studies.
Software 02 00008 g004
Table 1. Studies obtained from each source.
Table 1. Studies obtained from each source.
SourceSearchTitle/Abstract AnalysisSelection CriteriaSnowball Sampling
ACM Digital Library7371483-
Science Direct6685627-
IEEE Xplore20810023-
Others---75
Total1426421033108
Table 2. Elicitation techniques.
Table 2. Elicitation techniques.
TechniqueStudiesTotal
Artificial Intelligence Techniques[51,72,73,74,75,76,77,78]8
Apprenticing[22,79,80,81,82]5
Brainstorming[21,22,29,51,66,67,72,73,80,82,83,84,85,86,87,88,89,90]17
Card Sorting[21,22,67,72,82,84,88]7
Crowdsourcing[51,56,73,78]4
Domain Analysis[21,22,29,60,68,77,80,81,82,85,91,92,93,94,95,96,81]17
Focus Group[21,29,51,55,56,66,73,84,97]9
Interviews[21,22,29,45,46,47,48,51,52,55,56,59,60,66,67,73,74,77,78,80,81,82,84,86,87,88,89,90,92,93,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119]53
Introspection[22]1
Laddering[21,22,72]3
Observation[21,22,46,48,50,66,72,77,78,82,84,87,93,101,105,110,111,118,119]19
Process Mining[61,63,120,121]4
Protocol Analysis[21,22,29,47,66]5
Prototyping[21,22,29,51,60,66,72,77,82,84,87,89,90,115,117,122]16
Repertory Grids[21,22,72,123]4
Scenarios[21,22,29,45,46,47,51,52,54,55,56,67,68,72,75,82,87,93,97,100,101,103,104,105,107,108,109,111,112,113,117,124,125,126,127,128,129,130,131,132,133,134]42
Questionnaires[21,22,29,45,46,47,51,54,55,56,59,60,66,67,78,80,81,82,83,84,87,88,90,91,93,94,96,97,98,99,102,103,104,106,111,112,113,117,126,129,135,136,137,138]33
Task Analysis[22,82,118,139]4
Use Cases[46,75,80,87,100,124]6
User Stories[22,56,78,113,124,134,140]7
Viewpoints[21,22,46,47,51,55,59,67,68,80,82,83,89,90,91,94,100,105,110,113,122,130,134,137]25
Workshops[21,22,48,50,51,54,55,56,66,72,80,81,82,85,89,90,98,99,100,101,104,111,112,113,115,122,129,134,141]29
Table 3. Elicitation approaches.
Table 3. Elicitation approaches.
ApproachStudiesTotal
Business-Oriented Requirements Engineering (BORE)[80,81]2
Business Process oriented Collaborative Requirements Acquisition and Refining (BPCRAR)[113]1
Cooperative Requirements Engineering with Scenarios (CREWS)[21,22,86,113]4
Design Thinking Workshop (DTW)[89]1
Ethnography[21,46,48,66,72,77,82,93]8
Global Software Development Requirements Elicitation (GSD-RE)[112,124,131,142]4
i-Star (i*)[22,46,83,85,96,100,107,117,132,133,135,140,143,144]14
Joint Application Design (JAD)[21,22,29,46,60,67,72,82,87,145]10
Knowledge Acquisition in Automated Specification (KAOS)[21,22,46,76,117,128,135,144]8
Macro to Micro Level Requirements Elictation (MAMIE)[100]1
Method for Elicitation, Documentation and Validation of Software User Requirements (MEDoV)[146,147]2
Multimedia Enhanced Goal-Oriented Requirement Elicitation (MEGORE)[117]1
MUST[29,145,148]3
Oppl’s Approach[122]1
Pedigreed Attribute Elicitation Method (PALM)[104]1
Problem Frames (PF)[21,22,74,98,105,149,150]7
Requirements Elicitation for Adaptive Socio-Technical Systems Using Repertory Grid (REASSURE)[123]1
Requirements Elicitation Oriented by Business Process Modeling for Enterprise Knowledge Development (REMO-EKD)[135]1
Soft Systems Methodology (SSM)[29,129,145,151]4
StakeRare[51,72,73]3
Surveys[21,22,29,45,46,47,51,54,55,56,59,60,66,67,78,80,81,82,83,84,87,88,90,91,93,94,96,97,98,99,102,103,104,106,111,112,113,117,126,129,135,136,137,138]44
User-Centered Design (UCD)[87]1
User-Led Requirements Construction (ULRC)[29,145]2
Wizard-of-Oz[152,153]2
Table 4. Elicitation methods to understand business processes.
Table 4. Elicitation methods to understand business processes.
ApproachStudiesTotal
AI Techniques[77,98]2
Apprenticing[22,79,80,81,82]5
Business-Oriented Requirements Engineering (BORE)[80,81]2
Business Process oriented Collaborative Requirements Acquisition and Refining (BPCRAR)[113]1
Card Sorting[21,22,72,122]4
Design Thinking Workshops[89]1
Domain Analysis[21,22,29,60,68,77,80,81,85,91,92,94,95,96,81]15
Ethnography[22,66]2
i-Star (i*)[22,135]2
Interviews[22,80,81,119]4
Joint Application Design (JAD)[22,72,113]3
Knowledge Acquisition in Automated Specification (KAOS)[22,135,144]3
Method for Elicitation, Documentation and Validation of Software User Requirements (MEDoV)[146,147]2
Observation[22,66,105,118]4
Oppl’s Approach[122]1
Problem Frames (PF)[22,105]2
Process Mining[61,63,120,121]4
Protocol Analysis[21,22,46]3
Requirements Elicitation for Adaptive Socio-Technical Systems Using Repertory Grid (REASSURE)[123]1
Requirements Elicitation Oriented by Business Process Modeling for Enterprise Knowledge Development (REMO-EKD)[135]1
Scenarios[22,113]2
Task Analysis[22,118,139]4
Viewpoints[22,122]2
Workshops[21,22,80,81]4
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Menezes, T. A Review to Find Elicitation Methods for Business Process Automation Software. Software 2023, 2, 177-196. https://doi.org/10.3390/software2020008

AMA Style

Menezes T. A Review to Find Elicitation Methods for Business Process Automation Software. Software. 2023; 2(2):177-196. https://doi.org/10.3390/software2020008

Chicago/Turabian Style

Menezes, Thiago. 2023. "A Review to Find Elicitation Methods for Business Process Automation Software" Software 2, no. 2: 177-196. https://doi.org/10.3390/software2020008

Article Metrics

Back to TopTop