Why?
My 30-month old neighbor knows the most important question she could ever ask – “Why?” We all knew that question at that age. She knows how to use it, and so did we. “Why are you wearing sunglasses?” “Why is the sun out?” “Why does the earth spin around the sun?”
Why do we stop asking why? When we’re grown-ups, and toddlers ask “why?” for the hundred-thousandth time, why do we say “because I said so?” I’m not on a crusade to enlighten the toddlers of the world (ok, maybe on our street, but that’s not the point of this article).
Stop to think about the best people you work with – developers, project managers, CIOs, you’ll find a common pattern – they ask “why?” all the time. Somehow, they never stopped asking “why?”. Why?
“WHY?” is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.
A reader and made a comment about a previous post about requirements testability – he proposed that by rewriting the requirement, we may lose sight of the real requirement. This is really a risk that we lose the underlying “why?” of the requirement. There are ways to prevent this – keeping requirements synchronized with a product roadmap, repeatedly articulating the strategy, and just keeping your eye on the ball.
Another approach, the one we use, is to structure requirements in the context of goals. We document the goals for a product, we identify the use cases that are required to achieve the goals, and we document the functional requirements required to enable the use cases. Maintaining linkage, or tracability, between the requirements and the goals that they ultimately support is the key to not losing sight of the real requirements.
Asking “why?” can also help in requirement elicitation. “Why do we need 99.99% uptime instead of 99.9%?” “Why is it a requirement that the system work without an internet connection?” “Why is it important to the user to be able to save their work in progress?”
Why will we wait until a later post to talk about elicitation?
Latest Articles
Comments on all Articles
