While it's true that requirements come from the stakeholders, often the stakeholders don't really have them, they don't know them, and when they think they know them, often those are not the "real requirements" but some proxies which may even need to be violated to get a good product - i.e. I may think that a significant requirement is to ensure that some thingamajig very reliable and has many redundant duplicates/backups, but a better solution is a design that removes that thingamajig at all.
The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I'm not talking about making the detailed spec, I'm talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.