Quality Attributes,
measured & mnemonic'd.
Every quality attribute scenario is really the same instrument reading a different dial: something happens (stimulus), it hits a part of the system (artifact), the system reacts (response), and you grade it with a number (measure). Learn that one shape, and all nine attributes fall into place.
Every quality attribute the course tests
Six of these get full "scenario + tactics" treatment (starred ★) — those are the ones the exam loves. The rest still show up in definitions questions, so know them by one line each.
Usability
How easy it is to learn and use the system, and how well it supports the user in getting things done.
Modifiability
The cost — in time and money — of making a change to the system.
Security
The system's ability to resist unauthorized access while still serving legitimate users.
Performance
Timeliness — the system must respond to events within acceptable time/resource limits.
Reliability
The system's failure rate — how often, and how badly, things go wrong.
Portability
The effort needed to move the system to a different software or hardware environment.
Testability
How easily the software can be made to reveal its faults — needs controllable inputs and observable outputs.
Availability
The system's uptime — concerned with failures and how long they last.
Interoperability
The system's ability to work with other software or hardware systems.
Anatomy of a quality attribute scenario
Every general and sample scenario in this chapter — availability, performance, security, whatever — is filled out using the exact same six blanks. Memorize the blanks, not the examples.
Who triggers it
User, attacker, another system, or something internal to the system itself.What happens
The event that arrives — a request, a crash, an attack, a wish to change the UI.The situation it happens in
Normal operation, overload, startup, design-time, runtime, under attack…What part gets hit
The processor, a database, the UI, a code module — whatever is affected.How the system reacts
Logs the error, disables the source, redeploys, denies access, restores data.How you grade success
Response time < 2s, 99.999% uptime, repair time, path coverage %.The uptime attribute
Availability
system's uptimeConcerned with system failure and the duration of that failure. A failure means the system stops delivering the service it was built for — availability tactics exist to detect that fast, contain it, and get back to normal.
| Source | Heartbeat monitor |
| Stimulus | Server becomes unresponsive |
| Environment | Normal operation |
| Artifact | Process |
| Response | Disable the source of failure, then repair it |
| Measure | Repair time |
The "how much does change cost" attribute
Modifiability
cost of changeNot just "can it change" — how much it costs in time and money to add, remove, or tweak functionality, quality attributes, capacity, or technology.
| End-user | "I want dark mode" → dev implements & redeploys → measured in cost, downtime, satisfaction |
| Developer | Refactors code at design/build time → implement → test → integrate → measured in coding/testing effort |
| Sys. Admin | Scales servers / upgrades DB at runtime or init → apply, redeploy, test stability |
The timeliness attribute
Performance
timelinessEvents occur, and the system must respond within acceptable time and resource limits — regardless of how busy it is.
| Latency | Delay before it starts — e.g. 2s before video plays |
| Deadline | Must finish by — payment confirms within 5s |
| Throughput | Work per second — 1,000 requests/min |
| Jitter | Inconsistent response times (1s, then 4s) |
| Miss Rate | % of deadlines missed — 2 of 100 frames = 2% |
| Data Loss | Data that never arrives — 5 of 100 packets |
The resist/detect/recover attribute
Security
resist unauthorized accessThe ability to prevent or resist unauthorized access while still letting legitimate users in. An attack is an attempt to breach security.
| Source | Disgruntled employee, remote location |
| Stimulus | Attempt to modify pay-rate data |
| Environment | Normal operations |
| Artifact | Data within the system |
| Response | System maintains an audit trail |
| Measure | Correct data restored within a day; source of tampering identified |
The "prove your bugs" attribute
Testability
ease of finding faultsHow easily the software can be made to demonstrate its faults. Requires controlling inputs and observing outputs.
| Source | Unit tester |
| Stimulus | Code unit completed |
| Environment | Development |
| Artifact | Code unit |
| Response | Results captured |
| Measure | 85% path coverage within 3 hours |
The "how easy is this to use" attribute
Usability
ease of use + supportHow easy it is for the user to accomplish a task, and how much the system helps them do it.
| Source | User |
| Stimulus | Downloads a new application |
| Environment | Runtime |
| Artifact | System |
| Response | User uses the app productively |
| Measure | Productive within 2 minutes |
If the exam only lets you write one tactic
Straight from the lecture's closing "extra question" — the minimum viable answer for each attribute.
| Quality Attribute | Fastest correct tactic to name |
|---|---|
| Security | Resisting Attacks / Detecting Attacks / Authenticate Users |
| Testability | Separate Interface from Implementation |
| Modifiability | Localize Changes / Encapsulation / Hide Information |
| Performance | Introduce Concurrency / Increase Available Resources |
Where students actually lose points
Pulled straight from a graded midterm on this exact diagram (Server / Heartbeat / Unresponsive scenario). Same shape, different words each time — practice filling the six blanks fast.
"Repair time" is the ruler, not the action. The action is "disable + repair the source." Keep them in separate sentences.
"Error detection" and "error recovery" are the right family — but be precise about which of the 4 branches (Detection / Prep+Repair / Reintroduction / Prevention) each tactic sits under.
Students often skip stating "Normal Operation" explicitly — graders want all six anatomy parts named, not just the two headline ones.
Did I name: attribute → source → stimulus → environment → artifact → response → measure, in that order, each in one clause?