20171031 (anv afternoon) specification by example

@kimvanwilgen | www.kimvanwilgen.comSpecification by example 1
@kimvanwilgen | www.kimvanwilgen.com
Specification by
example
Kim van Wilgen
www.kimvanwilgen.com

Specification by example is a collaborative approach to
defining requirements and tests for software products
based on using realistic examples instead of abstract
statements. It is applied in agile software development, in
particular behavior driven development.
Gojko Adzic in Specification by example, 2011

@kimvanwilgen| www.kimvanwilgen.comSpecification by example 6
And how about BDD, TDD and ATDD?

Goal of specification by example

Specifying use cases asks for a
design of a solution.
This is not a business capacity
➢ Derive scope together
➢ Focus on goals and
understanding value
➢ Ask Why to uncover hidden
goals
➢ Ask alternatives to express value
Deriving scope from business goals

Methods to derive scope from goals
Smart use cases
User story mapping
Example mapping
Feature injection

Case:
The company builds software for ATM’s. They ask for implementing a free choice of bills.
Customer:
- Explain how you want to have a free choice in bills to improve satisfaction.
- Why do you want a free choice in bills: It was found that customers want a choice in bills when withdrawing, and
that improves customer satisfaction at the ATM
- Why do you want improved customer satisfaction: Some banks are choosing ATM software vendors based on this.
Turnaround will improve by 90%.
- Is there a workaround for choosing notes: Yes, a customer can withdraw a small amount of money for pocket
change and the rest in big bills, or change one big note at a store
- Do customers ever have the need for only big bills: No
- Could we always give some small notes and have improved customer satisfaction: Yes
- Will customer satisfaction be higher when customers can choose the composition of their small notes? Yes
- Is a choice amongst two or three option satisfactionary? Yes
- In what countries will the software be operated? In the eurozone incl. UK and Switserland
Let’s try scoping

Key examples
Getting examples to gather
the specifications and get a
deep understanding of the
case

Example mapping

Three amigos Business
Developer
Tester
More than 25
minutes
Practice more
Story too big
Too many questions
Feedback
from example
mapping
Many reds  Stop
Some reds  Define actions
Example mapping session

Case: You are building the use case for choosing bills for a cash
withdrawal. Get the key examples
Customer:
- Is the choice entirely free or are there contraints? We don’t want our small bills to run out
fast. So there will be some maximum on the amount in small bills.
- How big is the maximum of small bills? Well I don’t know yet. I guess it depends on the
country’s currency anyway
- How is it determined which bills to provide? I don’t know. I would like some small bills but i
guess never more then 4 of the same notes.
- What if the bills of some kind run out? Then you will offer only alternatives that don’t
contain those.
- How can the customer choose? He will be presented with some standard options, or with
the least amount of options available given the presence of notes and the amount of the
cash withdrawal.
Key examples

• Saves time and makes the meeting effective
• Get a basic structure in place
Preparation and analysis
• Leads to a traditional handoff from analyst to developer: developers
just take the requirements without deep understanding
• For complex cases do just enough preparation to have a discussion

Case: You are building the use case for choosing bills for a cash withdrawal. Get the key examples
Customer:
- Is the choice entirely free or are there contraints? We don’t want our small bills to run out fast. So there will be some maximum on the amount in small bills.
- How big is the maximum of small bills? It’s about giving some pocket money. Ten small bills should suffice. The rest will always be in big bills. Otherwise the ATM could fysicaly disfunction too.
- What are small bills? Depends on the country. For euros it’s 10, and 20, the other note is 50. For the UK it’s 5, 10 and 20, also leaving 50’s. And in Switserland it’s 10, 20 and 50, leaving the 100, 200 and 1000 bills.
- Hmmm, maybe we should focus on euros and make the other algoritms in a seperate use case? That’s fine.
- How is it determined which bills to provide? There will be three options: smallest possible, least pocket change possible, and the ‘ big pocket money’ option.
Smallest possible: Take 4 x 10. Add 4 times 20, and add 50’s. But only if the withdrawal amount isn’t reached.
Example: withdraw 100. Get 4 x 10 = 40. Add 3 x 20.= 100
Example 2: withdray 70. Get 4 x 10 = 40. Add 2 x 20 = 80. Oh, now subtract the biggest note possible to get to the amount. So in this case subtract 1 x 10 = 70. So 3 x 10 and 2 x 20.
Example 3: Wtihdraw 130. Get 4 x 10, 4 x 20 and 1 x 50 = 170. Subtract 2 x 20 = 130.
Example 4: Withdraw 140. Get 4 x 10, 4 x 20 and 1 x 50 = 170. Subtract 1 x 20 and 1 x 10 = 130
Big pocket money
Take 4 x 20 and add 50’s. Add 20 and then 10 to reach the amount
Example: Withdraw 100. Get 4 x 20. Then add 20 to get to 100. So 5 x 20
Example 2: Withdraw 130. Get 4 x 20. Then add 50. So 4 x 20 and 1 x 50
Example 3: Withdraw 140. Get 4 x 20. Then add 50. Then add 10. So 4 x 20, 1 x 10, 1 x 50
Least pocket change possible
Take as many 50’s as possible. Then add 20’s en then a 10.
Example: Withdrax 100. Get 2 x 50.
Example 2: Withdraw 140. Get 2 x 50 and 2 x 20.
- What if the bills of some kind run out? Then you will offer only alternatives that don’t contain those, using the same algoritm but now allowing up to 8 x the small bill that is available..
- Might we set up a table with the options for each amount, including the options when some notes aren’t available? Yes, that’s fine.
Key examples

Business users think about the user interface
perspective. They offer examples on how things
should work rather than what is required. This extra
information must be removed to make key examples
simple to communicate and understand.
Refining the specification

Automating the specification without changes

Living documentation

Tools for automation

Imperative vs. Declarative language
And being unibiquitous

Imperative vs. Declarative style
Gone too far

Avoid workflow style
It leads to lots of repetition

Focus on a single action

Test pyramid: make small tests
Focus on small tests and fast feedback that’s valuable and supports you the most

Case: Implement the case to withdraw an amount of 130 euro.
Try it!

Withdraw money will
provide three options
Withdraw 130 with all
notes available will give
you (4 x 10, 2 x 20, 1 x
50), (4 x 20, 1 x 50) and
(1 x 10, 1 x 20 and 2 x 50)
Withdraw 130 with no
10’s will give you (4 x 20,
1 x 50)
Seperate tests for their function

Deriving scope
Collaborate on deriving scope
Scoping asks for design
Key examples
Use example mapping
Stop if there are too many questions
Prepare somewhat
Refining the specification
Remove UI for maintainability
Automating without changes
Use declarative language for maintainability
Avoid workflow style
Make tests small
Wrap up

References
and questions
www.kimvanwilgen.com
kimvanwilgen
kimvanwilgen@gmail.com

20171031 (anv afternoon) specification by example

20171031 (anv afternoon) specification by example

Recommended

More Related Content

What's hot

What's hot(19)

Similar to 20171031 (anv afternoon) specification by example

Similar to 20171031 (anv afternoon) specification by example(20)

Recently uploaded

Recently uploaded(20)

20171031 (anv afternoon) specification by example