Users Can’t Know Their Requirements Early
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 effort.
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.