Functional requirements describe what the system is supposed to do — logging in, generating a report, sending a notification. Non-functional requirements describe how well it is supposed to do it — how fast, how securely, for how many users at once. The former define the functions; the latter define the quality of how they perform. Omitting either of these groups is the most common reason behind projects that “work” yet are still unfit for production.
What are functional requirements
Functional requirements are a description of specific system behaviors: which operations it performs, how it reacts to input, and what result it returns. Each one can be reduced to the sentence “the system must enable / the system must perform.” These are what make up the list of features that the client most easily imagines and most often dictates at the first meeting.
A well-written functional requirement is unambiguous and verifiable. “The system should be convenient” is not a functional requirement — it’s a wish. “The system must allow the user to reset their password via a link sent to their email address” — that one is, because it can be implemented and tested without interpretation.
Examples of functional requirements
- The user logs in with a username and password; after five failed attempts the account is locked for 15 minutes.
- The system generates a PDF invoice based on an order and sends it to the customer’s email address.
- An administrator can grant and revoke a role for another user.
- The search engine returns products matching a phrase and filters the results by category and price.
- The system exports a sales report to a CSV file for a selected period.
Notice that each example describes an action and its result. That is the essence of a “function”: input, processing, output.
What are non-functional requirements
Non-functional requirements (NFRs) describe the quality attributes of the system as a whole. They don’t state what function the software delivers, only with what quality it is supposed to deliver it and within what boundaries it is supposed to operate. These are what decide whether an application that “passes all scenarios” will withstand real traffic, an attack, and legal requirements.
NFRs are harder to capture, because the client rarely states them outright. Nobody will say “I want 99.9% availability,” but everyone will say “the system can’t go down.” It is the team’s role to translate such expectations into measurable thresholds. An unmeasurable non-functional requirement is useless — “the system should be fast” has to be turned into “API response time below 300 ms for 95% of requests.”
Performance
Defines how fast the system responds and how much work it does per unit of time. It is measured by response time, throughput, and resource usage. Example: the page loads in under 2 seconds, and key API endpoints respond in under 300 ms at the 95th percentile.
Scalability
States how the system behaves under growing load — and whether it can be expanded without rewriting it. Example: the application supports 10,000 concurrent users, and adding more instances increases throughput linearly, with no downtime.
Security
Describes data protection, authentication, authorization, and resistance to attacks. Example: sensitive data encrypted at rest and in transit, two-factor authentication for administrative accounts, and GDPR compliance regarding the storage of personal data.
Availability
Defines what percentage of the time the system is operational and how quickly it returns to service after a failure. Example: 99.9% availability per month (about 43 minutes of downtime), and a recovery time objective (RTO) of under one hour.
Usability and digital accessibility
Concerns ease of use and compliance with accessibility standards. Example: a new user completes a key task without instructions, and the interface meets WCAG 2.1 at level AA, which makes it usable for people with disabilities.
To this list you usually add a few more: reliability, maintainability, portability, and regulatory compliance. In IT projects, it is precisely these attributes that most often generate cost and risk, even though they take a back seat at the start.
Comparison table: functional versus non-functional
| Criterion | Functional requirements | Non-functional requirements |
|---|---|---|
| Question | What is the system supposed to do? | How well is it supposed to do it? |
| Scope | A single function or operation | An attribute of the entire system |
| Example | ”The user resets their password" | "Password reset works in <2 s, data encrypted” |
| Source | Usually stated outright by the client | Often hidden, has to be drawn out |
| Measurability | Met or not (works / doesn’t work) | A numeric threshold (time, %, number of users) |
| Testing | Functional, acceptance tests | Performance, load, security tests |
| Effect of omission | A function is missing | The system works but crashes, is slow, or insecure |
The most important takeaway from this table: both kinds of requirements depend on each other. A non-functional requirement always describes the quality of a specific function. “Login time below 1 second” makes no sense without a login function. That is why NFRs are worth assigning to functions, rather than keeping them in a separate, disconnected bucket.
How to gather and document requirements
Gathering requirements is not about writing down wishes, but about getting to the actual business needs. Functions usually surface on their own — the harder and more important work is on what goes unsaid: data volumes, expected availability, legal constraints, integrations. A solid foundation comes from business requirements analysis, which connects business goals with specific system requirements.
The most common techniques are stakeholder interviews, workshops, analysis of existing processes, and a review of the data and systems that the new software is meant to replace. Every requirement should have an owner, a rationale, and an acceptance criterion — otherwise, at the acceptance stage, there is no way to determine whether it has been met.
The result of this work is captured in a single, versioned document. The standard is the software requirements specification (SRS) — it organizes functional and non-functional requirements, assigns them identifiers, and becomes the point of reference for the team, the tests, and acceptance. A good specification is unambiguous, complete, consistent, and verifiable: every requirement can be tested, and none contradicts another.
In practice, it’s worth sticking to a few rules:
- Every requirement has a unique identifier (e.g., FR-012, NFR-004) — it makes tracking and writing tests easier.
- NFRs are measurable — with a threshold, a unit, and a condition (e.g., “with 1,000 users at the same time”).
- Non-functional requirements are assigned to the functions they concern, rather than left in isolation.
- The document is versioned, and every change has a date and an author.
Prioritization with the MoSCoW method
Not all requirements are equally important, and budget and time are always limited. The most popular prioritization method is MoSCoW, which divides requirements into four groups:
- Must have — critical. Without them, the release makes no sense or is not legally compliant. Example: login, encryption of personal data.
- Should have — important, but not blocking the launch. They can be delivered in the next release without disaster. Example: exporting reports to CSV.
- Could have — desirable, “nice to have.” They go in if time and budget remain. Example: a dark interface theme.
- Won’t have (this time) — deliberately out of scope for this release. Not rejected forever, only deferred — and clearly written down as such.
MoSCoW also works for non-functional requirements. 99.9% availability may be a “Must have” for a payment system, and only a “Could have” for an internal reporting tool. The key is to set priorities together with the business and to write down the rationale — because at the first deadline conflict, the whole team comes back to this list.
How to test non-functional requirements
Functional requirements are verified relatively simply: tests check whether the function works in line with the acceptance criterion. With non-functional requirements it’s harder, because you’re testing a quality threshold rather than a single scenario — and you do it with different tools and on an environment close to production.
Performance and scalability are checked through software performance tests: load, stress, and soak. They show whether the system holds the declared response time under real and extreme traffic, and where its limit lies. The remaining attributes — security, availability, reliability, usability — require separate approaches: penetration tests, failover trials, or user studies.
A broader picture of this discipline is provided by the guide to non-functional tests, which organizes the types of tests and shows how to link them to specific NFRs from the specification. The rule is one: if a non-functional requirement has no assigned method of verification, in practice it doesn’t exist — no one will prove that it has been met.
The most common mistakes
- Ignoring non-functional requirements. The team writes down the functions and only remembers performance and security right before going to production — when changes are most expensive.
- Unmeasurable NFRs. “The system should be fast and secure” can’t be tested. Without a threshold, a unit, and a condition, it’s a declaration, not a requirement.
- Confusing a requirement with a solution. “Use a PostgreSQL database” is a technical decision, not a requirement. The requirement is: “transaction data must be consistent and durable.”
- No priorities. When everything is “critical,” nothing is critical. At the first slip, the team doesn’t know what to cut.
- Requirements without an owner and an acceptance criterion. At acceptance, there’s no way to determine whether a function is ready, because no one has defined what “ready” means.
- A specification that goes out of date. Requirements change during a project. If the document doesn’t keep up, the team works on outdated assumptions.
How ARDURA Consulting supports requirements analysis
At ARDURA Consulting, we treat requirements analysis as the foundation of a project, not a formality before coding. Our analysts and consultants help draw out the unspoken requirements, translate business expectations into measurable NFRs, and capture the whole in a coherent, versioned specification that guides the team all the way to acceptance.
We have access to more than 500 senior specialists and more than 211 completed projects, so for requirements analysis we assign people who have built similar systems and know where the risk usually lies. Onboarding a specialist takes two weeks on average, so the analysis gets moving quickly and you don’t lose months on recruitment. It’s an approach in which we are a partner responsible for the outcome, not a supplier of hands for hire.
If you’re planning a new system or want to put the requirements in an ongoing project in order, start with solid analysis. Check out ARDURA Consulting’s software development services and let’s talk about your project — we’ll help turn expectations into a specification the whole project can be built on.