Quality Attributes and Architecturally Significant Requirements

Welcome to Chapter 2: Quality Attributes and Architecturally Significant Requirements. Architecture exists to deliver qualities: speed under load, staying up when parts fail, being safe to change, keeping data secret. This chapter shows how to turn vague wishes such as fast, reliable and secure into precise, testable requirements that can drive design decisions.

Ask any group of stakeholders what a system must do, and you will get a list of features: search for a flight, pay for a basket, book an appointment. Ask how well it must do them, and the answers are vaguer: it should be fast, it should not go down, it should be secure. Those second answers are quality attributes, and they are what architecture is mostly about. A requirement that has a measurable effect on the structure of a system is called an architecturally significant requirement. Most of them turn out to be quality attributes or constraints, rather than functions.

This diagram from Section two point one makes the point. Two ticketing systems have identical features: browse events, hold seats and pay. One sells tickets for a three hundred seat village hall. Its busiest moment brings a few requests a second, so one web application with one database is the right answer: cheap, simple and easy to change. The other sells a sixty thousand seat stadium tour. It must absorb a burst thousands of times larger, and never sell the same seat twice. So it needs a page cache, a virtual waiting room, a carefully designed seat inventory, partitioned storage and a payment queue. Same functions, completely different architectures. The difference comes entirely from quality attributes and constraints.

This chapter suits developers who are moving towards architecture. It also suits anyone who writes or reviews requirements. You will need some comfort with simple arithmetic: percentages, multiplication and division. It builds on Chapter 1's idea that architecture exists to satisfy stakeholders' concerns through trade-offs. This chapter makes those concerns precise. And it leads into Chapter 3, which introduces the design principles architects use to achieve these qualities.

There are eight sections. Section two point one separates functional requirements, quality attributes and constraints, and works through a concert-ticketing system on the day a big tour goes on sale. Section two point two introduces the international standard for product quality, with its nine characteristics, and shows how to use it as a memory aid rather than a form to fill in. Section two point three teaches the single most useful technique in the chapter: the six-part quality attribute scenario, which turns must be fast into a statement you can test.

Here is its shape. A scenario tells a short story, from left to right. A source, someone or something, produces a stimulus: an event the system must respond to, such as a burst of requests or a server crash. The stimulus reaches an artifact, the whole system or one part of it, within an environment: normal operation, a peak, a degraded state, or an attack. The artifact responds, and the response is judged by a response measure: the number. The stimulus and the response measure are the two parts people most often leave out, and the two that matter most. The example underneath puts it together: five hundred shoppers a second hit checkout on Black Friday, and orders are confirmed within one and a half seconds at the ninety-ninth percentile, with no lost orders.

Sections two point four to two point seven visit the qualities that most often shape architectures. Section two point four covers performance and scalability, with real arithmetic: latency and throughput, percentiles, queueing and the limits of adding more processors. Section two point five does the same for availability and reliability: the nines, the time between failures and the time to repair, and how components combine in series and in parallel. Section two point six covers the qualities of change: modifiability, testability and deployability. Section two point seven gathers security, usability and accessibility, interoperability, cost, energy efficiency, safety and regulatory qualities.

This is the chapter where the course starts to calculate. You will see why a request to a server that is ninety per cent busy takes, on average, ten times its service time. None of the mathematics is harder than school arithmetic. Numbers also expose false comfort. An average response time of a hundred and twenty milliseconds can hide the fact that one request in fifty takes more than a second. That is why professionals specify percentiles. Section two point eight closes the loop. No system can be fast, available, secure, cheap and easy to change all at once. It shows how a workshop and a utility tree turn a crowd of opinions into a ranked list, and which qualities conflict.

If you remember one thing from this chapter, make it this: a quality is not a requirement until it has a stimulus, a context and a measure. The checkout must be fast is a wish. When two thousand customers a minute submit orders during the Friday evening peak, ninety-nine per cent of checkouts complete within one and a half seconds: that is a requirement. It can be designed for, tested, monitored and argued about with evidence.

Sections two point one to two point three are best read in order, because the rest of the chapter uses their vocabulary. After that, you can dip into the qualities you need. The whole chapter takes about three hours to read. When a section calculates, work through the numbers yourself. That is how they become tools you can use in a real conversation. Each section ends with a few self-check questions. Answer them in your head before you look. When you are ready, take the optional chapter test: twenty multiple-choice questions and two written answers, in about forty five minutes. The pass mark is eighty per cent.

That is the map of Chapter 2. Start with Section two point one, where we separate functional requirements, quality attributes and constraints, and meet a ticketing system on its busiest day. See you there.