Fast, reliable, scalable, secure, maintainable: none of these can be passed or failed, so none of them can be designed for. A quality goal becomes a requirement only when it carries three things. First, a quantity that somebody can actually observe from outside the system, such as the time between a request arriving and its answer leaving, or the fraction of requests answered successfully. Second, a value for that quantity. Third, the condition under which the value must hold, which is where most attempts fall down: over what period is it measured, at what point in the distribution, and under how much load. Ninety-five percent of responses under two hundred milliseconds, measured over a calendar month, at up to three hundred requests a second, is a requirement. Fast is not. The condition matters because an average hides the slow answers that people actually complain about, and a target with no stated load is met trivially at zero traffic. Numbers also cost money in a way that words do not, so writing them down turns a mood into a conversation about what the organisation will pay for. After this Concept you can take any vague quality word in a brief and rewrite it as a quantity, a value and a condition, or state exactly which of the three is still missing and who has to supply it.
Quality attributes (the "-ilities") are measurable, system-wide properties — such as performance, scalability, availability, maintainability, and security — that a software architecture must deliver …