What’s wrong with the traditional approach to requirements definition and how a more proactive, collaborative, prototype and visualization driven approach generates better results.
I R E M E N T S A R E N ’ T G AT H E R E D • They don’t exist yet • People don’t know what they want until they see it • Some don’t know what they want until they see enough of “not it” • Your job is to help them understand what could be, not take orders http://bizarro.com/comics/february-7-2015/
full-contact sport” - J O H N E C K M A N https://www.thestar.com/sports/leafs/2013/05/13/toronto_maple_leafs_defenceman_jake_gardiner_goes_from_healthy_scratch_to_difference_maker_vs_boston_bruins_cox.html
O P T I O N S O P E N • Don’t get locked in to “over-specified” requirements • Differentiate between goals and tactics, make sure requests are aligned • Requirements will change (they should!) • Plan far enough in advance, (but no farther)
R AC T S • How can you do contracts in the absence of detailed requirements? • Discovery as a paid effort, based on high level definition • Scope to budget • BRD as a fetish object - gives us the impression of control (not the reality)