TWiki Tip of the Day
Revision control
TWiki has "Soft security" anyone can change anything, but changes are logged. There is a complete ... Read on
BPMNBased Speci Cation Of Task Descriptions

Main
---+ Introduction
Business processes modelling helps to specify re-quirements to build an information system (IS).This is the requirements engineering (RE) process. The Business Process Modelling Notation (BPMN) is a business process modelling technique. Modelling processes with this technique results in Business Process Diagrams (BPDs). However, business processes can not directly be translated to functional requirements of an IS (Vara & Sanchez, 2009).

This gap was researched, a method for bridging the gap was developed, and the method was tested in practice. This gap is between the business and the system  domain, to which their paper was applied. Vara and Saanchez (2009, p. 124) define the goal of this method as "to present an approach that provides methodological guidance to properly specify functional re-quirements from business processes". This introduction will shortly explain the proposed approach. After the introduction, an example is used to elaborate on the method and related literature on the subject is discussed.

A global overview of the method is provided by
Vara and Sanchez (2009), which can be seen in
Figure 1. The method, or new approach as the
paper defines, is clearly divided in two stages.
These stages (and the preliminary stage) are shortly introduced, before using the method in
the example.

   * Figure 1: <br />
     <img src="%ATTACHURLPATH%/Figure_1.png" alt="Figure_1.png" width='723.2' height='160.8' />

Before the first stage, business processes are
modelled in collaboration with the stakeholders.
Together with written business rules and a table
with input and output data objects, these can
be seen as the To-Be-BPDs.

In the first stage, BPDs enrichment, the first
activity is BPD labelling. Input from the To-Be-BPDs is used to label the BPDs. Every element of the BPDs is labelled by system analysts
and stakeholders. This activity is called BPD labelling. Labels indicate the level of automation
of the element. Next to labelling, business rules
and data objects are also discussed.

Still in the first stage, the next activity is
the modelling of consecutive 
flows. Consecutive 
flows are an addition to the BPMN method.
This enables BPMN models to explicitly define
if a task following its preceding task is executed
immediately. Normal sequence 
flows of BPMN can not specify this behavior. As in the first activity, system analysts work together with stakeholders. Modelling of consecutive 
flows results in
enriched BPDs.

The second stage uses these enriched BPDs
to extract task descriptions. This stage is called
Specification of Task Descriptions. Task descriptions are defined by Vara and Sanchez (2009,
p. 128) as specifying "IS support for the execution of a set of consecutive 
flow objects of an
enriched BPD". This definition clearly integrates
the deliverables of the different stages. The filling of textual templates is done according to
guidelines. The stakeholders have to validate
these guidelines in this stage.

---+ Example
To illustrate the use of this method, an example
has been included in this paper. The method defined in Figure 1 is used in Table 1, which refers
to all example deliverables. The following sections explain the different steps of the method.

   * Table 1: <br />
     <img src="%ATTACHURLPATH%/Table1.png" alt="Table1.png" width='370' height='307' />
---++ Preliminary stage
The business process in this example is the processing of an order at a small webshop. System
analysts and stakeholders collaborate to model
an initial BPD. This is an iterative process where
the To-Be-BPD is constantly updated with the
feedback of the stakeholders. This feedback, and
also in the other stages, is not represented in the
examples. The example deliverables are deemed
sufficient to understand the method.

The result of the preliminary stage is illustrated in Figure 2. Notice that this BPD does
not specify the automation of elements or any
consecutive 
flows.

   * Figure 2: <br />
     <img src="%ATTACHURLPATH%/Figure_2.png" alt="Figure_2.png" width='588.28' height='176.33' />

---++ Stage 1 
After the initial BPD has been modelled, the
next activity of the method is BPD labelling.
Collaborators have to agree on the automation
of every single element of the BPD. There are
several labels which can be assigned to any element of the BPD. These are IS for controlled
by the system, O for out of the system, and U
for controlled by the system. For example, the
system analysts label the element 'Order item at
supplier' as being controlled by the system (IS).
Stakeholders however clarify that this element is
being controlled by the user (U), but carried out
by the system. Eventually, this discussion leads
to the conclusion that this step will be more efficient if it is automated. They agree to label the
element IS. This feedback process goes on until
stakeholders and system analysts agree on the
labelled BPD.

The agreement on automation results in the
labelled BPD, depicted in Figure 3.

   * Figure 3: <br />
     <img src="%ATTACHURLPATH%/Figure_3.png" alt="Figure_3.png" width='588.28' height='176.33' />

The agreement on automation also marks the
end of the first activity in the second stage. The
labelled BPDs can now be used for the next activity in the first stage: modelling of consecutive 
flows. Stakeholders and system analysts together discuss which 
flows of the BPD are consecutive 
flows. In this example, stakeholders and
system analysts might at first not agree on some
points. In the first activity, system analysts labelled the element 'Order item at supplier' as
IS. Therefore, they assumed that this element
immediately follows the preceding element 'Notify customer'. Stakeholders point out that this
is not done immediately, but once the demand
reaches a certain level. The 
flow between the
element is a sequential, and not a consecutive flow.

Eventually, they agree on all 
flows. The deliverable of this activity, and also of the first stage,
is the enriched BPD in Figure 4.


   * Figure 4: <br />
     <img src="%ATTACHURLPATH%/Figure_4.png" alt="Figure_4.png" width='588.28' height='176.33' />

---++ Stage 2
The textual template is filled with data from the
enriched BPD. This marks the translation from business processes to functional requirements.
Thus, this approach enables to bridge this gap.
The resulting example task description is found
in appendix A.1.

---+ Related Literature
The paper of Vara and Sanchez (2009) focussed
on a methodological approach to elicit functional
requirements from business processes. Requirement engineering is a critical success factor in
software projects (Hofmann & Lehner, 2001).

Practical experience from Vara and Sanchez
(2009) reveals BPMN is the right choice for communication business processes. BPMN stems
from the Object Management Group (Business
Process Modeling Notation Version 2.0 , 2011).
Several studies show the suitability of BPMN for
modelling business processes (Wohed, Aalst, Dumas, Ter Hofstede, & Russell, 2006; Owen, Raj,
et al., 2003; Aldin & Cesare, 2009). The creators
of the method also prefer BPMN to model business processes (Vara, Sanchez, & Pastor, 2008).

This research follows an earlier research by the
same authors. This approach proposed by Vara
and Sanchez (2008) is very similar to the newer
proposed approach by Vara and Sanchez (2009).
The modelling of consecutive 
flows was introduced in the latter to complete the approach.

Lauesen (2003) developed the Task & Support method, which generates task descriptions. These task descriptions have been used as a basis for Vara and Sanchez (2009). Lauesen (2003)
also discusses the benefit of task-based descriptions over use cases. Task-based descriptions can
integrate human and computer actions, where
use cases can only separate them.

In the preliminary stage of the BPMN-based
specication of task descriptions, business rules
are used to complement the BPD. Von Halle
(2002) showed the value of business rules. By
seperating data from processes, implementation
time can be reduced.

These studies on related literature show that
the method of Vara and Sanchez (2009) is very
relevant in the domain of requirements engineering, and uses well-supported concepts for their
method.
---+ References
Aldin, L., & Cesare, S. de. (2009). A comparative analysis of business process modelling
techniques.

Business Process Modeling Notation Version 2.0 (Tech. Rep.).
(2011, January). Available from
http://www.omg.org/spec/BPMN/2.0/PDF
(Retrieved 14 feb 2012)

Hofmann, H., & Lehner, F. (2001). Requirements engineering as a success factor in
software projects. Software, IEEE , 18 (4),
58-66.

Lauesen, S. (2003). Task descriptions as
functional requirements. Software, IEEE ,
20 (2), 58-65.

Owen, B., Raj, J., et al. (2003). Bpmn and
business process management introduction
to the new business process modeling standard. Management , 2678 (May 2008).

Vara, J. de la, & Sanchez, J. (2008). Improving requirements analysis through business process modelling: A participative approach. In Business information systems
(pp. 165-176).

Vara, J. de la, & Sanchez, J. (2009). Bpmn-based specication of task descriptions:
Approach and lessons learnt. Requirements Engineering: Foundation for Software Quality , 124-138.

Vara, J. de la, Sanchez, J., & Pastor, O. (2008).
Business process modelling and purpose
analysis for requirements analysis of information systems. In Advanced information
systems engineering (pp. 213-227).

Von Halle, B. (2002). Business rules applied:
Business better systems using the business
rules approach . John Wiley and Sons Ltd.

Wohed, P., Aalst, W. Van der, Dumas, M.,
Ter Hofstede, A., & Russell, N. (2006). On
the suitability of bpmn for business process
modelling. Business Process Management ,
161-176.

---+Appendix

   * Appendix A.1: <br />
     <img src="%ATTACHURLPATH%/appendixA1.png" alt="appendixA1.png" width='483' height='406.8' />
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	Figure_1.png	manage	77.6 K	16 Feb 2012 - 15:05	KevinVanRooij	Figure 1
png	Figure_2.png	manage	15.8 K	16 Feb 2012 - 15:07	KevinVanRooij	Figure 2
png	Figure_3.png	manage	17.5 K	16 Feb 2012 - 15:07	KevinVanRooij	Figure 3
png	Figure_4.png	manage	20.1 K	16 Feb 2012 - 15:07	KevinVanRooij	Figure 4
png	Table1.png	manage	26.2 K	16 Feb 2012 - 15:08	KevinVanRooij	Tabel 1
png	appendixA1.png	manage	64.5 K	16 Feb 2012 - 15:08	KevinVanRooij	Appendix A.1