Functional vs Non-Functional Requirements: What Quality Engineers Need to Understand | Amber Insights #012
Introduction
A system can do exactly what the requirement says and still provide a poor, unsafe or unusable experience.
Imagine an online banking application.
A customer enters the correct details and successfully transfers money to another account.
Functionally, the feature works.
But what if the transfer takes 45 seconds to complete?
What if another customer can access the transaction?
What if the application becomes unusable when thousands of customers log in at the same time?
What if someone using a screen reader cannot complete the transfer?
What if the service fails and loses the transaction?
The ability to transfer money is only one part of the requirement.
How that capability performs, behaves, and withstands different conditions matters too.
This is where understanding the distinction between functional and non-functional requirements becomes important.
For a Quality Engineer, that distinction is not simply terminology.
It influences what we test, how we test it, the environments and tools we need, the risks we consider, and ultimately the evidence we provide about quality.
01. What Is a Functional Requirement?
A functional requirement describes what a system should do.
It defines a capability, behaviour, action, or response that the system must provide.
For example:
An authenticated customer can update their email address.
That requirement describes functionality.
From it, we might begin investigating questions such as:
Who is allowed to update the email address?
What information must the customer provide?
How is the new email address validated?
What happens when the change succeeds?
What happens when the email address is invalid?
Should the customer receive confirmation?
Should the previous email address be retained?
These questions help us understand the behaviour behind the functionality.
Other examples of functional requirements might include:
A customer can reset their password.
An administrator can deactivate a user account.
The system calculates the total value of an order.
A payment can be refunded.
A user can search for a product.
The system sends a confirmation email after registration.
In each case, we are describing something the system does.
02. What Is a Non - Functional Requirement?
A non-functional requirement describes how well the system must operate or the conditions and quality characteristics it must satisfy.
Consider our email address example again:
An authenticated customer can update their email address.
That tells us what the system should do.
But we might also have expectations such as:
The update should complete within two seconds.
The customer's personal information must be protected.
The functionality must be accessible using a keyboard.
The service must remain available during expected levels of demand.
Changes must be recorded in an audit trail.
Those requirements do not introduce entirely new business functionality.
Instead, they describe important quality characteristics of that functionality.
These may concern areas such as:
Performance
Security
Accessibility
Reliability
Availability
Scalability
Usability
Maintainability
Compatibility
Recoverability
And this is where Quality Engineering becomes broader than checking whether a button produces the expected response.
03. The Difference Is Easier to See Together
A useful way to understand the distinction is to examine the same feature through both lenses.
Functional requirement
A registered customer can search for products by product name.
Non-functional requirements
Search results should be returned within two seconds under the agreed operating load.
The search functionality must meet the agreed accessibility requirements.
Customer search activity must not expose another customer's information.
The search service must support the expected number of concurrent users.
The functional requirement asks:
Can the system do it?
The non-functional requirements ask questions such as:
How well does it do it?
Under what conditions?
To what standard?
04. Functional Does Not Mean More Important
One mistake teams can make is treating functional requirements as the main requirements and everything else as additional.
That can create significant risk.
Imagine an authentication service that correctly validates usernames and passwords.
Functionally, it works.
But suppose it allows unlimited login attempts.
Or credentials are transmitted insecurely.
Or authentication takes 30 seconds during peak periods.
Or the service becomes unavailable whenever traffic increases.
The core functionality may technically exist, but we would struggle to describe the overall solution as high quality.
Quality is not simply the presence of functionality.
A system must also operate within the quality expectations that matter to its users, organisation, and operating environment.
05. Non-Functional Requirements Must Be Testable Too
Consider this requirement:
The application should be fast.
We encountered a similar problem in Issue 011.
What does fast mean?
Without a measurable expectation, different people may interpret it differently.
A Developer may consider five seconds acceptable.
A Product Owner may expect three seconds.
A customer may abandon the journey after two.
A stronger requirement might state:
For 95% of requests, the account summary page should load within two seconds under an agreed load of 5,000 concurrent users.
Now we have something that can be evaluated.
We know:
What is being measured: account summary response time
Expected result: within two seconds
Threshold: 95% of requests
Operating condition: 5,000 concurrent users
That gives the Quality Engineer something considerably more useful than the application should be fast.
The same principle applies across other quality characteristics.
Instead of:
The application should be accessible.
We need to understand the accessibility standard and acceptance expectations.
Instead of:
The service should be reliable.
We need to understand what reliability means for that service and how it will be measured.
Instead of:
The application should be secure.
We need to understand the security controls, threats, standards, and acceptance criteria that apply.
A non-functional requirement that cannot be objectively evaluated may still contain an important intention, but it needs further clarification before we can confidently demonstrate that it has been satisfied.
06. Performance Is More Than Speed
Performance is often reduced to one question:
How quickly does the page load?
But performance can involve much more.
A Quality Engineer may need to understand:
Response time: How quickly does the system respond?
Throughput: How many transactions can it process within a given period?
Concurrency: How does it behave when many users interact with it simultaneously?
Scalability: What happens as demand increases?
Stability: Can the system maintain acceptable behaviour over an extended period?
Consider a service that processes an individual transaction in 300 milliseconds.
That sounds excellent.
But what happens when 10,000 transactions arrive at approximately the same time?
Testing one transaction tells us very little about that condition.
1 User → 100 Users → 1,000 Users → 10,000 Users
Does acceptable performance remain acceptable as demand changes?
07. Security Requirements Change How We Test
Security requirements may influence almost every part of a system.
Suppose the functional requirement states:
A customer can view their account information.
The obvious functional scenario is to verify that the customer can access their account.
But the security perspective introduces another question:
Can the customer access someone else's account?
Now we are thinking about authorisation.
We may also need to consider authentication, session management, sensitive data, encryption, auditability, and other controls depending on the system and its risks.
This illustrates an important Quality Engineering principle.
Testing what an authorised user can do is only part of the picture. Sometimes we also need to establish what a user must not be able to do.
08. Accessibility Is a Requirement, Not a Final Check
Accessibility should not appear for the first time just before release.
If a service needs to meet defined accessibility expectations, those requirements should influence design, development, and testing throughout delivery.
Quality Engineers may need to consider areas such as:
Keyboard navigation.
Focus order.
Form labels.
Error identification.
Colour contrast.
Screen reader compatibility.
Alternative text.
Zoom and text resizing.
Accessible names and roles.
But accessibility testing is not simply a checklist of technical checks.
The underlying question is:
Can people with different access needs successfully use the service?
If accessibility expectations are known early, teams can design for them.
If they are discovered at the end, remediation can become considerably more difficult.
09. Reliability, Availability, and Recovery Are Different Questions
These terms are sometimes used interchangeably, but they examine different aspects of system behaviour.
Reliability considers whether the system continues to perform correctly over time.
Availability considers whether the service is accessible when it is required.
Recovery considers what happens after something goes wrong.
Imagine a payment service becomes temporarily unavailable.
Several questions immediately matter.
What happens to transactions already in progress?
Are requests retried?
Could a retry create duplicate payments?
Is data lost?
How quickly should the service recover?
How do we know recovery has completed successfully?
Can processing safely resume?
These are not necessarily visible from the user interface.
But they can be critical to the quality of the service.
10. One Requirement Can Have Several Quality Dimensions
Requirements should not always be placed into perfectly isolated boxes.
Consider:
A customer can submit an online application.
We could examine that single capability from several perspectives.
Functionality
Can the application be submitted successfully?
Performance
How quickly should submission complete?
Security
Is the information protected during submission and storage?
Accessibility
Can users with different access needs complete the journey?
Reliability
What happens if part of the process temporarily fails?
Compatibility
Does the journey work across the supported browsers and devices?
Data integrity
Is the submitted information stored correctly?
Observability
Can the team determine what happened if submission fails?
This is why Quality Engineers should avoid thinking:
I have tested the functionality, therefore I have tested the feature.
You may have tested one dimension of the feature.
11. Not Every System Needs the Same Quality Characteristics
The importance of a non-functional requirement depends heavily on context and risk.
Consider two systems.
One is an internal application used occasionally by five employees.
The other processes thousands of financial transactions every minute.
Their performance, availability, security, and recovery expectations are unlikely to be identical.
Similarly, the consequences of five minutes of downtime may be very different for:
A marketing website.
An internal reporting dashboard.
An emergency service.
A payment platform.
A healthcare system.
This is why non-functional requirements should not simply be copied from one project to another.
The question should be:
Which quality characteristics matter for this system, and what level of each characteristic is required?
Risk and business context should help answer that question.
12. Ask About Non-Functional Requirements Early
Quality Engineers should not wait until functional testing is complete before asking about performance, accessibility, security, or reliability.
During refinement, requirements analysis, or technical discussions, we can begin asking:
What response times are expected?
How many users or transactions must the service support?
What happens when demand increases?
What availability is required?
What accessibility standard applies?
Which browsers and devices must be supported?
What information is sensitive?
What audit evidence is required?
What happens when a dependency becomes unavailable?
What recovery behaviour is expected?
How will these characteristics be measured?
Some of these questions may be answered by Business Analysts or Product Owners.
Others may require Architects, Developers, Security specialists, Accessibility specialists, Platform Engineers, or operational teams.
The Quality Engineer does not need to personally own every answer.
Our responsibility is to recognise when an important quality question has not yet been answered.
13. A Practical Quality Requirements Lens
When analysing a new feature, I find it useful to look beyond the immediate functionality and ask:
Functionality — What must the system actually do?
Performance — How quickly and under what level of demand?
Security — What must be protected, and from whom?
Accessibility — Who needs to use the service, and what accessibility expectations apply?
Reliability — How consistently must the service operate?
Availability — When must the service be accessible?
Recovery — What should happen after failure?
Compatibility — Which environments, browsers, devices, or platforms must be supported?
Data Integrity — How do we ensure information remains accurate and consistent?
Observability — What evidence will allow us to determine what happened?
THE REQUIREMENT → Functionality | Performance | Security | Accessibility | Reliability | Availability | Recovery | Compatibility | Data Integrity | Observability
Which quality dimensions matter for this requirement?
14. Functional and Non-Functional Testing Work Together
The distinction between functional and non-functional requirements is useful because it helps us think about different dimensions of quality.
But in practice, they are closely connected.
A feature cannot deliver the intended customer outcome merely because its functional path works.
Nor is excellent performance particularly useful if the underlying functionality produces the wrong result.
Quality Engineering therefore needs both perspectives.
We need evidence that:
The system does the right thing.
And evidence that:
It does it to the level of quality the business and users require.
That is the bigger picture.
Final Thoughts
Functional requirements help us understand what the system must do.
Non-functional requirements help us understand important quality characteristics and operating expectations surrounding that behaviour.
Both influence testing.
Both can contain ambiguity.
Both need to be sufficiently understood.
And both can expose significant risks when they are considered too late.
When analysing a requirement, therefore, do not stop once you understand the successful functional journey.
Ask what else must be true for that functionality to be considered genuinely fit for purpose.
How quickly must it respond?
How secure must it be?
Who must be able to use it?
How reliable must it be?
What happens under pressure?
What happens when something fails?
And how will we demonstrate that those expectations have actually been met?
A feature is not high quality simply because it works. The conditions under which it works matter too.
About the Author
Amber Idumwonyi is a Senior Quality Engineering professional with extensive experience delivering Quality Engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Comments