Many established techniques and modeling methods for business process management (BPM) are known. Since many of them are domain-independent, they can also be applied for requirements engineering within software development processes. In order to build a bridge between requirements engineering and the BPM body of knowledge, this paper first identifies 26 basic process characteristics (e.g., duration of cycle times). A classification is created, which recommends built-time methods for agile as well as traditional (e.g., waterfall model) software development processes. For both types, this contribution discusses the application of the most suitable BPM techniques (e.g., case management for agile processes vs. variants of BPMN for traditional development processes). Software development processes (SDP) are used to handle a structured and professional implementation of requirements engineering (RE) [WK00]. The orientation towards business process management (BPM), understood as the organization of activities (e.g., requirements engineering), events (e.g., specification sheet approval), resources (e.g., change request databases) and individuals (e.g., developers), is an essential core characteristic of Software Engineering (SE) [Mü12]. In literature, it is widely accepted, that the explicit application of BPM techniques to SE makes a significant contribution to the professionalization required in business practice (e.g. [LT99;Vo10;HKW14;Mü12]). As [Vo10] point out in their trend study, it has always been the core of BPM to model processes that transfer the requirements of users (process customers) into the development of software (process participants). In particular for RE, there are numerous new methods discussed in the BPM field. Many approaches are domain-independent or transferable to other business areas. As a consequence, RE as essential part of SE can
benefit from two fundamental different groups of BPM techniques5 [Fe05], which are also differentiated in known maturity models: • •
Pre-deployment: Numerous techniques exist for the efficient assessment of processes (e.g., notations, workshop organization rules, role models) before it is actually implemented. Many case studies show that simple improvements as well as underlying resources may already be detected by modeling (“build”) the actual state of a process [Ko10].
Post-deployment: Numerous methods (e.g., scorecards) as well as tools (e.g., test automation software) are used in SE during the execution (“running”) of the SDP. In BPM, however, many domain-independent best practices are known to support the organizational and technical handling of processes after deployment (e.g., workflow and groupware management systems).
In the lifecycle of a process [LSK17], these two groups distinguish recognized methods according to whether they are supportive in the planning of processes or its implementation. Studies (such as those by [LT99;Vo10]) show that many companies can already achieve significant professionalization by modeling workflows. Such findings are also known in publications on SE [LC06]. This paper therefore focuses on the first group mentioned because they are also relevant in requirements engineering. In RE, two basic paradigms (traditional vs. agile development processes) are known [GSM06]. Coming from a process-oriented view on these paradigms, they have fundamentally different workflow characteristics (for example robustness vs. flexibility, pre-definition of processes vs. knowledge-based ad-hoc decisions). Also, their goals (e.g. communicated in an i*-model) result in fundamentally different process characteristics. Whether a user is allowed to ask for continuous adjustments (agile procedure) or whether an executable software exists only at the end of the development (traditional procedure) is known in advance as a basic decision. Accordingly, corresponding BPM techniques may not be equally well suited for both traditional and agile development processes.
In order to be able to assess which BPM techniques can be used to professionalize a procedure, often process characteristics are used. In evaluations, [Le16] and [LHB15] showed that such central process properties are generally known in advance (for example, because they are dictated by a classical or agile paradigm). Moreover, it proven for many situations that their consideration supports the selection of BPM techniques. For example, [LHB15] successfully showed scenarios for the selection of executing software for a given set of process characteristics. In addition, numerous studies show that essential process properties in the SE affect the suitability of BPM techniques [KN08;HLB14;BRZ05]. This is discussed in particular in the step of the RE. 5 The terms “pre-deploy” and “post-deployment” are used in this publication. Both are both known in the jargon of the BPM and the SE community. However, there are concepts and terms that are more appropriate for each of the disciplines (e.g., “build-time” vs. “run-time” or “modeling” vs. “implementation”).
Business Process Management Approaches in RequiremenEtsnEgnignieneereirningg 22157 It should be up to this contribution to clarify, which BPM pre-deployment techniques can successfully lead to added value for which type of SDP.
This paper will therefore answer the following questions:
Which basic process characteristics determine the suitability of business process management pre-deployment techniques? Which pre-deployment techniques are suitable for the fundamental types of software development processes? Section 2 briefly describes the related work. To answer the first question, section 3 outlines a general model, which links pre-deployment techniques with fundamental process properties. This model is then used in Chapter 4 to give an assessment of which software development processes should rely on which BPM findings. Chapter 5 expands the theses of this contribution by showing further steps for bridging between BPM and RE.
Both questions will be answered in one workshop contribution to provide researchers and practitioners with coherent arguments. Question 1 lays the theoretical and scientific foundation for a fundamental link between existing BPM and SE knowledge. The exemplary discussion on the results (question 2) gives practitioners the chance to benefit directly from the findings of question 1. Scientists receive a basis for argumentation in order to get into the detailing of the techniques and procedures. 2
Software development is performed in processes [SL02]. While these are different in their basic requirements, it is agreed that small (e.g., prototyping) and large software developments (e.g., according to the waterfall model) follow a fundamental process model [SL02;RBP09].Nevertheless, the major part of science and research on SDPs is related to the classical project management [BS06;RBP09]. On the one hand, primarily methods of project management (e.g., personnel planning, time monitoring, quality measurement) are adapted to the requirements of SE. From a BPM perspective, on the other hand, individual software developments should be seen as instances of a development process [AS06]. When authors from the SE domain take this processoriented view, their focus is mostly on technical or normative aspects. Technical publications show, for example, theoretical models for software quality, mathematical simulation possibilities for development processes or algorithms for the improvement of coding. The BPM literature pursues not only technical aspects but also mainly investigates organizational aspects. In terms of normative aspects, SE publications aim to implement process-oriented frameworks as best practices. For example, experts from the SE often describe ISO and CobIT processes to increase the software quality [SL02]. Hence, BPM best practices are usually seen isolated for individual processes (such as standards for change management, risk management, program management). Fundamental BPM paradigms (e.g., adaptive case management), which could be applied to many tasks of the SE, are therefore not pursued [XK00;WK00;SL02]. There are, in fact, textbooks and studies that address the combination of BPM modeling techniques and RE. In most cases, these publications stem from SE (e.g.,[AS06]). It is noticeable that they were published especially in the years of 2000 to 2010. This could be due to the fact that in this time more aspects of open development processes (such as open source software) were addressed [Ko05]. This shift away from closed innovation – similar to the idea of human-centered computing [SGD06] – depends on the interaction between people. These can be customers or volunteers, who play an active role in the process (e.g., advisor or developer). BPM publications have been addressing such challenges of openness with specific solutions for a number of years under the slogan of Social BPM and BPM 2.0 [LSK17].
Based on a qualitative literature analysis, publications were identified and codified.
Following the inductive approach by [Ma08], first relevant databases were selected, then
search terms were used to come up with a comprehensive database. To answer the first
research question, a comprehensive list of pre-deployment techniques was developed.
Following the definitions of [Al05;La94], we subsume under this term all textual and
graphical methods, notations, best practices, industry standards, and procedures to plan
and design the actual state of a process [Wi05]. Several scientific databases were
investigated, in which typical state of the art knowledge from the BPM discipline is
suspected (e.g., Business Source Complete and SpringerLink). No results have been
taken into account fro
The same methodology and the same databases were used to identify the process characteristics. However, the steps of an inductive category building were carried out for the collection and listing following the methodology by [EK08]: In contrary to the techniques, which are exposed to be part of trends and also hypes, the literature recognizes that at a high-level view (e.g., strategy formulation) processes already have a fixed set of known characteristics. They serve as the basis for the selection of analytical methods, BPM tools and also control mechanisms [HLB14]. Such characteristics of a process prior to its modeling have been the subject of various studies (see section 2). A list could be created by systematically searching for combinations such as "BPM" and keywords like "properties", "structure", "mark", "feature" and "requirement". A classification scheme is generated to connect the two building blocks of the model. Using the idea of a Target Activity Grid [BW09], it was evaluated which technique can
Business Process Management Approaches in RequiremenEtsnEgnignieneereirningg 22179 be used for which process characteristic in a table-like representation. For this purpose, two experienced experts were asked for individual assessments. Both experts have a practical background in the usage of the techniques or can estimate their range of application by own research and teaching practices. A boolean assessment is used to evaluate whether the technology can adequately satisfy a processes characteristic or not. Based on 15 publications, which give statements on basic process traits, a total of 23 process characteristics could be identified in the analysis (see Table 1, more names are given in Table 2). The values of the properties can be assessed partially on nominal and partially on ordinal scales (see cells in columns of Table 1). As a rule, a process needs to fall into at least one value of the process characteristic properties, but can hold more than one. For the 9 process characteristics in the row at the bottom of Table 1 no scale is provided by literature. In such cases an ordinal 3-scale was assumed, using 'high', 'medium' and 'low' as properties. This scaling is usually sufficient for use in a theoretical model since the meaningfulness of the process characteristic can be evaluated quick enough by the model user. For further processing each property value is assigned a scaling number from 1 to 5. Key findings on characteristics and their scaling are taken from [LSK17;Va03;NP11;Jo12;LHB15;Ci15;Br11] loosely structured unstructured Among the identified pre-deployment techniques there are classical notations (e.g., BPMN), but also approaches that do not focus on the formal design of processes in the first place. There are established and frequently discussed approaches (e.g., BPM 2.0), but also techniques that are in the early stages of development and application (e.g., BPMN-D). A total of 31 BPM techniques is included in the model. Table 2 presents the evaluation table, which combines pre-deployment techniques (columns) with fundamental process characteristics (rows). An entry in the table cells indicates that the technique can be used when a process holds this value of the characteristic. Characteristics
\ Pre-deployment techniques Tab. 2: Classification scheme combining process characteristics with pre-deployment techniques
Business Process Management Approaches in RequiremenEtsnEgnignieneereirningg 22291 4
After the general classification approach was developed, it is now used to answer the second research question. For company-independent application, general assessments must be filled into the model. This means it is necessary to assess the extent to which the two fundamentally different SDPs (traditional and agile) follow the process characteristics developed in the last section. In order to avoid company-specific peculiarities in the user input, which might influence the overall assessment, two scientists have made the assessment. With a total of more than 70 publications and more than 30 years of research as well as teaching experience in the field of process management, the two researchers have a broad experience in the BPM and SE field. The mini Delphi study serves as method. After their assessment, individual deviations were subject of a face-to-face discussion. Although it is a qualitative research, the tabular classification is also suitable for the application of a simple scoring algorithm. The number of hits (h) per technique does not give any proof in a quantitative sense, but it is intended to support the discussion as a general assessment. As a result of the methodology, the characteristics of the two SDPs stereotypes can be obtained. The order of the evaluations presented can be understood as a vector of the 23 properties from Table 2. • •
Traditional Process Development Processes: The expert assessment for the traditional SDPs (e.g., waterfall model) is as follows6.
[(2);(3);(1,3);(1,2,3);(3);(2);(3);(1);(3);(1);(2);(1);(3);(1);(3);(1);(1);(1);(1);(2);(3);(1);(3)] Agile Development Processes: For agile SDPs (for example according to the idea of SCRUM), the expert assessment led to the following values.
[(4);(3);(2);(1,2,3);(1);(1);(1);(2);(1);(3);(1);(3);(1);(3);(1);(2);(3);(3);(3);(1);(1);(3);(1)] 6 The values in brackets refer to the scaling number of the property (cell entry in each row of Table 1), identified as valid for 'traditional'. 5
In the following paragraphs, an excerpt of the resulting recommendations for or against specific pre-deployment techniques is discussed. Table 3 outlines the top 3 recommendations. The number of hits results from counting.
Agile Techniques Ad-hoc BPMN Collaborative BPM / Design Thinking / Adaptive Case Management (ACM) Social BPM / Collaborative Case Management (CCM)/ Emergence Case Management (ECM)
Hits 18 17 16
Traditional Techniques BPMN choreography diagram / Hierarchical BPMN Miner uBPMN / BPMN light / BPMN-D BPMN Gamification / BPMNDiffViz / Modelling Software Processes using BPMN / Process mining (flat) / BPMN4CP / BR+SWS / BPM Reuse
Hits 19 18 17 The discussion is intended to give first indications7, which areas of application and possibilities result from essential BPM techniques in the two SDPs. This section will in particular show that the BPM techniques support the general mind-set behind the different approaches in the SE with special attention to RE. Since the classical software development requires many departments to collaborate both professionally and technically, the BPMN choreography diagram (h=19) is particularly suitable. It models the exact and complete control flow across department or team boundaries (e.g., specification, testing) with a particular focus on communication. In the stages of the waterfall model, the process manager has to have an overview of the stages of development, but the internal behavior of subjects are not that relevant in his/her view. Since it is not stipulated in the traditional view of software development to step backwards (for example development only after the complete specification), this technique supports collaboration in SDPs with a particularly formal technique. If this explicit pre-modeling is not possible, the technique of the Hierarchical BPMN Miner (h=19) is suitable. It is known that the pre-definition of fundamental development stages (e.g., as milestones) is possible. However, many further developments of traditional SE (for example, the V-model XT) have resulted in particular from the realization that not all activities can be determined exactly (e.g., which requires all stakeholders to meet to come up with the requirements). The recommended pre-deployment technique supports this weakness by automatically analyzing and comparing BPMN models. In this sense, it is understandable why BPM Reuse (h=17) is recommended as a pre-deployment technique as well. This is due to the fact that satisfying process control flows (e.g., 7 In further research (see also section 6), it is necessary to examine the specifications for individual combinations (SDPs including sub-categories and BPM technique including further developments), how the co-operation (e.g., use of requirements specifications) can be applied in practice.
Business Process Management Approaches in RequiremenEtsnEgnignieneereirningg 23213 development instances that produced high-quality software within the given budget) must be recognized and imitated. By doing so, this technique supports one of the major challenges of SE since its discipline foundation. Following the same consideration, the recommendation of uBPMN is very suitable (h=18). The idea behind this further development of BPMN lies in the continuous technology implementation in many processes activities. Ubiquitous computing technology is currently a much-debated form of IT-enabled information processing, which is entering more and more areas of daily life and work (trend of “digitization”). In software development, many steps have always been PC-supported. Also, typical human-centric steps (e.g., a story telling workshop) result in digital information (e.g., requirement lists), which is passed on to the next development stages. An interesting recommendation is the notation BPMN-D (h=18). Once again, the BPMN standard is being further developed. However, the normative character of the notation is successively reduced by the inclusion of declarative elements. This means that both imperative (i.e., fixed control flows, events, and communication flows) as well as optional and soft content can be modeled. This technique paves the way for agile methods, which allow for the clearance and implementation of activities (e.g., the order of implementation of requirements). BPMN light (h=18) follows the same tendency, when it aims at that not all contents of the development process can or must be modeled in detail. Rather, this technique focuses on the fact that the process model is well understood by users. This simplification is an important point in classical software development: process models are often powerful and large. However, they must be understood by the teams (e.g., developers) to secure compliance. 5.2
As many properties for agile methods fundamentally differ from those of the traditional SDP, the recommendations are almost inverse. The handling of individual requirements (e.g., written in user stories) in short sprints goes along with the core idea of case management. Instead of defining all necessary steps to achieve a final result (i.e., the executable software) in advance, individual requirements (e.g., features, masks, data streams) are implemented one after another. Agile approaches (e.g., SCRUM) can therefore apply the idea of Adaptive Case Management (h=17), in which the modeling (i.e., planning of the team organization) is combined with the execution (i.e., actual software development) of workflows. The peculiarity of the adaptivity is to provide good workflow parts (e.g., good activity combinations) as reusable templates. They can be accessed again if the requirements of another instance (e.g., sprint planning) are similar. This case approach, which has been laid down in medicine for decades, has also received increased popularity in SE in recent years. The same applies to aspects addressed within Emergence Case Management (h=16) as a sub-form. Ad hoc BPMN receives the highest value in the recommendation (h=18). The application of the technique is certainly not useful for overall development (e.g., steps of sprint planning, daily SCRUM, development and a retrospective). Rather, this technique can be applied in the individual sprint parts, if the exact way to implement a feature is not yet known - similar to cases. For example, ad hoc BPMN allows changes in the parallelization of tasks. It fits well into the basic conditions of agile development (e.g., on-site customer, team in a room, pair programming). What is striking is that, with Social BPM (h=16) and Collaborative Case Management (h=16), techniques are recommended that rely heavily on the competences of the process teams. The common idea of both techniques is that people involved in the process (for example developers, testers) should influence the design of the processes. This means that these individuals no longer merely assume the execution of the processes, but can also provide an important input for improvements in the predeployment phase. It therefore corresponds precisely to the core idea of the agile manifesto. With concrete SCRUM methods, such as the retrospective, many agile development processes follow this social BPM view. The recommendation of the relatively new method of design thinking (h=17) for agile SDPs is easily comprehensible. In fact, there is a large interaction between many agile methods to generate and document customer needs (such as story-telling for requirements engineering) and techniques from design thinking (such as customer journeys for understanding a customer’s view). 6
Based on the idea that numerous good practices and methods from the field of process management can be used for SE, 31 pre-deployment techniques for the design of processes have been identified. Since traditional and agile SDPs are fundamentally different, a general classification scheme for an assignment has been developed. Based on 28 typical process characteristics, the most appropriate methods for each SDP type were discussed. While BPMN including various further developments can be used for example in the waterfall model, case- or social-driven techniques are suitable for agile approaches such as SCRUM. Although we used a common approach for literature analysis [Ma08] and relevant databases as well as comprehensive search words, there might be more material to exploit. It is up to future work to enhance the database in order to further test the hypothesis. An ongoing evaluation by the authors, which uses recommended techniques in real-life scenarios, may provide further practical guidance in further publications. In addition, it should be the subject of further research how the actual and internal collaboration may look between the recommended BPM techniques and the SE steps (e.g., how, when, and where exactly functional or non-functional requirement statements can be used in which BPM step). This contribution provides the general scope of such investigation. In further research, also attempts can be made to extend the methodology for post-deployment techniques. In addition, further studies may provide quantitative evidence for the findings of this research.
Business Process Management Approaches in RequiremenEtsnEgnignieneereirningg 23235 7 [HKW14] Heinrich, R.; Kirchner, K.; Weissbach, R.: IEEE 1st Int. Workshop on the Interrelations between Requirements Engineering and Business Process Management (REBPM).
Proceedings, IEEE, 2014.
Allweyer, T.: Geschäftsprozessmanagement, Controlling. W3l, Herdecke, 2005.
Acuna, S.T.; Sánchez-Segura, M.I.; New Trends in Software Process Modeling. World Scientific, New Jersey, 2006.
Brambilla, M.; Fraternali, P.; Ruiz, C.V.:A model-driven approach to Social BPM applications. Social BPM Handbook, BPM and Workflow Handbook Series 2011, pp. 95112, 2011.
Boehm, B.; Rombach, H.D., Zelkowitz, M.V.: Foundations of Empirical Software Engineering. Springer, 2005.
Best, E.; Weth, M.: Geschäftsprozesse optimieren. Gabler, Wiesbaden, 2009.
Di Ciccio; D.; Marrella, A.; Russo, A.: Knowledge-Intensive Processes: Characteristics, Requirements and Analysis of Contemporary Approaches. Journal on Data Semantics 4, pp. 29-57, 2015. [KT05]
Kasi, V.; Tang, X.: Design Attributes and Performance Outcomes: A Framework for Comparing Business Processes. In (SAIS Eds.): In Proceedings of the 10th Southern Association for Information Systems, 2005. und
Workflow[WK00]
Wang, Y.; King, G.; Software Engineering Processes. CRC, London, 2000.