A big part of the problem with defining and quantifying is a linguistic one, and it comes in two pieces:

1. the idea that the term "quality" represents is subjective, and therefore the word "quality" means different things to different people, and
2. we refer to "quality" as an attribute rather than a perception.

The first is pretty obvious, so I'm going to avoid getting into more detail on it (unless someone cares to have that conversation).

The second, though, is tricky. We often say that things "are quality" or "have quality" -- or even "are of the highest quality". Those phrasings suggest that most people think of quality as something bound explicitly to a product -- product X has more quality than product Y. This leads to attempts to quantify and thereby measure "quality" in such a way that is universal, so that numbers can be plugged into a spreadsheet and the "highest quality" product can be empirically chosen.

Unfortunately, quality is not an attribute of the product but an attribute of the observer. What we really mean when we say we want a high-quality product is that we want a product that has been designed to fit our perception of quality. This is important, so let me rephrase it in more practical terms: a quality product is a product that does what its customers want it to do.

When it becomes necessary to look at quality from a broader view -- that is, not with regard to a particular set of customers and their needs -- we neccessarily limit ourselves. This is, of course, useful. But, look at what we do: we define quality in terms of what the majority of people want products to do -- be consistent, not break, be affordable, be intiuitive, etc. We then apply processes, methods, and technology to assure that our products meet all of these common goals, and to ensure that any given product will meet the other (more specific) needs of a customer.

The problem in perception usually comes as a result of a phenomenon every developer is painfully aware of: most customers don't know what they want. As a result, producers who can anticipate their customers' needs and desires and incorporate them into a product will be percieved as higher-quality than those that only respond to the requests and specs provided by the customer. In other words, they key to quality is knowing what the customer wants even when they don't know they want it.

Of course, all of this means that "demonstrating the quality of a product" really is "convincing the customer that the product meets all their needs". The fact that I have a test suite demonstrates to my customer that I will be able to modify the product with a low risk of breaking things. This is a customer need: they need to be able to get new functions without breaking old ones.

Pretty much any rule that you can point to and say "quality software must have this" can be directly tied to a common need of the majority of customers. Standards compliance? Customers need interoperability and protection against vendor lock-in. Graceful degradation? Customers need to be sure that core functions operate in adverse situations. And so on.