Writing requirements that don't lie
Vague requirements feel safe because they're hard to be wrong about. They're also where projects go to die.
Requirements are where a project's intentions get written down, and they're often written to sound reasonable rather than to be true. 'The system should be fast' or 'easy to use' feels like a requirement but commits to nothing — it's vague enough that nobody can be wrong, which means nobody can be right either.
Vague requirements defer the conflict
Fuzzy requirements don't prevent disagreement; they postpone it to the most expensive moment — after the thing is built. 'Fast' meant one thing to the writer and another to the builder, and you find out when it's done and someone's unhappy. The vagueness felt like agreement; it was deferred conflict.
Make them concrete and testable
A good requirement is specific enough that you can tell whether it's met. Not 'fast' but 'responds within a second.' Not 'easy' but 'a new user completes the task without help.' The discipline of making requirements testable forces the hard conversations early, when they're cheap.
If you can't test whether a requirement is met, it isn't a requirement. It's a hope you'll argue about later.