Functional vs Non-Functional Requirements
Requirements split into two kinds, and the difference quietly decides whether a project succeeds. One kind is what the software should do. The other is how well it should do it. Beginners remember the first and forget the second — which is exactly where a lot of software fails.
Functional requirements are the features and behaviors: "a user can reset their password". Non-functional requirements are the qualities and constraints: "login responds in under a second", "passwords are stored securely". Both are real requirements; only one is obvious.
Think of buying a car. Its functions are clear: it drives, it brakes, it carries five people. But you'd never choose on functions alone — you also care that it's safe, quiet, reliable, and fuel-efficient. Those qualities are the non-functional requirements, and they're often what actually makes or breaks the choice.
Functional Requirements
A functional requirement describes something the software does — a feature or behavior you could point to and demonstrate. "Users can create an account." "The app sends a confirmation email." "An admin can delete a comment." Each is a concrete action the system performs. These are the requirements teams naturally think of first, because they're the visible reason the software exists.
Non-Functional Requirements
A non-functional requirement describes how well the software must do its job — its qualities and constraints rather than its features. How fast it responds, how many users it handles at once, how secure the data is, how easy it is to use, how reliably it stays up. They don't add a new button; they set the bar every button has to clear.
| Functional (what it does) | Non-functional (how well) |
|---|---|
| A user can log in | Login responds in under a second |
| A user can set a reminder | The reminder fires within a minute of the chosen time |
| The app shows a habit list | It loads smoothly for 100,000 users at once |
| A user can save data | Data is encrypted and never lost |
Why Non-Functional Is Easy to Miss
Non-functional requirements are invisible until they're violated. Nobody notices "the page loads fast" — they only notice when it's slow. So they're easy to leave unstated, and that's dangerous: a feature that technically works but is painfully slow, insecure, or falls over under load has effectively failed, even though every functional requirement was met. Software that shines in a demo and collapses in the real world almost always missed its non-functional requirements.
The "-ilities"
Many non-functional requirements end in "-ility", so the whole family is nicknamed the -ilities: reliability, scalability, availability, usability, maintainability, and more. You don't need to memorize the list — just to remember that for every feature, there's a quiet question of how well, and naming it up front is what separates demo-ware from real software.
On Cadence, the reminders work shows both kinds. The functional requirement is plain: "users can set a daily reminder." But the non-functional ones are what make it trustworthy: the reminder must fire within a minute of the chosen time, and it must never double-send. Get the feature but miss those, and users get reminders at the wrong time or twice — and quietly stop trusting the app.
- "Requirements just means features." Features are the functional half. The non-functional half — speed, security, reliability — is just as much a requirement, and often the harder one.
- "Performance and security can be added later." They're requirements from the start. Bolting them on at the end is expensive and often impossible — they shape the design itself.
- "Non-functional requirements are optional nice-to-haves." They're frequently the hardest, most important constraints. A fast-enough, secure-enough bar can be tougher to hit than the feature itself.
- Naming non-functional requirements early is what separates software that works in a demo from software that survives the real world.
- It gives you a checklist beginners lack: for every feature, also ask how fast, how secure, how reliable, how usable it must be.
- The "-ilities" are vocabulary you'll meet again in the design, testing, and production chapters — they're where a lot of real engineering effort goes.
Knowledge Check
Which of these is a functional requirement?
- A user can reset their password
- The page responds in under one second
- The app supports 100,000 users at the same time
- All stored data is kept encrypted
What does a non-functional requirement describe?
- How well the software does its job — its qualities and constraints
- The specific features and actions the software offers
- The exact code used to build each feature
- Optional extras the team can choose to add later if there is any spare time
Why are non-functional requirements easy to miss?
- They're invisible until violated, so they often go unstated
- They almost never apply to real software
- They're so trivial that teams meet them automatically
- They genuinely don't affect whether the software succeeds or fails in the end
A team builds the reminders feature, and it works — but reminders sometimes fire an hour late. What kind of requirement did they miss?
- A non-functional requirement — that reminders fire on time
- A functional requirement — the feature doesn't exist at all
- No requirement at all — late reminders are perfectly fine
- A diagram requirement about how the feature is drawn
You got correct