Validating Requirements with Given-When-Then
When identifying requirements, it can be really tricky to develop a good understanding of how software should behave.
Waterfall teams invest a lot of time upfront in capturing and reviewing exhaustive requirements documents to make sure their product is both complete and correct in addressing these needs. Agile teams incrementally approach building the solution a piece at a time—and that means validating the requirements incrementally, too.
Ellen Gottesdiener and Mary Gorman wrote the book Discover To Deliver: Agile Product Planning and Analysis and recently posted an article explaining how to use Given-When-Then to validate requirements.
As business analysts, we write requirements for three audiences: our implementation team, our stakeholders, and our future selves (in descending order of priority).
The implementation team consumes the requirements while building the solution. The stakeholders (may) consume our requirements documents as part of validating that we are about to go build something that does what they need. Our future selves need the ability to look back and understand why we did something in the first place.
One mistake many agile teams make is combining their ability to make changes quickly with the dynamic of human nature that it is easier to get accurate feedback about a thing than it is to walk in with a blank slate and get someone to describe what they need that thing to be.
While iterative development helps you minimize costs, even this approach doesn’t allow you to get it right until after the second (or third) iteration—because you have to build it wrong first, then get feedback, then fix it.
The Given-When-Then (GWT) approach, shared with Ellen and Mary by Dan North, gives the team a thing before building it wrong—allowing the team to combine the benefits of incremental development with the benefits of getting it right the first time.
The GWT structured elicitation presents stakeholders with a context (the “given”) in the language of the business—not forcing stakeholders to learn the tools of formal requirements writing. Then the stakeholders are presented with a scenario (the “when”) and an outcome (the “then”).
This is the thing that pressure tests our understanding as business analysts about how the system should behave. The stakeholders can tell us, easily and precisely, given a context, that when this scenario occurs, then this output is expected. During the conversation with stakeholders, we will uncover many other scenarios that need to be addressed as well.
GWT is a great tool for making sure that this requirement is correct and for discovering some of the requirements that we did not realize were there. Where GWT does not help is in ensuring that we have captured a complete understanding of all related requirements.
Decision trees/decision tables are the right tool for this job. This excerpt from Visual Models for Software Requirements by Joy Beatty and Anthony Chen provides a great overview and explanation of how to use them to make sure we don’t miss anything.
