Quality Attributes (Non-Functional Requirements)

What it is

Quality attributes (QAs) — also called non-functional requirements (NFRs) or "-ilities" — describe how well a system performs its intended functions, rather than what it does. While functional requirements describe behavior (e.g., "the user can place an order"), quality attributes describe constraints and properties (e.g., "order placement must complete in under 200 ms at the 99th percentile under 10,000 concurrent users"). They are architecture-significant because they are the primary driver of structural decisions.

ISO/IEC 25010 (the successor to ISO 9126) provides a formal taxonomy of product quality characteristics including functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability — each decomposed into sub-characteristics. While the ISO taxonomy is comprehensive, practitioners typically work with a smaller set of the most architecture-relevant attributes for any given system.

Why it exists

Functional requirements alone cannot drive architecture. Two systems with identical functional requirements can have radically different architectures depending on their quality attribute requirements. A system that must handle 1 million requests per second is fundamentally different in structure from one that must handle 100, even if both expose the same API. Similarly, a system with strict data-sovereignty requirements requires a different deployment topology from one optimized purely for cost.

Quality attributes are the primary mechanism through which business context translates into technical structure. Without explicit, measurable NFRs, architects make implicit assumptions that may be discovered as wrong only during production incidents or failed load tests. Documenting QAs early — and making them measurable and testable — dramatically reduces late-stage rework.

When to use

• At the start of any significant new system or major capability, before the first architecture sketch is drawn.
• When evaluating competing architecture options — QAs provide objective evaluation criteria.
• During architecture reviews to validate that the proposed design satisfies the stated quality requirements.
• When defining Service Level Objectives (SLOs) and Service Level Agreements (SLAs) for internal or external consumers.
• When writing fitness functions to automatically verify that deployed systems stay within quality attribute bounds over time.

When not to use

• Do not treat every quality attribute as equally important — prioritize based on business risk. Over-engineering for availability in a batch job that runs nightly adds cost without benefit.
• Do not define NFRs in unmeasurable terms ("the system must be fast") — they must be quantified to be useful.
• Do not allow NFRs to be specified without stakeholder sign-off; architects cannot unilaterally decide that a system needs five-nines availability.

Typical architecture

Quality attributes are often in tension with one another. The table below shows the most common architecture-significant QAs and their typical measurement approaches, along with the structural patterns that primarily satisfy them.

Quality Attribute    Measurement                 Primary Architectural Levers
─────────────────────────────────────────────────────────────────────────────
Availability         Uptime % (e.g., 99.9%)      Redundancy, failover, health checks
Performance/Latency  p50, p95, p99 response time  Caching, CDN, async processing
Throughput           Requests/sec, msgs/sec       Horizontal scaling, partitioning
Scalability          Linear scale under load      Stateless services, sharding
Reliability          Error rate, MTBF/MTTR        Circuit breakers, retries, idempotency
Security             OWASP coverage, pen test     AuthN/Z, encryption, network policies
Maintainability      Mean time to change (MTTC)   Modularity, test coverage, abstractions
Testability          Test coverage, test speed    Dependency injection, hexagonal arch
Observability        MTTD (mean time to detect)   Structured logs, traces, metrics
Deployability        Deploy frequency, lead time  CI/CD, feature flags, blue-green
          

Pros and cons

Implementation notes

Make QAs measurable (SMART NFRs): Every quality attribute requirement should be Specific, Measurable, Achievable, Relevant, and Time-bound. "The API must respond in under 100 ms at the p99 percentile for the search endpoint, measured under a sustained load of 5,000 requests per second, excluding upstream database cold-start periods." This is actionable. "The API must be fast" is not.

Fitness functions: Coined by Neal Ford, Rebecca Parsons, and Patrick Kua in Building Evolutionary Architectures, fitness functions are automated checks that verify quality attribute requirements on every build or deployment. A fitness function for performance might run a k6 load test against a staging environment and fail the pipeline if p99 latency exceeds 100 ms. A fitness function for modularity might use ArchUnit to assert that no infrastructure code is imported into the domain layer.

QA tensions to manage explicitly: Security vs Performance — adding TLS, JWT validation, and rate limiting all add latency; measure the overhead and make it visible. Availability vs Consistency — achieving high availability often requires relaxing strong consistency guarantees (see CAP Theorem). Simplicity vs Extensibility — premature abstraction in the name of extensibility is one of the most common sources of unnecessary complexity.

Common failure modes

• Missing NFRs at project start: The most common failure — teams discover in production that they needed 99.9% availability but designed for convenience.
• Unmeasurable NFRs: "Good performance" and "highly available" are useless without numbers attached to them.
• NFR gold plating: Specifying five-nines availability for a back-office reporting tool that is only used during business hours — engineering effort wasted on unjustified requirements.
• Ignoring QA tensions: Independently satisfying each QA without recognizing their interactions leads to contradictory architectural decisions.
• No fitness functions: QAs defined once and never tested allow systems to silently degrade as the codebase evolves.

Decision checklist

• Have availability targets been expressed as a percentage (e.g., 99.9%) and translated into an acceptable downtime budget per month?
• Are performance targets specified at a particular percentile (p95/p99) and at a defined load level, not just average response time?
• Have security requirements been tied to a specific threat model rather than a generic "the system must be secure" statement?
• Is there a prioritized ranking of QAs so architects know which to sacrifice when trade-offs cannot be avoided?
• Are QA requirements included in the Definition of Done for each feature, not just documented once and forgotten?
• Have fitness functions been defined for the top 3–5 most important QAs and integrated into the CI/CD pipeline?
• Has the cost of achieving each QA target been reviewed with the business — e.g., the infrastructure cost of multi-region active-active vs active-passive?
• Are there SLOs defined for external-facing services, with error budgets and clear ownership?

Example use cases

• A payment processing platform defines strict availability (99.99%), consistency (strong), and security (PCI-DSS) QAs — which drives it to a synchronous, multi-region active-active architecture with distributed ACID transactions.
• A social media feed service prioritizes throughput and availability over strong consistency — allowing eventual consistency and partition-tolerant storage, accepting that users may briefly see stale data.
• An internal analytics dashboard prioritizes maintainability and deployability over raw performance — using a monolithic architecture with clean module boundaries rather than microservices.
• An IoT telemetry pipeline prioritizes scalability and deployability — using a Kafka-based event streaming architecture that scales horizontally with device count.

Related patterns

• Architecture Principles — principles express the values that determine which quality attributes are prioritized.
• Architectural Trade-off Analysis — the technique for resolving tensions between competing quality attributes.
• CAP Theorem — the fundamental constraint governing the availability/consistency quality attribute tension in distributed systems.

Further reading

• ISO/IEC 25010 — the international standard for software product quality models.
• Building Evolutionary Architectures — Ford, Parsons, Kua — the source of fitness functions as a QA verification mechanism.
• Understanding Quality Attributes — InfoQ — practical guide to eliciting and applying NFRs.