When a customer come to here and say, hey I need help with my problems. So what should we do? We will send a BA out to learn about his/her problems firstly. This phase is called”requirement gathering”. Based on the document given by BA, developers and testers will know what should we do to solve the problems.
So what is a business requirement and functional requirement?
Business requirement document (BRD) are written to define the requirements of a business process or system that needs to support a business process. Or let’s say it is mainly about what customers want us to do. It contains the business requirements that needs to be met and fulfilled by the software product that we are going to develop. For example, if a customer or client want to manage his/her inventory effectively and efficiently, the BRD may state that the client needs a system to better manage his/her inventory, and e.g. lower down the inventory level, faster response, etc. Such document identifies what the system must to in order to fulfill the requirements of the client.
In contrast, FSD defines “how” the system will fulfill the requirements of the clients by outlining the functionality and features that will be supported by the system. Once the business requirements are established, the functional requirements are defined and developed in order to move the project forward. This document is mainly targeted at the technical team to understand the requirements correctly and implement the solution in an intended way.
Here is a really good example from ajiethkumar.wordpress.com:
Requirement in BRD – The user should be able to capture the customer data.
Requirement in FSD – For User to capture the customer data, create a menu option called ‘Customer Data’. When the user clicks on the menu option, render a screen/pop-up window/dialog-box containing the FORM with the required fields (Name, Address, City, State, Zip, Phone, SSN, etc.) and ‘Save’ & ‘Cancel’ button. When the user clicks the ‘Save’ button, and validate the FORM for mandatory fields are populated and the correctness of the field values that is entered.
If ‘yes’, save the details.
If ‘no’, then alert the user with meaningful error message and highlight the fields with error. Also retain the values of the fields in the form that are correct.
From the above example, it is seen that a one-liner BRD statement can lead into a complex level of implementation. These steps are decided by the SME while writing the FRD in conjunction to the Product Knowledge.
Hence a one-pager BRD may end up in multiple pages of FSD.