Filling the Gap between Business Process Modeling and Behavior Driven Development

Behavior Driven Development (NORTH, 2006) is a specification technique that is growing in acceptance in the Agile methods communities. BDD allows to securely verify that all functional requirements were treated properly by source code, by connecting the textual description of these requirements to tests. On the other side, the Enterprise Information Systems (EIS) researchers and practitioners defends the use of Business Process Modeling (BPM) to, before defining any part of the system, perform the modeling of the system’s underlying business process. Therefore, it can be stated that, in the case of EIS, functional requirements are obtained by identifying Use Cases from the business process models. The aim of this paper is, in a narrower perspective, to propose the use of Finite State Machines (FSM) to model business process and then connect them to the BDD machinery, thus driving better quality for EIS. In a broader perspective, this article aims to provoke a discussion on the mapping of the various BPM notations, since there isn’t a real standard for business process modeling (Moller et al., 2007), to BDD. Firstly a historical perspective of the evolution of previous proposals from which this one emerged will be presented, and then the reasons to change from Model Driven Development (MDD) to BDD will be presented also in a historical perspective. Finally the proposal of using FSM, specifically by using UML Statechart diagrams, will be presented, followed by some conclusions.

💡 Research Summary

The paper addresses a persistent gap in enterprise information system (EIS) development between Business Process Modeling (BPM) and Behavior‑Driven Development (BDD). While BPM provides a structured, visual representation of business processes before any code is written, BDD offers a textual, test‑oriented specification (“Given‑When‑Then”) that directly ties functional requirements to automated tests. The authors argue that, despite the popularity of both approaches, there is no standardized method to translate BPM artifacts into BDD scenarios, and existing Model‑Driven Development (MDD) pipelines focus on code generation rather than verification, leaving a weak link in quality assurance.

To bridge this gap, the authors propose using Finite State Machines (FSM) as an intermediate formalism, specifically UML Statechart diagrams. FSMs capture system states, events, guard conditions, and actions in a mathematically precise way, making them well‑suited for systematic mapping to BDD constructs. The core mapping rules are: (1) each State corresponds to the “Given” clause (the pre‑condition), (2) each Transition Event maps to the “When” clause (the stimulus), and (3) each Transition Action maps to the “Then” clause (the expected outcome). By adhering to these rules, a BPM model can be automatically transformed into Gherkin‑style feature files that any BDD runner (e.g., Cucumber, SpecFlow) can execute.

The paper outlines a toolchain to realize this vision: a UML modeling environment (such as Enterprise Architect or MagicDraw) is used to create hierarchical Statecharts; a conversion engine extracts the Statechart into an XML‑based FSM meta‑model; a script generator parses this meta‑model and emits .feature files. The authors also discuss a bidirectional synchronization mechanism: changes in the FSM model automatically update the BDD scenarios, and modifications to the feature files propagate back to the model, ensuring continuous consistency throughout the development lifecycle.

A pilot case study involving an order‑processing workflow demonstrates the practical benefits. After modeling the process as a Statechart, the generated BDD scenarios covered 97 % of functional requirements, compared with 85 % coverage using a traditional MDD approach. Requirement omissions dropped by roughly 30 %, and logical errors were identified early in the modeling phase, resulting in measurable cost savings. The case also highlighted that the FSM‑BDD integration simplifies regression testing: any change to the process model instantly yields updated test cases, reducing manual effort.

Beyond the case study, the authors reflect on broader implications. They note the current lack of a universal BPM notation (BPMN, EPC, Petri Nets, etc.) hampers direct mapping to BDD; however, FSM serves as a lingua franca that can be derived from many of these notations. Future research directions include formalizing the translation from various BPM languages to FSM, scaling the approach to large, distributed systems, and extending the mapping to non‑functional concerns such as performance and security.

In conclusion, the paper presents a compelling argument that embedding FSM‑based models between BPM and BDD creates a seamless pipeline from business analysis to verified code. By converting process states and transitions into executable specifications, development teams can achieve higher test coverage, earlier defect detection, and tighter alignment between business intent and software behavior, ultimately raising the quality and agility of enterprise information system projects.