Author Topic: BRD Vs FRD  (Read 231 times)

1213066901

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
BRD Vs FRD
« on: April 11, 2021, 09:48:31 pm »
What is the difference between BRD and FRD?.

1211663501

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: BRD Vs FRD
« Reply #1 on: May 29, 2021, 11:41:01 am »
Business Requirement Document

-    BRD highlights ?Business Requirements? ? i.e., high-level business goals of the organization developing the product or solution with the help of IT.
-    In other words it describes at very high level the functional specifications of the software
-    A formal document illustrating the requirement provided by the client
-    The requirements could be collected either by verbal or written or both
-    Created by a Business Analyst (usually) who interacts with the client
-    Entire work is executed under the supervision of the Project Manager
-    It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD ?

-    To arrive at a consensus with stakeholders
-    To provide input into the next phase of the project
-    To explain how customer/business needs will be met with the solution
-    Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder?s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Functional Requirement Document

-    FRD highlights ?Functional Requirements? i.e., functionality of the software in detail
-    Depending on the product, FRD document can be between 10 to 100 pages
-    It too describes at a high level the functional and technical specification of the software
-    Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
-    In a small and medium sized organizations a BA take care of this
-    Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
-    FRD is derived from the BRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Here an analyst after discussing with stakeholders and project manager ponder on questions like ?

-    How we develop the expected requirement(s)?
-    What are the features and functionalities?
-    What are the tools and/or systems used and their dependencies?
-    How will the customer reacts when they start using the solution?
-    Any assumptions or constraints?

Most common objectives of FRD ?

-    Depict each process flows for each activity interlinking dependencies
-    Holistic view for each and every requirements, steps to built
-    Estimating detailed risks for each new change request
-    Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.