Good requirements do good software

I have had a meeting with some guys from a major telecom.
We have provided them some software and they wanted some changes.
I was impressed. Really. It was the first time when I met somebody with a clear vision of WHAT they want. They gave us the demands. They said they didn't care how would we implement this as long as:
1. Works.
2. Works correctly.
3. Works fast.

I felt well to discuss with them as I felt that this is the way the software should be done. The client asks for something an imposes some restriction, but it will never tell you how to do your job.
Contrariwyse inside many companies specifications are hideous mix of what and how.
I have often seen specs that did not describe only the requirements and domain specific business rules but also contained big chuncks of pseudo implementations.
In my oppinion it is not a good practice to do this as it is dangerous from solution's point of view to mix this details in spec. The spec is somehow a contract between developer and client. If implementation details are bound into spec they should be present in the code. More than this the spec is crafted long before design documents so the decisions taken at spec level will heavily influence the design (generally in a bad way).