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:
|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 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 extend 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:
- Inside-out, starting with the eight top-level properties
- Outside-in, by reading through the extensive list of qualities.
- By asking your stakeholders for terms (either properties or specific qualities) they consider important, and then continue with steps 1 or 2.
- 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.
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.