Most systems do not fail because they do the wrong thing.
They fail because they do the right thing too slowly, too unreliably, too insecurely or at too high a cost.
That is the world of non-functional requirements, often shortened to NFRs. And in my experience, it is where many of the most expensive production problems are quietly born.
What Are Non-Functional Requirements?
Functional requirements describe what a system does. "The customer can view their order history."
Non-functional requirements describe how well it does it. "Order history loads within two seconds for 95 percent of customers, is available 99.9 percent of the time, and only shows a customer their own orders."
Same feature. Completely different engineering challenge.
Why They Get Ignored
NFRs rarely appear in a user story. Business stakeholders assume they are obvious. Delivery teams assume someone else will define them. And testing them properly takes time that projects under pressure do not want to spend.
So they get skipped until the first production incident, when suddenly everyone cares a great deal.
"We will deal with performance later" is one of the most expensive sentences in technology.
The Categories That Matter Most
Performance
How fast does the system respond, and how much load can it handle? Always define performance under a specific load, not in isolation.
Availability and recovery
How much downtime is acceptable? If something fails, how quickly must the service be restored (recovery time objective) and how much data can be lost (recovery point objective)? These numbers drive architecture and cost dramatically.
Scalability
How will the system cope with growth in users, data and transactions over the next few years? Designing for ten times today's volume is very different from designing for a hundred times.
Security and compliance
Who can access what? What data is sensitive? Which regulations apply? Security requirements need to be designed in from the start, because retrofitting them is painful.
Maintainability
How easily can the system be changed? This affects every future project, even though it rarely appears in the business case.
Observability
When something goes wrong at 2 a.m., can the team see what is happening? Logs, metrics, tracing and alerting should be requirements, not extras.
Cost
What is acceptable to build, run and change the system? In the cloud era, a design choice can quietly double the monthly bill.
Make Them Measurable
"The system must be fast" is a wish, not a requirement.
A good NFR is specific and testable:
- 95 percent of product searches return results in under 2 seconds at 500 concurrent users
- The service is available 99.9 percent of the time during business hours
- In a regional outage, service is restored within 4 hours with no more than 15 minutes of data loss
- Personal data is encrypted in transit and at rest
If you cannot test it, you cannot prove you met it.
They Pull Against Each Other
Here is the part that makes NFRs genuinely interesting for architects: they conflict.
Higher availability costs more. Stronger security can reduce usability. Maximum performance can hurt maintainability. You cannot maximize all of them at once.
The architect's job is to help the business choose the right balance for this particular system, and to make those trade-offs visible rather than accidental.
How I Approach NFRs on a Project
- Raise them in the first week, not the last month.
- Use a short checklist of categories so nothing is forgotten.
- Ask the business for real numbers, and offer examples if they struggle.
- Tie the most important NFRs to specific design decisions.
- Make sure they are tested, especially performance and failover.
- Monitor them in production, because that is where they really matter.
Final Thought
Users rarely notice when non-functional requirements are met. They notice immediately when they are not.
Treat them as first-class requirements, and your systems will be the ones nobody has to talk about in the incident review.