Non-Functional Requirements

By the Syncfusion DevTutorials team · Last updated October 21, 2026

Turn "fast", "accessible" and "works everywhere" into requirements a check can measure: a number, a unit, and the condition it is tested under.

Fast, Accessible, Works Everywhere

Many specs end with three hopeful lines:

• It should be fast.
• It must be accessible.
• It must work in every country.

Everyone agrees with them.

But nobody can test them.

The agent cannot test them either. So it picks the easiest way to build, and hopes it is good enough.

Simple lesson: a quality you cannot measure is only a wish. An agent cannot build a wish.

A Real-World Example

You order a sofa and say, "It must fit in my flat."

The sofa arrives. It is too wide for the front door.

A better order says, "It must fit through an 80 cm door."

Now anyone can check it with a tape measure.

Words like "fast" are like "fit in my flat". Numbers are the tape measure.

Click the button and open the Agent tab.

• All three lines show NOT UNDERSTOOD.
• Open Preview & Checks. The checks measure the result.

The results:

• 100,000 rows take 9.2 seconds to export.
• Keyboard users cannot reach the Export button.
• German users see numbers in the wrong format.

Simple lesson: if a line cannot be tested, the agent guesses. The guess is usually the easy way, not the good way.

TL;DR

1. Non-functional requirement (NFR) = a line about how well the feature works, not what it does.
2. Common NFRs are about speed, accessibility and locale.

3. Every NFR needs three parts:

   • Measure = what you check.
   • Target = the number or standard to reach.
   • Condition = when and where you check it.
4. "Fast" becomes "under 3 seconds for 100,000 rows on a mid-range laptop".
5. "Accessible" becomes real keys, a name for the button, or a standard like WCAG 2.2 AA.
6. "Works everywhere" becomes named locales and what gets formatted.
7. If nobody can test a line, it is too vague.

What You Will Learn

In this lesson, you will learn:

1. What a non-functional requirement is.
2. The three parts every NFR needs.
3. How to write a speed line you can test.
4. How to write an accessibility line you can test.
5. How to write a clear locale line.

Three Parts of an NFR

Measure, Target, Condition

Every good NFR answers three questions.

What do you measure?

• How long the export takes
• Whether the keyboard can reach the button
• How numbers are written

What is the target?

• Under 3 seconds
• WCAG 2.2 AA
• German number format

Under what condition?

• 100,000 rows
• A mid-range laptop
• Users in the en-US and de-DE locales

If one part is missing, people argue about whether the line was met.

Example:

The export should be fast.

Nobody can check this.

Exporting 100,000 rows shall finish in under 3 seconds on a mid-range laptop.

Anyone can check this, and they all get the same answer.

Watch three wishes turn into three checks. Each step makes one line testable.

Each testable line turns one check green.

Simple lesson: give every NFR a measure, a target and a condition.

Speed

A Number, a Unit and a Size

A speed line needs three things:

• A number, like 3
• A unit, like seconds
• A size, like 100,000 rows

Example:

Exporting 100,000 rows shall finish in under 3 seconds on a mid-range laptop.

Leave out the size, and the line is still a guess. Fast for 10 rows may be slow for 100,000.

p95 = 95 Out of 100

For a server, you can use p95.

p95 = 95 out of 100 requests must be this fast or faster.

An average can hide a few very slow requests. p95 shows them.

Watch one speed line become testable, one part at a time.

The check only passes when the line has the number, the unit and the size.

With a clear speed line, the agent picks a faster way to build:

• React: it builds the file in a Web Worker, so the page does not freeze.
• ASP.NET Core: it reads orders in pages, instead of loading them all at once.

Simple lesson: a time without a size is not a test.

Accessibility

Real Keys, a Name or a Standard

Accessibility = people can use the feature with a keyboard or a screen reader.

"Must be accessible" is one of the most common vague lines.

Without details, the agent may build:

• a clickable box instead of a real button
• an icon with no name
• a button the keyboard cannot reach

It looks fine. But it fails for keyboard and screen reader users.

Instead, write what must happen.

Example:

The Export button shall be reachable with Tab.
Pressing Enter shall start the export.
The button's accessible name shall be "Export to Excel".

Accessible name = the words a screen reader says for the button.

You can also name a standard:

The page shall meet WCAG 2.2 AA.

WCAG = a list of accessibility rules many companies use. A tester can check each rule.

For a file from a server, accessibility can mean:

• a header row with column names
• a sheet with a clear name

Locale

Name the Locales and What Is Formatted

Locale = the country and language settings that decide how numbers and dates look.

The same number looks different in different locales:

• en-US: 1,250.00
• de-DE: 1.250,00

"Works everywhere" hides this choice.

Ask:

• How are numbers written?
• How are dates written?
• How is money written?

If people read the file, name the locales to test:

Numbers and dates shall use the user's locale. Tested with en-US and de-DE.

If a machine reads the file, the answer is the opposite. A machine needs one fixed format on every server:

Numbers shall use the invariant culture: 1250.00.

Invariant culture = one fixed format that never changes with the server's settings.

Watch the locale line become clear.

Once the line names the format, the check passes.

Simple lesson: say who reads the numbers, then name the format they need.

Lab Exercise: Give Every NFR a Number

QA has sent real targets.

Rewrite the three vague lines. Each one needs:

• a measure
• a target
• a condition

Press Check my spec.

All three checks should pass. Open Preview & Checks to see the results change.

What Changes per Tool

The ideas are the same in every tool. Only the place changes.

Some NFRs apply to every feature, like an accessibility standard. Put those in the repo docs too, so every feature gets them.

Common Mistakes

Exercises

These exercises help you turn wishes into lines you can test.

Press Check when you are ready. Use Show Hint if you get stuck.

What to Remember

• An NFR says how well the feature works.
• Every NFR needs a measure, a target and a condition.
• A speed line needs a number, a unit and a size.
• An accessibility line needs real keys, a name or a standard.
• A locale line needs locale codes and what is formatted.
• Machines usually need one fixed format.
• If nobody can test a line, it is too vague.

Further Reading

• WCAG 2.2, by the W3C: the accessibility standard.
• Intl.NumberFormat on MDN: how numbers change by locale.
• GitHub Spec Kit: success criteria in a Spec Kit spec.

Next: Task Planning. You will learn how to split work between several agents. Each agent can then work without getting in the way of the others.