6 What is formulation?
Formulation is the collaborative act of turning a team’s shared understanding of expected system behavior into a business-readable specification. The chapter emphasizes that this is not just about writing down requirements in plain language, but about using clear, unambiguous terms rooted in the business domain so that everyone involved means the same thing when they read the documentation. That shared language is essential because without it, teams risk translation errors, misunderstandings, and inconsistent assumptions that weaken both collaboration and the software itself.
The chapter also explains that formulation is useful because it can serve two purposes at once: documenting behavior and enabling automated verification. It surveys several documentation styles and tools that support this idea, from tabular systems like FIT and FitNesse to developer-centric tools and, most importantly in the book, Gherkin. Gherkin provides a simple structured language for feature files, using keywords such as Feature, Rule, Scenario, and step words like Given, When, Then. This makes scenarios readable for business stakeholders while still being machine-readable enough to connect documentation directly to automation.
A major theme is that when formulation is paired with automation, documentation becomes living documentation. As scenarios are executed, they reveal when implementation and specification have drifted apart, whether because the code changed, the documentation is outdated, or a defect exists. The chapter also distinguishes between scenario types and granularity: most scenarios should be small, illustrative examples that focus on a single rule, while a smaller number of longer journey scenarios can show end-to-end business flow. Together, these practices help teams keep specifications accurate, useful, and aligned with real system behavior.
BDD practices
Summary
- We need a ubiquitous language to arrive at an unambiguous, shared understanding of the domain
- There is more than one format that can be used to formulate requirements as documentation that can be automated
- The most popular target format is Gherkin, which is simple and multi-lingual
- The presence of Gherkin does not necessarily indicate that a behavior-driven approach to development has been followed
- Documentation that automatically verifies itself against the system it documents is called living documentation
- Documentation should include both illustrative and journey scenarios – and these should have different assertion styles
FAQ
What is formulation in BDD?
Formulation is the process of turning a shared understanding of how a system should behave into a business-readable specification. It usually results in text that looks close to natural language, but it still needs careful wording to be clear and useful.
Why is formulation considered simple but not easy?
Formulation is simple because the output often resembles ordinary language. It is not easy because the team must be precise, unambiguous, and consistent so that everyone interprets the specification the same way.
What is the main purpose of formulation?
The primary purpose of formulation is to document a shared understanding of the system’s expected behavior using unambiguous terms rooted in the business domain.
Who should be involved in formulation?
Formulation should be a collaborative activity involving representatives from both business and delivery. Without that collaboration, there is no confidence that the language used means the same thing to all stakeholders.
Why should formulation use business-domain language?
Using business-domain language helps the team describe behavior in terms that stakeholders understand. The terminology should match the domain being documented, such as orders and deliveries in a pizza app, or matrices and normalization in a mathematical library.
What is a Ubiquitous Language and how does it relate to formulation?
A Ubiquitous Language is a shared language structured around the business domain and used by all team members. It reduces translation effort, lowers the risk of misunderstanding, and supports clearer collaboration and documentation.
What are the two benefits of formulated scenarios?
Formulated scenarios serve two main purposes: they document a shared understanding of the system’s behavior, and they can automatically verify that the system behaves as expected when made machine readable.
What makes a scenario machine readable for automation?
To be used by automation tools, a scenario must be formulated in a structure that software can understand and execute. This is why formats like Gherkin, tables, or keyword-based specifications are used.
What is Gherkin used for in formulation?
Gherkin is a structured natural-language syntax, mainly used for writing feature files that contain scenarios. It uses keywords such as Feature, Rule, Scenario, Given, When, Then, And, and But, and can be automated by Cucumber tools.
What are the main scenario types discussed in this chapter?
The chapter distinguishes between illustrative scenarios and journey scenarios. Illustrative scenarios focus on a single rule and make up most scenarios, while journey scenarios describe a complete user journey and should be kept to a small minority.
Effective Behavior-Driven Development ebook for free
