The classic classification splits quality into three groups by WHAT you are asking about. PRODUCT OPERATION — how well does it run? CORRECTNESS does it satisfy the specification? RELIABILITY does it perform without failure? Measured as MTBF, or availability. EFFICIENCY how much CPU, memory, bandwidth does it need? INTEGRITY can unauthorised access be prevented? USABILITY effort needed to learn and operate it PRODUCT REVISION — how easily can it be changed? MAINTAINABILITY effort to locate and fix a defect FLEXIBILITY effort to modify an operational program TESTABILITY effort to test that it works PRODUCT TRANSITION — how easily does it move? PORTABILITY effort to move to another environment REUSABILITY can parts be used in other programs? INTEROPERABILITY effort to couple it to other systems FUNCTIONAL vs NON-FUNCTIONAL, since this is the distinction the attributes belong to: FUNCTIONAL WHAT the system does — "the user can transfer money" NON-FUNCTIONAL HOW WELL it does it — "the transfer completes within 2 seconds, 99.9% of the time" Non-functional requirements are usually the ones that determine ARCHITECTURE, and the ones that are hardest to retrofit. You can add a feature to a working system; you cannot easily add "responds in 100 ms" to one that responds in 10 seconds. ISO/IEC 25010 — the modern replacement for McCall, with eight characteristics: functional suitability · performance efficiency · compatibility · usability · reliability · security · maintainability · portability

A quality attribute is worthless as a requirement unless it is MEASURABLE. "The system shall be user-friendly" cannot be tested; "a trained user shall complete a booking in under 90 seconds with fewer than 2 errors" can. attribute how to make it measurable ───────────────────────────────────────────────────────── reliability MTBF, failure rate, availability % performance response time percentile, throughput usability task completion time, error rate, training hours portability % of code needing change per platform maintainability mean time to repair; cyclomatic complexity security time to compromise; vulnerabilities found in audit testability % statement/branch coverage achievable AVAILABILITY ARITHMETIC — the "nines", worth memorising because the numbers are counter-intuitive: availability downtime per year per month ────────────────────────────────────────────── 90% (1 nine) 36.5 days 73 hours 99% (2 nines) 3.65 days 7.3 hours 99.9% (3 nines) 8.77 hours 43.8 minutes 99.99% (4 nines) 52.6 minutes 4.4 minutes 99.999% (5 nines) 5.26 minutes 26 seconds Each extra nine divides downtime by 10 and typically MULTIPLIES cost — redundant hardware, multi-region deployment, on-call staffing. Going from 99.9% to 99.99% means your entire yearly allowance is under an hour, which rules out any manual recovery procedure. MTBF / MTTR RELATIONSHIP: availability = MTBF / (MTBF + MTTR) WORKED: MTBF = 1000 hours, MTTR = 1 hour availability = 1000/1001 = 0.999 = 99.9% Improve MTTR to 0.1 hour (6 minutes) with the same MTBF: = 1000/1000.1 = 0.9999 = 99.99% READ THAT AGAIN: reducing RECOVERY time from 60 to 6 minutes bought a whole extra nine, without making the system fail any less often. Often it is far cheaper to recover faster than to fail less — which is the entire argument for automated rollback and for chaos engineering.

Quality attributes CONFLICT. An architect's job is choosing, not maximising. EFFICIENCY vs MAINTAINABILITY hand-optimised code is faster and harder to read. Every abstraction that aids maintenance costs some performance. EFFICIENCY vs PORTABILITY using platform-specific features is faster and less portable. SECURITY vs USABILITY every additional authentication step improves security and annoys users. Password complexity rules push users to write passwords down — a security measure producing a security hole. RELIABILITY vs EFFICIENCY redundancy, checksums, retries and validation all cost time and memory. FLEXIBILITY vs SIMPLICITY a configurable system handles more cases and is harder to understand, test and support. "Make it configurable" often means "we could not decide, so the user must". TIME-TO-MARKET vs everything the trade nobody writes down but everyone makes. HOW ARCHITECTS RESOLVE THIS: state the attributes in PRIORITY ORDER, with measurable targets, and record the trade explicitly. Instead of: "the system must be secure, fast and easy to use" write: "1. security (no unauthenticated data access) 2. reliability (99.9% availability) 3. performance (p95 under 500 ms) 4. usability where 3 and 4 may be sacrificed for 1 and 2" That ordering is what lets an engineer make the right call without escalating — which is the practical purpose of an architecture document. THE COST OF QUALITY has three components: PREVENTION planning, reviews, training, tooling APPRAISAL inspection, testing, audits FAILURE internal (rework before release) and EXTERNAL (support, warranty, reputation, liability) The relationship is the cost-of-change curve again: money spent on prevention and appraisal reduces failure cost by far more than it costs, because external failure is the most expensive category by an order of magnitude.