Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20171031 (anv afternoon) specification by example

841 views

Published on

Specification by example workshop for the companies' internal learning conference

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

20171031 (anv afternoon) specification by example

  1. 1. @kimvanwilgen | www.kimvanwilgen.comSpecification by example 1 @kimvanwilgen | www.kimvanwilgen.com Specification by example Kim van Wilgen www.kimvanwilgen.com
  2. 2. @kimvanwilgen | www.kimvanwilgen.comSpecification by example 5 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
  3. 3. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 6 And how about BDD, TDD and ATDD?
  4. 4. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 7 Goal of specification by example
  5. 5. @kimvanwilgen | www.kimvanwilgen.comSpecification by example 8
  6. 6. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 9 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
  7. 7. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 10 Methods to derive scope from goals Smart use cases User story mapping Example mapping Feature injection
  8. 8. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 11 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
  9. 9. @kimvanwilgen | www.kimvanwilgen.comSpecification by example 12 @kimvanwilgen | www.kimvanwilgen.com Key examples Getting examples to gather the specifications and get a deep understanding of the case
  10. 10. @kimvanwilgen | www.kimvanwilgen.comSpecification by example 13 @kimvanwilgen | www.kimvanwilgen.com Example mapping
  11. 11. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 14 Example mapping
  12. 12. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 15 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
  13. 13. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 16 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
  14. 14. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 17 • 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
  15. 15. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 18 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
  16. 16. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 19 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
  17. 17. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 20 Automating the specification without changes
  18. 18. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 21 Living documentation
  19. 19. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 22 Tools for automation
  20. 20. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 23 Imperative vs. Declarative language And being unibiquitous
  21. 21. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 24 Imperative vs. Declarative style Gone too far
  22. 22. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 25 Avoid workflow style It leads to lots of repetition
  23. 23. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 26 Focus on a single action
  24. 24. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 27 Test pyramid: make small tests Focus on small tests and fast feedback that’s valuable and supports you the most
  25. 25. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 28 Case: Implement the case to withdraw an amount of 130 euro. Try it!
  26. 26. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 29 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
  27. 27. @kimvanwilgen| www.kimvanwilgen.comSpecification by example 30 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
  28. 28. @kimvanwilgen | www.kimvanwilgen.comSpecification by example 31 @kimvanwilgen | www.kimvanwilgen.com References and questions www.kimvanwilgen.com kimvanwilgen kimvanwilgen@gmail.com

×