In the traditional process, requirements are specified and handed over to developers and testers, who interpret them to produce software and test scripts. Working in isolation, developers and testers are influenced by their own understanding, which is not necessarily the same as what the customers intended. Different people understand abstract requirements differently, especially things that seem obvious but depend on domain expertise or a particular jargon. Small differences in understanding and expectations have a large cumulative effect, causing the project to miss the target or to require lots of rework straight after delivery.
With specification by example, we use the same set of realistic examples consistently throughout the process. The examples clearly define what it is that we want. They are first used as a specification, then as a target for development and as the acceptance criteria to verify the results of development. They are also used to discuss later system changes. This avoids the need for the translation of information between different participants in the development process.
