Non-Functional Acceptance
Treating quality-attribute targets as acceptance criteria with automated verification, so a release can fail on latency the way it fails on a broken feature.
Functional acceptance is routine: the story has criteria, tests assert them, and a failure blocks the release. Non-functional requirements are usually written into a document and verified, if at all, by a performance test late in a programme whose results arrive too late to change any structural decision.
Making them acceptance criteria means each target from the NFR matrix has a named automated check, a threshold, and a place in the pipeline where failing it stops the change. Latency has a load test at a defined workload; recovery has an automated failover exercise; security has scanning with severity thresholds; accessibility has an automated pass plus a scheduled manual audit.
The important consequence is timing. A latency budget checked on every change identifies the change that broke it, which is a five-minute fix. The same budget checked quarterly identifies that something in three hundred changes broke it, which is an investigation. Continuous verification is worth more than thorough verification here, because attribution is most of the cost of fixing.