Keywords

1 Introduction

Business process models (or shortly process models) represent the organizational processes in an abstract way including at least the activities, control flow between the activities, roles, events and artifacts [1]. Process models are utilized for pure organizational purposes such as process improvement and communication between stakeholders; and for many other practices such as project management, requirements specification, conformance to regulations and knowledge management [2, 3].

We frequently observe in the organizations that process models are not utilized in a systematic manner to develop artifacts of related practices that can benefit from this knowledge. This increases the development effort and makes it hard to achieve completeness for those artifacts, as process analysis is repeated for each artifact. The separate development of artifacts also results in broken traceability between the artifact and business processes. Later, as business process definitions and artifacts are updated separately, they may become unrelated and conflicting; and high amount of effort is spent for maintenance. The problem is more critical if the organization plans to automate its processes by a process-aware information system (PAIS) [4]. In this case, process models are essential for the design of PAIS [5] and many artifacts are developed in software development life cycle (SDLC) based on business process knowledge. Failing to use process models systematically in SDLC means that the knowledge captured in business domain cannot be transferred to technological domain, thus it becomes difficult to meet business needs by the PAIS.

To overcome the problems, we developed a unified BPM methodology, UPROM. UPROM components include notation, process, guidelines and artifact generation principles. UPROM notation and process guide the users to analyze business processes and user requirements in an integrated way [6]. When the methodology is followed, the following artifacts can be generated automatically: user requirements document and COSMIC software functional size estimation [7] for the PAIS, and process documentation including process definition document and business glossary.

UPROM tool is a graphical BPM tool that supports UPROM methodology and automatically generates the mentioned artifacts. Model driven approach is followed based on Eclipse Modeling Framework (EMF) [8] and Eclipse Graphical Modeling Framework (GMF) [9]. Diagram editors are developed as Eclipse plugins. All editors are based on a meta-model. Some plugins were reused from bflow* Toolbox [10], thus inheriting its specific features such as continuous verification.

UPROM tool provides editors for six diagram types in conformance with the notation: Value Chain (VC), Function Tree (FT), Event Driven Process Chain (EPC), Organization Chart (OC), Conceptual Entity Relationship (ER) and Function Allocation (FA). Diagrams represent different business process perspectives which are functional (VC and FT), behavioral (EPC), organizational (OC) and data (ER and FA). The core diagram of the notation is EPC which is known with the ARIS framework [11].

The objective of the UPROM tool is to provide a modeling environment to analyze and model business processes and user requirements in an integrated way. The modeling environment provides editors for six diagram types; together with the features to enrich the diagram objects for analysis, form a coherent modeling project structure and generate artifacts that can be utilized as input to software design and development.

UPROM tool is used by process modelers for analysis of processes in the business domain. End users utilize it to review and validate the models. The tool provides functionality for modelers to integrate business process and user requirements analysis. There are tools that can generate process documentation, but we did not encounter a BPM tool generating also textual user requirements and functional size estimation. UPROM tool was utilized in various projects, including two e-government projects for Company and Trademark Central Registration Systems, Public Investment Analysis of Ministry of Development, Integrated Information System Project of METU Campus and three small internal applications.

In this paper, we present the features particular to UPROM tool to support the methodology and generate the artifacts. In Sect. 2, UPROM methodology is briefly presented. Section 3 describes the tool features and the generation of artifacts. Section 4 provides related work with a brief comparison with other tools. Section 5 provides the conclusion, summarizes the findings from the applications and presents the future work.

2 UPROM Methodology

UPROM methodology aims to integrate the practices of business process analysis and user requirements analysis By unifying analysis activities, a set of models can be developed that embeds all information to generate artifacts related to user requirements, software size estimation and process documentation practices. The methodology includes the notation, meta-model, process, guidelines and artifact generation procedures. The artifacts that can be generated by UPROM methodology are: textual user requirements document, COSMIC software functional size estimation, process definition document and business glossary. As all of these artifacts are based on a single source of model set, completeness and consistency of them are improved, they become traceable to business processes and maintainability is enhanced. More information on UPROM methodology and outputs of case studies can be found in [6, 12]. UPROM process consists of three main activities as shown in Fig. 1.

Fig. 1.
figure 1

UPROM high level process and related outputs

Full size image

2.1 Developing Core BPM Diagrams

This step includes the analysis of business processes by developing core BPM diagrams. Initially, the scope of BPM studies is defined. Then, highest level decomposition of processes is identified as process modules and modeled in a process map (as a VC, FT or EPC diagram). The processes are decomposed further into lower level process modules. Detailed business process analysis is then conducted for process modules. The process shown in Fig. 1 can be conducted in parallel for multiple process modules by different teams in an iterative manner. Alternatively, process modules can be analyzed one by one with a waterfall-like approach.

Functional, behavioral, and organizational perspectives of business processes are analyzed in this step. Process information is elicited through workshops. Available process documents, legislations and laws applicable to the domain are also important sources of information. The modelers depict the decomposition of processes by using VC and FT, and model control flow by means of EPC diagrams. A VC diagram represents high level value added activities to obtain products and services. Other VC or EPC diagrams can be assigned as sub-diagrams for value chain symbols. A FT diagram depicts decomposition of related activities. Functions in FT diagrams can have other FT or EPCs as sub-diagrams. EPC is the core of the notation to analyze the control flow [13]. Another EPC, FT or FA can be assigned to a function; and an EPC or FT diagram can be assigned to a process interface in an EPC diagram. In parallel, all organizational elements placed in EPCs and their relations are modeled in an OC diagram.

2.2 Developing Analysis Diagrams Associated to BPM Diagrams

In this step, each leaf function in EPC diagrams is analyzed to identify if that function is required to be automated in the PAIS to be developed. If so, an FA diagram is created as a sub-diagram of that function. Leaf functions in EPCs are the functions in the lowest level of the hierarchy, which have no further EPC or FT sub-diagram assigned. FA diagram serves the purpose of analyzing user requirements for the related function. An FA diagram is used to analyze the responsibilities to conduct the function, related entities, operations on entities, related applications and constraints. In parallel to FA analysis, entities that are placed on FA diagrams and their relations are modeled in conceptual ER diagram. An ER diagram provides an overview of all entities in the system, together with generalization, aggregation and named relations between them. Further features provided by UPROM tool are described in Sect. 3.

2.3 Generating Artifacts

Upon completion of business process and user requirements analysis steps, artifacts can be generated automatically by using UPROM tool. Artifact generation principles are detailed in Sect. 3. Generated artifacts can be utilized as inputs to subsequent phases of software design and development. User requirements, core business process and analysis models and process documentation are inputs to the detailed requirements analysis, testing and acceptance phases. Functional size estimation is critical for software development planning in early phases. Process definition document and business glossary are used by different stakeholders types in the operation phase of the software.

3 UPROM Tool

UPROM tool provides an integrated environment to develop six different diagram types based on a meta-model. A snapshot of the modeling environment with EPC diagram editor can be seen in Fig. 2. In conformance with the tool’s objectives, the tool features described in the following sections enable users to apply the methodology. The feature described in Sect. 3.1 is on the structure of the modeling project. This feature helps the user to organize core BPM and analysis diagrams in a structured way in the form of a coherent modeling project. Independent of the complexity of the models, the user can understand the process hierarchy. This structure also helps to generate artifacts in a standard form. Feature in Sect. 3.2 forces the users to develop diagrams conforming to the meta-model. Section 3.3 is about defining unique objects. This feature helps to establish conceptual connections between the business process and analysis concepts. The same concepts in the project, independent of being used in business process or requirements analysis, become cohesive. It enables business processes and generated artifacts become consistent and traceable to each other. Section 3.4 is on additional attributes. This feature is used to enrich the diagrams and the objects so that extra information required for detailed business process and user requirements analysis can be trapped all in the same set of models. The extra information is then utilized in artifact generation. Section 3.5 includes artifact generation procedures.

Fig. 2.
figure 2

Typical UPROM tool modeling environment and example project structure

Full size image

3.1 Structure of the Modeling Project

The repository in which the set of diagrams in the same BPM scope is maintained is called modeling project. Within a modeling project, all functional and behavioral diagrams of types VC, EPC and FT must be connected to each other by sub-diagram relations. The folder structure of the modeling project is established in conformance with its sub-diagram decomposition. Each sub-diagram of type VC, EPC or FT shall be placed under a folder with the same location with the higher level diagram this sub-diagram is referenced to. There can be no FA diagrams in the top level hierarchy, as they can only exist as a sub-diagram of a function in an EPC diagram.

UPROM tool checks if the folder structure conforms to the hierarchical structure of the modeling project. An example modeling project structure is shown on the left part of Fig. 2. Only one diagram of type VC, FT or EPC exists at the top level, which is the process map (e.g. Company.ftd). For each sub-diagram referenced from the process map, the sub-diagram file is placed inside a folder. The same rules apply for lower level diagrams. FA diagrams are placed inside the folder of their related EPC. ERD and OC diagrams can be placed anywhere, preferably in the highest level to be easily accessible.

3.2 Diagram Editors and Relation Constraints

UPROM tool editors run in conformance with the meta-model. VC diagram comprises value chain, risk, objective and product objects. FT diagram has only the function object. EPC diagram include event, function, process interface, logical operators (and, or, xor), business rule, application, organizational elements (position, organizational unit, group, internal and external person), information carriers (document, list, log, file, reference), key performance indicator (KPI), risk and improvement objects [14]. OC diagram notation has organizational element objects. FA diagram has organizational elements, function, entity, application and constraint objects. ER diagram covers entity, cluster, attribute, generalization, aggregation and relationship objects. Simplified meta-model of the most distinguishing diagram types of UPROM, EPC and FA, are provided in Fig. 3. Inheritance relations and connection types (control flow, information flow and relation) are not shown. An EPC diagram can contain any number of these objects, but must at least have two events (start and end) and a function. An FA diagram can contain one and only one function, and must have at least one application and entity.

Fig. 3.
figure 3

Simplified UPROM meta-model for EPC (up) and FA (down) diagrams

Full size image

UPROM tool prevents formation of a connection not allowed in the meta-model. Predefined connection names are assigned between some constructs. An organizational element and a function can be connected via a relation named as: “carries out, approves, supports, contributes to, must be informed”. A function can be connected to an entity with a relation named as: “reads, changes, lists, creates, deletes, views, uses”.

3.3 Unique Object Assignment

The objects in the same modeling project are assigned to be unique if they are assigned the same name and they are of the same object type or group. Instances of the same object can exist in any diagram. Objects from these groups can be assigned to be unique:

  • Information carriers, entity, cluster, attribute, key attribute.

  • Function, process interface, value chain.

When a new object is added, if there is already an object with the same name and type (or one of the object group types) in the project, the user is asked if the new object is the same with existing object(s). If the user approves that they are the same, attribute values of the objects are assigned to be the same. When attributes of any instance of the unique object are updated, all other instances also have the updated values. Users can search for the occurrences of unique objects and see the list of instances.

3.4 Process and Object Attributes

A set of attributes representing meta-data of a process can be assigned to each diagram. The meta-data of a process include description, model name, purpose, scope, status and version. All objects have the attributes of name, id, description, incoming and outgoing connections. In addition, some object types have specific attributes. Organizational elements, information carriers, application, entity, cluster, KPI and attribute type objects can be assigned a technical term attribute. Information carriers, entity, cluster, business rule and constraint type objects can have document link attribute. Sub-diagrams can be assigned to function, process interface and value chain objects.

3.5 Generation of Artifacts

Utilizing the information embedded in the modeling project which is developed by using the features explained in the above sections, UPROM tool can be used to automatically generate artifacts. As a characteristic of EMF and GMF libraries; files for six diagram types and related attributes are all saved in a standard XML format by UPROM. The only information used by UPROM to generate the artifacts are the folder structure (to find the diagram files) and the files in XML format. UPROM tool finds the diagram files under the selected project by using the folder structure, parses these XML diagram files to obtain variables for each diagram and object (using dom4j libraries); and generates the artifacts in PDF format using iText library [15].

When a user reads the diagrams by using the tool, she can dynamically navigate through the hierarchy, jump between the diagrams using sub-diagram relations and examine the attributes on will. The problem with the static reports in PDF format is that, the information is provided to the users in a static and non-navigable way. To present a report where the user can still have the feeling of the hierarchy, we arranged the diagrams so that they are initially ordered through the lower levels of the hierarchy, then go back to the upper levels in conformance with the placement of objects in the process models. For all reports except business glossary, the information presented is grouped under headings for functional diagrams (VC, FT or EPC). In all these reports, the placement of the diagram in the hierarchical structure is written in the heading.

When the report is to be prepared using the information only from a single diagram, such as business process models report, generating the related section of the report is easy. But in most of the reports, we need to parse information regarding diagrams in the whole project, and interpret the cross-relations across diagrams. Two examples of this are identification of external applications (on which no entities are created, changed or deleted in any of the FA diagrams) and identification of the processes that triggered an EPC diagram (which requires examining all other EPC diagrams that have the same end event(s) of that EPC’s start event). Such reports are more complex and requires accurate analysis algorithms. However, they add value by providing extra information to the user which cannot be directly observed by reading the diagrams.

Business Process Models Report and Analysis Models Report present pictures of the diagrams in pdf format so that the users can read the diagrams independent of the tool. In business process models report, VC, FT, EPC and OC diagrams in the modeling project are reported. Diagrams are placed under headings with name and address of the related process. FA and ER diagrams are listed in Analysis Models Report. For FA diagrams, model name, address, and the related EPC process are placed as the heading.

User requirements document, functional size estimation report, process definition document and business glossary require detailed generation procedures and formatting. Generation details are explained in the following sections based on example diagrams in Figs. 4 and 5. A partial EPC diagram is depicted in Fig. 4. Figure 5 is the FA diagram for the function named “Identify company director” in this EPC. Complete versions of the artifacts in four different case studies can be seen in [12].

Fig. 4.
figure 4

A partial EPC diagram

Full size image
Fig. 5.
figure 5

An example FA diagram for “Identify company director” function of the above EPC

Full size image

User requirements document, functional size estimation report, process definition document and business glossary require detailed generation principles and formatting. The details for generating these artifacts are explained in the following sections based on example diagrams in Figs. 4 and 5. A partial EPC diagram is depicted in Fig. 4. Figure 5 is the FA diagram for user requirements analysis of the function named “Identify company director” in the EPC. The complete versions of the artifacts generated in four different case studies can be seen in [12].

User Requirements Document: User requirements statements are generated using FA diagrams. Requirements derived from an FA diagram are for the function in focus. A requirement is related to the EPC diagram which carries this function. Each FA diagram is utilized to generate three types of natural language sentences [16]. Example user requirements sentences generated for the FA diagram in Fig. 5 are provided below:

Type 1: Organizational Element – Function:

  • Company Establishment Applicant or Company Responsible shall carry out the operation of identifying company director.

    This requirement type specifies the role(s) to execute the function. The name of the connection type can be selected from: “carries out, approves, supports, contributes to, must be informed”. More than one organizational element can be connected to a function with the same or different connection types. If the connection is labeled with a number as in Fig. 5, either of the organizational elements can conduct the function.

Type 2: Function – Entity – Application:

  • During entering company director, by using id no residence address and personal credentials shall be viewed on Central Civil Registration System; by using eCompany no legal entity id shall be used on eCompany System; company director info shall be created and updated on eCompany Application Module.

    This type of requirement specifies the entities involved and the operations conducted on those entities during the execution of the function, and also the applications related to those entities. The type of operations can be chosen from the list: “uses, views, creates, changes, reads, deletes, lists”. Each operation has a meaning in terms of defining the user requirement for the function [16]. As seen in the example, parts of this sentence are formed for each application on the FA diagram, then joined as a single sentence.

Type 3: Application – Constraint:

  • During entering company director, at least one director shall be assigned.

  • During entering company director, definition of more than one director shall be allowed.

  • During entering company director, director shall not be accepted if she is not a resident of the country.

Constraints to be considered by the applications during the execution of the function are stated in this sentence type. Constraints can include state changes, limitations on attributes of entities, time and other limitations. The formation of this sentence is relatively straightforward, as constraints are already defined in the models in natural language form. Still, constraint object is helpful as analysts are guided to identify the related constraints during their analysis specific to the function.

The textual requirement statements identified according to the algorithms above are placed in a user requirements document. The organization of the statements in the document is important to enhance readability of the document. A new heading is put in the document for each VC, FT and EPC diagram. Requirements formed by all FA diagrams referenced from an EPC are placed under the heading of the related EPC. When there is an EPC sub-diagram in that VC, FT or EPC diagram, a subheading is placed for that EPC diagram and related requirements are placed under that heading. A hierarchical number and a unique ID is assigned to each statement. An excerpt from the generated user requirements document can be seen in Fig. 6. This document includes sample statements from the same EPC in Fig. 4, but this time for the functions of: “Apply for company establishment” and “Select company type”. The details of user requirements analysis and generation in UPROM can be found in [16].

Fig. 6.
figure 6

Excerpt from user requirements document for the example EPC diagram.

Full size image

COSMIC Functional Size Estimation Report: FA diagrams which serve the purpose of user requirements analysis are also utilized to generate an early functional size estimation of the software to be automated. The estimation is based on COSMIC standard [7]. COSMIC method defines the size of a software as the total number of data movements (DM), which is added up to calculate the size in function points (FP). DM types are: Entry, Read, Write, eXit [7]. According to COSMIC method, DMs are identified from software requirements. In this early phase where we do not yet have the software requirements, we utilize the user requirements to establish an early size estimation of the system. For this, we convert operations defined in FA diagrams to DMs, as it is a high level way of expressing data manipulations in the system. Functional size estimation is achieved by, first converting operations to DMs; then applying various rules. In the first step, for each operation, the following conversion is applied to identify DMs:

Following the conversion step, four rules are applied to fine-tune estimated DMs identified for each application in an FA diagram. Then, two rules are further applied by scanning the overall modeling project. At the end, for each FA diagram, total size is identified separately for each module in the diagram that is to be developed to automate the processes. For example, for “Identify company director” diagram (in Fig. 5), there is no FP assigned to “Central Civil Registration System” (shown in Fig. 7-right). This is because it is an external system and is not to be developed as part of the process automation. The details of the rules can be found in [17].

Fig. 7.
figure 7

Excerpts from a functional size estimation report

Full size image

In functional size estimation report, a heading is placed for each EPC diagram numbered in conformance with its hierarchical position as in the user requirements document. For an EPC diagram, each FA diagram referenced from that EPC is placed in a subheading, given a unique ID. DMs for each application in that FA diagram are listed. An excerpt from the functional size estimation report can be seen in Fig. 7. This figure includes the estimated FP values for the functions: “Apply for Company Establishment”, “Determine Free Zone Status”, “Identify Company Director” which are all part of the EPC in Fig. 5, and “Enter Company Communication Info” function which is in another EPC. The total FP size of each application is calculated and provided in the summary section of this report.

Process Definition Document: This document presents natural language definitions of processes in a predefined template format. VC, FT and EPC models are utilized to generate the document conforming to a template. A separate numbered section is generated for each VC, FT and EPC diagram in the project. Those sections are concatenated to form the whole document. Sections of the document for an EPC diagram are as follows:

  • Process Information: Process purpose, scope, status, version, author, description.

  • Process Responsibilities (table): Responsible name, type (e.g. organizational unit, position, etc.) and responsibility types.

  • Inputs (table): Name, type, source (if input is provided by another role), link.

  • Outputs (table): Name, type, target (if outputs are handed to another role), link.

  • Entrance criteria (table): Event, processes that exit with this event, their address.

  • Exit criteria (table): Event, processes that start with this event, their address Activities (listed in the order of vertical placement on the diagram): Responsibilities of that activity, inputs and outputs, application, risks, sub-diagrams/external processes, description, business rules.

  • Business rules: Name, related activity.

  • External processes and sub-processes utilized by the process.

  • KPIs: related activity, information sources used, measurement period, target.

Some fields of the process definition document are filled by using the attributes described in Sect. 3.4. These are all fields under process information heading, link for inputs and outputs and description of activities. Some fields are identified by examining inter-relations between diagrams. For entrance criteria, “other processes that exit with this event” is achieved by scanning all EPC diagrams in the modeling project and identifying other processes that have the same event as the exit event. The same applies for the corresponding field of exit criteria. In this way, the user can, at a glance, obtain cross-process information that she could only achieve by examining the whole project. The excerpt shown in Fig. 8 provides an example for the partial EPC given in Fig. 4.

Fig. 8.
figure 8

Excerpt from process definition document

Full size image

Business Glossary: Business glossary is a supplementary document to ensure common understanding of the terminology used in the processes. This report also requires scanning of the modeling project to find out distinct terms. All definitions in the project are obtained from the models by using technical term attributes of organizational element, information carrier, application, entity, cluster and attribute objects. By means of unique object property, an object has a single definition regardless of the number of its instances. Easy maintenance is also ensured, as the terminology definitions can be updated on any instance of an object. As exemplified in Fig. 9, the report is composed of three parts: organizational, application and general definitions. The ER diagram is utilized to organize general definitions. An aggregate entity is placed at the top of the general organization list, left indented. The components of the aggregate entity are grouped under that item and indented right. Indentation is used in a similar manner for relationships and generalizations. In this way, a business user can get an understanding of the entities in the system and their relations with each other by reading the document.

Fig. 9.
figure 9

Excerpt from business glossary

Full size image

4 Related Work

BPM tools provide a software environment to develop business process model diagrams. They are usually more comprehensive than just a drawing tool. These are named as “suite” providing many other functionalities to the users, including model object databases, model checkers, various modeling techniques, guidance for users, creation of reports, support for customization and process execution environments.

UPROM tool is developed specifically to apply UPROM methodology. Before developing this tool in our research group, we tailored diagrams in ARIS Business Architect [14] to meet meta-model needs and develop scripts to generate the artifacts. Thus, ARIS Business Architect or any other tool which has a tailorable meta-model and produce custom reports can be used to apply UPROM methodology. However, ARIS and similar suites provide abundant notation alternatives. On the contrary, diagram types of UPROM tool are limited and focused on integrated analysis of process models and user requirements as defined by the methodology.

As an alternative to Eclipse, we could also use a modeling language creation tool such as MetaEdit+ [18] to design and use the diagrams based on the meta-model. MetaEdit+ already provides many notations including business process notation. If tailored to include the diagram types of UPROM and generate the artifacts in the same manner, MetaEdit+ environment, instead of Eclipse, can as well be used. Moreover, MetaEdit+ can also be utilized to generate code for the diagrams; which is not a functionality provided and aimed by UPROM tool. However, we preferred an Eclipse based tool as we were able to reuse plugins from the open source bflow* Toolbox. bflow* Toolbox provides EPC and VC diagram editor plugins that are similar to UPROM notation and an integrated environment for multiple diagram editors; together with continuous validation for EPC.

There are other BPM tools with process documentation and glossary functionality such as Signavio [19], Bizagi [20], ARIS and Visual Paradigm [21]. These tools could be used as well, if tailored, to generate similar process documentation. However, although value is observed in generating textual requirements from models, approaches do not exist to generate textual requirements from business process models [22]. We cannot also find any tools to support such approaches. As the measurement procedure for functional size requires too much effort, many researchers worked on automating the measurement from software models, mostly using UML models such as use cases, sequence and class diagrams [17]. But we observe no tool to automate the estimation by using process models. Thus, to our knowledge, there are no tools that can generate textual user requirements and functional software size estimation for process automation together with the process documentation.

5 Conclusion and Future Work

In this paper, we presented a unified BPM tool. UPROM tool is based on EPC for control flow modeling, and supports five other diagram types. It provides an integrated modeling environment for business process and user requirement analysis. Using the diagrams developed, the tool can automatically generate textual user requirements document, software size estimation and process documentation that can be used as input to software design and development phases.

UPROM was used in two e-Government projects (Company and Trademark Central Registration Systems) and Public Investment Processes of Ministry of Development. The first two projects included 3 analysts from the main contractor, 3 analysts from organization and 2 domain experts. These projects aimed to automate the establishment of new companies and trademarks, and manage them through their lifetime. The first phase covered the analysis of processes and user requirements, and preparation of the technical contract to automate the processes. 3 analysts and 70 domain experts were involved in the third project. The scope was the analysis of the development and publishing of the governmental investment programs.

Generated artifacts were used as project deliverables and acceptance is completed by the users [12]. The results collected by observations and interviews revealed that completeness, consistency and maintainability of the generated artifacts were improved. Another case study was conducted in a retrospective manner to compare business process and requirements analysis outputs of the Integrated Information Systems project for our university campus with the ones developed by applying UPROM. Ninety seven percent of the items in the existing documents were covered and 40 % of these items were improved by the artifacts generated by UPROM. A case study set of three internal business applications was conducted to evaluate size measurement estimation capability of the method. The results deviated at most by 5.6 % compared to formal COSMIC measurement results.

We observed various benefits in these projects by applying UPROM [6]. Apart from the benefits achieved by means of the methodology, which is out of scope of this paper, many of the benefits were enabled by the tool. The analysts reported that integrated modeling environment for six diagram types supported them to smoothly move from process to user requirements analysis and transfer the process knowledge to analysis phase. The analysts mostly enjoyed the automated artifact generation. In three of the projects, the analysts needed to develop these artifacts manually if they were not generated. Another important point mentioned was the reduced maintenance effort. The customer required many changes (specifically in the Public Investment Processes). The analysts emphasized the ease of regeneration instead of manual update of documents. The artifacts were traceable to the models. However, the generated statements did not cover all possible requirements. The analysts needed to manually add non-functional and general system requirements to prepare the technical contract (for two projects). Moreover, specifically for process definition document, different templates were required in different projects, so we needed to tailor the code generation.

The users in our projects, being nontechnical, were not confident in analyzing the requirements. However, they mentioned that they were able to understand and review the generated requirements. Process documentation was favored by many domain experts of different backgrounds. Both domain experts and analysts found the business glossary helpful to ensure a common understanding of the concepts. In the organizations, project managers were using subjective methods to estimate the project effort. The availability of an objective estimation without the need of an expert and even an extra effort, was highly appreciated by them.

The artifacts generated by UPROM tool only cover analysis results in the business domain and create an opportunity to transfer this knowledge to the technical domain. Additionally, traceability to the process models is limited only to the artifacts, whereas the big challenge is achieving traceability to the implementation. The project team needs to design necessary methods to directly utilize these artifacts as direct inputs to software requirements analysis, design and development, and complete traceability until implementation. We will work on such methods in the following phases of the mentioned projects.

For future versions, we plan to develop a functionality to enable users design the format and content of the artifacts and add new process documents presenting process information from different perspectives like RACI charts. At the moment, requirements sentences are generated in Turkish and generation of English sentences are planned for future versions. BPM tools supporting EPC notation are rather restricted in number. EPC is commonly accepted as a good notation for analyzing processes with end users. We believe that similar functionality can be achieved for also BPMN and plan to implement the methodology in a similar way also based on BPMN.