Quality Attributes and Non-Functional Requirements
What this domain tests
This domain tests whether you can turn "-ilities" into measurable, testable scenarios and select tactics whose trade-offs you can state explicitly.
Core rules
- Use the six-part scenario: source, stimulus, environment, artefact, response, response measure. Omitting the environment or the measure makes the requirement untestable.
- Tactics are design decisions; patterns are packaged tactics. Availability: redundancy, heartbeat, failover, circuit breaker. Performance: concurrency, caching, pooling, queueing. Security: authentication, authorisation, encryption, auditing. Modifiability: deferring binding time, encapsulating change. Testability: seam injection and observability.
- Most architecture failures are trade-off failures rather than tactic failures: consistency versus latency, security versus usability, availability versus cost, modifiability versus performance.
- Prioritise quality attributes with stakeholders, since you cannot maximise all of them. A utility tree makes the ranking visible.
Worked example
Requirement: "the portal must be highly available." That is unmeasurable. Rewritten: when a datacentre loses power (source: infrastructure; stimulus: outage; environment: normal operation; artefact: portal; response: sessions continue on the secondary region; measure: 99.9% monthly availability, RTO 30 minutes, RPO 5 minutes, at most two minutes of failed requests). The numbers force design choices - active-passive warm standby versus active-active - and the RTO/RPO expose the cost.
Traps
- Leaving measures out; "fast", "secure", and "reliable" are unfalsifiable.
- Confusing reliability (time between failures) with availability (proportion of time usable).
- Reading CAP as a simplistic "pick two"; partitions are rare, but the latency/consistency trade-off is continuous.
- Naming a pattern without stating the quality attribute it serves and the one it degrades.