2015 IEEE 17th Conference on Business Informatics

Combining Process Modeling and Requirements

Engineering
an Experience Report
Heli Hiisil, Mika Kujala
Planning and Development
Ilmarinen Mutual Pension Insurance Company
Helsinki, Finland
heli.hiisila@iki.fi, mika.kujala@ilmarinen.fi
work, and developing IT systems. Business process
management (BPM) focuses on improving corporate
performance by managing and optimizing a companys
business processes [1].
Renewal of the software systems of a complex business
process is a major challenge for an organization - IT projects
consume companys resources and are seldom finished in
accordance with their original schedule and budget, or deliver
the benefits expected. According to a study of large-scale
software projects, the average cost overrun is 66%, average
schedule overrun is 33%, and average benefit shortfall is 17%
[2]. Especially organization with the outsourced IT
development may face many challenges. Based on our previous
study [3], one of the biggest challenges from the customer
organizations point of view is to develop business and IT as a
whole, and requirements can be an important tool when
combining the business process, IT system development and
enterprise architecture.
No real competitive advantage is gained by a new system
implementation if the business processes are not developed as
well. Also, a minor improvement of the current state is not
enough when targeting strategic business transformation via
development. To support large and complex system
development projects ahead, Business-driven Development
(BDD) [4] [5] method was introduced at the case study
organization in 2010. The BDD method was implemented to
support business process modeling and IT system development
in four major projects.
The goal of this study is to investigate how to combine
process modeling and requirements engineering (RE) in the
software development projects. This study reports lessons
learned from utilizing the BDD method in four projects. We
also studied how to combine process modeling to other
requirements modeling techniques, such as use cases, business
rules, and other requirements in a total of 15 large projects
implemented at the outsourced environment.
The related work to our study is introduced briefly in
Section II. We present the research methodology including the
description of the case study organization, projects studied and
validity evaluation in Section III. Section IV introduces the
results of BDD method implementation and combining process
modeling to other requirements modeling techniques. The main
results of the study are summarized and discussed in Section
VI. Finally, we present conclusions and propose some future
research directions.

Abstract Using IT development efforts for achieving new

business goals is a challenging task. Optimally, IT projects and
solutions should be aligned to answer the real requirements of
actual business development targets. Process modeling has been
widely applied as a tool for business process and IT development.
The goal of this study is to investigate how to combine process
modeling and requirements engineering (RE) in software
development projects. We studied the use of process modeling
focused Business-driven development (BDD) method and other
modeling techniques to support complex large projects in the
outsourced environment. The results presented here are based on
17 interviews, a study of 4 projects implemented with the BDD
method and the experiences gathered from 11 other large
projects at the case study organization. This report outlines the
results of combining process modeling to use case, business rule
and other requirements and architecture modeling. To a large
extent, the results were positive and indicate the benefits for
using business process modeling as a visual tool for combining
business and IT development, and as a part of the requirements.
However, the perspective and abstraction level for process
modeling should be carefully selected. Our study concludes also
that requirements modeling should cover different aspects from
both project and enterprise context in a comprehensive manner.
Keywords Business-driven development (BDD), process
models, requirements engineering (RE), enterprise architecture
(EA), use cases, business rules, non-functional requirements

I. INTRODUCTION
Effective business processes can bring competitive
advantage for a company and IT systems are a valuable asset in
the information centric processes. IT systems enable process
automation, contain valuable business logic and complex
business rules, support business specialists as process tools,
and enable the storage of the information. The complexity of
the IT systems has increased and one business process may
utilize several software systems, components, SOA services,
and integrations. Furthermore, the amount of stakeholders is
often very high as the business process may flow over several
organization units, have external or outsourced parts, and can
be closely connected with customers processes.
Process models have been a tool for developing business
during the past decades. Processes have been developed from
different perspectives, for example optimizing process work,
removing waste based on lean principles, developing
organization practices to meet quality standards, automating
978-1-4673-7340-1/15 $31.00 2015 IEEE
DOI 10.1109/CBI.2015.20

242

A. Case Study Organization

The case study organization was an insurance company
taking care of statutory pension security in Finland. The
company had over 560 employees. Pension insuring is
information centric and highly integrated in the business field.
The companys large legacy systems were built in the 1980s
and 1990s. These systems became the backbone of the
companys IT infrastructure. Systems were tailor-made based
on the business and user needs, and legislation. In the late
1990s IT was recognized as a tool for developing business
enabling automation, digitalization, web services, and complex
business logic. The amount of technologies and integrations
increased and the complexity of the systems expanded. IT
system development was outsourced in 2006 and is nowadays
provided by external suppliers. Most of the suppliers are well
known international software companies.
Legacy systems serving pension, insurance processes and
financial processes were at the end of the life cycle and largescale development projects were on the way. During the years
of system development, part of the knowledge of the
organization was built into the systems business logic, process
automation, and integrations between the systems. At the prestudy phases of the renewal projects, a major challenge was to
collect requirements related to hidden business logic.
Renewing monolithic systems brought challenges to project
scoping and each business process also utilized a number of
integrated software systems. This added complexity to the
projects. To improve project outcomes, the Business-driven
development method was implemented in 2010.

II. RELATED WORK

Process modeling has been a tool for developing processes
from different viewpoints: business-to-business processes,
human interaction workflows, and system workflows [6] and a
large variety of process modeling techniques [7] are available.
Process modeling has also been a topic of interest of academic
study during the past decades [8]. Business Process
Management (BPM) offers concepts, methods, and techniques
to support the development of companys business processes
[9]. One of the BPM related methods the Business-driven
development method (BDD) [4] combines business process
and IT development. The aim of BDD methodology is to
develop IT solutions that directly satisfy business requirements
and needs [4]. In the BDD, business requirements flow
downwards from the business level to the IT level and IT
requirements flow upwards to the business level via
hierarchical process modeling: business process level analysis
models are further defined in system level design models and
connected with Service Oriented Architecture (SOA) [5].
Business process focus has also been identified as emerging
themes of requirements engineering (RE) by Hansen, et al.
[10]. According to a definition of Nuseibeh and Easterbrook
[11] requirements engineering (RE) is the process of
identifying stakeholders and their needs, and documenting
these in a form that is amenable to analysis, communication,
and subsequent implementation. The number of available
requirements modeling techniques, frameworks and tools is
high and it is challenging to select the most suitable technique
for the project context [3]. In addition to process modeling, the
case study organization has applied several requirements
modeling techniques, such as UML modeling and use cases,
business rules and non-functional requirements. Use cases have
been widely used to model interaction between the user and the
system [12] and a business rule is a statement that defines or
constrains some aspect of the business [13]. Furthermore, in
addition to functional requirements, also non-functional
requirements are often needed [14] [15]. Glinz [14] points out,
that a non-functional requirement is an attribute of or a
constraint on a system, and that these attributes may include
both performance requirements and specific quality
requirements.
Also the importance of enterprise architecture (EA) has
increased, as the number of technologies and complexity of the
solutions has grown rapidly in the case study organization.
TOGAF [16] is an Open Group Standard, an enterprise
architecture framework that provides a widely accepted and
increasingly applied methodology for enterprise architecture
development. In the Business Architecture phase of TOGAF
the link between the strategy of the enterprise and the required
business model is established and the high-level enterprise
BPM process models are designed [16]. The case study
organization is in the process of establishing a more robust EA
practice, but currently there is no holistic framework or method
like TOGAF in use.

B. Data Collection and Analysis

Research and interviews were planned with external
university researchers to support both the scientific work and
development work of the case study organization. The research
was performed based on interviews, document reviews and
validation workshops (Table I).
TABLE I.
Method
Interviews

Project
documentation
review

Validation
workshops

III. RESEARCH METHODOLOGY

SUMMARY OF DATA COLLECTION METHODS

Data collection
17 interviewees were selected based on the
organizational and project roles to comprehensively
represent different projects, experience of the BDD
method and organizational functions responsible
for RE and project work.
Project documentation, process models and
requirements were studied of 15 projects: A)
Insurance process automation, B)
Pension
estimation process C) Pension process renewal D)
Insurance process automation, further development
F) Financial processes; G-P) 10 other large-scale
projects are reference projects between 2006-2014.
Three workshops were organized to validate the
findings with the interviewees and IT management.
During the validation workshops, the author
presented the results of the analysis and the
participants gave feedback on the results. The
validation workshops lasted 2-4 hours.

The interviews were semi-structured and conducted in

Finnish. The themes of the interview questions were the
following:

In the research methodology section case study

organization and projects are introduced, data collection and
analysis are reported, and the validity of the study is evaluated.

243

main focus of the project study was in the projects A-D

utilizing the BDD method the use of the process modeling in
the projects studied is summarized in Table II.

Experiences of implementation of the Business-driven

development method
How different projects utilized the BDD method to collect
requirements?
Experiences of other requirement modeling techniques
utilized in the projects
The
interviewees
included
five
business
developers/specialists, three steering group members of IT
development projects, two requirements definition specialists,
two process developers, two IT managers, two IT architects,
and one project manager. The duration of each individual
interview was approximately an hour. All the interviews were
recorded and transcribed. In addition to the interviews, process
models, requirements documents, project plans and the final
reports of the projects were studied. Four projects implemented
with the BDD method were studied in greater detail to study
method implementation and process modeling.
The interview data were analyzed iteratively. The unit of
analysis was large IT development projects and the focus of the
investigation was to analyze experience of the BDD method,
process models, use cases, business rules and other
requirements models used. Interview data were analyzed with
open-coding content analysis [17]. Large amount of interview
data and findings from the project documentation was
categorized and analyzed to summarize lessons learned. The
first author of the paper was responsible for the analysis of the
results. Three workshops were organized to validate the
findings with the interviewees and IT management. During the
validation workshops, the author presented the results of the
interview and project study analysis and the participants gave
feedback on the results.

TABLE II.

USE OF PROCESS MODELING IN THE PROJECTS STUDIED

Project
Project A Insurance
process
automation and
project D developing
Insurance
processes further

Project B
Pension
estimation
process

Project C Pension process

renewal,
prestudy

Project E
Renewal
of
financial
processes

C. BDD method implementation and projects studied

The methodology implemented in the case study
organization was based on the one introduced by Mitra [4] and
Koehler et al. [5]. Method was implemented as a tool for
developing business processes, collect requirements and
combine business and IT development. During the
implementation of the method in the organization, proof-ofconcept modeling example processes was made, instructions
written, modeling tools introduced and trained to practitioners
and a knowledge center was introduced to support the projects.
The pre-study phase in the method implemented was
iterative and process models were hierarchically composed.
First development goals and the process hierarchy were defined
and project scoped. Then high level business processes
(analysis models) were defined. The next level in the
hierarchical modeling was to define design processes (system
level) in detail including software system services. In addition
to process modeling, use cases, business rules and functional
and non-functional requirements were defined and current state
and to-be environment and architecture modeled.
For the project study, we selected large scale development
programs or projects based on two selection criteria: 1)
program was implemented in the outsourced environment 2)
the cost of the implementation > 1M. These programs covered
the strategically important outsourced IT system development
projects of the case study company during 2006-2014. The
costs of the programs / projects varied from 1M to 40M. The

Projects G-P

Use of process modeling in the project

Project A was implemented based on the BDD
method; however analysis and design models of
processes were combined into a single model.
Business rules and use cases connected to the
process models were defined. Solution was a tailormade implementation into Business Process
Management System (BPMS). Project D was
further development of project A. Process models,
use cases and business rules of project A were
updated and redeveloped.
Analysis level models were defined based on the
method and business rules and business use cases
connected to the process models were defined. Also
functional and non-functional requirements were
defined. Tailor-made implementation into Business
Process Management System was planned.
However, the project was cancelled during the
implementation phase and process was later
implemented as a part of project C.
Process hierarchy and business processes were
modeled. In addition, business rules and functional
and non-functional requirements were defined.
Pension handling processes included complex
business logic and a long sequence of automated
and manual phases as well as iterations. Instead of
tailored implementation into BPMS, the
components of software products were used to
build the solution. Requirements were partly
redefined later.
Process models were used in the early pre-study
phase and process hierarchy and the most important
business process were modeled to support project
work, but the BDD method was not utilized in the
project. Also, functional and non-functional
requirements were defined. The project included
the implementation and integration of several
software products and changes to systems.
10 other large scale programs or projects between
the years 2006-2014 were studied. At least high
level business process models were utilized in 60%
of the studied projects. The solutions delivered
included tailor-made software implementations, the
deliveries and modifications of the software
products, changes to current systems, integration
work and SAAS services.

D. Validity Evaluation
Threats to validity were analyzed based on the framework
by Runeson et al. [18]. The authors of the paper are employees
of the case study organization, which is both a strength and a
possible threat to the validity of the results. Based on the
practical experience of the case study organizations RE
process, BDD method implementation and projects studied, the
authors have background information and the researchers had
full access to all necessary project documentation.
As a threat, the researchers' own experience may have
affected the interpretation of the results. To avoid construct
validity threats, validation workshops where the practitioners
of the case study company reviewed the findings iteratively
were organized. This study is based on experiences of a single
organization and does not give conclusive results of

244

Figure 1.
First, the importance of strategic development goals was
emphasized by the interviewees. Strategic development goals
were needed to steer to-be process modeling and requirements
definition, for example expected automation level, customer
value and benefits and development costs. In four studied
projects, development goals were defined based on the analysis
of the process capabilities, which brought the focus into all the
assets related to process (IT systems, human resources and
knowledge of individuals, process instructions, etc.). Second
perspective identified was the organizational approach.
Business processes flow over several organizational units and
transformation of the business process often required
development or organizational capabilities, roles and
responsibilities, and sometimes outsourcing decisions. The
third perspective identified was the business process approach,
including business process workflows, business rules and logic
needed. The fourth perspective identified was the system level
including descriptions of how the process is performed in the
IT systems, services, and integrations including also manual
tasks.
As-is process modeling was needed to fully understand the
current end-to-end processes functionality, software systems
used and current state challenges. Both system and business
specialists knew deeply parts of the process, but end-to-end
process knowledge was rare. Though understanding of current
state as-is processes is important, most focus and resources
should be spent on to-be modeling.
Enterprise process modeling is a comprehensive approach
including all processes of the company. If comprehensive
current state process modeling exists in the company,
development projects may utilize the documentation as a
starting point. The process hierarchy was identified as a useful
tool for defining the development project scope based on the
business processes and establishing common vocabulary
between the stakeholders. The process hierarchy was also used
in the acceptance testing to set the focus of the testing efforts to
end-to-end business processes.
Modeling a complex business process comprehensively at
different hierarchical levels required extensive effort. High
level process models and the process hierarchy were useful
from the management point of view in the organizational
perspective. Business specialists were interested in business
process and business logic mainly from the functional and
behavioral perspectives. Specific system level process models
were often needed by the technical people from the
informational perspective. Most of the practitioners would have
preferred a single model for business and system level
processes.
Business process modeling including process hierarchy and

implementing and utilizing the BDD method or other models

used. However, process modeling, use cases and business rules
are widely used tools and lessons learned based on practical
experience may be useful to other service production
organizations.
IV. RESULTS
In the results section, lessons learned about the BDD
method implementation and experiences of the projects
utilizing the method as well as results of combining the use
case, business rule and other requirements modeling with
process modeling are reported.
A. Business-Driven Development Method Lessons Learned
The BDD method gave a solid framework for modeling
end-to-end processes and had the business process focus.
Actual business process development can be done with the
most suitable methodology, for example based on the lean
principles. Building the capability of the organization related to
the new BDD method - organizations development processes,
knowledge of practitioners, assets, use of tools and models,
culture related required more time, resources and change
management than expected.
Process modeling requires skill and knowledge of best
practices. In the outsourced environment, customer
organization project team mainly consisted of non-technical
business specialists. Design level modeling required
architecture skills. All suppliers were not familiar with the
BDD method; the supplier implementing the system
development should be trained to use the method. Based on the
experiences, method was best suited for developing tailored
solutions based on the process management system (BPMS).
When utilizing a software product (COTS) as a solution,
product specific limitations should be considered in to-be
process modeling.
B. Using Process Modeling to Collect Requirements
One of the challenges identified related to process modeling
was that there is a large number of process modeling
perspectives, abstraction levels, modeling techniques and
notations available. Different stakeholders, such as
management, business specialists, business developers, IT
architects, and suppliers specialists, had different expectations
to process models and previous experience of using different
modeling notations and tools. At the beginning of the work, the
purpose and abstraction level of modeling should be agreed
on. The aim of the process development was to transform the
current state (as-is) process to the to-be process usually
strategic, organizational, business process and system level
perspectives were developed during the project. Different
perspectives of process modeling identified are illustrated in

Fig. 1. Different perspectives of process modeling identified.

245

analysis level process models were considered the valuable

tools of business and IT development. Lessons learned about
the process modeling are summarized in Table III.
TABLE III.

Process
hierarchy
/
process mapping

Development
goal
setting
based on process
capabilities

Analysis model /
business process
model

Design model /
system
level
model

Solution
planning
and
analysis (SOA
services,
software
products etc.)

Modeling tools
and
round
tripping between
the models

Modeling
process
supported
several
integrated
systems

by

C. Combining Process Models, Use Cases and Business Rules

Use case modeling was used in several projects in the case
study organization and the practitioners were familiar with the
method. However, use case diagrams lack the end-to-end
process view, which is relevant to get a grasp of the complex
business process behind. Use case modeling and business
process modeling was combined to receive benefits from both
modeling techniques. Business process modeling defines the
sequence of automated and manual tasks and provides a
comprehensive view of the process. Tasks of the business
process were further defined as use cases and business rules.
Also in some projects studied, the use case included a whole
business process however, this was not recommended by the
practitioners in case of complex business processes.
Also business rule modeling was combined to process
modeling. Many of the case study organizations business rules
were derived from the law or regulation, but also other
business-related rules were identified. Rules were defined in a
semi-formal manner utilizing natural language and business
terms. Each business rule had a unique id and steps for
performing the rule were defined. Project A contained a total of
125 rules, which were updated and modified in project D. In
project B 35 rules were defined and in project C 135 rules. The
abstraction level of business rules and documentation varied in
the projects and practitioners understand the term business rule
in various ways. In project A, manual tasks were defined by the
business rules. In addition to business rules defining system
logic, system level specific handling rules were defined in the
use cases in projects A and D. Both levels of abstraction of
rules were needed.
The approach combining process modeling to use cases and
business rule modeling is illustrated in a simplified process
model of Figure 2. The process model defines the end-to-end
business process and each step of the process is further defined
as use cases. Business rules are utilized to define the rules
related to decisions made during the process execution.
Combining three modeling techniques enabled the more
comprehensive modeling of business logic.

PROCESS MODELING LESSONS LEARNED

Lessons learned
The process hierarchy was useful in defining the
project scope, establishing the common
terminology and useful tool of process acceptance
testing. Process discovery was time-consuming and
the management engagement was needed. The
hierarchy was negotiated between the stakeholders
as there is no correct hierarchy. Some guidance
was given by industry reference models, but they
did not completely match companys processes.
Strategic development goals were needed to steer
to-be process modeling and requirements
definition. Development goals were defined based
on the analysis of process capabilities, which
brought the focus on the assets related to the
process. However, process capability was a new
and abstract concept and different projects applied
the concept at different abstraction levels (the
capability of the business / process/ organization /
individual).
The analysis model was considered useful - focus
was improving the end-to-end process instead of
sub
processes
based
on
organization
responsibilities. Innovation and fresh thinking were
valued to avoid copying old ways into the new
systems. The organizational perspective of process
modeling was needed to lean the processes.
Design models of projects A and D were used to
implement the process into the business process
management system. Design level process models
were considered useful documentation in the
testing, technical planning and implementation and
maintenance phase. System level process modeling
required cooperation with the system supplier to
create common understanding about the solution
to-be.
Feedback of the IT solutions available is needed to
define realistic and affordable to-be processes and
requirements. The BDD method support
identification of SOA services. However, in the
projects
implementing
software
products,
integrations, SAAS services etc., solution planning
and analysis of how different components support
to-be processes was considered essential.
Modeling tools enabled hierarchical process
descriptions. There were separate tools for analysis
(business level) and design models (system level).
Round-tripping between the models was considered
difficult based on the limitation of the tools. Most
of the practitioners would have preferred a single
model for business and IT processes. Process
modeling tools did not support reviewing
requirements fully.
In project E, systems supporting financial processes
were highly integrated and information flows in the
process through several systems. If comprehensive
large-scale process modeling is not possible or
feasible, defining the process hierarchy and
modeling the most important business processes
increases common understanding and adds value.
Also in the complex integrated environment,
process modeling may be a useful tool for modeling
how the business process is actually performed at
the system level.

Fig. 2. Combining process modeling, use cases and business rules.

Lessons learned from combining use cases, business rules

and other modeling techniques are summarized in Table IV.
Business practitioners preferred detailed use cases and business
rules to model both business and system logic required to
define the complex logic of automated information centric
processes. In addition to process modeling, use cases and
business rules, also functional and non-functional requirements
were needed to comprehensively define requirements.

246

TABLE IV.

LESSONS LEARNED OF COMBINING THE MODELING

D. Summary of the Modeling Demands Identified

Process modeling was able to capture valuable
requirements related to end-to-end business processes. Use
case and business rule modeling were then used to define
business logic and required functionality. The design level
models of the BDD method also capture system level
requirements. During the analysis of the results, also other
demands for the requirements modeling were identified from
the customer organization context - requirements should cover
different aspects comprehensively, from both project and
enterprise context. From the case study organization point of
view, different aspects of the requirements modeling identified
are illustrated in Figure 3.
Strategy should steer goal setting and transformation of the
business. Development goals derived from the company
strategy was the first aspect identified development goals
should steer decision related to to-be process modeling,
requirements definition and project in general. To achieve
strategic goals, business development of service products,
processes and organization were the next identified layers.
Business logic and functionality were seen as traditional
sources for user and system requirements by the interviewees.
Master data management and the importance of information
modeling were also emphasized to enable maintainable long
terms solutions. Also, integration related requirements may
have a major impact on business processes, for example
enabling the target automation level. The solution to be
developed should also fit into the enterprise infrastructure
(platforms, other systems etc.). Enterprise architecture both
enables and brings limitations to solutions and thus architecture
models and guidelines were seen as vital sources of the
requirements.
Also environmental factors, such as legislation related to
the business branch and compliance, may introduce vital
requirements. User needs and other stakeholders should not be
forgotten, either.

TECHNIQUES

Combining
use cases to
process models

Business
use
cases vs. system
use cases

Business rules

Reusable
business rules

Development
goals

Functional
requirements

Non-functional
requirements

Architecture
models
and
guidelines

User stories

Concepts

Examples

Lessons learned
Process tasks were further specified with use cases
to define business and system logic steps,
alternatives, handling rules and exceptions. When
use cases are modeled based on process tasks, the
modeling may not be optimal from UML modeling
perspective. However, combining two approaches
brought value from the business modeling
perspective.
In project A and D, use cases defined combined
both business and system level aspects. Business
specialists preferred detailed system specific use
cases over separate high level business use cases.
Business level use cases were defined in project B
based on analysis level process maps, but deriving
system level use cases during the specifications
phase with the software supplier was challenging.
Business rules were used to define requirements
related to business logic. Rules provide
understandable documentation for business people
and formally define business logic for system
development purposes.
One business rule may be used in different process
phase or use case. Business rules were defined in
many projects as a part of use case documentation.
If the same rule was utilized in many use cases,
separate business rule documentation was utilized.
The importance of goals to steer the requirements
definition and project work in general was
emphasized. The studied projects had initial high
level goals. In addition to top-down derived goals
from the management, also unwritten goals from
different stakeholders can be recognized (derived
bottom-up).
In addition to automated processes, users use the
functionalities of the system manually. Customer
service, for example, is often based on performing
several tasks reviewing and updating customer
information. In addition to process modeling,
functional requirements (system shall phrases)
were used to supplement process models.
Process modeling did not cover all non-functional
requirements such as reliability, maintainability,
security, usability and fault tolerance. Company
had a set of frequently needed non-functional
requirements to be used as a starting point of
project requirements definition. Process modeling
may be used to collect requirements, but additional
requirements documentation was needed.
Process models were seen as a tool for connecting
business
and
architecture
development.
Architecture guidelines have brought vital
requirements related to services, software products,
integrations and information.
Also enterprise
architecture guidelines and enterprise IT
infrastructure may bring limitations to solutions.
Architecture guidelines were needed in the
procurement for the suppliers to deliver comparable
bids.
User stories were considered as a useful tool for
modeling stakeholder requirements. Connecting the
user role and benefits expected to the requirements
has been useful.
User interface concepts and product concepts, for
example, have been utilized to develop and
visualize business ideas.
Examples of specialties of the business area have
been useful to make difficult functionalities
understandable.

Fig. 3. Development goals and requirements should cover comprehensively

different aspects of from both project and enterprise context.

247

Practices of defining use cases varied in the projects.

Discussion of business level and system level use cases
reported also in the white paper [23] has caused some
confusion. Business specialists preferred single comprehensive
documentation containing both business logic and system
related requirements to avoid the maintenance of separate
documentations.
Based on the interviews, use case
documentation should be written in natural language utilizing
business terminology. Practitioners also preferred the
documentation of business rules within the use cases instead of
separate business rule documentation, to enhance readability.
Process models were a tool for connecting business process
development, requirements engineering and architecture
development. Enterprise architecture framework TOGAF [16]
aims at establishing a connection between the strategic
business targets and the state of the actual IT systems and their
development within an enterprise. Applying Business
Scenarios and Business Process Modeling as critical tools in
the Business Architecture Phase of TOGAF emphasizes the
approach of process orientation and clarifies the connection
between strategic business targets and the state of actual IT
systems and their development requirements within an
enterprise. All of the disciplines, BPM, RE, and EA, are
closely connected, and include valuable viewpoints.
The BDD method can be applied in some of the future
projects of the case study organization, but not as a standard
development method for all projects. The suggested approach
based on the experiences was to combine process modeling at
the chosen abstraction level to other appropriate requirements
and architecture modeling techniques. The case study
organization uses outsourcing for all development projects, and
most of the practitioners are non-technical business specialists
or part-time business developers
modeling techniques
should meet the needs of the organization. In case of
professional organizations that have skilled resources for
modeling tasks, the BDD method may very well be useful as
such. To receive most benefits from the process modeling,
focus on the business process development with a suitable
methodology, such as lean principles, was recommended for
future projects during the validation of the results. In addition
to process modeling, business modeling focusing on customer
value [24] is often needed. Combining process modeling to
service design or service blueprinting [25] might be a good
combination in the future development projects.

To conclude, modeling should comprehensively cover

different aspects of the project and enterprise context and
appropriate modeling techniques should be selected based on
the application domain and available resources (time, skills and
knowledge, tools). Combining process modeling, traditional
requirements modeling techniques and architecture modeling
was considered beneficial by the practitioners and enabled
more comprehensive requirements modeling. However,
requirements documentation should form a solid
understandable entity. If too many modeling techniques were
used, documentation scattered. Furthermore, business
processes, logic and system functionality and other
requirements should be modeled, defined and documented
using business terms.
V. DISCUSSION
This report outlines the results of combining process
modeling to other requirements modeling techniques. To a
large extent, the results were positive and indicate the benefits
to combining these techniques. However, the perspective and
abstraction level for process modeling should be carefully
selected.
Implementation of a new development method, in the
organization requires extensive training and support for the
practitioners. Building the capability implementing BDD
practices, knowledge of practitioners, assets, use of tools and
models, and culture related to RE required more time,
resources and change management than expected. Cultural
change, user involvement, training and education and pilot
projects were identified as the success factors of RE process
development by Kauppinen et al. [19], and similar experiences
were reported by the practitioners also in this study. In the
outsourced environment, also the supplier organizations should
have knowledge of the methods and tools used.
Hierarchical process modeling required modeling skills,
business and IT knowledge and was time-consuming.
Combining different modeling perspectives, functional,
behavioral, organizational and informational [8] into a single
model turned out to be problematic. Based on the study,
hierarchical modeling can be used to alleviate the problem. At
the beginning of the modeling work, a common agreement is
required on the perspective, use and the abstraction level of the
models to be produced. Furthermore, round-tripping between
the analysis and design models was considered challenging by
the practitioners. Similar findings related to round-tripping
between the models have also been identified by Branco et al
[20]. Our study also supports the findings of Liskin [21] a
variety of requirements artifact types is often needed to
successfully conduct a project however, using multiple
artifacts causes problems like manual translation effort and
inconsistencies.
The BDD method was used in the case study organization
as the main tool for collecting requirements in four projects. In
addition to process modeling, other types of modeling of
requirements were needed to comprehensively define the
requirements set in the studied projects. Combining process
modeling to use cases and business rules was seen useful. Also,
process modeling does not support the definition of nonfunctional requirements [22], but additional non-functional
requirements were needed in the projects studied.

VI. CONCLUSIONS
Based on the experiences received, we recommend using
business process modeling as a visual tool for combining
business and IT development. If comprehensive large-scale
hierarchical process modeling is not possible or feasible,
defining a process hierarchy and modeling a selection of the
most important business processes increases common
understanding of end-to-end business processes and adds value.
Also in the complex integrated environment, process modeling
may be a useful tool for modeling how the business process is
actually performed at the system level. In addition to process
modeling, other modeling of the requirements was also needed.
The importance of strategic development goals to steer the
process modeling and requirements definition was emphasized.
Combining process modeling to use cases and collecting

248

business rules related to processes was seen useful by the

practitioners. Also non-functional user and system
requirements and architecture modeling were needed to
complement process modeling.
The role of the requirements identified in the study was to
define the development goals, scope, content, complexity and
development environment to internal stakeholders and software
suppliers to steer the project to meet the business goals. Our
study concludes, that requirements modeling should cover
different aspects from both project and enterprise context in a
comprehensive manner. Furthermore, careful consideration is
required for selecting the best fitting modeling techniques in
the project application domain and based on the project group
skills and knowledge.

[4]

[5]

B. Curtis, M. I. Kellner and J. Over, "Process modeling," in

Communications of the ACM 35.9, 1992.

[9]

M. Weske, Business Process Management - Concepts, Languages,

Achitectures, Springer, 2007.

[14] M. Glinz, "On Non-Functional Requirements," in 15th IEEE

International Requirements Engineering Conference, 21-26, 2007.
[15] L. Chung and J. C. Sampaio do Prado Leite, "On Non-Functional
Requirements in Software Engineering," Chung, Lawrence, and
Julio Cesar Sampaio do Prado Leite. "On non-functional
requirements in Conceptual modeling: Foundations and
applications, pp. 363-379, 2009.
[16] The Open Group, "The Open Group Architecture Framework
(TOGAF) Version 9.1," The Open Group, 2011.
[17] J. Lazar, J. Feng and H. Hochheiser, Research methods in humancomputer interaction, Chichester West Sussex U.K.: Wiley, 2010.
[18] P. Runeson, M. Host, A. Rainer and B. Regnell, Case study
research in software engineering: Guidelines and examples, John
Wiley & Sons, 2012.
[19] M. Kauppinen, M. Vartiainen, J. Kontio, S. Kujala and R.
Sulonen, "Implementing requirements engineering processses
throughout organizations: success factors and challenges,"
Information and Software Technology, vol. 44, no. 14, pp. 937953, 2004.
[20] M. Castelo Branco, Y. Xiong, K. Czarnecki, J. Kster and H.
Vlzer, "An Empirical Study on Consistency Management of
Business and IT Process Models," GSDLAB TECHNICAL
REPORT, Waterloo, 2012.

REFERENCES
T. Panagacos, The Ultimate Guide to Business Process
Management: Everything You Need to Know and How to Apply
It to Your Organization, CreateSpace Independent Publishing
Platform, 2012.

H. Hiisil, M. Kauppinen and S. Kujala, "Challenges of the

customer organization's requirements engineering process in the
outsourced environment - A case study," in Requirements
Engineering: Foundation for Software Quality, pp. 214229,
2015.

[8]

[13] Business Rules Group, "Defining Business Rules ~ What Are

They Really?," 2000.

We would like to thank case study organization

management and practitioners for co-operation and support
during the study, especially our supervisor Jukka Hirvinen.
Also thanks to Aalto university researchers Marjo Kauppinen
and Sari Kujala who participated to the research planning.

[3]

R. S. Aguilar-Savn, "Business process modelling: Review and

framework," in International Journal of production economics
90.2, pp. 129-149, 2004.

[12] I. Jacobson, G. Booch and J. Rumbaugh, The unified software

development process, Addison-Wesley, 1999.

ACKNOWLEDGMENT

McKincey&Company, Business technology office, "Delivering

large-scale IT projects on time, on budget, and on value," 2012.

[7]

[11] B. Nuseibeh and S. Easterbrook, "Requirements engineering: a

roadmap," in Proceedings of the conference on the future of
Software engineering (ICSE'00), pp. 35-46, 2000.

Comprehensive modeling of the requirements is a

challenging task. Process modeling combined with use cases
and business rules was a good approach, but did not cover nonfunctional requirements. The importance of non-functional
requirements was emphasized by the interviewees and a need
to maintain a set of companywide common non-functional
requirements to be used in different projects was recognized.
Architecture modeling could be used to alleviate the dilemma
of comprehensive modeling from both enterprise and project
context.
The focus in the case study organization has changed from
the internal service production processes to from-customer-tocustomer processes. End-to-end process modeling is one of the
tools to develop business, but also service design seems to be
an emerging trend. A topic of interest is how to combine
effectively service design, business process development and
requirements engineering in the development projects.

[2]

M. Dumas, M. La Rosa, J. Mendling and H. A. Reijers,

Fundamentals of Business Process Management, Springer, 2012.

[10] S. Hansen, N. Berente and K. Lyytinen, "Requirements in the 21st

Century: Current Practice and Emerging Trends," in Design
Requirements Engineering: A Ten-Year Perspective. Design
Requirements Workshop, LNBIP., Springer Berlin Heidelberg, pp.
44-87, 2009.

VII. FUTURE WORK

[1]

[6]

[21] O. Liskin, "How Artifacts Support and Impede Requirements

Communication," in Requirements Engineering: Foundation for
Software Quality, pp. 132-147, 2015.
[22] C. J. Pavlovski and J. Zou, "Non-functional Requirements in
Business Process Modeling," in Proc. 5th Asia-Pasific Conference
on Conceptual Modelling, Wollongong, pp. 103-120, 2008.
[23] M. Langlands and C. Edwards, "Business vs. System Use Cases,"
AgileEA Whitepapers, 2009.
[24] J. Gordjin, H. Akkermans and H. Van Vliet, "Business modelling
is not process modelling," in Conceptual modeling for e-business
and the web, Berlin Heidelberg, 2000.

T. Mitra, "Business-driven development," IBM developer works,

http://www.ibm.com/developerworks/library/ws-bdd/index.html,
2005.

[25] J. Ojasalo, "Contrasting theoretical grounds of business process

modeling and service blueprinting," in Global Conference of
Business and Finance Proceedings, 2012.

J. Koehler, R. Hauser, J. Kster, K. Ryndina, J. Vanhatalo and M.

Wahler, "The Role of Visual Modeling and Model
Transformations in
Business-driven
Development," in
Proceedings of the Fifth International Workshop on Graph
Transformation and Visual Modeling Techniques, pp.1-12, 2006.

249