#IWDev 11 - Requirements Gathering

How to maximise the bang-for-your-buck we gathering requirements.

Transcript

1. Matt Ball, #iwdev 11 Requirements Gathering Getting the most ! for your $ Tuesday, 7 May 13
2. I’ve said it (here) before Building software is easy Tuesday, 7 May 13
3. ...and this as well But it can be hard to figure what you’re building Tuesday, 7 May 13
4. In fact Many people agree with this Tuesday, 7 May 13
5. Enough already! No more power phrases, please. (but lets keep the pictures going, yeah?) Tuesday, 7 May 13
6. So why is it so difficult? Requirements Gathering is hard Not enough time Stakeholder uncertainty Communication problems Tuesday, 7 May 13
7. Before all of that though, let me introduce you to... Tuesday, 7 May 13
8. The four gnomes Gnome Gnomes Gnome Ungnomes Ungnome Gnomes Ungnome Ungnomes Tuesday, 7 May 13
9. But wait! What is a good requirement anyway? Will deliver measurable value Will identify any and all stakeholders Will be testable Seen it elsewhere? Copy it. Tuesday, 7 May 13
10. Not enough time Problems: Time is money. Full requirements and specification takes lots of it. Tuesday, 7 May 13
11. Not enough time Solutions: Take an Agile approach to requirements: Keep them lean Pictures User stories Examples Tuesday, 7 May 13
12. Stakeholder uncertainty Problems: User wants v.s. Business needs Broken processes (don’t need I.T. bandages) Tuesday, 7 May 13
13. Stakeholder uncertainty Solutions: Ask questions Why do they want it? Is it even an I.T. problem? Tuesday, 7 May 13
14. Communication problems Problems: Developers think implementation Testers think edge-cases Stakeholders think £££ Tuesday, 7 May 13
15. Communication problems Solutions: Speak plain english (or whatever...) Review documentation, always User stories Examples Tuesday, 7 May 13
16. !$ Maximize bang for your buck What if they were all just 1 task? Requirements Conversation Documentation Testing Tuesday, 7 May 13
17. Gherkins! You knew they were coming, am I right? Tuesday, 7 May 13
18. BDD Behavior Driven Development: Developers, Stakeholders, Testers - in fact anyone! Conversations and questions. Documentation in plain language we can all understand. Tuesday, 7 May 13
19. BDD Documentation: Features and user stories Scenarios and examples Concise and lean Tuesday, 7 May 13
20. BDD Testability: Automated tests Validates correctness Validates value If you cannot write a test for a requirement - you don’t understand it, or it isn’t one. Tuesday, 7 May 13
21. BDD Unseen benefits: Understanding, requirements, documentation and tests are always in line with each other. Fragile tests indicate problems with a requirement. Transparency - for everyone. Tuesday, 7 May 13
22. Reading Tuesday, 7 May 13