Requirements Is A Word That Needs To Go Away

Every time I hear the word requirements these days, I always think of the scene in 12 Years A Slave where they were told how much they had to pick that day to avoid being beaten. I don't know why exactly, but that word drives me nuts.

As a software team, our job is to find out what the customer needs, not what they ask for up front. One of my first lessons as a programmer in 1981 was that people ask for all sorts of stuff, but if you just implement that, they never like what they get. What they actually need is something you only learn over time, usually by showing them stuff along the way and getting feedback.

Requirements is a word that usually results in some detailed list of things you must do, often delivered and "signed-off" on up front. In all of my experience in enterprise companies (both working there and as a consultant) this is usual practice both for in-house development and for working with external development. People do this out of fear that if everything isn't listed in excruciating detail, they will be ripped off.

I remember once arguing with someone who insisted on writing requirements with the word "shall" everywhere, like some kind of legal document.

This is totally incompatible with an agile mentality. You'd think it was obvious to everyone by now but there are many places where this is still general practice, even if they claim to be agile. Requirements documents and sign-offs give people comfort, as if putting something on paper will make everything come out fine.

A financial services company I worked at used requirements as a hammer, they hated doing any work for "the business" so they built a requirements process that required 15 separate steps including documents, meetings and sign-offs to "nail down the requirements". Needly to say no one ever asked them for anything after that.

Another place I worked had a simple project that I estimated as being about two weeks worth of coding for one person. Six months later the requirements document was 120 pages long and was still incomplete. I left soon thereafter so I never found out if they ever finished it.

The worst thing is when people insist on putting everything in a document up front, demanding an exact estimate, and then constantly changing everything anyway and refusing to pay more. It's also bad when you deliver exactly what they asked for and they hate it.

I like to think of figuring out what the customer or user needs as a discovery process, like a defense attorney trying to understand what the prosecution is doing. You have to ask a lot of questions, learn what the system or process or whatever you are trying to build software for does.

A friend of mine worked at a large company that decided to build a new processing system for everyone to use to replace the existing one. So the developers proceeded to have meetings with managers and VPs to determine what they wanted, spent a year building it, and then rolled it out to all the workers. Of course it was horrible, both to use and it also failed to perform all the required functions, as no one had ever thought to ask the workers themselves. In the end it took a year of updates to the new system before the old one could be retired, making everyone's job doubly harder.

I had a much different experience building something like this at a local travel company around 2000. Their corporate air pricing group was operating on faxed word documents from the travel agencies they worked with, and their analysts would program the reservation system based on the details. There was no audit trail, and no easy way for the agents to know the status of the work. The company's IT group wasn't interested in the group, so they went outside and hired my employer, and me and one other guy got to work on this.

It was apparent that they really had no idea what to even ask for or what could be done, so we spent time explaining what we might be able to do. We also spent days sitting with the analysts to learn what they did all day. After that we started to build prototypes of what we though might be useful, and met most days with them to explain what we were proposing. They started to see what could be useful and began to make suggestions themselves. This continued for most of the six months we worked on this until we had 100 agencies running the system in beta. It had an external system for the agencies to use to enter all the data, a workflow system for the analysts and their managers to manage the work, and an audit trail to track everything that was done. Everyone liked how it worked, even the IT group got involved and wanted to build a login page. Of course they now had to have tons of meetings to decide on how to do it and it took six months, giving us time to build version 2!

In the end the company saved money, their customers were happy, and the system worked well until it was fully automated two years later (which sadly cost the analysts their jobs).

Of course every project can't end perfectly, but it was fun to be able to teach people what was possible and have them learn what they could ask for. The key was understanding what they did and support the discovery of what they needed. The end result was something that everyone liked. If we had been forced to sign off on something up front I doubt it would have ever been as good, plus by doing it in this clearly iterative (freeform) fashion we did the project with only two people since there was little overhead time wasted. I still think it was one of the most fun projects I ever did.

Getting requirements up front is like planning a route through mountains you have no map for: usually you wind up falling off a cliff or drowning in a river. It's helpful to have some basic idea when you start but it's easier to see what's right in front of you and use that to guide yourself to the end. Experienced trail scouts can follow a trail of an animal or person just by being aware of the little details around them, letting those details lead them along. If all you do is look at the horizon, you usually step in the crap in front of you.

In the end the only thing that will make people happy when you build some software, is if it meets their needs. Of course who gets happy is a good question sometimes, you might build something that the CEO thinks is great but the actual users hate. I wish that never happened but in many places pleasing the CEO is more important than making something that works; a sad fact of life in this industry.

One of my favorite sayings is "People don't know what they want until they see it." If you can give them enough to see before you spend too much time you can usually wind up building something that succeeds. If you don't show them stuff continuously and get feedback and respond quickly to that feedback, you run the risk of not capturing their real needs.

I'm sure requirements isn't going anywhere no matter how much I hate that word. Yet I really hope to work with more people who would rather work a little bit on figuring out what they need. It's much more rewarding to have happy customers than argue about change requests!