Speaking about machines
Machines transfer energy from one state to another: start with this, end with that. In the same way, business machines turn inputs into outputs. A business that turned a thing back into itself would be of questionable value. It follows then business machines are eased by recording the rules of transference.
What is needed is a method for everyone involved in a creating a business machine, a system, to agree on the its expected behavior. A way of unambiguously communicating ideas, so that they can be understood by all. A plain language that follows syntax such that it forms pseudocode. That is: high-level code meant to be read by people. With that kind of pseudocode, business rules can be recorded and negotiated without directly writing complex code (i.e. programming languages and database queries). Ideally, the same method used to record expectations would serve for validating the outcome.
Many pseudocodes exist, each similar in describing a precondition and postcondition. Some are written lists of attributes the system shall have. Some are governed by strict templates. Some closely resemble computer languages. While these heuristics offer straightforward ways to flatly record requirements, few are as efficient as Given-When-Then.
The power of Given-When-Then
Created for highly collaborative agile development focused on testable results, GWT is a natural language pseudocode that fuses precision with behavior. As its name suggests, it specifies three clauses written in paragraphical tercets, each set of which describes a single scenario.
- Given - starting precondition that must be true, data that must exist
- When - the user action that triggers the transition to a postcondition
- Then - the observable outcome provided by the system
There are multiple ways to expand these three clauses, but an understanding of each is essential. A few rules will help keep things in order.
Rules for GWT
- Each paragraph (set of given, when, then) must describe one and only one scenario. Given the light is off, when a user flips the light switch, then set the light to on. Turning the light off again is a separate need.
When a user flips the light switch
Then set the light to ON
- Each must be written in short, active-voice sentences as if speaking directly to the system itself. ”Then set the light to on” is an executable command. "Then the light will be on" is not.
- Then is a required clause. Without an observable result, the requirement is valueless. However, in some cases either, given or when, but not both, may be omitted if evident from the context. ”Given the light is on, then make its color blue” is apparent: the unstated when clause being that someone has already switched on the light.
Then set its color to blue
- Unless otherwise specified, actions happen immediately, within system limits, and remain true until made false. The light will be on as soon as the switch is on, not later, and will stay on until otherwise stated.
Requirements as opportunity
Together, these GWT's clauses describe what should happen without specifying how it should be accomplished. In the example above, business owners and lighting designers can work out dazzling luminescent compositions while electrical engineers develop the necessary infrastructure. Leaving so much detail unspecified can be uncomfortable, yet by not restraining those parameters collaborators are freed to exercise their full abilities.
Recording requirements with GWT does more than enable a single written resource to serve the project from discovery to delivery; it provides an opportunity to think through the business rules logically. Testing is facilitated not only by ensuring the product follows steps set forth in given-when-then but also by thinking through the steps themselves. Creators are empowered to ask what should happen under ideal and less than ideal conditions.
GWT is an opportunity to consider relationships between business rules, explore dependencies, and create better solutions.