Start with what the system has to do
If you are sitting down to write requirements for the first time and trying to work out what functional requirements actually are, the fastest way to understand them is this: they describe what a system must do in response to something. A user logs in, the system checks credentials. An applicant submits a form, the system validates the data and updates a status. A payment is processed, the system sends a confirmation email. Every one of those behaviours is a functional requirement. They are the documented commitments that tell developers, testers, and stakeholders what the system will actually do when it is built.
I have spent a long time working across government, utilities, health, and enterprise environments, and the question of what functional requirements are comes up constantly, not just from junior BAs but from project managers and product owners who have been handed a requirements template and need to fill it in. The confusion is understandable because the term sounds formal and technical when, in practice, it is quite concrete. Once you understand how to spot them, you will find them everywhere in a project.
What makes a requirement “functional”
A functional requirement defines a specific behaviour or function of the system. It answers the question: when this happens, what does the system do? The word “functional” is doing real work here. It separates these requirements from non-functional requirements, which deal with qualities like performance, security, and availability rather than specific system actions. If you want a clear breakdown of how those two types relate to each other, the article on business requirements vs functional requirements vs non-functional requirements covers that distinction well.
Functional requirements sit in the middle layer of a typical requirements hierarchy. Business requirements sit above them and describe why the project exists and what outcomes the organisation needs. Functional requirements sit below that and describe how the system will fulfil those outcomes. System requirements, where they exist separately, describe the technical implementation below that.
- Business requirement: the organisation needs to collect application fees from users before an application is assessed.
- Functional requirement: the system must display a Transaction Details page showing the application fee, GST amount where applicable, and a total in $X,XXX.XX format before proceeding to payment.
- Non-functional requirement: the payment page must load within two seconds under normal network conditions.
That distinction between levels is what makes functional requirements so useful. They are specific enough to be testable and design-ready, but they do not prescribe the technical solution. They say what must happen, not how the code should make it happen.
How to recognise a functional requirement
In practice, I look for a few markers when I am reviewing requirements to check whether something is genuinely functional.
- It describes a system action or response. The system must, the system shall, the system displays, the system sends. If the subject is the system and the verb is an action, it is almost certainly functional.
- It is triggered by something. Functional requirements do not exist in isolation. There is always a trigger: a user action, a time event, a status change, or a data condition. If you cannot identify the trigger, the requirement is probably too vague.
- It is testable. You should be able to write a test case against it. “The system must send a confirmation email when payment is successful” is testable. “The system must be easy to use” is not functional, it is a quality attribute.
- It is specific to a feature or function. Functional requirements describe distinct pieces of system behaviour, not general principles. Each one should be traceable to a specific feature, screen, or process step.
- It involves a business rule or decision. Where the system has to make a decision based on data (for example, displaying a GST line only when the user is submitting from within Australia), that conditional logic belongs in a functional requirement.
A worked example with a real point of friction
On Project X, a government portal for processing applications from external users, the client needed to introduce an online payment step before applications were queued for assessment. The existing system had a simple “Submit” button on the final screen of the application wizard. The business requirement was clear: applicants must pay a fee before their application is reviewed. My job was to translate that into functional requirements the development team could build against.
I documented requirements covering the status model (an application should show “In Progress” when created but not yet submitted, “Gone to Payment” once the applicant accepted the terms and conditions and proceeded to the payment gateway, and “Submitted” once payment was confirmed), the transaction details screen (displaying the applicant name, application number, reference, fee amount, GST where applicable, and total in $X,XXX.XX format), and the failure handling (if payment failed, the status must revert to “In Progress” and the applicant must receive an email with the transaction details including the payment reference and date of attempt).
The friction came from the payment gateway integration. The development lead initially pushed back on the requirement that the system should automatically poll the gateway for applications stuck in “Gone to Payment” status. His concern was that this background polling process was not explicitly in scope and added development effort. I had to show that without it, a payment could be taken by the gateway without the application status ever updating, leaving the applicant with no confirmation and no ability to retry. The requirement was not optional; it was the safety net that prevented real money from disappearing into a status void. We documented it explicitly as a system process requirement with its own trigger condition, and it went into scope. That kind of friction, where a stakeholder questions whether a requirement is genuinely necessary, is exactly where precise functional documentation earns its keep.
Functional requirements vs business requirements: the key differences
Getting this wrong causes real problems. If you write business requirements where functional requirements should be, developers have to guess at the implementation. If you write functional requirements where business requirements should be, the project loses its strategic thread. The table below shows how the two types differ in practice.
| Dimension | Business Requirement | Functional Requirement |
|---|---|---|
| Focus | Why the project exists; the outcome the organisation needs | What the system must do to deliver that outcome |
| Audience | Executives, sponsors, project governance | Developers, testers, solution architects |
| Language | Business language, outcome-oriented | System language, behaviour-oriented |
| Testability | Validated through business outcomes and KPIs | Tested directly through test cases and acceptance criteria |
| Example | Applicants must pay a fee before assessment begins | The system must update application status to “Submitted” when payment is confirmed |
| Where documented | Business Requirements Document (BRD) | Functional Requirements Document (FRD) or equivalent |
If you are working across both document types on the same project, the article on Business Requirements Document vs Functional Requirements Document is worth reading before you start structuring your artefacts.
How to structure functional requirements in a document
There is no single correct format, but the most useful structures I have used share a few common elements. At the simplest level, each functional requirement should include: a unique identifier (so it can be traced), a description of the system behaviour, the trigger or condition, and any business rules that govern the behaviour.
In more formal waterfall projects, I would typically organise functional requirements by feature area or use case, with each use case containing a set of related requirements. In agile contexts, functional requirements are often captured as acceptance criteria attached to user stories rather than as standalone numbered statements. The underlying thinking is the same; the format adapts to the delivery approach. For a deeper look at how to write user stories alongside formal requirements, the article on how to write user stories and acceptance criteria covers both formats side by side.
Common mistakes when writing functional requirements
After reviewing hundreds of requirements documents across different industries, the same mistakes appear again and again.
- Writing solutions instead of requirements. “The system must use a dropdown menu to display application types” is a design decision, not a requirement. The requirement is that the user must be able to select an application type. Let the design team decide the control.
- Leaving out the condition. “The system must send an email” is incomplete. Send an email when? To whom? Containing what? Every functional requirement needs its trigger and its context.
- Bundling multiple behaviours into one statement. If a requirement contains “and” more than once, it probably needs to be split. Each statement should describe one discrete system behaviour so that it can be tested and traced independently.
- Confusing functional and non-functional requirements. Performance thresholds, security constraints, and availability targets are not functional requirements. They do not describe what the system does; they describe how well it must do it. Mixing them into your functional requirements section creates confusion during testing and scope discussions.
- Writing requirements that cannot be tested. If you cannot describe the pass or fail condition for a requirement, it is not ready. “The system must be user-friendly” fails this test. “The system must display a validation error message adjacent to the relevant field within two seconds of form submission” passes it.
Getting functional requirements right is one of those skills that pays compound interest over a BA career. When they are precise, testable, and well-structured, every downstream activity, from test planning to change management, becomes faster and less ambiguous. When they are vague or conflated with design decisions, the project absorbs the cost through rework, disputes, and scope creep. The quality of your functional requirements is, in many ways, the quality of your analysis.
Frequently asked questions
What are functional requirements in simple terms?
Functional requirements describe what a system must do in response to a specific trigger or user action. For example, when a user submits a payment, the system must update the application status and send a confirmation email. They are the documented behaviours a system must perform to meet the business need.
What is the difference between functional and non-functional requirements?
Functional requirements describe specific system behaviours, such as what happens when a user clicks a button or submits a form. Non-functional requirements describe qualities of the system, such as how fast it must respond or how secure it must be. Both matter, but they are documented and tested differently.
What is the difference between a business requirement and a functional requirement?
A business requirement describes why a project exists and what outcome the organisation needs, such as collecting fees before applications are assessed. A functional requirement describes what the system must do to deliver that outcome, such as displaying a transaction summary screen before routing the user to a payment gateway. Business requirements drive functional requirements, not the other way around.
How do you write a functional requirement correctly?
Each functional requirement should state what the system must do, under what condition, and any rules that govern the behaviour. It should be specific enough to test, free of design decisions, and scoped to a single system behaviour. A unique identifier for each requirement makes traceability much easier as the project progresses.
Where are functional requirements documented?
In waterfall projects, functional requirements are typically captured in a Functional Requirements Document or FRD, sometimes as part of a broader specification. In agile projects, they are often embedded as acceptance criteria within user stories. The format changes depending on delivery approach, but the underlying content remains the same.
Try Ash, Your Virtual BA
If you have just worked through what functional requirements are and you now need to actually write them for a real project, Ash can help you move from understanding to output. Ash is a virtual BA assistant that can guide you through structuring your functional requirements, check whether your statements are testable and well-formed, and help you produce a Functional Requirements Document section by section. You do not need to start from a blank page. Try Ash Virtual BA and turn what you have just read into a document your development team can actually use.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.