I used to think of a requirement as a specification, a description of the thing to be built, written precisely enough that someone could build it. That definition is not wrong, but it is incomplete in a way that causes real problems.

The way I think about it now: a requirement is a record of a shared understanding. If the understanding is not actually shared, no amount of precision in the writing will save it.

I try to separate three things

  • The problem: what is actually going wrong, for whom, and why it matters.
  • The behaviour: what the system should do, described in terms of outcomes rather than screens.
  • The agreement: how we will know it is done, including the cases we deliberately decided not to handle.

When these get collapsed into one paragraph, you end up with a requirement that describes a solution and quietly hides the reasoning. Six weeks later someone asks why it works that way and nobody remembers.

Outcomes before screens

If I write "add a dropdown with these five options," I have made a design decision and disguised it as a requirement. If I write "the user needs to be able to indicate which category this belongs to, and the categories change a few times a year," I have described the actual constraint, and now the person building it can tell me that a dropdown is a bad idea if the list changes, which I might not have known.

The undefined case is the requirement

Most of the time, the interesting part of a requirement is not the main path. It is what happens when the thing is missing, duplicated, out of order, too large, submitted twice, or entered by someone who should not have access to it.

I have started treating "what happens if not?" as a reflex. Not to be difficult, but because those are the questions that surface real disagreement while it is still cheap.

Acceptance criteria are a conversation, not a checklist

Writing acceptance criteria forces a specific kind of honesty. You cannot write "the report should be fast" as a criterion. You have to say what fast means, and that question usually reveals that nobody had agreed on it. That discomfort is the point.

Requirements should be allowed to change

The version written before anyone has seen anything working is a hypothesis. Once people can actually use something, they understand their own problem better, and so do I. Treating that as scope creep rather than as new information is, I think, one of the easiest ways to build the wrong thing carefully.

What I try to protect is not the original wording. It is the reasoning: the record of why we decided what we decided, so that when it changes, we change it deliberately.