I much prefer the "The stakeholders are happy with the results of their investment" definition rather than tying quality to requirements.

My experience is that humans seem to be notoriously and consistently bad at producing 'requirements'. 'Good requirements' should completely define the thing to be delivered...but it seems that we are not so insightful or complete in our understanding of what is needed to be able to make it truely 'complete.' There always seems to be 'things forgotten' or 'things misunderstood' by the requirements producers.

Hence it seems to be all too frequently that things that exactly match requirements are still not what the stakeholder, as chromatic noted, wanted. Though I have seen too many stakeholders reluctantly/begrudgingly decide (often, it seems to be in the interest of keeping cost and schedule to a minimum) that they're happy enough to go ahead and accept the product. I'd be hard pressed to consider such an outcome as having delivered a 'quality product.'

The weak (in my opinion) linkage between 'quality' and 'requirements' is one of the reasons that my teams have so much trouble delivering satisfactory systems even though we've thoroughly tested that every single requirement is proven to work. So we've gone to broader testing to try to ensure that what we've come to call 'essential services' (which are end-to-end functional capabilities/services as defined/requested by the stakeholders...somewhat similar to Use Cases) are provided correctly and consistent with what the stakeholder expects. It is one of the key elements of our movement towards defining 'quality': a stakeholder-expectations-centric strategy.