not such a universal ordering, and there shouldn't be. For one thing, everyone's ordering priority might be very different. For another thing (and this is the most important reason of all), the ordering of the "ilities" should be project dependent. If you're building a system that is to be platform independent, then portability should leap to the top of the list. If you're building a system that you expect to keep around for a long time, then the two maintainability traits-modifiability and understandability-should move to the top of the list. If you're working on a hard real-time problem, where nanoseconds and/or memory space count a lot, then efficiency belongs at the top of your list. In fact, ordering the "ilities" at the beginning of a project is a vital, identifiable task-and one in which your customers/users must participate.
So there's my clarification about the definitions of quality. And, with this elaborated definition, I think I've covered the ground many of you suggested, such as the thought that quality should be project specific (my answer being that the elements of the definition don't change, but the ordering must).
Second, what do I believe quality is NOT? That's where I presented the following equation:
User satisfaction = Compliant Product + Good Quality + Delivery Within Budget/Schedule
No one seemed to disagree with this equation in their comments. The equation is nicely intuitive, and captures something I believe is extremely important about a lot of vital characteristics.
But notice what happens when you accept this equation. Quality stands alone, distinct from all the other entities mentioned in the equation. It's NOT the same as "user satisfaction." That's a much more complicated entity, for which good quality is only a subset. It's NOT the same as "compliant product" (meeting requirements)-that's clearly different from quality. It's NOT the same as "delivery within budget/schedule." I don't mean to diminish the importance of user satisfaction, or meeting requirements, or meeting estimation constraints. Those are all really important things. It's just that they are separable from, and rather importantly different from, quality.
And what about those of you who suggested that the topic of quality should be broadened? Here's how I feel about the suggestions readers made:
How about the thought that quality should be quantified? That's a tough one. My first answer would be "yes, of course it should." But how? If you, like me, believe that quality is a collection of "ilities," then it is those "ilities" that you must quantify. For some, it's easy-reliability and efficiency. For others, it's next to impossible-modifiability and understandability. Wishing and believing that quality should be quantified are not enough to make it so. Some elements are quantifiable, others are not.
What about those ways of enhancing quality, like "caring/concerned developers" and "good software process"? Good people and good process are both roads to good quality.
And finally, what about the role of documentation in all of this? There's no doubt in my mind that documentation is important. Especially user documentation, but also accurate and up-to-date maintenance documentation. But I think it is important that we separate software from its auxiliary features, such as documentation. Getting good documentation is important, and it is a matter of managerial will, as well as technical skill.
Normally, I hate to revisit old topics. But in this case, with all the intriguing comments readers came up with, I think it was valuable. I hope you'll agree.