Getting to the core, requirements gathering in the wild

2,888 views

Published on

Session slides as delivered on March 18th 2014 at Engage in Breda, The Netherlands by Sophie Lavignac-Le Madec & Femke Goedhart

Abstract: The basis of any good project is good requirements. Knowing what it is you are going to build / get determines whether your project will be a success or a flat out failure. In reality though the requirements phase is often trivialized or even forgotten. This session will give you tips & tricks as well as explain to you the basic techniques on how to effectively get to the core of the requirements, identify ways of prioritizing them and explain some core concepts of Functional and Technical design elements. Coming from a requirement gathering as well as development & customer point of view Femke & Sophie will take you through some of the real life examples they have come across and a lot of do's & don'ts they have seen (and despaired over)

Published in: Technology

Getting to the core, requirements gathering in the wild

  1. 1. GETTING TO THE CORE REQUIREMENTS GATHERING INTHE WILD
  2. 2. SPEAKERS Femke Goedhart Business Consultant - Silverside,The Netherlands f.goedhart@Silverside.nl @FemkeGoedhart nl.linkedin.com/in/femkegoedhart Sophie Lavignac-Le Madec Senior Engineer Messaging & Collaboration at SES, Luxembourg sophie.lavignac@ses.com lu.linkedin.com/pub/sophie-le-madec/6/2b0/653
  3. 3. “Knowing what you get before you get it”
  4. 4. REALITY…. It’s all critical! No timeWe assumed… Scope??? THEY DON’T USE IT
  5. 5. ROI?
  6. 6. DEVELOPMENT WORK Rework 40% Development 60% Shull et al. 2002, GAO 2004
  7. 7. INFLUENCE OF REQUIREMENTS ON REWORK Rework 40% Requirement Errors 75% Other 25% Leffingwell 1997
  8. 8. COST OF REWORK 1x Requirem ents phase D evelopm ent phase Production phase
  9. 9. COST OF REWORK 1x 2-3x Requirem ents phase D evelopm ent phase Production phase
  10. 10. Requirem ents phase D evelopm ent phase Production phase 1x 2-3x 100x Boehm 1981; Grady 1999; Haskins 2004 COST OF REWORK
  11. 11. All we really need is some document management! Ok, but is that all? Exam ple
  12. 12. Well yes, but we expect it to also do … and … and … Mmm…. ok, is document management really what you need then? Exam ple
  13. 13. Development phase Requirements phase Signoff $$$ $
  14. 14. REQUIREMENTS Vision & Scope User Requirements Software Requirements specification
  15. 15. INCREASING LEVELS OF DETAILS: Vision & Scope document User requirements document Software requirements specification Business requirement Business rules User requirement Quality Attribute External interfaces Functional requirement System requirement Constraints Non-Functional requirement Software Requirements Third edition,Wiegers & Beatty
  16. 16. START WITHTHE WHY Vision & Scope document User requirements document Software requirements specification WHY HOW WHAT
  17. 17. REQUIREMENT DOCUMENTS? Vision & Scope User Requirements Software Requirements specification Project Charter Functional Design Technical Design Project requirements document Project initiation document etc, etc…
  18. 18. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt STAGES Software Requirements Third edition,Wiegers & Beatty
  19. 19. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
  20. 20. ElicitationRequirements DevelopmentRequirements Engineering Budget &Time? Waterfall or Agile? User centric or Product centric? SCOPE
  21. 21. ElicitationRequirements DevelopmentRequirements Engineering DiscoverDesignDevelopTest Discover Develop Design Test Sprint #1 Sprint #2 Sprint #3 Discover Develop Design Test Discover Develop Design Test AGILE OR WATERFALL?
  22. 22. WHO ? ElicitationRequirements DevelopmentRequirements Engineering OWNER
  23. 23. WHO ELSE? ElicitationRequirements DevelopmentRequirements Engineering Who will use it? Who will depend on it? Who has a stake in it? OWNER
  24. 24. WHO ELSE? • Direct users • Indirect users • Stakeholders • Sponsors • Acquirer • Management • Compliance auditor • Suppliers • Regulatory body • Quality assurance • Etc, etc……. ElicitationRequirements DevelopmentRequirements Engineering Who will use it? Who will depend on it? Who has a stake in it? OWNER
  25. 25. ElicitationRequirements DevelopmentRequirements Engineering Yes! that’s what we want! Well I think something else is more important! That’s not what I wanted! Exam ple
  26. 26. TACTICS FOR GATHERING REQUIREMENTS • Interviews • Focus groups • Observation • Document studies • RFP Documents • Workshops • Questionnaires • Incident & compliance systems • SME’s • Market research • Review of current systems • …. ElicitationRequirements DevelopmentRequirements Engineering
  27. 27. TACTICS FOR GATHERING REQUIREMENTS • Interviews • Focus groups • Observation • Document studies • RFP Documents • Workshops • Questionnaires • Incident & compliance systems • SME’s • Market research • Review of current systems • …. ElicitationRequirements DevelopmentRequirements Engineering Talking != Listening!
  28. 28. METHODS ElicitationRequirements DevelopmentRequirements Engineering Creative Problem Solving (Isaken & Treffinger) • Mess finding • Data finding • Problem finding • Idea finding • Solution finding • Acceptance finding
  29. 29. METHODS ElicitationRequirements DevelopmentRequirements Engineering Iterative question asking (Sakichi Toyoda) • Why? • Why? • Why? • Why? • Why? <-Root cause
  30. 30. ElicitationRequirements DevelopmentRequirements Engineering
  31. 31. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
  32. 32. SMART • Specific • What? Why? Who? Where? Which? • Measurable • How much? How many? Is it quantifiable? • Attainable • Can it be achieved with the resources & facilities available? • Relevant • Does it relate to the project vision & scope? • Timely • Can I set a date to it? AnalysisRequirements DevelopmentRequirements Engineering
  33. 33. PRIORITISE AnalysisRequirements DevelopmentRequirements Engineering
  34. 34. MOSCOW AnalysisRequirements DevelopmentRequirements Engineering • Must • Should • Could • Won’t (or would)
  35. 35. MOSCOW AnalysisRequirements DevelopmentRequirements Engineering Requirement M S C W Insert multiple order lines x Create an export of closed orders x Allow to copy order details to allow quick registration x Allow for inserting personal notes on orders x
  36. 36. MOSCOW AnalysisRequirements DevelopmentRequirements Engineering Requirement Costs M S C W Insert multiple order lines $100 x Create an export of closed orders $1500 x x Allow to copy order details to allow quick registration $250 x Allow for inserting personal notes on orders $100 x x
  37. 37. EISENHOWER DECISION MATRIX AnalysisRequirements DevelopmentRequirements Engineering Urgent Not Urgent Important Not Important
  38. 38. PRIORITISE AnalysisRequirements DevelopmentRequirements Engineering Urgent Not Urgent Important Must! Should Not Important Could Won’t (Nice to have)
  39. 39. AnalysisRequirements DevelopmentRequirements Engineering KEEP IT SIMPLE STUPID
  40. 40. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
  41. 41. UNIFIED MODELLING LANGUAGE Structural UML diagrams • Class diagram • Component diagram • Composite structure diagram • Deployment diagram • Object diagram • Package diagram • Profile diagram SpecificationRequirements DevelopmentRequirements Engineering Behavioural UML diagrams • Activity diagram • Communication diagram • Interaction overview diagram • Sequence diagram • State diagram • Timing diagram • Use case diagram
  42. 42. SpecificationRequirements DevelopmentRequirements Engineering VISUALISE
  43. 43. WRITE IT DOWN • Build prototypes • Provide demo’s of similar functionality • Models & Diagrams • Draw out process- and workflows • Mockups of screens & forms • Use cases, function descriptions • Tell it as a story:“a day in the life of…” SpecificationRequirements DevelopmentRequirements Engineering
  44. 44. TALKTHETALK… SpecificationRequirements DevelopmentRequirements Engineering User ?? Developer ??
  45. 45. TALKTHETALK… SpecificationRequirements DevelopmentRequirements Engineering User ?? Developer ?? Management $$$?
  46. 46. example ElicitationRequirements DevelopmentRequirements Engineering
  47. 47. ElicitationRequirements DevelopmentRequirements Engineering
  48. 48. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
  49. 49. EXPECTATION GAP ValidationRequirements DevelopmentRequirements Engineering Time —> What the developer builds What the user wants Expectation gap Software Requirements Third edition,Wiegers & Beatty
  50. 50. EXPECTATION GAP ValidationRequirements DevelopmentRequirements Engineering Time —> What the developer builds What the user wants Expectation gap contact pointcontact point Software Requirements Third edition,Wiegers & Beatty
  51. 51. PLAY IT BACK! “I ‘ve heard that…” “I understand you want…” “You expect it to…” etc. etc… ValidationRequirements DevelopmentRequirements Engineering
  52. 52. ROLE Check your personal feelings at the door but don’t forget to keep an eye on project scope & constraints! ValidationRequirements DevelopmentRequirements Engineering
  53. 53. 4-EYES PRINCIPLE ValidationRequirements DevelopmentRequirements Engineering
  54. 54. ValidationRequirements DevelopmentRequirements Engineering SIGN OFF ONTHE REQUIREMENT BASELINE
  55. 55. ElicitationRequirements DevelopmentRequirements Engineering Exam ple
  56. 56. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
  57. 57. Change managementRequirements DevelopmentRequirements Engineering THINGS CHANGE
  58. 58. – Douglas Hofstadter “Hofstadter's Law: It always takes longer than you expect, even when you take Hofstadter's Law into account” Change managementRequirements DevelopmentRequirements Engineering
  59. 59. MANAGE CHANGES • Set up a formal RFC (Request For Change) process • Register all changes and use version control • Translate into effect (impact on time, costs & end result) • (Re-)Prioritise • Communicate • Sign off on changed requirements Change managementRequirements DevelopmentRequirements Engineering
  60. 60. WRAP UP • Treat Requirements Gathering as if it’s a project on its own • Assign or free up enough resources • Evaluate afterwards (improvements for future projects) • Incorporate an outsiders view • Don’t set it in stone…. things change, just make sure you manage it! • Be open… you might be pleasantly surprised!
  61. 61. QUESTIONS? Femke Goedhart f.goedhart@Silverside.nl @FemkeGoedhart nl.linkedin.com/in/femkegoedhart Sophie Lavignac-Le Madec sophie.lavignac@ses.com lu.linkedin.com/pub/sophie-le-madec/6/2b0/653

×