ABSTRACT

In recent years, the process orientation requirements engineering field has received significant interest. However, dealing with ordinary users within an enterprise for developing as-is business process is very complex because this requires skills, responsibility, knowledge, and expertise of business processes. This research answers the following questions: 1) how to systematically gather information regarding as-is business process requirements in an informal environment and by non-expert users? and 2) how can an enterprise refine the identified business process with a semantic process model? The primary purpose of this research is to develop a supporting framework that is suitable for the definition of an as-is business process to be deployed within the enterprise environment. Hence, the focus is on gathering requirements to define the as-is business process. This framework concentrates on three significant aspects of this process: development, refinement, and serialization the semantics of the process model. To accomplish this objective, the LORS framework has been proposed, which consists of four phases (List, Order, Refinement, and Serialization). The framework presents a new unique technique to identify the business process, refine the process, and generate the model semantics. This study assumes that a simple and complete framework will help non-expert users define a high-quality as-is process, such that enhance and facilitate the matching process with existing reference models. We present a case study, evaluate the case study relative to specified criteria, and research the limitations and implications discovered from our research. This research concludes that the LORS framework is simple, flexible, visible, interactive, dynamic, and effective.

Keywords:

Business Process Identification/Discovering, Business Process Requirements Engineering, BPMN MIWG, As-Is Business Process Creation, Model Semantics, Model Refinement, LORS Framework

1. Introduction

Recently, there is an increase in the application of requirements engineering to create and design the business process [1] . Moreover, to understand the importance of defining the business process, John Wheeler shows that existing costs expended to understand the business processes (BP) exceed the costs expended on technology deployed to support the enterprise (10% to 15% spent on technology, 30% to 40% spent on understanding BP requirements) [2] . According to [3] , the priority and resources allocated to development of business process methodologies will increase over the next five years. Therefore, current research is increasing to facilitate the discovery and identification of the enterprise business process [4] . When we reference the business processes, we refer to the enterprise utilization of documentation that describes the components of the process models [5] . The business process models are considered to be blueprints of the enterprise processes that capture, in graphical and/or textual media, the form of events, activities, business rules, and documents that describe the information flow and relations between these business entities [6] . Clearly, the enterprise has a requirement for experts with substantial knowledge regarding business processes. Thus, discovery and documentation of the enterprise as-is business process (as-is BP) are the first steps in the consideration of business process management [7] . As a result, the selection of suitable discovery methods, techniques, and process flow will provide aids to assist in the success of defining and modeling the business process [8] . The problem of capturing, describing, representing and refining the business process of an enterprise has always been very important [9] . Likewise, tremendous amounts of time and resources are usually consumed to define and model the business process; these present many challenges to the non-expert users in order to successfully gather business requirements required to create the business process [10] . These challenges include a lack of business process modeling experience, obstacles encountered in capturing the activities flow, the complexity of the business process, difficulty in applying the guidelines associated with requirements gathering, and lack of complete knowledge and awareness of the business process. Also, the development of an as-is BP model requires substantial time and can be too inefficient to provide valuable results [7] . Consequently, this research strongly supports the requirement to develop a new framework to build a business process in an optimal manner that correctly reflects the enterprise reality. Developing a useful as-is BP presents a challenge. The reasons are documented in [11] : 1) most enterprises are still functionally organized and the business processes are not clearly visible, and 2) describing a business process is often a difficult task that requires human interaction, e.g., interviews with employees engaged in the process. Additionally, input from users and stakeholders is very useful regarding their activity and expected behavior within the enterprise [12] . Therefore, it is imperative to find a proper way to identify the business processes that are compatible with the nature of the users and all stakeholders. Considering the aforementioned problems, mainly regarding ambiguity of the definition and description of the business process, the motivation of this research is the need to develop a coherent, structured, and complete framework for the definition of the as-is business process. Additionally, the lack of business process modeling expertise has been cited in several of the above-mentioned works. A primary reason to develop a new framework is the requirement to identify a maximal set of more efficient techniques that provide better solutions for the definition of the as-is BP to be utilized by a population of non-expert users. Specifically with regard to this research, the problem that we attempt to solve is the development of a LORS framework (List, Order, Refinement, and Serialization) that enables the non-expert user in an informal environment to develop the current state of the business process without requiring either modeling experience or development skills. In most cases, the employees of the enterprise are not familiar with the business process modeling techniques and tools [13] . As a result, we introduce the LORS framework to provide important assistance with the acceptance of this new way of depicting enterprise processes. This research work is a subset of a larger research effort and is a continuation of previous work [14] , as shown in Figure 1 (the shadow represents this research work). In this research, we assume that the simple and complete framework helps non-expert users define high-quality as-is business processes such that the quality of the as-is BP models effect on matching process to the relevant ERP reference models. Furthermore, the use of vendor terminology (ontology) helps to syntactically define the business process elements correctly and generate a model for semantic aids that will assist in matching the reference models. Given these assumptions and the above problem statement, this research identified a set of requirements to define the phases of the LORS framework. The requirements of this research are grouped within categories that correspond to the business process identification phases. These are as follows: R1: The solution shall enable the non-expert users to define the as-is business process, R2: The solution shall enable the refinement of the business process according to specified refinement guidelines, styles, methods, and rules, and R3: The solution shall generate the model according to the BPMN

MIWG formats. The purpose of this research is to answer the following questions: i) how will non-expert users systematically gather information regarding the as-is BP in an informal environment? and ii) how can the identified business process be refined in order to derive a semantic process model in compliance with BPMN MIWG? This aspect of the business process requirements engineering has not yet been sufficiently addressed in the literature. Therefore, the primary emphasis of this research is to develop a framework based on results that are relevant to the requirements engineering field and, in particular, the area of business process definition and modeling. This research concentrates on user-centric business process identification and provides the following contributions: a) development of a supporting framework that aids with the creation of an as-is BP under conditions of uncertainty that are characteristic of most enterprise organizational environments, b) definition of a mechanism for the acquisition of the business process elements, and c) extension of the previous mechanisms by allowing the refinement of the identified business process that is based on pre-defined guides, styles, methods, and rules. In addition, we will generate the model semantics from the identified business process defined by the BPMN MIWG formats. The structure of this paper is as follows: Section 2 introduces background and prerequisite data required to develop an as-is business process, and provide the basic concepts such as BP requirements engineering, BP refinement and quality dimensions, BPMN, BPMN MIWG, and model semantics and serialization. In Section 3, we present a review of the related work. The research model is outlined in Section 4. The LORS framework and associated framework meta-model are presented in Sections 5 and 6, respectively. A case study and application using the LORS framework is described in Section 7. The discussion and limitations of the research are discussed in Sections 8 and 9, respectively. Finally, the conclusions to this research and a discussion of future research are presented in Section 10.

2. Background and Preliminaries

This section presents the necessary background to support the theoretical and practical concepts; a short review includes the following aspects: business process, Business process identification/discovering, documentation of the as-is business process, business process requirements engineering, business process modeling, business process model and notation (BPMN), BPMN Model Interchange Working Group (MIWG), model semantics specified by BPMN MIWG serialization, business process modeling techniques and methods/approaches/tools, and business process refinement.

2.1. Business Process

A business process is a set of logically related activities performed to achieve a defined business outcome [15] . A business process can be completely managed within a single enterprise unit or it can be managed by numerous separate enterprises [16] . The main concepts of the business process are: action, process, role, actor, flow, and goal [9] . The three uses of the business process are to initially create the business process, provide business process education, and manage the business process decisions [17] . The architecture of the business process consists of four components: the network of activities, the flow units, the resources, and the information structure [18] . The research in [19] documented that a business process passes through three stages of change: 1) the business process is presented via classical flowcharts, 2) the business process concentrates on information requirements to support the identified business model, and 3) business process management as the business process reaches “steady state”. Consequently, in order to define the business process, knowledge regarding the canonical concepts and architecture is required.

2.2. Business Process Identification/Discovering

The definition of the business process consists of discovering the components of the business enterprise and their interactions, both component-to-component as well as human-to-component. There are six stages that constitute the business process definition process; these are based on a bottom-up approach: identification of the business activities, identification of the human/data flows between activities, specification of the relationships between business activities, evaluation of the relationships, and identification of the coupled activities [20] . According to [21] , the author distinguishes three separate techniques to approach business process discovery: 1) centralized versus distributed approach, 2) top-down versus bottom-up approach, and 3) structured versus free form approach. In the first case, the centralized approach, decisions are made by an analyst meeting, as a team, with multiple Subject Matter Experts (SME). The distributed approach is characterized by the decisions formulated by an analyst after interviewing all Subject Matter Experts (SME) individually, and then combining and merging the input from all interviewees. In case (2), the top-down approach, the analyst begins at the highest level (root node) of abstraction and descends downward toward the terminal node, adding detail at each deeper level within the tree; in contrast, the bottom-up approach begins with no details at a terminal node and appends details as the design ascends upward toward the root. In the structured approach, the SMEs answer predefined questions and aggregate the answers to form the specifications of the business process. Each approach described above has advantages and disadvantages, and the selection of a suitable technique is affected by a number of factors such as types of modelers (experts, non-experts) and environments.

2.3. As-Is Business Process Preparation, Collection, or Documentation

The model that presents the current state at a particular time is referred to as the as-is business process, while the model that reflects future enhancements represents the to-be model [22] [23] . According to [22] , the as-is model reflects the operation level of the enterprise at a current time such that the model consists of two views: the organizational view and the process view. In [13] the author references exhibits of five points that are required to develop the as-is business process: 1) specification of the level of detail, 2) choice of the associated views (organizational view, data view, process view, or function view), 3) assignment of the modeling conventions (general modeling guidelines have to be defined), 4) selection of the source of information (such as organizational manuals, or documentation of the application systems), and 5) development of an identification plan. As a result, all primary requirements identified above must be specified before creating the as-is business process. The as-is BP model can be applied in various circumstances according to [13] : i) specification of the shortcomings and potential improvements of the enterprise, ii) business analysis as a prerequisite to the development of new processes, iii) generation of an overview of the current situation to aid external processes within external entity, iv) use of a checklist to help development of the to-be model, and v) the as-is model can be reused as the main input to the to-be models. In addition, the as-is BP can be used to match software reference models. The primary objectives of developing the as-is BP include: a) improving or redesigning the enterprise [24] [25] [26] , b) enhancing the enterprise integration [27] [28] [29] , c) providing the starting point for development of the architecture of necessary information systems [30] , d) use in the requirements enumeration phase in the development of the information systems [31] , and e) deployment as a knowledge repository of the enterprise [22] .

2.4. Business Process Requirements Engineering

The requirements engineering attraction to develop the business process has gained interest in recent years [32] [33] . This requirement defines the behavior of the required features and functionalities of a system, i.e., they represent the system capabilities, features, and constraints [10] . Likewise, the requirement to create an as-is BP defines the behavior of the process to include the behavior of its features and activities that represent the process functional areas, actors, features, flows, and the business rules. The difference between classical requirements engineering approaches and process-based requirements engineering is documented in [34] . Also, the difference between traditional and business process requirements engineering is presented in [35] . Furthermore, the researchers illustrated that the previous techniques do not provide sufficient information to develop the business process; hence, new techniques must be developed. Furthermore, in order to define the business process, the information from current business procedures and applications must be identified [22] . This research concluded that requirements engineering is considered as an appropriate technique to develop a coherent, complete, and valid business process by using the web-based application, which depends on the LORS framework.

2.5. Development of Business Process

In the early 20th century, the definition of process modeling was initially used for organizational design [36] . A business process model was then considered as a visual representation of the business process. Furthermore, it reflected an abstraction of a business process and provided a perception regarding the various activities that defined this process. The primary conceptual artifacts that represent the business process model are processes, activities, events, roles, rules, etc. [37] . According to [38] , the model describes a set of organized and structured activities with defined inputs and defined outputs. Moreover, design or modeling of the business process is described as the time period during which manual and/or automated workflow descriptions of a process are described and/or developed electronically [16] . Referring to [39] , the fundamental questions that can assist the creation of a business process are provided, e.g., who are the actors or functional areas involved in the enterprise operations?; what are the activities that can be included?; who are the actors who execute the activities?; what are the inputs and outputs of activities?; what are the sequence of activities?; and what are the activities that can be carried out in parallel? For more information and guidelines on how to model business process, the reader should refer to [40] . The workflow model typically contains a collection of concepts that are useful in the description of the business process, its activities, the dependencies among activities, and the requirements that will implement the required activities [41] . From this point of view, the workflow specification consists of an activity structure (control flow), exception handling, and activity duration. The formalized business process model elements are represented in the form of geometric shapes such as circles (events), rectangles (activities), or diamonds (for business rules) [42] . Moreover, process diagrams contain textual information in the form of labels assigned to geometric shapes, or serve as a vehicle to add more descriptions [43] . Also, textual information performs an important role in the interpretation and relationships, as well as to improve the construction of a cognitive model [44] . In this light, the task of modeling the business process consists of adding some elements to the model such as nodes, edges, naming activities, and adding conditions to the edges [45] . According to [22] , three issues that must be accommodated when modeling are: 1) the business process model developed by multiple modelers, residing either internal or external to the enterprise, 2) the unstructured of business process problem domain, and 3) the requirement to identify the detailed phases involved in the modeling process. Additionally, business process modeling evolved through three stages beginning with the use of flowcharting, mapping, and process modeling [46] . Some considerations have been presented in [47] , when formulating the business process model. They are: i) the end users must understand the abstraction of the model, ii) the model must be structured, iii) the rules of modeling must be clear, and iv) the use of patterns is helpful in the modeling. Consistent with [8] , previous studies of the business process modeling can be classified into: a) distinguish various stages of the process modeling with tools and techniques, b) management of the deployment of existing techniques for the business process, and c) comparison of various tools of the business process modeling. Consequently, in order to model the business process correctly, it must include all issues that are identified above by the researchers.

2.6. Business Process Model and Notation (BPMN)

The international standard for process modeling is called the Business Process Model and Notation (BPMN), and was developed by the Object Management Group (OMG) [48] . The BPMN is the de-facto standard for the graphical representation of the enterprise [4] . The core elements of BPMN related to the design of the business process specification involve events, tasks, gateways and sequence flows [49] . In addition, the BPMN is emerging from the Business Process Management Initiative (BPMI). The BPMN process model consists of four basic element: Flow Objects (events, activities, and gateways), that connect the Objects (Sequence Flow), Swim lanes, and Artifacts [50] . The primary goal of BPMN is to afford a notation that is easily recognizable by business and IT users, including the business analysts who design the processes and the IT developers who are responsible for implementing BPMN [51] . BPMN version 2.0 provides a diagram definition model and a meta-model that is capable of interchanging XMI and XSD formats. Therefore, due to the widespread usability of BPMN, this research focused on the process model elements and the model semantics of BPMN MIWG.

2.7. BPMN Model Interchange Working Group (MIWG)

The main problem of the previous modeling languages like BPMN is the lack of formal semantics which causes the absence of a clear definition of the notation and heterogeneous with other modeling notation [49] . The enhancement offered to BPMN includes a native model serialization that makes it fully independent from other languages, such as XML Process Definition Language (XPDL) and Web Services Business Process Execution Language (WS-BPEL) [4] . Previously, the BPMN 1.0 and 1.1 versions did not provide any direct mapping between BP diagrams and an XML representation of the BP model. Rather, a partial mapping between BPMN and WS-BPEL is provided, which is insufficient for creating a formal semantics [52] . Since January 2013, the Object Management Group (OMG) has focused on an important issue represented by model semantics and interchange of models between the tools. In this case, the OMG established a new group called the BPMN Model Interchange Working Group (BPMN MIWG) to provide support for an exchange of models between different tools. The primary goal of this group is to support and guide vendors in creating compliant BPMN tools, identify issues in the BPMN specification, and facilitate model interchange [53] . Currently, The BPMN MIWG is working on enhancing the model interchange feature by importing, refining, and exporting some models from several vendor tools [53] . There are two types of business processes in BPMN 2.0, the first is a process model (model semantics) that contains the semantics, while the second is a process diagram which presents the visual representation. Moreover, there are two XML formats for BPMN processes: 1) XML Schema Definition (XSD) and 2) XML Metadata Interchange (XMI). However, XSD-based is the more popular format [53] . Additionally, there are three relevant aspects specific to the interchange formats: i) meta-model, ii) serialization (serial representation), and iii) mappings between a meta-model and serialization [54] . Consequently, this research concentrated on the BPMN XSD serialization format which means that the fourth phase within the LORS framework generates a model semantics based on BPMN MIWG serialization.

2.8. Business Process Refinement (Quality Dimensions)

This section provides a background of business process refinement and quality dimensions. The task of validating the model as to whether it correctly reflects reality is very difficult and sophisticated, primarily because it depends on discussions with stakeholders which means that it is dependent on other validation mechanisms [55] . Different frameworks and guidelines have been developed that define quality aspects in the context of process models. Moreover, the validation of the business process elements is based on the XML of the process model created using XPDL or XML in BPMN [4] . Therefore, the validation of the model’s robustness must be conducted during the refinement phase of the creation of the as-is BP. In research documented in [56] , the authors present seven process modeling guidelines (7PMG) that focus on modeling practice and present a set of instructions on how to build a process model as well as providing guidelines to enhance existing process models. Moreover, the six principles that are presented in the guidelines address correctness, clarity, relevance, comparability, economic efficiency, and systematic design. There are several frameworks and guidelines developed to define the quality aspects of the business process such as the semiotic framework for model quality (SEQUAL) [57] , Guidelines of Modeling (GoM) [58] , Seven Process Modeling Guidelines (7PMG) [56] , and other studies that focus on metrics to assess the business process quality. The SIQ Framework is a process quality model based on three dimensions of quality [59] : 1) syntactic quality: this guarantees successful compiles of a business process constrained by modeling technique rules; therefore, the modeling language syntax and vocabulary play an important role, 2) semantic quality: this ensures that the process models will reflect true statements regarding the real world, and 3) pragmatic quality: this assures that the business process models are comprehensible.

The quality and general diagram criteria of the business process representation are presented in [60] . The publication, BPMN Method & Style, authored by B. Silver, documents the BPMN modeling techniques [61] . However, the quality of business process modeling is often neglected [62] . Thus, before generating the business process models, the verification work must provide correct semantics of the models and verify them formally. As a result, in order to develop a new complete framework for the development of the business process, the framework must concentrate on three important aspects beginning with quality dimension, evolution criteria, and pitfalls of the business process.

3. Related Work

The definition of the as-is BP has generated substantial research efforts and this research has produced a variety of different frameworks and approaches. In the following, the related works discussed fall into the context of this research. The studies include defining, identifying, and discovering the as-is BP within the enterprise. Many researchers studied the business process model from a variety of directions; the compendium of this work provides a complete picture of the enterprise’s procedures [32] [33] [63] . Other prominent approaches to business process modeling procedures are presented in [64] [65] , which address the procedures to gather the requirements to build a model. Several ideas regarding the acquisition of requirements to develop a business process are mentioned in the articles [66] [67] . In addition, several articles have stated that requirements engineering is appropriate to build the business process models; refer to [64] [65] .

The research in [20] presents a brief review of the definition of the business process based on a bottom-up approach, conducted over five stages: 1) defining the activities of business, 2) determining the information flows between business activities, 3) applying the appropriate technique to quantify the relationships between business activities, 4) evaluating the relationships between coupled activities, and 5) identifying the coupled activities to develop the mode of the business process. However, the primary focus of the researchers is the relationship between the coupled activities within the enterprise and their interactions. In other research [68] , the author has proposed a pragmatic framework called (CAP) that consists of three iterative phases: Capture, Analysis and Presentation, all of which are mostly concerned with capturing and understanding processes without prescribing particular notations. However, the different notations may be used within each CAP phase.

An approach to develop a process model deployed a user-centric approach to identify modeling requirements is documented in [69] . This approach concentrates on the acquisition of the formal components of the model taken from a natural language document provided by experts or users. The authors argue that the conventional methods of object oriented analysis and conceptual modeling are insufficient to support requirements acquisition and validation by the end-user. In article [9] , a formal framework to support enterprise and business process modeling has been presented, based on the situation calculus (a knowledge representation formalism used in artificial intelligence). This process applies the logic programming language, ConGolog [70] . The framework relies on concepts such as objectives and goals, roles and actors, actions and processes, and responsibilities and constraints. In addition, the work is dependent on results from the i* framework that confirm the need for intentional concepts in enterprise modeling. However, the use of complex mathematical notation presents difficulties for the end users and special skills are required in the case of the situation calculus and ConGolog.

Other research [71] [72] [73] has presented significant procedures that assist in the acquisition of information about a process by using scenarios in the context of business process design. The approach of requirements engineering that concentrates on the visualization of requirements has been presented by [74] . Moreover, the end-to-end business process approach proposed by [75] is dependent on this scenario approach. Furthermore, in article [35] , the authors presented an approach referred to as business process-driven requirements engineering that supports the acquisition of software requirements to assist the operations of an enterprise and ensure business/IT alignment. The approach relies on the mapping of business process goals into system goals that support the high-level goals (goal modeling, goal tree). In paper [8] , the author discusses the problems of business process modeling and the techniques that were used for modeling and investigates the use of various techniques to find a better solution. The author also divided the business process modeling techniques into diagrammatic and tabular techniques.

The [76] study proposed an approach for business process based requirements engineering called [vem:xi:]. They used the Business Process Modeling Notation (BPMN) that provides the description of end-to-end flow activities that cross business units. However, they focus more on the generation of Service Oriented Architecture (SOA) artifacts based on the requirements engineering phase. Further, the integration of the requirements engineering approach within the modeling of the business process and workflows is presented in [77] . However, this work does not extend to include the modeling of customers within the formal definition; it also does not adequately address the explicit management of knowledge within an enterprise. The [78] study developed a collaborative business process modeling approach that supports the end-users that is based on a humanistic approach, a more user-centric approach. However, the developed approach places primary emphasis on knowledge representation and visual composition rather than defining the business process model.

In the [79] research, the authors presented a method for business process modeling referred to as the Task-Based Modeling method (TBM). They focused on management tasks and depend on selecting predefined tasks that are reusable. A methodology to implement enterprise process modeling that applies the concepts of enterprise process evolution has been presented in [80] . The authors discussed a zero-time enterprise modeling technique by using a components assembly technique, a set of concepts, and schema used in dynamic enterprise process modeling. However, this work relies mainly on an agent-based enterprise that requires support from the existing IT organization.

In other research [81] , the authors have used a methodology called Tabular Application Development (TAD). This methodology consists of six phases: the first three phases deal with business process identification, modeling, improvement, object model development, design, and implementation. The methodology used four tables that describe the enterprise functionality by describing business processes, work processes, procedures, and activities. The [82] study suggested an approach to formal business process modeling within an informal environment with more focus on the early design phases. They concentrated on gathering requirements of a business process based on business scenarios. Their approach is divided into five phases: elicitation, formalization, validation, integration, and verification. Also, in the paper [83] , the authors offered an approach to develop an as-is process model based on worker descriptions by using a control flow perspective. There are three stages of this approach: data collection, data extraction, and modeling and analysis with assistance from a questionnaire. However, no evaluation of the proposed work is presented. In fact, the three previous works are considered as closer to this research. There is different research that is interested in defining the business process models through experiments and combinations. The [42] study conducted experiments with 89 students (novices designers) and found that the hybrid design that combines text labels with abstract graphics is suitable for the design of the business process. In the article [84] , the researchers merged techniques from the fields of 1) business process engineering and 2) requirements engineering, and defined BORE: a Business-Oriented approach to Requirements Elicitation.

Although many studies have been conducted on the topic of building an as-is BP model, only a small amount of research that is focused on the early phases of building the as-is BP can be located. Moreover, most of this research is still insufficient due to problems and drawbacks. These problems include: 1) does not provide detailed descriptions of the techniques, approaches, and frameworks, 2) does not provide a clear illustration of the hierarchy of different layers in the frameworks, 3) rarely provides systematic approaches to identify acquisition of the information necessary to develop a process model, 4) absence of comprehensive methods in the literature dealing with the early stages of creating a valid business process model, 5) the frameworks are unclear and unnecessarily complex, 6) most of the methods are manual and error-prone, and 7) there is no study reported in the literature that clearly discusses the model serialization. In general, the difference of all other frameworks and approaches are summarized by the assertion that only the LORS framework concentrates on the definition of the as-is BP model by gathering all relevant information in an informal environment and from non-expert users through the web-based LORS application. Further, the proposed framework in this research is created from the perspective that the enterprise has a number of business processes. These business processes are executed by functional areas or actors within the enterprise. Each business process is included within a set of activities. A set of activities has a business rule and workflow to define its status. In addition, a set of activities is activated and de-activated by specific events. This research attempts to provide a flexible, visible, coherent, complete, and dynamic framework that assists non-expert users within the enterprise to build an as-is business process.

4. Research Model

This research is carried out to assist enterprises with the creation of the as-is BP to be used by non-expert users. The research model consists of six steps as follow: 1) conducting a literature review by searching the web sources such as scientific databases, i.e., Web knowledge, Scopus, to gain a general understanding of the definition of the as-is business process, business processes principals, BPMN, BPMN MIWG, model refinement, and model semantics or serialization. The keywords used during this research were “identified/discover/define/create as-is business process, business processes identification, business process modeling”, and “as-is BP frameworks, business process refinement, business process serialization”, 2) understanding the as-is BP techniques, methodologies, frameworks, and business process modeling principles, 3) exploring the business process components such as functional areas, activities, events, business rules, and work flow, 4) investigating the vendors’ terminology (i.e. SAP ERP vendors), 5) reviewing the model refinement guidelines, rules, styles, methods, and frameworks related to refining the business process quality dimensions, 6) studying the BPMN serialization based on BPMN MIWG (XML serialization), and 7) developing the framework that assists non-expert users to identify and build an as-is business process. Further, in this research, the definition of related literature is based on the three criteria proposed by [85] and [86] . These criteria include: i) Defining the domain area, as mentioned above, ii) defining the as-is BP within the domain under investigation, iii) Defining the sources of the relevant literature. The sources used in this paper were the scientific databases provided by Springer, Elsevier, IEEE, ACM, and most of the related journals that exist in the web of knowledge and Scopus, and iv) Defining the search strategy and the search terms. The process of refinement is conducted by using specialized terms. The research model is shown in Figure 2.

5. A LORS (List, Order, Refinement, Serialization) Framework

According to the American Heritage Dictionary of the English Language, the

framework itself can be defined as “A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed; An external work platform; a scaffold; A fundamental structure, as for a written work; A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality”. The objective of providing a structured framework for the definition of the as-is BP is that the detailed stages involved in the development process can be identified. This research concentrates on defining, formalizing, refining, and generating the semantics of the as-is BP for enterprises that do not have a business process model and cannot create one automatically from instance information systems, e.g. a Relational database. Furthermore, this research assumes that the LORS framework can be supported by non-expert users to develop a complete, coherent, and correct as-is business process. Before providing details regarding the LORS framework, it is necessary to provide a formal definition of a business process. In this research, the business process is defined as a set that consists of functional areas (FA), activities (AC), workflow (WF), business rules (BR), business rule states (BRS), and events (EV). The business process is a set that has the following elements (FAs, WF, BRs, BRS, EVs). The LORS framework phases are illustrated in Figure 3; more details about each phase and its steps are described below.

The task to build an as-is BP requires the formality of a model and a domain specification. Through the formalization, the users create the model with respect to a syntax that reflects a given domain specification [87] , such as ERP domain (SAP terminology). Using a LORS framework enables the non-expert user to define the current status of the enterprise in an interactive and user-friendly fashion. Furthermore, LORS refines the defined process and automatically generates the model semantics (XML) based on BPMN MIWG; this is more compact and more powerful and closer to the BPMN specifications. The proposed LORS

framework consists of four phases: List, Order, Refinement, and Serialization (LORS); with an Add optional phase to instruct the user regarding the interface to the LORS framework, called “Preparation Phase”. The prototype forms of the web based application that implements the LORS framework layers includes interface elements which enable the user to list all process elements such as functional areas, activities, business rules, states, and events; this includes the possibility of building the relationships between elements through pre-defined lists. Therefore, to prepare the complete, correct, clear requirements for the definition of the as-is BP model, the LORS framework classification of the information is collected through the LORS phases and stored in the tables of the database. The following section describes the phases (steps) of the LORS framework in more detail. Notice that the user can save partial state information, and return to any phase or step in the LORS framework to add, delete, or update any elements; this capability is common for “ease of use” web interfaces.

1) Preparation Phase (Optional): In this phase, the users learn the interface to the LORS framework phases through a video. Probably the most efficient technique for understanding the details of business processes and their connections is apprenticing [84] . The first phase assists the user to acquire the knowledge to interface with each phase, e.g., how to list the functional areas (business units), actors, activities, events, and business rules states; also how to order the workflow. The first phase is considered optional.

Deliverable of the Preparation Phase: After the preparation phase, the user will be familiar with the LORS phase and have sufficient knowledge that will allow him/her to create the as-is BP model.

2) List Phase (Manual): The second phase deals with listing all business process elements such as functional areas, actors in functional areas, activities, business rules with state, and events. To achieve this, the phase is partitioned into four steps to list the different elements of the business process. The primary concentration in the List phase is on gathering information regarding the as-is business process. The main challenge is to combine the information collected from users in an informal environment into a valid database that is refined with the collected data. The following subtitles illustrate the steps in the List phase. In addition, the vendors’ terminology (ontology) is used to provide a label of the business process elements in all steps.

i) List the Functional Areas: The user interacts with the web application interface and is able to list all functional areas within the enterprise. The term ‘‘functional area” involves the business unit and the actors within the enterprise. The actors represent the entity in the enterprise and can be a human actor such as an employee or an automated actor such as a machine [9] . The functional area description includes the name of the FA, and the type of the FA (business unit, or actor).

ii) List the Activities in each FA: This activity is carried out in an enterprise as an organizational role; and the output includes a collection of responsibilities and actions executed by a business unit or an actor within an enterprise. To define a business process, all activities must be identified at the level of each functional area within the enterprise [8] . The characteristics of the activity are type, functional area, time, rule, input/output, and cost [81] . An activity is automated when it is executed within the system without human intervention, while an activity is non-automated if there is a requirement that a user interact with the system to perform the process. In this step, the user lists all activities of each functional area; this produces the activity characteristics such as activity name, and activity type (manual, semi-automated, automated).

iii) List the Business Rules with States in each FA: The business rules are a collection of one or more conditions and a set of one or more actions (states). Each business rule is an expression, which results in a value of true, false or null (unknown) [38] . Furthermore, business rules represent specific policies, practices, standards, regulations, and guidelines that define how business units or actors in the enterprise carry out business and are therefore considered to be user-perspective requirements [77] . According to [88] , business rules are classified into two categories: structural and operative rules. The structural rules define how a business activity is organized while the operative rules define how the activity is carried out. Additionally, different types of conditions and constraints occur in business processes [83] . There are three types of the conditions: pre-conditions, post-conditions, and other conditions that occur during execution. The Pre-condition must be evaluated as TRUE before the functional code is executed while the post-condition is evaluated at the conclusion of the functional code. Other conditions include logical, event occurrence, timer expiration, and stochastic events. In the notation tools, gateways are constructs for the execution flow of the process and can be one of the following: 1) AND gateway (for creating concurrent execution flows), 2) XOR gateway (to select one of a number of mutually exclusive flows), and 3) OR gateway (to select any number of flows from the set of all outgoing flows) [49] . In this step, the state must be entered after each business rule through entered the outgoing flow of business rule. For the sake of simplicity, consider this simple example of a business rule that implements the “IS CAPACITY AVAILABLE?” rule via an “OR gateway”. The business rule states supports three outputs: i) capacity available, ii) capacity not available, and iii) capacity partially available Thus there are three outgoing flows from the “OR gateway”. In this step, the user lists all business rules (conditions) for each functional area with the following information: business rules label, business rules type (And, Or, XOR), business rules states (outputs of conditions), business rules position (pre-conditions, post-conditions, and other conditions). The “IS CAPACITY AVAILABLE?” rule will be included in the list.

iv) List the events in each FA: Events can be used to signal the start (start event), intermediate event, or end (end event) of a process. The role of the user in this step is listing the events in each functional area. The list event step includes the event label (if one exists) and type (start, intermediate, and end event).

v) Vendor Terminology in the List phase (Automated): This step focuses on user inputs (dynamic typing) that are based on vendor terminology such as SAP terms in reference models. The field of ontology describes the existence of objects in the world and how they are related [89] . Ontology can play a role in improving the quality of the creation of the as-is BP models. Indeed, gathering information often leads to the following specific problems: the information contains redundancies and repetitions, homonyms and synonyms, exceptional cases to be handled, and implicit information or confusion or inconsistencies between the schema and instance levels [82] . Often when we define the as-is business process, there are several types of documents to be considered, such as working instructions, already existing process models, intra-net information or even theses regarding parts of the process. Consequently, use of these conventions and standard terms can help in consolidating and reinforcing the enterprise as-is models [13] . Further, ontology is a formal conceptual model of a real world domain, which represents the semantics underlying that domain. This level of semantic accuracy is recognized as useful (or even essential) to provide the basis for the production of generalized and reusable models of organizational behavior [89] . Also, the benefits of ontology-based terminology used within the business process model include improved model distribution, integration and interoperability, and model matching [90] . Therefore, in this research, the vendor terminology (such as: SAP terms) is used and the link between the LORS forms and the vendor dictionary is established to define consistent labels for functional areas, activities, business rules, events, and other objects used to build the as-is business process.

Deliverable of the List Phase: A list of functional areas (business units, and actors), a list of activities in each FA, a list of business rules with states in each FA, a list of events in each FA, with respect to the vendor’s terms.

3) Order/Workflow Phase (manual): The Order phase is used to represent the relationship between any two or more elements within a process that were entered previously by users during the List phase. A workflow can be defined as a set of activities organized to achieve some business process [41] . There are three types of workflow that are used: sequence, message, and association. The structured information gathered in the List phase can be translated to an appropriate formal representation. Moreover, in order to develop the workflow of the as-is business process, the sequence flow of those elements must be established through interactive dialog defined in the LORS framework (before, after lists). In this phase, there are five steps that address the workflow of business process elements required to build the basic structures; these are: 1) order the functional areas, 2) order the activities, 3) order the business rules, 4) order the events, and 5) link the different functional areas. The type of workflow can be specified by the user but must be defined as one of the five basic structures. Furthermore, according to the LORS framework, a unique identifier for each element is automatically generated according to its sequence within the functional areas; thus the workflow is dependent on element identifiers (incoming, or outgoing).

i) Order the Functional Areas: In this step, all functional areas are arranged and the numbers that reflect the order of the functional areas are enumerated (i.e. list contains 1, 2, 3, 4, 5; means five functional areas). The user selects the number that corresponds to the functional area arrangement.

ii) Order the Activities in each FA: In this step, the arrangement of each activity in a functional area is established. The output is similar to that of 3.1 such that each activity appears in an enumeration list, and the user selects the suitable value that corresponds to the flow of activity in the functional area.

iii) Order the Business Rules with States in each FA: The LORS Framework presents the frame of each functional area with a list of the business rules (contains: business rule label, BR type, BR position, and BR states) that were previously specified. The user selects the appropriate arrangement of all business rules from the BRs enumeration list of each functional area. This creates an ordered list of the Business Rules. According to the type (AND, OR, XOR) and position (pre-condition, post-condition, another condition) of the business rules, the corresponding lists (before, or after list) appear in the frame. Associated with each business rule are two lists (before list, and after list) which contain the activities and events that were previously specified for each functional area. The user simply selects a suitable element from the list (before, or after list) that corresponds to the workflow of the business rules in the functional area. This process iterates until all business rules within all functional areas are ordered. Notice that the activation of the order list (before, or after list) depends on the business rule position (post-c, pre-c, or other-c). When the business rule position is a post-condition, the “before list” is activated, while the “after list” is activated when the position is a pre-condition. Naturally, the two lists (before, and after list) are activated when the business rule position type is other-condition. Furthermore, the outgoing flow of each business rule state flows to either activity, business rule, or event. To illustrate this processing, assume a business rule called “Is capacity available?” with three states (capacity available, capacity not available, and capacity partially available), so each state flows out to either the activity, business rule, or event. Therefore, the user selects the outgoing flow for each state and the flow is linked to the corresponding activity, business rule, or event in the functional area.

iv) Order the Events in each FA: In this step, the tuple of events that was previously specified appears to users with event information (event label, event type), and the order list (before, or after list) that contains the other elements appears also. Notice that the activation of the lists (before, or after list) depends on the event type, e.g., when the event type is a start event, the “after list” is activated, while the “before list” is activated when the event type is end event. Again, the two lists (before, and after list) are activated when the event type is intermediate event. Simply, the user selects the suitable element from the order lists (before, after list) according to the workflow of the event in the functional area. Usually, the order list identifies (and contains) the other elements in the functional area.

v) Link between different FAs: This step concentrates on linking the different functional areas that have been entered and ordered in the previous phases. The task performed by the user in this step is to create the link between the functional areas through the elements. The interactive list that appears to the users consists of: outgoing from FA (automated same functional area), type of outgoing element in FA (AC, BR, or EV), select specific outgoing element, incoming FA list, type of incoming element (AC, BR, or EV), select incoming element, and type of workflow. Notice that the activation element lists depends on the type of outgoing/incoming element. When the user selects the activity as a type of outgoing element, the activity list is activated while the other lists are disabled. This process iterates until the different functional areas are linked together (if there is a link). The link between different functional areas can support multiple links, i.e., there are multiple outgoing/ingoing flows between the functional areas.

Deliverable of the Order Phase: Arrangement of the functional areas (business units, and actors), an arrangement of activities in each FA, arrangement of business rules in each FA, arrangement of events in each FA, with respect to refinement rules that are imposed on each element.

4) Refinement Phase (Automated): This section describes a method that the LORS Framework relies upon to improve and verify the consistency, correctness, and completeness of the as-is business process. Regarding the business process refinement, this phase refers to the ability to precisely depict all essential elements of a business process in the context of functional areas, activities, business rules with states, and events that compose a business process in the correct way [6] . Moreover, the primary goal of this phase is to eliminate mistakes that originate from invalid inputs during the List or Order phases when creating the as-is model. The refinement process is automated and enforces rules on the elements of the business process. There are four rules (business rules requirements) that are imposed in the refinement process: FA rules, AC rules, BR rules, and EV rules. These rules depend on the known frameworks, guidelines, styles, and methods that are presented in the literature review.

In the aforementioned literature review, several frameworks, guidelines, methods and styles have been developed to ensure the quality and refinement aspects of business process models. The validation of business process elements is mostly based on the XML serialization of the business process model (i.e., the BPMN process model) created using XPDL or XML in MIWG [4] . Therefore, in this research, the refinement of the business process refers to user inputs and the business process serialization. Moreover, the refinement phase depends on the following frameworks and guidelines that were explained previously in the literature: the SEQUAL framework [57] , Guidelines of Modeling (GoM) [58] , Seven Process Modeling Guidelines (7PMG) [56] , the SIQ Framework [59] , the BPMN Method & Style [61] , and the formal verification of the models [91] . In addition, this research includes the 22 pitfalls presented in the [46] article, and the potential problems of the as-is BP model that were presented in the framework documented in [55] . In this research, the following validation and refinement techniques were used to find and correct the missing information in the List and Order Phases: examining the user inputs and any refinements of the elements, check of the model serialization, and application of the refinement rules to the user inputs. There is a matrix in the LORS framework that supports the refinement process; it consists of the following: 1) List Phase Refinement (LPR): (FAs List Refinement (FALR), Activities List Refinement (ACLR), Business Rules List Refinement (BRLR), and Event List Refinement (EVLR), 2) Order Phase Refinement (OPR): (FAs Ord. Refinement (FAOR), FA Ord. Refinement (FAOR), Activities Order Refinement (ACOR), Business Rules Order Refinement (BROR), Event Ord. Refinement (EVOR), and Workflow Order Refinement (WFOR)), and 3) Serialization Phase Refinement (SPR): (FAs Serialization Refinement (FASR), Activities Serial. Refinement (ACSR), Business Rules Serialization Refinement (BRSR), Event Serialization Refinement (EVSR), and Workflow Serialization Refinement (WFSR).

Deliverable of the Refinement Phase: a valid as-is BP that refines the as-is BP elements (refine the functional areas, refine the activities, refine the business rules, and refine the events).

5) Serialization Phase (Automated): The business process creates serialized business process elements and property values that are inserted into an XML stream to generate the model semantics. There are two XML-based formats: the XML Metadata Interchange (XMI) and the XML Schema Definitions (XSDs), but the serialization is based on XML Schema Definitions (XSDs) [53] . There are also two types of definitions: model definitions and graphical definitions. The model definition describes the elements of the business process and their relations; while the graphical definitions describe the visualization aspects [53] . There are two dimensions that need to be considered during a business process serialization: the semantics of the meta-model elements when different representations are used, and the terms that describe the model elements [92] . Further, the benefits of the business process semantic are enhancing the validation, use in model matching, and reuse of the model. There are four automated steps in this phase: 1) extracting the element information such as id, name, and other attributes that were previously specified by the user, 2) constructing the model semantics serialization based on the elements workflow entered by the user in compliance with the BPMN MIWG semantics of the meta-model elements, 3) mapping the elements entered by the user to the BPMN IMWG meta-model elements, and 4) generating the model semantics.

Deliverable of the Refinement Phase: Generate the model semantics using the XML file based on the BPMN MIWG format.

6. A LORS Framework Meta-Model

In order to develop a new framework to define a business process, a thorough analysis of existing meta-models is important. The meta-model encapsulates the formalization of modeling concepts and their relationships [93] . In addition, in order to describe the high-level syntax of a modeling framework/tool, it must be described by meta-classes, meta-associations, and cardinality constraints. Moreover, the meta-models of the business process allow capturing three important aspects of the business process such as informational, functional, and behavioral aspects [94] . For instance, the BPMN meta-model contains 151 meta- classes and 200 meta-associations. Moreover, there are several modeling approaches that are described by meta-models such as the Quality-Oriented Business Process Meta-Model (QOBPM), the Business Process Model and Notation (BPMN) Meta-model, and the Transactional Meta-Model for Business Process (TMBP). A comparative study of business process meta-models is presented in [94] , and the researchers concluded that most of the meta-models do not support practice modeling. In [95] , the researchers created a meta-model that is used to illustrate the modeling frameworks, approaches and tools for a specific domain. Several techniques are sufficiently developed to create meta-models such as UML Class diagrams, ER-diagrams, graphs, and XML schema. The design criteria that are necessary to develop a meta-model with an interchange format are completeness, simplicity, unambiguity, generality, and extensibility [96] . The LORS framework is illustrated in Figure 4 with consideration of the previous meta-models and the design criteria that is defined to develop a meta-model.

7. Case Study and Application

In this research study, a simple process was used as a case study to explain the LORS framework phases discussed above. The case study is an enterprise

application that executes a purchasing process for materials that are defined by three functional areas: warehouse, purchasing, and the accounting functional area. Major process activities include: “create purchase requisition”, “create purchase order”, and “verify and payment”. To illustrate the scenario, the warehouse department sends the purchase requisition to a purchasing department to create the purchase order containing the details (quantity, sizes, and other specifications). Subsequently, the purchasing department sends the order to an accounting department to create the invoice to allow the buyer to make the payment. After receiving the payment, the purchase order is closed. At this point, the warehouse receives the order. In the warehouse functional area, the source of supply is determined, including all specifications of the order and a suitable vendor is identified. Based on the purchase order from the purchasing functional area, the accounting functional area verifies the invoice and sends payment to the supplier. Materials are received by the warehouse functional area and in this way the business processes are completed.

In this case study, the as-is BP is called “purchase material” and was easily developed by the employee. The employee who participated in this activity interacts with a prototype of the web-based LORS application to complete the text boxes (required information) as shown in Table 1. All phases and steps of the LORS framework, including specific details have been applied and the final deliverables (process model and model semantics) are shown. Due to the limitations of space, it is not possible to present all details of the case study here (see Table 1). In comparison with the conventional process approaches for building an as-is model, the benefits of applying the LORS framework include: 1) development of a valid as-is BP model performed by non-expert users with no modeling skills, and 2) the ease of use in the development and refinement of the process and the generation of the model semantics. This research is part of a larger research effort that specifies the areas of change within the enterprise when implemented with the Commercial Off-The-Shelf (COTS) IT. Consequently, generating the valid as-is model semantics can help in the model matching process when comparing the reference model with an as-is model. The specification of the enterprise areas of change is more efficient and cost effective.

8. Discussion and Evaluation

This section describes the deliverables generated by the application of the LORS framework as described in the case study illustrated previously. The development of the as-is BP called “Purchase Materials” was performed, and the explanation of all deliverables to each phase within the LORS framework was provided. Three functional areas (Warehouse, Purchasing, and Accounting) were easily defined, and the activities, business rules, and events of each functional area were entered by the user during the List phase, consistent with the use of vendor terminology. To arrange the elements that entered the List phase, simple interfaces are presented that enable the user to build the workflow between the different elements of the functional areas, and also create the links between the different

functional areas through the simple lists (before, after lists) using the interactive screens. Further, refinement of the developed business process was conducted automatically in parallel with the first two phases (List, and Order phase) using the predefined guides, styles, and methods. Generating the model semantics represented by the BPMN MIWG formats was illustrated in the case study. We conclude that the LORS framework is characterized by simplicity, flexibility, visibility, and dynamics.

There are several criteria that provide the basis for evaluation of the framework such as: the rigor imposed by the framework, the simplicity of the framework, the complexity in the application of the framework, ease of use, and managerial implications [41] . Moreover, in [97] , the authors present a framework called Quality-based Modeling Evaluation (Q-ME) that assesses the business process modeling quality through a set of quality attributes. Analysis of the business process modeling frameworks/approaches includes an evaluation of the strengths and weaknesses, relative to adaptability, expression support, dynamism, flexibility, and complexity considerations [98] . Indeed, there is a large amount of research to investigate the evaluation criteria applied to the framework/approach of the as-is BP identification as mentioned in references [99] [100] . The criteria used in the evaluation of the business process discovery framework are presented in Table 2.

In evaluating this results of this research, we apply the evaluation criteria specified previously and conclude that the LORS framework offers a complete solution to the problem of creating an as-is BP by non-expert users within an informal environment. The basis for this conclusion is:

1) Simplicity: The LORS framework is simple to use by any employee within the enterprise. It enables the non-expert user to define the functional areas, activities, business rules, workflow, and also create links between the different functional areas within the process. In addition, the user develops the as-is process without the expertise and background required to perform formal business process modeling and associated extraction tasks. In addition, interaction with the LORS framework excludes ambiguous steps and does not require the users to possess modeling skills. Moreover, the LORS framework preparation phase provides a user-friendly interface that allows users to easily build the current status process models via the LORS framework.

2) Flexibility: The framework is flexible as it allows the non-expert user to define a business process through interaction with the LORS application in two easy phases (List, and Order phase). Additionally, the framework supports automated phases to refine the as-is BP and generate the model semantics. This is accomplished by using the set of guidelines, methods, and styles that were

mentioned previously in the Refinement and Serialization phase.

3) Visibility: The visibility of the LORS framework is enhanced via support for many functional areas, activities, and business rules. Support to view workflows is excellent, because the framework presents the workflows in the form of well-arranged tables; this is an example of the first guideline in the 7PMG, “use as few elements in the model as possible”. Moreover, the LORS framework phases and steps are easily comprehended and easily managed. Therefore, the visibility of the LORS framework that contains many process elements exceeds that of other frameworks. This is because the entire extracted business process is presented in well-arranged tables within the application interface, and workflow of the process elements is clear and it is easy to track the paths between process elements.

4) User involvement (Interactive): Developing the as-is BP requires interaction between enterprise employees and the LORS application and this will involve the users. They will be actively involved in the first two manual phases within the LORS framework (List, Order phase) as these are considered to be the core tasks. The user involvement requires interaction with the actors, business units, activities, business rules, and workflow within the enterprise to properly create the as-is business process.

5) Dynamism: The LORS framework is a dynamic system that can automatically refine all elements when a business process is defined. Dynamic typing of objects is supported that is based on vendor terminology. Additionally, the framework provides support to build and generate the model semantics.

9. Limitations and Implications of the Research

This research effort has limitations and we present them here. Indeed, there are three types of process models: process model, choreography model, and collaboration model. In this research, the LORS framework is restricted to the internal as-is BP that consists of three categories of elements used in the process model such as flow objects (events, activities, and gateways), connecting objects (sequence flow, message flow, and association), and functional areas; other types are outside the scope of this study. During the serialization phase, the model semantic that is created is based on the XSD BPMN MIWG format, but the format is not fully implemented by most tool vendors and this creates interoperability problems. Moreover, the business process diagram (visual representation) is not addressed in this research because it is not important in model matching (just model semantics). The research does not compare the LORS frameworks with other frameworks as this effort is also beyond the scope of this research. The LORS framework has been evaluated relative to the criteria related to the business process framework and by the case study. This research has significant implications for future research and provides valuable insights into the discovery and development of the business process model without the requirement to apply a formal modeling tool; this is the cornerstone for further studies in the field of business process discovery and modeling.

10. Conclusion

Various frameworks and approaches have been proposed to assist in the definition of an as-is business process. Each of these addresses some of the problems; some focus on the precision while others focus on completeness, consistency, and refinement. This research has studied a method to improve the traditional practice of development of an as-is BP in an informal environment for use by non-expert users. The contributions of this research are 1) the LORS framework, designed to discover and develop an as-is business process, 2) providing a mechanism to refine the business process model based on refinement guidelines, styles, methods, rules, and frameworks, and 3) generating the model semantics and representation using the BPMN MIWG formats. In this research, we introduced the LORS framework to focus on a business process requirements engineering solution. The framework presented helps to overcome a set of limitations characteristic of traditional frameworks, and simplifies the discovery and development of an as-is BP so that it is easily adopted by non-expert employees within the enterprise. We provided an overview of the LORS framework and identified the four phases (List, Order, Refinement, and Serialization) supported by LORS. We also presented a high-level overview of BPMN elements, BPMN MIWG, and the business process with attention to the serialization based on the MIWG format used to generate the model semantics. The case study, framework evaluation criteria, and research limitations and implications were discussed. The framework evaluation process indicates that the LORS framework is simple, flexible, visible, interactive, and dynamic. The follow-on research and development work will address the limitations that were previously mentioned. We plan to investigate the following areas: i) improvement of the proposed framework with more attention on the refinement phase, ii) identification of the relationship between elements, and iii) extending the framework to include other perspectives such as semantic model matching.

Cite this paper

Al-Sabri, H. and Al-Mashari, M. (2017) Process-Oriented Re- quirements Engineering: User-Centric LORS Framework. Journal of Software Engineering and Applications, 10, 95-127. https://doi.org/10.4236/jsea.2017.102006

References