Asking stakeholders “what are your quality requirements?” usually produces silence, or buzzwords. Hardly anybody can write a measurable quality requirement from a blank page.

Reacting to one, though, is easy. Put a concrete example in front of people and they will tell you immediately that the number is far too high, that this particular quality does not matter for their system at all, or that you have just hit the one thing they really care about. That reaction is the requirement - you only have to write it down.

The arc42 quality model gives you the raw material for this: around 150 example requirements, plus some 190 quality characteristics to help you find the right term in the first place.

Take one that is roughly in the area you want to discuss, for example:

Requirement. All automated unit tests for a subsystem must execute quickly enough to give developers rapid feedback.

Acceptance criteria

• All unit tests for a subsystem complete in less than 180 seconds
• Test execution time is measured on standard CI/CD infrastructure

from Q42, “Quick unit tests”

Then let your stakeholders argue with the numbers. Keep the structure, replace the context and the thresholds with theirs, and you have a quality requirement that is specific, measurable, and actually agreed on.

See tip 1-12 for the anatomy of such scenarios, and tip 1-24 for more on the quality model itself.