Module Name - Business

Problem Solving and

Storytelling

EditEdit
MasterMaster
Topic - Documentation
texttext stylesstyles
Today’s Agenda
1. Introduction to BRD
2. Key elements for creating BRD
3. Best Practices for creating BRDs
4. BRD v/s FRD
5. Applications of BRD
6. Sample BRD template
Definition: Business Requirement Document (BRD)

“A Business Requirement Document (BRD) focuses on the

business perspective as it holds the details of the business
solution for a project”

In simpler terms, BRD shall indicate what the business wants

to achieve. The BRD indicates all the project deliverables and
the inputs and outputs associated with each process function
related to the project.
Job Roles & Recent trends
1. Aligning with Business Objectives
Consider a scenario where a retail company wants to build a new e-commerce
platform. Without proper business analysis, the development team might focus solely
on building the technical infrastructure but could miss critical business objectives.
Scope of work: A skilled Business Analyst would delve into the company's goals
and suggest features such as personalized recommendations and a streamlined
checkout process, aligning the technical work with the overarching business
strategy.
2. Requirements Definition
Clear requirements are the foundation of any successful software project. Take a
healthcare software system, for example. A comprehensive BRD for such a system
would outline the need for secure patient data storage, easy access for medical
professionals, and adherence to healthcare data regulations.
Example: These requirements ensure that sensitive patient data is protected and
readily available to authorized personnel.
Job Roles & Recent trends
3. Risk Mitigation
Software projects often face risks such as scope creep, changing requirements,
or conflicts among stakeholders. A Business Analyst acts as a risk manager.

Industry Example: For instance, in a financial software project, a change in

government regulations might impact the project. A skilled Business Analyst
would identify this risk early and devise a plan to adapt to regulatory changes,
ensuring the project remains on track.

4. Efficient Resource Allocation

In the world of software development, time and resources are precious
commodities. A well-defined BRD helps in prioritizing requirements. Consider an
educational software project. The BRD may differentiate between "must-have"
features like a student grading system and "nice-to-have" features like a virtual
classroom. This ensures that development resources are allocated wisely.
Key Elements for creating BRD
 Key Elements for creating BRD
1. Executive summary
The executive summary outlines the project’s requirements. It is usually written after
the BRD is completed so that all major points can be included.

2. Project Objectives
It is crucial to create an objective that is specific, measurable, achievable, realistic and
time-dependent. It makes it easy to establish a comprehensive agreement while
keeping the project focused and on track. An often overlooked component is the
measuring process that identifies and enables modification if and when it is necessary.

3. Project scope
The project scope shall outline the boundaries of the project and is one of the most
critical components. The scope answers three important questions:
 What are the problems that the project addresses?
 What are the boundaries for implementing the project?
 What is the expected ROI from the completion of the project?
 Key Elements for creating BRD
4. Business Requirements
Business requirements are essential for an overall view of the project’s impact on the company’s
balance sheet and expected revenues. This section should also include details about how the
project will be funded.
 Functional requirements
The functional requirements section details who is responsible for what, how, when and where
the project will be completed and what is needed to accomplish that. This should include
timelines, diagrams and charts to help in planning and recording progress.

5. Key Stakeholders
Project stakeholders include anyone with an interest in your project. These are likely the people
who will read your BRD template to understand what the project is about. The key stakeholders
include:
• Team members working on the project
• Project managers leading the project
• Executives approving the project
• Clients influenced by the finished project
 Key Elements for creating BRD
6. Project Constraints
It is crucial to create a thoroughly planned and detailed schedule that includes deadlines,
milestones and a monitoring system. This will help keep key stakeholders updated on the project
at specific phases. Adjustments can be made to add or subtract resources to keep certain
components of the project, such as cost and resources, on track. Project constraints may include:
• Project risks
• Team availability
• Resources
• Project dependencies
• Deadlines
• Project budget
Project constraints help stakeholders visualize the complexity of the project and how easy it will be
to achieve project objectives. Anyone involved in the project should first review the project
constraints.
7. Cost-benefit analysis
A cost-benefit analysis details about all the associated costs involved in the project along with the
expected benefits.
 Case Study: Designing a BRD for e-commerce website

Problem Statement:

Mr. Prashant is working as a business analyst in XYZ corporation, he is required

to create a Business Requirements Document (BRD) that outlines the goals,
objectives, and specifications of a software project for e-commerce website.
Draft a BRD based on the purpose & scope highlighted below:

Purpose of the BRD: To define the requirements for the development of an e-

commerce website.

Scope: The website will include features for browsing products, adding items to cart,
making payments, and managing user accounts.
 Case Study: Designing a BRD for e-commerce website

Business Objectives:
- Increase online sales a user-friendly and efficient shopping experience.
- Capture customer data for marketing and personalized recommendations.
- Improve customer satisfaction through fast, secure, and accurate order processing.

Stakeholders:

Project Sponsor: The executive responsible for funding and overall success of the
website.

Product Owner: The primary stakeholder who will provide input and make decisions
on behalf of the business.

Development Team: Com designers, developers, testers, and other technical

members responsible for building the website.
 Case Study: Designing a BRD for e-commerce website
Functional Requirements:
User Registration: Users should be able to create accounts, login, and manage their personal
information.
Product Catalog: Display a list of available products with search, filter, and sorting options.
Shopping Cart: Allow users to add/remove items, specify quantities, and view a summary before
checkout.
Payment Processing: Integrate with a secure payment gateway to handle transactions.
Order Management: Provide order history, tracking, and cancellation options for users.
Admin Dashboard: Enable administrators to manage products, inventory, users, and orders.
Non-Functional Requirements:
Performance: The website should be fast and responsive, capable of handling a high number of
concurrent users.
Security: Implement strong encryption, user authentication, and protection against common web
vulnerabilities.
Scalability: Design the system to handle future growth by easily adding new features and
accommodating increased user traffic.
Usability: Ensure the website is intuitive and easy to navigate, with clear instructions and error
handling.
 Case Study: Designing a BRD for e-commerce website

User Stories and Use Cases:

- User Story 1: As a customer, I want to be able to search for products so I find
what I'm looking for.
- User Story 2: As a registered user, I want to be able to save items to my wish list
for future purchase.
- Use Case 1: Process Payment - The system will integrate with a payment
gateway to securely process credit card transactions.

Note:
This is just a basic example of how a BRD can be structured for an e-commerce website. In a real-world
scenario, the document would be much covering all relevant requirements and specifications needed for the
successful development of the software project.
Sample Template
Best Practices for writing BRDs
Use words that encourage action: There are several ways to encourage action with
the use of words and that includes using very simple and uncomplicated jargon that is
easy to understand.

Get others involved: It is crucial to encourage others to get involved with activities
such as brainstorming, focus groups, interviews, surveys and ideas for prototyping.

Do some research: Research past projects to determine the feasibility of the BRD.
Evaluate the project to determine if it stands up to scrutiny.

Include visuals: Include visuals, such as charts and diagrams when necessary, as
they can be powerful in making point and sending the message to wider audience

Validate the contents: After writing the business requirements document, review
must be completed before distribution.
Best Practices for writing BRDs
Continually gather requirements
While you usually gather requirements early on in the project life cycle, business
analysts should be open to identifying and documenting new requirements as
needed. It can be tempting to sweep new information under the rug if you’ve already
progressed past the initial stages of the project. However, the end product will be
better if you have fleshed out all the requirements necessary—even if they were
added later in the game.

Get to know your stakeholders

Build a rapport with your stakeholders and learn how they operate. Tailor your
elicitation methods to their style or preferred method. By adapting your methods to
the person, you will be more effective in gathering requirements.
BRD v/s FRD
Applications of BRDs

A well-developed BRD has several applications, including that it can:

By using this document one can verify test cases cover all functionality of the
application as per the requirements of the customer:

Requirements: Requirements of a particular project from the client.

Traceability: The ability to trace the tests.

Matrix: The data which can be stored in rows and columns form.
#LifeKoKaroLift

Thank You!