20171031 (anv afternoon) specification by example

@kimvanwilgen | www.kimvanwilgen.comSpecification by example 1

@kimvanwilgen | www.kimvanwilgen.com

Specification by exampleKim 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 adesign of a solution.

This is not a business capacity

➢ Derive scope together

➢ Focus on goals andunderstanding value

➢ Ask Why to uncover hiddengoals

➢ Ask alternatives to express value

Deriving scope from business goals


Methods to derive scope from goals

Smart use casesUser story mappingExample mappingFeature 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, andthat 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 examplesGetting examples to gatherthe specifications and get a deep understanding of thecase



Example mapping


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 thecash 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: developersjust 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 thingsshould work rather than what is required. This extra information must be removed to make key examplessimple to communicate and understand.

Refining the specification


Automating the specification without changes


Living documentation


Tools for automation


Imperative vs. Declarative languageAnd being unibiquitous


Imperative vs. Declarative styleGone too far


Avoid workflow styleIt leads to lots of repetition


Focus on a single action


Test pyramid: make small testsFocus 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 scopeCollaborate on deriving scopeScoping asks for design

Key examplesUse example mappingStop if there are too many questionsPrepare somewhat

Refining the specificationRemove UI for maintainability

Automating without changesUse declarative language for maintainabilityAvoid workflow styleMake tests small

Wrap up



References and questions

www.kimvanwilgen.com

kimvanwilgen

[email protected]

Engineering

20171031 (anv afternoon) specification by example