BRD- Business Requirement Document or BRS Document
Business Requirement Specification Document both are same. The Business or Clients or other Stakeholders provide a requirement. One requirement can be small or big. But, has to be break wherever it requires and taken as multiple requirements.
FRD- Functional Requirement Document or FRS Document
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? Limitation? any other supporting Process Flows/Maps/Wiring Diagrams etc.
The main difference between BRD and FRD is that a BRD tells the whole requirement (story) whereas the FRD tells the sequence of operations to be performed by a single process.
BRS is actually a document that covers the business aspect of a requirement on a broad level. For eg: let’s consider that you want to develop a new website. Your BRS would address what business your website is being built for. Let’s say it is a website like eBay y and it allows people to shop online. This would be your business requirement covered in the BRS.
The FRS would actually address each function that the website provides in order to make the shopping experience of the people visiting the website efficient and easy. Not just this it would also address issues of security etc that may need to be built into this website. Both the BR and FR can actually be addressed in the same document. However, this depends on the organization. Both BRS and FRS are made by the BA who captures the requirements from the end user. A developer would be involved in making a technical document which would address the technical design of the website which the BA may or may not concern himself with.
FRS is the Functional Requirement Specification it is an initial phase of SDLC. Gathering the requirements from customer and prepares the Business Requirement specification by Business Analysts. Next, in Analysis phase System Analysts analyze the BRS and prepare the SRS (System Requirement Specification).
BRD is a high level documentation (means tables) and SRS/FRS is Low level documentation (use case diagrams).
Data Requirement for creating BRD and FRD
First of all, determine what data already exist that fulfills the requirements you have documented. What is the format and structure of these data? If it is found in a proprietary database, can it be extracted in a structured form?
Obtain the raw data files that will eventually be imported into analysis matrix. They may need to be extracted or exported from databases, or they may already exist in spreadsheet form. At this stage, do not worry about whether the database or data files can be directly accessed by the analyst.
Also Read: Regular Blogging can bring more business
Instead, make sure the data can be accessed via the tools you will be using to prepare the data for the analysis. Most database management systems can export to comma – or tab-delimited text files, and such files will ordinarily be sufficient. Note that the import procedures have been designed to work most smoothly with data source files in Excel.
Determine the condition of the existing data. Are there duplicate records for contacts and other entities? Is data that is supposed to be required actually missing? Is the data consistently formatted? For example, do contact data include both “Mr.” and “Mister”? Establish a plan for cleaning up the data. This process often requires hours of manual processing of the data, so it is important to determine how much of the process will your response be, and how much will be the organizations.
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 the 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 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.
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
- A holistic approach to business needs with the help of the 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.
The format of BRD –
There are many formats or templates that the organization follows. However, it depends upon the practices that are carried in the organization. For a product based company, the BRD format is different as compared to service-based firms. The standard format which is followed in most organizations is shown below. It is important to note that for a clear understanding of the document we should include a list of acronyms used.
The BRD template contains –
- document revision
- RACI chart
- business goals
- business objectives
- business rules
- project objective
- project scope
- in-scope functionality
- out-scope functionality
- business process overview (modeling diagrams, for instance, Use Case and Activity Diagram)
- legacy systems
- proposed recommendations
- business requirements
- list of acronyms
- glossary of terms
- related documents
Functional Requirement Document
FRD highlights “Functional Requirements” i.e., the 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 a technical expert, for instance, System Architect.
Also Read: Learning and Training for an organization
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 build
- 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.
The 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.
The FRD template contains
- Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
- Functional Requirements
- Modeling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data
- Model/Data Dictionary, Functional Requirements
- Other Requirements – Interface Requirements, Hardware/Software Requirements,
Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. In any organization, all projects are being hoped from Waterfall to Agile. If the stakeholders are positive with the documents then BA will design the same. But if there is a need for the continual delivery of a working product then the documentation will not be preferred.
However, documentation will remain a valid artifact of any project in the distant future.