This blog is targeted at the audience to give a very high-level outlook on “Business Requirement Document” and “Functional Specification Document”. In my forth coming blogs, I shall write on the above said documents in detail.
Business Requirement Document (BRD)
This document contains the client requirements at a very high level merely in terms of English words. These requirements can be one-liner, a statement or user stories. It depends on how the client reverts back to the Business Analysts (BA).
In general, BA’s use various Business Requirement Gathering Techniques (like Questionnaires, One-One Interviews, Group Discussions, Requirements Patterns etc.) to get the information from the client depending upon the complexity of the business and availability of the client.
BA’s shall capture those initial requirements and then revert back to the client for further clarifications on the initially stated requirements to make it crystal clear and to test the understanding. This keeps both the Client and BA in the same page.
This document generally does not have solution for the requirement in it. Upon mutual agreement over the requirements, client signs-off the document. The signed-off document shall be passed on to the Subject Matter Experts (SME) for bridging the gap, if any.
NOTE:
- In some cases, this document will have the solution to the requirements.
- BA’s can be SMEs themselves. When a BA is a SME, then the client interaction for Business Requirement Gathering may go an extra mile from Functional Requirements perspective as well. Hence the document will have more details in it and may also act as FSD by itself. Sometimes it is called Statement of Work (SOW).
- In some cases, the Project Manager (PM) shall act as both BA and SME. This is a corner case.
Functional Specification Document (FSD)
From the signed-off BRD, the SME shall look upon for an optimum feasible solution from the available solutions. Then SME shall start writing the document called FSD elaborately. FSD will contain the apt solution and the workflow to achieve the solution in terms of the product’s intended capabilities, look and feel, and UI.
This document is mainly targeted at the technical team to understand the requirements correctly and implement the solution in the intended way. Hence the document shall have details about the workflow laid in to achieve the solution.
For e.g.,
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.
NOTE:
- The implementation ideas in FSD shall be shared with the Users for their consent (for both solution and usability) and then be implemented. This keeps the stakeholders in sync and also a precaution to avoid rework.
- The FSD should be developed keeping holistic view of scalability and third-party interfacing in mind.
