A functional requirement describes what a piece of software must do: a specific feature, action or behaviour. A non-functional requirement describes how well it must do it, setting a standard for a quality such as speed, security, reliability or accessibility. Together they define both the features and the quality of a bespoke software project.
Two kinds of requirement, one project
When you commission custom software, you and your supplier agree a list of requirements: the statements that say what is being built. These are normally drawn out during the discovery phase, the planning stage at the start of a project. Those statements fall into two groups, and knowing the difference helps you brief a project well and judge whether the finished work is acceptable.
Functional requirements are the features and behaviours. Non-functional requirements are the qualities those features must meet. A booking system that lets a customer reserve a table is meeting a functional requirement; the same system loading in under two seconds and staying online during a busy evening is meeting non-functional ones.
This entry explains the distinction so you can spot gaps in a brief. It is not a guide to writing the whole document. For that, our deeper read on the software requirements specification covers how to capture, structure and sign off requirements in full.
What functional requirements are
A functional requirement states something the software must do. It describes an action the system takes, a feature it offers or a rule it follows, usually from the point of view of the person using it. The international requirements standard ISO/IEC/IEEE 29148 sets out how requirements should be written and structured for exactly this purpose.
Functional requirements are the part of a brief most buyers find easy to picture, because they map onto what they want the software to achieve. Typical examples for a small business system include:
- A customer can create an account and reset a forgotten password.
- The system sends an email confirmation when an order is placed.
- A manager can export a sales report to a spreadsheet.
- An invoice number is generated automatically and never repeats.
Each one is a discrete thing the software does. If a functional requirement is missing, a feature you needed simply will not be there.
What non-functional requirements are
A non-functional requirement sets a standard for how well the software does its job. It does not add a feature; it puts a quality bar on the features that already exist. Common categories, as set out in established software-engineering references on functional and non-functional requirements, include:
- Performance: how fast the software responds, for example a page that loads in under two seconds.
- Security: how data is protected, for example encryption of personal data and compliance with UK GDPR.
- Reliability and availability: how dependable it is, for example 99.9% uptime during business hours.
- Scalability: how well it copes with growth, for example handling 200 users at once without slowing down.
- Accessibility and usability: how easily everyone can use it, for example meeting the WCAG accessibility guidelines.
Non-functional requirements are the ones buyers most often forget, because they describe qualities that feel assumed rather than features that feel chosen. That omission is costly: an unstated quality often resurfaces mid-build as a new demand, a common source of scope creep, and it is where a project quietly drifts off course.
Functional vs non-functional: side by side
The two types of requirement differ on a handful of things that matter when you are briefing and accepting a project:
| Functional requirement | Non-functional requirement | |
|---|---|---|
| Question it answers | What must the software do? | How well must it do it? |
| What it describes | A feature, action or behaviour | A quality: speed, security, reliability, accessibility |
| Example | A customer can pay by credit card | A card payment completes within three seconds |
| If it is missing | A needed feature is simply absent | The feature works, but is slow, insecure or unreliable |
| How buyers treat it | Usually listed; easy to picture | Often forgotten; feels assumed |
The two are not rivals. A complete brief needs both: functional requirements that name every feature, and non-functional requirements that say how good each feature has to be. A useful test is to take any functional requirement and ask "how fast, how secure, how reliable does this need to be?". The answers are your non-functional requirements.
Why each requirement must be specific and measurable
Whichever type a requirement is, it has to be specific enough to test. A requirement nobody can measure cannot be accepted, disputed or signed off fairly, and it is exactly the kind of wording that leads to a dispute at the end of a project.
"The system must be fast" is not a requirement; it is an opinion. "A search results page must load in under two seconds for up to 100 concurrent users" is a requirement, because either it does or it does not. The same discipline applies to functional requirements: "good reporting" should become a named list of reports, fields and formats.
Non-functional requirements drive cost more than buyers expect. Building software that handles ten users is far cheaper than building software that handles ten thousand, and a system that may be down overnight costs less than one that must never stop. Stating those targets up front lets your supplier design and price the right thing once, rather than rebuilding it later. Measurable requirements also become the basis for user acceptance testing: the checks you run before you accept and pay for the work.
Getting requirements right is where a project succeeds or fails Most software projects that go wrong were unclear on paper before a line of code was written, and the missing piece is usually the non-functional half. Red Eagle Tech's bespoke software development service starts every engagement with a structured discovery process that draws out both the features you need and the quality standards they must meet, so the brief is sound before the build begins.
