quality-attributes-taxonomy

What this skill does

# 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:**

```text
- 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:**

```text
- 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:**

```text
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:**

```text
- 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:**

```text
- 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:**

```text
- 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:

```text
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:**

```text
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:**

```text
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:**

```text
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 toleran