Process-oriented documentation of user requirements for analytical applications4challenges, state of the art and evaluation of a service-based configuration approach

In recent years, the integration of process design in conjunction with the use of analytical applications to provide information tailored to user requirements to support operational process activities (e.g., Operational BI) has become increasingly widespread. In analytical software development/implementation projects, the insufficient involvement of analytical end users with their process context and the resulting unclear requirements/expected analytical software functions are still one of the main reasons for analytical project failure. Embedded in a Design Science Research Process, this paper shows the shortcomings of existing approaches, tools and models (1. BPMN process model extensions, 2. configurators in analytical applications, 3. models used in analytical implementation projects) for the documentation/conceptual configuration of analytical requirements. As a second part, this paper presents the evaluation results of a new process-oriented and service-based configuration approach for analytical applications, whose practicability, usefulness and acceptance were evaluated in expert reviews and in analytical development projects.


A. Main topic and challenges
ROCESS orientation has established itself in corporate practice since the 1990s as a primary structuring approach for corporate organizational forms and as the basis for a (re)organization of operational value-adding activities. In addition to the efficient linking of tasks, which is the initial focus of process-oriented design, the targeted use and visualization of information required in processes is becoming increasingly important [1] in times of advancing digitization and automation of corporate processes [2]. P Systems of insight [3] or rather analytical applications have long been used for retrospective analysis of corporate activities for the management under the keyword Business Intelligence (BI). Due to a wider dissemination of analytical information in operational processes and the subsequent process-centric design of static analytical reports and interactive dashboards [4], original focus and functional range of analytical application/BI design [5] have widened. Additional aspects include 1. the trend to a modular analytical application structure [6], 2. the consideration of analytical self-services [7] and 3. the implementation of real-time monitoring and automatic actions [8], [2] (Section III.A).
Concerning the development of analytical applications, the insufficient inclusion of end users with their process context and the resulting unclear requirements/expected deliverables are repeatedly cited in literature as the main causes for project failure or for the implementation of analytical applications that does not meet user expectations [9], [10]. Own results from interviews and an online survey with experts in analytical requirements management confirm this hypothesis: five of the experts surveyed find inadequately communicated/documented requirements are very frequent, four experts find them rather frequent and only two experts find them less frequent as a main reason for delayed or insufficient implementations of analytical applications.
In addition, practice-oriented literature provides evidence for a number of detailed causes for delays or failure of analytical development projects. Some of them already point out important aspects that must be better taken into account in future user-and process-oriented conceptual analytical application configuration in terms of requirements documentation. These include: 1. Unclear ideas on the users9 side about goals, functionalities and detailed system specifications due to insufficiently elaborated and planned project scopes, information needs and use cases [11], [10]; 2. Requirements formulated by users in an unclear and/ or misleading manner and the resulting misunderstandings among technical developers [12], [9]; 3. Data privacy risks known to the process users and not considered right from the start throughout requirements elicitation and documentation [9], [13]; 4. Uncoordinated planning and implementation of individual data analyses within overall processes [14] leading to fragmented and insufficiently integrated analytical application landscapes and impeding the data-driven process design. These aspects suggest the fact that models, configurators and other tools used in the documentation of requirements for process-related analytical applications in implementation projects are apparently insufficient.

B. Objective of the current work
In the context of the above-mentioned challenges, the results presented in this paper show a broad overview about the current state of the art concerning tools and models for configuration and conceptual modeling of analytical applications. The new results extend and supplement an earlier literature review regarding scientific models supporting requirements documentation for analytical applications (c.f. [15], summary in Section III.B) and investigate additional alternatives to configure analytical applications: -Applicability of process modeling languages to represent information requirements (Section III.C); -Availability of models for requirements documentation/conceptual configuration provided with analytical application products (Section III.D); -Use of tools for requirements documentation in analytical development projects (Section III.E). The results confirm the need for new tools to document/configure user requirements regarding analytical applications from a process-oriented perspective. As a second part of this paper, the authors present detailed results of expert reviews regarding the completeness and usefulness of a new approach for the conceptual configuration of analytical applications based on analytical services (initially presented in [15], short introduction in Section IV.A) and its practicability in the context of process-related analytical requirements documentation proofed in two real projects. This leads to the following two research questions: RQ1: What support do models and tools from science and practice provide regarding documentation/configuration of process user requirements for analytical applications?
RQ2: To what extent is a configuration approach for analytical services suitable to be used in analytical implementation projects and to solve the identified challenges regarding documentation/configuration of process user requirements for analytical applications?

C. Structure of this paper
After the introduction of the subject area of this paper, the identification of current challenges and relevant process-oriented trends as well as the presentation of the paper's objectives in Section I, Section II presents the research method. Section III provides the current state of the art regarding different tools and models for documenting conceptual requirements for analytical process support in science and practice. Section IV shows the practical relevance of the new process-oriented configuration approach for analytical applications (initially introduced in [15]) based on evaluation results. Section V concludes the paper.

II. RESEARCH METHOD
The research results presented in this article have been elaborated as parts of a wider research project developing a comprehensive modeling approach for the documentation/configuration of conceptual process user requirements for analytical applications (for further details see [15]). A six-step Design Science Research Methodology Process [16] guides this superordinate research project. Within the first Design Science phase "Problem Identification and Motivation", the following research methods were used to develop the new research results presented in the current paper: -The modeling language Business Process Model and Notation (BPMN) served as a starting point to find suitable representations to configure analytical process requirements due to its leading position as a worldwide used process-modeling standard [17], [18]. The analysis (Section III.C) encompassed all previous BPMN extensions surveyed by [19]. -Analytical products were analyzed to determine whether they provide pre-built models/configurators for documenting business user requirements (Section III.D). This analysis comprised all 13 analytical products in the quadrants "Leaders", "Visionaries" or "Challengers" of "Gartner Magic Quadrant for Analytics and BI Platforms 2021" [20]. Investigation techniques included both interviews with software providers and the analysis of product information. -Four interviews were conducted with project managers/ experts responsible for requirements management. They confirmed that requirements documentation is still a critical, and so far an insufficiently supported success factor in analytical implementation projects. In addition, an online survey conducted with six experts in analytical requirements management from practice (about 125 participants of an event for analytics specialists were invited via e-mail) provided further feedback regarding the quality of different models, notations and documents used in this area (Section III.E). In the fifth phase "Evaluation" of the overall Design Science Research Process, the previously developed configuration approach for analytic services and its intended integration into process models [15] was evaluated with regard to its usefulness/practical value (proof of value) [21] and its acceptance by the model users (proof of acceptance) [21], [22]. For this purpose, content-related feedback on the model structure (i.e., regarding the selected analytical services, their relationships to each other (service network) and the design of the service-internal service features) was collected in 12 expert reviews [21] with 17 experts in the field of analytics (project/requirements managers, data scientists). After the final definition of the analytical service network structure (after the third expert review), 13 experts provided an additional quality assessment (Section IV.B). Furthermore, the configuration approach has been tested in two analytical development projects (1. Machining Daily Demand report 774 PROCEEDINGS OF THE FEDCSIS. SOFIA, BULGARIA, 2022 for an industrial enterprise; 2. Population Forecasting dashboard for a healthcare company) (Section IV.C).

A. Relevant characteristics for tools/models
Analytical/BI applications that can be successfully used in practice are characterized by the fact that they provide 1. the right information at 2. the right time in 3. a suitable presentation form and generated with 4. the right analysis methods to 5. the right users [5]. The following additional design aspects (identified in a literature review) for tools/models supporting the configuration of analytical applications address the denoted detailed causes for delays or failure of analytical development projects mentioned in Section I.A: 6. Models utilized by business users (causes 1 + 2): Requirements documentation tools should be designed for users [23] to get them more involved in the analytical design process. 7. Graphical modeling notation (cause 2): Graphical models in requirements documentation [24] provide a more intuitive access to conceptual models [25]. 8. Provision of configuration alternatives (causes 1 + 2): Providing configuration alternatives in analytical requirements models [26] ensures acceleration of selection decisions and reduces the risk of misleading requirements descriptions. 9. Data privacy (cause 3): An examination of the planned analytical use cases from a data privacy perspective is an important task within the requirements analysis to prevent extensive adjustments during the implementation of analytical applications [27]. 10. Process-relation (cause 4): A strong link to process design in the phase of requirements elicitation and requirements documentation [1] has a positive effect on an analytical information provision that is coordinated between the process activities. To stress the deep integration of operational processes with analytical applications (accompanied and pushed, e.g., by the dissemination of approaches such as "Business Process Intelligence", "Business Activity Monitoring", "Operational BI" [28] and "Context-Oriented Analytical Applications" [29] in research and practice), further important requirements aspects regarding analytical application design (identified in a literature review) must be added: 11. Service-oriented design: To support the adjustment of analytical applications due to changing processes [6], the modularized provision of subcomponents of analytical applications as reusable analytical services in terms of service-oriented architectures (SOA) [4], [30] enables customer-centric service provision [31] as well as the (re)combination of analytical components from different providers [32]. 12. Self-services: To enable rapid customization of analytical applications [7] due to changes in process information demand, analytical self-service applications should enable process staff to independently adapt or create analytical reports/dashboards, to integrate new data, to check and/or improve data quality and to adjust analytical data models [33]. 13. Automatic actions: The proliferation of IoT assets and their integration into operational process controls [34], the acceleration of operational applications (e.g., faster data storage structures) and direct interconnections between systems of data origination and data use are drivers for "real-time enterprises" with the ability to react immediately to occurring events [35]. Business Activity Monitoring (BAM) applications [8] monitor process executions to identify threshold violations or error events and support the automated/rule-based execution of actions. As a consequence of the aspects listed above, tools/models for the conceptual configuration of analytical applications in order to document user requirements should address these various aspects to improve their usefulness for practice. This is examined in more detail in the following subsections.

B. Scientific models to support the configuration of requirements for analytical applications
The structured literature review (presented in more detail in [15]) with regard to scientific models for analytical requirements documentation and configuration encompassed a very broad search space (<requirements= AND <analytical software= OR <information systems=) in order to obtain results without restrictions in the perspectives of observation (e.g., business engineering) and business domains (e.g., production). The analysis of 13 identified requirements and configuration approaches [26], [36]- [47] aimed to identify to what extent these approaches comprehensively ("X"), partially ("(X)"), or do not ("-") address the requirement aspects enumerated in Section III.A. The results of this analysis showed that none of these approaches even comes close to addressing all aspects, with major deficits in the areas >provision of configuration alternatives<, <serviceoriented design=, <process-relation=, <periodicity=, <presentation=, <automatic actions=, <self-services= and <data privacy= (Table I).

C.Representation of information requirements in process modeling languages
In addition to the modeling approaches just described, which focus on the configuration of analytical applications/requirements, process-modeling languages can describe information requirements from the process design perspective as well. The standard process modeling languages widespread in practice (e.g., Business Process Model and Notation (BPMN), Extended Event Driven Process Chain (eEPK), UML Activity Diagram) contain the socalled information or data objects, which represent informational inputs in or outputs from process activities in graphical process models. However, the information or data objects in the standard versions of the above-mentioned process notations are only black-box objects unveiling just an identifier without further details (e.g., without content specification, the origin of information or the way of information provision). With these modeling objects, it is not possible to provide a comprehensive specification of a desired information provision [48]. The same abbreviated black-box representation applies to process-relevant databases and software applications.
In addition to the standard versions of process modeling notations, a large number of notational extensions especially for BPMN have emerged (surveyed by [19]). Many of them support the representation of technical and dataoriented content not included in this research. This involves the representation of technical data models (e.g., [49]) and the representation of backend data flows, data changes and technical interactions with data stores (e.g., [49], [50]).
Besides these technical approaches, there are also modeling extensions focused on individual domain-specific requirements aspects, which predominantly do not address the specification of analytical requirements. These BPMN model extensions represent process requirements in specific application domains/industries such as disaster management [51]. The only exception is [52], but this approach considers just a very small part of the user-oriented re-quirement spectrum of analytical applications with the specification of threshold values for specific key figures to support simulation runs (addressing "data/information" and "automatic actions" (c.f. Table I)).

D. Conceptual configurators for analytical application products
The conceptual configuration of analytical products belongs to the product configuration, which pursues the goal of specifying the quality and structure of product-relevant characteristics [53]. The product configuration distinguishes the customer-inherent configuration (customers/users can select product parameters/characteristics freely) as well as the customer-coherent configuration (customers/users can select predefined parameter sets) [53].
First, a configuration system consists of a configuration component as a content-logical model with configuration elements, configuration variants and their relations. Furthermore, a presentation component allows the interaction between the configuration system user and the configuration component [54]. For the implementation of configuration systems in the special context of software configuration, different kinds of configurators/configuration models are applicable [55]: 1. Software reference models to analyze the potentials of a software product including the description of data structures, operational transactions (functions) and supported processes, 2. checklists for the interactive and systematic reduction of the configuration area regarding a (standard) software product by a question and answer dialogue between user and system, and 3. preconfigured systems as exemplary preselected configuration variants for a homogeneous target group. In the case of a flexible conceptual application configuration by users themselves or in

Selfservices
Data privacy [40] - direct interaction with the users, the focus in this current work lies on conceptual configuration models in the form of checklists/requirements catalogs. The availability of analytical self-service functions within software tools, which could also be regarded as a type of user-sided configuration of analytical applications, is deliberately excluded from this study about the provision of configuration systems in practical products. This is due to the use of analytical self-service functions requires certain in-depth technical or data-related knowledge that cannot be assumed from users of analytical applications (especially casual users like telephone agents in call centers). Furthermore, due to a reduction of complexity, analytical self-service functions represent only a limited part of the actual functional range and available design variants of analytical tools, and thus offer self-service users only limited options for system (re-)design and a comprehensive implementation of their requirements.
The analysis of analytical products with regard to prebuilt models/configurators for documenting business requirements (e.g., as a support function for implementation projects) included all product vendors except niche players in the "Gartner Magic Quadrant for Analytics and BI Platforms 2021" [20]: Microsoft, Tableau and Qlik in the <Leaders= quadrant; MicroStrategy, Domo and Google (Looker) in the <Challengers= quadrant; and Sisense, ThoughtSpot, Oracle, SAS, SAP, Yellowfin and TIBCO Software in the <Visionaries= quadrant. Within all examined analytical software products, there are no specific models/configurators to support the collection of user requirements. Taking the example of Microsoft Power BI, available limited support in this area includes the specification of textual change requests regarding existing dashboards/reports via a comment function (plain text without structuring guidelines). Furthermore, in some tools it is possible to integrate external software development applications (e.g., Github) to maintain requirements. To support collaborative development, some vendors establish community areas to collect and discuss ideas for further developments/adaptations of the standard functions of the tools. However, this does not serve to specify/configure concrete requirements for individual use cases.
As an example, TIBCO Software explicitly stated that the provision of models for product-specific application configuration/requirements documentation is deliberately not offered as a part of its own tool. This means that software vendors pass the responsibility and the choice of suitable requirements configurators/documentation models to the external implementation partners.

E. Requirements documentation in the context of analytical development projects
Referring to an own online survey (n=6, Section II provide more information about the research method) about tools and models used in analytical implementation projects for requirements documentation, Table II shows the mentioned models and documents and their prevalence in practice (column <Sum=). Textual and unstructured/less structured use case descriptions are by far the most widespread tool for requirements documentation. It is worth mentioning here that with use case descriptions, the users with their concrete (usage and operating) requirements have already moved into the center of attention, meanwhile conventional formats such as requirements specification sheets seems to play a minor role. They are followed at some distance by both the content-structured requirements catalogs (checklists) and data models. However, data models are not able to provide even a complete picture of the various requirement facets (e.g., with respect to structural and graphical design of user interfaces, access and distribution paths of information) due to their purely dataoriented view.
As expected and in addition to the one-sided (technical) data models and the mockups (belonging rather to the technical implementation area), requirements catalogs perform best in terms of achievable completeness of requirements content (Table II). This happens because requirements catalogs already mention various design alternatives of an analytical application, which can thus be considered or deliberately excluded from the beginning of application development. Requirements catalogs are also obviously well suited to achieve requirements documentations that are under-

Models/documents Very good Good Less good Bad Sum
Textual user story 1 3 2 -6 Requirements catalog Requirements specification sheet standable both for business users and developers (Table III), since here (in contrast to the lower rated purely textual documents) structural relationships and terminologies are already defined [56] to facilitate the creation of a common understanding. Requirements catalogs also reached a positive score regarding the frequency of inconsistencies (Table IV), because a clear requirements structure in catalogs can be recognized and compared more easily than content in unstructured continuous texts (e.g., use case descriptions).
A similar result emerges how data privacy risks are taken into account in requirements documentation (Table V): Textbased documents got a worse score here, while requirement catalogs at least received a better rating. It is remarkable that no model/document was able to achieve a very good rating. This again substantiates the still inadequate consideration of data privacy risks in requirements documentation.
One expert in this survey provided detailed information about the specific requirements catalog models used in projects. These are the cross-domain requirements templates according to [56] to create requirements in form of sentences with specific content placeholders in a particular order, which ensures a uniform way of formulating requirements. Unfortunately, this predefined formulation structure alone does not provide any information about the structural and content design of domain-specific applications and the relevant analytical requirements aspects and variants. Based on these results, requirements catalogs seem to be best suited for documenting requirements with regard to the design of analytical applications from a practical point of view in terms of a complete, consistent and unambiguous provision of content. Furthermore, a new requirements catalog for analytical applications should encompass the specific functional and non-functional properties of this software domain, as well as actively consider the other model aspects described in Section III.A.

A. Presentation of the modeling approach
The configuration approach already presented in more detail in [15] enables the configuration of analytical services to document requirements in process contexts. The use of services in the sense of encapsulated functions connected via standardized interfaces [3] allows the flexible conceptual (re-)configuration of analytical applications. The configuration approach is appropriate for different analytical use cases, business domains, data formats as well as analysis methods. It can be classified as a customer-inherent product configuration [53] in order to permit a modular orchestration of analytical components/services.
The configuration approach is based on the distinction of three different configuration areas (cf. [15]): -Use Case-Specific Configuration Content enables the specification of individual reports/dashboards. -Configuration Content for Analysis Preparation describes the required functional scope in the area of analytical self-services. -Use Case-Overlapping Configuration Content addresses design aspects that affect the entire analytical application.
Requirements specification sheet Each configuration area contains a set of analytical service types, which can be configured in more detail (c.f. Fig.  4-7) to describe specific aspects of the analytical application more precisely. Fig. 1 shows the service network for the Use Case-Specific Configuration Content with its associated analytical service types on four levels and their logical interconnections. In this way it describes reports/dashboards, their diagrams as well as the key figures displayed therein and the underlying basic data. Fig. 2 Modeling objects for the internal configuration of analytical services [15] Fig . 2 shows the different modeling objects available for the graphical configuration of the specific service features within the individual analytical services (c.f. Fig. 4-7). In order to be able to represent the interconnection of the analytical services needed to configure a specific analytical use case (in terms of a specific dashboard or report) in connection with the related process activity, the analytical services are represented as data objects (e.g., Fig. 3) in BPMN pro-cess models. To make the respective analytical service types distinguishable, the BPMN data objects bear specific identifiers (c.f. [15]).

B. Results of the expert reviews
Within the intensive review sessions (c.f. Section II), the analytical experts got an overview about the whole configuration approach for analytical services (Section IV.A) concerning the three specific interconnected analytical service type networks ( Fig. 1 and [15]) within the three different configuration areas (Section IV.A), and about the numerous service type-specific graphical service feature configurations (e.g., Fig. 4-7). As a result, the experts confirmed that the configuration approach has a predominantly high and increased potential benefit for practice (Table VI). This concerns in particular the areas of unambiguity and completeness of content, modularization of requirements and the possibility of reuse, the identification of new design options, obtaining an overview about analytical process support and using the instantiated models as a starting point for deriving a technical concept. It is also noteworthy that this approach was rated with a predominantly higher added value compared to models previously used in these companies.

C. Presentation of evaluation use cases
Based on the positive evaluation by the experts (Section IV.B), the configuration approach was tested in a healthcare project to develop a dashboard presenting annual Popula-  tion Forecast information in different counties in the federal state of Saxony. In this project, some planning for the dashboard design had already been done before. Based on this, all analytical services needed to describe the entire analytical use case (from the basic data to the key figure calculation and visualization up to the integration in the dashboard) were configured together with three development team members (project manager, data analyst, analytical developer). Due to the numerous design features and design variants considered in the different analytical services, some new facets and features of the dashboard that had not yet been considered in the previous development were identified. The elaborated analytical service models subsequently served as the conceptual basis for further dashboard implementation. The positive feedback from the three experts involved (high benefit: 16 times; increased benefit: 16 times; less high benefit: 3 times; low benefit: 1 time; willingness to use in future projects: 3 out of 3) (Table  VI) was clear evidence of the usefulness, acceptance and, in particular, practicability of the configuration approach in implementation projects. In a second case study, the configuration approach was used to configure a Machining Daily Demand report in an industrial enterprise. This case study was not developed in the middle of an ongoing project with analytical experts, but rather at the beginning of the requirements elicitation process together with a requirements provider from the business department. This report should inform a storekeeper in near real-time which parts from stock are needed in which quantities, according to the current planning for the supply of the daily production. To obtain an overview, Fig. 3 shows the process model for this use case with the interconnections of all involved analytical services. The "Performance Indicator Service" (Indicator-S) (Fig.  4) plays a central role in the use case. The calculation of the indicator "Machining Daily Demand" should not only take into account the "Basic Data Service" (Data-S) "Production Program Data" provided at the beginning of a day's production, but also consider events in the upstream parts flow and the resulting dynamic changes for the supply of the other parts ("Direct Supply Stream Data" (Fig. 5); c.f. service interconnections in Fig. 3). The "Alerting and Automation Service" (Alert-S) defines to monitor the development of the indicator and to trigger an automatic on-screen warning message and a control instruction to a robot if the threshold is exceeded (Fig. 6). Finally, the "Report Service" specifies the access conditions for the prospected user role (storekeeper) (Fig. 7). Based on identified challenges in practice for the documentation of process-related requirements in the context of analytical software development in combination with challenges emerging with process-oriented analytics, this work has shown that neither scientific approaches (requirements models for analytical applications; process modeling languages and their language extensions), analytical products nor the textual documents and models predominantly used in implementation projects for requirements documentation are able to sufficiently address these challenges and the essential analytical design aspects. Furthermore, evidence was provided by experts that a service-based conceptual approach for the customer-inherent [53] configuration of analytical services [15] addressing all 13 requirements aspects relevant for analytical application development (Section II-I.A) leads to a predominantly increased to high benefit for analytical development projects.
The applied research design did not comprehensively investigate all facets of this topic, and this leaves opportunities for further research. A more extensive investigation of configuration models used in analytical implementation projects could yield additional design recommendations for the further development of the configuration approach. Furthermore, in the current approach, data objects with a label of the service type and a unique identifier represents the analytical services in the process models. Future research activities could investigate which essential service features from the detailed service models could expand the content to be represented in the data objects (using extension mechanisms for type definitions available in BPMN) to visualize more detailed information about analytical process support directly in the process models.