Non-Functional Requirements
Correct functionality alone is not enough
Two systems can do the same thing but feel completely different. One responds within tens of milliseconds and survives a server failure; the other slows down under load and periodically becomes unavailable. Functionally, they are similar, but their non-functional requirements are different.
Non-functional requirements describe system properties and constraints: how fast, reliable, scalable, or secure the system must be while performing its functions.
Common groups of requirements
- Performance — acceptable latency and required throughput.
- Scalability — the ability to handle growth in users, requests, and data.
- Availability — how often the service must be ready to handle requests.
- Reliability — how predictably the system preserves correct behavior and data.
- Security — requirements for data access, transmission, and storage.
- Cost — infrastructure and operational constraints.
Not every system needs the maximum possible level in every category. An internal report generated once a day and a payment API have completely different priorities.
A good requirement can be checked
The phrase “the system must be fast” sounds reasonable, but it is almost useless. It does not tell us what counts as success or when the architecture stops satisfying the requirement.
Weak: The system must respond quickly.
Better: 95% of read requests must complete within 200 ms.In a real project, the number should come from the product, observations, and constraints, not from a desire to write a nice-looking metric. For now, the important principle is this: a non-functional requirement is useful when it can be measured or at least checked unambiguously.
Requirements can conflict
Higher availability can increase infrastructure cost. Stronger data consistency can add latency. Additional encryption and security checks also consume resources. That is why non-functional requirements do more than supplement the architecture — they force us to set priorities.