JOURNAL OF COMPUTING, VOLUME 4, ISSUE 8, AUGUST 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

59

The cooperation of requirement engineering and business process modeling to elicit requirements
A.Khosravi, N.Modiri
AbstractThe main goal of producing a software application is to support requirements which the software is designed for. As a software supports stakeholders requirements more complete and accurate, it will become more successful and accepted. Detecting business processes and their goals are inseparable part of system development. Organizations endeavor to overcome their rivals by providing distinctive services. To achieve these goals, they identify, optimize and redesign their business processes. The goals of these processes are very important since if organizations dont elicit their goals, they wont be able to implement them appropriately so that their projects will be failed. On the other hand, during modeling and analyzing business processes, we can understand some undiscovered requirements which they had been neglected before process modeling. In this research we will show the cooperation of requirement engineering and business process modeling to elicit system requirements. Index TermsRE, BPM, Requirements elicitation

1 INTRODUCTION
Takeholders satisfaction has been the principal factor for an application to be succeeded or failed. As the IT growing up and organizations utilizing it, necessity of software applications is becoming more understandable. The consistency of application functionality and stakeholders requirements and providing their desired quality is the crucial issue. Regardless of the architecture we use to produce software, detecting business processes and their goals are inseparable part of system development. As the goals of a system and its processes are not detected, it is impossible to supply stakeholders expectations. So the project will be failed. To detect business processes, firstly we should identify the goals and clarify that the processes should supply what requirements. To do so, we can utilize requirement engineering to elicit requirements and then by analyzing them we can identify and resolve the flaws. This flow leads us to a final product which is harmonic with customers requirements. Furthermore, it is possible to face new requirements during business process analyzing and modeling. So that business process modeling has effects on requirements respectively. In this research we will show the cooperation of require

ment engineering and business process modeling and the interactive relation between them. In the first section we introduce business processes in brief. In the next part we will present how requirement engineering can help us to detect business processes and their goals. And finally we will discuss the cooperation of requirement engineering and business processes modeling to elicit system requirements.

2 BUSINESS PROCESS
Generally a process is a chain of activities with the specified begin, end, inputs and outputs. There are several definitions to explain what a business process is. Each of them highlights a specific feature of a business process. According to Hammer and Champy, a business process is a set of activities which takes one kind or more inputs and produce a valuable output for customers, each business process has a specific goal and it is affected by the events occurring in the external world or other business processes. [1] Davenports defined business process as a collection of structured and measurable activities which are designed to produce a specific output for a specific customer. [2] In another definition, a business process is a complete and dynamically coordinated set of activities or related tasks which they must be executed to deliver a value to a customer or to supply other strategic goals. [3] And finally business process is a series or network of val-

Atefeh Khosravi is the MS. Student of software engineering at Izlamic Azad University- Tehran Northern Branch, Tehran,Iran Nasser modiri is a lecturer at Islamic Azad University of Zanjan, Zanjan, Iran

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 8, AUGUST 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

60

ue-added activities, performed by their relevant roles or collaborators to purposefully achieve the common business goal. [2] According to these definitions achieving a goal and being systematic are the common characteristics of a business process. We should consider that there are several actors and roles to perform activities in every business process. It is noticeable that an activity can be performed not only by an individual or a single department, but also it can be the result of the operation of many people, machines or even different systems of different organizations which are cooperating with each other to achieve a common goal. One important success factor for a business process is the fit between business environment and business processes. There is no best way to provide this fit and it is possible that one convenient solution in an organization fails in another organization. The fit between the characteristics of the adopting organization and the standardized business process designs embedded in the adopted system affects the likelihood of implementation success or failure [4, 5]. We should note that applying an experienced and successful case in different times to different organizations necessarily will not be successful so that each organization should identify its conditions, goals and probabilities and align their business processes with them. As a result identifying goals and assuring that business processes goals are based on them is a necessary issue. In the next section we will show how RE (Requirement Engineering) can assist us to elicit goals and business processes.

Requirement engineering discovers, models and specifies and documents these requirements for a system and its domain and then validate them by ask stakeholders confirm. Classic RE has four phases: feasibility study, requirement elicitation and analyze, requirement specification and requirement validation. Generally RE specifies that whether the system is convenient for the desired business and if so it discovers requirements and standardizes them. And finally in validation phase it evaluates that if requirements are according to customers desires. [7, 8]

3.1 Feasibility study

For all new systems the RE process must start from feasibility study. Primary business requirements, system general description and the way that the system is going to support the business are inputs for this phase. The outcome will be a report to make a decision based on, to determine if development of the system would be fair or not.

3.2 Requirements elicitation and analyze

In this phase engineers contact customers and end users to collect some information about system domain, system functionalities, services should be provided, system constraints and etc. Requirements elicitation and analyze may cause involvement of different stockholder with different role.

3.3 Requirement specification

The goal of requirement specification is to achieve a common understanding of requirements. In this phase requirements have to be documented in different levels for usage of different users. For example documents which are used by developers should contain detail of system and technical issues to provide them. However, there is no need to put technical solution in a document used by testers. Requirement documents describe system and it domain. They can be used as criteria for future processes such as system detail design, test cases, validation and verification and change management. Without these documents system developers have no idea about the system. They dont have any source to compare the final result with, so that they dont know whether they are doing a right thing or even a thing in a right way!

3 HOW RE CAN BE HELPFUL TO DETECT BUSINESS

PROCESSES

System requirements are the description of functionalities which it is expected to be supplied. These requirements are customers organization goals and they should be satisfied by the application [6]. We can classify requirements into two main groups: User requirements and system requirements. User requirements should specify functional and nonfunctional requirements; they should be empty of jargons and easy to understand for users. It should define external behavior of system and avoid details of system design. System requirements are developed version of user requirements which can be used as the starting point for designing system. They contain system details and describe how user requirements should be supported. These requirements should be specified accurate and complete, and to decrease ambiguity it is better to describe them by using natural and structured languages which are capable of containing tables and system models.

3.4 Requirement validation

This phase examines that whether supplied functionalities are relevant to customers requirements or not. This phase is a bit overlapped with requirements analyze in the matter that validation phase focuses on discovering problems and conflicts among requirements and checks their compatibility.

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 8, AUGUST 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

61

This phase is very important because when an undiscovered problem becomes detected in developing phases, the cost of its correction will be huge. As we mentioned in previous section, a business process should supply stakeholders goals to become successful. However, specifying goals is very difficult since every project usually has plenty of business processes with many stakeholders having different views.

Fig. 2.How RE assists to detect business processes and goals

Fig. 1.Goal elicitation problems

4
Stakeholders have their personal expectation from the business processes. They often state their expectations generally and they cannot present a precise definition for their goals. Sometimes goals are vague even for stakeholders and they dont know what they should expect from the system exactly. Sometimes it is possible that their goals and expectations are in conflict with each other. On the other hand, environmental difficulties and business domain complexity may make it difficult for analysts to specify and understand the stakeholders goals. In addition analysts lack of knowledge of special domain causes misunderstanding and an obvious matter for stakeholders becomes incomprehensible for analysts. To avoid these sorts of problems and to be assured of understanding business processes correctly, utilizing RE is necessary. In RE process in feasibility study phase, we identify the stakeholders and specify the domain of business, what the main goal is and who the business processes end users are. Then we analyze the environment, facilities and the internal and external factors which may affect the system. If the system is feasible, goal and requirement elicitation will be started. In goal and requirements elicitation phase, we utilize different methods like formal and informal interviews, observations, case studies and scenarios, brain storming, prototyping and etc to identify and extract stakeholders goals and requirements. Then we analyze, classify and prioritize them to recognize the relation between them or even their flaws and conflicts. For goal and requirement elicitation we can use methodologies such as Tropos [9] or frameworks such as NRF [10]. Even it is possible to use the combination of several techniques to specify goals more precisely and through some steps we can extract the goals and requirements more specifically.

THE COOPERATION OF RE AND BPM

In the previous section we showed how RE is useful to specify the goals of a business process. In this part we will demonstrate that how business processes modeling can assist us respectively to specify requirements. It is inevitable that understanding concepts is easier for human by modeling them. By using a model, a person can understand the problem visually and even he can find undiscovered solutions to improve the situation. Business processes are not exempt as well. Modeling the processes existing in a business leads us to identify the problem and its deficiencies more quickly. Furthermore, we can assume the BPM (Business Process Model) as a tool which enables us to optimize the business process by simulating the process and its alternatives. There are loads of advantages of modeling business processes which are not limited to the list below: Increases visibility and understanding of an organizations activities, Provides the ability of recognizing bottlenecks, loops and deadlocks, Provides the ability of recognizing the parts of system which potentially can be optimized, Causes to define actors and their role more conveniently, Depicts overlaps and conflicts more clearly. We can use BPMs as a starting point to specifying system requirements. However, these BPMs are general and abstract (since before applying RE, the goal of them is not clear exactly). Modeled business processes are a set of macro-processes which should be executed according to the organizations strategies in orderly. Then we can decompose these macro-processes into the new macroprocesses.the refinement of macro-processes produces chain of processes that operationalize organizational procedures. [11] Now by using these BPMs, we can elicit the requirements which were neglected in primarily modeling of business

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 8, AUGUST 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

62

processes: According to BPMs, different actors and their roles are specified in processes so that the actors requirements to perform their tasks can be elicited. According to BPMs, the relations between processes become specified. It is possible to emerge some requirements to organize these relations and interactions. According to BPMs, the involved system domains can be recognized and some of them may be not in the organizations domains so that new requirements come forward to supply the activities existing in those domains. In addition sometimes it is necessary to use special protocols for domains interactions and we should consider this requirement as well. According to BPMs and during macro-processes decomposition, emerging new requirements is possible to support the functionality of processes which they had not been considered before. According to BPMs, deadlocks, loops and bottlenecks are clearer so that we can elicit some new requirements to handle them. According to BPMs, we can recognize inconsistent and conflicted processes so that new requirements come out to solve this problem. According to BPMs, weak points and threats can be identified more easily so that new requirements emerge to prevent or resolve them. Determinable requirements from BPMs are not limited to stated items. We should note that sometimes these new requirements need some other prerequisites, or even it is possible that their inconvenient interaction with other specified requirements leads us to support further new requirements. Generally the main goal of RE and BPM is to absorb stakeholders satisfaction by supplying their requirements. To elicit the business processes existed in an organization, at first, we should identify the goal of them. We cannot achieve it but by applying requirement engineering. Requirement engineering specifies stakeholders and identifies and manages their requirements and then according to them we can realize the desired business processes and model them. According to these models some new requirements will be diagnosed which they had not detected before. Sometimes since we are modeling business processes based on elicited requirements, we detect some new events which we need new requirements to handle them. In addition sometimes when we presenting business process models to stakeholders to get their confirmation, we realize that a utilized method to handle a specific events is not applicable according to the organizations constraints, so that we have to replace it with a new solution and it will create new requirements. On the other hand to support these new requirements we again need some business processes which their model potentially is the source of some new requirements. This cyclic cooperation will continue. In each iteration,

requirements help us to detect business processes and the model of these business processes is a tool to elicit neglected requirements. Once we get stakeholders confirm and their satisfaction, we can be assured that we have supplied their requirements so that the final product will be accepted and successful.

Fig. 1. Supplemental role of requirement engineering and business process modeling

CONCLUSION
In this research we emphasized on the cooperation of RE and BPM to elicit system requirements. Generally the main goal of RE and BPM is to absorb stakeholders satisfaction. To elicit the business processes existed in an organization, at first, we should identify the goal of them. We cannot achieve it but by applying requirement engineering. Requirement engineering specifies stakeholders and identifies and manages their requirements and then according to them we can realize the desired business processes and model them. Business process models are easier to understand. According to these models we can detects flaws, conflicts and potentially optimize-able parts of system and their corresponding requirements. Some new requirements also will be diagnosed which they had not detected before. Sometimes since we are modeling business processes based on elicited requirements, we detect some new events which we need new requirements to handle them. On the other hand to support these new requirements we again need some business processes. Modeling them may redirect us to identify new requirements. This cooperation continues until elicited requirements become comprehensive, complete, and accurate and match to stakeholders expectations.

REFERENCES
1. 2. Hammer, M. and Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business, New York, NY, 1993 Ryan K. L. Ko, A computer scientist's introductory guide to business process management (BPM), Crossroads, Vol. 15 Issue 4, Article No. 4, 2009

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 8, AUGUST 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

63

3.

4.

5.

6.

7.

8. 9.

10.

11.

Strnadl, G. F., Aligning Business and It: The Process-Driven Architecture Model, Computer as a Tool, 2005. EUROCON 2005.The International Conference on, Vol.2, pp. 1048-1051, 2005 Peter Trkman, The critical success factors of business process management, International Journal of Information Management, Vol. 30 Issue2, pp.125-134, 2010 Morton. N.A., Hu. Q., Implications of the fit between organizational structure and ERP: A structural contingency theory perspective, International Journal of Information Management, Vol. 28 Issue 5, pp. 391402, 2008 L. Chung, Julio Cesar Sampaio do Prado Leite, On Non-Functional Requirements in Software Engineering, Lecture Notes in Computer Science,Vol. 5600/2009, pp. 363-379, 2009 F.Mejia, J.Tavarez, F.Alvarez, L.Gonzalez, H.Limon, H From Requirements Engineering To Service Oriented Requirement Engineering:An Analysis Of Transition", ICIS, 2009 I.Sommerville, Software Engineering, 8th edition, pp.142 147 Giorgini P, Mylopoulos J, Sebastian R, Goaloriented requirements analysis and reasoning in the Tropos methodology, Engineering Applications of Artificial Intelligence, Vol. 18, pp. 159171, 2005 Chung, L., Nixon, B.A., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. International Series in Software Engineering, vol. 5, pp 476. Springer, Heidelberg, 1999 E.C.S. Cardoso, J.P.A. Almeida, G. Guizzardi , Requirements engineering based on business process models: A case study ,EDOCW 2009, pp. 320-327,2009

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617