Re: [IxDA] Simplifying Needs and Requirements Description

7 Sep 2010 - 7:46am
3 years ago
1 reply
823 reads
DrWex
2006

> /Do you have suggestions or ressources for an easy-to-apply-workflow for > establishing requirements and goals?/

I don't have a workflow, per se, but I have a rule I like to share. It's called the "Rocket-Propelled Hamster" rule, or RPH as my current boss likes to call it.

The story goes like this: Once upon a previous job I was working with the business team on a requirements document and came across the 'requirement' that "The system should index all saved emails." My response was that this sentence didn't belong in a requirements(*) document.

"Why not?" asked the product manager.

"Because," I replied, "What you care about is that the product return search query results quickly. You don't care if we use an index, a hash table, or rocket-propelled hamsters as long as we get the right results out fast enough. Now let's figure what 'fast enough' means..."

And thus was born the RPH rule: no requirements document shall contain sentences where the phrase "rocket-propelled hamsters" can be substituted without changing the meaning of the sentence.

Best of luck, --Alan

(*) There's an important difference between product requirements and what are sometimes called functional requirements. Mixing the two up is a major source of headache.

Comments

7 Sep 2010 - 9:29am
Paul Pinkney
2009

Nice!  Love the RPH rule.

As another perspective, I refer to this as the what-how rule.  That is, you tell me WHAT you need, and we'll provide options for HOW it can be done.  I like the addition of RPH as something concrete that you can present to clients, so that they know, if they give you too much "how", that is, limit your ability to do your job, some mutant RPH might be what you get, and as entertaining as that might be, it's probably not what you want.

Syndicate content Get the feed