Software Quality Attributes Vocabulary — Code Quality Exercises

1 / 5

A product requirements document lists "maintainability" as a non-functional requirement citing ISO 25010. A developer asks: "What exactly does the standard say maintainability includes?" Which answer correctly names the ISO 25010 sub-characteristics of maintainability?

ISO/IEC 25010 (Systems and Software Quality Requirements and Evaluation) provides the authoritative vocabulary for software quality attributes used in requirements engineering, architecture decisions, and quality assurance.

ISO 25010 Maintainability sub-characteristics:

Sub-characteristic	Definition	Typical measurement
Modularity	Changes to one component have minimal impact on others	Coupling metrics, component cohesion
Reusability	An asset can be used in more than one system	Library usage metrics, API surface
Analysability	Effectiveness of diagnosing deficiencies or failure causes	MTTR, log coverage, observability tooling
Modifiability	Can be modified without introducing defects or degrading quality	Change failure rate, regression test results
Testability	Effectiveness of establishing test criteria and running validation	Branch coverage, cyclomatic complexity

Why this vocabulary matters in practice:
When writing non-functional requirements, specifying "the system shall be maintainable" is meaningless unless you reference which sub-characteristic you mean and how you will measure it. E.g. "Modifiability: any single feature change shall not require modification of more than 3 modules" is a testable NFR.

Key vocabulary:
• Non-functional requirement (NFR) — a quality attribute constraint rather than a functional capability
• ISO 25010 — the international standard defining the software quality model
• Quality attribute — a measurable or testable property of a software system

2 / 5

An architect writes in an Architecture Decision Record: "This approach has implications for system reliability as defined by ISO 25010." What does ISO 25010 define as reliability, and how is it measured in practice?

ISO 25010 reliability has four distinct sub-characteristics, each with measurable indicators — understanding them enables precise engineering conversations about system dependability.

ISO 25010 Reliability sub-characteristics:

Sub-characteristic	Definition	Measurement
Maturity	Meets needs for reliability under normal operation	MTBF (Mean Time Between Failures)
Availability	Accessible and operational when required	Uptime %; SLA compliance
Fault tolerance	Operates despite hardware or software faults	Graceful degradation tests; chaos engineering results
Recoverability	Recovers data and state after interruption	RTO/RPO; MTTR

Reliability vs Availability — an important distinction:
A system can be highly available (rarely fully down) but have low reliability (frequent partial failures, degraded modes, data inconsistencies). ISO 25010 captures this by treating availability as just one sub-characteristic of the broader reliability concept.

Practical example:
A payment processing system might have 99.95% availability but poor fault tolerance (a single database node failure causes incorrect charge amounts rather than a clean error). Availability looks good; fault tolerance is failing.

Key vocabulary:
• MTBF — Mean Time Between Failures; average time a system runs without failure
• RTO — Recovery Time Objective; maximum acceptable restoration time
• RPO — Recovery Point Objective; maximum acceptable data loss (in time)
• Chaos engineering — deliberately injecting failures to test fault tolerance

3 / 5

A developer proposes a new feature. The architect responds: "This creates a portability concern — it tightly couples us to vendor-specific APIs." What does portability mean as an ISO 25010 quality attribute?

ISO 25010 portability captures the architectural property of flexibility to change infrastructure, cloud providers, or deployment environments — a critical consideration in vendor lock-in risk assessments.

ISO 25010 Portability sub-characteristics:

Sub-characteristic	Definition	Example
Adaptability	Can be adapted to different hardware/software/operating/usage environments	Containerised deployment; environment config via env vars
Installability	Can be effectively and efficiently installed or uninstalled in a specified environment	Helm chart deployment; clean uninstall scripts
Replaceability	Can replace another specified software product for the same purpose in the same environment	Implementing a standard interface (e.g. S3 API) that other tools also implement

Vendor lock-in as a portability risk:
When a system calls vendor-specific APIs (e.g. AWS Lambda-specific invocation patterns, Azure-specific bindings), migrating to a different cloud provider requires significant rework. Mitigation strategies:
• Abstract vendor APIs behind a domain interface (Adapter/Facade pattern)
• Prefer standards-based APIs over proprietary ones when capability is equivalent
• Document vendor-specific dependencies explicitly in architecture decision records (ADRs)

Key vocabulary:
• Vendor lock-in — architectural dependency that makes switching vendors costly or impractical
• Portability — the degree to which a system can be transferred to a different environment
• Adapter pattern — a design pattern that wraps vendor-specific code behind a stable interface

4 / 5

In a quality review meeting, a PM asks: "What is the difference between performance efficiency and reliability as quality attributes? Aren't they the same thing?"

Performance efficiency and reliability are distinct ISO 25010 quality characteristics that can vary independently — understanding the difference prevents requirements confusion in project planning.

ISO 25010 Performance Efficiency sub-characteristics:

Sub-characteristic	Definition	Metric example
Time behaviour	Response and processing times; throughput under normal conditions	P99 latency <200ms; 1000 req/s throughput
Resource utilisation	Amounts and types of resources used to perform functions	CPU <70% at peak; <4GB RAM at steady state
Capacity	Degree to which maximum limits meet requirements	Supports 10,000 concurrent users

Four quadrants — performance vs reliability combinations:
• High performance, high reliability → ideal production system
• High performance, low reliability → fast but fragile; failures are quick and frequent
• Low performance, high reliability → slow but stable; rarely fails, never fast
• Low performance, low reliability → technical debt priority target

How this matters in architecture decisions:
A caching layer (e.g. Redis) improves performance efficiency (reduces P99 latency) but can introduce reliability concerns (cache stampede on cold start, stale data issues). The architect must consciously manage the trade-off between the two attributes.

Key vocabulary:
• Performance efficiency — resources used relative to work performed under stated conditions
• P99 latency — the 99th percentile response time; 99% of requests complete within this duration
• Quality attribute trade-off — the architectural reality that improving one attribute often degrades another

5 / 5

A tech lead uses the phrase "quality attribute trade-off" in an Architecture Decision Record. A junior developer asks what this means. What is the correct explanation?

Quality attribute trade-offs are an architectural reality — no system can simultaneously maximise all ISO 25010 quality attributes, and the architect's job is to make these trade-offs explicit and intentional.

Common quality attribute tensions:

Trade-off	Example
Security ↔ Usability	MFA and session timeouts improve security but increase friction for the user
Performance ↔ Maintainability	Hand-optimised SQL is faster but harder to understand and modify safely
Reliability ↔ Performance	Synchronous replication improves durability but adds latency to every write
Portability ↔ Performance	Abstracting away vendor APIs sacrifices access to performance-optimised features
Maintainability ↔ Performance	Caching improves performance but adds complexity to cache invalidation logic

Architecture Decision Record structure for trade-offs:
① Context: the forces competing in this decision
② Decision: the chosen architectural option
③ Trade-offs accepted: which quality attributes are degraded and by how much
④ Consequences: what follow-up work is required to mitigate the downside

The ATAM method (Architecture Tradeoff Analysis Method):
ATAM is a structured framework for analysing quality attribute trade-offs in architecture reviews, commonly used in government and defence software procurement.

Key vocabulary:
• Quality attribute trade-off — accepting degradation in one quality attribute to improve another
• Architecturally Significant Requirement (ASR) — a requirement that materially constrains the architectural design
• Architecture Decision Record (ADR) — a document capturing the context, decision, and trade-offs of an architectural choice