Imported from majiayu000/claude-skill-registry-data (
design/quality-attributes-taxonomy/SKILL.md). Install upstream withnpx skills add majiayu000/claude-skill-registry-data --skill quality-attributes-taxonomy. Copyright stays with the author.
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 scaleTrade-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 rateTrade-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 windowTrade-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 patchTrade-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 coverageTrade-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 p99Availability 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 lossSecurity 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 minutesISO 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 frameworkestimation-techniques- Quantify capacity requirementscap-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