Requirements Development

Scott Berkun has an interesting post on requirements, and why they’re problemmatic. He says that “data collection” isn’t the issue. I agree with that. He also refers to “requirements gathering” (to me, not so good) and “requirements definition” (a little better, perhaps).

I like to think of this whole business not as requirements gathering, but as requirements development. (I credit Ian Heppell for pointing this out to me, but I believe that Karl Wiegers has said something along the same lines.) Some people think and write as though requirements are there to be gathered, like pretty stones or ripe blueberries in more-or-less plain sight. That’s often true of desires; they’re often visible right on the surface. But many requirements aren’t obvious from the start until we’ve learned more about what we’re developing, about what’s feasible and what’s unachievable. Testing often reveals new information that informs new thinking about what is required. In just about every case, some stakeholders’ desires will conflict. That’s why requirements must be discovered, revealed, prioritized, negotiated, and decided as the project continues.

Scott suggests giving authority over requirements to one person per major area. Even then, there’s a good chance that some requirements will conflict when they involve several major areas. As much as I’m a fan of collaboration, delegation, and self-organizing teams, at a certain point somebody’s signing the cheques. For good or ill, that will be the person to decide (or to delegate the decision to some other person) on what is a real requirement and what isn’t.

There was another interesting aspect to the post. In the comments, PSJ provides an example of a common problem. He (she?) says “Certainly being given some control and ownership over the requirements document would have made my life easier in the past.”

Now, you might think that the problem here is lack of control—and I’d agree, but I see another problem: Note how easily “requirements document” and “requirements” seem to slip into one another.

With respect, I’d suggest that someone (perhaps PSJ him/herself, but certainly the person who owns the project) needs control and ownership over the requirements, not merely the requirements document. The map is not the territory.