Your requirement isn't non-functional. It's a quality requirement or a constraint, and they behave nothing alike

Stop saying non-functional

"Non-functional" is a leftover label. It tells you only that the statement is not a function. The CPRE Foundation Level syllabus (English v3.2.0, 26 February 2024) treats quality requirements and constraints as different kinds of requirement, with different work attached to each. The glossary (v2.2.0, 1 October 2025) keeps that split. Folding both into "NFR" is how a measurable reliability target and a non-negotiable platform edict end up in the same parking lot.

A quality requirement describes a desired characteristic of the system that you can, in principle, check after delivery. A constraint removes options from the solution space before design starts. Mixing them up does not make the project more agile. It makes the argument later, when someone tries to trade a legal limit against a performance wish.

This article is a comparison. Read the two columns as two jobs, not two synonyms. Then use the slider, the defect hunt, and the decision tree on a real sentence from your last workshop.

They do not behave the same

The table is the whole point. A quality requirement without a scale is an unfinished quality requirement. A constraint without an owner who actually holds the limit is an unfinished constraint. Neither is improved by calling it non-functional.

Write the quality need so later verification has something to measure:

Scale: search time
Measure: 95th percentile over 10 000 records
Target: under two seconds
Method: agreed reference data

Vague

Testable

Compare Vague and Testable

Vague ← → Testable

The left-hand card is what workshops produce when nobody is allowed to be pedantic. The right-hand card is the same need after someone names the actor, the measure, and the condition. The wipe is not decoration. It is the work.

Ambiguity is the usual hiding place

Natural-language requirements fail in boring, repeatable ways. The Foundation Level treats quality of specification as something you can inspect: terms that are defined, statements that can be checked, comparisons that have a reference. It does not examine you on a list of defect nicknames. The nicknames below are practice labels for problems the glossary already implies.

Nominalisation does the same damage without a flagged word. "Reporting shall be provided" hides who reports, to whom, and when. Incomplete comparisons ("better than the current system") hide the reference. If you only remember one inspection habit, remember this: every adverb and every "all" is a bet that nobody will ask "compared with what?"

Follow the work, not the label

When a statement arrives as "non-functional", split it before you store it.

flowchart TD
  A[Statement arrives] --> B{Removes options}
  B -->|Yes| C[Constraint]
  C --> D[Record the source and the limit]
  B -->|No| E{Named scale}
  E -->|Yes| F[Quality requirement]
  F --> G[Define measure, target, method]
  E -->|No| H[Not yet a requirement]
  H --> I[Go back to the stakeholder]

The tree is the flowchart in a form you can walk with a keyboard. Reduced motion does not hide any node; the static list under the live control is the whole argument.

A template that refuses empty slots

Trace the split, or it collapses again

The matrix is a working surface, not a score. Empty cells are the argument you have not had. If JavaScript never runs, the marks you authored are still visible as a static table.

What to take into the next meeting

Do not ban the phrase "non-functional" as a loyalty test. Ban it as a filing cabinet. When someone uses it, ask which of the two jobs they mean. If they mean a quality, ask for the scale. If they mean a constraint, ask who holds the limit. If they cannot answer, you do not yet have a requirement. You have a conversation that still needs a chair.

The Foundation Level will examine you on the distinction, not on this site's widgets. The widgets exist so the distinction is hard to skip when you are tired. Use them. Then write the two kinds down as if someone else will have to test them in six months, because someone else will.

How the distinction shows up in ordinary work

Start with the sentence someone wrote on a slide: "The solution must be secure, fast, and aligned with our architecture." That sentence is doing three jobs and naming none of them. Security might be a cluster of quality requirements (authentication latency, residual risk against a named threat) and a cluster of constraints (a mandated identity provider, a prohibition on storing card data). Speed is almost always a quality requirement in disguise, waiting for a scale. Architecture alignment is usually a constraint with a missing owner: whose architecture, which decision, which date.

A useful habit is to rewrite the slide as a list of statements, each with a kind. If you cannot assign a kind, the statement is not ready. If two people assign different kinds, you have found the argument early, which is the only cheap time to have it.

Quality requirements earn their keep at verification time. If the test method is "we will see how it feels in UAT", you have deferred the argument to the most expensive room in the programme. Constraints earn their keep at design time. If a constraint is discovered after a vendor is chosen, you do not have a requirements problem. You have a procurement problem that the requirements set failed to prevent.

There is a third failure, quieter than either: treating a quality target as if it were a constraint so that nobody can negotiate it. "It must be under a second" said as a law, with no stakeholder who will defend the cost of that second, is a quality requirement wearing a constraint costume. The costume will be removed in a steering meeting, and the specification will look like it lied. Write it as a quality requirement with a target, and record who owns the target. Then a later trade is a change, not a humiliation.

The opposite costume is also common. A statutory retention period is rewritten as "the system shall support flexible retention" because flexible sounds like a quality. It is not. The statute is a constraint. Flexibility, if anyone actually wants it, is a different requirement and probably a function: an administrator can set a period within the legal range. Split them. The legal range stays a constraint with a source. The administrator function stays a function. Any extra wish about how quickly a purge completes is a quality requirement with a scale.

When you inherit a backlog labelled NFR-01 through NFR-40, do not transcribe the labels. Walk each item through the decision tree. Some will die as unfinished conversation. Some will become constraints with a source you have to go and find. Some will become quality requirements that still need a measure. The walk is slower than a copy. It is the work the copy was invented to avoid, which is why the copy keeps failing in production.

None of this requires a new role. It requires that whoever is writing the specification is allowed to be pedantic in the room, and that "we already agreed it" is not allowed to mean "we agreed a slogan". The comparison columns at the top of this article are the test: if a statement cannot sit cleanly in one column, it is not yet a statement. It is still a meeting.

Write the distinction into the next artefact you actually own: the backlog item, the interface contract, the test idea, or the change request. If the artefact still says NFR, replace the label before you argue about the number. The number on a quality requirement is a target on a scale. The number on a constraint is usually a version, a date, or a prohibition. Mixing those numbers in one cell is how a spreadsheet becomes a fight.