Three Reasons for Writing Effective Business Requirements

The Truth about Developers

Speaking as an old developer, I can authoritatively state that developers do not deal well with ambiguity. The reason is very simple. We cannot code ambiguity. The beauty of bits is that they do not waffle. If my program says the sales tax is 5.6% instead of the legally mandated 6.5%, the math works just fine every time. That does not necessarily mean that the outcome is satisfactory. Matter of fact, there are probably a whole slew of business managers, accountants, government agencies, and tax attorneys who might maintain that the law ought to take precedence over my program. The problem is, they cannot change my program. I can.

Developers and Real People

A second trait of developer-minded individuals like me is that we don’t deal particularly well with people. That is presumably because they (humans) are not as predictable as my other friends and allies (computers). For instance, the computer does not randomly select the aforementioned sales tax rate (unless I programmed it to do so). Every time I ask it, it will reliably respond with the same number. Computers are notoriously stubborn, bur very consistently so.

Developers and the Geek Syndrome

Thirdly, developers like me tend to be geeks. What does that imply? In his book “The Inmates are Running the Asylum” (which is required reading for anyone who wants to communicate with a developer — see side column reading recommendations), Alan Cooper observes, “A geek would rather be right than rich”.  (A trait which, my tax accountant, my banker, my spouse and all of my business partners can testify is true and apparently unchangeable.)  This basically means that, once I have understood a requirement, other interpretations might be possible, but mine is the only right one.

The Combinatorial Explosion

Taken individually, these three traits (I do not deal well with ambiguity, I do not deal well with people, and I would rather be right than rich) might be simply irritating. Together, they are a sure-fire recipe for conflict. What they really mean is that if you give me a requirement that contains any ambiguity, I will resolve it to get my code written. Given that I do not deal well with people, I certainly am not going to ask them any questions. I do not want to give them cause to think that I am ignorant. Besides, I know that I’m smart enough to figure out what they meant without bugging them with silly questions.

So How Bad Can It Really Be?

Of course, once I have figured it out, rule three applies: I am a geek, ergo I am obviously right. And don’t you non-geeks come trying to tell me that I’m not because I can explain to you in excruciating detail (I live for minutia) why I’m right. I don’t care what you meant when you stated the requirement, the only thing that is important is what I understood when I read it. After all, that is what is coded and computers don’t lie.

The Final Analysis

The irrefutable consequence of this set of circumstances is this: if you want to get a solution that meets your needs, get your needs figured out first. If you need help with that, talk to your analyst (business, system, or other). I do not have time to help you with that; I am too busy writing code. You will get a solution that works for you if you give me a clear, concise, unambiguous set of business requirements that I can only interpret one way. If my way is your way, too, this just might be the beginning of a wonderful friendship.

Remember, requirements rule!

Editor’s Note

As a side note, our self-paced series entitled “Writing Effective Requirements for IT Projects” tackles this problem head-on. The series is broken into short, audience-focused “knowledge nuggets” that teach only those steps in the requirements definition process that each particular audience needs to be able to do effectively.

You might also want to note that we have now scheduled a number of free webcasts for which you can register by clicking on the title in the sidebar. These 1-hour programs are designed to give the participant an idea of what we offer and how we offer it as a series of virtual workshops. The webcasts are not workshops in the truest sense of the word since they do not have a thundering herd of interactive exercises (which our virtual workshops do have), but they should give you a good idea of what each of our virtual workshop series is all about. We look forward to greeting you there.

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "Eight Roles Responsible for Business Requirements"