The Trouble with Requirements

“Daddy, would you get me some milk?”

It started innocently enough: a simple request from my four-year-old daughter for a glass of milk before bed. Even at this young age, she’s already a procrastinator and a night owl, so I know that I should do whatever it takes to expedite the process.

I delivered the milk.

“Daaaaddyyyyy, I wanted a pink cup. One of the new ones. And a straw.”

Slight pout. Arms crossed.

Parenting theories differ on what to do here. There are two routes to take, but only one involves tears (possibly mine), so I transferred the milk to the appropriate pink cup and maintained order in our little corner of the universe. Choose your battles, I say.

Now … what was I doing before all of that?

Up-Front Investment

I’ve been developing software long enough to know the perils of requirements — incomplete, absent or just plain bad — but I still get bitten by it on occasion. In the case of the milk, I didn’t do enough work up front to ensure that what I was delivering was what my “client” expected.

“What kind of cup would you like?”

“What color?”

“Would you like ice?”

A few simple, up-front questions would have saved a lot of time and frustration — not to mention cups — and the mental context-switching derailed the progress I was making on whatever task I was doing beforehand.

The same is true for software development: you’re asking for trouble if you dive into a project without really knowing what you’ve signed up for.

If Only it Were that Easy

Building software, of course, is a lot more complicated than serving a cup of milk, and the requirements for software grow along with the size and complexity of the project. You could be faced with weeks to months of meetings and conversations about what this thing is going to look like and how it’s going to work. No one likes that, but, at some level, it has to happen.

Even if you think you know what the client wants, the odds that you accurately interpreted what the client said are low. Some experts have said that projects can slip by as much as 400% due to misinterpreted verbal requirements. Furthermore, plenty of research has shown that the cost to fix a late-discovered defect is significantly higher than it would have been if you’d caught that issue during the discovery phase:

From Steve McConnell’s “Software Quality at Top Speed.”

Here’s why it’s hard

There are several flaws with software requirements and the way they are traditionally gathered.

The first is impatience. Everyone involved in the project — from the business owner to the technical team — is antsy to get started on his or her piece. Knowing you have something big to deliver, whether that’s three months out or three years, increases anxiety and causes team members to dread anything that isn’t directly producing tangible results.

The second flaw is the honeymoon problem. The planning and discovery phase of a project is the most collaborative, optimistic and fun, and it’s common for constraints to be lifted — or forgotten altogether — in favor of pie-in-the-sky ideation. Everything has been going incredibly smoothly, and no one wants to be Debbie Downer and reel everyone back to reality.

The third problem is futility: many business analysts and project managers will tell you that regardless of how much documentation they write, the developers won’t read it. That’s mostly true, in my experience, but it’s still a cop-out: developers can’t let themselves be ignorant, but we also need to make the documentation more easily digestible for the busy project team.

So, no one wants to document the requirements, and no one wants to read them. What do you do?

Spend Time Where it Matters

Good developers create and use modular components that can be quickly ported from one project to another. This doesn’t mean that you can’t or won’t customize a UI — you often will — but try to focus customization on the places where it really matters.

For example, nearly every authenticated web site needs some sort of password reset functionality. In the vast majority of cases, clients do not have a specific vision of how the password reset on their site will work, so they don’t enter into the project with any requirements in mind. This is a commodity feature — what the client wants most is a bug-free, industry-standard workflow that their users will find reliable, predictable and painless.

You don’t need to build that from scratch every time.

It’s in your best interest to have a suite of components that are ready to be integrated into any new project. It’s good for your development timelines, it’s good for quality control, and it’s good for the client. Moreover, it can save time at the beginning of a project by significantly reducing the volume of requirements that need to be gathered. Imagine starting the planning phase of a project with:

1. A list of what canned components you offer;
2. Documentation of existing features;
3. Working demos.

You would be able to get past the commodity features very quickly and move on to the pieces that really deserve the most discussion.

Of course, even a feature like password reset has opportunities for branding, so we expect to do a small amount of look-and-feel work on each implementation, but even if a client wants to make more significant tweaks to the workflow, we’re ahead of the game. We’ve established some working parameters and given context to any discussions that need to take place, and most of the code has already been written.

Do Less … More Often

Another great option for minimizing the pain of requirements is to work more iteratively, frequently delivering manageable chunks of the site. This approach is underscored by the growth of agile methodologies and concepts like just-in-time requirements definition. A few hours of requirements definition at the beginning of a sprint is much less daunting than a month of meetings at the beginning of the project (see the impatience problem, above).

Taking an agile approach allows requirements to be documented quickly, while they’re fresh in everyone’s mind and memories haven’t had much time to play the telephone game.

Sometimes, delivering a solid module with a subset of requirements has a powerful impact. The definition of “Minimum Viable Product” can change during the course of a project, and I’ve seen success in the past deferring more nebulous or aspirational features to a later sprint. Then, once the business owner sees a production-ready module, any remaining features can become less important, in favor of other modules that are, say, zero percent complete at that point: “You know what? Now that I see it, I think we can launch without [feature X]. I’d rather you move onto a different module that’s more important.”

Software is Service

It’s also important to remember — and I’m talking to you, developers — that fleshing out requirements is real, valuable work, and it matters not just to the end product but also to the client relationship. You’re being judged and evaluated at every step of the project, and it’s often by more emotional metrics. Are you providing exceptional value in every interaction?

Successful New York restaurateur Danny Meyer sums up the value of service well:

“Whoever you are, whatever business you’re running — we’ve all been commoditized …. The Internet has made it so that what we do really, really well — as soon as the word gets out, someone’s gonna copy how we do it, but the one thing that cannot be copied is how we make people feel.”

The trouble with a glass of milk is that it’s not always just a glass of milk, and the trouble with developing software is that it’s not just developing. When someone asks you to build a confirmation page, they’re really asking, “Can you help me craft the perfect confirmation page for my customers?” That’s not just a request for software — it’s a request for service. It’s a complete package, and we need to remember that.

Tonight I’ll get the milk right the first time.

A version of this was originally posted on goosetail.com.