Thursday, July 31, 2014

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.