.svg){kind=small}
Functional requirements describe what a solution must do, while non-functional requirements describe the conditions and qualities under which it must do it. A functional requirement might state that a customer can reset a forgotten password. A non-functional requirement might state that the password-reset page must load within two seconds for 95% of requests or that reset links must expire after a defined period.
Both types are important. A system can contain every required feature and still fail if it is too slow, difficult to use, unreliable, insecure or unable to support the expected number of users.
Functional vs non-functional requirements at a glance
| Area | Functional requirement | Non-functional requirement |
|---|---|---|
| Primary question | What must the solution do? | How well, under what conditions or to what quality must it operate? |
| Focus | Behaviour, capability and information | Quality, constraint and service characteristics |
| Examples | Create an account, calculate a price, approve a request | Performance, security, accessibility, reliability, scalability |
| Testing | Does the function produce the expected behaviour? | Does the solution meet a measurable quality or constraint? |
| Risk if missed | Required capability is absent or incorrect | Capability exists but is unusable or unsuitable in practice |
Where do functional and non-functional requirements fit?
The International Institute of Business Analysis distinguishes several broad requirement categories: business requirements, stakeholder requirements, solution requirements and transition requirements.
Functional and non-functional requirements are both types of solution requirement. That distinction is useful because it reminds us that they sit beneath a wider chain of needs.
For example:
- Business requirement: Reduce abandoned online applications.
- Stakeholder requirement: Applicants need to save an incomplete application and return later.
- Functional requirement: The system must allow an authenticated applicant to save an incomplete application.
- Non-functional requirement: A saved application must remain available for at least 30 days and must be protected from access by other applicants.
Good analysis keeps these levels connected so teams can explain why a detailed solution requirement exists.
What is a functional requirement?
A functional requirement specifies a capability, behaviour or information-handling need of the solution. It describes something the system, service or process must be able to perform.
Functional requirements often relate to:
- creating, reading, updating or deleting information
- calculations and business rules
- searching and filtering
- user authentication
- workflow and approvals
- notifications
- integrations with other systems
- report generation
- data validation
- role-based behaviour
Examples of functional requirements
- The system must allow a customer to download an invoice as a PDF.
- A manager must be able to approve or reject an expense claim.
- The booking system must calculate VAT using the applicable tax rate.
- The service must send a confirmation email after a booking is completed.
- Users must be able to search the course catalogue by keyword.
- The application must prevent an order being submitted without a delivery address.
Notice that each example describes an observable capability or behaviour.
What is a non-functional requirement?
A non-functional requirement, sometimes called a quality requirement or quality-of-service requirement, describes a condition or quality the solution must possess. It can constrain how the solution is designed and can be just as important as the functionality itself.
Typical categories include:
- performance
- availability
- reliability
- security
- privacy
- usability
- accessibility
- scalability
- maintainability
- compatibility
- portability
- recoverability
- auditability
- localisation
- legal or regulatory compliance
Examples of non-functional requirements
- Search results must be displayed within two seconds for 95% of requests under normal operating load.
- The online service must support 5,000 concurrent authenticated users.
- The application must meet the organisation's defined accessibility standard.
- Customer data must be encrypted in transit using approved protocols.
- The service must be available for 99.9% of each calendar month, excluding agreed maintenance windows.
- Audit records must be retained for seven years.
- The system must recover from the defined critical failure scenario within 30 minutes.
These examples are much more useful than vague statements such as “the system should be fast” or “the website must be secure”.
Why are non-functional requirements so easy to miss?
Functional requirements are visible. Stakeholders naturally think about the actions they expect to perform: submit an order, approve an invoice, generate a report or update a customer record.
Quality attributes are often taken for granted until they fail. A stakeholder may assume that:
- pages will load quickly
- the service will be available when needed
- private data will be protected
- the application will work with assistive technology
- the system will cope when usage increases
- backups and recovery will be reliable
If these assumptions are not made explicit, the delivered solution can technically satisfy its functional specification while still creating a poor or risky outcome.
A practical example: online course booking
Imagine an organisation is building an online course-booking platform.
Possible functional requirements
- A visitor can search for courses by subject.
- A visitor can select a scheduled course date.
- A customer can enter delegate details.
- The system can calculate the total price and applicable VAT.
- A customer can submit a booking request.
- The system sends confirmation to the customer and training provider.
- An administrator can update the booking status.
Possible non-functional requirements
- The catalogue search should return results within an agreed response time.
- The booking process must work on supported mobile screen sizes.
- Personal information must be transmitted and stored according to the organisation's security requirements.
- The service must support the expected peak number of simultaneous users.
- The booking pages must meet defined accessibility requirements.
- The service must maintain an audit trail of changes to booking status.
- Recovery arrangements must meet the agreed recovery-time objective.
The functionality defines the booking process. The non-functional requirements help determine whether that process is usable, safe and operationally suitable.
Functional requirements are not the same as business requirements
This is an important distinction for Business Analysts.
“Increase online sales by 15%” is not a functional requirement. It is a business objective or business requirement.
“Customers must be able to compare three products side by side” is closer to a functional solution requirement.
Confusing these levels can cause teams to lose sight of why a feature is being built. Requirements traceability helps preserve the connection from business outcome through stakeholder needs to solution behaviour.
Non-functional requirements should be measurable
One of the most common problems with non-functional requirements is vague language.
Consider:
The system must be easy to use.
Different people can interpret “easy” differently. It is difficult for a designer to know what is expected and difficult for a tester to determine whether the requirement has been met.
A stronger version might specify an observable outcome, such as a defined percentage of representative first-time users being able to complete a task without assistance within an agreed time.
The correct measure depends on the situation, but the principle is the same: define quality in a way that can be assessed.
Examples of weak and stronger non-functional requirements
| Weak wording | Stronger direction |
|---|---|
| The website must be fast. | Specify a response-time target and the load conditions under which it applies. |
| The system must be secure. | Define relevant authentication, encryption, access, audit and security-control requirements. |
| The application must be reliable. | Define availability, failure or recovery targets. |
| The interface must be user-friendly. | Define usability outcomes for representative users and tasks. |
| The platform must be scalable. | Define expected growth, transaction volume or concurrent-user levels. |
Common non-functional requirement categories
Performance
How quickly must the solution respond, process transactions or complete jobs? Performance requirements should normally identify both a target and the conditions under which it applies.
Availability
When must the service be accessible? A 24-hour consumer service may have very different needs from an internal system used only during weekday working hours.
Security
Security requirements may cover authentication, authorisation, encryption, session management, audit logging, vulnerability management and other controls.
Privacy
What personal information is processed? Who may access it? How long should it be retained? What restrictions apply to its use or location?
Accessibility
What accessibility standards or organisational requirements must the product meet? Accessibility should be considered during design rather than treated as a late testing exercise.
Usability
How effectively can the intended users complete important tasks? Consider user experience, learnability, error prevention and the context in which the solution will be used.
Scalability
How should the solution behave as users, transactions or data volumes grow?
Recoverability
How quickly must service be restored after failure and how much data loss, if any, is acceptable?
Maintainability
How easily can the solution be supported, changed, monitored and diagnosed throughout its life?
Are security requirements functional or non-functional?
Security is commonly treated as a non-functional quality, but individual security requirements can describe functional behaviour too.
For example:
- Functional: The system must allow an administrator to disable a user account.
- Non-functional/security quality: The system must automatically lock an account after the defined number of unsuccessful authentication attempts.
The classification is less important than making sure the requirement is clear, necessary and testable. Teams should avoid wasting time debating labels while important security needs remain undefined.
Are accessibility requirements functional or non-functional?
Accessibility is normally considered a quality characteristic and is frequently handled among non-functional requirements. However, accessibility can also drive very specific behaviour and design decisions.
The practical priority is to identify accessibility needs early and apply them across the solution rather than treating them as optional enhancements.
Who defines non-functional requirements?
They should not be left solely to technical teams. Different stakeholders contribute different needs.
- Business owners may define availability and operational priorities.
- Security specialists may define security controls.
- Legal and compliance teams may identify regulatory constraints.
- Users can provide usability and accessibility needs.
- Architects and engineers can help translate business expectations into measurable technical qualities.
- Operations teams can define monitoring, support and recovery needs.
- Business Analysts help ensure these perspectives are elicited, reconciled and linked to the wider business need.
How do you elicit non-functional requirements?
They rarely emerge from asking “What should the system do?” alone. Useful questions include:
- How many people will use it at the busiest time?
- How quickly does this task need to complete?
- What would be the impact if the service were unavailable for an hour?
- What information is sensitive?
- Who must and must not be able to access it?
- What legal or regulatory requirements apply?
- What devices, browsers or environments must be supported?
- What accessibility needs exist?
- How much data will the system hold after three years?
- How quickly must service be restored after a failure?
- What evidence or audit trail must be retained?
Requirements elicitation techniques such as interviews, workshops, document analysis and observation can all help. See our beginner's guide to requirements gathering for a broader overview.
How are functional and non-functional requirements tested?
Functional tests usually check whether a specified action produces the expected result. For example, when a valid customer submits a booking, does the system create the booking and send the required confirmation?
Non-functional testing may involve:
- performance and load testing
- security testing
- accessibility testing
- failover and recovery testing
- usability evaluation
- compatibility testing
- capacity testing
Defining the requirement clearly before testing is crucial. A test team cannot objectively prove that a website is “fast enough” unless “fast enough” has been defined.
Functional and non-functional requirements in Agile
Agile teams still need both. Functional needs may appear in user stories, backlog items, acceptance criteria and supporting models. Non-functional requirements may appear in acceptance criteria, separate backlog items, architecture standards, a Definition of Done or broader solution constraints depending on the organisation.
The risk is that qualities affecting the whole product can become fragmented across individual stories. Teams need a way to maintain visibility of cross-cutting needs such as security, performance and accessibility.
Frequently asked questions
Is a user story a functional requirement?
A user story can represent a stakeholder or solution need, but it should not automatically be treated as equivalent to a complete functional requirement. Additional acceptance criteria, rules, models and non-functional information may be needed.
Is performance functional or non-functional?
Performance is normally treated as a non-functional quality requirement.
Is security always non-functional?
Security is commonly grouped with non-functional qualities, but specific security behaviours can also be expressed functionally. The important issue is that security needs are explicit and verifiable.
Can a non-functional requirement apply to several features?
Yes. Many non-functional requirements are cross-cutting. A security, accessibility or performance constraint may apply to the entire solution or a large group of functions.
Which requirements are more important?
Neither category is inherently more important. The correct priority depends on business value, risk, regulation and stakeholder need. A required function is useless if it cannot operate at the necessary quality, while excellent performance cannot compensate for missing essential functionality.
Develop stronger requirements with ExperTrain
Understanding requirement types is a core Business Analysis skill. ExperTrain's Business Analysis: Requirements Development, Documentation and Management course explores elicitation, modelling, documentation, requirement quality, traceability and change throughout the requirements lifecycle.
You can also explore our wider Business Analysis training, use the Business Analysis Glossary for terminology, or read What Is Requirements Gathering?.
Further reading
Found this article useful? Add ExperTrain as a Preferred Source on Google to help surface more of our training guides, articles and learning resources.
.png){kind=small}
