Imperfect Requirements

Requirements are a map, not the territory.

Requirements are written by people, not by gods. Those people wite at different times, for different reasons, with different skills. They're are written by committees, in a hurry, without the information needed. They get stuck, and stay stuck while the world changes.

They're incomplete, inconsistent, ambiguous, untestable, misleading, limited, excessive, obscure.

But, sometimes, they're the only map of an unknown territory. Sometimes they're the cheapest and fastest way to understand a problem or its solution. Sometimes they're the only lever you've got to open a door. Sometimes, they're the only authority you can use to make yourself heard. Doesn't make them the Word of God.

Requirements are to be questioned, re-ordered, bent, combined and replaced. We do all these things as we learn about what we need to make and do.

At a different scale, requirements change as the world changes, and as our needs change. As we re-make the requirements, we'll need to remake our understanding and our solutions as well.

We prefer requirements to stay still. We may need them to stay still. We may need that so strongly that we act to prevent changes to our records of requirements. And that is, of course, to confuse the map with the territory once again.

Reacting to Change

How does your team, your organisation, react to changes to requirements?

• Does it keep requirements under change control? Does it do that to allow change to be communicated? To ensure that change is authorised? To control change? To prevent change?
• Does it keep requirements where they can be found? Who has access? How can people search? Are there several places?
• Does it label its requirements? Can requirements be separated? Can they be traced? Where are the labels used? Who uses the labels? How can people and systems spot when the requirement changes, but the label stays the same?
• Does it review its requirements? How does it do that judgment? Who owns a requirement? Who can ask for change, and who can make a change? How long does review take? Is an unreviewed requirement as 'good' as a reviewed one? Are all changes reviewed? Do reviews expire?
• How far does a change go? How does a requirement change affect the system that fulfils it, or the system that builds and maintains that system? How do budgets and resources change? How do the documents change? The advertising? The understanding in operations and the help desk? How do the tests change? How do SLAs change, and capacity planning? Do end-users get to find out?