The FRD is what you produce when the delivery context demands a formal artifact: regulated industries, government procurement, large outsourcing contracts, or any situation where "we discussed it in Jira comments" isn't sufficient proof of what was agreed.
A functional requirements document captures what a system must do — the behaviors, functions, and interactions it must support — in a form that can be reviewed, approved, signed, and referenced later.
A complete FRD typically contains:
- Scope statement — what's in and what's out
- Stakeholder needs — who the system serves, organized by role
- Functional requirements — specific, testable statements ("the system shall allow a user to reset their password via a link sent to their registered email address")
- Data requirements — key entities, attributes, and relationships
- Interface requirements — integration points with external systems
- Assumptions and constraints — what the solution depends on or is bounded by
Each requirement gets a unique ID for traceability purposes.
On the LPT project, I wrote requirements documentation — but not as one big FRD. It was structured as a knowledge base: processes described in BPMN, requirements organized by business domain, linked to specific Jira tickets. The substance of an FRD, but with a structure that made it actually usable by developers who needed to navigate it daily.
BABOK doesn't mandate an FRD as an output. It specifies outcomes — requirements must be specified, organized, and verified. The FRD is a common way to achieve those outcomes when the context demands it.
Exam tip: The question isn't "should there be an FRD?" It's "what format and level of detail does this context require?" That judgment is what CBAP questions test.