Functional requirements
Functional requirements (FRs) are requirements that specify what a system should do – the specific behaviors, features, and capabilities a user needs from it – as distinct from non-functional requirements, which specify how well the system should perform (its quality attributes, such as performance or availability).
A good functional requirement describes a user-visible outcome, not an implementation. It should hold up even if the underlying UI or technology changed completely:
| Good | Bad |
|---|---|
Allow payments to be made by credit card |
Integrate with [payment provider] |
The user can buy the book |
Add a "buy" button to the product page |
Notify the user when their payment has failed |
Show an error dialog with the message "Payment failed" |
Keeping requirements free of implementation detail – UI widgets, API calls, database schemas – keeps the specification stable as the technical solution evolves, and preserves the technical team’s ownership of how the requirement is met.
Expressing functional requirements
Functional requirements can be captured with a mix of artifacts – use cases, user stories, user journeys, wireframes, entity relationship diagrams – chosen to fit the nature of the change.
A common approach is to lead with Gherkin feature files. Each feature opens with a user story (who the feature is for, what they want, and why) and is then made concrete through acceptance criteria written as scenarios, which double as the input to acceptance testing.
Large pieces of functional scope should be broken down into smaller, independently deliverable features (an "epic" like authentication might decompose into registration, login, password reset, and roles) so that requirements, design, and delivery can proceed incrementally rather than as one large batch.
Where functional requirements live
Functional requirements are typically collected in a product requirements document (PRD), written from a business/end-user perspective, and then elaborated – alongside non-functional requirements – into a system requirements specification (SRS) as a change moves through design and delivery.