When aspiring analysts begin learning about documenting project requirements, they are bound to encounter terms such as Business Requirements Document (BRD), Software Requirements Specification (SRS), and Functional Requirements Specification (FRS).
If you are looking for a quick comparison between the three, then here you go:
- BRD contains ‘high-level’ business requirements,
- SRS contains ‘detailed’ functional and non-functional requirements
- FRD/FRS contains ‘granular’ functional requirements, data flow, and UML diagrams.
However, if you want to understand the subtle differences and uses of all three documents, please read on…..
Business Analysis is governed by specific, defined standards and frameworks that should be followed to conduct practical requirements analysis in any project. However, there are no universally accepted guidelines for BRD, SRS, and FRS across any body of knowledge (e.g., BABOK, CMMI) for their overall structure (format), content, and level of detail. Thus, this results in organizations modifying these requirement documents based on their processes & standards, the resources available to them, and the type of project.
The side-by-side comparison below aligns with the most widely accepted business analysis and project documentation practices:
[Please click the image to expand]
Business Requirements Document (BRD)
A BRD is one of the most widely accepted requirements documents, and BABOK, the globally recognized standard for the practice of business analysis, defines it as:
A Business Requirements Document (BRD) is a requirements package that describes business requirements and stakeholder requirements (it documents requirements of interest to the business, rather than documenting business requirements).
Example: One of the statements in the BRD could look like:Â “The Company would like to improve its efficiency by tracking the time employees spend on different activities.“
BRD is usually one of the first documents created in the project
The BRD also contains the needs of a specific/group of stakeholders that will interact with the final service or product. Thus, it answers the ‘Why’ part of the requirements (and not ‘What’ or ‘How’), i.e., why the requirements are being undertaken and what results are expected from the system. It should be noted that all future requirements, enhancements, and change requests against the project should be justified by the company’s (or business’s) goals and needs listed in the BRD.
The project’s business analyst always prepares a BRD after analyzing the client company and speaking with stakeholders. Once a BRD is ready, it’s often reviewed and signed off by the client to ensure it correctly captures the business’s expectations and the key stakeholders.
The primary audience of the BRD
Software Requirement Specifications (SRS) Document
Once the ‘why’ of the project is identified (by creating the BRD), it’s time to document the ‘What’ requirements that must be fulfilled to satisfy the business’s needs.Â
A Software Requirement Specifications (SRS) document is a detailed and structured requirements document that contains the functional requirements (illustrates behavior), non-functional requirements (depicts characteristics) along with any use cases that the software must fulfill.
Example: The proposed software to track the employee’s office time will contain the following modules:
- Login Module: This module authenticates users using the credentials entered and allows only registered users to log in.
- Administrator Module: This module will contain features that allow an admin to manage users: add, edit, or delete/inactivate users; add/edit user permissions; group users; add projects, etc.
- Employee Module: This module will include features to help employees enter their effort details: enter/edit effort spent, enter/edit task details, select a project, edit basic information, reset the password, view previous effort details, etc.
- Reporting Module: This module is exclusive to administrators and allows them to generate aggregated time-and-effort reports for users, projects, and tasks. Furthermore, the admin should be able to export these reports in .xlsx and PDF formats.
SRS is a vital document in any project. It bridges the gap between what businesses want and what they will get by documenting the software’s overall architecture, features, and workflows. Since a software’s major requirements are clearly organized and elaborated in an SRS, it’s commonly used to estimate the cost and effort required to develop the software. At times, it’s even used as a contractually binding document between two parties since it contains enough details to reach an agreement.
You can view an SRS as a document that elaborates on the BRD’s high-level statements into modules, submodules, and features, without going in-depth on each page.
The project’s systems analyst prepares the SRS; however, if a systems analyst is unavailable, it may be prepared by the business analyst. To prepare an SRS, the analyst must conduct requirement elaboration sessions with the relevant stakeholders, meticulously analyze all the aspects of the software being developed, and then list the requirements for each. It’s ensured that every listed requirement in an SRS meets the business objectives outlined in the BRD.
The primary audience of the SRS is the project managers, SMEs (subject matter experts), and technical and implementation leads responsible for overseeing the development of the listed functionalities.
Other names: Product Requirements Document (PRD) and System Requirements Specification
Note: Some organizations or small projects do not create an SRS and just elaborate their BRD to accommodate the functional and non-functional requirements and use case details.
Functional Requirement Specifications (FRS) Document
The FRS document is the most detailed and granular of the three. It finally describes ‘How’ precisely the system is expected to function to satisfy all the requirements listed in the BRD and SRS.
A Functional Requirement Specifications (FRS) document is a granular and low-level document that elaborates all the details around the functional requirements on a project.
Example: The Login module will contain the following fields
- Enter Username: This field is a text box that allows the user to enter their registered company’s email ID.
- Enter Password: This field is a text box that allows the user to enter the password. The entered password should not be shown to the user and should be encrypted as a ‘*’.
- Submit button: When clicked, this button validates whether the entered credentials are valid. In case either the username or the password is incorrect, the system should display an alert message ‘Incorrect Username or Password’……
The FRS document is very descriptive and unambiguous in its description of all functional requirements (including business, compliance, and security requirements), specifying all fields and user interactions on every page of the software being built. Also, for better comprehension, process flow diagrams, UML diagrams, and wireframes are added to the FRS.
It should be noted that the FRS document is created from a user’s perspective and describes how the software will behave when an external user interacts with it. The development team uses this project artifact to understand precisely what they have to build, and the testing/QA team uses it to understand the different scenarios & test cases on which the software should be tested.
The FRS is prepared by the business/systems analyst on the project, and after completion, it’s reviewed by the project manager. After that, the FRS is shared with the clients for a final review, and once approved, it becomes a standard document (aka baseline) that defines how the software is to function.
The primary audience of the SRS is the technical leads, development teams, and testing teams.
Other names: Functional Specifications Document (FSD), Functional Specification (FS), Product Specification, and Functional Specs.
Â
FREE KIT DOWNLOAD: Get BA Documents Template Toolkit!!
Our free Template Toolkit contains the following professional, pre-formatted, and ready-to-use Business Analyst Document templates:
- Use Case Document Template
- Requirement Traceability Matrix (RTM) Template
- Requirement Management Plan Template
- Project Vision Document Template
- Test Case Template