Skip to main content

Command Palette

Search for a command to run...

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

FeatureAttributeDefinitionStakeholder Concern
AvailabilitySystem ready when neededUptime, business continuity
PerformanceTimely responseUser experience, throughput
SecurityResist attacksData protection, compliance
ModifiabilityEase of changeTime-to-market, maintenance cost
TestabilityEase of testingQuality assurance, confidence
UsabilityEase of useUser adoption, productivity

Extended Quality Attributes

AttributeDefinition
ScalabilityHandle growing load by adding resources
InteroperabilityExchange information with other systems
PortabilityRun in different environments
DeployabilityEase of deployment to production
ObservabilityUnderstand 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
SecurityPerformance, UsabilityEncryption adds latency; MFA adds friction
PerformanceModifiability, CostHighly optimized code is harder to change
AvailabilityCostRedundancy requires additional infrastructure
ModifiabilityPerformanceAbstraction layers add overhead
UsabilitySecurityConvenience features may create vulnerabilities

Trade-off Analysis Process

  1. Identify Scenarios: List quality attribute scenarios with priorities
  2. Evaluate Options: For each architectural decision, assess impact on each scenario
  3. Document Trade-offs: Record what you're sacrificing and why
  4. Validate with Stakeholders: Ensure business accepts the trade-offs
  5. Create ADRs: Document decisions in Architecture Decision Records

Quality Attributes by Stakeholder

Different stakeholders prioritize different attributes:

StakeholderTop PrioritiesSecondary Concerns
End UsersPerformance, Usability, AvailabilitySecurity (implicit)
BusinessAvailability, Security, CostTime-to-market
OperationsObservability, Deployability, ReliabilityAutomation
DevelopmentModifiability, TestabilityDeveloper experience
Security/ComplianceSecurity, AuditabilityPerformance 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


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

Sources