Don't ask where this has come from, just accept that it has come ;-)
The key to good software engineering is good requirements management, and this must come from both sides.
Poor customer requirements (no matter how aggressively chased by the software provider) will always lead to "to-ing and fro-ing" and exasperation on both sides, no matter how good the provider is.
I know of software providers who have been described as "useless", by one customer (who as an organisation never really knew what they wanted, or had any ability to express their desires in good, unambiguous requirements) and "excellent", by another customer (who had a very clearly documented set of requirements that had been fully agreed internally before issue)!
The image at the top of this Building Better Software blog summarizes the situation in some case quite well. It's easy to laugh at this image, but it's a real issue that people (who sometimes should know much better) sometimes really don't know what they need (they all know what they want!).
For example, I know of a project that required data from vehicles captured at 5 second intervals. No problem, easy in fact with the proliferation of CAN bus. But the vehicles were electric and the customer wanted to analyse how much energy was being recovered through regenerative braking, and basic application of the Nyquist Shannon theorem says that with a 5 second sample time only events of 10 seconds or greater duration could be reliably captured. So guess what? Next to no regenerative braking events were captured and the customer started trying to tell the vehicle manufacturer that the vehicles were faulty as they weren't performing regenerative braking as advertised. All because the customer didn't tell the software provider what they wanted to do with the data, just that they wanted data collected at a certain interval (the customer then went back to the software provider and requested free changes since it was "obvious" what they wanted to do with the data... but that's another story!).
Of course feature-creep is also a problem - adding kludges in an attempt to "make a tweak" to keep a customer happy will only lead to borked systems. Customers need to be quoted, and need to expect to have to pay if they want changes or increases to a system's capability so that the work can be correctly undertaken.
Finally, competing documentation "standards" can make things worse. From diagrammatic through to natural language (sometimes including metaphor and simile) lots of people have differing ideas on what makes "good requirements", and the gamut runs from UML, SysML, SDL through to RFC2119-based prose and "user stories". In fact this XKCD applies quite nicely.
