Getting to the core, requirements gathering in the wild
•
19 gefällt mir•3,573 views
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)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Getting to the core, requirements gathering in the wild
Ähnlich wie Getting to the core, requirements gathering in the wild (20)
Mehr von Femke Goedhart
Mehr von Femke Goedhart (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Getting to the core, requirements gathering in the wild
- 1. GETTING TO THE CORE REQUIREMENTS GATHERING INTHE WILD
- 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. “Knowing what you get before you get it”
- 4. REALITY…. It’s all critical! No timeWe assumed… Scope??? THEY DON’T USE IT
- 5. ROI?
- 6. DEVELOPMENT WORK Rework 40% Development 60% Shull et al. 2002, GAO 2004
- 7. INFLUENCE OF REQUIREMENTS ON REWORK Rework 40% Requirement Errors 75% Other 25% Leffingwell 1997
- 10. Requirem ents phase D evelopm ent phase Production phase 1x 2-3x 100x Boehm 1981; Grady 1999; Haskins 2004 COST OF REWORK
- 11. All we really need is some document management! Ok, but is that all? Exam ple
- 12. Well yes, but we expect it to also do … and … and … Mmm…. ok, is document management really what you need then? Exam ple
- 14. REQUIREMENTS Vision & Scope User Requirements Software Requirements specification
- 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. START WITHTHE WHY Vision & Scope document User requirements document Software requirements specification WHY HOW WHAT
- 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. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt STAGES Software Requirements Third edition,Wiegers & Beatty
- 19. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
- 20. ElicitationRequirements DevelopmentRequirements Engineering Budget &Time? Waterfall or Agile? User centric or Product centric? SCOPE
- 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. WHO ? ElicitationRequirements DevelopmentRequirements Engineering OWNER
- 23. WHO ELSE? ElicitationRequirements DevelopmentRequirements Engineering Who will use it? Who will depend on it? Who has a stake in it? OWNER
- 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. 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. 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. 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. METHODS ElicitationRequirements DevelopmentRequirements Engineering Creative Problem Solving (Isaken & Treffinger) • Mess finding • Data finding • Problem finding • Idea finding • Solution finding • Acceptance finding
- 29. METHODS ElicitationRequirements DevelopmentRequirements Engineering Iterative question asking (Sakichi Toyoda) • Why? • Why? • Why? • Why? • Why? <-Root cause
- 31. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
- 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
- 34. MOSCOW AnalysisRequirements DevelopmentRequirements Engineering • Must • Should • Could • Won’t (or would)
- 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. 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. EISENHOWER DECISION MATRIX AnalysisRequirements DevelopmentRequirements Engineering Urgent Not Urgent Important Not Important
- 38. PRIORITISE AnalysisRequirements DevelopmentRequirements Engineering Urgent Not Urgent Important Must! Should Not Important Could Won’t (Nice to have)
- 39. AnalysisRequirements DevelopmentRequirements Engineering KEEP IT SIMPLE STUPID
- 40. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
- 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
- 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
- 48. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
- 49. EXPECTATION GAP ValidationRequirements DevelopmentRequirements Engineering Time —> What the developer builds What the user wants Expectation gap Software Requirements Third edition,Wiegers & Beatty
- 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. PLAY IT BACK! “I ‘ve heard that…” “I understand you want…” “You expect it to…” etc. etc… ValidationRequirements DevelopmentRequirements Engineering
- 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. 4-EYES PRINCIPLE ValidationRequirements DevelopmentRequirements Engineering
- 54. ValidationRequirements DevelopmentRequirements Engineering SIGN OFF ONTHE REQUIREMENT BASELINE
- 56. Requirements Engineering Requirements Development Requirements Management Analysis ValidationSpecificationElicitation Change Mgt Software Requirements Third edition,Wiegers & Beatty
- 57. Change managementRequirements DevelopmentRequirements Engineering THINGS CHANGE
- 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. 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. 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. 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