I love the whole concept of Specification by Example. This approach ticks several boxes for me:

1. Business requirements
2. Concrete requirements
3. Earlier conversations
4. Shared understanding
5. Automated tests
6. Living documentation

Business Requirements

Specification by Example focusses requirements on the business need. I admit that isn’t new but it is definitely a good thing. Requirements from the perspective of the business have been around for a long time. Use Cases and more recently User Stories have brought this type of requirements into the mainstream.

There are several advantages to putting the emphasis on business requirements as opposed to technical requirements:

• both parties, development and business, understand the requirements (business reps generally don’t understand technical requirements)
• it enables vertical slicing of requirements, thus the user gets value in small frequent increments (technical types tend to chunk in components that take a while to build)

Concrete Requirements

Specification by Example abandons the older style of describing requirements with abstract statements in favour of concrete examples. Hence the name, specification by example. “Concrete” is my term but means the tests are precise, complete, and realistic.

Earlier Conversations

I particularly like that Specification by Example (and BDD) formalises conversations that should, and usually do, happen anyway. It also brings these conversations forward in the development process thus reducing the time it takes to release to live.

BDD in a Nutshell (Rachel Davies)

Shared understanding

There are two aspects of Specification by Example that encourages shared understanding:

• process encourages conversation across disciplines (BA, Dev, Test)
• the automated tests document the results of those conversations and remind of the team of the implications long after the people themselves are gone

Automated Tests

Specification by Example makes the jump from requirements to automated tests trivial; at least it does if you’re using a tool like Cucumber. The way I look at it if I have to write down requirements, and most teams need to, then I may as well write the requirements so the requirements can also be automated tests.

Living Documentation

Traditional documentation quickly become stale. People stop updating it and then everybody stops referring to the documentation because it is stale. Which just makes it worse.

Requirements specifications that drive the automated tests are less likely to go stale. The nagging “Red” on the build monitor should prevent this.

This post is part of a series on Specification by Example.