BRD Vs FRD

Related Articles

what are the project priorities? Why this is important ? How to handle this ? 

2 days ago

What are the elicitation techniques using in a project?

2 days ago

What is requirement prioritization in Business analysis?

2 days ago

Business Requirements Document (BRD)

 

Business Requirement Document comes handy when we are looking for technology service provider, Consultant or a contractor to help you with a project. In this blog the key concepts related to BRD and its importance for success of a project are discussed.

BRD definition: “A Business Requirement Document (BRD) focuses on the business perspective as it holds the details of the business solution for a project.”

Business requirements document also emphasizes on the needs and expectations of the customer. In simpler terms, BRD indicates what the business wants to achieve.  The BRD indicates all the project deliverable and the inputs and outputs associated with each process function.

 

The process function is responsible for Critical to Quality (CTQs) parameters that relate to needs and wants of the customer. CTQs are responsible for a positive Voice of Customers (VOC). VOC describes the customer’s feedback about their experiences with your products or services. BRD focuses on the business objectives and distinguishes between the business solution and technical solution.

 

Objectives of a business requirement document:

• To get an agreement among stakeholders
• Communicate to the technology server provider, the business needs, the customer needs, and what the solution needs to do to satisfy business and customer needs
• To determine the input to the next phase of the project
• Describe in details of the needs of the customer and business that the solution intends to meet

Business Requirements Document- Key elements

A business ana a project manager who has a thorough understanding of the Business Process drafts business requirement document. The business requirement document is drafted for a project to ensure the implementation of all the requirements to achieve business objectives.

The most critical component of a business requirement document is the scope of the project along with the restrictions and constraints. The scope comprises of three key things:

• What are the problems which the business wants to solve?
• What are the restrictions?
• Is it worth to invest the time and money required for the project?

What are the preparations required to create a business requirements document?

 

There are a few things that you need to do before creating a business requirements document:

• You should define the need of the company/ organization
• You have to get all the stakeholders involved.
• You must identify the phases of the project.
• You should establish benchmarks/ standards for all project requirements.
• You need a process in place to monitor the schedule & measure milestones.
• You will also need to use a suitable template.

 

Who is responsible to create a Business Requirements Document (BRD)?

 

To create a business requirements document, you should include the project’s team, the business partners, and anyone else who may be needed for the project. Businesses grow or change in phases and cycles, and as they change, the requirements may also change. For the changes in the phases of the business, you must create a business requirements document. The size or stage of the development is of little relevance, but what is important is that different requirements are needed for the business to survive or progress to new phases.

 

Who should be involved in business requirements document creation?

A number of teams and partners should create the BRD:

• Core team of the project
• Any or all business partner(s)
• Process owner(s) or representatives
• Subject matter experts
• Change/project/product management, quality department and/or IT management as needed or available

Business Requirement Document Template – An ideal BRD template

Business Requirement Document Template or Sample BRD Document Template Should Contain the following

1. A summary statements
2. Project objectives
3. Needs statement
4. Project scope
5. Financial statements
6. Functional requirements
7. Personal needs
8. Schedule, timeline & deadlines
9. Assumptions
10. Cost & Benefit

 

1- A summary statement

The executive summary is the outline of the requirements of the project. The best time to formulate a summary statement is once the BRD is written completely.

2- Project objectives

The project objectives should be written in a SMART format which implicates they must be specific, measurable, attainable, realistic and time-bound.

3- Needs statement

The needs statement outlines why the project is needed for the business and how the project will be able to meet the needs.

4- Project scope

The project scope outlines what to be included and what should not be included.

5- Financial statements

The financial statements indicate the impact of the project on the company’s balance sheet and revenue over the specific period of time. This also holds the information on the funding of the project and how it would be done.

6- Financial statements

This section outlines in a detailed manner the functional requirements and corresponding features including diagrams, charts, and timelines.

7- Personal needs

This section covers the human resources aspect of the project. Who needs to be hired and when the hiring needs to be done. It also covers the cost of the resources.

8- Schedule, timeline & deadlines

Each phase of the project is covered in detail in this section.  This helps to ensure that all stakeholders are aware of what is required and when it will be required.

9- Assumptions

The assumptions outline anticipated events that would occur during the course of the project.

10- Cost & Benefit

This section holds a detailed list of all the costs involved in the project along with the cost-benefit analysis.  The savings from the project are also listed here.

 

Tips for writing a business requirements document

Are planning to write a successful business requirements document? Here are some tips that you can follow for writing an effective business requirements document:

• Be action-oriented:Don’t use complex jargon rather use simple easy to understand language that encourages action.
• Engage stakeholders:Encourage all the other project stakeholders to get involved in activities such as brainstorming, surveys, focus groups, interviews, and ideas for prototyping.
• Do feasibility research:Research some of the past projects to determine the feasibility of your BRD. Evaluate your project to understand whether the solution desired can be developed within the constraints of time & cost.
• Include visuals:Include visuals and graphical representations, such as charts and diagrams, when necessary, as they can be powerful in making your point.
• Validate the contents:After writing the business requirements document, have it reviewed thoroughly before distribution. Obtain validation of the information and the contents–including the assumptions–and ensure that all errors or omissions are corrected.

 

Best Practices for Business Requirements Documents:

Here are the best practices for BRD:

1. Validate the scope: You must review and refine the scope as needed based on a process detail table, identify the changes to find out what is in or out of scope now that the requirements have been developed. Complete this process prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after approvals from business partners should be handled through a change control process.
2. Create impact document: Create a design-elements diagram for each level two or three process function for impact assessment for:

• Process
• People
• Technology
• Product
• Materials and supplies
• Facilities
• Machinery and equipment
• Others as necessary (depending on the organization)

 

Functional Requirements Document (BRD)

 

The Functional Requirements Document (FRD) is a formal statement of an application’s functional requirements. It serves the same purpose as a contract. Here, the developers agree to provide the capabilities specified. The client agrees to find the product satisfactory if it provides the capabilities specified in the FRD.

Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. The document should be tailored to fit a particular project’s need. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application.

The Functional Requirements Document (FRD) has the following characteristics −

• It demonstrates that the application provides value in terms of the business objectives and business processes in the next few years.
• It contains a complete set of requirements for the application. It leaves no room for anyone to assume anything which is not stated in the FRD.
• It is solution independent. The ERD is a statement of what the application is to do— not of how it works. The FRD does not commit the developers to a design. For that reason, any reference to the use of a specific technology is entirely inappropriate in an FRD.

The functional requirement should include the following −

• Descriptions of datato be entered into the system
• Descriptions of operationsperformed by each screen
• Descriptions of work-flowsperformed by the system
• Descriptions of system reportsor other outputs
• Who can enter the datainto the system?
• How the system meets applicable regulatory requirements?

The functional specification is designed to be read by a general audience. Readers should understand the system, but no technical knowledge should be required to understand this document.

Functional Requirements Deliverables

A Business Requirements Document (BRD) consists of −

• Functional Requirements− A document containing detailed requirements for the system being developed. These requirements define the functional features and capabilities that a system must possess. Be sure that any assumptions and constraints identified during the Business Case are still accurate and up to date.
• Business Process Model− A model of the current state of the process (“as is” model) or a concept of what the process should become (“to be” model)
• System Context Diagram− A Context Diagram shows the system boundaries, external and internal entities that interact with the system, and the relevant data flows between these external and internal entities.
• Flow Diagrams (as-is or to-be)− Diagrams graphically depict the sequence of operations or the movement of data for a business process. One or more flow diagrams are included depending on the complexity of the model.
• Business Rules and Data Requirements− Business rules define or constrain some aspects of the business and are used to define data constraints, default values, value ranges, cardinality, data types, calculations, exceptions, required elements and the relational integrity of the data.
• Data Models− Entity Relationship Diagrams, Entity Descriptions, Class Diagrams
• Conceptual Model− High level display of different entities for a business function and how they relate to one another.
• Logical Model− Illustrates the specific entities, attributes and relationships involved in a business function and represents all the definitions, characteristics, and relationships of data in a business, technical, or conceptual environment.
• Data Dictionary and Glossary− A collection of detailed information on the data elements, fields, tables and other entities that comprise the data model underlying a database or similar data management system.
• Stakeholder Map− Identifies all stakeholders who are affected by the proposed change and their influence/authority level for requirements. This document is developed in the origination phase of the Project Management Methodology (PMM) and is owned by the Project Manager but needs to be updated by the project team as new/changed Stakeholders are identified throughout the process.
• Requirements Traceability Matrix− A table that illustrates logical links between individual functional requirements and other types of system artifacts, including other Functional Requirements, Use-cases/User Stories, Architecture and Design Elements, Code Modules, Test Cases, and Business Rules.

Difference between BRD & FRD

The Business Requirement Document (BRD) describes the high-level business needs whereas the Functional Requirement Document (FRD) outlines the functions required to fulfill the business need.  BRD answers the question what the business wants to do whereas the FRD gives an answer to how should it be done. FRD is derived from a BRD.