Slides from my presentation on challenging requirements at Oredev 2010

1. Challenging
Requirements
Gojko Adzic
@gojkoadzic
http://gojko.net
gojko@gojko.com

4. ...agent Felix Leiter delivering a message to Bond
from M to watch Auric Goldfinger …
...In London, Bond learns that his true mission is
determining how Goldfinger transports gold
internationally....
...Bond escapes and witnesses Goldfinger's
meeting with US mafiosi, who have brought the
materials he needs for Operation Grand Slam...
...Turning to the bomb, Bond manages to force
the lock by hammering on it with a pair of gold
bars, but the mechanism inside baffles him....
an atomic specialist turns off a switch...
...Bond and Goldfinger struggle for the latter's
gold-plated revolver and accidentally shoot a
window.... Goldfinger is blown out of the cabin.

13. We want to show on statements the
reductions that weren't applied

14. Refuse solutions to
unknown problems:
understand what the real
problem is and solve that

15. We found this IP geolocation
service – let's use it to identify
where the customers are from

17. Refuse suggestions to
use a technology:
you know IT better than they do
(if not, why have they hired you?)

18. ““We want to give our affiliatesWe want to give our affiliates
real-time reports”real-time reports”

19. Don't rush into solving
the first problem they
give you:
keep asking “why” until you get
to the money

20. We have performance issues with
the counterparty hierarchy – fix it!

21. Know your
stakeholders:
who is going to use this
and why?

22. We want to send video to
mobile devices

23. Don't start with stories!
Start with a very high level
example of how people will use
the system

24. We want a 2.5 Mach fighter jetWe want a 2.5 Mach fighter jet

25. Great products come
from understanding the
real problem and whose
problem it is

26. Effect maps
• Why? What is the desired business change?
• Who are the people that can create desired
effects?
• What does the target group want, need,
should do?
• How should the product or operation be
designed to fulfil that?

28. Remember
• Share the responsibility for requirements
• Requirements shouldn't be taken at face value
• Refuse requirements in form of tasks
• Know your stakeholders
• Make a clear map from tasks to goals
• Start with high level examples
– Derive features and stories from that
– Communicate intent
– Focus on what, not on how

29. http://gojko.net
@gojkoadzic
http://specificationbyexample.com