When we talk about what something has to do, we sometimes answer with options of what it could do or opinions of what it should do.
A strong requirement describes the results you want without outlining how to get there.
A weak requirement might be written as: “A user is able to easily publish an article with one click of a button.” This simple sentence implies the interaction (one click), the interface (a button), and introduces an ambiguous measurement of quality (easily).
When we introduce implications and ambiguity into the process, we can unknowingly lock ourselves into decisions we don’t mean to make.
As an example, I once had a client ask for a “homepage made of buttons, not just text.” He had no idea that, to a web designer, a button is the way a user submits a form online. To my client, the word button meant he could change the content over time as his business changes.