The manual construction of business process models is a time-consuming and errorprone task. While recommendation systems are widely used and auto-completion functions are a standard feature of programming tools, such techniques are rarely applied in commercial BPM tools although implementation strategies have already been suggested. Therefore, this paper collects requirements from different perspectives (literature and empirical studies) of how to effectively and efficiently assist process modelers in their modeling task. The condensation of requirements leads to a catalog, which provides a solid foundation to implement Process Modeling Recommender Systems (PMRSs). The contents in this paper represent a shortened version of the full paper. The original work summarized in this extended abstract has been published in [Fe15].
Business process modeling and reorganization are still among the top-ten of relevant topics of today’s CIOs [Lu13]. However, the construction of semi-formal process models is even today, after two decades of research on business process modeling, a highly manual task that can be challenging, especially for unexperienced modelers. It might not be easy to figure out where to start and stop modeling and on which abstraction level to model [Wi10, Ni113] since guidance in modeling is largely missing in current tools. These barriers call for process modeling support features, which assist users during process modeling and make suggestions how to complete a currently being edited process model. Such assistance functions are common features in programming environments or e-commerce systems (e.g., amazon.com). Although it has been demonstrated that assistance functions are beneficial in these domains, assistance functions are rarely considered in commercial BPM tools. Therefore, it should be a priority to offer assistance functions in process modeling tools. However, it seems that auto-completion of programming snippets is easier than auto-completion of graphical process models. This may be caused by a variety of attributes and characteristics such as syntactic consistency, semantic validity, completeness and readability that influence the decision for an appropriate subsequent fragment. Since giving recommendations in modeling is not straightforward, we elicit and present a requirements catalog for Process Modeling Recommender Systems (PMRSs). This is not a trivial task and it should be noted that the elicitation and specification of requirements are considered to represent quite difficult processes in the area of requirements engineering [La02]. In this way, we expect that our contribution will fertilize the discussion and development of assistance functionality in process modeling, which already has been identified as useful [KHO11]. 2
The goal of the paper that is summarized here is to provide a holistic view on requirements for PMRSs. For achieving this, relevant scientific works were inspected conducting a systematic literature review as well as different empirical studies were carried out within two years. With regard to the latter, we performed three studies, namely (i) a short online-survey about modeling support functionality, (ii) a case study, and (iii) a survey at a major fair that was based on a live-demonstration of a prototypical implementation. The first and the last of the mentioned case studies also largely involved business users (especially the last one, a live-demonstration and survey at a major fair, CeBIT). Summing up, the research process followed can be characterized to be exploratory in nature [SLP09], where the results from literature as well as from users gradually consolidate the set of requirements, which are finally synthesized into a structured collection. Our research process is depicted in Fig. 1. In order to provide a catalog of requirements, we consolidated the plethora of requirements that were elicited according to the procedure sketched in Section 2. For a detailed description of the elicited requirements from the literature (RL), the survey (RS), the case study (RC) and the prototype (RP), we refer to the original article [Fe15]. During this consolidation process, we at first combined redundant requirements and then detected and consolidated requirements that are subsumed by others. Finally, we further classified the requirements as being functional (FUNC), non-functional (NFNC), architectural (ARCH) or data-related requirements (DATA). We decided for these categories for the following reasons. The distinction between functional and non-functional requirements is well known in systems and software engineering. However, we additionally distinguish between requirements concerning the data since these are an important precondition of a PMRS as well as requirements concerning the architectural perspective. The latter ones are relevant in respect to the provisioning of the system. Table 1 shows the integrated results.
Req.
No.
R01 R02 R03 R04 R05 R06 R07 R08 R09 R10
Recommendation of basic constructs Recommendation of additional objects Innovative and intelligent recommendations Provision of context and meta-information Quality and relevance of recommendations Easy handling of the recommendations Personalized recommendations Knowledge base management and evolution Advanced features Multiple interfaces and platforms
RL1 RL2, RP1-2 RC2, RP7 RL3-4, RC1, RS2, RP8 RL5, RL10 RL6, RL8-9, RS3-4, RC6 RL7 RL11, RP3, RC3 RC4-5 RL12, RP4-6, RS1
C N U F
C N F N
H C R A
A T A
D ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ What can be seen when looking at Table 4 is that the distribution of source requirements according to their type being one of RC, RL, RP or RS is not equal. One requirement was detected exclusively by analyzing the case study and three exclusively by the literature analysis. Seven requirements were detected by two or more types of source requirements. Only one requirement was detected by all four types. It thus can be concluded, that the derivation of requirements from different sources such as the literature analysis and the survey, the case study and the prototype presentation in fact is valuable and leads to a more holistic elicitation of requirements.
Although sophisticated modeling tools exist, guidance in process modeling in terms of auto-completion and recommendation features is largely missing even in today’s tools. In the contribution [Fe15] that is summarized by the paper at hand, we therefore systematically collected requirements for such features as a first step towards the stepwise iterative development of PMRSs guiding the modeler in modeling. We derived the requirements deductively from literature as well as inductively by three empirical studies conducted within two years that involved both practitioners and students. We hope that our requirements catalog may be useful and serve as a point of reference both for researchers and the industry engaged with the development of PMRSs.
Lauesen, S.: Software Requirement: Styles and Techniques. Addison Wesley, Harlow, England, 2002. [SLP09]