quality attributes
Quality Attributes: Design for Non-Functional Requirements
Quality attributes are measurable properties of a system that indicate how well it satisfies stakeholder needs beyond basic functionality, including availability, performance, security, and modifiability.
Quality Attributes: Design for Non-Functional Requirements
TL;DR
Quality attributes (also called non-functional requirements or NFRs) are the properties of a system that determine how well it performs its functions—not what it does. Architects use architectural tactics to achieve quality attributes, making conscious trade-offs since optimizing one attribute often impacts others.
Key Takeaways
- Beyond functionality: Quality attributes determine system success as much as features
- Measurable: Each attribute should have quantifiable acceptance criteria
- Trade-offs required: Improving one attribute often degrades another
- Tactics-driven: Specific design patterns and tactics achieve each attribute
- Stakeholder-specific: Different stakeholders prioritize different attributes
Why Quality Attributes Matter
Functionality is not enough. A system that does what it's supposed to but is slow, insecure, or impossible to modify will fail. Studies show:
- 80% of system failures are due to quality attribute issues, not functional bugs
- Poor modifiability leads to 10-25% annual increases in maintenance costs
- Performance issues cause 40% of e-commerce cart abandonment
- Security breaches average $4.45M per incident (IBM, 2023)
Architecture's Primary Concern
Functionality can be achieved with almost any architecture. The architecture's job is primarily to achieve quality attributes while enabling functionality.
The Core Quality Attributes
| Feature | Attribute | Definition | Stakeholder Concern |
|---|---|---|---|
| Availability | System ready when needed | Uptime, business continuity | |
| Performance | Timely response | User experience, throughput | |
| Security | Resist attacks | Data protection, compliance | |
| Modifiability | Ease of change | Time-to-market, maintenance cost | |
| Testability | Ease of testing | Quality assurance, confidence | |
| Usability | Ease of use | User adoption, productivity |
Extended Quality Attributes
| Attribute | Definition |
|---|---|
| Scalability | Handle growing load by adding resources |
| Interoperability | Exchange information with other systems |
| Portability | Run in different environments |
| Deployability | Ease of deployment to production |
| Observability | Understand system state from external outputs |
Quality Attribute Scenarios
Quality attributes must be measurable. We express them as scenarios with six parts:
┌─────────────────────────────────────────────────────────────┐
│ Quality Attribute Scenario │
├──────────────┬──────────────────────────────────────────────┤
│ Source │ Who/what generates the stimulus │
├──────────────┼──────────────────────────────────────────────┤
│ Stimulus │ The event or condition │
├──────────────┼──────────────────────────────────────────────┤
│ Artifact │ What part of system is affected │
├──────────────┼──────────────────────────────────────────────┤
│ Environment │ Under what conditions │
├──────────────┼──────────────────────────────────────────────┤
│ Response │ How the system should respond │
├──────────────┼──────────────────────────────────────────────┤
│ Measure │ How we measure the response │
└──────────────┴──────────────────────────────────────────────┘
Architectural Tactics
Tactics are design decisions that influence the achievement of a quality attribute. They're the building blocks architects use to design for quality.
Availability Tactics
Availability Tactics
├── Detect Faults
│ ├── Ping/Echo
│ ├── Heartbeat
│ ├── Voting (redundant components)
│ ├── Exception Handling
│ └── Self-Test
├── Recover from Faults
│ ├── Active Redundancy (hot standby)
│ ├── Passive Redundancy (warm standby)
│ ├── Spare (cold standby)
│ ├── Rollback
│ ├── Retry
│ └── Ignore Faulty Behavior
└── Prevent Faults
├── Removal from Service
├── Transactions
├── Process Monitor
└── Exception Prevention
Performance Tactics
Performance Tactics
├── Control Resource Demand
│ ├── Manage Sampling Rate
│ ├── Limit Event Response
│ ├── Prioritize Events
│ ├── Reduce Overhead
│ └── Bound Execution Times
├── Manage Resources
│ ├── Increase Resources
│ ├── Introduce Concurrency
│ ├── Maintain Multiple Copies (caching)
│ └── Bound Queue Sizes
└── Arbitrate Resources
├── Scheduling Policy
└── Load Balancing
Security Tactics
Security Tactics
├── Detect Attacks
│ ├── Intrusion Detection
│ └── Monitoring/Logging
├── Resist Attacks
│ ├── Authenticate Actors
│ ├── Authorize Actors
│ ├── Maintain Data Confidentiality
│ ├── Maintain Data Integrity
│ ├── Limit Exposure
│ └── Limit Access
├── React to Attacks
│ ├── Revoke Access
│ ├── Lock Account
│ └── Inform Actors
└── Recover from Attacks
├── Audit Trail
└── Restore State
Modifiability Tactics
Modifiability Tactics
├── Reduce Size of Module
│ └── Split Module
├── Increase Cohesion
│ └── Increase Semantic Coherence
├── Reduce Coupling
│ ├── Encapsulate
│ ├── Use an Intermediary
│ ├── Restrict Dependencies
│ └── Abstract Common Services
└── Defer Binding
├── Compile Time
├── Build Time
├── Deployment Time
├── Startup Time
└── Runtime
Trade-off Analysis
No Free Lunch
Improving one quality attribute often degrades another. Effective architecture requires conscious trade-offs aligned with business priorities.
Common Trade-offs
| If You Improve... | You May Degrade... | Example |
|---|---|---|
| Security | Performance, Usability | Encryption adds latency; MFA adds friction |
| Performance | Modifiability, Cost | Highly optimized code is harder to change |
| Availability | Cost | Redundancy requires additional infrastructure |
| Modifiability | Performance | Abstraction layers add overhead |
| Usability | Security | Convenience features may create vulnerabilities |
Trade-off Analysis Process
- Identify Scenarios: List quality attribute scenarios with priorities
- Evaluate Options: For each architectural decision, assess impact on each scenario
- Document Trade-offs: Record what you're sacrificing and why
- Validate with Stakeholders: Ensure business accepts the trade-offs
- Create ADRs: Document decisions in Architecture Decision Records
Quality Attributes by Stakeholder
Different stakeholders prioritize different attributes:
| Stakeholder | Top Priorities | Secondary Concerns |
|---|---|---|
| End Users | Performance, Usability, Availability | Security (implicit) |
| Business | Availability, Security, Cost | Time-to-market |
| Operations | Observability, Deployability, Reliability | Automation |
| Development | Modifiability, Testability | Developer experience |
| Security/Compliance | Security, Auditability | Performance impact |
Measuring Quality Attributes
Each attribute should have quantifiable metrics:
Availability Metrics
- Uptime: Percentage of time system is operational (99.9% = 8.76 hours/year downtime)
- MTBF: Mean Time Between Failures
- MTTR: Mean Time To Recovery
Performance Metrics
- Response Time: End-to-end latency (p50, p95, p99)
- Throughput: Requests per second
- Utilization: Resource usage percentage
Security Metrics
- Vulnerability Count: Open critical/high vulnerabilities
- MTTD: Mean Time To Detect (security incidents)
- MTTR: Mean Time To Remediate
Modifiability Metrics
- Change Lead Time: Time from commit to production
- Change Failure Rate: Percentage of changes causing incidents
- Coupling Metrics: Afferent/efferent coupling, instability
Implementation Guide
Step 1: Elicit Quality Requirements
For each critical use case:
1. Identify relevant quality attributes
2. Write quality attribute scenarios
3. Prioritize scenarios (high/medium/low)
4. Get stakeholder sign-off on priorities
Step 2: Select Tactics
For each high-priority scenario:
1. Review applicable tactics
2. Evaluate trade-offs with other scenarios
3. Select tactics that balance requirements
4. Document decisions (ADRs)
Step 3: Design Architecture
Apply selected tactics to architecture:
1. Choose patterns that embody tactics
2. Design components and interactions
3. Validate against scenarios
4. Review trade-offs with stakeholders
Step 4: Validate and Monitor
Ensure quality attributes are achieved:
1. Define SLIs/SLOs for each attribute
2. Implement monitoring and alerting
3. Conduct architecture evaluations (ATAM)
4. Iterate based on production data
Related Topics
- Prerequisites: What is Enterprise Architecture?
- Deep Dives: Availability, Performance, Security
- Frameworks: AWS Well-Architected
Quick Reference Card
Quality Attributes at a Glance
CORE ATTRIBUTES
├── Availability → Uptime, fault tolerance
├── Performance → Response time, throughput
├── Security → Confidentiality, integrity, authentication
├── Modifiability → Change cost, extensibility
├── Testability → Observability, controllability
└── Usability → Learnability, efficiency
SCENARIO TEMPLATE
[Source] → [Stimulus] → [Artifact] in [Environment]
→ [Response] measured by [Metric]
COMMON TRADE-OFFS
Security ←→ Performance (encryption overhead)
Availability ←→ Cost (redundancy expense)
Performance ←→ Modifiability (optimization complexity)
DESIGN APPROACH
1. Write measurable scenarios
2. Prioritize with stakeholders
3. Select appropriate tactics
4. Accept and document trade-offs
5. Validate in production