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

1. Ask about requirements: "What's the expected latency? Availability target?"
2. State assumptions: "I'll assume we need 99.9% availability"
3. Justify decisions: "I'm adding a cache here for performance"
4. 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