Architecturally Significant Requirement
also called ASR
A requirement whose satisfaction demands a structural decision, as opposed to one that can be met by any reasonable implementation.
Most requirements are not architecturally significant. A new report, a validation rule, an additional field — any competent structure accommodates them.
A requirement is architecturally significant when meeting it constrains the structure: a 99.99% availability target forces multi-zone deployment and automated failover; a data residency rule forces regional partitioning; a 10× growth projection forces a scaling axis to be chosen; an integration with a fixed legacy protocol forces an adaptation layer.
The test: would satisfying this change how the system is decomposed, deployed or connected? If not, it is an implementation concern and architecture should not spend attention on it.
Why the filter matters: architectural attention is scarce, and a design process that treats every requirement as significant produces slow decisions and over-specified structures. Identifying the small number — usually five to fifteen — that actually drive the design is what makes an architecture defensible and reviewable.
The set that drives design is typically composed of a few key quality attributes, the constraints that cannot be traded, and a handful of high-risk functional requirements where the difficulty is structural rather than logical.