Requirements Drive Design


I admit that it sounds trivial, and possibly “strawman argument”-esque to make a statement like “Requirements Drive Design” but the reality is that for most of the last twenty years, the bulk of my challenges have come from a very prevalent attitude among many I/T practitioners that the “design” of their systems should influence the way the requirements are reflected in a conceptual information model.

While the sequence of events “should” be:

  1. Determine Requirements (Note: This includes a DETAILED and exhaustive dictionary of key business terms that are to be implemented.  How else do you move an idea from one head into another and ensure that it is the same idea in head #2?)
  2. Design Solution
  3. Implement Solution
  4. Assess Results
  5. Identify Enhancements
  6. {go to step #1} …

The reality is, in most inherited legacy-system environments the developer’s approach is…

  1. Review requirements based on how much work/change/risk they will introduce to the current system
  2. Identify any requirements that point out gaps in understanding of the current system, categorize these as “unnecessary”, “ill-thought-out”, etc… and fight to leave these completely out of the discussion.  If pressed, characterize the other “side” as “not team players”, “stubborn”, “obsessed with unnecessary details”, etc…
  3. From the rest of the requirements, identify those that will require the most work / introduce the most change / or incur the most risk and fight to have these changes tabled.
    Handy phrases to attach to the targeted requirements to be dismissive of them:
    a) “Theoretically entertaining”
    b) “Ivory tower thinking”
    c) “Not based in the ‘real world'”
    d) “Too expensive” (don’t bother to really estimate cost vs benefits, the assertion is scary enough)
  4. Implement the easiest changes from a technological standpoint in order to show activity and “progress”, declare victory, have cake, take photos and ignore the growing murmur coming from the business as they order pitchforks and begin stockpiling materials for torches.

I don’t care what methodological “wrapper” you put around it… You can call it “Waterfall”.  You can call it “Agile”.  You can call it “Fred”.  But the FIRST thing you’d better do is figure out what the business needs and then be willing to figure out what your current environment is actually doing in order to identify the deltas between what is being done and what is desired.



Leave a Reply