Quality Attributes Taxonomy

This skill provides a comprehensive framework for understanding and applying quality attributes (non-functional requirements) in system design.

When to Use This Skill

Keywords: NFR, non-functional requirements, quality attributes, -ilities, scalability, reliability, availability, performance, security, maintainability, ISO 25010

Use this skill when:

• Defining non-functional requirements for a system

• Evaluating architectural trade-offs

• Conducting architecture reviews

• Preparing for system design interviews

• Ensuring all quality dimensions are considered

• Translating business needs to technical requirements

What Are Quality Attributes?

Quality attributes (QAs) describe HOW a system performs, not WHAT it does. They're often called:

• Non-Functional Requirements (NFRs)

• The "-ilities" (scalability, reliability, etc.)

• Cross-cutting concerns

• System qualities

Key insight: Functional requirements define features; quality attributes define how well those features work.

The Core Quality Attributes

Primary Attributes (The Big 6)

Attribute Definition Key Question

Scalability Handle growing load Can we grow 10x? 100x?

Reliability Consistent correct operation Does it work correctly every time?

Availability System uptime Is it running when needed?

Performance Speed and throughput How fast is it?

Security Protection from threats Is it safe from attacks?

Maintainability Ease of change Can we update it easily?

Secondary Attributes

Attribute Definition Key Question

Testability Ease of verification Can we test it effectively?

Observability System visibility Can we see what's happening?

Operability Ease of operation Can we run it in production?

Portability Platform independence Can we move it?

Interoperability System integration Can it work with others?

Cost Efficiency Resource optimization Is it cost-effective?

Detailed Quality Attribute Definitions

Scalability

Definition: The ability to handle increased load by adding resources.

Type Description Example

Vertical Add more power to existing machines Upgrade to larger instance

Horizontal Add more machines Add more servers behind load balancer

Elastic Automatic scaling based on load Auto-scaling groups

Measurement:

• Maximum concurrent users
• Requests per second at given latency
• Data volume supported
• Cost per transaction at scale

Trade-offs:

• Scalability often conflicts with consistency (CAP theorem)

• More scalability = more complexity

• Horizontal scaling requires stateless design

Reliability

Definition: The probability of correct operation over time.

Concept Definition

MTBF Mean Time Between Failures

MTTR Mean Time To Recovery

Fault Tolerance Continue despite component failures

Resilience Recover from failures gracefully

Measurement:

• Error rate (errors / total requests)
• Failure rate (failures / time period)
• Data accuracy percentage
• Successful transaction rate

Trade-offs:

• Higher reliability = higher cost (redundancy)

• Reliability vs performance (checksums, validation)

• Reliability vs complexity (more failure modes to handle)

Availability

Definition: The proportion of time a system is operational.

Level Uptime Downtime/Year Downtime/Month

99% Two 9s 3.65 days 7.31 hours

99.9% Three 9s 8.76 hours 43.8 minutes

99.99% Four 9s 52.6 minutes 4.38 minutes

99.999% Five 9s 5.26 minutes 26.3 seconds

Measurement:

Availability = Uptime / (Uptime + Downtime) = MTBF / (MTBF + MTTR)

Trade-offs:

• Each additional "9" is exponentially more expensive

• Availability vs consistency (CAP theorem)

• Planned maintenance affects availability

Performance

Definition: How fast and efficient the system operates.

Metric Definition

Latency Time to complete one request

Throughput Requests processed per unit time

Response Time Total time user waits

Utilization Resource usage percentage

Common Targets:

• Web page load: < 2 seconds
• API response: < 100 ms (p99)
• Database query: < 10 ms
• Batch job: < scheduled window

Trade-offs:

• Performance vs cost (faster hardware costs more)

• Latency vs throughput (batching improves throughput, hurts latency)

• Performance vs consistency (caching improves speed, may serve stale data)

Security

Definition: Protection of data and systems from unauthorized access.

Principle Description

Confidentiality Data accessible only to authorized

Integrity Data is accurate and unaltered

Availability Systems accessible when needed

Non-repudiation Actions are attributable

Measurement:

• Time to detect breaches
• Number of vulnerabilities
• Compliance audit results
• Mean time to patch

Trade-offs:

• Security vs usability (more security = more friction)

• Security vs performance (encryption adds latency)

• Security vs cost (security tools and expertise are expensive)

Maintainability

Definition: Ease of modifying the system over time.

Aspect Description

Modularity Components can change independently

Reusability Components can be repurposed

Analyzability Easy to understand the system

Modifiability Easy to make changes

Testability Easy to verify changes

Measurement:

• Time to implement typical change
• Defect injection rate per change
• Code complexity metrics
• Documentation coverage

Trade-offs:

• Maintainability vs performance (abstractions add overhead)

• Maintainability vs time-to-market (good design takes time)

• Maintainability vs specialization (generic = slower)

Quality Attribute Scenarios

How to Specify Quality Attributes

Use this template to make QAs measurable:

Source: [Who or what generates the stimulus?] Stimulus: [What event occurs?] Artifact: [What part of the system is affected?] Environment:[Under what conditions?] Response: [How should the system respond?] Measure: [How do we know it succeeded?]

Example Scenarios

Scalability Scenario:

Source: Marketing campaign Stimulus: 10x traffic spike Artifact: Web application Environment:Normal operation Response: Auto-scale to handle load Measure: Latency stays under 200ms at p99

Availability Scenario:

Source: Hardware failure Stimulus: Database server dies Artifact: Order processing system Environment:Peak business hours Response: Failover to replica Measure: Recovery in < 30 seconds, no data loss

Security Scenario:

Source: External attacker Stimulus: SQL injection attempt Artifact: User authentication Environment:Production Response: Block attack, alert security team Measure: Zero successful injections, alert within 5 minutes

ISO 25010 Quality Model

The ISO 25010 standard defines 8 quality characteristics:

Characteristic Sub-characteristics

Functional Suitability Completeness, correctness, appropriateness

Performance Efficiency Time behavior, resource utilization, capacity

Compatibility Co-existence, interoperability

Usability Learnability, operability, accessibility

Reliability Maturity, availability, fault tolerance, recoverability

Security Confidentiality, integrity, non-repudiation, accountability

Maintainability Modularity, reusability, analyzability, modifiability, testability

Portability Adaptability, installability, replaceability

Quality Attributes in System Design Interviews

How to Address QAs

• Ask about requirements: "What's the expected latency? Availability target?"

• State assumptions: "I'll assume we need 99.9% availability"

• Justify decisions: "I'm adding a cache here for performance"

• Acknowledge trade-offs: "This improves scalability but complicates consistency"

Common QA Trade-offs in Interviews

Decision Improves Hurts

Add caching Performance Consistency, complexity

Add replication Availability Consistency, cost

Use async processing Throughput Latency, complexity

Shard database Scalability Cross-shard queries

Add encryption Security Performance

Use microservices Maintainability, scalability Latency, complexity

QA Checklist for Design Reviews

Before finalizing a design, verify:

• Scalability: Can handle 10x growth?

• Reliability: Handles component failures?

• Availability: Meets uptime target?

• Performance: Meets latency/throughput targets?

• Security: Protects data and access?

• Maintainability: Easy to update and debug?

• Cost: Within budget at scale?

• Observability: Can monitor and troubleshoot?

Architectural Tactics by Quality Attribute

Scalability Tactics

Tactic Description

Horizontal scaling Add more instances

Load balancing Distribute traffic

Sharding Partition data

Caching Reduce repeated work

Async processing Decouple components

Availability Tactics

Tactic Description

Redundancy Multiple instances of components

Failover Automatic switch to backup

Health checks Detect failures early

Graceful degradation Reduce functionality vs complete failure

Geographic distribution Survive datacenter failures

Performance Tactics

Tactic Description

Caching Reduce computation/IO

CDN Serve content closer to users

Connection pooling Reuse expensive connections

Compression Reduce data transfer

Indexing Speed up queries

Security Tactics

Tactic Description

Encryption Protect data at rest and in transit

Authentication Verify identity

Authorization Control access

Audit logging Track actions

Input validation Prevent injection attacks

From Business Requirements to Quality Attributes

Translation Guide

Business Requirement Quality Attribute Technical Implication

"Must handle Black Friday traffic" Scalability Auto-scaling, elastic capacity

"Cannot lose orders" Reliability, durability Replication, backups, transactions

"Always available" Availability Redundancy, failover, monitoring

"Fast checkout" Performance Caching, optimization, CDN

"Protect customer data" Security Encryption, access control, auditing

"Easy to add features" Maintainability Modular design, clean architecture

"Regulatory compliance" Security, auditability Logging, encryption, access control

"Global users" Performance, availability CDN, geographic distribution

Related Skills

• design-interview-methodology

• Overall interview framework

• estimation-techniques

• Quantify capacity requirements

• cap-theorem

• Consistency/availability trade-offs (Phase 2)

• trade-off-analysis

• ATAM and decision frameworks (Phase 5)

• architectural-tactics

• Detailed tactics per attribute (Phase 5)

Related Commands

• /sd:analyze-nfrs [scope]

• Analyze quality attributes in code (Phase 5)

• /sd:explain <concept>

• Explain any quality attribute

Related Agents

• trade-off-analyzer

• Evaluate design trade-offs (Phase 2)

• sre-persona

• Reliability/observability perspective (Phase 5)

• security-architect

• Security implications (Phase 5)

Version History

• v1.0.0 (2025-12-26): Initial release

Last Updated

Date: 2025-12-26 Model: claude-opus-4-5-20251101