Quality is something perceived by the users of a product.

Different types of users see different parts of a product and have different reasons for working with the product. Their differing motives for working with the product imply that they have different concerns about how they should use the product and therefore what they perceive as being a quality product.

Some types of users are,
* Data capture user
* Reporting user
* Administrator user
* Active monitoring and control user
* Developer
* Integrator
* Architect
* Sales and Marketing

(what else?)

Concerns of a data capture user are,
* Can effectively capture data
* Clean intuitive user interface for the not-so-bright (no offence intended)
* Suited to catching and verifying capture issues before committing the capture

Concerns of a developer are,
* Well structured code / easy to find issues
* Fair documentation with reasonably refactored code
* Well tested
* Component isolation or separation

Concerns of the integrator are,
* Good 3rd party documentation
* TechnicalNotes available for tricky topics
* Example usage/intergration code
* Protocols, schemas and sequences well documented
* Configuration sanity tests and faq available

Concerns of sales and marketing,
* Features and issues clearly identified
* Bugfree software, does what it does without crashing
* Slick GUI
* Access to a software expert

Concerns of an administrator,
* Well defined security target
* Defined configuration and issue resolution
* Performance analysis available
* Easy to administer
* Slick GUI not an issue

etc etc etc.

-- Tim

----

Now, one axis/concern is the availability of the material listed above.
The other concern is the quality of the material.

It's pointless having a technical note that is a brief summary of ideas and jotting of notes.
It is potentially easy to describe quality metrics for each individual artifact but quality goes further than this.
It's about producing those artifacts for all the right users.

-- Tim