This site supports you in defining specific quality requirements for your system.

To make the best use, you should become familiar with our terminology.

Our Domain Language

Let’s explain some terms:

Term	Explanation
Property	Our 8 top-level properties (#flexible, #efficient, #reliable etc.). Find the full list plus the mapping to qualities here. These terms are highly abstract, and will be interpreted individually by different stakeholders. They can be used as starting points, but need to be detailed. Q42 maps these properties to 10-30 different specific qualities.
Specific Quality	The detailed and specific terms, like accessibility, accountability, accuracy etc. Currently, Q42 collects more than 100 such terms under Qualities by Name. These terms are usually well-defined, but need examples or acceptance criteria to really help in developing systems. Q42 contains examples for many (hopefully all, at some day in the future)
Stakeholder	People, roles or organizations that need, want or require certain quality requirements for their systems.
Examples	These are the specific requirements stakeholders have for a system or product, often expressed in the form of quality scenarios. They should facilitate stakeholder communication by enabling a common understanding of the good enough. Q42 provides >50 of these examples
Acceptance criterion	What does good enough mean with respect to a specific quality.

Three Dimensions of Quality

Dimension 1: Properties/Qualities

What property (like availability, latency, speed or maintainability) is relevant. On this site, we use the color blue to denote qualities.

Dimension 2: Acceptance Criteria

What amount, size or extent of any property (like 99% availability...). We use the colour green for these criteria or examples.

Dimension 3: Stakeholder

For whom or what roles/organizations is this quality/property relevant?

How to Use Q42

You can approach in several ways:

1. Inside-out, starting with the eight top-level properties
2. Outside-in, by reading through the extensive list of qualities.
3. By asking your stakeholders for terms (either properties or specific qualities) they consider important, and then continue with steps 1 or 2.
4. By reading the examples of quality requirements.

All these approaches are described below.

Inside-Out, starting with Q42 Quality Properties

Let’s assume that your stakeholders want a “flexible” system. This is completely unsuitable as a requirement because it is too unspecific.

You could search under the term “#flexible” (to be found under “Quality Properties”). There you find a collection of related terms (“Qualities tagged with #flexible”), and also a collection of exemplary quality requirements of this generic term.

Outside-In

The other way round is viable, too: In case your stakeholders have specific requirements, like “compliance”: Just start with the (extensive!) list of qualities.

Again, you will find related qualities and examples on the detail-pages

Start with Examples

The third option starts with the examples of quality requirements. These are automatically mapped to the properties and low-level qualities.