The Truth About Software Requirements

I am a computer programmer by profession. In my personal time, however, I am a computer programmer. The difference between the two: requirements (or the absence thereof).

In my industry, software requirements are considered a big deal by nearly all of my users, especially the paying kind. In the 5 years I’ve been working in this industry, I’ve learned five lessons that I’d like to share with my readership (yes, all 3 of you, not counting family).

Lesson 1: Requirements Change

Duh. Everyone knows this. If you’re a great computer programmer, you cope with it by writing flexible code and having a positive attitude. What people don’t know is that changing requirements are really just a symptom of a deeper problem, which I’ll cover later. The lesson here is that you must be flexible, but you already knew that. So, on to…

Lesson 2: Requirements are a Front

Software requirements exist for one reason: People are sick of crappy software. Several years ago, some well intending but misguided people set about to solve the “crappy software problem” by creating a process to control software development more closely with carefully crafted and well managed requirements. Who can blame them? If users knew how to write good software, they would do it themselves. They certainly wouldn’t pay some “socially awkward” person who yammers about closures and list comprehensions. But since they don’t know how to write software, they have to manage those who do. I’m referring here to “the paying kind” of users I mentioned before. I should point out that I’m not talking about shrinkwrap software here, but rather custom development projects with big price tags.

So what’s the front? The front is that the customer knows what he wants, and he desperately wants to communicate that to you, but he only has this crippled 1200 baud modem of a language called “requirements.” This puts you, the programmer, in interpreter mode. Your job is to find out what he really wants and translate that into a usable product. This leads me to…

Lesson 3: You, The Programmer, Must Control the Requirements

Because great programmers recognize their role as an interpreter, translating requirements into what the customer really wants, and translating that into code, you have to be in charge of the requirements. This means that once in a while, you have to go out on a limb and say things like, “Mighty customer, sir, your requirements document says A, but I think you might like B better.” Sometimes you might even have to implement and demonstrate the feature to him first. This is a risky place to be, but it’s where you have to go if your software project is to be successful. This means you actually have to think about what the customer is asking for. Yes, great programmers don’t just translate requirements into code, they go behind the requirements and they control the requirements by gently nudging them in the direction that the customer really needs.

This means you’ll be wrong sometimes. That’s the price you pay to have a successful software project. If you find that you are wrong too often, you probably don’t understand your customer well enough, and some homework is in order. Stop controlling the requirements until you understand your customer fully.

By the way, very few programmers can do this right all the time. I only know a few, and I’m not one of them yet. Most programmers will simply translate requirements into code, and then get very upset when their product is thrown away or rejected by the customer (even if it “satisfies” the requirements”). This is all too often the case because the requirements were bogus in the first place. Truly great programmers, on the other hand, will not only satisfy their customers, but will exceed expectations by delivering a product that gives the customer something they didn’t even know they needed (pay attention managers: that means more revenue), but now can’t live without.

Let’s take an example from the shrinkwrap world: A couple years ago, no one would have thought they needed a $500 cell phone, but now millions of people just have to have one. Why? Because Apple figured out what people really wanted, before people even asked for it. Do you think some Apple customer handed Steve Jobs a requirements document to build the iPhone? Yeah right.

Lesson 4: The Only Real Requirement

In the end, there is only one real requirement, and it’s quite simple: The customer should get what he wants, and also what he needs. Sometimes you, the programmer, have to help the customer realize that what he wants is not what he really needs, or that what he needs is above and beyond what he wants. This takes people skills. Some customers even want something that is totally at odds with what they need. These people are rare in my experience. You may have noticed that I used the word “gentle” above. That is for these customers.

You have to go behind the requirements to figure out the real needs of your customer. If you don’t, you will fail, even if you follow the requirements to the letter. I should say: Especially if you follow the requirements to the letter. In my experience, implementing the requirements is about 30% of the total effort on a software project. The other 70% is spent discovering and implementing the things that the customer really needs.

Lesson 5: Good Requirements Can’t Replace Good Programmers

Some people seem to think that if you write your requirements well enough, you can afford sub-par programmers. This is simply not true. I don’t care how good your requirements are. I don’t care how much work you did to make them perfect. If you hand them over to crappy programmers, your project will fail. Period.

The only way to run a successful software project is to employ the best people. Never think that if you apply enough rigorous process and manage requirements well enough that you can compensate for having crappy programmers on your project. Nothing can compensate for crappy programmers.

Remember what I said about 30% vs 70%? Good programmers make up the 70%, even if you have perfect requirements (hint: you don’t have perfect requirements).

Happy Coding!

Now that you know what I know, get out there and find out what your customers really want! Oh, and don’t expect to find the answer by just asking, “Hey, what do you really want?”

Good luck!

P.S. I mentioned a “deeper problem” in my first section. Did you figure out what it is? I hope so.

4 comments to “The Truth About Software Requirements”

You can leave a reply or Trackback this post.
  1. I agree with everything you said, except that bit about “nobody ever asked for” a better phone. Nobody with power or gobs of money, maybe. I know more than a few people who would have been happy to ask for an improved phone if they knew anyone who would listen, and some probably even tried. Now they probably wouldn’t have asked for an iPhone exactly, but something that was an improvement. Maybe more of an improvement than even the iPhone, maybe less.

    I think it’s important to realize that, when dealing with people that have a personal interest in the product anyway (corporations may be a different story), people *are* willing and eager to tell you what they really want. Requirements is a bad way to do it, and no fun for either end, but they go through the pain because they so want you to understand what they want. If you can build the trust that you are “getting” what they are trying to say, in spite of their lack of vocabulary, theory, etc., and if you really can understand what they’re getting at, then you will be poised to work “miracles”.

  2. Hans,

    Good points. Let me respond to the bit you disagreed with. :)

    My point is not that “nobody every asked for” a better phone. I personally complain about my cell phone all the time. My point is that, even though people were dissatisfied with their current phones, no one created a set of requirements for a better phone, at least not to the degree that Apple did with the iPhone.

    Now, I’m willing to grant that maybe, just maybe, people did come up with a list of what would make an awesome phone. Even if that’s true, there’s no way they came up with a list as exhaustive as the iPhone’s, and they certainly didn’t write requirements for the nifty zoom and fade effects of the user interface.

    This debate is somewhat irrelevant anyway because my article wasn’t talking about shrinkwarp products (with this one exception), but rather custom software development. My point was to simply say that Apple didn’t create the “world’s coolest phone” by taking requirements from customers and simply implementing them.


  3. Dave,

    I am a software developer myself (10+ years) and I have worked at Fortune 100 companies (Intel & Grainger) and now independently provide software services to clients. I have worked with developers that have earned prestigious awards like Honeywell’s software engineer of the year award and also have worked with individuals who couldn’t write descent code to save their life yet, somehow ended up in management.
    I state all of that just to say I completely agree with you, from an informed perspective. I use to be very frustrated working on million dollar projects that were so loaded with requirements, that no one ever took a good look at the problem, instead they only wanted to “meet” requirements. We have all used programs that may be able to accomplish the objective, but it certainly wasn’t intuitive or easy to use. Many times you have to stop the customer from designing the solution and instead have the developers take a good look at the problem. This is where many people go wrong. In best case scenarios I actually like to do the job of the client and then design the software around that experience. Many customers don’t know how or what technology can do for them, they simply get a glimpse of a possible solution then try to pigeon hole you into developing that solution. I do know how companies get into “tech specs” and “requirement docs” and love to use the “hit by a truck” analogy. I have seen so much time spent in these phases, it has really helped me understand how the government can spend 100K on a 10 cent screw.
    As far as the iPhone goes, cover your ears my mac friends, Apple has missed some key features where a good requirements doc could have helped out. Not making the phone 3G was a huge drawback for me, in fact I use the internet so much, that alone would keep me from buying the phone. Another drawback is the battery being soldered to the motherboard. Everyone knows batteries go bad, and it would be nice if you could simply replace the battery like in most cell phones. With all that being said, yes, the iPhone has certainly done some amazing things that has caught everyone’s attention.

    Back to looking at RC plane stuff for me!


  4. I just remembered a great Joel Spolsky article called “The Iceberg Secret” that may have subconsciously inspired this whole article. Here it is:

    Great Quote: Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.