What are Software Quality Attributes?
Software Quality Attributes (QAs) are non-functional requirements that define
how well the software performs under specific conditions, not what it does,
but how it does it.
They serve as the architectural drivers in early design and are often used to
evaluate architectural decisions.
ISO/IEC 25010 Standard (Software Product Quality Model)
The ISO/IEC 25010 defines eight primary quality attributes:
Performance System response time, throughput, latency,
etc.
Scalability Ability to handle growth (users, data, transactions)
Security Protection against threats, data breaches,
unauthorized
access
Availability System uptime; fault-tolerance, redundancy
Maintainability Ease of making changes (bug fixes, updates)
Usability Ease of learning and using the system
Interoperability Ability to work with other systems
Reliability Continuity of correct service under defined conditions
Examples
Netflix uses availability and scalability as key attributes; ensures
millions of users can stream with minimal downtime.
Banking applications prioritize security, reliability, and auditability.
Mobile apps focus on usability and performance due to limited screen
size and real-time interaction.
Balancing Trade-offs in Software Design
Why Trade-offs?
Not all quality attributes can be maximized simultaneously. Improving one
attribute often leads to degradation of another.
This is called attribute interaction or architectural trade-offs.
Common Trade-offs
Trade-off Pair Description & Example
Performance vs. Encryption ensures security but adds computational
Security overhead (slower performance).
Availability vs. In distributed systems (like NoSQL databases), high
Consistency availability may reduce strict consistency (CAP
theorem).
Maintainability Highly modular code is easier to maintain but may
vs. Performance introduce overhead at runtime.
Usability vs. More authentication steps enhance security but reduce
Security usability.
Architectural Evaluation
Architectural Evaluation is a systematic assessment of whether a software
system’s architecture satisfies required quality attributes like performance,
availability, modifiability, and security.
Architectural evaluations are typically conducted:
Before system implementation, to mitigate risk
During re-architecture or scaling, to validate changes
For compliance or quality assurance in large enterprises
Techniques to Evaluate Trade-offs
1. ATAM (Architecture Tradeoff Analysis Method)
Structured method for analyzing architectural decisions based on
quality attribute goals.
2. Utility Tree (from SEI)
Helps prioritize quality attributes with scenarios and quantify trade-off
impacts.
3. Scenario-based Design
Define real-world use cases to evaluate how architectural choices
affect different attributes.
ATAM
The Architecture Tradeoff Analysis Method (ATAM) is a scenario-based
evaluation technique developed by the SEI (Software Engineering Institute)
to assess the consequences of architectural decisions on quality attributes.
Purpose
Identify architectural risks early
Document trade-offs and sensitivity points
Support better architectural decisions
Key Concepts in ATAM
Scenario Description of a situation involving stimulus and
response
(e.g., user load spike)
Tradeoff Point A decision where improving one quality
degrades another (e.g.,
performance vs. security)
Sensitivity Point A decision that affects a quality attribute significantly
Non-functional Quality attributes like scalability, modifiability, etc.
Requirements
ATAM Process Phases
ATAM is conducted over nine steps grouped into four phases:
Phase 1 - Preparation
1. Present ATAM Educate stakeholders about ATAM process and
goals
2. Present Business Drivers Business goals, constraints, quality goals
3. Present Architecture Architects describe the system, design
decisions
Phase 2 - Evaluation
4. Identify Architectural Approaches Patterns, tactics, decisions
used
5. Generate Quality Attribute Utility Tree List of quality goals
ranked by importance and risk
Example: Availability > Performance >
Modifiability
6. Analyze Architectural Approaches Match scenarios to
architecture; identify risks
Phase 3 - Consolidation
7. Brainstorm and Prioritize Scenarios Stakeholders create
additional scenarios
8. Analyze Tradeoffs Explore how architectural
decisions affect multiple attributes
Phase 4 - Reporting
9. Present Results Document risks, tradeoffs, non-risks, sensitivity
points
Roles in ATAM Evaluation
Evaluation Team Conducts and facilitates ATAM (often external
or SEI-trained)
Software Architects Present architecture and decisions
Project Stakeholders Provide scenarios, priorities, and risks
Domain Experts Validate assumptions and feasibility
ATAM Outputs
Risk Themes (Recurring architectural concerns)
Sensitivity and Tradeoff Points
Prioritized Scenarios
Utility Tree
Recommendations
Benefits of Using ATAM
Early risk identification Reduces cost of late-phase
architectural errors
Focus on quality attributes Aligns architecture with business
goals
Stakeholder involvement Ensures requirements are realistic
and complete
Informed decision-making Documents tradeoffs and rationale
for future
reference
