Requirements gathering for developers
•Download as PPTX, PDF•
1 like•279 views
My goal with this talk was to provide developers and tech folks with an understanding of requirements gathering. Key concepts and resources that they can use to make their own coding practice better. Part of being a professional coder
Recommended
More Related Content
What's hot
What's hot (18)
Similar to Requirements gathering for developers
Similar to Requirements gathering for developers (20)
More from Dorje McKinnon
More from Dorje McKinnon (12)
Recently uploaded
Recently uploaded (20)
Requirements gathering for developers
- 5. Dorje McKinnon Vajra.co.nz : Digital projects delivered
- 6. Requirements gathering and other soft skills
- 7. But why ?
- 8. LOWER Risk
- 9. War stories
- 10. Plan 1. What do others think you need to know 2. Skills practice 3. Do some requirements gathering 4. Your take away 5. Conclusion
- 11. But what is requirements gathering? For CodeCamp?
- 12. Introductions
- 13. WAT!
- 14. Lee Porteous Within the agile world this leads to the need to fail early ie put some early prototypes in front of users (build good relationships with them, be open to change) and get feedback from them. We are starting to use a technique called HCD or Human Centred design which has a host of tools that you can use to do this including sketching even to build prototypes together. CX Customer Experience Designers too ie so that we understand what are customers want and need and be able to deliver to those. The days of receiving specs or asking questions of users has long proved unsuccessful. People are generally tactile and need to be seeing something in front of them to critique.
- 15. Chris Saunders Key skills of a programmer for requirement gathering? Top skill (off the top of my head) 1. Communication, building a relationship with customer/stakeholder.
- 16. Sarah Kinley not taking things at face value. ALWAYS asking why/what is the end game.
- 17. Stuart Charters 1) Understanding the business problem that is being solved (and not the solution that the client thinks they need/want) & how that fits with other business processes 2) Asking the right questions & challenging assumptions (both open & closed questions, checking info by repeating back & testing the "hardness" of constraints - e.g. it needs to operate 24x7 when the business only operates working hours) 3) Triangulation - talking to multiple people to ensure that processes are properly understood (including people who are actually doing the process rather than people who think they know the process) • At a more code level • It is probably about getting good coverage of the requirements by test cases - especially corner cases - from the business. • Overall it is about being more "holistic" in looking at the solution.
- 18. Craig O’Laughlin 1. Know what problem is being solved – be human/user centered • Developers engage more if you put this in story form 2. Acceptance is defined (e.g. we’ve solved X problem when Y is possible) 3. Constraints are understood, because they influence the design 1. Tech e.g. only open source 2. Existing software e.g. old code 3. Can we do it ? 4. What risk is there
- 19. Joel on the human mind
- 20. Don’t know Joel?
- 21. Bill Wake Remove UI from consideration of developers early on so they can focus on unleashing their creative solution User stories are superb way to capture requirements: use the invest model I – independent (thin slice stand alone functionality) N – Negotiable, design solution can be creative V – Valuable to customer E – Estimable for ranking S – Small 50% of sprint T – Testable >>> leads to >> Acceptance >> therefore “You all really want to be testers”
- 22. Take aways
- 23. Key themes 1. Relationships (with clients stakeholders users, mostly the actual users not their bosses) 2. Questions (challenge assumptions / question why) 3. Acceptance Know when a requirement has been met
- 24. Which & Why
- 25. Key themes Which & Why 1. Relationships (with clients stakeholders users, mostly the actual users not their bosses) 2. Questions (challenge assumptions / question why) 3. Acceptance Know when a requirement has been met
- 26. Soft skills
- 30. Questions Theme
- 31. Questions Don’t accept face valueAsk what and why Challenge assumptions Open and closed questions
- 32. Poor Questions What do you want ? Wishes Design Delight Expectations ≠ Delivered product
- 33. Good Questions What do you do ? Why ? Context ? Needs
- 35. Practice What do you want in your phone ? What is the biggest challenge with your phone and why ? In what context ?
- 36. Acceptance Theme
- 38. Practice
- 39. Conclusion
- 40. Users
- 41. Requirements
- 42. Coding
- 43. Summary •Requirements first •Relationships and understanding of user context •Needs not wishes (What you do and why not what you want). •Acceptance criteria
- 44. References • Fun Javascript history https://www.destroyallsoftware.com/talks/the-birth- and-death-of-javascript • Photos not otherwise attributed www.unsplash.com • House plan https://www.flickr.com/photos/fugue/116863933 • Why https://www.flickr.com/photos/ksayer/5614813544 • http://www.codemag.com/Article/0102061 • Design thinking requirements https://www.batimes.com/articles/minimize- risk-with-effective-requirements-gathering.html • Wishes VS needs https://www.d- labs.com/en/journal/wants__needs__requirements__asking_the_right_questi ons_in_user_research.html • Postit note https://www.flickr.com/photos/jogibaer2/5459043426 • Senior tablet user https://www.flickr.com/photos/jitze1942/ • Group work ideas http://www.liberatingstructures.com/2-impromptu- networking/ • Useful tools http://www.romanpichler.com/blog/10-tips-writing-good-user- stories/ • Detailed description of requirements gathering what and how https://www.slideshare.net/menameissa/business-requirements-gathering- and-analysis • Best practice example https://nuonline.mediaspace.kaltura.com/media/Requirements+Gathering+- +Example/1_f7e6g0w5
Editor's Notes
- BUT definitely less important than beer
- Requirements for pencils are important too.
- Seriously would it be easier to have fixed this during the planning phase or now ??
- Kia ora, koutou katoa Ko, Dorje McKinnon aho
- Who has a story of when they started coding first then did the requirements Back up Andrew was talking about his analytics business. They use a lean start up model …. White board and a web cam / SunGard
- An analogy might help
- Introduce yourself to your neibour and find out what enjoyed the most so far today ?
- If you don’t know Joel you’ll know his work
- Take aways
- OK up out of your seats. Introduce yourself you don’t know. Find out which of the three themes they think is most important and why it is important in their context
- Who with ?
- Stuart and Sarah
- Wishes that describe user’s idea of what the right solution is, so design is curtailed,
- Wishes that describe user’s idea of what the right solution is, so design is curtailed,
- Needs are the
- You all have a phone. Pick someone you haven’t talked to today. Introduce yourself, and ask the bad question What do you want in your phone ? Listen for one minute then ask What is the biggest challenge with your phone and why ? Find out the Context the problem occurs in.
- There are 3 big ones here : speed, you have tight deadlines so you assume. Which is the second one, Assumptions. And they mean that the third one Expectations are different. This is where if you’re working with needs and not wishes you’re set. If you deliver a wish, it will never be quite good enough.
- Topics Music Sport
- Requirements reduce risk, cost, time. Good requirements need you to have conversations with users, about what they do and why (not what they want) and you must have DEFINED ACCEPTANCE criteria
- Put users first
- The important point is that Users come first then do your requirements
- Finally and only after users and requirements do the coding
- Any questions