Architectural Drivers
The handful of requirements whose change would force the structure to change — the only ones worth designing against.
A system may carry four hundred requirements and six drivers. Drivers are the requirements with structural leverage: change one and the shape of the system changes with it.
How to find them
For each candidate requirement ask: if this were relaxed by an order of magnitude, would I build the same thing? If yes, it is not a driver. Ten thousand orders a day and a hundred thousand orders a day are usually the same architecture. A hundred thousand and a hundred million are not.
Drivers come from four places: the few functional requirements that are structurally significant (a multi-tenant boundary, a regulated audit trail), quality attributes with hard numbers, non-negotiable technical or organisational constraints, and adopted principles.
Industry example
Stripe's dominant driver is not throughput — payments volume is modest next to an ad exchange. It is correctness under retry. Because clients time out and retry over unreliable networks, and because the operation moves money, the system must guarantee that a repeated request does not create a second charge.
That single driver propagates everywhere: idempotency keys as a first-class API concept, request records persisted before side effects, an events-and-webhooks model with at-least-once delivery and consumer-side deduplication, and reconciliation as a standing process rather than an incident response. None of that is implied by the functional requirement "charge a card".
Contrast with a driver that sounds similar but pulls the opposite way: an analytics ingest pipeline also receives duplicates, but a duplicated page-view costs nothing, so the architecture spends nothing on preventing it.
Failure scenario
Treating every requirement as a driver produces an architecture that satisfies nothing well and takes three years. Treating none of them as drivers produces a design that works right up to the first quarter of real growth.
Trade-off
Naming six drivers means explicitly deprioritising the other 394. That is uncomfortable, and it is the job. Write down which ones you set aside and why, because that list is the first thing to re-read when the system starts creaking.
Interview question
"Here is a product brief. Name the three architectural drivers and tell me what you would build differently if each one were removed."