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

Unable to load book!

The book could not be loaded.

(try again in a couple of minutes)

manning.com homepage
test yourself with a liveTest