BPM and requirements elicitation at multiple levels of abstraction: A review

Abstract

Business process models can be useful for requirements elicitation, among other things. Software development depends on the quality of the requirements elicitation activities, and so adequately modeling business processes (BPs) is critical. A key factor in achieving this is the active participation of all the stakeholders in the development of a shared vision of BPs. Unfortunately, organizations often find themselves left with inconsistent BPs that do not cover all the stakeholders' needs and constraints. However, consolidation of the various stakeholder requirements may be facilitated through the use of multiple levels of abstraction (MLA). This article contributes to the research into MLA use in business process modeling (BPM) for software requirements by reviewing the theoretical foundations of MLA and their use in various BP-oriented approaches.

Full text

BPM AND REQUIREMENTS ELICITATION AT MULTIPLE
LEVELS OF ABSTRACTION: A REVIEW
Carlos Monsalve1, 2, Alain April2 and Alain Abran2
1CIDIS-FIEC, Escuela Superior Politécnica del Litoral (ESPOL)
Km. 30.5 vía Perimetral, Guayaquil, Ecuador
2Software Engineering Research Laboratory, École de technologie supérieure (ETS)
1100 rue Notre-Dame Ouest, Montréal, Québec, Canada
ABSTRACT
Business process models can be useful for requirements elicitation, among other things. Software development depends
on the quality of the requirements elicitation activities, and so adequately modeling business processes (BPs) is critical. A
key factor in achieving this is the active participation of all the stakeholders in the development of a shared vision of BPs.
Unfortunately, organizations often find themselves left with inconsistent BPs that do not cover all the stakeholders’ needs
and constraints. However, consolidation of the various stakeholder requirements may be facilitated through the use of
multiple levels of abstraction (MLA). This article contributes to the research into MLA use in business process modeling
(BPM) for software requirements by reviewing the theoretical foundations of MLA and their use in various BP-oriented
approaches.
KEYWORDS
Business process modeling, levels of abstraction, requirements elicitation, requirements modeling, review.
1. INTRODUCTION
Business process models were designed to help document, communicate, or improve an organization’s
business processes (BPs) as part of a BP management initiative. BP models are also used by software
engineers and business analysts for requirements elicitation and analysis (Mayr et al., 2007, IIBA, 2009).
Software development is dependent on the quality of the requirements elicitation activities (Abran et al.,
2004). It is critical, therefore, that BPs be adequately modeled. A key factor in creating a high quality BP
model is the active participation of all the stakeholders in the development of a shared vision of BPs (Sedera
et al., 2004, Becker et al., 2000). Unfortunately, the literature shows that organizations find it difficult to
establish this level of participation: the lack of truly cross-departmental business process modeling (BPM)
initiatives; the lack of a consensus on BPM notations; and the growing complexity of these notations.
A recent study by Harmon (Harmon and Wolf, 2010), for instance, shows that only 23% of BPM projects
are cross-departmental initiatives that involve all stakeholders (i.e. most often they are departmental
initiatives led by either IT or management stakeholders).
The evidence also reveals that different stakeholders are accustomed to using different notations,
conventions, and techniques to represent BPs (Monsalve et al., 2010). Some authors have reported that it can
be very difficult to choose a single BPM notation that will allow effective communication between
stakeholders (Monsalve et al., 2010, Dreiling et al., 2008).
Other authors point out that BPM notations have become highly complex over the years, as a result of the
attempt to satisfy the multiple BP perspectives required by stakeholders (Muehlen and Recker, 2008). Even
then, the most popular BPM notations still lack the constructs to appropriately use BPM for requirements
elicitation (Monsalve et al., 2010).
The difficulties inherent in developing a shared vision of BPs may create inefficiencies and duplications,
resulting in numerous communication problems, the need for rework, software engineering project delays,
cost overruns, and, perhaps, failure. Solving these difficulties requires the means to consistently model
IADIS International Conference Information Systems 2011
237

various BP perspectives. Ideally, the solution should be simple, and not significantly increase the complexity
of BPM notations. This would allow BP models to be easily understood by all stakeholders.
A solution involving identification of the modeling constructs for representing a specific BP perspective
is proposed by Monsalve et al. (Monsalve et al., 2010). One of the pillars of this proposal is an MLA
(multiple levels of abstraction) analysis. Based on that proposal, this article contributes to the research on
MLA use in BPM by reviewing the theoretical foundations of MLA and its use in various BP-oriented
approaches.
The structure of this article is as follows. Section 2 presents a review of the theoretical foundations of
MLA. Section 3 describes the use of MLA in various BP-oriented approaches. Finally, section 4 concludes
with a review of the contributions of this research, its limitations, and future work.
2. THEORETICAL FOUNDATIONS
Business process management developed from the various recommendations that have been proposed to
increase the competitiveness of organizations, either by improving the quality of their products and services
(Elzinga et al., 1995), or by improving the performance of their BPs (Zairi and Sinclair, 1995). It is strictly a
management approach, and not a technology or a type of information system. Smith and Fingar (Smith and
Fingar, 2007) have pointed out that one reason why organizations have not been undertaking this form of
management is that it has been considered as an IT initiative.
BPM has been used for requirements elicitation by both software engineers and business analysts. Each of
these professions has a guide to its body of knowledge: the Software Engineering Body of Knowledge
(SWEBOK), and the Business Analysis Body of Knowledge (BABOK) respectively. The SWEBOK (Abran
et al., 2004) presents requirements elicitation as a complex activity that has to consider various stakeholders
“at different levels of an organization.” The BABOK (IIBA, 2009) also stresses the importance of
considering all types of stakeholders. In both cases, the various requirements must be represented in a
consistent and structured way, in order to guarantee that they are understood by all stakeholders.
Therefore, the inclusion of management and IT stakeholders is a key factor for both BPM and
requirements elicitation, as each type of stakeholder provides the means to represent their particular modeling
needs in a consistent way.
Many authors (Dreiling et al., 2008, Berger and Guillard, 2000, Bhat and Deshmukh, 2005, Gulla and
Brasethvik, 2000, Haque et al., 2003) have argued that the use of MLA helps in the selection of the
information to be provided to the various types of stakeholders. The BABOK recommends the use of MLA to
represent their perspectives. The BP model should move from a “high level” to a “low level”, depending on
the stakeholder targeted (IIBA, 2009).
This review looks at the various managerial activities of the organization . One approach to classifying
these activities, which has been used for a long time, is Anthony’s model (Anthony, 1965, Gorry and Morton,
1971). It defines three levels of activity: strategic, tactical, and operational. The strategic level covers all the
activities related to the goals and policies of the organization. The tactical level deals with the procurement
and efficient use of resources. The operational level deals with the efficient and effective execution of
specific tasks. Anthony’s model has influenced both the design of commercial BPM notations, such as
Qualigram (Berger and Guillard, 2000), and recent BPM research (Bhat and Deshmukh, 2005, Haque et al.,
2003). Moreover, Berger and Guillard (Berger and Guillard, 2000) maintain that the recommendations of the
International Organization for Standardization (ISO) for documenting BPs reflect the three levels of activity
found in organizations. It can be argued that even organizations that have not adopted the traditional pyramid
structure host stakeholders with various levels of information needs which respond to the types of activities
being performed at a particular time.
3. MLA AND ITS USE IN BP-ORIENTED APPROACHES
MLA is commonly used in a number of BP-oriented approaches. This section reviews the use of MLA in: 1)
process-oriented management approaches; 2) BPM notations; and 3) recent BPM research proposals.
ISBN: 978-972-8939-47-2 © 2011 IADIS
238

3.1 MLA in Management-Oriented Approaches
Among the management-oriented BP approaches in which MLA is commonly used, some that, to our
knowledge, are structured in three layers are presented below.
3.1.1 The Balanced Score Card
The Balanced Score Card (BSC) (Kaplan and Norton, 2007) defines four perspectives: financial, customer,
internal process, and innovation/learning. The internal process perspective focuses on the core BPs of the
organization, and is structured in three layers (mission, objectives, and measures).
Table 1. MLA in management approaches
3.1.2 The ISO 9000 Family of Standards
The ISO 9000 family of standards (ISO, 2008, ISO, 2009) follows an approach that recommends three levels
of documentation (quality manual, description of BPs, support records), reflecting the three levels of
managerial activity (Berger and Guillard, 2000).
3.1.3 The Supply Chain Operations Reference Model
The Supply Chain Operations Reference model (SCOR) (Council, 2008) proposes a process reference model
with three description levels: 1) top; 2) configuration; and 3) process element. The information to be
represented at each level is depicted in Table 1.
Note in Table 1 that a management-oriented approach typically presents three layers of abstraction. Also,
these approaches consider that it is important to include both customers and providers in the BP modeling
process. (Inter-level equivalences are not shown in this table.)
3.2 MLA in BPM Notations
Several BPM notations were investigated in the course of this research. We present here only those notations
that use levels of abstraction similar to those proposed in Anthony’s model.
3.2.1 The Qualigram Language
Qualigram (Berger and Guillard, 2000) proposes three levels of abstraction (see Table 2). The top level
(strategic) models the processes, answering the questions “why?” and “where to?” The intermediate level
(organizational) models the procedures, answering the questions “who?” and “what?” Finally, the lowest
level (operational) models the work instructions, answering the questions “how?” and “using what?”
3.2.2 The Architecture of Integrated Information Systems
The Architecture of Integrated information Systems (ARIS) defines five enterprise perspectives, each
presenting three description levels: requirements definition, design specification, and implementation
description. From a BPM point of view, ARIS works on three levels: 1) strategy, 2) design, control, and
optimization, and 3) execution (Scheer et al., 2005, Davis, 2008). In addition, ARIS suggests a BPM
hierarchy composed of three abstraction levels: high-level process, functions, and tasks (Davis, 2008).
Anthony’s Model BSC Process
Perspective ISO 9000 SCOR Process Reference Model
Level Content Content Content Level Content
Strategic Goals, objectives Mission Quality Manual Top level Scope, types
Tactical Resources Objectives Business
Processes Configuration
level Description and configuration
of processes
Operational Specific tasks Measure Support records Process element
level Details of each process: inputs,
outputs, information, metrics.
IADIS International Conference Information Systems 2011
239

Table 2 summarizes the modeling notations reviewed. All use a three-layered approach. (Inter-level
equivalences are not shown.)
Table 2. MLA in BPM notations
3.3 MLA in BPM Research Proposals
Having reviewed the use of MLA in BPM notations, this section presents its use in selected BPM
publications. The majority of the proposals found in the literature also recommend modeling BPs at three
levels of abstraction (see Table 3). However, the content of each abstraction level varies from one proposal to
another, and depends on the author.
Bhat and Deshmukh (Bhat and Deshmukh, 2005) argue that, in order to share a common vision of BPs, a
hierarchy topped by a business process level representing the core processes of the organization is necessary.
This hierarchy includes two additional levels (i.e. process workflow and business procedure) to address the
individual requirements of the various stakeholders, as depicted in Table 3.
Haque et al. (Haque et al., 2003) contend that experiments in both industry and academia have yielded
better results when both organizational and technological issues are considered, rather than only the latter.
They propose to model BPs at three levels of abstraction, as depicted in Table 3.
Lin et al. (Lin et al., 2002) analyze various BPM notations to find the “essential components” of BPM,
and propose a BPM method that uses three levels of abstraction, as depicted in Table 3.
Table 2. MLA in BPM research proposals
Anthony’s Model Qualigram ARIS
Level Content Level Content Perspective
views BPM point of view Process
model
hierarchy
Strategic Goals,
objectives Level 1.
Process Processes, sub-
processes,
objectives.
Requirements
definition Strategy level High-level
processes
Tactical Resources Level 2.
Procedure Procedures,
instructions, roles. Design
specification Design, control and
optimization level Functions
Operational Specific
tasks Level 3. Work
instruction Instructions,
operations, tools,
documents.
Implementation
description Execution level Tasks
Bhat&
Deshmukh
Level Business processes Process workflow Business procedures
Content Core processes Workflow and sub
processes Procedures, tasks, system info,
details
Haque, Pawar, &
Barson
Level Level 3. Company
strategy Level 2. Functional &
Process phase Level 1. Operating team
Content Strategy, goals. High level business
processes, functions. Details of organization
&providers’ processes.
Lin, Yan, and Pai Level Gross grained Medium grained Fine grained
Content Supply chain network Core processes Functionality of each process
Gulla &
Brasethvik
Level Business Workflow Functional
Content Goals, strategy Workflow, roles, tools,
resources ERP point of view of business
processes
Dreiling,
Rosemann, van
derAalst, & Sadiq
Level Management Business analyst Technical
Content High level business
processes, inter-relations Rich detail (workflow),
some rigor, intuitive
notation
Information required for the
implementation of the systems
ISBN: 978-972-8939-47-2 © 2011 IADIS
240

Gulla and Brasethvik (Gulla and Brasethvik, 2000) propose three levels of abstraction (see Table 3). They
conclude that “in practice, the process models are usually combinations of all these three [levels].”
Dreiling et al. (Dreiling et al., 2008) argue that, if a BP model is generated for a specific purpose, then it
probably will not be reused for any other purpose. They propose three levels of abstraction (see Table 3). The
management-oriented level depicts the big picture of BPs. The BA-oriented level aims to facilitate
communication between business analysts (BAs) and users. The technically oriented level adds rigor to the
models. Each level may use a different BPM notation. To integrate the various notations, a mapping at a
meta-level is proposed.
Table 3 summarizes the research proposals reviewed. (Inter-level equivalences are not shown.)
4. CONCLUSION AND FUTURE WORK
The SWEBOK and the BABOK stress the importance of considering the requirements of all the stakeholders
at the various levels of an organization. The BPM lessons learned suggest that any BPM initiative must
consider both groups of stakeholders: management and IT. Despite the multiple efforts, the most popular
BPM notations still lack the constructs required to appropriately use BPM as a means for requirements
elicitation. Recent studies reveal that organizations find it difficult to produce consistent and reusable BP
models. The use of MLA opens the way for a consistent representation of the BPs that cover the needs and
constraints of all the stakeholders involved in a software project. MLA is already commonly used in various
BP-oriented approaches, and it has also been recommended for BPM in recent research.
All the approaches reviewed in this article use three levels of abstraction. However, the characteristics of
the levels vary from author to author. The approaches with a management orientation favor the representation
of the goals of the core BPs, their metrics, and the various activities, roles, and resources involved in BPs.
The approaches with an IT orientation favor the representation of the details of BPs, with a rigorous
description of each workflow.
To arrive at a unified BPM approach, the abstraction levels should provide the means to satisfy the
modeling needs and constraints of each stakeholder in accordance with the type of managerial activity to be
performed at a particular time. Such an approach cannot solely be aimed at being used as a means for
deploying software applications, but must also facilitate collaboration among the various stakeholders.
This article suggests using Anthony’s model as a basis for defining each level of abstraction (i.e. strategic,
tactical, and operational). At the strategic level, the goals of the organization are communicated, and the core
BPs and their main relationships, as well as the external stakeholders that are relevant to the organization, are
depicted. At the tactical level, the activities of the BPs are described, and the ways in which the various roles
and departments of the organization interact, as well as the resources required for each BP, are depicted. This
level also makes it possible to identify the critical activities required to achieve the goals of the organization
if this is considered necessary. The operational level is very challenging, as it can take many forms,
depending on the specific needs of each stakeholder. For instance, if the stakeholder is dealing with the
implementation of a software application, then all the additional information required to implement the
application is modeled at this level in a rigorous way. In contrast, if the stakeholder needs the BPs to be
formalized to comply with an external regulation, then the critical activities of each BP, their control criteria,
and their corrective actions are modeled at this level (Ouanouki and April, 2007).
The MLA approach proposed for BPM needs to be validated. Two case studies are under way to try out
the approach with two BPM notations: Qualigram and BPMN (OMG, 2009). Qualigram has been selected for
two reasons: 1) its focus is management-oriented, and 2) the review shows a good match between its
characteristics and the foundations of MLA. The Business Process Modeling Notation (BPMN) has been
selected for two reasons as well: 1) it is popular, and 2) an effort is under way to establish it as a BPM
standard.
REFERENCES
Abran, A., Moore, J., Bourque, P. & Dupuis, R., 2004. SWEBOK: Guide to the Software Engineering Body of Knowledge
2004 Version. IEEE Computer Society, Los Alamitos, California.
IADIS International Conference Information Systems 2011
241

Anthony, R. N., 1965. Planning and Control Systems: A Framework for Analysis. Division of Research, Graduate School
of Business Administration, Harvard University, Boston.
Becker, J., Rosemann, M. & von Uthmann, C., 2000. Guidelines of Business Process Modeling. Business Process
Management. Springer Berlin / Heidelberg.
Berger, C. & Guillard, S., 2000. La rédaction graphique des procédures : démarche et techniques de description des
processus. Association Française de Normalisation, AFNOR, Paris.
Bhat, J. M. & Deshmukh, N., 2005, Methods for Modeling Flexibility in Business Processes. Proceedings of the Sixth
Workshop on Business Process Modeling, Development, and Support, BPMDS'05. Porto, Portugal.
Council, S. C., 2008. Supply-Chain Operations Reference-model. SCOR Overview. Version 9.0.
Davis, R., 2008. ARIS Design Platform. Advanced Process Modeling and Administration. Springer, London.
Dreiling, A., Rosemann, M., van der Aalst, W. M. P. & Sadiq, W., 2008. From conceptual process models to running
systems: A holistic approach for the configuration of enterprise system processes. Decision Support Systems, Vol.
45,No. 2, pp 189-207.
Elzinga, D. J., Horak, T., Lee, C.-Y. & Bruner, C., 1995. Business process management: Survey and methodology. IEEE
Transactions on Engineering Management, Vol. 42,No. 2, pp 119-128.
Gorry, G. A. & Morton, M. S. S., 1971. A framework for management information systems. Sloan Management Review
Vol. 13 No. 1 pp 50-70.
Gulla, J. A. & Brasethvik, T., 2000, On the Challenges of Business Modeling in Large-Scale Reengineering Projects.
Proceedings of the 4th International Conference on Requirements Engineering, ICRE'00. Schaumburg, IL, pp 17-26.
Haque, B., Pawar, K. S. & Barson, R. J., 2003. The application of business process modelling to organisational analysis
of concurrent engineering environments. Technovation, Vol. 23,No. 2, pp 147 - 162.
Harmon, P. & Wolf, C., 2010. The State of Business Process Management 2010. BPTRENDS
IIBA, 2009. A Guide to the Business Analysis Body of Knowledge (BABOK Guide). International Institute of Business
Analysis (IIBA), Toronto.
ISO, 2008. ISO 9000 Introduction and Support Package: Guidance on the Concept and Use of the Process Approach for
management systems.
ISO, 2009. ISO 9000 Introduction and Support Package: Guidance on the Documentation Requirements of ISO
9001:2008
Kaplan, R. S. & Norton, D. P., 2007. Using the Balanced Scorecard as a Strategic Management System. Harvard
Business Review, Vol. 85,No. 7/8, pp 150-161.
Lin, F.-R., Yang, M.-C. & Pai, Y.-H., 2002. A generic structure for business process modeling. Business Process
Management Journal, Vol. 8,No. 1, pp 19-41.
Mayr, H. C., Kop, C. & Esberger, D., 2007, Business Process Modeling and Requirements Modeling. First International
Conference on the Digital Society, ICDS '07. Guadeloupe, pp 8-8.
Monsalve, C., April, A. & Abran, A., 2010, Representing Unique Stakeholder Perspectives in BPM Notations. 8th ACIS
International Conference on Software Engineering Research, Management and Applications, SERA 2010. Montreal,
pp 42-49.
Muehlen, M. Z. & Recker, J., 2008, How Much Language Is Enough? Theoretical and Practical Use of the Business
Process Modeling Notation. CAiSE '08: 20th international conference on Advanced Information Systems
Engineering. Montpellier, France, pp 465-479.
OMG, 2009. OMG Business Process Model and Notation (BPMN), Version 1.2. Object Management Group.
Ouanouki, R. & April, A., 2007, IT Process Conformance Measurement: A Sarbanes- Oxley Requirement. International
Conference on Software Process and Product Measurement IWSM - Mensura 2007. Palma de Mallorca, Spain, pp 26
- 37.
Scheer, A., Thomas, O. & Adam, O., 2005. Process Modeling Using Event-driven Process Chains. Process-aware
Information Systems: Bridging People and Software through Process Technology Wiley-Interscience, Hoboken, New
Jersey.
Sedera, W., Gable, G., Rosemann, M. & Smyth, R., 2004, A success model for business process modeling: findings from
a multiple case study. Eighth Pacific Asia Conference on Information Systems, PACIS 2004. Shanghai, China.
Smith, H. & Fingar, P., 2007. Business process management: the third wave. Meghan-Kiffer Press, Tampa, Fla.
Zairi, M. & Sinclair, D., 1995. Business process re-engineering and process management. A survey of current practice
and future trends in integrated management. Business process management journal (Online), Vol. 1,No. 1, pp 8-30.
ISBN: 978-972-8939-47-2 © 2011 IADIS
242