![](bg2.png)
(1) Each process is depicted using a BUCM - Busi-
ness Use-Case Model, i.e., by a circle and a set of
relationships to the diverse actors that participate. (2)
The activities in each process are specified using an
AD- Activity Diagram, i.e., a flowchart-like model
that represents the steps that comprise the process (Ja-
cobson et al., 1999). Finally, (3) Additional informa-
tion is specified in a glossary and a set of textual de-
scriptions and specifications.
Challenges using RUP. Although there are some
books and guides describing how to elicit require-
ments based on the models representing the processes
in RUP, we faced multiple challenges.
Using the glossary: our software engineers had
problems to write correctly the terms in the glos-
sary. Some times they wrote incorrect definitions or
assumed incorrectly that two terms were equivalent.
The problems were aggravated by users that refused
to read and correct glossaries with a large number of
terms.
Using the BUCMs: software engineers and stake-
holders had problems to review the BUCMs. These
models represent processes as use-cases without spec-
ifying an ordering of the tasks, inputs and outputs nei-
ther the people that perform the tasks. Many times
the stakeholders approved a BUCM because they rep-
resented steps in the process without noting missing
tasks or missing participants.
Using the ADs: finally, activity diagrams cannot
represent some elements important in the processes
such as escalations and deadlines. Software engineers
and stakeholders were able to use ADs to discuss on
the typical case of the process but failed to represent
there the exceptional flows.
Additionally, we found problems trying to create
a single set of models representing the business pro-
cesses. In many projects the stakeholders were sure of
the steps in the current process but not of the steps in
the process they want. In addition, we had to deal
with constant changes on the stakeholders, the do-
main’s experts, the involved legal regulations and/or
the software requirements. Many times, the models
combined elements of the current process with one or
more of the desired processes. It was hard, when a
change in a regulation or stakeholder occurred, to de-
termine which elements must be modified. Moreover,
some stakeholders did not receive well the ideas and
recommendations of the software engineers because
they believed that the software engineers did not un-
derstand the process because of these models.
Related Work. There are other methods and mod-
eling notations aimed to represent business process.
For instance, the BPMN - Business Process Model-
ing and Notation - is an OMG standard for “bridg-
ing the gap between process design and implementa-
tion”. Although business modeling can be done inde-
pendently of the software development, it is clear that
each process can benefit from the other.
There are studies that show a misalignment be-
tween the software applications and the business
processes of many organizations (Przybylek, 2014).
These studies describe, as a main reason, the lack
of methodology and rigor to determine the software
requirements from the business goals. Other stud-
ies (Sedelmaier and Landes, 2014) (Monsalve et al.,
2012) have shown the benefits of determining require-
ments based on the modeling of the business pro-
cesses that the software aims to support. Thereby, we
can find tools integrating business and software mod-
eling such as IBM Rational and Visual Paradigm.
3 OUR PROPOSAL
To overcome the mentioned problems we integrated
conceptual maps and BPMN diagrams into the Re-
quirements activities of the RUP.
Figure 1: Changed requirements activities.
Figure 1 shows the process starting when a client
requests a new software. Then, the project team
model the business and elicit the requirements. The
requirement specifications are later reviewed with the
client. If the client agrees, the process follows to other
phases such as analysis, design and implementation
(out of the scope of this paper).
3.1 Model Business
The main changes we made on the Business Modeling
sub-process were the artifacts produced, showed in
Figure 2. We complemented the glossary with a con-
ceptual map, and replaced the BUCM and AD by an
AS-IS business process model. In addition, once they
are built, the conceptual map and the business pro-
cess models are reviewed and modified directly with
the client.
Conceptual map: A conceptual map is a technique
to graphically represent the knowledge. The project
Software Development Process Supported by Business Process Modeling - An Experience Report
243