Architecturally significant requirements are those requirements that have a measurable effect on a computer system’s architecture. This can comprise both software and hardware requirements. They are a subset of requirements, the subset that affects the architecture of a system in measurably identifiable ways. Relation to non-functional requirements and quality attributes Architecturally significant requirements were only recently, as of 2016, recognized as an important notion. When talking about architecture, the terms non-functional requirements or quality attributes are often used. However recent empirical studies show that, for a software system, not all non-functional requirements affect its architecture, and functional requirements can also affect its architecture. This research suggests that, when discussing software architecture, it is worth distinguishing which software requirements are architecturally significant, as well as whether they are functional. Characteristics Architecturally significant requirements can be characterized from the following aspects. Descriptive characteristics Architecturally significant requirements are often hard to define and articulate, tend to be expressed vaguely, tend to be initially neglected, tend to be hidden within other requirements, and are subjective, variable, and situational. Other requirements could also demonstrate these descriptive characteristics. However, architecturally significant requirements’ significance made these manifestations unique and challenging. Indicators A requirement that has wide effect, targets trade-off points, is strict (constraining, limiting, non-negotiable), assumption breaking, or difficult to achieve is likely to be architecturally significant. Indicators for architectural significance that have been reported in the literature include: The requirement is associated with high business value and/or technical risk. The requirement is a concern of a particularly influential stakeholder. The requirement has a first-of-a-kind character, e.g. none of the responsibilities of already existing components in the architecture addresses it. The requirement has QoS/SLA characteristics that deviate from all ones that are already satisfied by the evolving architecture. The requirement has caused budget overruns or client dissatisfaction in a previous project with a similar context. The OpenUP and Peter Eeles discuss additional criteria for architectural significance in several articles and presentations. Seven criteria for architectural significance were discussed at the European Conference on Software Architecture in 2020: business value/risk, stakeholder concern, quality level, external dependencies, cross-cutting, first-of-a-kind, source of problems on past projects. These criteria are described in an Heuristics 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. See discussion of