Architecture is about refining the understanding. Concepts become clearer over time, which means they are reworked, redefined as the understanding progresses. In this direction, it is beneficial to distinguish between constraints and other non-functional requirements.

The most authoritative specification regarding NFRs is the ISO 25010 (and its predecessor ISO 9126). But it doesn’t define constraints as a separate category.

The first definition of constraint I stumbled upon was in Peter Eeles’ FURPS+ terminology. Here, the ‘+’ is used to refer to design, implementation, interface and physical requirements as opposed to functional, usability, reliability, performance and supportability requirements.

Attribute-driven Design makes a clearer distinction by calling the ‘+’ requirements as constraints. It also applies the term recursively: every iteration of the design has to take previously taken design decisions as constraints. Thereby the initial constraints^[1]Such as a strategic management decision to use a specific framework or organization-wide decisions from an architectural governance board of the organization, even specific requests from customer … Continue reading are mixed in with the later constraints introduced during the design, which also guarantees a consistent design.

The basic differentiating characteristic of constraints is that they actually belong to the solution domain, while NFRs belong to the problem domain. I find them most beneficial since they allow you to see what is just an internal decision, and so may be (sometimes should be) challenged.