Home / BA / BRD vs FRD

BRD vs FRD

Documentation


Documentation is the most important aspect for any BA. The documentation is useful to depict the requirements and the detailed discussion about new features and change request if any. There are many different types of documents that a BA prepares. Some of the important ones are listed below –

  • Business Requirement Document (BRD)
  • User Stories
  • Use Case Specification Document
  • Functional Requirement Document (FRD)
  • Requirements Traceability Matrix (RTM)
  • Market Requirements Document (MRD)
  • Product Requirements Document (PRD)

Apart from these there are several other documents that is created by Business Analyst. It helps in understanding the business process and business events. A business events is a trigger that gives birth to the requirement. These requirements are then fulfilled by opting for IT solution.

Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

serveimage

Documentation pictured as sheets comprising some useful information

Lets take a look at the similarities and striking differences between BRD and FRD.


Business Requirement Document

  • BRD highlights “Business Requirements” – i.e., high-level business goals of the organization building 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

Below is the sample BRD document –

sample brd

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


Format of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

  • document revision
  • approvals
  • RACI charti
  • introduction
  • business goals
  • business objectives
  • business rules
  • background
  • project objective
  • project scope
  • in-scope functionality
  • out-scope functionality
  • assumptions
  • constraints
  • risks
  • business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
  • legacy systems
  • proposed recommendations
  • business requirements
  • appendices
  • list of acronyms
  • glossary of terms
  • related documents

Now lets try to dig more in FRD…


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 with discussing with stakeholders and project manager ponder on questions like –

  • How we develop the expected requirement?
  • What are the features and functionalities?
  • What are the tools and/or systems used and their dependencies?
  • How will the customer reacts when 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

Below is the sample FRD document

sample frd

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


Format of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD. But there should be no confusion for BA to prepare this document.

The FRD template contains –

  • Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
  • Methodology
  • Functional Requirements
  • Modelling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
  • Other Requirements – Interface Requirements, Hardware/Software Requirements,
  • Glossary

From the above account we could conclude that the usage of BRD vs FRD is a clear example where such miscommunication creates a quite bit of confusion.

About Arpan Rewatkar

Check Also

Acceptance Criteria, Business Value and Complexity Point in Scrum-

Acceptance Criteria: Acceptance Criteria are the conditions or stories that a software system product or …

Leave a Reply

Watch Dragon ball super