Geeks With Blogs
Chris Breisch   .NET Data Practices
Search this Blog!

There's an interesting post at Tyner Blain regarding Business Requirements.  Their piece is a follow-up piece to a piece by Robin Goldsmith.

I find both pieces fascinating because they deal with whats and hows, two items that I find myself constantly bringing up in our design meetings whether they're with the clients or not.

The difference between REAL business requirements and system requirements is not the level of detail. The difference is qualitative. Business requirements are whats. System requirements are design hows. Design doesn’t have to be technical. A product or system is a presumed solution how to accomplish the presumed whats. Whats do not decompose into hows. Hows are a response to whats.

Far too often we find ourselves creating and following requirements that aren't requirements at all, because they're whats and not hows.  If you're ever going to save yourself from scope creep, you have to design to the whats and not the hows.  As Robin points out, whats don't change very often.  Hows do.

In short, business requirements are the whats.  Product requirements are the hows.  Design to the business requirements.

Or, as our friends at Tyner Blain put it:

This is the interesting part - the more tightly (effectively, rationally) the product requirements are coupled to the business requirements, the less change we will have in project scope over time. However - the key is to define the scope in terms of the business requirements , not product requirements.

Posted on Tuesday, April 10, 2007 7:37 AM Architecture | Back to top

Comments on this post: Business Requirements -- The "REAL" Requirements

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Chris J. Breisch | Powered by: