_bpmn_anali2

8/7/2019 _BPMN_anali2

1/14

Improving Requirements Analysis through

Business Process Modelling: A Participative

Approach*

Jose Luis de la Vara and Juan Snchez

Department of Information Systems, Valencia University of Technology,Valencia, Spain

{jdelavara,jsanchez}@dsic.upv.es

Abstract. Although requirements analysis is acknowledged as acritical success factor of information system development fororganizations, mistakes are frequent at the requirements stage.Two of these mistakes are the lack of understanding of the businessby requirements engineers and the miscommunication betweenbusiness people and systems analysts. As a result of theseproblems, information systems may not fulfill organizational needs.To prevent these problems, this paper describes an approach based

on business process modeling. The business environment ismodeled in the form of BPMN diagrams. The diagrams are validatedby end-users and are then analyzed by systems analysts in order toreach an agreement on the effect that the information system willhave on the organization. Finally, requirements are specified bymeans of the description of the business process tasks to besupported by the information system.

Keywords: Requirements analysis, understanding of the business,communication, business process, BPMN.

1 Introduction

Requirements analysis is acknowledged as a critical success factor forsoftware projects [32]. If not properly addressed, requirements cancause a project to fail. Nevertheless, practical experience proves thatmistakes are frequent at this stage of information system (IS)

development for organizations. Two of these mistakes are the lack ofunderstanding of the business by requirements engineers and themiscommunication between business people and computing people.These problems can hinder business/IT alignment [19][27], thus IS doesnot fulfill the needs of the organization.

Requirements must be defined in terms of phenomena that occur inthe business environment [38]. However, it is common for requirementsdocumentation to be solution-oriented, to not reflect the businessenvironment, or to only consist of a data model in the form of a class or


2/14

entity-relationship diagram. As a solution, several authors have pointedout the importance of organizational modeling during

*This work has been developed with the support of the Ministry of Education andScience of Spain under the project SESAMO TIN2007-62894 and the program FPU,and cofinanced by FEDER.W. Abramowicz and D. Fensel (Eds.): BIS 2008, LNBIP 7, pp. 165176, 2008. Springer-Verlag Berlin Heidelberg 2008

requirements analysis [3][4][37] and the role that requirementsengineers play as business analysts [15][28]. Organizational modelsdepict the structure and behavior of an enterprise and are very useful inhelping developers properly understand the business environment andthe requirements that an information system must fulfill.

Furthermore, good communication between business people andsystems analysts is essential at the requirements stage [17][20][30],however it can be difficult to achieve. There is a gap between thebusiness domain and the computing domain that can cause mismatchesbetween what customers say and what requirements analystsunderstand. Even worse, what customers think they have said and whatrequirements analysts think they have understood can be totallydifferent. One reason for this miscommunication is that therequirements models that are used can be hard to understand and

difficult to validate by customers because of their lack of computingbackground. Therefore, models that facilitate communication duringrequirements analysis should be used.

To prevent these problems, business process modeling is a goodsolution. Business process modeling has not only been acknowledge asa good means for organizational modeling, but also as a must forinformation system development [1][12][25]. In addition, businessprocess models facilitate human understanding and communication bysharing a common representational format [8]. Among the several

notations for business process modeling currently available is BPMN(Business Process Modeling Notation) [23]. It has been designed to beeasily understandable, and it is positioned as the de facto standard forbusiness process modeling.

Although there are several related works that define solutions to theproblem of linking organizational modeling and requirementsengineering (which will be described in more detail in Section 2), themain contribution of this paper consists in providing a methodologicalapproach for deriving the software functionality from organizational

models. The approach allows systems analysts to properly understandand analyze the organization, its needs, and goals in a participative waywith business people and end-users.

In short, this work describes a requirements analysis approach basedon business process modeling. This approach is the result of a projectbetween the Technical University of Valencia and the company CARETechnologies [5]. The business environment is modeled in the form ofBPMN diagrams. The diagrams are validated by end-users and are thenanalyzed in order to reach an agreement on the effects that an IS will


3/14

have on the organization. Finally, requirements are specified by meansof the description of the business process tasks to be supported by theinformation system. These well-defined requirements are the input ofthe subsequent development stages.

The paper is organized as follows: section 2 presents related works;section 3 presents the general description of the approach; sections 3.1,3.2 and 3.3 describe the stages of the technique in detail; section 4describes practical experience using the approach; finally, section 5presents our conclusions and future work.

2 Background and Related Work

This section presents background research: section 2.1 describes BPMN;section 2.2 review organizational modeling and goal-orientedrequirements approaches.2.1 BPMN

We use BPMN for business process modeling because it offers a notationthat is understandable by all business process users (process analysts,IS developers, process managers). Therefore, BPMN provides astandard that fills the gap between business models and theirimplementation. The notation consists of a diagram, called Business

Process Diagram (BPD), whose aim is to provide a means for thedevelopment of graphical models of business process operations. A BPDis designed from a set of graphical elements that make diagrams simpleto develop and easy-tounderstand. The graphical elements are flowobjects, connecting objects, swimlanes, and artifacts [23].

Several surveys have evaluated the adequacy of BPMN for businessprocess modeling [22][35][36]. From our point of view, BPMN has threemain advantages: it is one of the most expressive notations, it is easy touse and understand, and it has been receiving strong support from both

practitioners and vendors. As a result, BPMN is considered to be the defacto standard for business process modeling.

2.2 Related Work

The need for organizational modeling in requirements engineering hasbeen widely acknowledged. Many approaches consider it to be the firststep in software development, and some of them use business processmodeling. Nevertheless, the use of models and techniques that facilitatethe communication with customers is not common. Some of the

approaches that have received attention in the last few years arereviewed in this section.

The i* framework [37] is one of the most popular techniques fororganizational modeling. It has been used in several requirementsengineering and software development methods, such as Tropos [6]. i*is a goal-oriented technique that is focused on the dependencies amongthe organizational actors. Its models are considered to be strategicbecause actors are not only interested in achieving their own goals, but


4/14

are also interested in relationships with other actors. As stated by otherauthors [3][14], the i* framework has some deficiencies. Its models canbe too complex, and they do not support granularity and refinement.

EKD [4] provides a way of analyzing an enterprise by using enterprise

modeling. It is composed of a goal model, a business rules model, aconcepts model, a business process model, an actor model, a resourcesmodel, a technical components model, and a requirements model. In ouropinion, EKD may be inconvenient to use because none of its models arestandard. Furthermore, it lacks tool support to facilitate thedevelopment and maintenance of all its models.

Some approaches use UML models for organizational and businessprocess modeling [13][21]. These approaches use elements that areclose to those elements used in software development areas. However,

this fact is a drawback because models that are easy to use andunderstand by computing people tend to be too complex to be validatedby customers. In addition, the UML-based approaches do not clearlyspecify some aspects such as the technology that implements businessprocesses or the relationships among the different organizational views.

The ARIS method [29] provides a framework for developing,optimizing and describing integrated information systems. Thearchitecture is structured in four levels: process engineering, processplanning and control, workflow control, and application systems. The

aim of the ARIS framework is to describe an information system forsupporting business process. Therefore, the core of ARIS is the businessprocess, which is a sequence of activities in an enterprise to generateoutput for the process customer. A reduction of complexity withinenterprise modelling is achieved by using different views. The differentviews are connected within the process view. The most importantspecification document for presenting the business process model is theevent-driven process chain (EPC) diagram that integrates all possibleviews. ARIS contains different techniques for modelling: entityrelationship (ER), UML class diagram, use case, and EPC, however aconcrete description for the use of each model during a specific phase ismissing [10].

Another interesting and more recent technique is B-SCP [3], whichintegrates business strategy, context and process using a requirementsengineering notation for each of them. Its purpose is to enable theverification and validation of requirements in terms of alignment withand support for business strategy, as well as with the businessprocesses that support that strategy. B-SCP uses RADs [25] for businessprocess modeling, which is less expressive than BPMN. In addition, it has

problems associated with goal decomposition, and we think that itsrequirements specification should be more precise.

3 Approach for BPMN-Based RequirementsEngineering

In this section, we present a precise method to guide the construction ofrequirement models corresponding to organizational models using BPMN


5/14

diagrams, according to the ideas introduced in section 1. Figure 1 showsa schematic representation of the activities contained in the proposedmethod. The approach consists of three stages: organizational modeling,business process analysis, and functional requirements specification.

The first stage depicts the current business environment (As-Is), whichhas some problems to be solved or needs to be fulfilled by the new (ormodified) IS. Since the organization will change due to the ISdevelopment (To-Be), the changes may have an effect on businessprocesses.

In this first stage, the organization for which the IS is going to bedeveloped is modeled. The information gathered is the following: aglossary, the business events, the business rules, a role model, aprocess map, and the domain data. Business process diagrams of

the organization are created from this information. !!!!During business process analysis the diagrams are analyzed inorder to reach an agreement on the effects that the development of theinformation system may have on the business process. One of theseeffects is the support or control that the information system will have.The business process elements are labeled according which tasks thesystem will carry out and which tasks will be manually executed.Changes in the business process can occur.

Finally, functional requirements are specified by means of the

description of the business process tasks to be supported by the IS.Every task will have a textual template that describes it. The set oftemplates will be the starting point for the rest of the developmentstages.


6/14

Fig. 1. Approach overview

3.1 Organizational Modeling

To model an organization, the first step is to interview the staff so thatthe people that play roles in the organization can describe their work. Inaddition, it is advisable to look through the available documentationrelated to the organizational activity and the business policies. Thepurpose of the information collected in the organizational modelingstage is to understand the business environment to be able to model thebusiness process correctly.

The processes are classified into three categories in the process map[16]: management processes, which are the processes related to themanagement and concern key factors in the long term; core processes,which are linked with product creation and/or service provision; andsupport processes, which support operative processes and usuallyconcern resources and measures. A glossary is used to define all theorganizational concepts unambiguously. Business events are recurrentand significant things that occur while the organization activity goes onand to which the organization must respond. Business rules constrain ordefine the organizational data and behavior. The different roles and theactivities that the roles are responsible for are specified in the rolemodel. The domain data are the entities of the organizational domain


7/14

that are the input and the output of business process tasks. They arerepresented by means of a class diagram where there are only classesand the relations among them.

Finally, business processes are modeled from the weaving of all the

above information. A business process can be defined as a complete anddynamically coordinated set of collaborative and transactional activitiesthat deliver value to customers [31] and collectively realize a businessobjective or policy goal [34]. Every business process of the process maphas a BPD. BPDs are created from the weaving of all the informationgathered, so BPMN graphical elements correspond to this information.The organization is modeled as a pool of every BPD, and the roles aremodeled as the lanes. The activities of the roles are modeled as tasksand are included in the BPDs. Events have to be classified as start,

intermediate, and final. Each event is included in the BPD where theactivity to be triggered is located. Business rules are modeled asgateways, or defined as documentation of the business process tasks, ifthey cannot be represented graphically. Data objects are included inBPDs later.

The process of organizational modeling is not straightforward andrequires a good interaction between the customer and the requirementsengineer. Customers must validate the BPDs to guarantee that theyproperly reflect the organization, and several iterations are usually

needed.

3.2 Business Process Analysis

In the second stage, once the organizational modeling is finished, therequirements engineer has enough knowledge of the business toproperly understand its activity.

The introduction of an IS in an organization requires business processreengineering and its effect can be assessed before, during or after aprocess is designed [2]. The new business process (to-be) can be

designed from the original one (as-is), from the organizational problemor need, or from the solutions that the IS can provides. The IS willsupport the required business processes and will be designed in termsof the IS capabilities.

A BPD depicts both the high level requirements specification and thebusiness requirements of the IS. The elements of the business processesare analyzed to establish the effects that the IS will have on them, todetermine the elements that will disappear, and to determine the newelements that will be introduced to improve the process. Different

alternatives can be proposed, and a solution must be agreed upon withthe customer.

When a solution is agreed upon, the business process elements arelabeled according to the IS support. Events and gateways can be labeledas follows: O (out of the system) if the element will not be part of thesystem and will not affect it, IS (controlled by the system) if the IS willbe in charge of the control and execution of the element with no humanparticipation. Apart from these two labels, tasks can be labeled as U(executed by a user) if they will be executed by a user that interacts


8/14

with the IS.Figure 2 shows the application of business process analysis to the

case study of a company that rents apartments for holidays on thecoast.

The organization has increased its number of apartments due togrowth in the number of customers. Therefore, an IS is needed tofacilitate the organizations activity and increase its efficiency. As anexample, the check-out process is used. Its

Fig. 2. Labeled check out process of an apartment rental company

purpose is to have the apartments ready to be cleaned so that newcustomers can move in. The process starts when a customer goes to thereception desk to check out, or when occupation of the apartment hasexpired and the customer has yet not checked out. In this case, thehousekeeper must notify the customer of this fact. Once the receptionistchecks the customer data and receives the apartment keys, thehousekeeper must check the inventory of the apartment and itscondition in order to guarantee that nothing is missing or damaged. Ifthere is something damaged, the housekeeper will create a repair reportand the receptionist may charge the customer for existing damages.Finally, the receptionist returns the deposit to the customer and marksthe occupation as finished. Data flow (through BPMN data objects) is notshown in the figure for reasons of clarity.

Among several alternatives, Figure 2 shows the solution that wasagreed upon with the rental company so that the business process wassupported by the IS. The system will be in charge of triggering theoccupation expiration. The housekeeper will use the IS when notifyingcustomers, checking the apartment inventory and creating repair


9/14

reports. Lastly, the receptionist will use the system when checking thecustomer data, invoicing charges and marking occupations as finished.

3.3 Functional Requirements Specification

In the last stage of the approach, functional requirements are specifiedfrom the labeled BPD. For this purpose, business process tasks to besupported by the system (labeled as executed by a user or controlled bythe system) are described through a textual template.

The content of the template is based on Constantines essential usecases [7] and Lauesens task & support descriptions [18]. An essentialuse case is a simplified and generalized form of a use case. It depicts anabstract scenario for one complete and intrinsically useful interaction

with a system as understood from the perspective of the users. A task &support description is a way to express what the system actors want toperform, including domain-level information and how a new systemcould support an activity to solve a problem. Both essential the usecases and the task & support descriptions contain the fewestsuppositions about technology.

An example of task template is shown in Table 1. It corresponds to theNotify customer task of the check-out process. The template includesthe business process to which the task belongs, the name of the task,the role responsible for its execution, the trigger preconditions, and thepostconditions of the task, the input and output data and their states,and a specification of the interaction between a user and the IS throughuser intention and system responsibility.

All the information of the task templates comes from BPDs. The nameof the business process and the name of the task are the same as intheir BPD. The role is the participant in the business process that is incharge of the task. The triggers correspond to the events with a triggerthat precede the task in the business process and have to be part of theIS (controlled by the system), in the same way the preconditions

correspond to the gateways that represent decisions and are part of theIS. The postconditions section describes what the change in state of thesystem will be after the task is completed. The input and output of thetask is its data object in the business process. Finally, user intention andsystem responsibility are defined from the behavior of the participant incharge of the task when executing it and how the system will support it.User intention can also include actions that do not represent interactionswith the system. The business rules specified in the templatecorrespond to the business rules defined as the documentation of the

task in the organizational modelling stage.After every business process task has been described, the subsequent

development stages will base their work on the task templates toprovide the organization with an IS that fits its needs, its structure, andits behavior.

Table 1. Template for the Notify Customer Task


10/14

Business Process: Check out

Task: Notify Customer Role: Housekeeper

Triggers

Occupation expired

Preconditions -Postconditions

Updated information stored in System

Input Output

Data Object State Data Object State

Occupation Expired OccupationExpiration Notified

Customer - --

User intention System responsibility

1. Show the apartments whose occupation

has expired

2. Select an apartment

3. Show the occupation and the customer

data

4. Phone the customer

5. Notify the customer of the occupationexpiration

5. Mark the occupation expiration as notified

6. Record the notification of occupation

expiration

Business Rules

1. Clients are to check out by 10.00 a.m. on the last day of their stay at the latest, and they

are obliged to have vacated the apartment by this time.

4 Practical Experience The research project presented in this paper has been done in thecontext of the OO-Method project [24]. OO Method is an industrial modeltransformation method that relies on a CASE tool to automaticallygenerate complete information systems from object-oriented conceptualmodels. As stated above, the approach is the result of a project with acompany, CARE Technologies. The purpose of the project was to solveproblems related to the requirements stage by trying to link the


11/14

business domain and the software domain.After analyzing the requirements practices of CARE, we identified

problems related to business understanding, purpose analysis of the IS,and communication with end-users. The company uses OO-Method [26],

a methodology for automatic software generation based on dataconceptual modelling. The conceptual schemas consist mainly of a classdiagram that is enriched with functional information about the result ofclass service execution. Analysts usually use class diagrams as a uniquesystem model, by simply providing a textual description about therequirements and validating them on the class diagram or when theapplication has been generated.

Although analysts feel comfortable with this technique for informationsystem development, we think it could be improved. Some authors have

stated that class diagrams alone might not be appropriate forcommunicating and verifying requirements, that there are few empiricalstudies addressing the ability of end-users to understand class models,and that they can be very complex for people that have not beentrained in object-oriented modelling [11]. In addition, objects might notbe a good way of thinking about a problem domain [33].

The approach has been used in three projects in order to evaluate itand to try to find deficiencies and make improvements. It is currentlybeing used on new projects. The approach has been refined gradually

based on the comments of both customers and analysts. The projectsdeveloped were a car rental company, the organization of a golftournament, and the organization of this case study. They aresmall/medium size projects. CARE had developed software for thecompanies previously, so both the techniques that they usually use andthe approach that we have proposed could be compared.

For the case study (apartment rental company), the introduction ofthe new IS did not change the business process significantly, and theresult was automation rather than reengineering.

We held five meetings to obtain the requirements specification of thecase study: two meeting for organizational modelling, one meeting todefine the task templates, and one meeting to validate the entirerequirements specification. A fifth meeting was held to talk about theexperience with end-users and analysts. Each meeting tookapproximately 2 hours.

As expected, the end-users stated that they could understand andvalidate the requirements models of the approach more easily than theclass diagrams, thus facilitating communication and interaction. Theyalso felt more involved in system development and claimed that they

had a more participative attitude.When asking analysts about the usefulness of the approach, we

obtained different opinions. Although all the analysts stated that theapproach allowed them to better understand the organizations, thepurpose of the IS, and, consequently, the requirements, there weresome analysts who did not think the approach could improve their jobsignificantly and would probably not use it.

We do not find these comments about the usefulness of the approach


12/14

discouraging. When analyzing the opinions more deeply, the analyststhat did not think that the approach was as useful were senior analystswho are already very skilled in modelling with OO-Method andinteracting with customers. In fact, some of them said that they usually

model the systems while the customer describes what the systemshould do, so they can quickly generate it, validate it, and fix it ifneeded. However, most of the junior analysts, who have less experiencein dealing with customers and, therefore, in understanding what iswanted or needed, considered that the approach could really help them.

We think these results are a reflection of common practices ininformation system development. Models are only used when they arebelieved to be useful [9]. In our case, some senior analysts do not thinkthat the approach can accelerate their job, whereas junior analysts think

that it can improve their performance.Finally, this practical experience has some limitations. First, we thinkthe approach has to be used in more projects to draw definiteconclusions. Second, the opinions of both the customers and theanalysts were obtained by discussing with them informally, so we arenow designing a specific form to survey the next projects. Last but notleast, we also want to assess the approach by means of experimentswith students and software developers from other companies.

5 Conclusions and Future Work

A methodological approach to guide the process of deriving requirementmodels from organizational models has been presented in this paper. Asa main contribution, the approach allows requirement engineers toproperly understand the organization and its environment in aparticipative way with customers. Business people and requirementengineers both share a common language thanks to BPMN and tasktemplates. BPDs are the basis for the customer to validate that the

organizational structure and behavior is properly understood so that therequirements engineers can propose solutions for the organizationthrough an IS. This is an important point because the approach impliesthe involvement of business people, which is another success factor insoftware development [32].

Requirements analysis is still a stage of software development wheremistakes are common. Therefore, it can be the source of problems insubsequent development stages, which can cause an IS not to fulfill thereal needs of the organization. Two mistakes which have been detected

in practice are the lack of understanding of the business byrequirements engineers and the miscommunication between businesspeople and computing people.

As stated above, the approach is the result of a project with acompany whose purpose is to link business and software domains.Future work on the project involves the development of a tool thatsupports the approach. It also involves: the linking of this approach tothe OO-Method [26], which is a methodology for automatic softwaregeneration based on conceptual modeling, and the introduction of a


13/14

technique for the analysis of non-functional requirements.In addition, we want to extend the approach by introducing

information about the user interface in the task templates in order toderive an abstract description of the interaction between the users and

the IS.

References

[1] Alexander, I., Bider, I., Regev, G.: Workshop on Requirements Engineeringfor Business Process Support (REBPS 2003), Klagenfurt/Velden, Austria(2003)

[2] Attaran, M.: Exploring the relationship between information technology andbusiness process reengineering. Information & Management 41, 585596

(2003)[3] Bleistein, S.: B-SCP: an integrated approach for validating alignment of

organizational IT requirements with competitive business strategy. PhDThesis, The University of New South Wales, Sidney, Australia (2006)

[4] Bubenko, J., Persson, A., Stirna, J.E.: User Guide (online) (2001),http://www.dsv.su.se/~js/ekd_user_guide.html

[5] CARE Technlogies, http://www.care-t.com[6] Castro, J., Kolp, M., Mylopoulos, J.: Towards requirements-driven information

systems engineering: the Tropos Project. Information Systems 27, 365389(2002)

[7] Constantine, L., Lockwood, L.: Software for Use: A Practical Guide to theModels and Methods of Usage- Centered Design. Addison Wesley, Reading(1999)

[8] Curtis, B., Kellner, M., Over, J.: Process Modelling. Communications of theACM 35(9), 7590 (1992)

[9] Dardenne, van Lamsweerde, A., Fickas, S.: Goal-directed RequirementsAcquisition. Science of Computer Programming 20, 350 (1993)

[10] Daoudi, F., Nurcan, S.: A Benchmarking Framework for Methods to DesignFlexible Business Process. Software Process Improvement and Practice 12,

5163 (2007)[11] Dobing, B., Parsoms, J.: Understanding the role of use cases in UML: areview and research agenda. Journal of Database Management 11(4), 2836(2000)

[12] Dumas, M., van der Aalst, W., ter Hofstede, A.: Process-Aware InformationSystems. Wiley, Chichester (2005)

[13] Eriksson, H., Penker, M.: Business Modeling with UML: Business Patterns atWork. John Wiley and Sons, Chichester (2000)

[14] Estrada, H., et al.: An Empirical Evaluation if the i* Framework in a Model-Based Software Generation Environment. In: Dubois, E., Pohl, K. (eds.)

CAiSE 2006. LNCS, vol. 4001, Springer, Heidelberg (2006)[15] International Institute of Business Analysis. Business Analysis Body ofKnowledge (online) (2006), http://www.iiba.com

[16] International Organization for Standardization. ISO 9001:2000,http://www.iso.ch

[17] Holtzblatt, K., Beyer, H.: Requirements gathering: the human factor.Communications of the ACM 38(5), 3132 (1995)

[18] Lauesen, S.: Task Descriptions as Functional Requirements. IEEE Software20(2), 5865 (2003)


14/14

[19] Luftman, J., Raymond, R., Brier, T.: Enablers and Inhibitors of Business-ITAlignment. Communications of AIS 1 (1999)

[20] Lukaitis, S., Cybulski, J.: The Role of Stakeholder Understanding in AligningIT with Business Objectives. In: REBNITA 2005, Paris, France (2005)

[21] Marshall, C.: Enterprise Modeling with UML. Addison-Wesley, Reading (2001)[22] Nysetvold, A., Krogstie, J.: Assessing Business Process Modeling LanguagesUsing a Generic Quality Framework. Advanced topics in database research5, 7993 (2006)

[23] OMG. Business Process Modeling Notation (BPMN) Specification (online)(2006), http://www.bpmn.org

[24] OO Method project, http://oomethod.dsic.upv.es[25] Ould, M.: Business Processes: modelling and analysis for re-

engineering and improvement. Wiley, Chichester (1995)[26] Pastor, O., Molina, J.C.: Model-Driven Architecture in Practice: A Software

Production Environment Based on Conceptual Modeling. Springer,Heidelberg (2007)

[27] Reich, B., Benbasat, I.: Factors That Influence the Social Dimension ofAlignment Between Business and Information Technology. MIS Quarterly24(1), 81113 (2000)

[28] Rubens, J.: Business analysis and requirements engineering? The same, onlydifferent? Requirements Engineering 12, 121123 (2007)

[29] Scheer, A.-W.: ARIS - Business Process Frameworks, 3rd edn. Springer,Berlin (1999)

[30] Siau, K.: The Psychology of Information Modeling. Advanced topics in

database research 1, 116118 (2002)[31] Smith, H., Fingar, P.: Business Process Management: The Third Wave.

Meghan-Kiffer Press (2002)[32] Standish Group. Chaos, http://www.standishgorup.com[33] Vessey, I., Coner, S.: Requirements Specification: Learning Object, Process,

and Data Methodologies. Communications of the ACM 37(5), 102113(1994)

[34] WfMC. Workflow Management Coalition: Terminology & Glossary (1999)[35] Wahl, T., Sindre, G.: An Analytical Evaluation of BPMN Using a Semiotic

Quality Framework. Advanced topics in database research 5, 94105 (2006)[36] Wohed, P., et al.: On the suitability of BPMN for Business Process Modelling.

In: Dustdar, S., Fiadeiro, J.L., Sheth, A.P. (eds.) BPM 2006. LNCS, vol. 4102,Springer, Heidelberg (2006)

[37] Yu, E.: Modeling Strategic Relationships for Process Reengineering. PhDThesis, University of Toronto, Canada (1995)

[38] Zave, P., Jackson, M.: Four Dark Corners of Requirements Engineering. ACMTransactions on Software Engineering and Methodology 6(1), 130 (1997)

_bpmn_anali2

Documents