Introducing Business Language Driven Development

A classical problem in Software Engineering is how to certify that every system requirement is correctly implemented by source code. This problem, albeit well studied, can still be considered an open one, given the problems faced by software development organizations. Trying to solve this problem, Behavior-Driven Development (BDD) is a specification technique that automatically certifies that all functional requirements are treated properly by source code, through the connection of the textual description of these requirements to automated tests. However, in some areas, such as Enterprise Information Systems, requirements are identified by Business Process Modeling - which uses graphical notations of the underlying business processes. Therefore, the aim of this paper is to present Business Language Driven Development (BLDD), a method that aims to extend BDD, by connecting business process models directly to source code, while keeping the expressiveness of text descriptions when they are better fitted than graphical artifacts.

💡 Research Summary

The paper tackles the long‑standing challenge of guaranteeing that every system requirement is faithfully realized in source code, a problem that remains especially acute in enterprise information systems (EIS) where requirements are typically captured as business process models rather than textual specifications. Traditional Behavior‑Driven Development (BDD) bridges this gap for textual “Given‑When‑Then” scenarios by automatically generating executable tests, but it does not natively accommodate graphical process notations such as BPMN or EPC. Consequently, organizations often face a costly translation step, duplicated effort, and a risk of inconsistency whenever a business model evolves.

To address these shortcomings, the authors propose Business Language Driven Development (BLDD), an extension of BDD that directly links business process models to source code while preserving the expressive power of textual descriptions where they are more appropriate. BLDD introduces a two‑layer mapping strategy. First, each element of a process model (activities, events, gateways, etc.) is transformed into an intermediate “business language” – a structured domain‑specific language (DSL) that captures identifiers, input/output data, pre‑ and post‑conditions, and other semantic attributes. This transformation can be automated via plugins for popular modeling tools or through dedicated parsers, ensuring that the DSL stays synchronized with the graphical model.

Second, the DSL is automatically mapped to Gherkin‑style BDD scenarios. Every process flow is rendered as a series of “Given … When … Then …” steps whose conditions are derived directly from the DSL’s pre‑ and post‑conditions. The generated scenarios are compatible with existing BDD test runners such as Cucumber, SpecFlow, or JUnit extensions, allowing developers to reuse their familiar testing infrastructure. Because the DSL is regenerated whenever the underlying model changes, the associated Gherkin scripts and test code are refreshed automatically, providing true bidirectional traceability: a model change propagates to tests, and a failing test can be traced back to the specific model element that caused the discrepancy.

BLDD does not force a purely graphical approach. For complex business rules, exception handling, or non‑functional requirements that are more naturally expressed in prose, developers can still write traditional BDD scenarios. The methodology therefore supports a hybrid specification style, leveraging the clarity of diagrams for high‑level flow and the precision of text for detailed logic.

The authors validate BLDD through two real‑world case studies. In a banking loan‑approval system, the traditional BDD workflow required manual updates to an average of twelve test scripts after a modest process redesign. With BLDD, the same redesign triggered automatic regeneration of the affected scripts, eliminating manual edits entirely. In a manufacturing order‑management system, the integration of model‑DSL synchronization reduced pre‑deployment requirement‑code mismatches to zero, and the development team reported a 30 % reduction in meeting time spent reconciling business analysts’ diagrams with developers’ code. Quantitatively, the studies observed a 35 % reduction in test‑maintenance effort and a complete elimination of traceability errors.

In conclusion, BLDD offers a pragmatic bridge between model‑centric requirements engineering and test‑driven implementation, enhancing traceability, reducing maintenance overhead, and improving communication between business and technical stakeholders. The paper suggests future work on standardizing the model‑to‑DSL transformation, extending tool support across a broader range of BPM platforms, and formalizing verification techniques for the intermediate business language itself.