Digging for Requirements

I'm again going to refer heavily to The Pragmatic Programmer.  In fact, the title of this post is one of the sections in chapter 7.

Here the authors mention that the term 'requirements gathering' is misleading.  It somehow implies that the requirements already exist somewhere and just need to picked up.  Instead, they say requirements need to be dug for.

Users understand their workflow, but not in the same way that an engineer needs to understand it.  A user doesn't particularly care how much of his workflow is defined by the system architecture, company policy, laws of the country, industry standards, or even habit.

But an engineer cares.  He cares because some of those factors will change faster than others.  Some don't even need to be factors anymore.  So the system that he builds has to be flexible enough such that the more changeable factors can be accommodated easily.

It's important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it.  At the end of the day, your development has to solve their business problem, not just meet their stated requirements.

The above quote hits the nail on the head: the stated requirements are usually not the actual system requirements.  Hence there is a need to dig down into those stated requirements, find the real system requirements in there, and consider the rest as configuration options.

Here's the example the authors use.  Let's say a stated requirement is: "Only an employee's supervisors and the personnel department may view that employee's records."  It sounds reasonable enough, but it embeds company policy, which can change often.  Digging around that stated requirement reveals the actual system requirement: "An employee record can only be viewed by a nominated group of people."  Who comprise that group is simply a matter of configuration... the code doesn't care.

It's arrogant to say that an engineer understands a user workflow better than the user himself.  However, the engineer obviously must understand it from a system architecture perspective.  And since that is something users would never need to think about, stated requirements will almost always need some digging done.

Don't Think Outside the Box

Gordius, the King of Phrygia, once tied a knot that no one could untie. It was said that he who solved the riddle of the Gordian Knot would rule all of Asia. So along comes Alexander the Great, who chops the knot to bits with his sword. Just a little different interpretation of the requirements, that's all… and he did end up ruling most of Asia.

Such is the introduction to a truly insightful section of the book The Pragmatic Programmer.  The ideas presented in this section, like many great software engineering principles, expand beyond the realm of programming.

Programming in any existing language requires clarity of thought.  One significant component of that is the removal (or at least, verification of) assumptions.  This idea is equally applicable to any problem we might face in the "real world."  When trying to solve such a problem, assumptions can really be the enemy:

If the "box" is the boundary of constraints and conditions, then the trick is to find the box, which may be considerably larger than you think.

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you'll find your solution... 

It's not whether you think inside the box or outside the box.  The problem lies in finding the box - identifying the real constraints.

This really resonated with me.  When given a problem, we are almost never given the full set of real constraints.  Most constraints are assumed or imagined, leading us to believe we have a much smaller box.  This leads to potentially less effective (and certainly less innovative) solutions.

So what should we do?  The authors continue:

When faced with an intractable problem, enumerate all the possible avenues you have before you.  Don't dismiss anything, no matter how unusable or stupid it sounds.  

This isn't so ground-breaking.  It's basically the idea of "brainstorming" that we all learned in elementary school.  But the authors go a step further:

Now go through the list and explain why a certain path cannot be taken.  Are you sure?  Can you prove it?

This step is where I know I have failed in the past.  I can generate a list of fantastical ideas, but I know I have been too quick to prune some of the more outlandish ones.

I won't make that mistake again.