A Review to Find Elicitation Methods for Business Process Automation Software

: 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 identiﬁed 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 speciﬁc approaches to elicit requirements in this context.

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: What are the elicitation approaches and techniques cited in the literature? RQ 2 : What are the most suitable elicitation approaches and techniques cited in the literature to understand business processes? RQ 3 : 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.

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

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.
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.

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 WinApp-Driver 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].

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].
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.

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.

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.

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].

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.

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.

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.

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.

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.

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.

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?

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. 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%).

Overview of Studies
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.

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.    On the other hand, Table 3 presents the 24 approaches discovered during the review.  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-gridbased 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.

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.

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.

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: Most studies introduced methods to elicit requirements for general software.
Only two studies elicited requirements for BPAS, but both were in academic contexts. L 3 : The methods ignored the changes in business processes during the BPAS development. L 4 : Most methods ignored the characteristics of business processes and the difficulties to develop BPAS. L 5 : Most methods did not properly regard the needs of the organization in an automation context. L 6 : 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.

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.