Catch my recent Requirements.net podcast interview.
A while back I was involved in a discussion during which someone commented that because exceptions are really just alternatives to the main success path, then there’s really no need to bother distinguishing them from other alternatives to the main success path.
While I knew that idea didn’t feel quite right, and there must be a good (and probably simple) response, I didn’t have one at the tip of my tongue at the time. And I admit, it wasn’t a burning issue that kept me awake at night, so I never thought much about it afterward until I came across this description of why we differentiate between the two.
“Early on, the goal is not to be right, but rather to be wrong in interesting, illuminative ways. Oh, it’s nice to feel like a genius when you do get it right the first time; but that’s rare. Much more common is that you think that you got it right, because your customer nods and doesn’t say much, when what’s really happening is that he’s too busy and just wants this meeting to be over. So being “right” in your early Echoes can lead to a false sense of security; and trying too hard to be right right away is misplaced effort and worry. Be as correct as you can manage, but recognize the limitations of your current knowledge.”
Ever taken a “20 questions” approach to requirements elicitation? According to The Bitter Project Manager, there are good reasons for doing so. Querying the user/customer in 20 questions fashion helps to determine s/he wants by eliminating the things s/he doesn’t.
The idea of a “requirements workbench” is one that the guys over at Requirements.net have been consistently socializing over the past few months, and one that I have been following with interest.
Requirements.net has recently posted a Business Analyst Workbench Whitepaper and a Workbench Buyer’s Guide. To give the general gist of the workbench without stealing Req.net’s thunder, the workbench concept includes requirements management capabilities, but then goes beyond that to support the analyst through elicitation, elaboration and communication and validation activities.
I recently stumbled upon this video, got a kick out of it and thoughts I’d share. It is basically a video parody for the process of designing the stop sign if the project were kicked off in 2008. There have definitely been times in my career as a BA where I’ve felt like the poor chap trying to design to the customers’ specs.
Oh.. and for geeks like me who saw this and then wondered when we really did get the stop sign, here’s an interesting link.