BRD vs FRD

BLOG-1 BRD vs FRD

BRD( Business Requirement Document):

Business requirement document (BRS) or Business requirement specification document (BRS) both are same. The Business/ Client/ other stakeholders provide a requirement. One requirement can be small or big. But, has to break wherever it requires and taken as multiple requirements.

• 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 requirement.

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 chart
• 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

FRD( Functional Requirement Document):

Functional requirement document(FRD) or Functional Requirement Specification document both are same. The process to reach the expectancy of the BRD is an FRD. How we develop the expected requirement? What are the features? Functionalities? Tools or systems used and interdependencies? How they react when start working together when this functionality takes place? Assumptions? Limitations? Any other supporting process flows/ maps/writing diagrams etc.

• 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.

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

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. As in my organization all projects are being hoped from Waterfall to Agile. If the stakeholders is positive with the documents then BA will design the same. But if there is a need for the continual delivery of working product then documentation will not be preferred.

However, documentation will remain a valid artefact of any project in distant future.