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

1. Requirements are important

2. Pencil
requirements

3. Toilet
requirements

4. Java Script
requirements

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

27. Relationships
Questions
Acceptance
Mine or
yours ?

28. Relationship
Theme

29. Relationship
Theme

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

34. Wishes
Wishes and
needs
Needs
Design
Delight
Expectations

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

37. Acceptance
challenges

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