Functional and Non-Functional Requirements
A functional requirement states what the system must do: behaviour you can trigger and observe, such as "When a customer places an order, the system shows the order number and sends a confirmation email." A non-functional requirement states how well it must do it, and under which conditions: "The confirmation page appears within 2 seconds for 95% of orders while 500 customers are checking out at once."
The split mirrors functional and non-functional testing from the testing fundamentals module. Some teams call non-functional requirements quality requirements, or NFRs.
Why it matters
Non-functional requirements are the ones most often left out, or written as a single adjective: "fast", "secure", "easy to use". A feature can do exactly what its functional requirements say and still fail its users because it takes 40 seconds, shows one customer another customer’s data, or cannot be used with a screen reader. Such problems tend to surface late, when the fix may mean changing the architecture.
For a tester, a requirement is usable test basis only if you can state an expected result from it. "The page must be fast" gives none. Getting non-functional requirements stated as numbers before development starts is what makes them testable.
Functional requirements: what the system does
A functional requirement describes behaviour that a user or another system can observe: what goes in, which rules apply, and what comes out or changes. If you can check it by performing an action and comparing the result with an expected outcome, it is almost certainly functional. Each one usually belongs to a single feature or story. In an online shop:
- Validation: the postcode field accepts only the formats of the delivery countries.
- Business rules: orders of 300 SAR or more ship free (the next lesson covers business rules).
- Workflows: an order moves from "Paid" to "Shipped" when the warehouse scans the parcel.
- Outputs and interfaces: confirmation emails, invoices, the call to the payment provider.
- Permissions and errors: only the account owner sees the order history; a declined payment keeps the basket.
Try it: Requirements → Test Cases Try it: Requirements → Test Scenarios
Non-functional requirements: how well it does it
A non-functional requirement adds no behaviour; it sets the quality the behaviour must reach. In the terms of ISO/IEC 25010:2023 from the lesson on software quality, functional requirements belong to functional suitability and non-functional requirements to the other eight characteristics. Some teams also list constraints separately, such as a required database or a regulation.
Many non-functional requirements cut across features: a response-time target or WCAG conformance applies to every page, so it belongs in a shared list of quality requirements or the Definition of Done rather than in one story. They are checked by measuring a value under stated conditions, often with specialised tests and tools; some, such as monthly availability, only by monitoring in production. Examples for the same shop:
- Performance efficiency: search answers within 1.5 s at the 95th percentile with 200 concurrent users.
- Security: a session ends after 15 minutes without activity.
- Reliability: checkout is available 99.9% of each month, excluding announced maintenance.
- Interaction capability: the checkout pages conform to WCAG 2.2 level AA.
- Compatibility, which ISO/IEC 25010 files under flexibility: the shop works in the latest two major versions of Chrome, Safari, Firefox and Edge.
Functional requirement
What the system must do
- Example:
- Placing an order shows the order number and sends a confirmation email
- ISO/IEC 25010 characteristic:
- Functional suitability
- Reach:
- Usually one feature or story
- Expected result:
- A specified output, message or state change
- How it is checked:
- Functional tests: perform an action, compare the result
Non-functional requirement
How well it must do it, and under which conditions
- Example:
- The confirmation page appears within 2 s for 95% of orders, with 500 customers checking out at once
- ISO/IEC 25010 characteristic:
- The other eight: performance efficiency, security, reliability, interaction capability…
- Reach:
- Often many features: kept in a shared list or the Definition of Done
- Expected result:
- A measured value compared with a target
- How it is checked:
- Specialised tests and tools; some only by monitoring in production
The line is not always sharp: a rule such as an account lockout serves security but is written and tested as behaviour.
Making non-functional requirements measurable
As in the lesson on non-functional testing, a measurable requirement states a measure, a target with a unit, the conditions it applies to and the method of measurement. Written down as a requirement, it carries three more things: the ISO/IEC 25010 characteristic it belongs to, so the team can see which qualities are covered and which are still missing; an ID, so that test cases and results can trace to it; and a record of who decided the numbers. Some requirements methods call this measurable part of a requirement its fit criterion.
The numbers are business decisions: the tester proposes and asks, the product owner decides, and the decision is recorded with the requirement. Before proposing a number, the tester also checks that it can be met at all, as the worked example below shows.
Worked example: a homework portal draft
A school orders a homework portal, and the tester receives this draft before development starts. Decide for each line whether it is functional or non-functional, and whether you could test it as written.
Homework portal: draft requirements
H1 A student can upload one file per assignment until the deadline.
H2 Accepted formats are PDF and DOCX, up to 20 MB.
H3 After the deadline the Upload button is disabled and shows "Submission closed".
H4 Only the student and the course teachers can open a submission.
H5 Uploads must be fast.
H6 The portal must be available during exam weeks.
H7 The portal must work on phones.Worked example, continued: sorting and rewriting
H1 to H3 are functional: each has an action and an observable result. H4 sits on the line: it protects security (confidentiality), but it is written as behaviour and tested like a functional requirement: open another student’s submission and expect a refusal. Teams file it under either heading; what matters is that it is testable as written. H5 to H7 are non-functional and cannot be tested as written. The tester proposes values for the school to confirm:
- H5, performance efficiency: with 300 students uploading at once, a 20 MB file sent over a 10 Mbit/s connection is confirmed within 30 s of pressing Upload for 95% of uploads. The transfer alone takes at least 16 s, so a lower target could never be met.
- H6, reliability: from 06:00 to 24:00 in exam weeks the portal is available 99.5% of the time, measured by an external check every minute.
- H7, compatibility (flexibility in ISO/IEC 25010): upload and download work in the latest two major versions of Chrome on Android and Safari on iOS.
- Missing: an accessibility target, and how long files are kept.
Try it: Test Scenario Generator Try it: AI Requirement Gap Analyzer
Common mistakes
- Testing only what the user stories describe and never asking about performance, security, accessibility or compatibility.
- Putting a requirement that applies to every page, such as WCAG conformance, into a single story, where it is checked once and then forgotten.
- Writing a number without conditions: 2 seconds for which operation, at what load, at which percentile?
- Proposing a target without checking that it can be met: a 20 MB upload over 10 Mbit/s cannot finish in less than 16 s, whatever the code does.
- Inventing a target and testing against it as if it had been agreed, instead of proposing it to the product owner.
The QA perspective
Ask non-functional questions in backlog refinement and requirements review, not in the week before release. For each feature, walk the quality characteristics as a checklist: does this one apply, and what is the target? Record each answer as a requirement with an ID, so tests and results can be traced to it.
Plan non-functional testing early: a load test needs a production-like environment and realistic data, and availability needs monitoring. In the test report, give the measured value next to the target and the conditions: "95th percentile 1.8 s against a target of 1.5 s at 200 users" is something the team can act on.
Practice exercise
Classify the requirements of a table booking app
A restaurant chain is building a table booking app. Classify each requirement below as functional or non-functional, name the ISO/IEC 25010 characteristic of each one, and say which you could test as written. Rewrite one untestable requirement as a proposal for the product owner. Then write two questions for the product owner about what the list leaves out.
B1 A guest can book a table for 1 to 8 people, up to 30 days ahead.
B2 The restaurant receives an SMS for every new booking.
B3 The booking confirmation must appear quickly.
B4 The app must be secure.
B5 The app must cope with the evening rush in Ramadan.- Mark each requirement F or NF, with its ISO/IEC 25010 characteristic.
- Write the expected result a test would check; where you cannot, mark the requirement untestable, and rewrite one of those.
- List what is missing as questions.
Show the model answer
B1 and B2 are functional (functional suitability), each with an expected result a test can check. B1: a booking for 8 people 30 days ahead is accepted; 9 people, or 31 days ahead, is refused. Its edges are worth testing: 0, 1, 8 and 9 people, and 30 and 31 days ahead. B2: for each new booking the restaurant receives exactly one SMS.
B3, B4 and B5 are non-functional and cannot be tested as written. B3 is performance efficiency (time behaviour). B4 is security, and so broad that it has to be split into several specific requirements. B5 is performance efficiency (capacity), because it is about the load the app must carry; the real evening peak should come from last year’s data.
One rewrite, here B3: "After the guest taps Confirm, the confirmation appears within 2 s for 95% of bookings at 150 bookings per minute." Record it with an ID and its characteristic, and mark the values as proposed until the product owner confirms them.
Questions: What happens when the SMS cannot be sent? Which accessibility standard applies?
Frequently asked questions
Is a security requirement functional or non-functional?
Security is a non-functional characteristic, but many security needs are written as behaviour, such as locking an account after 5 failed attempts, and are tested like functional requirements. The label matters less than testing both the behaviour and the risk behind it.
Who decides the numbers in a non-functional requirement?
The product owner or the business stakeholders, with input from architects, operations and current usage data. The tester asks for the numbers, proposes values when none exist, and flags targets that cannot be measured or met.
Where do non-functional requirements go in an agile team?
A requirement for one story goes into its acceptance criteria. Requirements that apply to every story, such as WCAG conformance, usually go into the Definition of Done or a shared list of quality requirements.
Which of these is a non-functional requirement: searching the system, issuing and printing reports, response speed and security, or moving between pages?
Response speed and security. Searching the system, issuing and printing reports and moving between pages are things the system does, so they are functional requirements. Speed and security say how well it must do them, and they become testable once they carry numbers, such as a response within 2 seconds for 95% of searches.
What are common examples of non-functional requirements?
Performance and capacity (response time, the number of concurrent users the system supports), reliability and the ability to recover after a failure, usability (ease of use), compatibility and interoperability with other systems, security, maintainability and portability. Issuing and printing reports is not one of them: it is a function, so it is a functional requirement.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelThe product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- Web Content Accessibility Guidelines (WCAG) 2.2The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
Practise with Mutqan tools
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Derive test scenarios from functional requirements with coverage mapping.
Generate high-level test scenarios covering functional, negative, security, usability and compatibility angles for a feature.
Measure an endpoint's response time over several samples: min, max, average, median and p95.
Find missing requirements — error handling, permissions, edge conditions, non-functional needs — with Mutqan AI.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.