# Quality Attribute Prioritizer

**Companion resource for Developer to Architect by Shameel Ahmed**
**Chapter 18: Balancing Quality Attributes**
**devtoarch.com/resources**

---

Use this worksheet at the start of a design engagement to establish which quality attributes matter most in this specific context. Prioritization prevents the common failure of optimizing everything equally.

**System:** ___________________________
**Context / Project:** ___________________________
**Date:** ___________________________
**Participants:** ___________________________

---

## Step 1: Score Business Priorities

Rate each business driver on a scale of 1-5 for this system:
1 = Not important, 3 = Moderately important, 5 = Critical

| Business Driver | Score (1-5) | Notes |
|----------------|-------------|-------|
| Revenue directly depends on system availability | | |
| User trust is a key differentiator | | |
| Rapid feature delivery is a competitive requirement | | |
| Cost efficiency is a primary constraint | | |
| Regulatory compliance is mandatory | | |
| System must handle unpredictable traffic spikes | | |
| Data accuracy is safety-critical | | |
| Team will need to extend the system frequently | | |

---

## Step 2: Rate Quality Attributes

For each quality attribute, score it 1-5 based on how important it is for this system, given the business priorities above.

| Quality Attribute | Definition | Score (1-5) |
|------------------|-----------|-------------|
| **Performance** | Response time and throughput under expected load | |
| **Scalability** | Ability to handle growth in users, data, or transactions | |
| **Availability** | Uptime and resistance to failures | |
| **Reliability** | Consistency and correctness of behavior over time | |
| **Security** | Protection from unauthorized access or malicious use | |
| **Maintainability** | Ease of making changes without introducing defects | |
| **Testability** | Ease of verifying correct behavior | |
| **Deployability** | Frequency and safety of releasing changes | |
| **Modifiability** | Ease of extending or changing behavior | |
| **Interoperability** | Ability to work with other systems and standards | |
| **Usability** | Ease of use for end users (if user-facing) | |
| **Cost efficiency** | Operating cost within acceptable bounds | |
| **Compliance** | Meeting regulatory and legal requirements | |
| **Auditability** | Ability to trace and verify system activity | |
| **Portability** | Ability to run on different platforms or providers | |

---

## Step 3: Identify Top Attributes

Based on your scoring, list the top 5 quality attributes in priority order.

| Priority | Quality Attribute | Why It Tops the List |
|----------|------------------|----------------------|
| 1 | | |
| 2 | | |
| 3 | | |
| 4 | | |
| 5 | | |

---

## Step 4: Document Known Trade-offs

Quality attributes conflict. Documenting known trade-offs up front prevents surprises later.

| If we optimize for... | We accept less of... | This is acceptable because... |
|----------------------|---------------------|------------------------------|
| | | |
| | | |
| | | |

---

## Step 5: Set Measurable Targets

For each top-priority attribute, define what "good enough" looks like in measurable terms.

| Attribute | Measure | Target | Rationale |
|-----------|---------|--------|-----------|
| | | | |
| | | | |
| | | | |

---

## Agreement Sign-off

All participants agree that these priorities and trade-offs reflect the system's actual requirements.

| Name | Role | Sign-off |
|------|------|---------|
| | | |
| | | |
| | | |

---

*From Developer to Architect by Shameel Ahmed | devtoarch.com | leanpub.com/devtoarch*
*E-Book ISBN: 978-93-6068-417-4*