Why your latest requirements document is worse than useless.
I’m sure that last time you created a big, thick, detailed specification of everything that is needed in a new system it gave you a tremendous feeling of pride and accomplishment. And that summarizes the only value of that deliverable nicely. Because I bet no one read it. I mean, really read it. And even if they did, I bet it doesn’t reflect what was actually built. And even if it did, I bet that within months it was out of date. And even if it wasn’t I bet no one trusts it so no one looks at it anyway.
Arborcide is the murder of trees. An unintended but real consequence of a big, thick requirements document (OK, maybe virtual trees).
So what is the alternative?
Some level of documentation will always be required. Small, lightweight documents that describe the big picture and a cross reference to details are essential. But how do you document detailed requirements? And how do you make sure that the requirements are still valid and current?
The one version of the truth about the way any software system really works is the source code from which the system is generated. The problem is that there is a lot of source code and it is hard to see the wood for the trees. And you have to be proficient in programming languages to read the code. And that only tells you what the system does, not what it is supposed to do, and whether it really does it.
So, to summarize so far, the picture we are painting seems to indicate that we need to document the system in the source code, by showing what the system is supposed to do and proving whether it does it.
Can we do that?
It sounds a little bit like testing, doesn’t it?
Behavior Driven Development, sometimes abbreviated to BDD, allows you to do just this. The business analyst, or QA, or a developer, or even an end user, writes a user story using an intuitive syntax that reads just like, well, a story. Instantly recognizable. The story is written in any text editor (a word processor will do) and is then placed in a programming tool (note that tools are becoming available that allow users to create stories easily in the developers’ development environment). The story might look something like “As a customer I want to browse available products and if I see something I need request an order”.
The story is then elaborated to describe more detail, using 3 statements:
Given identifies a precondition; something like “given a customer wants to buy a product”
When identifies an action that is taken; something like “the customer enters product details and quantities and presses submit”
Then identifies the work the system does; something like “the system checks for available stock, and if available creates an order and prompts the customer for name and address”.
This can also be started by business analysts but can require developers’ help to finish.
All of this is written before any real programming starts. And at this point you can “run“ the above. And everything fails because there is no program!
But see how that tells you that there is some work to do. And the developers write the program in such a way that the result needed from the “then” can be verified by the system. So when the system matches the expectation specified in the “then” the functionality is complete. What a way to track progress! And look how the documentation matches the source code perfectly. And guess what – every time the system is built, forever, these test run. So if someone breaks something you find out right away because a test fails immediately. And the documentation can be trusted because it matches the system.
Is this real? Can it work? Yes it can! Organizations are doing this now.
I’m just sowing seeds for interest here. I will blog more about this, and give some examples of tools and books that can help you move forward on Behavior Driven Development. This is a great opportunity for generalizing specialists!
Follow needpoweredchg on Twitter to hear more news on this topic. And let us know if you’d like more detail, or even training classes on how to get started on Behavior Driven Development.