are you tired of wasting your time on requirements that nobody wants if so
stick around for this tutorial on creating an effective business requirements document
hey Doc Squad Dr White here with the business analysis doctor today I'm giving you a detailed
tutorial on creating an effective business requirements document but before we get started
if you want more business analysis training and tips be sure to subscribe to the page and
turn on the notification Bell with that said let's get started now let's talk about what
you'll learn first we'll look at what a business requirements document is or BRD we'll look at the
primary BRD audience then we'll look at the main components of a BRD we'll look at some BRD best
practices and then we'll look at an example of a business requirements document so what does a
business requirements document this is a formal document that outlines high-level requirements
including business and stakeholder requirements it describes the project rationale the scope of
the project as well as the key stakeholders the business requirements document is often referred
to as the BRD business requirements documents are used to create stakeholder alignment on
the business needs create a shared understanding of the solution scope what needs to be achieved
and the required resources it also provides a basis for decision making regarding scope
prioritization and resources so who is the brd4 the primary audience for the business requirements
document includes the sponsor who's responsible for the overall success of the project and will
be the final decision maker regarding the project goals and scope senior Executives and high-level
decision makers need to understand the business goals of the project and how they align with the
Strategic goals of the overall organization the subject matter experts will provide significant
input and insight into identifying the business needs and defining the objectives scope and
expected outcomes marketing and sales teams may need to understand the overall scope and direction
of the project in order to develop effective messaging and marketing strategies external
stakeholders such as vendors and partners may be interested in understanding the broader business
objectives and direction of the project in order to allocate the proper resources to support it so
the main components of a business requirements document includes business requirements
stakeholder requirements the business process overview scope and limitations a glossary
an appendix and the approvers and sign off the first section we'll look at is the business
requirements business requirements are statements that describe the problem or opportunity the goals
the objectives and the expected outcomes unlike stakeholder or solution requirements business
requirements are a combination of different types of statements that represent the high-level
business needs and the reasons for the project the main components of the business requirements
documents section includes the following need statement the need statement comes in the form
of a problem statement or an opportunity statement problem statements describe internal or external
issues that cause damage to the organization this focuses on current problems such as Revenue
loss dissatisfy customers delays and operations and services or non-compliance with regulatory
requirements these problems need to be resolved by the project opportunity statements describe
the current situation and outlines the potential areas of growth for improvement in a particular
area this may include opportunities to increase areas such as Revenue customers markets reputation
Etc these opportunities are to be seized by the project next is business goals business
goals are statements that describe longer term ongoing and qualitative States or conditions that
the business is seeking to achieve and maintain high-level goals are generally broken down into
various areas to include the expected results for example improve customer satisfaction increase
market share enhance brand recognition or create new capabilities next is business objectives these
are quantifiable results expected from achieving the goals these are measured to assess whether or
not the goals have been met a common approach to validating objectives is to ensure they meet the
smart criteria the first Criterion for the smart objectives is being specific specific objectives
describe something that has an observable outcome measurable objectives are trackable to measure the
outcome attainable objectives are feasible in relation to the effort and the goals relevant
objectives align to the Enterprise's vision mission and goals and time-bound objectives
Define a time frame that is consistent with the need the last component for business requirements
is Success metrics these are indicators that are measured in order to assess the
factors that have the greatest impact on the Project's success business objectives indicate
the progress toward meeting the overall business goals while success metrics are the elements that
get measured to indicate the progress towards meeting those objectives now let's discuss the
main components of the scope and limitations section the first element in this section
is solution scope this is the new features and capabilities that comprise the boundaries of the
change and the characteristics of the solution the more requirements approved the larger the
solution scope it's best practice to indicate the solution components that are in scope as well as
out of scope for the project the solution scope May describe changes to functions capabilities
technology business rules data or processes next we have the stakeholders these are the people or
groups who will be impacted by the project including internal and external stakeholders
key roles and responsibilities may be outlined here as well constraints are influencing factors
that cannot be changed and create limitations or restrictions on the product or solution
raw projects may have both project and solution constraints the BRD will only include solution
constraints assumptions are influencing factors that are considered to be true but has not been
verified they could also be conditions that are true now but may not be in the future these
assumptions are confirmed or disproven prior to making any decisions on which they impact
dependencies are the components of the solution that are dependent on the completion of internal
or external project factors common dependencies may be the implementation of requirements that
are dependent on other requirements decisions to be made resources funding or other constraints
outlining dependencies is an easy way to better understand what tasks need to be completed and
in what order the next section is the business process overview a business process describes
how work is performed within the organization including the steps involved the roles and
responsibilities of those involved and the systems and tools used to execute the process by including
the business process in the BRD stakeholders can get a better understanding of how the business
operates and how the proposed solution will impact existing processes this information is
important for defining the scope and designing the solution that meets the needs of the business it's
generally best practiced to include a depiction of the current state and the future State the current
state is a depiction of the existing state representing how a process within the context
of the project is currently performed in the organization this is often represented as an as
is process model the future state is a depiction of the desired or Target State representing how
process is expected to be performed within the scope of the project after changes have been made
this is often represented with a 2B process model the next section to include is the stakeholder
requirements stakeholder requirements are statements that describe the needs of the
stakeholder or stakeholder group that need to be met in order to fulfill the business requirements
please note that solution requirements such as functional and non-functional requirements should
not be included in the business requirements document those are reserved for more detailed
requirement specifications that come after the vrd has been approved we'll talk more
on that later in the lesson a complete list of stakeholder requirements should convey the key
features of the solution these statements will be decomposed into solution requirements in
Downstream specification documents it's often helpful to group The stakeholder requirements
by stakeholder groups it could help to ensure the requirements are organized in a way that
ensures that each stakeholder understands which requirements are relevant to them and can avoid
confusion it also makes it easier to track progress on individual requirements to ensure
that all stakeholders have provided their input now let's look at the supplemental sections of
the business requirements document these are additional sections that provide additional
context background information or supporting details that are relevant to the business
requirements these sections can vary based on the project and organization common supplemental
sections that may be included in the BRD include the glossary of terms which provides a common
understanding of the terms that are used in the BRD this is especially critical when a term may
have different meanings for different stakeholders or if there are acronyms that need to be defined
for stakeholders who may not be familiar with them the appendix includes any attachments or links to
additional information outside of the actual BRD that is relevant to the project such as diagrams
charts or tables and finally the approvers and sign off this section includes the signatures
of all stakeholders with decision-making authority to indicate their approval of the
business requirements document a signed off BRD ensures that all stakeholders are in agreement
with the requirements outlined in the document now let's take a look at some best practices
for the business requirements document it's best practice to document business requirements in a
separate document prior to including it as part of a larger document that contains all levels of
requirements here are some reasons why a BRD is needed before a functional requirement or
a software requirement specification document is developed first of all a BRD provides context and
scope having sign off on the BRD helps to ensure that the upcoming detail requirements focus on the
right goals and objectives and insurance coverage for all necessary features and functionalities it
prevents waste having sign off on the BRD also helps prevent wasted time and effort
spent on analyzing and documenting detail require environments that don't align with the business
objectives are deemed to be out of scope the BRD helps guide decision making by providing a clear
understanding of the business requirements and priorities this helps the analyst and development
team prioritize features and functionalities based on business value it manages expectations
the business requirements document helps manage expectations early by providing a
clear understanding of the expected outcomes if business expectations around capabilities
are unrealistic the project team can redirect the business to more feasible expectations early on
now let's look at an example business requirements document to start you would include the name of
the project the version number and date I usually like to include the company logo
on the document that I'm creating then we have the revision history here you would include any
changes that are made to the document as they are reviewed you can use whatever numbering
convention that works best for the organization next is a basic table of contents so the first
section is the business requirements section here I've highlighted some key areas of the
problem statement which states that the admissions department is currently bombarded with calls and
appointments with students and potential students who need information and assistance currently the
department has been exceeding application slas by two weeks on average then we move on to our
business goals the goal of this project is to improve service and increase efficiency by
revising the department's website to enable self-service for all applications and forms
related to the admissions department so there are some key objectives that we'll need to achieve one
is that we want to reduce Department call volume by 50 percent within one month of implementation
as you can see here all of these objectives meet the smart criteria mentioned earlier in the lesson
now let's look at the success metrics so one of the metrics is the number of incoming scheduling
and financial aid calls per month now let's move on to the scope section here we discuss what's in
scope as well as out of scope then we have a table of the key stakeholders our business constraints
assumptions and dependencies one of the business constraints is that only forms that do not
require a wet signature can be submitted online an assumption will be that the website is available
24 7 outside of scheduled maintenance and one of the dependencies could be that the students will
need to create online accounts to submit the forms the next section is the business process overview
as you can see it includes the process map for both the as is and the 2B feature state
for details on creating a process map using bpmn see the link in the description the next
section is the stakeholder requirements the general format for stakeholder requirements
is to include an after an action and object and a qualifier if appropriate so the first stakeholder
requirement here states that students must be able to identify all functional areas within
the admissions Department from the home page again I'm not decomposing these into functional
requirements because those are reserved for more details documents like a functional requirements
document or a software specification document also in this example we can assume that this is
a waterfall project but if your organization is using agile or a hybrid model this section could
also be a list of high-level user stories instead next is our glossary of terms as you can see I've
defined SLA which is a service level agreement to respond within 48 hours this term was used in our
problem statement now we have the appendix where I included links to some relevant documents such as
the business case and the full versions of the process maps that were included in the BRD and
finally we have our approval and sign off section where we get our approvals and signatures from the
key decision makers once we get the sign off we have the green light for this to serve as an input
for our detailed requirements document well there you have it folks that's what you need to create
an effective business requirements document if you learned something new tell me about it below
and I'd love to hear your feedback also be sure to check out all the business analysis and ba
certification training and resources we have for you available at my website thebadoc.com thank
you so much for watching have a productive and prosperous day and I'll see you next time bye now