Functional and non-functional requirements: a guide for the founder paying the bill
Noon on a Monday. A founder opened enrollment for a course with 900 people on the waitlist. The homepage loaded; the checkout didn’t. He watched his launch conversion evaporate for forty minutes.
The studio’s answer was technically correct and commercially devastating: “that wasn’t in the scope.” And it wasn’t. The document he had approved described very well what the system did. It never said how many people could do it at the same time.
Functional requirements say what the software does. Non-functional requirements say how it behaves while doing it: how fast, for how many simultaneous users, at what availability, under which security rules. The difference between functional and non-functional requirements is the difference between a system that passes the test and a system that survives the launch.
Every founder writes the functional ones. Almost none write the non-functional ones. And it’s the non-functional ones that decide the price of the build, the behavior on launch day, and the size of your loss when something breaks.
What functional and non-functional requirements are
A functional requirement is something the system has to do. It has a subject, a verb, and an object. “The customer downloads a duplicate invoice.” It either does it or it doesn’t. It’s binary, which is why it’s easy to write, easy to test, and easy to enforce.
A non-functional requirement is a quality the system has to have while doing that. It isn’t a new function; it’s a constraint on every function. “The duplicate invoice appears in under 2 seconds, for up to 300 people at once, 99.5% of the month.” It isn’t binary. It’s a range, a limit, a number.
The academic literature calls the non-functional ones “quality attributes,” and there’s an international standard that organizes them: ISO/IEC 25010, which defines a software product’s quality characteristics (performance, security, reliability, maintainability, and others). You don’t need to memorize the standard. You need to know it exists, because it’s the source of the list of questions nobody asked you.
The most common confusion is thinking “non-functional” means “optional,” or “a technical thing the dev handles.” It’s the opposite. The functional part is what the dev handles alone, because you already explained it. The non-functional part is what he will decide on your behalf, quietly, if you say nothing.
Three examples of functional requirements (the easy part)
Take a scheduling system for a network of clinics:
- “The patient picks an available slot on a provider’s calendar and confirms the appointment.” Does it or doesn’t.
- “The system sends a text-message reminder 24 hours before the appointment.” Does it or doesn’t.
- “The receptionist reschedules an appointment and the old slot becomes available again.” Does it or doesn’t.
This is what any founder can write over coffee, and it’s what nearly every requirements document contains. It’s good. It’s necessary. And it’s insufficient, because none of those three sentences says what happens when 40 receptionists across 12 locations use the system at 8 a.m. on a Monday, which is exactly when it needs to work.
Non-functional requirements: the seven questions nobody asks you
Here’s the list that replaces the standard. Seven questions. If your document doesn’t answer them with numbers, you don’t have non-functional requirements. You have hope.
1. Performance. How fast?
Not “fast.” How many milliseconds, on which screen, in the worst case. Patient search returns in under 500ms. The monthly report can take 30 seconds, and that’s fine, as long as it tells the user it’s working.
2. Load. How many at the same time?
The number that was missing from the course launch. How many simultaneous users at peak? And what is the peak: payroll day, the enrollment window, Black Friday? Systems don’t fall over at the average. They fall over at the peak.
3. Availability. How much downtime is tolerable?
99% uptime sounds great until you do the math: that’s more than 7 hours of outage a month. 99.9% is 43 minutes. The difference between those two numbers is an architecture decision and a budget decision, and it’s yours, not the developer’s. Google’s SRE Book is the reference for how this gets defined without guessing.
4. Security and privacy. Who can see what?
If you handle health, financial, or any personal data, compliance isn’t an optional requirement; it’s a legal obligation with a penalty attached. For US health data, that’s HIPAA. Who accesses the record? Is the data encrypted at rest? Is there a log of who viewed what? That’s a non-functional requirement, and nobody is going to write it for you.
5. Usability and accessibility. Usable by whom?
“The receptionist completes a booking in fewer than 4 clicks.” “The app works on Android 9, because half our base is on old hardware.” A usability requirement with a number is a requirement. Without a number, it’s decoration.
6. Maintainability. Who can work on this later?
The requirement that saves the most money in year 2 and that almost nobody writes. Can another team take over this code? Are there automated tests? Is there documentation? You’re either buying an asset or a hostage.
7. Recovery. And when it goes wrong?
Backups how often? How long to restore? Do you accept losing the last 24 hours of data, or the last 5 minutes? Those two answers cost very different amounts, and the only thing worse than picking the expensive one is not picking, then finding out which one you bought on the day of the disaster.
A blank requirement isn’t empty. It has a default value.
This is the sentence the whole article is worth.
When you don’t specify how many simultaneous users the system handles, the developer doesn’t leave that field blank. He fills it in. And he fills it in with whatever is fastest to build and cheapest to run, because that’s what you asked for when you asked for “as fast and cheap as possible.” He’ll spin up a small instance, a database with no replica, no queue, no cache. And he’ll be right, because you didn’t ask for anything else.
The same goes for the other six. With no availability requirement, you bought “whatever.” With no backup requirement, you bought “there probably is one.” With no maintainability requirement, you bought code that exactly one person in the world understands, and that person doesn’t work for you.
None of this is bad faith on the studio’s part. It’s the mechanical consequence of a contract that only describes functions. The vendor delivers what’s written, and what’s written works: our founder’s checkout worked. It passed every test. With one user.
That’s why “how much does an app cost?” almost never has an honest answer before this conversation. The same set of features can cost $80,000 or $300,000 based on the non-functional requirements alone, and we’ve written before about why an app’s price depends more on you than on the studio.
The number test
If you take one thing from this article, take this:
A non-functional requirement without a number isn’t a requirement. It’s a wish.
“The system should be fast” is a wish. “The system should be secure” is a wish. “The system should be scalable” is the most expensive wish of all, because it sounds technical enough that everyone signs off without understanding what they bought.
A real non-functional requirement has three parts: a number, a condition, and a consequence.
| Wish | Requirement |
|---|---|
| “Search has to be fast.” | “Search by customer ID returns in under 500ms at the 95th percentile, with 200 simultaneous users. Above that, it shows a wait notice instead of an error.” |
| “The system can’t go down.” | “99.5% availability measured monthly, excluding maintenance windows announced 48 hours in advance.” |
| “It needs to be secure.” | “Health data encrypted at rest and in transit. Every record access is logged with user, date, and IP, retained for 12 months.” |
| “It has to handle the launch.” | “800 simultaneous checkouts with no degradation beyond 2 seconds. Load-tested before go-live, with the test as an acceptance criterion.” |
Notice what the right-hand column does: it turns an opinion into something that can be measured, tested, and enforced. It’s the same discipline as acceptance criteria, applied to the system’s qualities instead of its functions.
And notice the third part, the consequence. “Shows a wait notice instead of an error” is a product decision only you can make. The developer can tell you what it costs. He can’t tell you what’s acceptable to your customer.
Why the non-functional requirements set the price
A serious studio will quote you a higher price when you hand over good non-functional requirements. That feels backwards, and it’s the best signal there is.
The reason is simple: surviving 800 simultaneous checkouts takes infrastructure, queues, caching, and load testing. That’s real work, and real work has a price. When the quote goes up after you specify the load, what happened wasn’t an increase. It was the reveal of the true price, which had been hiding behind an assumption nobody had said out loud.
The cheap quote you got before writing the non-functional requirements wasn’t cheaper. It was the same product with the risk transferred to you.
This is also the best way to compare proposals. Send the seven numbers to three studios. Whoever comes back with the same price as before didn’t read them. Whoever raises the price and explains line by line where it went up, that’s the one you want at the table.
Where a non-functional requirement becomes an obligation
A number living in a Google Doc protects nobody. It has to travel through three documents to become an obligation:
In the requirements work, it’s born. That’s where you find out there’s an 8 a.m. peak and that half the base is on old Android. That work is yours, and we’ve already covered how to write a software requirements document without being technical.
In the acceptance criteria, it becomes a test. “Load test with 800 simultaneous sessions, executed before go-live” is a line that turns a promise into a verifiable event, with a date.
In the contract, it becomes a consequence. A non-functional requirement that doesn’t appear in the software development contract is a hallway conversation. If contracted availability is 99.5% and the system delivers 97%, what happens? If the answer is “we’ll talk about it,” you don’t have a requirement. You have a topic.
The course founder didn’t lose his launch because he hired bad people. He lost it because he bought a system that did everything he asked for, and he never asked that it work for 900 people at once. The document was right. It was just half-written.
Frequently asked questions
What are functional requirements?
They’re the functions the system has to perform: what it does. “The user resets their password by email,” “the manager exports the report as CSV.” They have a binary answer: the system either does it or it doesn’t. They’re the part of the scope almost every founder can write on their own.
What are non-functional requirements?
They’re the qualities and constraints that apply across the whole system: how fast, for how many simultaneous users, at what availability, with what level of security, how easy to maintain, with what recovery plan. They don’t describe a new function; they describe how all the functions behave under pressure. They’re the requirements that decide the price of the build and the outcome of launch day.
What’s the difference between a functional and a non-functional requirement?
The functional one is what; the non-functional one is how well. “Issue the invoice” is functional. “Issue the invoice in under 3 seconds, for 500 simultaneous orders, at 99.5% availability” adds the non-functional ones. The functional decides whether the software is useful; the non-functional decides whether it holds up.
What are 3 examples of functional requirements?
(1) “The patient picks an available slot and confirms the appointment.” (2) “The system sends a text-message reminder 24 hours before the appointment.” (3) “The receptionist reschedules an appointment and the old slot becomes available again.” Each describes a concrete system action with a binary answer.
What are the types of non-functional requirements?
The ones that matter to someone commissioning a build are seven: performance (how fast), load (how many at once), availability (how much downtime is tolerable), security and privacy (who sees what, and which regulation applies), usability and accessibility (usable by whom, on what device), maintainability (who can take over the code later), and recovery (backups and restore time).
Who writes the non-functional requirements: me or the studio?
The numbers are yours; the architecture is theirs. Only you know the peak is at 8 a.m., that losing 24 hours of data is unacceptable, and that half your users are on old phones. How to deliver that is the builder’s problem. The classic mistake is outsourcing the question along with the answer, then discovering on launch day which default value you bought without knowing it.