Skip to main content
SpringerLink
Log in

Design science in action: developing a modeling technique for eliciting requirements on business process management (BPM) tools

  • Special Section Paper
  • Published:
Software & Systems Modeling Aims and scope Submit manuscript

Abstract

Selecting a suitable business process management (BPM) tool to build a business process support system for a particular business process is difficult. There are a number of BPM tools on the market that are available as systems to install locally and as services in the cloud. These tools are based on different BPM paradigms (e.g., workflow or case management) and provide different capabilities (e.g., enforcement of the control flow, shared spaces, or a collaborative environment). This makes it difficult for an organization to select a tool that would fit the business processes at hand. The paper suggests a solution for this problem. The core of the solution is a modeling technique for business processes for eliciting their requirements for a suitable BPM tool. It produces a high-level, business process model, called a “step-relationship” model that depicts the essential characteristics of a process in a paradigm-independent way. The solution presented in this paper has been developed based on the paradigm of design science research, and the paper discusses the research project from the design science perspective. The solution has been applied in two case studies in order to demonstrate its feasibility.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Subscribe and save

Springer+ Basic
$34.99 /Month
  • Get 10 units per month
  • Download Article/Chapter or eBook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime
Subscribe now

Buy Now

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13

Similar content being viewed by others

Explore related subjects

Discover the latest articles, news and stories from top researchers in related subjects.

Notes

  1. Note that the step-relationship model suggested in this paper has no direct connection to the models used in our BPS systems, and the modeling techniques used in iPB.

  2. The basis for the definitions in this section is a systems-oriented view of business processes presented in [10].

  3. The dichotomy type/instance is accepted in all dialects of the BPM literature. However, different terms can be used to express this dichotomy. For example “process” itself can be used to refer to the type, while case or run is used to denote the instance. Another term that is used to denote the type is process model, which is typical for an operational view. We have chosen to use the terms “type” and “instance” as they suit both our pragmatic and theoretical definition better.

  4. See a similar discussion about work systems in [3].

  5. The simplified software development process from Fig. 1 is used only as an illustration for the concepts being developed in the paper. We are not suggesting and/or arguing for/against any particular method of software system development.

  6. In this paper, we use the term hypothesis in its general meaning: “a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation” (Oxford dictionaries: http://oxforddictionaries.com). Our usage of this term bares no connotation as to how it is used in positivists’ research methods.

  7. This space includes all past, present, and possible future situation, problems, and solutions. Using orthogonal spaces in Fig. 3 is a simplification that is made in order to use relatively simple pictures to illustrate the basic concepts. In reality, the spaces are neither orthogonal, nor do they have a real metric to measure the distance between the points. For details, see [12, 13].

  8. The idea corresponds to Ronald Giere’s consideration of theories being like maps [24].

  9. A shared space is an information space that can be accessed by multiple users, such as a blog, wiki or a personal journal. A process shared space is an information space that supports communication/collaboration of process participants in the frame of a process instance.

  10. This paper is not aimed at evaluating or promoting iPB. A short description of the iPB project is included with the aim of demonstrating the DSR approach used in this research, more exactly to show how the research was initiated by a problem in IbisSoft. For the scope of this paper, it is enough to underline that iPB does not belong to the mainstream paradigm of workflow thinking, which created difficulties for its promotion. This, in turn, gave an impulse for finding a generic solution for this kind of problem. Note also that the process model built in iPB has no resemblance to the one suggested in this paper.

  11. For the time being, IbisSoft has postponed promotion of iPB, using it only as an internal tool. This required us to seek other test cases for the evaluation of our suggestions (see the right-hand side of Fig. 4).

  12. We plan to publish the result of this analysis separately as a part of our continuing work on the solution outlined in this paper.

  13. A more realistic example of software development is presented in Sect. 8.2.

  14. The term capability here is understood as ability to provide support for certain aspect of running business process instances.

  15. Which would satisfy [18] requirement on modeling: “Essentially, all models are wrong, but some are useful,” p. 424.

References

  1. ActionFlow: ActionFlow web site, available (2012–10-01) at: http://www.actionflow.com (2012)

  2. Agile manifesto: Manifesto for Agile Software Development, available (2012–10-01) at: http://agilemanifesto.org/ (2001)

  3. Alter, S.: Work system theory: overview of core concepts, extensions, and challenges for the future. JAIS 14(2), 72–121 (2013)

    Google Scholar 

  4. Anderson, J., Donnellan, B., Hevner, A.R.: Exploring the Relationship between Design Science Research and Innovation: A Case Study of Innovation at Chevron, Communications in Computer and Information Science. Springer, Berlin (2011)

    Google Scholar 

  5. Andersson, T., Bider, I., Svensson, R.: Aligning people to business processes experience report. Softw. Process Improv. Pract. 10(4), 403–413 (2005)

    Article  Google Scholar 

  6. Anttila, J., Jussila, K.: An advanced insight into managing business processes in practice. Total Qual. Manag. Bus. Excell. 24(8), 918–932 (2013)

    Article  Google Scholar 

  7. Appian: Appian cloud BPM, available (2012–10-01) at: http://www.appian.com/bpm-software/cloudbpm.jsp (2012)

  8. Baresi, L., Casati, F., Castano, S., Fugini, M.G., Mirbel, I., Pernici, B.: Workflow design methodology. In: Grefen, P., Pernici, B., Sanchez, G. (eds.) Database Support for Workflow Management: The WIDE Project, pp. 47–94, Kluwer (1999)

  9. Baskerville, R.L., Pries-Heje, J., Venable, J.: Soft Design Science Methodology, DERIST 2009, ACM, pp. 1–11 (2009)

  10. Bider, I., Bellinger, G., Perjons, E.: Modeling an agile enterprise: reconciling systems and process thinking. In: Johannesson, P., Krogstie, J., Opdahl, A. (eds.) The Practice of Enterprise Modelling, IFIP, LNBIP, vol. 92, pp. 238–252, Springer, Berlin (2011a)

  11. Bider, I., Johannesson, P., Schmidt, R.: Experiences of using different communication styles in business process support systems with the shared spaces architecture, Proceedings of CAiSE 2011, LNCS, Vol. 6741, pp. 299–313, Springer, Berlin, (2011b)

  12. Bider, I., Johannesson, P., Perjons, E.: Design science research as movement between individual and generic situation-problem-solution spaces. In: Baskerville, R., De Marco, M., Spagnoletti, P. (eds.) Organizational Systems. An Interdisciplinary Discourse, pp. 35–61. Springer, Berlin (2013a)

    Google Scholar 

  13. Bider, I., Karapantelakis, A., Khadka, N.: Building a high-level process model for soliciting requirements on software tools to support software development: experience report. PoEM 2013 (Short Papers). CEUR 1023, 70–82 (2013)

    Google Scholar 

  14. Bider I., Perjons E., Johannesson P.: In Search of the Holy Grail: Integrating social Software with BPM. Experience Report. LNBIP, No 50, pp 1–13, Springer, Berlin (2010)

  15. Bider, I., Perjons, E.: Evaluating adequacy of business process modeling approaches. Handb. Res. Complex Dyn. Process Manag. Techn. Adapt. Turbul. Environ., IGI, 79–102 (2009)

  16. Bider, I., Perjons E.: Preparing for the Era of Cloud Computing: Towards a Framework for Selecting Business Process Support Services. Enterprise, Business-Process and Information Systems Modeling, LNBIP, No 113, pp. 16–30, Springer, Berlin (2012)

  17. Bider, I., Perjons, E., Riaz Dar, Z.: Using Data-Centric Business Process Modeling for Discovering Requirements for Business Process Support Systems: Experience Report. Enterprise, Business-Process and Information Systems Modeling, LNBIP 147, pp. 63–77, Springer, Berlin (2013c)

  18. Box, G.E.P., Draper, N.R.: Empirical Model Building and Response Surfaces. Wiley, New York (1987)

    MATH  Google Scholar 

  19. BPMN: Business Process Model and Notation website, Object Management Group, available (2012–10-01) at: http://www.bpmn.org/ (2012)

  20. Cohn, D., Hull, R.: Business artifacts: a data-centric approach to modeling business operations and processes. IEEE Data Eng. Bull. 32(3), 3–9 (2009)

    Google Scholar 

  21. Duarte Filho, N. F., Costa, N. P.: A set of requirements for business process management suite (BPMS). In: Advances in Information Systems and Technologies, pp. 487–496, Springer, Berlin (2013)

  22. FIPS: Standard for integration definition for function modeling (IDEF0). National Institute of Standards and Technology (NIST). FIPS publication, p. 183 (1993)

  23. Gilbert, P.: The next decade of BPM. Keynote presentation at BPM 2010 conference, available (2012–10-01) at: http://www.bpm2010.org/wp-content/uploads/2009/08/2010-09-14-Gilbert-BPM-2010-Keynote.pdf (2010)

  24. Giere, R.: Scientific Perspectivism. University of Chicago Press, Chicago (2010)

    Google Scholar 

  25. Hammer, M., Champy, J.: Reengineering the Corporation: A manifesto for Business Revolution, Harper Business, New York (1993)

  26. Hant, V.D.: Process Mapping: How to Reengineer Your Business Processes. Wiley, New York (1996)

    Google Scholar 

  27. Hevner, A.R., March, S.T., Park, J.: Design science in information systems research. MIS Q. 28(1), 75–105 (2004)

    Google Scholar 

  28. iPB: iPB Reference Manual, available (2012–10-01) at: http://docs.ibissoft.se/node/3 (2012)

  29. Khan, R.: Evaluating BPM software. Bus. Integr. J. October issue (2003)

  30. Khomyakov M., Bider, I.: Achieving Workflow Flexibility through Taming the Chaos, OOIS 2000–6th international conference on object oriented information systems, pp. 85–92, Springer, Berlin (2000)

  31. Kleiner, N.: The focus of requirements engineering in workflow application development. CEUR Workshops Proc. 75, 372–377 (2003)

    Google Scholar 

  32. Link, E.: Diffusion Dynamics and Pricing of Innovations. Lund University Press, Lund (1997)

    Google Scholar 

  33. Müller, D., Reichert, M., Herbst, J.: Data-Driven Modeling and Coordination of Large Process Structures. In OTM2007, PartI, LNCS 4803. pp. 131–49, Springer, Berlin (2007)

  34. Neuman, W.L.: Social Research Methods. Qualitative and Quantitative Approaches, Sixth Edition, Peason (2006)

  35. Österle, H., Becker, J., Frank, U., Hess, T., Karagiannis, D., Krcmar, H., Loos, P., Mertens, P., Oberweis, A., Sinz, E.J.: Memorandum on design-oriented information systems research. Eur. J. Inf. Syst. 20(1), 7–10 (2010)

    Article  Google Scholar 

  36. Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S.: A design science research methodology for information systems research. J. Manag. Inf. Syst. 24(3), 45–78 (2007)

    Article  Google Scholar 

  37. Projectplace: Project Place website available (2012–10-01) at: http://www.projectplace.com (2012)

  38. Rogers, E.M.: Diffusion of Innovations. Free Press, New York (1962)

    Google Scholar 

  39. SalesForce: SaleForce website, available (2012–10-01) at: http://www.salesforce.com (2012)

  40. Sein, M.K., Henfridsson, O., Purao, S., Rossi, M., Lindgren, R.: Action design research. MIS Q. 35(1), 37–56 (2011)

    Google Scholar 

  41. SpringCM: Content cloud services, available (2012-10-01) at: https://www.springcm.com/products/springcm-content-cloud-services (2012)

  42. Swenson, K.D. (ed.): Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done. Meghan-Kiffer Press, Tampa (2010)

  43. Van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case handling: a new paradigm for business process support. Data Knowl. Eng. 53(2), 129–162 (2005)

    Article  Google Scholar 

  44. Van der Aalst, W.M.P., Van, Hee K.M.: Workflow Management: Models, Methods and Systems. MIT Press, Cambridge (2002)

    Google Scholar 

  45. Weske, M.: Business Process Management: Concepts, Languages, Architectures. Springer (2007)

  46. Wieringa, R.J.: Design science as nested problem solving. In: Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology, ACM, Philadelphia, pp. 1–12 (2009)

  47. Wohed, P., Andersson, B., Johannesson, P.: Open source workflow systems, Mod. Bus. Process Automa. 401–434 (2010)

Download references

Acknowledgments

The authors are grateful to all members of our team without whose efforts this paper would have never been written. Special thanks to Athanasios Karapantelakis and Nirjal Khadka, who participated in the project aimed at validation of the modeling technique suggested in this project. The authors are also much in debt to the anonymous reviewers whose comments helped us to improve the structure and readability of this paper.

Author information

Authors and Affiliations

  1. DSV, Stockholm University, Forum 100, 16440 , Kista, Stockholm, Sweden

    Ilia Bider & Erik Perjons

  2. IbisSoft AB, Box 19567, 10432 , Stockholm, Sweden

    Ilia Bider

Authors
  1. Ilia Bider
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Erik Perjons
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Ilia Bider.

Additional information

Communicated by Dr. Selmin Nurcan.

Appendices

Appendix 1: Matrices for the course preparation process model

This appendix contains all matrices for the model of the course preparation process described in Sect. 9.1

1.1 Input–output matrix

Input–output

Plan course

Schedule course

Print course material

Teach and learn

Evaluate

Plan course

Schedule course

*Activity sequence

    

Print course material

*Course material

    

Teach and learn

*Working material

*Schedule

Printed course material

  

Evaluate

*Evaluation form

    

1.2 Transitive input–output matrix

Input–output

Plan course

Schedule course

Print course material

Teach and learn

Evaluate

Plan course

     

Schedule course

x

    

Print course material

x

    

Teach and learn

x

x

x

  

Evaluate

x

    

1.3 Parallel execution matrix

Input–output

Plan course

Schedule course

Print course material

Teach and learn

Evaluate

Plan course

 

x

x

x

 

Schedule course

x

 

x

x

 

Print course material

x

x

 

x

 

Teach and learn

x

x

x

  

Evaluate

     

1.4 Parallel dependencies

Input–output

Plan course

Schedule course

Print course material

Teach and learn

Evaluate

Plan course

     

Schedule course

x

    

Print course material

x

    

Teach and learn

x

x

x

  

Evaluate

     

1.5 Weak dependencies

Input–output

Plan course

Schedule course

Print course material

Teach and learn

Evaluate

Plan course

   

Modification of teaching and learning activities Modification of material

 

Schedule course

Size of groups, elapses between activities, etc.

  

modification of schedule

 

Print course material

Feedback on quality of material

    

Teach and learn

Rational for learning and teaching activities

    

Evaluate

Rational for learning and teaching activities

    

1.6 Teams matrix

1.7 Weak dependencies + teams

Appendix 2: Guidelines for brainstorming process properties

This appendix contains a set of questions that could be used in a facilitating workshop with process participants aimed at building a high-level business process model for the process in question. Based on the answers, one can build all matrices introduced in Sect. 5.

  1. 6.

    Identify major step in the process.

Example software engineering, steps Requirements, Design, Coding, Test (See Fig.1)

  1. 7.

    For each step identify the following

    a) Inputs: things that should be provided to the people working in the step so that they can successfully complete their work. Inputs that needs to be present at the very beginning when work starts are marked with asterisk (*)

    b) Outputs: the result expected in this step

    c) Size of the step: team especially whether only one person is engaged in the step or there are more people engaged

Example Requirements

  1. a)

    Inputs: None

  2. b)

    Outputs: Requirements specifications; Test specifications

  3. c)

    Size of the team: more than one person

Example Design

  1. a)

    Inputs: Requirements specifications*

  2. b)

    Outputs: Design Specifications

  3. c)

    Size of the team: more than one person

  1. 8.

    For each pair of steps A and B determine the following

    a) I/O A to B: Outputs from A that serve as inputs for B

    b) I/O B to A: Outputs from B that serve as inputs for A

    c) Parallel execution?: Whether A and B are allowed to run in parallel

    d) Team Intersection?: Not intersect, Intersect, Coincide (are the same)

    e) Weak dependencies A to B: Whether B may require some extra information from A, aside of possible inputs to B that are outputs from A

    f) Weak dependencies B to A: Whether A may require some extra information from B, aside of possible inputs to A that are outputs from B

Example: A = Requirements, B = Design

  1. a)

    I/O A to B: Requirements specifications

  2. b)

    I/O B to A: None

  3. c)

    Parallel execution?: Yes

  4. d)

    Team Intersection?: Intersect

  5. e)

    Weak dependencies A to B: Yes, e.g. explanations on the importance of some requirements

  6. f)

    Weak dependencies B to A: No

Example A = Design, B = Requirements

  1. a)

    I/O A to B: None

  2. b)

    I/O B to A: None

  3. c)

    Parallel execution?: No

  4. d)

    Team Intersection?: Not intersect

  5. e)

    Weak dependencies A to B: No

  6. f)

    Weak dependencies B to A: No

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Bider, I., Perjons, E. Design science in action: developing a modeling technique for eliciting requirements on business process management (BPM) tools. Softw Syst Model 14, 1159–1188 (2015). https://doi.org/10.1007/s10270-014-0412-6

Download citation

  • Received:

  • Revised:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10270-014-0412-6

Keywords

Search

Navigation