Best of BATimes: BRD Vs FRD
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.
Let’s 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 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.
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
Now let’s 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
Advertisement
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.
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.