When an aspiring analyst starts to learn about documenting project’s requirements she/he is bound to come across terms like Business Requirements Document (BRD), Software Requirement Specifications (SRS) document and Functional Requirement Specifications (FRS) document. In this article, we will break down each of these documents, explore their uses, and understand the subtle differences between them.
Business Analysis is governed by certain defined standards and frameworks that should be followed in order to carry out effective analysis of requirements in any project. However, there are no universally accepted guidelines for BRD, SRS, and FRS in any of the bodies of knowledge (BABOK, CMMI) in terms of their overall structure (format), contents and the level of details. Thus, this results in organizations modifying these requirement documents based on their processes & standards, the resource available with them and type of project.
The information described below is in line with the most widely accepted business analysis and project documentation practices.
If you just wish to quickly understand the major differences between the three document types you may refer the comparison grid below, however, I would recommend going through the complete article to have a robust understanding.
Business Requirements Document (BRD)
A BRD is one of the most widely accepted requirements document 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 spent by the employees on different activities.
BRD is usually one of the first few documents
A BRD is always prepared by the business analyst on the project and is created after performing an analysis of the client company and talking to the client stakeholders. Once a BRD is prepared it’s often reviewed and signed off by the client to ensure it correctly captures the expectations of the business as well as the key stakeholders.
The primary audience of the BRD
Software Requirement Specifications (SRS) document
Once it has been identified ‘why’ the project is being undertaken (by creating the BRD), it’s now time to document ‘What’ requirements must be fulfilled in order to satisfy the needs of the business.
A Software Requirement Specifications (SRS) document is a detailed and structured requirements document that contains the functional requirements (depicts 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: Will authenticate the user based on the login credentials entered and allow only the registered users to login.
- Administrator Module: Will contain the features that will allow an admin to manage the users – Add user, edit users, delete/inactivate user, add/edit user permissions, group users, add projects, etc.
- Employee Module: Will include the features that will help employee enter his effort details – Enter/edit effort spent, enter/edit task details, choose project, edit basic details, reset password, view previous effort details, etc..
- Reporting Module: Module exclusive to the administrator and will allow them to extract aggregated time and effort reports against users, projects and tasks. Furthermore, the admin should be able to export these reports in .xlsx and PDF formats.
SRS is one of the vital document in any project as it bridges the gap between what business wants and what they will get by documenting the broad layout, characteristics, and workflows of the software being developed. Since a software’s major requirements are clearly organized and elaborated in an SRS, it’s commonly used for estimating the cost and effort required for developing that 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’ the BRD’s high-level statements into module, sub-module and features without going in depth on each and every page.
The SRS is prepared by the systems analyst of the project, however, in case a systems analyst is not available it may even be prepared by the business analyst. To prepare an SRS, the analyst has to conduct requirement elaboration sessions with the relevant stakeholders, meticulously analyze all the aspects of the software being developed and then list down the requirements against each one of them. It’s ensured that every listed requirement in an SRS should fulfill the business objectives listed in the BRD.
The primary audience of the SRS are the project managers, SMEs (subject matter experts), technical and implementation lead 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, non- functional requirements and use case details.
Functional Requirement Specifications (FRS) document
The FRS document is the most detailed and granular document of the three and it finally describes ‘How’ exactly the system is expected to function in order 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 textbox that will allow the user to enter the username which is their registered company’s email ID.
- Enter Password: This field is a textbox that will allow the user to enter the password. The entered password should not be shown to the user and encrypted as a ‘*’.
- Submit button: This button, when clicked will validate 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 elaborates all the functional requirement (including business, compliance, security requirements, etc..) in an unambiguous manner by specifying all the fields and user interactions on every page of the software being built. Also, to aid 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 the perspective of a user and describes how the software will behave when an external user interacts with it. This project artifact is referred by the development team to understand what exactly they have to build and by the testing/QA team to know what are 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 post-completion this document is reviewed by the project manager. Thereafter, the FRS is shared with the clients for a final review and once approved this document becomes a standard document (aka baseline) that defines the way the software is to function.
The primary audience of the SRS are the technical leads, development teams and testing teams.
Other names – Functional Specifications Document (FSD), Functional Specification (FS), Product Specification, and Functional Specs.