What is a functional requirements specification (FRS)?
A functional requirements specification (FRS) defines, testably, how a system must behave: business rules, validations, exceptions, interfaces and acceptance tests, each traced to the PRD. Also called a functional specification (FS or FSD); close to what ISO/IEC/IEEE 29148 calls a software requirements specification (SRS). For software, digital and integration concepts.
Also called: FRS, Functional specification, FS, FSD, Functional requirements document.
Why it matters
User stories say what people need. Engineers and testers need to know what the system does in every case.
The FRS states every rule and every exception, so the team builds and tests against one text, and every requirement traces back to the reason it exists.
How the specification is built
Ainna writes the FRS from the PRD and from a model of the system, so nothing in it is invented on the way.
- Scope. A check of the concept: software, a digital service or an integration, and what is in and out. In Ainna's document: purpose, audience and scope.
- The system model. Its actors, capabilities, components, interfaces and data. In Ainna's document: actors, roles and permissions; interface behaviour.
- The requirements. Each functional area, requirement by requirement, with its business rules, validations, inputs, outputs and exceptions. In Ainna's document: each functional area, requirement by requirement.
- The tests. Acceptance and test conditions for each requirement. In Ainna's document: acceptance and test conditions.
- Traceability. Every PRD requirement traced to the area that covers it, the requirements that specify it and the tests that verify it. In Ainna's document: traceability to the PRD.
What's inside
- Purpose, audience and scope
- Actors, roles and permissions
- Rules that hold across the system
- Compliance touchpoints
- Each functional area, requirement by requirement
- Business rules and validations
- Inputs, outputs and data handling
- Exceptions and system responses
- Interface behaviour
- Acceptance and test conditions
- Traceability to the PRD
- Assumptions and glossary
Where it fits
It is distilled from the PRD's requirements, a check of the concept's scope, and a system model of its actors, capabilities, components, interfaces and data.
It comes after Product Requirements Document (PRD), and leads to System Analysis, Design and Architecture.
Questions
Is an FRS the same as an SRS?
Close, and many teams use the names interchangeably. ISO/IEC/IEEE 29148, the international standard for requirements engineering, calls the software-level document a software requirements specification (SRS) and gives it all of a system's requirements, functional and non-functional. An FRS, also called a functional specification (FS or FSD), concentrates on the functional side: how the system must behave, rule by rule, with its validations, exceptions, interfaces and acceptance tests. Ainna's FRS traces each of these to the PRD, and its architecture document carries the quality targets.
What is the difference between a BRD and an FRS?
A business requirements document (BRD) states what the business needs and why, in the business's own terms. An FRS turns those needs into exactly how the system must behave, testably, for the people who build and test it. In banking, insurance and enterprise IT the two usually come as a pair. In Ainna, the PRD plays the BRD's part, with the business case, the users and the requirements, and the FRS traces every requirement back to it.
Who writes and signs off an FRS?
Usually a business analyst or product owner writes it with the engineering lead. Product signs off the behaviour; engineering and QA sign off that it can be built and tested.
How detailed should an FRS be?
Detailed enough that two engineers would build the same behaviour, and a tester could write a test for each requirement without asking.
Do the work in Ainna.
Ainna is where you frame a problem, explore ideas and test them against the evidence. When the work is done, this is how it is packaged: a functional requirements specification (FRS), written from your own analysis, about your own idea.
Which documents you can create depends on your plan.
Read next
- Where VentureForce began: number 0032 on Problem Radar
- All twelve: the document examples, together