What is the difference between BRD, FRD, and SRS
Published by Pavel Nakonechnyy on in Business Analysis.
Working as a Business Analyst, you’ll have to work with several documents for Software Development. BAs usually use two documents: a Business Requirement Document (BRD) and Functional Specification Document (FRD). However, other documents exist and they work together to create a comprehensive view of the project. One of the most important ones is Software Requirement Specification (SRS).
Business Requirement Document (BRD)
BRD is one of the first steps in a software development process and it’s usually created before any technical work begins. It contains the high-level business requirements available for understanding business stakeholders. Sometimes this document is referred to as Business Requirements Specification.
BRD explains what functionality should have and answers the “Why” part of the system requirements. It lists the business stakeholders’ requirements and expectations for the system and several key parts of the project: project scope, objectives, stakeholders, measurables, and constraints. BRD is prepared by business analysts as a result of their requirements elicitation process. BRD’s objective is to define success criteria, minimize scope creep, and establish consensus with the stakeholders.
BRD follows a free-form format with a mix of text and visuals.
Functional Specification Document (FRD)
BRD does not have sufficient information for the development team. Therefore, a separate Functional Specification Document is developed. It includes detailed requirements in technical terms that are used by the technical teams for further development of the system. The testing team uses FSD to build test scenarios. FSD is a technical document prepared by the business or systems analyst.
FRD describes How the system is going to function. It’s a technical response to the needs set out by the FRD and business objectives created during the planning phase of the project. This document focuses on “How” the system will function.
FRD is also known as Functional Specification Requirement (FSR), Functional Specification, and Product Specification.
FRD often employs diagrams in notations like Unified Modeling Language (UML), DFD, functional, or precedents. It includes several important parts: the context of a project (current state of the system), functional requirements, user interface, models (diagrams, flowcharts, prototypes, and mockups), and glossary. Its objective is to define the function of a system, identify dependencies, estimate risk and costs, improve internal project communications and provide a holistic view of every requirement.
After all, the main difference between BRD vs FRD is that BRDs focus on what the product should do while FRDs focus on how the product should do it.
Often, BRD is a part of a formal contract between the client and supplier that captures all the work in a project. Then, FRD is an internal document defining the solution required to meet the business needs identified in the BRD.
Software Requirement Specification (SRS)
Software Requirement Specification (SRS) is a complete description of the behavior of a system to be developed. It describes all the user interactions with the system in terms of use cases. It includes complete business requirements, system properties, constraints, and behaviors, detailing the system’s reliability, response time, storage requirement, etc. It is used to estimate the cost and effort required for developing that software.
It elaborates on the requirements from BRD to include the functional and non-functional requirements. It is usually developed only for big projects, where BRD and FSD are not enough to develop the system.
SRS is developed by system analysts together with business analysts during the planning phase of the project and used by project management, development, and delivery teams.
Comparison table
It isn’t easy remembering all the differences between BRD, FRD, and SRS just from reading a text piece. So, I’ve prepared a comparison table you can grab and use on everyday basis:
| BRD | FRD | SRS | |
|---|---|---|---|
| Order in project development | 1 | 2 | 3 |
| Contains | high-level business requirements | requirements in technical terms | complete description of the behavior of a system to be developed |
| Primary audience | business stakeholders | technical teams | project management, development, and delivery teams |
| Objective | define success criteria, minimize scope creep, and establish consensus with the stakeholders | define the function of a system, identify dependencies, estimate risk and costs, improve internal project communications and provide a holistic view of every requirement | estimate the cost and effort required for developing that software, include both the functional and non-functional requirements |
| Contents | – project scope, objectives, stakeholders, measurables, and constraints – stakeholder requirements and expectations | the context of a project (current state of the system), functional requirements, user interface, models (diagrams, flowcharts, prototypes, and mockups), and glossary | – all the user interactions with the system in terms of use cases |
You can save it as a nicely-formatted picture (click to open full-res):
Conclusion
In conclusion, BRD, FRD, and SRS are all documents important for software development projects, varying in their purpose and authors.