This is a golden rule that all project managers, developers and testers need to understand.
I’ve been thinking more about requirements. In the most recent two assessments I’ve
done, both organizations have been stuck on thinking they could define their requirements
before design and implementation.
IWBNI (It Would Be Nice If) users could know their requirements early. For small projects
(a couple of people, maybe a couple of months) it might even be possible to fully
know and define the requirements at the beginning of the project. But I contend it’s
not possible for users to fully know their requirements early for any substantive
The nature of software — ephemeral and malleable and not well understood by users
until the users see the artifacts — guarantees that as soon as a user sees the system,
the user will see the next step in the evolution of the requirements. (If any of you
want to help me rewrite that sentence, please do.)
Here’s an example. Fifteen years ago, I bought a light timer for the lights outside
the front door. We want the lights to come on when the sun goes down and go off when
we’re all in for the evening. It was an electro-mechanical clock timer switch and
worked for about ten years. About five years ago it started losing time and the ring
around the outside was harder and harder to use, to set the time properly. Finally,
I took Mark to Home Depot a couple of weekends ago and said, “Honey, it’s time for
a new switch.” I used the don’t-argue-with-the-wife voice, and Mark decided to give
in. He picked up a timer with an LCD display and put it in the cart. I picked it up
and said, “Oh, no, this has software in it. We don’t need something this complicated.”
We discussed it, and he used the don’t-argue-with-the-husband-who’s-going-to-install-it-for-you
voice, and I acceded. Well, when he’s right, he’s right. I love the timer. It knows
when sunset is, so the lights always come on at sunset. We don’t have to reprogram
it every week, or risk the kids coming home to a dark entryway.
I didn’t think I needed the extra features. In fact I was sure I didn’t need them.
It wasn’t until I saw how well the timer worked that I realized the extra features
were exactly what I wanted. I don’t want to have to reprogram
the timer every week during the winter. I don’t want to mess with it at all. But I
was sure no product could do what this timer did. But the “extra” features are now
part of what I require in a light timer.
I could have taken my own advice about requirements, and asked myself “What attributes
of the timer are important to me, as a user?” I would have answered: ease of programming,
fewer times of programming, programming override for those gray days. The first two
in my list are system attributes, not functionality. Users are notoriously ambiguous
about system attributes — not because they want to be, but because they literally
don’t know how they want the system to work. The override is partly functionality,
and partly an attribute of the system.
System attributes are the most important part of the requirements (some people call
these non-functional requirements), and they are the hardest to determine in advance.
One of the reasons agile methods work so well is that the user/customer sits with
the team and discusses the system attributes constantly. If you’re not using agile
methods, plan on iterating on requirements anyway. Especially plan on iterating through
the system attributes, and the product cost for those attributes. You won’t know your
requirements early, but you’ll learn them as you develop the system. And you’ll develop
a product people want to buy.