BPMNBased Speci Cation Of Task Descriptions

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) define 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 defines, is clearly divided in two stages. These stages (and the preliminary stage) are shortly introduced, before using the method in the example.

• Figure 1:
  

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 define 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 Specification of Task Descriptions. Task descriptions are defined 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 definition 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 defined 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:
  

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:
  

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:
  

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 first 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:
  

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 specication 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 specication 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: