2015 IEEE 17th Conference on Business Informatics
Combining Process Modeling and Requirements Engineering an Experience Report Heli Hiisilä, Mika Kujala Planning and Development Ilmarinen Mutual Pension Insurance Company Helsinki, Finland
[email protected],
[email protected],
[email protected] [email protected] Abstract— Using IT development efforts for achieving new business goals is a challenging task. Optimally, IT projects and solutions should be aligned to answer the real requirements of actual business development targets. Process modeling has been widely applied as a tool for business process and IT development. The goal of this study is to investigate how to combine process modeling and requirements engineering (RE) in software development projects. We studied the use of process modeling focused Business-driven development (BDD) method and other modeling techniques to support complex large projects in the outsourced environment. The results presented here are based on 17 interviews, a study of 4 projects implemented with the BDD method and the experiences gathered from 11 other large projects at the case study organization. This report outlines the results of combining process modeling to use case, business rule and other requirements and architecture modeling. To a large extent, the results w ere positive and indicate the benefits for using business process modeling as a visual tool for combining business and IT development, and as a part of the requirements. However, the perspective and abstraction level for process modeling should be carefully selected. Our study concludes also that requirements modeling should cover different aspects from both project and enterprise context in a comprehensive manner. Keywords— Business-driven development (BDD), process models, requirements engineering (RE), enterprise architecture (EA), use cases, business rules, non-functional requirements
I.
I NTRODUCTION NTRODUCTION
Effective business processes can bring competitive advantage for a company and IT systems are a valuable asset in the information centric processes. IT systems enable process automation, contain valuable business logic and complex business rules, support business specialists as process tools, and enable the storage of the information. The complexity of the IT systems has increased and one business process may utilize several software systems, components, SOA services, and integrations. Furthermore, the amount of stakeholders is often very high as the business process may flow over several organization units, have external or outsourced parts, and can be closely connected connected with with customer’s processes. processes. Process models have been a tool for developing business during the past decades. Processes have been developed from different perspectives, for example optimizing process work, removing waste based on lean principles, developing organization practices to meet quality standards, automating 978-1-4673-7340-1/15 978-1-4673-7340-1/15 $31.00 © 2015 IEEE
work, and developing IT systems. Business process management (BPM) focuses on improving corporate performance by managing and optimizing a company’s business processes [1]. Renewal of the software systems of a complex business process is a major challenge for an organization - IT projects consume company’s resources and are seldom finished in accordance with their original schedule and budget, or deliver the benefits expected. According to a study of large-scale software projects, the average cost overrun is 66%, average schedule overrun is 33%, and average benefit shortfall is 17% [2]. Especially organization with the outsourced IT development may face many challenges. Based on our previous study [3], one of the biggest challenges from the customer organization’s point of view is to develop business and IT as a whole, and requirements can be an important tool when combining the business process, IT system development and enterprise architecture. No real competitive advantage is gained by a new system s ystem implementation if the business processes are not developed as well. Also, a minor improvement of the current state is not enough when targeting strategic business transformation via development. To support large and complex system development projects ahead, Business-driven Development (BDD) [4] [5] method was introduced at the case study organization in 2010. The BDD method was implemented to support business process modeling and IT system development in four major projects. The goal of this study is to investigate how to combine process modeling and requirements engineering (RE) in the software development projects. This study reports lessons learned from utilizing the BDD method in four projects. We also studied how to combine process modeling to other requirements modeling techniques, such as use cases, business rules, and other requirements in a total of 15 large projects implemented implemented at the outsourced environment. environment. The related work to our study is introduced briefly in Section II. We present the research methodology including the description of the case study organization, projects studied and validity evaluation in Section III. Section IV introduces the results of BDD method implementation and combining process modeling to other requirements modeling techniques. The main results of the study are summarized and discussed in Section VI. Finally, we present conclusions and propose some future research directions. 242
A. Case Study Organization
II. R ELATED WORK
The case study organization was an insurance company taking care of statutory pension security in Finland. The company had over 560 employees. Pension insuring is information centric and highly integrated in the business field. The company’s large legacy systems were built in the 1980s and 1990s. These systems became the backbone of the company’s IT infrastructure. Systems were tailor-made based on the business and user needs, and legislation. In the late 1990s IT was recognized as a tool for developing business enabling automation, digitalization, web services, and complex business logic. The amount of technologies and integrations increased and the complexity of the systems expanded. IT system development was outsourced in 2006 and is nowadays provided by external suppliers. Most of the suppliers are well known international software companies. Legacy systems serving pension, insurance processes and financial processes were at the end of the life cycle and largescale development projects were on the way. During the years of system development, part of the knowledge of the organization was built into the systems business logic, process automation, and integrations between the systems. At the prestudy phases of the renewal projects, a major challenge was to collect requirements related to hidden business logic. Renewing monolithic systems brought challenges to project scoping and each business process also utilized a number of integrated software systems. This added complexity to the projects. To improve project outcomes, the Business-driven development method was implemented in 2010.
Process modeling has been a tool for developing processes from different viewpoints: business-to-business processes, human interaction workflows, and system workflows [6] and a large variety of process modeling techniques [7] are available. Process modeling has also been a topic of interest of academic study during the past decades [8]. Business Process Management (BPM) offers concepts, methods, and techniques to support the development of company’s business processes [9]. One of the BPM related methods the Business-driven development method (BDD) [4] combines business process and IT development. The aim of BDD methodology is to develop IT solutions that directly satisfy business requirements and needs [4]. In the BDD, business requirements flow downwards from the business level to the IT level and IT requirements flow upwards to the business level via hierarchical process modeling: business process level analysis models are further defined in system level design models and connected with Service Oriented Architecture (SOA) [5]. Business process focus has also been identified as emerging themes of requirements engineering (RE) by Hansen, et al. [10]. According to a definition of Nuseibeh and Easterbrook [11] requirements engineering (RE) is the process of identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. The number of available requirements modeling techniques, frameworks and tools is high and it is challenging to select the most suitable technique for the project context [3]. In addition to process modeling, the case study organization has applied several requirements modeling techniques, such as UML modeling and use cases, business rules and non-functional requirements. Use cases have been widely used to model interaction between the user and the system [12] and a business rule is a statement that defines or constrains some aspect of the business [13]. Furthermore, in addition to functional requirements, also non-functional requirements are often needed [14] [15]. Glinz [14] points out, that a non-functional requirement is an attribute of or a constraint on a system, and that these attributes may include both performance requirements and specific quality requirements. Also the importance of enterprise architecture (EA) has increased, as the number of technologies and complexity of the solutions has grown rapidly in the case study organization. TOGAF [16] is an Open Group Standard, an enterprise architecture framework that provides a widely accepted and increasingly applied methodology for enterprise architecture development. In the Business Architecture phase of TOGAF the link between the strategy of the enterprise and the required business model is established and the high-level enterprise BPM process models are designed [16]. The case study organization is in the process of establishing a more robust EA practice, but currently there is no holistic framework or method like TOGAF in use.
B. Data Collection and Analysi s Research and interviews were planned with external university researchers to support both the scientific work and development work of the case study or ganization. The research was performed based on interviews, document reviews and validation workshops (Table I). TABLE I. Method Interviews
Project documentation review
Validation workshops
III. R ESEARCH METHODOLOGY
SUMMARY OF DATA COLLECTION METHODS Data collection 17 interviewees were selected based on the organizational and project roles to comprehensively represent different projects, experience of the BDD method and organizational functions responsible for RE and project work. Project documentation, process models and requirements were studied of 15 projects: A) Insurance process automation, B) Pension estimation process C) Pension process renewal D) Insurance process automation, further development F) Financial processes; G-P) 10 other large-scale projects are reference projects between 2006-2014. Three workshops were organized to validate the findings with the interviewees and IT management. During the validation workshops, the author presented the results of the analysis and the participants gave feedback on the results. The validation workshops lasted 2-4 hours.
The interviews were semi-structured and conducted in Finnish. The themes of the interview questions were the following:
In the research methodology section case study organization and projects are introduced, data collection and analysis are reported, and the validity of the study is evaluated.
243
main focus of the project study was in the projects A-D utilizing the BDD method – the use of the process modeling in the projects studied is s ummarized in Table II.
Experiences of implementation of the Business-driven development method How different projects utilized the BDD method to collect • requirements? Experiences of other requirement modeling techniques • utilized in the projects The interviewees included five business developers/specialists, three steering group members of IT development projects, two requirements definition specialists, two process developers, two IT managers, two IT architects, and one project manager. The duration of each individual interview was approximately an hour. All the interviews were recorded and transcribed. In addition to the interviews, process models, requirements documents, project plans and the final reports of the projects were studied. Four projects implemented with the BDD method were studied in greater detail to study method implementation and process modeling. The interview data were analyzed iteratively. The unit of analysis was large IT development projects and the focus of the investigation was to analyze experience of the BDD method, process models, use cases, business rules and other requirements models used. Interview data were analyzed with open-coding content analysis [17]. Large amount of interview data and findings from the project documentation was categorized and analyzed to summarize lessons learned. The first author of the paper was responsible for the analysis of the results. Three workshops were organized to validate the findings with the interviewees and IT management. During the validation workshops, the author presented the results of the interview and project study analysis and the participants gave feedback on the r esults. •
TABLE II. Project Project A Insurance process automation and project D developing Insurance processes further
Project B Pension estimation process
-
Project C Pension process renewal, prestudy
Project E Renewal financial processes
C. BDD method imple mentation and projects stud ied The methodology implemented in the case study organization was based on the one introduced by Mitra [4] and Koehler et al. [5]. Method was implemented as a tool for developing business processes, collect requirements and combine business and IT development. During the implementation of the method in the organization, proof-ofconcept modeling example processes was made, instructions written, modeling tools introduced and trained to practitioners and a knowledge center was introduced to support the projects. The pre-study phase in the method implemented was iterative and process models were hierarchically composed. First development goals and the process hierarchy were defined and project scoped. Then high level business processes (analysis models) were defined. The next level in the hierarchical modeling was to define design processes (system level) in detail including software system services. In addition to process modeling, use cases, business rules and functional and non-functional requirements were defined and current state and to-be environment and architecture modeled. For the project study, we selected large scale development programs or projects based on two selection criteria: 1) program was implemented in the outsourced environment 2) the cost of the implementation > 1M€. These programs covered the strategically important outsourced IT system development projects of the case study company during 2006-2014. The costs of the programs / projects varied from 1M€ to 40M€. The
USE OF PROCESS MODELING IN THE PROJECTS STUDIED
Projects G-P
– of
Use of process modeling in the project Project A was implemented based on the BDD method; however analysis and design models of processes were combined into a single model. Business rules and use cases connected to the process models were defined. Solution was a tailormade implementation into Business Process Management System (BPMS). Project D was further development of project A. Process models, use cases and business rules of project A were updated and redeveloped. Analysis level models were defined based on the method and business rules and business use cases connected to the process models were defined. Also functional and non-functional requirements were defined. Tailor-made implementation into Business Process Management System was planned. However, the project was cancelled during the implementation phase and process was later implemented as a part of project C. Process hierarchy and business processes were modeled. In addition, business rules and functional and non-functional requirements were defined. Pension handling processes included complex business logic and a long sequence of automated and manual phases as well as iterations. Instead of tailored implementation into BPMS, the components of software products were used to build the solution. Requirements were partly redefined later. Process models were used in the early pre-study phase and process hierarchy and the most important business process were modeled to support project work, but the BDD method was not utilized in the project. Also, functional and non-functional requirements were defined. The project included the implementation and integration of several software products and changes to systems. 10 other large scale programs or projects between the years 2006-2014 were studied. At least high level business process models were utilized in 60% of the studied projects. The solutions delivered included tailor-made software implementations, the deliveries and modifications of the software products, changes to current systems, integration work and SAAS services.
D. Validity Evaluation Threats to validity were analyzed based on the framework by Runeson et al. [18]. The authors of the paper are employees of the case study organization, which is both a strength and a possible threat to the validity of the results. Based on the practical experience of the case study organization’s RE process, BDD method implementation and projects studied, the authors have background information and the researchers had full access to all necessary project documentation. As a threat, the researchers' own experience may have affected the interpretation of the results. To avoid construct validity threats, validation workshops where the practitioners of the case study company reviewed the findings iteratively were organized. This study is based on experiences of a single organization and does not give conclusive results of
244
Figure 1. First, the importance of strategic development goals was emphasized by the interviewees. Strategic development goals were needed to steer to-be process modeling and requirements definition, for example expected automation level, customer value and benefits and development costs. In four studied projects, development goals were defined based on the analysis of the process capabilities, which brought the focus into all the assets related to process (IT systems, human resources and knowledge of individuals, process instructions, etc.). Second perspective identified was the organizational approach. Business processes flow over several organizational units and transformation of the business process often required development or organizational capabilities, roles and responsibilities, and sometimes outsourcing decisions. The third perspective identified was the business process approach, including business process workflows, business rules and logic needed. The fourth perspective identified was the system level including descriptions of how the process is performed in the IT systems, services, and integrations including also manual tasks. As-is process modeling was needed to fully understand the current end-to-end processes functionality, software systems used and current state challenges. Both system and business specialists knew deeply parts of the process, but end-to-end process knowledge was rare. Though understanding of current state as-is processes is important, most focus and resources should be spent on to-be modeling. Enterprise process modeling is a comprehensive approach including all processes of the company. If comprehensive current state process modeling exists in the company, development projects may utilize the documentation as a starting point. The process hierarchy was identified as a useful tool for defining the development project scope based on the business processes and establishing common vocabulary between the stakeholders. The process hierarchy was also used in the acceptance testing to set the focus of the testing efforts to end-to-end business processes. Modeling a complex business process comprehensively at different hierarchical levels required extensive effort. High level process models and the process hierarchy were useful from the management point of view in the organizational perspective. Business specialists were interested in business process and business logic mainly from the functional and behavioral perspectives. Specific system level process models were often needed by the technical people from the informational perspective. Most of the practitioners would have preferred a single model for business and system level processes. Business process modeling including process hierarchy and
implementing and utilizing the BDD method or other models used. However, process modeling, use cases and business rules are widely used tools and lessons learned based on practical experience may be useful to other service production organizations. IV. R ESULTS In the results section, lessons learned about the BDD method implementation and experiences of the projects utilizing the method as well as results of combining the use case, business rule and other requirements modeling with process modeling are reported. A. Business-Driven Developm ent Method – Lessons Learned The BDD method gave a solid framework for modeling end-to-end processes and had the business process focus. Actual business process development can be done with the most suitable methodology, for example based on the lean principles. Building the capability of the organization related to the new BDD method - organizations development processes, knowledge of practitioners, assets, use of tools and models, culture related – required more time, resources and change management than expected. Process modeling requires skill and knowledge of best practices. In the outsourced environment, customer organization project team mainly consisted of non-technical business specialists. Design level modeling required architecture skills. All suppliers were not familiar with the BDD method; the supplier implementing the system development should be trained to use the method. Based on the experiences, method was best suited for developing tailored solutions based on the process management system (BPMS). When utilizing a software product (COTS) as a solution, product specific limitations should be considered in to-be process modeling. B. Using Process Modeling to Collect Requirements One of the challenges identified related to process modeling was that there is a large number of process modeling perspectives, abstraction levels, modeling techniques and notations available. Different stakeholders, such as management, business specialists, business developers, IT architects, and supplier’s specialists, had different expectations to process models and previous experience of using different modeling notations and tools. At the beginning of the work, the purpose and abstraction level of modeling should be agreed on. The aim of the process development was to transform the current state (as-is) process to the to-be process – usually strategic, organizational, business process and system level perspectives were developed during the project. Different perspectives of process modeling identified are illustrated in
Fig. 1. Different perspectives of process modeling identified.
245
analysis level process models were considered the valuable tools of business and IT development. Lessons learned about the process modeling are summarized in Table III. TABLE III.
Process hierarchy / process mapping
Development goal setting based on process capabilities
Analysis model / business process model
Design model / system level model
Solution planning and analysis (SOA services, software products etc.)
Modeling tools and round tripping between the models
Modeling process supported several integrated systems
by
PROCESS MODELING – LESSONS LEARNED Lessons learned The process hierarchy was useful in defining the project scope, establishing the common terminology and useful tool of process acceptance testing. Process discovery was time-consuming and the management engagement was needed. The hierarchy was negotiated between the stakeholders as there is no ‘correct’ hierarchy. Some guidance was given by industry reference models, but they did not completely match company’s processes. Strategic development goals were needed to steer to-be process modeling and requirements definition. Development goals were defined based on the analysis of process capabilities, which brought the focus on the assets related to the process. However, process capability was a new and abstract concept and different projects applied the concept at different abstraction levels (the capability of the business / process/ organization / individual). The analysis model was considered useful - focus was improving the end-to-end process instead of sub processes based on organization responsibilities. Innovation and fresh thinking were valued to avoid copying old ways into the new systems. The organizational perspective of process modeling was needed to lean the processes. Design models of projects A and D were used to implement the process into the business process management system. Design level process models were considered useful documentation in the testing, technical planning and implementation and maintenance phase. System level process modeling required cooperation with the system supplier to create common understanding about the solution to-be. Feedback of the IT solutions available is needed to define realistic and affordable to-be processes and requirements. The BDD method support identification of SOA services. However, in the projects implementing software products, integrations, SAAS services etc., solution planning and analysis of how different components support to-be processes was considered essential. Modeling tools enabled hierarchical process descriptions. There were separate tools for analysis (business level) and design models (system level). Round-tripping between the models was considered difficult based on the limitation of the tools. Most of the practitioners would have preferred a single model for business and IT processes. Process modeling tools did not support reviewing requirements fully. In project E, systems supporting financial processes were highly integrated and information flows in the process through several systems. If comprehensive large-scale process modeling is not possible or feasible, defining the process hierarchy and modeling the most important business processes increases common understanding and adds value. Also in the complex integrated environment, process modeling may be a useful tool for modeling how the business process is actually performed at the system level.
C. Combining Process Models, Use Cases and Business Rules Use case modeling was used in several projects in the case study organization and the practitioners were familiar with the method. However, use case diagrams lack the end-to-end process view, which is relevant to get a grasp of the complex business process behind. Use case modeling and business process modeling was combined to receive benefits from both modeling techniques. Business process modeling defines the sequence of automated and manual tasks and provides a comprehensive view of the process. Tasks of the business process were further defined as use cases and business rules. Also in some projects studied, the use case included a whole business process – however, this was not recommended by the practitioners in case of complex business processes. Also business rule modeling was combined to process modeling. Many of the case study organizations business rules were derived from the law or regulation, but also other business-related rules were identified. Rules were defined in a semi-formal manner utilizing natural language and business terms. Each business rule had a unique id and steps for performing the rule were defined. Project A contained a total of 125 rules, which were updated and modified in project D. In project B 35 rules were defined and in project C 135 rules. The abstraction level of business rules and documentation varied in the projects and practitioners understand the term business rule in various ways. In project A, manual tasks were defined by the business rules. In addition to business rules defining system logic, system level specific handling rules were defined in the use cases in projects A and D. Both levels of abstraction of rules were needed. The approach combining process modeling to use cases and business rule modeling is illustrated in a simplified process model of Figure 2. The process model defines the end-to-end business process and each step of the process is further defined as use cases. Business rules are utilized to define the rules related to decisions made during the process execution. Combining three modeling techniques enabled the more comprehensive modeling of business logic.
Fig. 2. Combining process modeling, use cases and business rules.
Lessons learned from combining use cases, business rules and other modeling techniques are summarized in Table IV. Business practitioners preferred detailed use cases and business rules to model both business and system logic required to define the complex logic of automated information centric processes. In addition to process modeling, use cases and business rules, also functional and non-functional requirements were needed to comprehensively define requirements.
246
TABLE IV.
LESSONS LEARNED OF COMBINING THE MODELING
D. Summary of the Modeling Demands Identified
TECHNIQUES
Combining use cases to process models
Business use cases vs. system use cases
Business rules
Reusable business rules
Development goals
Functional requirements
Non-functional requirements
Architecture models and guidelines
User stories
Concepts
Examples
Process modeling was able to capture valuable requirements related to end-to-end business processes. Use case and business rule modeling were then used to define business logic and required functionality. The design level models of the BDD method also capture system level requirements. During the analysis of the results, also other demands for the requirements modeling were identified from the customer organization context - requirements should cover different aspects comprehensively, from both project and enterprise context. From the case study organization point of view, different aspects of the requirements modeling identified are illustrated in Figure 3. Strategy should steer goal setting and transformation of the business. Development goals derived from the company strategy was the first aspect identified – development goals should steer decision related to to-be process modeling, requirements definition and project in general. To achieve strategic goals, business development of service products, processes and organization were the next identified layers. Business logic and functionality were seen as traditional sources for user and system requirements by the interviewees. Master data management and the importance of information modeling were also emphasized to enable maintainable long terms solutions. Also, integration related requirements may have a major impact on business processes, for example enabling the target automation level. The solution to be developed should also fit into the enterprise infrastructure (platforms, other systems etc.). Enterprise architecture both enables and brings limitations to solutions and thus architecture models and guidelines were seen as vital sources of the requirements. Also environmental factors, such as legislation related to the business branch and compliance, may introduce vital requirements. User needs and other stakeholders should not be forgotten, either.
Lessons learned Process tasks were further specified with use cases to define business and system logic – steps, alternatives, handling rules and exceptions. When use cases are modeled based on process tasks, the modeling may not be optimal from UML modeling perspective. However, combining two approaches brought value from the business modeling perspective. In project A and D, use cases defined combined both business and system level aspects. Business specialists preferred detailed system specific use cases over separate high level business use cases. Business level use cases were defined in project B based on analysis level process maps, but deriving system level use cases during the specifications phase with the software supplier was challenging. Business rules were used to define requirements related to business logic. Rules provide understandable documentation for business people and formally define business logic for system development purposes. One business rule may be used in different process phase or use case. Business rules were defined in many projects as a part of use case documentation. If the same rule was utilized in many use cases, separate business rule documentation was utilized. The importance of goals to steer the requirements definition and project work in general was emphasized. The studied projects had initial high level goals. In addition to top-down derived goals from the management, also unwritten goals from different stakeholders can be recognized (derived bottom-up). In addition to automated processes, users use the functionalities of the system manually. Customer service, for example, is often based on performing several tasks – reviewing and updating customer information. In addition to process modeling, functional requirements (‘system shall’ phrases) were used to supplement process models. Process modeling did not cover all non-functional requirements such as reliability, maintainability, security, usability and fault tolerance. Company had a set of frequently needed non-functional requirements to be used as a starting point of project requirements definition. Process modeling may be used to collect requirements, but additional requirements documentation was needed. Process models were seen as a tool for connecting business and architecture development. Architecture guidelines have brought vital requirements related to services, software products, integrations and information. Also enterprise architecture guidelines and enterprise IT infrastructure may bring limitations to solutions. Architecture guidelines were needed in the procurement for the suppliers to deliver comparable bids. User stories were considered as a useful tool for modeling stakeholder requirements. Connecting the user role and benefits expected to the requirements has been useful. User interface concepts and product concepts, for example, have been utilized to develop and visualize business ideas. Examples of specialties of the business area have been useful to make difficult functionalities understandable.
Fig. 3. Development goals and requirements should cover comprehensively different aspects of from both project and enterprise context.
247
To conclude, modeling should comprehensively cover different aspects of the project and enterprise context and appropriate modeling techniques should be selected based on the application domain and available resources (time, skills and knowledge, tools). Combining process modeling, traditional requirements modeling techniques and architecture modeling was considered beneficial by the practitioners and enabled more comprehensive requirements modeling. However, requirements documentation should form a solid understandable entity. If too many modeling techniques were used, documentation scattered. Furthermore, business processes, logic and system functionality and other requirements should be modeled, defined and documented using business terms. V. DISCUSSION This report outlines the results of combining process modeling to other requirements modeling techniques. To a large extent, the results were positive and indicate the benefits to combining these techniques. However, the perspective and abstraction level for process modeling should be carefully selected. Implementation of a new development method , in the organization requires extensive training and support for the practitioners. Building the capability – implementing BDD practices, knowledge of practitioners, assets, use of tools and models, and culture related to RE – required more time, resources and change management than expected. Cultural change, user involvement, training and education and pilot projects were identified as the success factors of RE process development by Kauppinen et al. [19], and similar experiences were reported by the practitioners also in this study. In the outsourced environment, also the supplier organizations should have knowledge of the methods and tools used. Hierarchical process modeling required modeling skills, business and IT knowledge and was time-consuming. Combining different modeling perspectives, functional, behavioral, organizational and informational [8] into a single model turned out to be problematic. Based on the study, hierarchical modeling can be used to alleviate the problem. At the beginning of the modeling work, a common agreement is required on the perspective, use and the abstraction level of the models to be produced. Furthermore, round-tripping between the analysis and design models was considered challenging by the practitioners. Similar findings related to round-tripping between the models have also been identified by Branco et al [20]. Our study also supports the findings of Liskin [21] — a variety of requirements artifact types is often needed to successfully conduct a project – however, using multiple artifacts causes problems like manual translation effort and inconsistencies. The BDD method was used in the case study organization as the main tool for collecting requirements in four projects. In addition to process modeling, other types of modeling of requirements were needed to comprehensively define the requirements set in the studied projects. Combining process modeling to use cases and business rules was seen useful. Also, process modeling does not support the definition of nonfunctional requirements [22], but additional non-functional requirements were needed in the projects studied.
Practices of defining use cases varied in the projects. Discussion of business level and system level use cases reported also in the white paper [23] has caused some confusion. Business specialists preferred si ngle comprehensive documentation containing both business logic and system related requirements to avoid the maintenance of separate documentations. Based on the interviews, use case documentation should be written in natural language utilizing business terminology. Practitioners also preferred the documentation of business rules within the use cases instead of separate business rule documentation, to enhance readability. Process models were a tool for connecting business process development, requirements engineering and architecture development . Enterprise architecture framework TOGAF [16] aims at establishing a connection between the strategic business targets and the state of the actual IT systems and their development within an enterprise. Applying Business Scenarios and Business Process Modeling as critical tools in the Business Architecture Phase of TOGAF emphasizes the approach of process orientation and clarifies the connection between strategic business targets and the state of actual IT systems and their development requirements within an enterprise. All of the disciplines, BPM, RE, and EA, are closely connected, and include valuable viewpoints. The BDD method can be applied in some of the future projects of the case study organization, but not as a standard development method for all projects. The suggested approach based on the experiences was to combine process modeling at the chosen abstraction level to other appropriate requirements and architecture modeling techniques. The case study organization uses outsourcing for all development projects, and most of the practitioners are non-technical business specialists or part-time business developers —modeling techniques should meet the needs of the organization. In case of professional organizations that have skilled resources for modeling tasks, the BDD method may very well be useful as such. To receive most benefits from the process modeling, focus on the business process development with a suitable methodology, such as lean principles, was recommended for future projects during the validation of the results. In addition to process modeling, business modeling focusing on customer value [24] is often needed. Combining process modeling to service design or service blueprinting [25] might be a good combination in the future development projects. VI. CONCLUSIONS Based on the experiences received, we recommend using business process modeling as a visual tool for combining business and IT development. If comprehensive large-scale hierarchical process modeling is not possible or feasible, defining a process hierarchy and modeling a selection of the most important business processes increases common understanding of end-to-end business processes and adds value. Also in the co mplex integrated environment, process modeling may be a useful tool for modeling how the business process is actually performed at the system level. In addition to process modeling, other modeling of the requirements was also needed. The importance of strategic development goals to steer the process modeling and requirements definition was emphasized. Combining process modeling to use cases and collecting
248
business rules related to processes was seen useful by the practitioners. Also non-functional user and system requirements and architecture modeling were needed to complement process modeling. The role of the requirements identified in the study was to define the development goals, scope, content, complexity and development environment to internal stakeholders and software suppliers to steer the project to meet the business goals. Our study concludes, that requirements modeling should cover different aspects from both project and enterprise context in a comprehensive manner. Furthermore, careful consideration is required for selecting the best fitting modeling techniques in the project application domain and based on the project group skills and knowledge.
[4]
[5]
B. Curtis, M. I. Kellner and J. Over, "Process modeling," in Communications of the ACM 35.9, 1992.
[9]
M. Weske, Business Process Management - Concepts, Languages, Achitectures, Springer, 2007.
[14] M. Glinz, "On Non-Functional Requirements," in 15th IEEE International Requirements Engineering Conference, 21-26, 2007. [15] L. Chung and J. C. Sampaio do Prado Leite, "On Non-Functional Requirements in Software Engineering," Chung, Lawrence, and Julio Cesar Sampaio do Prado Leite. "On non-functional requirements in Conceptual modeling: Foundations and applications, pp. 363-379, 2009. [16] The Open Group, "The Open Group Architecture Framework (TOGAF) Version 9.1," The Open Group, 2011. [17] J. Lazar, J. Feng and H. Hochheiser, Research methods in humancomputer interaction, Chichester West Sussex U.K.: Wiley, 2010. [18] P. Runeson, M. Host, A. Rainer and B. Regnell, Case study research in software engineering: Guidelines and examples, John Wiley & Sons, 2012. [19] M. Kauppinen, M. Vartiainen, J. Kontio, S. Kujala and R. Sulonen, "Implementing requirements engineering processses throughout organizations: success factors and challenges," Information and Software Technology, vol. 44, no. 14, pp. 937953, 2004. [20] M. Castelo Branco, Y. Xiong, K. Czarnecki, J. Küster and H. Völzer, "An Empirical Study on Consistency Management of Business and IT Process Models," GSDLAB TECHNICAL REPORT, Waterloo, 2012.
R EFERENCES T. Panagacos, The Ultimate Guide to Business Process Management: Everything You Need to Know and How to Apply It to Your Organization, CreateSpace Independent Publishing Platform, 2012.
H. Hiisilä, M. Kauppinen and S. Kujala, "Challenges of the customer organization's requirements engineering process in the outsourced environment - A case study," in Requirements Engineering: Foundation for Software Quality, pp. 214–229, 2015.
[8]
[13] Business Rules Group, "Defining Business Rules ~ What Are They Really?," 2000.
We would like to thank case study organization management and practitioners for co-operation and support during the study, especially our supervisor Jukka Hirvinen. Also thanks to Aalto university researchers Marjo Kauppinen and Sari Kujala who participated to the research planning.
[3]
R. S. Aguilar-Savén, "Business process modelling: Review and framework," in International Journal of production economics 90.2, pp. 129-149, 2004.
[12] I. Jacobson, G. Booch and J. Rumbaugh, The unified software development process, Addison-Wesley, 1999.
ACKNOWLEDGMENT
McKincey&Company, Business technology office, "Delivering large-scale IT projects on time, on budget, and on value," 2012.
[7]
[11] B. Nuseibeh and S. Easterbrook, "Requirements engineering: a roadmap," in Proceedings of the conference on the future of Software engineering (ICSE'00), pp. 35-46, 2000.
Comprehensive modeling of the requirements is a challenging task. Process modeling combined with use cases and business rules was a good approach, b ut did not cover nonfunctional requirements. The importance of non-functional requirements was emphasized by the interviewees and a need to maintain a set of companywide common non-functional requirements to be used in different projects was recognized. Architecture modeling could be used to alleviate the dilemma of comprehensive modeling from both enterprise and project context. The focus in the case study organization has changed from the internal service production processes to from-customer-tocustomer processes. End-to-end process modeling is one of the tools to develop business, but also service design seems to be an emerging trend. A topic of interest is how to combine effectively service design, business process development and requirements engineering in the d evelopment projects.
[2]
M. Dumas, M. La Rosa, J. Mendling and H. A. Reijers, Fundamentals of Business Process Management, Springer, 2012.
[10] S. Hansen, N. Berente and K. Lyytinen, "Requirements in the 21st Century: Current Practice and Emerging Trends," in Design Requirements Engineering: A Ten-Year Perspective. Design Requirements Workshop, LNBIP., Springer Berlin Heidelberg, pp. 44-87, 2009.
VII. FUTURE WORK
[1]
[6]
[21] O. Liskin, "How Artifacts Support and Impede Requirements Communication," in Requirements Engineering: Foundation for Software Quality, pp. 132-147, 2015. [22] C. J. Pavlovski and J. Zou, "Non-functional Requirements in Business Process Modeling," in Proc. 5th Asia-Pasific Conference on Conceptual Modelling , Wollongong, pp. 103-120, 2008. [23] M. Langlands and C. Edwards, "Business vs. System Use Cases," AgileEA Whitepapers, 2009. [24] J. Gordjin, H. Akkermans and H. Van Vliet, "Business modelling is not process modelling," in Conceptual modeling for e-business and the web, Berlin Heidelberg, 2000.
T. Mitra, "Business-driven development," IBM developer works, http://www.ibm.com/developerworks/library/ws-bdd/index.html, 2005.
[25] J. Ojasalo, "Contrasting theoretical grounds of business process modeling and service blueprinting," in Global Conference of Business and Finance Proceedings, 2012.
J. Koehler, R. Hauser, J. Küster, K. Ryndina, J. Vanhatalo and M. Wahler, "The Role of Visual Modeling and Model Transformations in Business-driven Development," in Proceedings of the Fifth International Workshop on Graph Transformation and Visual Modeling Techniques, pp.1-12, 2006.
249
