business process-driven requirements engineering: a...

Business process-driven requirements engineering: a goal-based approach

Jose Luis De la Vara González, Juan Sánchez Díaz

Department of Information Systems and Computation Valencia University of Technology

Camino Vera s/n, 46022, Valencia, Spain {jdelavara, jsanchez}@dsic.upv.es

Abstract. When developing an information system, software analysts must take the business environment into account so that the system properly fulfils the needs of the organization. Although requirements engineering is the bridge between enterprise and system domains, most of the research in this area is still solution-oriented, which does not address the real problems of the organization. As a consequence, since the enterprise is not correctly analyzed, the information system may not meet expectations, and business/IT alignment will not be achieved. To prevent these problems, we describe a business process-driven requirements engineering approach that allows software requirements to support the operations of an enterprise and assure business/IT alignment. This approach is based on the mapping of business process goals into system goals form which requirements are defined.

1 Introduction

The development of an information system (IS) is a complex process that not only requires the resolution of technical problems, but that also requires the organizational environment related to the application domain to be taken into account. In business contexts the application domain is constituted by the organization where the system will be deployed. Therefore, a good knowledge of the application domain is critical to be able to succeed in requirements elicitation.

Several authors have pointed out the importance of organizational modelling before requirements elicitation [13][21][23]. Organizational models depict the structure and behaviour of an enterprise and are very useful in helping developers properly understand the organizational environment and the requirements that the system must fulfil.

Nowadays, it is widely acknowledged that any IS must be a business process support system [1] (or process-aware information system [6]) that manages and executes operational processes involving people, applications, and/or information sources on the basis of process models. Since this shift has a direct impact on requirements engineering, new techniques differ from traditional ones. First, the traditional data-model does not give enough information to build a system, so a detailed process model is needed. Second, new systems must not only support a

2 Jose Luis De la Vara González, Juan Sánchez Díaz

business as is, they must also support a hypothetical new way of running the business that would not be possible without the system.

This paper describes an approach to derive requirements models from organizational models by means of goal modelling. Different stakeholders take part in the process. The links between the domains are the BPMN notation [17], which can be understood by all the stakeholders, and a goal tree that is derived from business process models. The goal tree is then labelled to represent the system impact, and finally a use case model is derived. The process assures business/IT alignment since software models are defined from organizational models.

This paper is organized as follows: section 2 presents the general principles of the proposed technique; sections 3 and 4 describe the stages of the technique in detail; finally, section 5 and 6 present related work and our conclusions.

2 Proposal overview

The proposal (Figure 1) is based on the perspective of strategy execution within the strategic alignment model [9], where business strategy is the driver of both organizational design choices and, subsequently, the design of the IT infrastructure. Therefore, we address business strategy, business infrastructure, and IT infrastructure. All of them must be in concordance to assure business/IT alignment, which will only be feasible if requirements are correctly defined from the beginning.

Figure 1. Stages of the proposal

In the first stage of the proposal, the business strategy is defined by means of an organizational mission statement, the strategic goals that support the statement, and the measures that indicate business success and their target level. Afterwards, the business infrastructure is represented by the organizational operational structure through a process map, a role model, a resource model, and business processes. Finally, business process goals are extracted and analyzed, the system goals are defined, and then requirements are derived from them. The output is a set of use cases that the system must fulfil to meet the operational needs of the enterprise. These requirements are the basis for the proper creation of IT infrastructure.

Business process-driven requirements engineering: a goal-based approach 3

3 Business strategy and infrastructure modelling

Business strategy is defined by organizational managers. It is a difficult task due to the complexity of business management. As a consequence, several models, such as BSC [11], ISO 9000 [10], or EFQM [8], have been formulated to support proper business strategy definition and organizational management.

These models describe business strategy by means of an organizational mission statement and the strategic goals that support it. The mission statement states why the organization exists and its main objective, whereas strategic goals represent how the mission can be fulfilled and why processes exist. In order to assess the success of the enterprise, measures related to strategic goals and their target levels are defined. Processes make measure assessment possible (Figure 2).

Figure 2. Correspondence among business strategy concepts

The next step is the modelling of business infrastructure. It is comprised of a process map, a role model, a resource model, and business process models. In the process map the processes are classified into three categories: strategic processes, which are the related to managerial scope and which concern planning processes and key factors in the long term; operative processes, which are linked with product creation and/or service provision; and support processes, which support operative processes, and which usually concern resources and measures. Since processes make measure assessment possible, they support strategic goals and the organizational mission. With regard to the role model, it is a standard model where actors play roles and where each role develops a set of activities within processes. The resource model is a glossary in the form of a class diagram that represents the most important concepts of the organizational domain that are used within processes.

Finally, business processes are modelled. A business process can be defined as a complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers [22]. We use BPMN [17] for business process modelling. This is a notation that has recently been developed and has a broad support


in industry. Its offers a notation that is easy-to-understand by all business process users (process analysts, IS developers, process managers…). Therefore, BPMN provides a standard that fills the gap between business models and their implementation.

Figure 3. Process of order management for a garment company

Figure 3 is an example of a BPMN diagram, which will serve as a case study. Figure 4 shows its resource model. It is a real process for the management of the orders of a garment company. A secretary selects the orders that must be processed. Each order contains the clothes ordered and the shipment destinations, and the packing lists show the decomposition of the order by shipment destination. The clothes are sent with a delivery note, and store managers select the destinations that must receive the clothes first. Store operatives receive the delivery note and place the garments in the boxes to be shipped. If there are not enough clothes in stock to cover the order, the clothes that are available are placed in the boxes. Then the store manager decides whether to wait for the rest of the order or to send the partial shipment. The packing list is modified in either case and is sent to secretary, who creates the final version of the packing list. Then the delivery note is placed into the box and the final shipment is prepared for delivery. All this information is exchanged on paper.

Figure 4. Resource model for case study


4 IT infrastructure link

After business infrastructure modelling has been performed, the IT infrastructure is defined. First the requirements must be specified in order to exactly state what the system must do according to business processes. To generate a proper specification, business infrastructure and IT infrastructure must be linked. Thus, IT infrastructure reflects the organizational operational behaviour, the system meets the needs of the enterprise, and business/IT alignment is achieved. As Figure 5 shows, this link is feasible thanks to the business process goals that are derived by means of heuristics. These goals are analyzed so that the system goals are established and the system requirements are defined from them.

Figure 5. Models and steps for IT infrastructure link

4.1 Derivation and analysis of Business process goals

Goals have been widely and successfully used in requirements engineering [13][15]. A goal can be defined as an objective or state that must be reached, and its definition makes reference to a set of properties whose fulfilment must be guaranteed.

Figure 6. Business process goal tree for case study

Processes have goals that must be fulfilled during or after their execution [12][14].

There are sub-goals that denote important milestones within the process, and whose


fulfilment is possible due to the actions of all the participants involved [19]. These sub-goals are operational goals that indicate when a process instance can be considered completed [2]. When using BPMN, sub-goals may be explicitly declared within the process structure or other models may be needed for their detection.

Our approach proposes the construction of a goal tree for the definition of business process goals. It uses the concepts of goal and task of i* [23]. A tree is created from structural patterns that are identified in BPMN diagrams following certain heuristics. For reason of brevity, these heuristics are not presented; they can be found in [5].

Figure 6 shows the goal tree for our case study. The process itself represents a goal and, every task and event with a trigger is represented as a task in the tree. Since loops must be fulfilled and some data objects must have a certain state at the end of the process, these conditions represent goals. Furthermore, inclusive aggregation relations in the resource model make some data objects goals contribute to other goals.

Figure 7. Labelled business process goals tree for case study

After the goal tree is defined, leaf elements are labelled according to the effect that the system development will have on them: the labels are “A” when the system supports the goal or task and therefore can be automated; the labels are “C” when the element is ceased because the IS carries out the task or goal autonomously without human intervention; the labels are “M” when the goal or task is manually fulfilled. If an element is labelled with “C”, the tasks that make the cessation possible must be defined, and the system develops them automatically. These tasks are then labelled as “IS”. Afterwards, all the labels are propagated to the higher levels.

Once the goal tree has been labelled, business process reengineering is possible. Since system development may entail the introduction of new actions that were not needed or feasible before and elements labelled as “C” are removed, a new business process goal tree can be defined and the process can be redesigned.


Figure 7 shows the labelled goal tree for this case study. The task “Print delivery note” has been introduced to fulfil the goal “Place delivery note”, and now the process does not require the participation of a secretary because all her actions are ceased.

Finally, the system goal tree is obtained by removing the elements that are labelled with “C” and “M”. The rest of the elements denote services that the IS must provide to support the process.

4.2 System requirements derivation

A use case model [18] is derived from the system goal tree, so the model depicts the requirements defined within the tree. Use cases are the tasks of the tree and they are put into packages that correspond to business processes. The use cases can be modified by the system analyst to improve their expressiveness. Also, relationships between use cases can be defined, and use cases can be introduced for user management or authentication.

Afterwards, the analyst assigns use cases to actors. If the use case comes from a task that is labelled as “IS”, then a “Clock” actor is in charge of the use case when the requirement takes place periodically and automatically; otherwise the use case is included (<<include>> relation) within another use case, which triggers it. When the label is “A”, then the actor is the participant who executes the element within the process from which the requirement is defined. New actors and the relationships among them can also be introduced.

Figure 8. Use cases diagram for case study

Figure 8 shows the use case diagram corresponding to the package “Order management” that was created for this case study. The following actors have been introduced: the “Clock” actor for periodical and automated functionality in the system; the “Administrator” actor for user management; the “User” actor for user authentication; and “Store staff” actor for common store operative and manager functionality. The “Check delivery note” use case substitutes the “Validate box” and “Distribute boxes” uses cases because it is the functionality that is actually needed.


5 Related work

Several proposals consider business modelling as the first step for software development. Some of them are i* [23], KAOS [4] and EKD [3]. Approaches that use UML are Eriksson [7] and Marshall [16].

The i* framework is focused on the dependencies among the organizational actors. Its models are considered to be strategic because actors are not only interested in achieving their own goals, but are also interested in relationships with other actors. We think that the i* models are too complex and are not scalable when applied to large real problems.

KAOS requirements models are built from organizational goals. This approach is supported by a formal framework that rigorously defines each term. Its main contribution is that it demonstrates that requirements correspond to system goals. However, one drawback is that it does not provide any mechanism to describe business processes.

EKD provides a way of analysing an enterprise by using enterprise modelling. It is composed of a goal model, a business rule model, a concepts model, a business process model, an actors and resources model, and a technical components and requirements model. In our opinion, EKD may be inconvenient to use because none of its models are standard.

The UML based approaches use elements that are very close to those elements used in the software development area. These approaches do not clearly specify some organizational aspects such as technology that implements business processes or the relationships among the different organizational views.

6 Conclusions and future work

In an organizational scope where management is based on process analysis and improvement, development methodologies for business process support systems differ from traditional ones. Therefore, organizational concerns must be taken into account and requirements engineering approaches must provide new ways of elicitation.

This paper has described a proposal to derive requirements models from organizational models by means of processes goals. This proposal allows developers to identify the system requirements that will support the organization in a systematic and participative way, where business managers, business analysts, and system analysts all take part. Since requirements are defined from business processes that support strategic goals, this approach guarantees business/IT alignment.

The proposal is currently being used in real cases, so that it can be evaluated and improved. The main objective of this proposal is the extension of OO-Method [20], which is a methodology for automatic software generation based on conceptual modelling, in order to broaden its scope to organizational and requirements modelling. In consequence, ways of properly linking this approach with OO-Method are now under study and discussion.


References

[1] Alexander, I., Bider, I., Regev, G.: Workshop on Requirements Engineering for Business Process Support (REBPS'03), Objectives and Motivation, Proceedings CAISE'03

[2] Bider, I.: Choosing Approach to Business Process Modeling – Practical Perspective, Research Report, Ibisoft, 2003

[3] Bubenko, J., Persson, A., Stirna, J.; EKD User Guide, 2001, http://www.dsv.su.se/~js/ekd_user_guide.html

[4] Dardenne, R., Lamsweerde, A. van, Fickas, S.: Goal-directed Requirements Acquisition. Science of Computer Programming, Vol. 20, New Holland, 1993, pp. 3-50

[5] De la Vara, J. L.: Requirements models derivation from organizational models. MC Thesis, Valencia University of Technology, 2006

[6] Dumas, M., Aalst, W. van der, Hofstede, A. ter: Process-Aware Information Systems. Wiley, 2005

[7] Eriksson, H., Penker, M.: Business Modeling with UML: Business Patterns at Work. OMG John Wiley and Sons, 2000

[8] European Foundation for Quality Management. http://www.efqm.org [9] Henderson, J. C., Venkatraman, N.: Strategic alignment: Leveraging information

technology for transforming organizations. IBM Systems Journal, 38(2-3): 472-484, 1999 [10] International Organization for Standardization. http://www.iso.ch [11] Kaplan, R., Norton, D.: The Balanced Scorecard : Translating Strategy into Action,

Harvard Business School Press, 1996 [12] Kavakli, E., Loucopoulos, P.: Goal-Driven Business Process Analysis Application in

Electricity Derregulation, Information Systems, 24(3), 1999, pp. 187-207 [13] Kavakli, E., Loucopoulos, P.: Goal Modeling in Requirements Engineering: Analysis and

Critique of Current Methods, Information Modeling Methods and Methodologies, 2004, pp. 102-124

[14] Kueng, P., Kawalek, P.: Goal-based business process models: creation and evaluation, Business Process Management, 3(1), 1997, pp.17-38

[15] Lamsweerde, A. van: Goal-Oriented Requirements Engineering: A Guided Tour. Proc. 5th IEEE International Symposium on Requirements Engineering, 2001, Toronto, Canada

[16] Marshall, C.: Enterprise Modeling with UML. Addison-Wesley, 2001 [17] OMG: Business Process Modeling Notation (BPMN) Specification, february 2006,

http://www.bpmn.org [18] OMG: Unified Modeling Language: Superstructure Version 2.0, july 2005,

http://www.uml.org [19] Ould, M.: Business Processes: modelling and analysis for re-engineering and

improvement. Wiley, 1995 [20] Pastor, O., et al.: The OO-Method approach for information systems modeling: from

object-oriented to automated programming, Information Systems, 26, 2001, pp. 507-534 [21] Regev, G., Wegmann, A.: Defining Early IT System Requirements with Regulation

Principles: The Lightswitch Approach, Proc. 12th IEEE International Requirements Engineering Conference (RE’04), 2004

[22] Smith, H., Fingar, P.: Business Process Management: The Third Wave. Meghan-Kiffer Press, 2002

[23] Yu, E.: Modeling Strategic Relationships for Process Reengineering. PhD Thesis, University of Toronto, 1995

business process-driven requirements engineering: a...

Documents