Quality is not something you "test into" a system — it's designed in through architecture. The architecture determines whether a system can be fast, secure, reliable, and maintainable. Quality attributes (also called "non-functional requirements" or "-ilities") are the primary drivers of most architectural decisions.
8.1 ISO 25010 Product Quality Model
ISO 25010 defines eight quality characteristics for software products. This is the standard vocabulary used to discuss quality across the industry.
8.2 Quality Scenarios
Quality attributes like "the system should be fast" are too vague to be useful. A quality scenario makes them concrete and measurable — specific enough to test and verify.
A quality scenario has six parts:
Example Quality Scenarios
| Quality | Scenario |
|---|---|
| Performance | "Under normal load (1000 concurrent users), the system responds to search queries within 2 seconds for the 95th percentile." |
| Availability | "When a database node fails, the system switches to a replica within 30 seconds with no data loss." |
| Modifiability | "A developer can add a new payment provider within 3 person-days without modifying existing payment code." |
| Security | "An unauthorized user attempting to access admin APIs receives a 403 response; the attempt is logged and an alert is triggered." |
| Testability | "A developer can run all unit tests for a single module in under 60 seconds in isolation." |
8.3 Quality Trade-offs
You cannot maximize all quality attributes simultaneously — they tension against each other. Architecture is fundamentally about making informed trade-offs between competing qualities.
8.4 ATAM — Architecture Tradeoff Analysis Method
ATAM is a structured method for evaluating architecture against quality goals. It brings together stakeholders, architects, and evaluators to systematically identify risks, sensitivity points, and trade-off points.
| Step | Activity |
|---|---|
| 1 | Present the architecture and business drivers |
| 2 | Identify architectural approaches (patterns, tactics used) |
| 3 | Generate quality attribute utility tree (prioritize quality goals) |
| 4 | Analyze approaches against scenarios |
| 5 | Identify sensitivity points and trade-off points |
| 6 | Identify risks and non-risks |
| ATAM Term | Definition |
|---|---|
| Sensitivity Point | A property that is critical to achieving a particular quality goal. Changing it significantly impacts that quality. |
| Trade-off Point | A property that affects multiple quality attributes — improving one quality degrades another. |
| Risk | An architecturally significant decision with potentially negative outcome. |
| Non-risk | A decision that is considered safe upon analysis. |
8.5 Quality Metrics
| Metric | What It Measures | Why It Matters |
|---|---|---|
| Cyclomatic Complexity | Number of independent paths through code | High complexity = hard to test and maintain |
| Afferent Coupling (Ca) | How many modules depend on this one | High Ca = high responsibility, risky to change |
| Efferent Coupling (Ce) | How many modules this depends on | High Ce = fragile, many reasons to change |
| Instability (I = Ce/(Ca+Ce)) | Tendency to change (0=stable, 1=unstable) | Stable modules should be abstract; unstable ones concrete |
Fitness Functions — Automated Architecture Guardrails
Fitness functions are automated tests that verify architectural properties. Instead of relying on manual code reviews to catch architecture violations, you codify the rules and run them in CI/CD.
Examples:
ArchUnit(Java): "Classes in packagedomainmust not depend on classes in packageinfrastructure"- Performance test: "The 95th percentile response time must be under 200ms"
- Dependency check: "No circular dependencies between top-level packages"
- Security scan: "No high-severity CVEs in dependencies"
Fitness functions make quality continuous and automated rather than periodic and manual.