I was sat quietly, contemplating software development when I noticed a sign on the wall. The sign was instructional and probably placed after some problem had occurred. It was essentially a requirement for customers of the coffee shop, such as me.
The requirement was absolutely clear. It read:
Please only put toilet tissue down the toilet.
The Original Requirement!
As far as I was concerned, this is an entirely unambiguous statement. I had read it just in time. After quietly using the unorthodox method that this required of squatting in the corner to do my business, I quietly placed only toilet tissue down the toilet and flushed.
Although it was uncomfortable and not a technique I would ever use at home, I had stuck faithfully to the requirement. Job done.
And this is why we need Specification by Example. Instead of stating “please only put toilet tissue down the toilet”, a specification workshop would almost certainly have resulted in the following examples:
|Item||Allowed Down The Toilet|
And suddenly all of the assumptions, errors and ambiguities in the original requirement are gone and we have a sensible concrete idea about what is really allowed or disallowed.
So this is my Specification by Example by Example.
If you aren’t already following Gojko Adzic, look him up or even buy his excellent book Bridging the Communication Gap, which is all about this subject.