The big, bad, requirements bat..

I ran across this today...revisited James Bach's blog to see if it'd been updated in the last 3 months (it had). (hmm...yet another reason to get with the program and do that rss thing..) Anyway, that linked to this.

It made me think. The article itself was thought provoking, but one of the comments really nailed it (for me.)

Once we begin to start telling the client what their performance is, what is should be, and how they can get there we will earn the title of value-added. When we look to them, seemingly qualified to provide this information, yet rarely capable, we enter into the same old pattern of validating assumptions.

This is a pattern I've found myself in more than once. Insisting (because, you know, it's QA dogma) that the client give you "The Requirements." Like they actually have a black, leather bound volume of sacred performance goals that, if you pry hard enough, you can get a peek at. Yet it's pretty widely accepted (ok, it's accepted by me) that folks often don't really know what they want until you show them. Do I really believe the client has deep understanding of the technical tradeoffs, (not likely) and is an expert in project management, having the experience to weigh the project tradeoffs. (cost, time, quality)

At some gut level, I've always been uneasy with this. (then again, perhaps t'was Grandma's goulosh for lunch..) It feels like that while the customer needs to tell us what they think they need/want, it's up to us (us being QA folks, business analysts, what have you) to draw out their ideas and objectives into a cohesive picture of what they really want.

(after all, we're the ones with experience in UI design, tiered performance tuning, and hardware cost/benefit characteristics, right?)

I don't know. It's sooooo tempting (read: easy) when considering "performance requirements" to simply write something like:
The UI must respond in 15 seconds to all user requests. "

Get the customer to sign off on that, and then beat the developers over the head with it when Windows 98 over a 28.8 modem link doesn't meet the standard.

But that really accomplishes nothing.

(and it annoys the developers)

Hmf. I don't have a good answer. The truth is out there...and is somewhere in between the extreme of CYA requirements-in-detail. (necessary for the space shuttle) and 100% seat-of-the-pants ad-hoc testing that's oh-so-agile (not really) but leaves test holes the size of battleships.

(what? Oh...no, we never thought to test that feature... I was busy making sure the UI resized properly when the color scheme changed..)

There is never a cut-and-dry answer.

Perhaps an adaptation of the serenity prayer is in order.

"PM, grant me the serenity to accept the limitations in my testing, the courage to push test boundaries, and the wisdom to know when do do which."

Amen.