Cross-Functional Requirement
A quality the system must exhibit across its features rather than a behaviour it must perform, so named because it cuts across all functionality.
The traditional term is "non-functional", and it is actively unhelpful: it sounds optional, it defines things by what they are not, and it invites deferral. "Cross-functional" describes them accurately — they apply across every feature rather than to any one of them.
The distinction in practice: functional requirements say what the system does — a user can place an order. Cross-functional requirements say how well — the order is placed within 500 ms, at 99.95% availability, with an audit record, accessible to screen readers, and compliant with data residency rules.
Why the naming affects outcomes: functional requirements are visible in a backlog and get built. Cross-functional ones are invisible unless someone insists, and they are the ones that cannot be retrofitted — security, availability, scalability and auditability are architectural properties, not features to be added in a later sprint.
The discipline that makes them real: state each one as a measurable scenario with a stimulus, an environment and a response measure, and attach it to the acceptance criteria of the features it constrains. An unquantified quality — "the system should be fast" — cannot be designed for, tested, or argued about productively.