Chapter 4. Initiating the changes

 

Many ideas central to Specification by Example have been around for decades. In the late 80s, Gerald Weinberg and Donald Gause wrote about communication problems with software requirements in Exploring Requirements: Quality Before Design.[1] The authors suggested that the best way to check for completeness and consistency of requirements is to design black-box tests against them—effectively suggesting the duality of specifications and tests in Specification by Example. In 1986, the German army used what later became the V Model to describe ways to build acceptance tests before implementation for validation. Today, we use the same method but refer to acceptance tests as specifications with examples. Ward Cunningham applied the practices of illustrating using examples and automating validation without changing specifications on the WyCASH+ project in 1989.[2]

1 Gerald M. Weinberg and Donald C. Gause, Exploring Requirements: Quality Before Design (Dorset House Publishing Company, 1989).

Unfortunately, these ideas didn’t catch on at the time. Long development phases made them impractical to execute. People spent months trying to write abstract requirements for projects that would last years. Detailing everything upfront with examples would delay that even longer.

How to begin changing the process

How to begin changing the team culture

How teams integrated collaboration into flows and iterations

Dealing with sign-off and traceability

Warning signs

Remember

sitemap