Software Quality Attributes
In short Quality attributes say how well a system must do its job: how available, fast, secure or easy to use it is. Wiegers and Beatty provide a catalog of sixteen attributes, a five-step way to elicit them, and a notation (Planguage) for writing targets that can be tested.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 14, including the elicitation approach they credit to Jim Brosseau and Tom Gilb’s Planguage.
On this page
Key ideas#
Quality attributes are not all of the NFRs#
Non-functional requirements (NFRs) include quality attributes, design constraints and external interface requirements. Quality attributes are the biggest part. The chapter opens with a classroom heating system that met its written requirements but was too loud to teach over: functionality without stated quality is half a product.
External and internal attributes#
Following Bass, Clements and Kazman, the authors split attributes into external ones, visible when the system runs and important mainly to users, and internal ones, important to developers and maintainers, which reach users indirectly.
| External (10) | What it means | Typical measure |
|---|---|---|
| Availability | Share of planned time the system is usable | % uptime in stated hours; MTTF / (MTTF + MTTR), where MTTF is mean time to failure and MTTR mean time to repair |
| Installability | Ease of installing, upgrading, rolling back, removing | Average install time for an untrained user |
| Integrity | Protection of data from loss or corruption | Pass/fail: atomic updates, backup and recovery |
| Interoperability | Exchanging data with other systems and devices | Formats and systems supported |
| Performance | Response time, throughput, data capacity, concurrent users, predictability, behavior under overload | Seconds, transactions per hour, users |
| Reliability | Running without failure for a period | Mean time between failures (MTBF), % successful operations |
| Robustness | Behaving sensibly with bad input, failed components, odd conditions | Observable outcome after the fault |
| Safety | Preventing harm to people or property | Hazards prevented; often regulated |
| Security | Blocking unauthorized access and malicious code | Pass/fail per threat |
| Usability | Ease of learning and efficiency of use | Task time, % tasks done without help, errors, steps |
Internal (6): efficiency (economical use of processor, memory and storage), modifiability (ease of understanding, fixing, extending and adapting), portability, reusability, scalability, and verifiability (testability).
Which attributes matter depends on the system. Embedded systems stress performance, efficiency, reliability, robustness, safety and usability; web and enterprise applications stress availability, integrity, interoperability, performance, scalability, security and usability.
Three cautions from the book. Very high availability is very expensive; the authors describe an air-traffic-control system where it required full hardware redundancy. Reliability is a lagging indicator: you only know a target was met after the period has passed. And state the observable result, not the mechanism: “use passwords” is a design choice; “only authorized users can change prices” is the requirement.
Five steps to elicit quality attributes#
The approach Wiegers and Beatty credit to Jim Brosseau:
- Start with the full list of sixteen so nothing is forgotten.
- Shortlist. Review stakeholders and decide which attributes apply. Write down why each one is in or out.
- Prioritize pairwise. For each pair ask: “If only these two existed, which matters more?” The totals rank the attributes. This focuses later elicitation and decides future trade-offs in advance. Include developers and support staff; their priorities often differ.
- Elicit specific expectations. Users rarely answer “how reliable must it be?” usefully. Ask targeted questions, and ask what would be unacceptable; limits are often easier to state than goals.
- Write measurable requirements. Each one needs a unit of measure, a minimum acceptable level and a target.
Planguage: precise targets#
Tom Gilb’s Planguage replaces a single sentence with keywords. TAG gives a unique ID; AMBITION states the intent; SCALE names the unit; METER says exactly how to measure; MUST is the minimum acceptable level; GOAL is the target, with its source; STRETCH and WISH record higher hopes; FAIL describes failure instead of success; DEFINED explains special terms. METER ends arguments about how a value was measured, and even writing just SCALE and METER removes most ambiguity.
Trade-offs and constraints#
Improving one attribute affects others, and not symmetrically. Stronger security usually costs performance, while faster performance barely affects security. Higher performance tends to hurt modifiability and portability; better portability tends to help interoperability, reusability and testability. Your pairwise ranking tells you which way to give.
Constraints narrow the developers’ choices: mandated technologies, platform limits, a client’s coding standards, backward compatibility, regulations, hardware limits, an existing user interface, external interfaces. Watch for users presenting a solution as a requirement (“payments must go through provider X”). Ask “why?” until you reach the need. If the proposed solution really is right, keep the constraint, but verify it first.
Example#
The Workshop, a fictional bike-repair chain, shortlists availability, performance, usability, security, integrity and interoperability (with the parts supplier). Pairwise comparison puts usability and integrity first, so if a richer booking screen threatens response time, usability wins within agreed limits.
TAG: Performance.Booking.SlotSearch
AMBITION: Customers see free repair slots almost instantly.
SCALE: Seconds from tapping "Find slots" until the slot list is fully shown.
METER: 50 timed searches on a mid-range phone during opening hours.
MUST: 4 seconds or less for 95% of searches.
GOAL: 2 seconds or less for 95% of searches <- owner
STRETCH: 1 second or less for 95% of searches.
DEFINED: Mid-range phone: the model the team agrees on as typical for customers.
Pitfalls#
- “User-friendly” or “fast” with no unit → add SCALE, METER and a MUST level.
- Stating a mechanism (autosave, passwords) → state the observable result.
- Asking users directly for numbers → ask about tasks and about what would be unacceptable.
- Forgetting internal attributes → ask developers and support about modifiability and testability.
- Demanding extreme availability without costing it → show the price before agreeing the target.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 14 (quality attributes, Brosseau’s elicitation steps, Planguage, attribute trade-offs, constraints).