functional vs non-functional requirements
Functional vs Non-Functional Requirements in System Design
Learn how functional requirements define what a system must do, while non-functional requirements define how well, securely, reliably and efficiently the system must perform those functions.
Introduction
Requirements provide the foundation for system design. They describe the expected system behaviour, required quality levels, operating conditions and constraints that influence architectural decisions.
Software requirements are commonly divided into two major categories:
- Functional requirements, which define what the system must do
- Non-functional requirements, which define how well the system must perform
A system can satisfy every feature requirement and still fail in practice if it is too slow, unavailable during important periods, insecure, difficult to operate or unable to support the expected workload.
Core distinction: Functional requirements describe capabilities and observable behaviours. Non-functional requirements describe measurable quality attributes, operating expectations and constraints applied to those capabilities or to the complete system.
In your System Design.xlsx curriculum, this is Topic 1.2 under System Design Process and Estimation. The module places functional and non-functional requirements before request flows, high-level diagrams and capacity estimation so architecture choices are driven by documented needs. 【1-16ade2】
Prerequisites
| # | Prerequisite | Why It Is Needed |
|---|---|---|
| 1 | Requirements discovery | Requirements are derived from stakeholder goals, user journeys and system boundaries. |
| 2 | Basic client-server knowledge | Many requirements concern requests, responses and backend processing. |
| 3 | Basic system terminology | Performance, availability, reliability and scalability appear in NFRs. |
| 4 | Understanding of measurable outcomes | Quality requirements must be expressed through verifiable criteria. |
What Are Functional Requirements?
Functional requirements define the actions, services, calculations, workflows and responses the system must provide. They answer:
Functional requirements commonly describe:
- User registration and authentication
- Creating, reading, updating and deleting records
- Searching, sorting and filtering data
- Calculations and transformations
- Sending notifications
- Processing payments
- Generating reports
- Integrating with external systems
- Handling invalid input or missing data
Functional requirements focus on features, operations and interactions between the system, users and external systems. 【2-0b73a8】【3-1119a2】
Functional Requirement Template
Requirement ID:
FR-<number>
Actor:
<User, system or external service>
Trigger:
<Event or input that starts the behaviour>
Requirement:
The system shall <specific observable action>.
Preconditions:
<Conditions that must already be true>
Successful result:
<Expected output or state change>
Failure result:
<Expected behaviour when processing cannot complete>URL Shortener Examples
| ID | Functional Requirement |
|---|---|
| FR-01 | The system shall create a short URL for a valid destination URL. |
| FR-02 | The system shall redirect a valid short code to its stored destination. |
| FR-03 | The system shall reject destination URLs using unsupported schemes. |
| FR-04 | The system shall return a not-found response for an unknown short code. |
| FR-05 | The system shall allow an authenticated owner to deactivate an owned short link. |
| FR-06 | The system shall stop redirecting an expired or deactivated link. |
| FR-07 | The system shall record a redirect event when analytics collection is enabled. |
What Are Non-Functional Requirements?
Non-functional requirements, commonly abbreviated as NFRs, define the quality attributes, limits and operating characteristics of the system. They answer questions such as:
- How quickly must the system respond?
- How much traffic must the system support?
- How available must the service be?
- What consistency behaviour do users require?
- What security controls must be applied?
- How much data loss is acceptable?
- How quickly must the system recover?
- How will operators detect failures?
Common NFR categories include performance, security, reliability, scalability, usability, maintainability and portability. 【2-0b73a8】【4-2739b3】
Non-Functional Requirement Template
Requirement ID:
NFR-<number>
Quality attribute:
<Performance, availability, security, durability, scalability or another area>
Operation or scope:
<The function, component or complete system affected>
Workload and conditions:
<Traffic, data volume, region, failure condition or environment>
Target:
<Measurable requirement>
Measurement point:
<Where and how the result is observed>
Exclusions:
<Any approved exclusions>
Verification:
<Load test, security test, failure exercise, monitoring report or review>Common Non-Functional Requirement Categories
| Category | What It Describes | Example Metric |
|---|---|---|
| Performance | Response speed and processing delay | p95 or p99 response latency |
| Throughput | Amount of work handled over time | Requests or events per second |
| Availability | How often the service is usable | Successful service time over a defined period |
| Reliability | Ability to produce correct outcomes consistently | Successful-operation or failure rate |
| Durability | Ability to preserve accepted data | Maximum acceptable data loss |
| Scalability | Ability to accommodate workload growth | Supported traffic or data volume |
| Security | Protection of access, data and operations | Authentication, authorization and audit controls |
| Privacy | Collection, use, retention and deletion of personal data | Retention and deletion rules |
| Consistency | Visibility and ordering of state changes | Strong, eventual or workflow-specific guarantee |
| Recoverability | Restoration after failure | Recovery time and recovery point objectives |
| Observability | Ability to detect and diagnose system behaviour | Required logs, metrics, traces and alerts |
| Maintainability | Ease of changing, testing and operating the system | Deployment, rollback or automated-test requirements |
Functional vs Non-Functional Requirements
| Comparison Area | Functional Requirement | Non-Functional Requirement |
|---|---|---|
| Primary question | What must the system do? | How well or under what conditions must it work? |
| Focus | Behaviour, feature or workflow | Quality, limit or operating characteristic |
| Typical scope | One use case or operation | One operation, a component or the complete system |
| Example | Create a short link | Support the approved creation workload within the required latency target |
| Verification | Functional or acceptance test | Load, resilience, security, usability or operational test |
| Architecture influence | Defines required system capabilities | Strongly influences scale, replication, caching, security and deployment choices |
Functional and Non-Functional Requirements Work Together
Functional and non-functional requirements are not competing categories. A useful design normally pairs a capability with the quality expectations applied to that capability.
| Functional Requirement | Related Non-Functional Questions |
|---|---|
| Create a short URL | How quickly, at what peak load and with which validation controls? |
| Redirect a short URL | What latency, availability and consistency are required? |
| Upload a file | What size limit, supported formats, security checks and completion target apply? |
| Transfer money | What consistency, durability, authorization and audit guarantees apply? |
| Send a notification | What delivery delay, retry behaviour and duplicate policy are acceptable? |
| Generate a report | What maximum data size, completion time and access control apply? |
Writing Measurable NFRs
The system must be fast.
The application must be scalable.
The service should be highly available.
The data must be secure.
The platform should be easy to maintain.Under <defined workload and operating condition>,
the <operation or component> shall meet
<numeric or objectively testable target>,
measured at <defined observation point>.Example Performance Requirement
NFR-PERF-01:
Under the approved normal and peak redirect workloads, the redirect operation
shall satisfy the latency targets documented in the approved service-level
objective, measured from the public API boundary.The numeric target should be supplied by stakeholders, operational evidence, existing measurements or an approved capacity assumption. It should not be invented without evidence.
Example Security Requirement
NFR-SEC-01:
Only an authenticated and authorized owner shall be allowed to deactivate an
owned short link. Every accepted deactivation shall produce the audit evidence
defined by the security policy.Example Reliability Requirement
NFR-REL-01:
A failure in analytics recording shall not create an invalid redirect mapping.
The required user-visible behaviour during analytics failure shall follow the
approved failure policy.Constraints Are Related but Different
A constraint limits how the solution may be implemented. Constraints are sometimes grouped with NFRs, but separating them usually improves design clarity.
| Statement | Classification |
|---|---|
| The system shall redirect valid short codes. | Functional requirement |
| The redirect operation shall meet an approved latency target. | Non-functional requirement |
| The service must run in an approved cloud region. | Technical or regulatory constraint |
| Redirect traffic will be ten times creation traffic. | Assumption until validated |
| The identity provider must be available for owner operations. | External dependency |
Acceptance Criteria
Functional Acceptance Example
Given:
A valid active short-code mapping exists.
When:
A visitor requests the short URL.
Then:
The system returns the redirect response containing the stored destination.Non-Functional Acceptance Example
Given:
The system is running in the approved test environment.
When:
The documented peak workload is applied for the defined test period.
Then:
The measured latency, throughput and error rate satisfy the approved targets,
and no invalid mapping state is produced.Testing Requirements
| Requirement Area | Typical Verification |
|---|---|
| Feature behaviour | Unit, integration and acceptance tests |
| Performance | Load, stress and benchmark tests |
| Availability | Monitoring evidence and controlled failure tests |
| Reliability | Failure injection, retry and recovery tests |
| Security | Authentication, authorization and security tests |
| Scalability | Capacity tests and scaling exercises |
| Durability | Persistence, backup and restoration tests |
| Usability | Task-completion and user-evaluation evidence |
| Observability | Log, metric, trace and alert validation |
| Maintainability | Automated build, test, deployment and rollback evidence |
Requirements Traceability Matrix
| Requirement | Type | Design Impact | Verification |
|---|---|---|---|
| FR-01 | Functional | Create-link request flow and persistence | Functional test |
| FR-02 | Functional | Redirect lookup path | Integration test |
| NFR-PERF-01 | Non-functional | Read path, caching and capacity | Load test |
| NFR-SEC-01 | Non-functional | Identity, authorization and audit design | Security test |
| NFR-REL-01 | Non-functional | Failure isolation and recovery behaviour | Failure test |
Common Mistakes
Documenting Features but Ignoring Quality
A feature can work correctly under light testing and still fail under the expected production workload.
Using Vague NFRs
Terms such as fast, scalable and secure must be replaced with measurable targets and verification conditions.
Inventing Numeric Targets
Obtain targets from stakeholders, existing measurements, policies, forecasts or approved assumptions.
Describing Technology as a Requirement
“Use Redis” is normally a design decision. “Frequently requested mappings must satisfy the approved latency target” describes the required outcome.
Applying One NFR to Every Operation
Read, write, reporting and administrative workflows can require different latency, availability and consistency behaviour.
Confusing Availability with Reliability
Availability concerns whether the service can be used. Reliability also concerns consistently producing correct outcomes.
Ignoring Failure Behaviour
Requirements should explain what users observe when dependencies, storage or asynchronous processing fail.
Writing Untestable Requirements
Every important requirement should have observable acceptance or verification criteria.
Ignoring Cross-cutting NFRs
Security, observability and maintainability can apply across many workflows rather than belonging to one feature.
Assuming NFRs Are Optional Enhancements
Quality requirements can determine whether a function is safe, usable and operable in its intended environment.
Requirements Review Checklist
Review Before Architecture
- Every major user journey has functional requirements.
- Functional requirements describe observable behaviour.
- Successful and failed outcomes are documented.
- Duplicate, retry and idempotency behaviour is defined where relevant.
- Performance targets identify the operation and workload.
- Availability targets identify the component and measurement period.
- Consistency expectations are documented per workflow.
- Durability and recovery expectations are defined.
- Security and privacy requirements are included.
- Monitoring and alerting expectations are included.
- Numeric targets have evidence or are marked as assumptions.
- Constraints are separated from requirements.
- Priorities and owners are recorded.
- Acceptance criteria are measurable.
- Requirements are traceable to design and verification evidence.
Practice Exercise
Classify the following requirements for an online shopping system as functional requirements, non-functional requirements, constraints or assumptions.
| Statement | Classification | Reason |
|---|---|---|
| The system shall allow a customer to add a product to a shopping cart. | Functional | Defines an observable capability |
| The checkout operation shall satisfy the approved response-time target under the stated peak workload. | Non-functional | Defines performance quality |
| The system must integrate with the organization's approved payment provider. | Constraint | Restricts the solution to a required dependency |
| Most customers will place fewer than ten items in one order. | Assumption | Requires validation through product evidence |
| The system shall reject checkout when no item remains available. | Functional | Defines failure behaviour |
| Only authorized support users shall view complete payment-failure details. | Non-functional | Defines an access-control quality requirement |
Implementation Task
- Choose a URL shortener, chat application or notification service.
- Write eight functional requirements.
- Write one NFR for performance, availability, security, durability and observability.
- Identify three constraints and three assumptions.
- Pair every functional requirement with relevant quality questions.
- Add acceptance criteria for two functional and two non-functional requirements.
- Create a small traceability matrix.
Frequently Asked Questions
What is the simplest difference between FRs and NFRs?
Functional requirements define what the system does. Non-functional requirements define how well and under which conditions it does it.
Is security functional or non-functional?
Security is commonly treated as a quality attribute, but individual security capabilities can also be functional. For example, logging in is a function, while the required authentication strength and access policy are quality or security requirements.
Is logging a functional or non-functional requirement?
Producing an audit event can be a functional requirement. Log coverage, retention, access control and operational usefulness are commonly non-functional or operational requirements.
Is scalability the same as performance?
No. Performance describes behaviour under a stated workload. Scalability describes how system behaviour and required resources change as workload or data volume grows.
Can one feature have several NFRs?
Yes. A payment operation can have performance, consistency, durability, security, audit and recovery requirements.
Do all NFRs apply to the complete system?
No. Some apply system-wide, while others apply only to a particular operation, component, user group, region or failure condition.
Why do NFRs strongly influence architecture?
Quality targets can affect replication, caching, partitioning, security, asynchronous processing, monitoring, deployment and recovery decisions.
What if stakeholders cannot provide an NFR target?
Record the target as an open question or assumption, identify an owner and gather measurements or business evidence before treating it as confirmed.
Can a requirement contain both functional and non-functional information?
Yes, but separating the capability from its quality criteria generally improves traceability, prioritization and testing.
What comes after classifying requirements?
Confirm constraints and assumptions, map the main request flows, create high-level diagrams and estimate QPS, storage and bandwidth before selecting detailed architecture components.
Key Takeaway
Functional requirements define the capabilities and behaviours a system must provide. Non-functional requirements define the measurable quality, scale, security, reliability and operating expectations applied to those capabilities. A defensible system design needs both. Write observable functional statements, measurable quality targets, explicit failure behaviour and acceptance criteria before selecting architecture components.