=Paper=
{{Paper
|id=Vol-2060/rebpm3
|storemode=property
|title=Taking Advantage of Business Process Management Approaches in Requirements Engineering
|pdfUrl=https://ceur-ws.org/Vol-2060/rebpm3.pdf
|volume=Vol-2060
|authors=Matthias Lederer,Werner Schmidt,Albert Fleischmann,Remzi Avci
|dblpUrl=https://dblp.org/rec/conf/modellierung/LedererSFA18
}}
==Taking Advantage of Business Process Management Approaches in Requirements Engineering==
https://ceur-ws.org/Vol-2060/rebpm3.pdf
Ina Schaefer, Loek Cleophas, Michael Felderer Nachname
(Hrsg.): 2018,
< Buchtitel>,
Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 223
Requirements Engineering und Business Process Management (REBPM) 15
Taking Advantage of Business Process Management
Approaches in Requirements Engineering
An Assessment Model based on Process Characteristics
Matthias Lederer 1, Werner Schmidt 2, Albert Fleischmann 3, Remzi Avci 4
Abstract: 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).
Keywords: Business Process Management, Software Development Process, Software
Engineering, Pre-deployment Techniques, Process Characteristics.
1 Motivation
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
1
ISM International School of Management, Karlstraße 35, D-80333 Munich, matthias.lederer@ism.de
2
Technische Hochschule Ingolstadt, Esplanade 10, D-85049 Ingolstadt, werner.schmidt@thi.de
3
Albert Fleischmann, InterAktiv Unternehmensberatung, Oldenburger Str. 231, D-26203 Wardenburg,
albert.fleischmann@interaktiv.expert
4
Universität Erlangen-Nürnberg, Lange Gasse, D-90404 Nuremberg
224 Vorname1
16 Matthias Nachname1
Lederer, Werner Schmidt,Nachname2
und Vorname2 Albert Fleischmann, Remzi Avci
benefit from two fundamental different groups of BPM techniques 5 [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”).
Taking Advantage of Business Process Management Approaches in Requirements
Engineering
Business Process Management Approaches in Requirements Engineering 225
17
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:
1. Which basic process characteristics determine the suitability of business process
management pre-deployment techniques?
2. 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 Related Work
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 process-
oriented 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).
226 Vorname1
18 Matthias Nachname1
Lederer, Werner Schmidt,Nachname2
und Vorname2 Albert Fleischmann, Remzi Avci
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].
3 Domain-Independent Selection of Pre-deployment Techniques
3.1 Methodology
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 from before the year 2012. To find relevant results, the search term
“BPM” (including synonyms) was combined with descriptions for pre-deployment (e.g.,
“modeling”, “acquisition”, “elicitation”, “identification”).
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
Taking Advantage of Business Process Management Approaches in Requirements
Engineering
Business Process Management Approaches in Requirements Engineering 227
19
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.
3.2 Results
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]
1 2 3 4 5
PC_1 Structuring
Structured structured with ad hoc structured with predefined loosely structured unstructured
exceptions exceptions
PC_2 Process Representation
Activity oriented Rule oriented Artefact oriented - -
PC_3 Process Implementation
Workflow engine Rule engine Program control flow - -
PC_4 Trend orientation
Data-driven Case-driven Social-driven - -
PC_5 Process participants
Person to person Person to application Application to Applic. - -
PC_6 Knowledge intensity
Knowledge-intensive Automated/Repeatable - - -
PC_8 Interrelatedness
Linked explicitly Inferred link - - -
PC_9 Collaboration intensity
Collaborative Semi-collaborative Non-collaborative - -
PC_11 Value repetition
Ad hoc Administrative Collaborative Production -
PC_16 Implementation
Big bang Step by step - - -
PC_17 Process instantiation
Automated Semi-automated Manual - -
PC_23 Process cycle time
Long-running Medium Short running - -
PC_7, 10,12, 13, 14, 15, 18, 19, 20, 21, 22
High Medium Low - -
Tab. 1: Process characteristic properties and their scaling
[LSK17;Va03;NP11;Jo12;LHB15;Ci15;Br11]
228 Vorname1
20 Matthias Nachname1
Lederer, Werner Schmidt,Nachname2
und Vorname2 Albert Fleischmann, Remzi Avci
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
P_12: BPMN choreography diagram
\
P_13: Hierarchical BPMN Miner
Pre-deployment
P_17: simulation-based BPMN
techniques
P_15: BPMN (flat) Mining
P_5: BPMN Gamification
P_24: Collaborative BPM
P_27: Design Thinking
P_11: BPMNDiffViz
P_4: Deontic BPMN
P_6: Ad-hoc BPMN
P_25: Social BPM
P_22: BPM Reuse
P_10: BPMN4RS
P_18: BPMN4CP
P_21: BR + SWS
P_7: BPMN light
P_3: BPMN Plus
P_16: BPMN-D
P_31: BPMN-Q
P_20: RrBPMN
P_9: ArC-BPM
P_26: BPM 2.0
P_19: EDBPM
P_8: AC-BPM
P_2: uBPMN
P_14: BPMN
P_1: S-BPM
P_23: iBPM
P_28: ACM
P_29: CCM
P_30: ECM
PC_1 1 1 3, 4, 4, 5 1 4, 5 1, 2 1 1 1, 2, 1 1 1, 2, 1, 2 1 3 1 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 3, 4, 1 3, 4, 1 4, 5 4, 5 4, 5 1
Structuring 5 to5 3 to5 3 5 to5 5 to5
PC_2 Process 3 1, 2, 1, 3 1, 2 1, 2 1 1 1 3 1, 3 1, 2 1 1, 2, 3 1, 2 1, 2 1, 2 1, 2 1, 2 2, 3 2 1, 3 1, 2 1 1 1 1 1 1 1 3
Represen-tation 3 3
PC_3 3 1, 2, 1, 3 1, 2 1, 2, 1 1 1, 3 3 1 1, 2, 3 1, 2, 3 1, 3 1, 2 1, 2, 2, 3 1, 2 2, 3 2, 3 1, 3 2 1 1 1, 3 1 1 1 1 3
Process 3 3 3 3 3
Implemen-tation
PC_4 1, 3 1, 2 1, 2 2 2, 3 2 2 1 1 1, 2 1 1, 2 1 1, 2 1 2 1 1, 2 2 1, 2 1 1, 2 1 3 3 3 3 2 2 2 1
Trend orientation
PC_5 Fixation of 2, 3 2, 3 2, 3 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 1 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 2, 3
the process ,3
participants
PC_6 2 2 2 2 2 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 1, 2 1 1 1 2
Knowledge
intensity
PC_7 Diversity 2 2 1 2 2 1 2, 3 1, 2 1, 2 2 2 3 2, 3 1, 2 3 2, 3 1, 2 1, 2 1, 2 2 2 1 1 1 1 1 1 1 1 1 1
of Information
PC_8 1 1 2 2 1, 2 2 1 1 1 1 1, 2 1 1, 2 1 1 2 1 1 1 1 1 1 1 2 1, 2 2 1, 2 2 2 2 1
Interrelatedness
PC_9 Collabo- 1 1, 2, 1, 2, 1, 2, 1, 2 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2 1, 2, 1, 2, 1 1, 2 1, 2 1, 2 1, 2, 1 1, 2 1 2 3
ration intensity 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
PC_10 1 1 1 1 1 1, 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Value
PC_11 Value 4 4 4 4 4 1, 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 3 3, 4 3, 4 3, 4 3 3, 4 3, 4 4
repetition
PC_12 Pre- 1 1 1 1 1, 2, 3 1, 2 1 1 1, 2 1 1 1, 2 1 1 1 1 1 1 1 1 1 1 3 1, 2, 3 1, 2, 3 3 3 1
dictability 3 3 3
PC_13 3 3 1 1 1, 2, 1 2, 3 3 3 2, 3 3 3 2, 3 3 3 3 3 3 3 1, 2, 1, 2, 3 3 3 1, 2, 1 1, 2, 1 1 1 3
Flexibility 3 3 3 3 3
PC_14 1 1 1, 2 2 1, 2, 3 1, 2 1 1 1, 2 1 1 1 1 1 1 1 1 1 1 1 1 1 2, 3 1, 2, 3 1, 2, 3 3 3 1
Model-ability, 3 3 3
control and
automation
PC_15 3 2 2 3 1, 2, 1 2, 3 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 2, 3 2, 3 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2 1, 2 1, 2 1, 2,
Complexity 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
PC_16 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2
Implementation
PC_17 Process 1 1, 2 1, 2 1, 2 1, 2 2, 3 1, 2, 1, 2 1, 2 1, 2 1 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 1, 2 2, 3 1, 2 1, 2 1, 2 2 2, 3 2 2 2, 3 3 2 2, 3 1, 2
instan-tiation 3
PK_18 1, 2, 1, 2 1, 2, 1, 2, 1, 2 3 1, 2, 1 1 1, 2 1 1 1 1 1 1 1 1 1 1 1 1 1 3 3 2 3 3 3 3 1
Robustness 3 3 3 3
PC_19 1, 2, 1, 2, 1, 2, 1, 2, 2, 3 1, 2 2 1 1 2 1 1, 2 1 1 1 1 2 1 3 2 1 1 2 1 2 2 1 1 1 1 2
Adaptability 3 3 3 3
PC_20 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 2, 3 1 1 1, 2 1 2, 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2
Adaptivity 3 3 3 3 3 3
PC_21 Selection 1, 2 1, 2, 1, 2, 1, 2, 2, 3 1, 2 2, 3 1, 2 1, 2 2 1, 2 2, 3 1 1, 2 2 2, 3 1 1 2 1 1 1 1 1 1 1 1 1 1 2 2
3 3 3
PC_22 IT needs 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1, 2 1 1 1 1 2, 3 1 1, 2 1, 2 1, 2 1, 2 1, 2, 1
3
PC_23 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2,
Process cycle 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
time
Tab. 2: Classification scheme combining process characteristics with pre-deployment techniques
Taking Advantage of Business Process Management Approaches in Requirements
Engineering
Business Process Management Approaches in Requirements Engineering 229
21
4 Application for Software Engineering
After the general classification approach was developed, it is now used to answer the
second research question.
4.1 Methodology
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.
4.2 Results
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 follows 6.
[(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'.
230 Vorname1
22 Matthias Nachname1
Lederer, Werner Schmidt,Nachname2
und Vorname2 Albert Fleischmann, Remzi Avci
5 Discussion
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 Traditional
Techniques Hits Techniques Hits
Ad-hoc BPMN 18 BPMN choreography diagram / Hierarchical BPMN Miner 19
Collaborative BPM / Design Thinking / Adaptive Case 17 uBPMN / BPMN light / BPMN-D 18
Management (ACM)
Social BPM / Collaborative Case Management (CCM)/ 16 BPMN Gamification / BPMNDiffViz / Modelling Software 17
Emergence Case Management (ECM) Processes using BPMN / Process mining (flat) / BPMN4CP /
BR+SWS / BPM Reuse
Tab. 3: Classification scheme combining process characteristics with pre-deployment techniques
The discussion is intended to give first indications 7, 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.
5.1 Traditional Software Development Processes
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.
Taking Advantage of Business Process Management Approaches in Requirements
Engineering
Business Process Management Approaches in Requirements Engineering 231
23
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 Agile Software Development Processes
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.
232 Vorname1
24 Matthias Nachname1
Lederer, Werner Schmidt,Nachname2
und Vorname2 Albert Fleischmann, Remzi Avci
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 pre-
deployment 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 Summary and Outlook
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.
Taking Advantage of Business Process Management Approaches in Requirements
Engineering
Business Process Management Approaches in Requirements Engineering 233
25
7 References
[Al05] Allweyer, T.: Geschäftsprozessmanagement, Controlling. W3l, Herdecke, 2005.
[AS06] Acuna, S.T.; Sánchez-Segura, M.I.; New Trends in Software Process Modeling. World
Scientific, New Jersey, 2006.
[BR11] 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. 95-
112, 2011.
[BRZ05] Boehm, B.; Rombach, H.D., Zelkowitz, M.V.: Foundations of Empirical Software
Engineering. Springer, 2005.
[BS06] Bittner, K.; Spence, I.; Managing Iterative Software Development Projects. Addison-
Wesley, Boston, 2006.
[BW09] Best, E.; Weth, M.: Geschäftsprozesse optimieren. Gabler, Wiesbaden, 2009.
[Ci15] 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.
[EK08] Elo, S.; Kynglas, N.: The qualitative content analysis process. Journal of Advanced Nursing
62, pp. 107-115, 2008.
[Fe05] Ferstl, O.; Sinz, E.J.; Eckert, S.; Isselhorst, T.: Wirtschaftsinformatik 2005: eEconomy,
eGovernment, eSociety. Wiesbaden, Springer, 2005.
[GSM06] Geras, A.; Smith, M.; Miller, J.: Configuring Hybrid Agile-Traditional Software Processes.
In: (Abrahamsson, P; Marchesi, M.; Succi, G. Eds.): Proceedings of the 7th International
Conference Extreme Programming and Agile Processes in Software Engineering. Springer,
Oulu, pp. 104-113, 2006.
[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.
[HLB14] Huber, S.; Lederer, M.; Bodendorf, F.: IT-enabled Collaborative Case Management:
Principles and Tools. In (Smari, W.W.; Fox, G.C.; Nygard, M. Eds.): Proceedings of the
2014 International Conference on Collaboration Technologies and Systems. IEEE,
Minneapolis, pp. 259-266, 2014.
[Hu04] Huo, M.; Verner, J.; Zhu, L.; Babar, M.A.: Software Quality and Agile Methods. In (SC
Eds.): Proceedings of the 28th Annual International Computer Software and
Applications Conference. IEEE, pp. 1-6.
[Jo12] Joachim, M.: Process Measurement in Business Process Management: Theoretical
Framework and Analysis of Several Aspects. KIT Scientific Publishing, Karlsruhe, 2012.
[KN08] Koch, S.; Neumann, C.: Exploring the Effects of Process Characteristics on Products
Quality in Open Source Software Development. Journal of Database Management 19, pp.
3008-3035,2008
[Ko05] Koch, S.: Free/open Source Software Development. Idea Group, Hershey, 2005.
[Ko10] Kobler, M.: Qualität von Prozessmodellen. Logos, Berlin, 2010.
234 Vorname1
26 Matthias Nachname1
Lederer, Werner Schmidt,Nachname2
und Vorname2 Albert Fleischmann, Remzi Avci
[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.
[LA94] Leymann, F.; Altenhuber, W.: Managing business processes as information resources. IBM,
1994.
[LC06] Lee, M.C.; Chang, T.: Applying TQM, CMM and ISO 9001 in Knowledge Management
for software development process improvement. International Journal Services and
Standards 2, pp. 101-115, 2006.
[Le16] Lederer, M.: Business Process Transparency Management. University Erlangen-Nürnberg,
Nürnberg, 2016.
[LHB15] Lederer, M.; Huber, S.; Bodendorf, F.: BPM-Tools im Überfluss – Wie strategische
Kriterien die Auswahl des richtigen IT-Werkzeugs beeinflussen. In (Berglehner,F.; Wilbers,
K. Eds.): Schulisches Prozessmanagement, Nürnberg: Texte zur Wirtschaftspädagogik und
Personalentwicklung, 2015.
[LK05] List, B.; Korherr, B.: An Evaluation of Conceptual Business Process Modelling Languages.
In (ASC Eds.): Proceedings of the 2006 ACM symposium on Applied computing. SAC,
Dijon, pp. 1532-1539.
[LSK17] Lederer, M.; Schott, P.; Knapp, J.: The Digital Future has Many Names - How Business
Process Management drives the Digital Transformation. In (IEEE Eds.): Proceedings of the
6th International Conference on Industrial Technology and Management. IEEE, Cambridge,
pp. 22-26, 2017.
[LT99] Luo, W.; Tung, Y.T.: A framework for selecting business process modeling methods.
Industrial Management & Data Systems 99, pp.312-319, 1999.
[Ma08] Mayring, P.: Qualitative Inhaltsanalyse. Beltz, Weinheim, 2008.
[Mü12] Münch, J. et al.: Software Process Definition and Management, Berlin: Springer, 2012.
[NP11] Niehaves, B.; Plattfaut, R.: Collaborative business process management: status quo and quo
vadis. Business Process Management Journal 17, pp. 384-402, 2011.
[RBP09] Royce, W.; Bittner, K.; Perrow, M.: The Economics of Iterative Software Development:
Steering Toward Better Business Results. Pearson, 2009.
[SGD06] Seffah, A.; Gulliksen, J.; Desmarais, M.C.: Human-Centered Software Engineering.
Springer, Heidelberg, 2006.
[SL02] Stiller, E.; LeBlanc, C.: Project-based Software Engineering. Addison Wesley, Boston,
2002.
[Va03] van der Aalst, W.: Business Process Management. ISRN Software Engineering, 2013, pp.
1–37, 2003.
[Vo10] vom Brocke, J. et al.: Current and Future Issues in BPM Research. Communications of the
Association for Information Systems 28, pp. 393-412, 2010.
[Wa09] Wang, Q. et al.: Trustworthy Software Development Processes: International Conference on
Software Process. Springer, Vancouver, 2009.
[Wi05] Wittges, H.: Verbindung von Geschäftsprozessmodellierung und Workflow-
Implementierung. DUV, Berlin, 2005.
[WK00] Wang, Y.; King, G.; Software Engineering Processes. CRC, London, 2000.