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 that a  project to improve business processes would be eased by a method for recording the rules of transference.

What is needed is a method for everyone involved in its construction to agree on the system's 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 writing any machine code at all. And the same system 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. 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 to empower 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 switch, then turn on the light. Turning the light off again is a separate need.
  • Each must be written in short, active-voice sentences as if speaking directly to the system itself. ”Then turn on the light” 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 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.
  • 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 are free to create the necessary infrastructure. Leaving so much detail unspecified can be discomforting, 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 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. To consider relationships between business rules, explore dependencies, and create better solutions.