You Can’t Un-Gild the Lily: The Importance of Requirements

You Can’t Un-Gild the Lily: The Importance of Requirements

Look out! I’m going Biblical! If you’re undertaking a project without doing requirements, you are “…like a foolish man who built his house on the sand. The rain fell, and the floods came, and the winds blew and slammed against that house; and it fell–and great was its fall.*”

Requirements are the bedrock on which your project—or rather, the end result your project is to produce—is built. If they’re not done, and done well, your life is going to be a swirling storm of bad-surprise phone calls, labyrinthine email threads, last-minute meetings and hacked-off sponsors.

The title I picked for this entry (before I started writing it—oops) isn’t really correct. Sure, you can un-gild the lily—that’s a decrease in scope. You can gild it, too—that’s a scope increase. If you’ve got good requirements, you can look at what is changing and what the impacts will be with relative ease, since you’ve got them right there in front of you, more or less. You can also set the changes in an orderly way so the folks who are building your wondrous widget will be able to make the proper adjustments. (It goes without saying you’ll have a cool change control process in place, right?)

Even with this lovely requirements arrangement, scope changes are a somewhat of pain in the neck and shoulders. Without it… yikes! You end up in a situation like I did with the first software effort I ever managed, in which the requirements came in each day over the phone, directly from the client, to the programmers. The programmers were always frustrated and the client was always dissatisfied. (Don’t worry, I fixed it and they all lived happily ever after.)

I could go on with a lot of obvious stuff about how great requirements are, but you probably know most of that already, so let me throw out a few pithy propositions.

Business Analyst. Use a Business Analyst to create the requirements and don’t treat them like a note-taker or layout specialist. The BA is the person at the nexus of the requirements whirlwind, but doesn’t have an axe to grind for any particular faction of the team. A good one will be alert for anything that lacks sufficient detail, will raise a flag when anything seems to be left out and will actively solicit input from the silent introverts in the room to be sure their ideas aren’t missed. An even better BA will act as an Architect Lite and keep the discussion on the right technical track. Business Analysts are often gifted facilitators, too, and can drive requirements meetings to productive results.

Straw Man. Start with a straw man. If you, or whoever is responsible for the requirements, can kick things off with a diagram or a model of how the project should flow and/or how the end product should look, you’ll see much more activity from the requirements team. It doesn’t matter if your mock-up is entirely wrong; in fact, that might be the best of all possible worlds. People’s creativity is often awakened when they have something to cast stones at. As the team tears the straw man up and puts it back together again to show how things should really be done, the genuine requirements emerge. Few things are scarier than a blank slate you’ve got to fill with good ideas, so avoid putting the team through that by having something written down to start with.

Traceability. One should be able to trace the most granular technical requirement back to the higher-level tech requirements, to the architecture documents, to the business functionality requirements, to the marketing description (if there is one). This is important for two reasons. One, when the actual builder of a feature is down in the weeds, they can often benefit from a view of the larger context in which requirement # was written. Given the larger view, they can build the granular component more closely to spec. Two, in almost every project, someone eventually asks, “why in the heck did we do it that way?” Usually this person is someone is a senior position and it’s most pleasant to be able to show them, in an orderly way, why the fruit baskets were woven of bamboo fibers instead of sweetgrass. Many organizations use database systems to organize requirements for traceability—not a bad idea.

* Matthew 7:26-27, from the New American Standard Bible

No Comments

Post A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.