Chapter 7. Illustrating using examples
Examples are a good way to avoid ambiguities and communicate with precision. We use examples in everyday conversation and in writing without even thinking about it—when I searched online for the phrase “for example,” Google returned more than 210 million pages that use this term.
With traditional specifications, examples appear and disappear several times in the software development process. Business analysts often get examples of existing orders, invoices, and reports from business users, which they translate into abstract requirements. Developers invent examples to explain edge cases and clarify them with business users or analysts and then translate the cases to code, without recording the examples. Testers design test cases that are examples of how the system is expected to work; they keep these examples to themselves and don’t communicate them to programmers or analysts.
Everyone invents their own examples, but there’s nothing to ensure that these examples are even consistent, let alone complete. In software development, this is why the end result is often different from what was expected at the beginning. To avoid this, we have to prevent misinterpretation between different roles and maintain one source of truth.