A requirement with a broad effect targets trade-off points, is strict (constraining, limiting, non-negotiable), assumption-breaking, or difficult to achieve, and is likely to be architecturally significant.
When a requirement specifies a software system’s quality attributes, refers to its core features, imposes constraints on it, or defines the environment in which it will run, it is likely to be architecturally significant.
Quality attribute scenarios[2] are one way to achieve the S (specific) and the M (measured) criteria in SMART.
[7] It has been suggested that architecture analysis and design be kept lightweight and flexible; quality attribute trees for specific application genres and technology domains can support such approaches.
[10] Exemplary advice on addressing system quality attributes (including architecturally significant requirements) is available in the literature.