In almost every requirements document, there's eventually an item whose origin no one can explain anymore. It sounds plausible. It was probably mentioned in a meeting at some point. And over time, no one thought to question it.
That's exactly the problem: plausibility is no substitute for a source.
Strictly speaking, a requirement that can't be traced back to a specific customer statement is an internal opinion formatted to look like a fact. It ends up shaping the product just like any genuine requirement, only without the evidence behind it.
The chain that rarely gets documented in full
There are several steps between a customer statement and a finished requirement. If only the outcome is documented, but not how you got there, the information you'll need most later disappears: why the requirement exists in the first place.
Every finished requirement should be traceable backward through this entire chain. Anyone questioning a requirement should be able to find the original customer statement behind it within a few minutes, not a vague memory of a conversation from three months ago.
Why this is more than documentation discipline
Traceability protects against three very different sources of error at the same time.
- The loudest individual voice: a strong statement from a single conversation remains an anecdote until it's supported by additional, independent sources.
- Internal wishful thinking: a requirement that no customer has ever actually raised, but that seems "obviously sensible" internally, becomes immediately visible when you check its traceability.
- Knowledge loss over time: if the team changes six months from now, you otherwise lose exactly the context that explains why a requirement was written the way it was.
MoSCoW as prioritization, not a popularity contest
Traceability alone isn't enough if everything still ends up looking equally urgent. MoSCoW prioritization, applied to voice-of-customer frequency rather than internal preference, creates a clear and defensible order of priorities.
Must
Without this requirement, the product isn't viable for the segment.
Should
High VoC frequency, but can be deferred for technical or timing reasons.
Could
Mentioned occasionally and useful, but not critical to the buying decision.
Won't
Deliberately excluded from this version, with the reasoning documented.
What matters is the link back to the first section: a requirement doesn't become a "Must" because someone made the strongest case for it internally. It becomes a "Must" because the underlying VoC analysis supports that priority.
A short example from the field
Eleven out of fourteen customer conversations independently mention the same manual step as a source of wasted time.
The raw statements are collected, categorized under "efficiency," and rated as high in both frequency and intensity. From there, a requirement is created with a clear acceptance criterion, a MoSCoW classification of "Must," and direct references to the eleven interview notes as its source.
Six months later, that requirement can still be explained in under a minute, regardless of who originally captured it.
Traceability isn't bureaucratic busywork. It's the most reliable way to distinguish a genuine customer requirement from a convincing-sounding internal opinion, especially when both end up looking equally credible on paper.