The Regenerate Web

OK! So everyone who has had received requirements for a project that didn't "add up" please raise your hand.  What about requirements that were impossible to figure out if they add up without rewriting them from scratch?  What about requirements that primarily describe the current situation, and not the desired future state?  How about requirements that are written more as a functional specification (I need a report that has these data elements with this sorting grouping and formatting)?  

One of the things that use cases and user stories, try to convey rather than higher ceremony requirements documents, is a sense of what is real, and what is important.  I think that the problem is more one of context.  For large projects, and projects where the requester is moving into unfamiliar territory, the context is important.  

When we "do" software design, we start to model the business process, and how our solution will interact or integrate into the business process.  We define components, and we model interaction between those components.  Why on earth do we wait until we are designing software to do this?  Because our SDLC or Methodology told us to?  Horsepuckey!

Many projects fail on requirements because the analyst feels  or acts as if he or she must capture every level of detail before we can determine feasibility.  The truth is that at that level of detail, things are probably going to change before we get into production, anyway.  So if you start out with 9 months to do the project, you take 6 months to finish the requirements before you can START design, and then it is already to late.  All you can do is reduce scope if you want to meet the originally posited date.  In 3 months, you can't staff up fast enough and maintain traction so that you actually increase velocity sufficiently to make a difference.  I have done that project several times, and the math is now firmly embedded in my grey matter.

If you have already been there and done that, you should be asking what should we do instead?

Indeed!!!  I propose that requirements should be modeled - that is, understand the basic structures, and the axes along which requirements are likely to vary as time marches on, and let the design begin as early as possible.  Care for an example?  Thought you might.

As I develop requirements for a new system, I have many sets of business rules for various aspects of the system.  As a requirements modeler, rather than having to nail down every last rule, what I really need are the processes that rules apply to (rule sets).  For each rule set, I need the rule basis data (sets of data elements that the rules rely on).  For each rule set, I need to know the frequency of change over the last 2 years, and the axes (data elements) along which it tends to change.  I don't really care what the rules are, only how they are applied in the process, and the data that is used to drive them.  

Frequently, I have seen analysts punt, because the business model is changing, and they can't nail down the exact rules that will be in place.  It would be my strong contention that the rules won't be static after the software is live anyway, so design for rules to change.  

For people who have been doing business rules for a long time, this is probably very basic, but based on some the the requirements documents that I have seen, it is less widely understood than it should be.