The arc42 quality model Q42 (pronounced “Kju-Fortytwo” or “Kju-Four-Two”) is a simple, pragmatic yet effective approach to product and system quality. It starts with stakeholders’ expectations and requirements.
Based upon typical stakeholder needs, Q42 consists of just 8 key system properties, which are sufficient to cover most, if not all, required, desirable or expected of the more than 100 traditional qualities.
But let’s start at the beginning:
Goals for Q42
- minimal, yet covering most of the traditional product and system quality properties
- simple and understandable explanations of our top-level properties
- supported by extensive and free (online) documentation
- free and open-source, maintained in a public repository
- technology- and vendor-neutral
- agnostic to development methods
Fresh Approach
Existing models like ISO-25010 propagated a fixed hierarchy (like a tree) of system qualities. Within this tree, it is often difficult or impossible to determine to which of the top-level characteristics a particular and specific quality requirement belongs. Therefore, Q42 breaks new ground by proposing only 8 adjectives (like flexible) as core quality properties.
It uses adjectives instead of nouns (like flexibility), which better reflects stakeholder expectations like “I need XYZ to be flexible”. These core properties (like reliable, flexible, usable, efficient etc) are used like labels or tags: Specific quality requirements might have several of such labels or tags.
It has been unclear to me for years that those responsible for ISO and other quality models write about “quality attributes”, but fail to use that type of words in their respective models. But that is a minor thing, despite being immediately visible.
To facilitate stakeholder communication and understanding, Q42 contains definitions and explanations for more than 100 different traditional system or product qualities, all labelled or tagged with one or several of the 8 key properties.
Example Quality Requirements
Q42 contains numerous (currently 101) examples for specific quality requirements. You can use these examples as a starting point to find and describe quality requirements for your own system.
Hyperlinks as Best-Friends
All terms and example-requirements are cross-referenced (hyperlinked). That enables different access patterns to this website:
- Start with the eight fundamental and generic properties, and dive into details from these.
- Start with any specific quality, and navigate to the appropriate example(s) from there. Look through the extensive list of 158 of these specific qualities.
- Start with asking your stakeholders for their generic or specific requirements - and then continue with 1. or 2.
- Finally, you might read through the list of example requirements.
Stakeholder first
Forgotten stakeholders are forgotten requirements.
Peter Hruschka, private conversation
Based upon the importance of stakeholders for project success, we centered our approach around the needs of the following typical stakeholder groups:
| Stakeholder Type | Typical Expectations |
|---|---|
| User | usable in terms of providing expected and desired functions, easy and pleasant to use, reliable, available when needed, safe |
| Management | efficient in terms of development and operational cost, reliable |
| Domain expert | reliable and efficient in terms of providing required functions, flexible in terms of providing new functions, |
| Product owner | flexible in terms of new features, |
| Developer | flexible and reliable in terms of maintaining the code, easily testable |
| Tester | testable with suitable effort, flexible in terms of automation and instrumentation, reliable in terms of reproducible test results |
| Admin | operable and reliable in terms of easily operating and administering the system, secure and reliable when integrating with other systems, flexible in terms of execution environments, safe and secure |
| Others |
Just Eight, not 35
Q42 proposes 8 “tags”, which suffice to cover most (hopefully all) of the traditional qualities. These tags should be almost self-explanatory, but I’ll try to clarify them with examples:
| Tag | Meaning(s) |
|---|---|
#reliable |
available, robust, dependable, fail-safe, fault-tolerant, consistent, recoverable, safe, secure |
#flexible |
flexible during development (easy to change and enhance), flexible concerning infrastructure and environments, flexible at runtime (configurable, adjustable, integratable) |
#efficient |
fast, responsive, efficient in terms of memory, CPU, threads, network and other resources, efficiently maintainable and operable |
#usable |
easy and pleasurable to use, attractive, aesthetic |
#operable |
easy to install, operate, monitor and administer, adequate operational costs |
#suitable |
providing suitable properties and responsibilities or functions |
#secure |
consistent, accountable, confidential, integrous |
#safe |
fail-safe, isolating faults, warns of hazards early, identifies risks early |
Code and Architecture Qualities
In several of the historical quality models, the development teams’ interest was either completely ignored or had low priority. In 1978, Barry Boehm proposed to care for structuredness, conciseness and legibility, but in later models, for example in the ISO-25010 standard, these properties are out of scope.
From my viewpoint, development teams play a crucial role in both initial development and long-term maintenance and evolution of systems. Therefore, we should consider their requirements on the internal structure and concepts as highly relevant, for example influencing the important time-to-market that most managers constantly call for.
Q42 regards development teams as first-class citizens:
#reliablein terms of “We can add now features or otherwise modify the systems, and can reliably predict the consequences of our changes. We can reliably fix bugs. We can reliably predict runtime behaviour.”#flexiblein several dimensions, e.g. flexible module or component structure, flexible code that is easy to modify, flexible software and hardware infrastructure.#usablein terms of understandable module structures, understandable code and data structures, understandable runtime behaviour.#suitablein terms of appropriately “We can easily understand, test and modify code, and we can add new responsibilities and functions with appropriate risks”.
Summary
The arc42 quality model has yet to prove its practical applicability, as it hit the market only in January 2023. Alas - we are highly optimistic that Q42 will mirror the usefulness of it’s elder sister, the arc42-template.
Please let us know of any positive or negative experience you encounter with our approach.