Functional vs Non-Functional Requirements
Definitions
Requirements fall into two fundamental categories:
Functional Requirements (FR) describe what the system does — the specific actions, behaviours, inputs, and outputs. They are the verbs of the system. If a functional requirement is not met, the system is fundamentally broken.
Non-Functional Requirements (NFR) describe how well the system performs its functions — the quality attributes, constraints, and characteristics. They are the adjectives and adverbs of the system. NFRs often dictate the entire system architecture because they constrain the solution space far more severely than FRs do.
Examples
For an e-commerce website:
| Functional Requirements (FRs) | Non-Functional Requirements (NFRs) |
|---|---|
| Allow a user to add an item to a shopping cart | Page load time < 2 seconds under normal load |
| Calculate total cost including VAT and delivery | 99.9% uptime per month (~43 minutes maximum downtime) |
| Send a confirmation email on successful payment | WCAG 2.1 AA accessibility compliance |
| Display order history for the past 12 months | Passwords stored using bcrypt with a salt factor of 12 |
The “-ilities” (NFR Categories)
NFRs are often grouped under the mnemonic “-ilities”:
- Scalability: can the system handle growth? (Vertical: bigger servers. Horizontal: more servers. Elastic: auto-scaling based on load.)
- Reliability: does it work correctly over time? (Availability, fault tolerance, recovery.)
- Maintainability: can it be modified easily? (Code clarity, modularity, documentation, test coverage.)
- Portability: can it run in different environments? (OS independence, containerisation, cloud-agnostic design.)
- Usability: can humans use it effectively? (Learnability, efficiency, error rates, satisfaction.)
Other common NFRs include security, performance, and compliance.
Latency vs Throughput
A common source of confusion within performance NFRs:
- Latency: the time required to complete a single operation. “The page must load in under 2 seconds.”
- Throughput: the number of operations the system can handle concurrently. “The system shall handle 5,000 transactions per second.”
You often must design differently to optimise one over the other. A system optimised for extremely low latency (single-threaded, in-memory, no coordination) may have poor throughput. A system optimised for high throughput (distributed, parallel, batched) may have higher per-operation latency.
NFRs Beget FRs
An NFR often generates specific functional requirements:
- NFR: “The system must comply with GDPR.”
- Generated FRs: “The system shall provide a button for the user to request deletion of all personal data.” “The system shall log every access to personal data with timestamp and user ID.” “The system shall encrypt personal data at rest using AES-256.”
This is how architectural security NFRs cascade into concrete, implementable, testable FRs.
Fit Criteria
Every NFR needs a fit criterion — a measurable, testable target. Without one, the NFR is indistinguishable from a wish.
| NFR (vague) | Fit criterion (testable) |
|---|---|
| “The system should be fast” | 95th percentile response time < 300 ms for logged-in users |
| ”The system should be reliable” | 99.99% uptime per calendar month (~4.3 minutes downtime max) |
| “The system should be secure” | OWASP Top 10 vulnerabilities absent; penetration test passed by an accredited third party |
| ”The system should be easy to use” | 90% of new users complete the primary task (purchase) within 5 minutes without assistance |
NFR Trade-offs
NFRs are in constant tension with each other. Engineering is the art of balancing them:
- Security vs Usability: a 24-character password with mandatory 2FA is highly secure but a terrible user experience. A 4-digit PIN is highly usable but trivially insecure.
- Performance vs Maintainability: hand-optimised inline Assembly achieves maximum speed but destroys maintainability, portability, and readability. A clean, modular design may be slightly slower but survives decades of evolution.
- Scalability vs Cost: an architecture designed to handle 10 million concurrent users costs far more upfront than one designed for 1,000. Build for your actual expected scale, not your fantasy.
The Iron Triangle (Fast, Good, Cheap) applies to NFRs just as it applies to overall project scope.
Classifying FR vs NFR
It is a classic exam trap to mistake an implementation detail for a functional requirement or vice versa. Helpful rules of thumb:
- If the statement describes a specific action or output the system must produce, it is an FR (or an FR generated from an NFR).
- If the statement describes a constraint on how the system operates, it is an NFR.
- “The system shall calculate VAT” → FR (an action the system performs).
- “The system shall calculate VAT in under 10 ms” → NFR (a performance constraint on that action).
- “Database passwords must be stored using bcrypt with salt factor 12” → NFR (a security constraint on how data is handled).
- “The system shall allow a student to reserve a book currently checked out” → FR (a specific action).
Expected Learning
- Define FR and NFR, and classify given statements into each category.
- Name the “-ilities” and explain their role in constraining system architecture.
- Distinguish latency from throughput and explain why they may require different design trade-offs.
- Explain how an NFR can generate FRs, with examples.
- Define fit criteria and explain why they are essential for testable requirements.
- Identify and resolve trade-offs between competing NFRs in a given scenario.
Past Paper Questions
Example Sheet 1, Question 2 directly asks you to classify drone requirements as FR or NFR, critique a vague requirement, and provide testable NFRs with fit criteria. Example Sheet 1, Question 6(c) tests the Security-vs-Usability NFR trade-off in a clinical setting.