Nov 04 2008
Specifying with examples
In order to get requirements, business analysts often work through a number of realistic examples with the customers, such as existing report forms or examining existing work processes. These examples are then translated to abstract requirements in the first step of the Telephone game. Developers extract knowledge from that and translate it into executable code, which is handed over to testers. Testers then take the specifications, extract knowledge from them and translate it into verification scripts, which are then applied to the code that was handed over to them by the developers. In theory, this works just fine and everyone is happy. In practice, this process is essentially flawed and leaves huge communication gaps at every step. Important ideas fall through those gaps and mysteriously disappear. After every translation, information gets distorted and misunderstood, leading to large mistakes once the ideas come through the other end of the pipe. Continue Reading »
The idea of the example-writing workshop to support acceptance testing seems to cause a lot of confusion and misunderstanding, at least judging from my two most recent talks and the questions during the discussion at the second Alt.NET UK conference. A lot of people seem to somehow contrast that to iterative development and mistake the workshop for big design up-front, expecting that it will increase the feedback loop. To resolve the misunderstanding, here is an example of how the workshop (and acceptance testing) fits into an agile process to shorten the feedback loop and improve iterative development. 
