Learn how to effectively define business requirements in your business or line of work using this free Business Requirements Template.

1. August 17, 2020
Business Requirements: How to Create a Business
Requirements Document (Free Template)
process.st/business-requirements
Jane Courtnell
August 17, 2020
Business, Management, Project Management
Tom: “I need a new warm, down jacket for my next trip.”
Me: “Great, I would opt for Patagonia or Arcteryx.”
Why did I recommend these brands to Tom and these brands only ?
It is due to brand trust. I know these brands deliver exactly what I want consistently.
As consumers, Tom and I are Patagonia and Arcteryx stakeholders. We have
expectations these two outdoor brands need to satisfy to retain our custom. These
expectations translate into requirements. In this scenario, our requirements were:
Value for money
Robust, long-lasting products
Functional products
Products that deliver on their intention
1/17

2. Patagonia and Arcteryx meet the business requirements for their products, satisfying
stakeholder and business needs. And so the brands thrive with a good reputation, brand
identity, leading to a healthy bottom-line and company success.
Defining the business requirements of a new product, project, system, service, or
software is vital. Without defined requirements, there is an absence of clear goals, focus,
and progression measures. This doesn’t bode well for success.
For instance, a study by Pulse of the Profession reported 37% of software projects failed
due to poorly defined requirements.
Because we don’t want you to fail, in this Process Street article we explain exactly what
business requirements are and how you can identify them for your business or line of
work. We explain the benefits that come from correctly defining business requirements.
We then clarify how you can document business requirements in a Business
Requirements Document using Process Street’s Business Requirements Template.
Sounds like the article you need to read to succeed…right?
As such, let’s jump to it. Click on the relevant subheaders below to hop-across to that
section. Alternatively, scroll down to read all we have to say:
Correctly defining the business requirements for your organization or line of work starts
here. Keep reading and learn how to consistently meet the needs of your stakeholders.
Ready?
Business Requirements Template
To kick off this article, I present you with Process Street’s free Business Requirements
Template. Use this template to identify key stakeholder needs that must be met in your
new project, product, service, system, or software.
By using this template, you will:
Gain stakeholder agreement for the new product/service or project,
Communicate needed solutions that satisfy customer and business needs,
Provide the required input to introduce the changes necessary,
Describe what and how the customer/business needs will be met by your
introduced changes.
Click here to access our Business Requirements Template!
Don’t have a Process Street account? No worries! Sign up for a free trial today to get
access to hundreds of premade templates like this one.
What are business requirements, and why you should care
2/17

3. Business requirements are critical activities an organization must perform to meet
stakeholder needs and organizational objectives. Business requirements are set and
documented in a Business Requirements Document (BRD).
When setting business requirements – also termed as Stakeholder Requirement
Specifications (StRS) – a business process, system, software, product, or service is
analyzed with the end-user as a priority. A solution to meet the needs of the end-
users/stakeholders is detailed as a business requirement within the BRD. The BRD can
be referenced at any point.
From the below image, you can see a skeleton structure of a BRD.
3/17

4. Understanding what business requirements are by grasping what
business requirements aren’t
Take a minute to think about the following for a moment:
1. An objective or expected benefit from a product/service/software/process, or
system,
2. A description of a product/service/software/process, or system,
❓ Question: Which one of the above details a business requirement? ❓
What’s your answer? – Use the comments section at the end of this article to note
down your thoughts as I would love to hear from you.
If you have taken the time to note down your response, I thank you ​♀️. But, I also
want to apologize as I have been a bit of a trickster.
You see, both of the above demonstrate exactly what a business requirement is not.
Why?
The above are objectives or expected benefits of a product/service/software/process, or
system. Business requirements are not objectives or expectations in themselves, rather
they meet objectives and expectations when satisfied.
It is important to understand this separation, to accurately define what business
requirements are so you can correctly identify the business requirements in your
organization or line of work.
For instance, consider the following. I have split the example up in terms of objectives,
expectations, and business requirements to highlight the differences.
Objective: Improve employee efficiency
Expectations: To increase output, providing stakeholders with a quick,
responsive service
Business requirement: Track employee time in the office
From the above, can distinguish between the objectives, expectations, and
requirements?
This information can be added to your BRD, as indicated in the image below.
4/17

5. Through rightful depiction and subsequent identification, business requirements will:
Reduce project failure rate: Misaligned or misinterpreted requirements can
lead to project failure as stakeholder expectations are not met. Defining the
business requirements creates a strong foundation from which a structured
process or method is created to meet stakeholder needs.
Contribute to the development of the business case: Well-defined
business requirements help describe a project in its entirety. This is critical for the
execution of a business strategy, and to meet specific goals. Projects will remain
on track, reducing failure rate, and providing positive traction with key project
stakeholders.
5/17

6. Saves costs: The establishment of business requirements early on not only
improves a project’s success rate, but also reduces costs in the long run. Think
about it, by keeping a project on track, change requests and the costs associated
are reduced. In addition, value is obtained from accurately delivering on the
stakeholder need.
Creates a user focus: An effective BRD uses integration and impact analysis
within all departments, prioritizing stakeholder needs. The aim is to balance the
end user’s expectations with what is feasible to deliver.
Business requirements vs functional requirements
As we have established, business requirements are key components for any business
project. They ensure the end project results meet stakeholder needs.
As you can see from the example BRD presented above ⬆ – see 3.1 Functional
Requirements – ⬆ business requirements come as a pair along with functional
requirements – some more jargon to add to your vocabulary.
Functional requirements are a detailed breakdown explaining how a project outcome
will operate to meet the business requirements specified.
It’s getting a bit confusing, isn’t it?
To explain further, let’s run through an example.
As a content writer at Process Street, I work remotely along with other members of
Process Street’s content creation team. Our team works hard to satisfy the business
requirements set for our department.
Our objective: To produce quality content regularly, consistently meeting the
needs of our readers, and to get our posts ranking on Google’s front page
Business requirement: Implement a system that reduces errors and increases
the efficiency of written content production
Functional requirements: To address how many employees the system must
accommodate; to fix common writing errors and identify the steps each writer
must take to meet content quality needs
6/17

7. As you can see, business and functional requirements are integral to a project.
Business and functional requirements have a shared goal, however, functional
requirements are far more specific. With continuous review, comparing the functional
requirements to business requirements, your project will stay on track.
Talking more about functional requirements is beyond the scope of this article. It is
necessary to understand what functional requirements are though. For more
information about functional requirements, read:
Functional Requirement
Functional and Nonfunctional Requirements: Specification and Types
7/17

8. How to create a Business Requirements Document
A Business Requirements Document (BRD) details the project of focus. As we have
already discussed, business requirements are highlighted in the BRD to clearly define
what the organization hopes to achieve.
Let’s say you introduce a new project, product, service, software, or system. Or you want
to increase capacity, retrench or reduce the capacity for other ventures. Or you change
your focus. Regardless, these changes demand new business requirements to be set.
With so much going on, sometimes it can be hard to handle these changes, which is why
a BRD is needed.
The hard part of creating a BRD is gathering the right information. Luckily for you, you
have free access to Process Steet’s Business Requirements Template. This template
details every step needed to create an effective BRD, meaning you can stringently assess
stakeholder’s needs to set your requirements appropriately.
Creating a BRD using Process Street, step #1: Identify stakeholder
needs
Once you have gathered your team, determine how you will identify your stakeholder
needs. Will you run focus groups? Hand-out surveys? Create a product prototype?
Our Business Requirements Template will detail best practices for each method used to
identify the needs of your stakeholders (see image below).
8/17

9. Best practices are detailed for each method used to identify stakeholder’s needs. In this case, a
stepped-process is given to successfully run focus groups for stakeholder’s need identification.
Creating a BRD using Process Street, step #2: Define organizational
objectives, expectations, and requirements
You can use the identified stakeholder needs to define organizational objectives and
expectations. Use your objectives and expectations to define your business
requirements.
Creating a BRD using Process Street, step #3: Determine work activities
that correspond to a particular requirement
Once you have identified your business requirements, determine work activities that
correspond to a particular requirement.
For instance, peer reviews, following an Editing Checklist, and team-wide reviews are
9/17

10. work activities used to reduce error in Process Street’s content creation process.
Also following processes such as our Pre-publish Checklist maximizes content creation
efficiency.
Creating a BRD using Process Street, step #4: Detail accountability,
priority, metrics and acceptance criteria
Next, detail who is accountable for which requirement. List requirements in order of
priority before deciphering metrics and acceptance criteria.
To exemplify the latter, at Process Street we follow a BAMM review system, assessing
the quality of produced content. A percentage score is given from following this system
to determine how good a piece of content is, detailing the needed amendments for the
content to be of the quality required.
10/17

11. At this point, the information you have so far obtained is summarized in the task titled
business requirements report notes, exemplified below. Once these notes are approved
by the relevant personnel, simply transcribe the information into an official BRD report.
Creating a BRD using Process Street, step #5: Create a business
requirements checklist
With a BRD clarity is provided, focus is retained and ambiguity is removed.
But your work doesn’t stop here. You need to devise a methodology to track and report
the status of each requirement – remember, meeting your business requirements is an
ongoing process.
As process masters, we at Process Street recommend you create a project requirements
checklist. Using this checklist will ensure all requirements are completed before the
formal implementation of a new product/project/service/software or system.
For more information on how you can create and edit checklists in Process Street,
watch the below video: Basics of Creating and Editing Templates.
Creating a BRD using Process Street, step #6: Effectively manage
change in your organization
As you introduce a new product/process/system/service or software, you are installing
change into your organization.
To successfully satisfy your set business requirements, your team needs to be open to
the relevant proposed changes. For this, you need to adopt a change management
model that is proven effective.
To help you, Process Street’s content creation team has been working hard to provide
top free template resources, to help you plan for and manage change appropriately.
11/17

12. Keep reading for more information and access to these free change management
model checklists. These checklists are to be used in conjunction with our Business
Requirements Template, for you to effectively execute change to meet your newly
introduced business requirements.
Creating a BRD using Process Street, step #7: Continually manage your
business requirements
Implement systems that will continually report on your business requirements status,
and make sure the need for these systems is communicated within your team.
Establish processes for your team to report on issues or concerns. Requirements may
change or be altered in some way. It is important to acknowledge and accommodate
this.
Manage change appropriately via a change management model
As previously mentioned, introducing newly set requirements initiates organizational
change that needs to be managed correctly.
For successful management of change, check out Process Street’s change management
model checklists. Access to these checklists is provided below, along with the relevant
checklist details.
Lewin’s Change Management Model Process Checklist
In Lewin’s Change Management Model, change is split into three stages:
Stage 1: Unfreeze the status quo
Stage 2: Make changes
Stage 3: Refreeze to lock-in changes for a new status quo
Lewin’s model breaks change down into bitesize chunks, taking people, and processes
into account. The model works to release rigid processes to introduce change, which in
this case, will allow the satisfaction of set business requirements.
Click here to access Lewin’s Change Management Model Process Checklist!
Bridges Transition Model Process Checklist
Bridges Transition Model looks at change as a journey instead of an abrupt shift. Three
stages of this journey are detailed:
Stage 1 – Ending, losing and letting go
Stage 2 – The neutral zone
Stage 3 – The new beginning
12/17

13. Each stage is characterized by the feelings instigated within the employee during that
period. In essence, Bridges Transition Model provides emotional support to employees
as changes are introduced to meet your set business requirements.
Click here to access Bridges Transition Model Process Checklist!
ADKAR Model Change Management Process Checklist
The ADKAR Model takes a bottom-up approach for the application of change. Each
letter in the acronym stands for a goal to be reached:
A: Awareness of the need for change
D: Desire to participate and support the change
K: Knowledge on how to change
A: Ability to implement the required skills and behaviors for change
R: Reinforcement to sustain change
With these goals, the ADKAR Model successfully plans for change on both an individual
and organizational level. As a change management model, ADKAR is easy to learn,
creates a new lens for viewing change, drives action, and addresses how change
happens.
Click here to access the ADKAR Model Change Management Process Checklist!
McKinsey 7-S Model Process Checklist
The McKinsey 7-S Model identifies 7 elements of a company, detailing how one will
impact the other. These elements are split into 2 categories, hard and soft. Hard
elements are driven by management and are more tangible. Soft elements are driven by
culture and are less tangible.
Hard elements include:
Strategy
Structure
Systems
Soft elements include:
Shared values
Style
Staff
Skills
The model aims to align these 7-S elements so that they support each other and the
change objectives, which in this case, are to satisfy the introduced business
requirements.
13/17

14. Click here to access the McKinsey 7-S Model Process Checklist!
PDCA Cycle Change Management Model Process Checklist
The PDCA cycle looks at change as a continuous process for improvement.
There are four stages:
Stage 1: Plan
Stage 2: Do
Stage 3: Check
Stage 4: Act
These stages are iterative, that is, as a circle, each stage is completed again, and again,
and again…
Problems are identified, solutions are tested systematically, results are assessed and
new solutions are implemented when needed.
It is recommended to use the PDCA Cycle as you come to the end of our Business
Requirements Template, in the ongoing requirements management section.
Click here to access the PDCA Cycle Change Management Model Process Checklist!
Kotter’s Change Management Model Process Checklist
Kotter’s Change Management Model’s core focus is to create a sense of urgency for
change. The model states, with this urgency, momentum for change is obtained.
The model splits the application of change into 8 stages:
Stage 1 – Creating a sense of urgency
Stage 2 – Building a core coalition
Stage 3 – Forming a strategy vision
Stage 4 – Getting everyone on board
Stage 5 – Removing barriers and reducing friction
Stage 6 – Generating short-term wins
Stage 7 – Sustaining acceleration
Stage 8 – Setting the changes in stone
The first stages create drive within your team to implement the needed change. The
following stages focus on sustaining this drive, seeing the change through to the end.
Click here to access Kotter’s Change Management Model Process Checklist!
Kubler-Ross Change Curve Process Checklist
The Kubler-Ross Change Curve recognizes the emotional burden of change on
employees within a company. These emotions can place a stranglehold on productivity.
14/17

15. However, if acknowledged and managed correctly the negative emotional repercussions
of change can be minimized.
The Kubler-Ross Change Curve details five stages of grief during the change process:
Stage 1: Denial
Stage 2: Anger
Stage 3: Bargaining
Stage 4: Depression
Stage 5: Acceptance
With knowledge of these stages, the model suggests a way to manage, control, and
direct these emotions positively and progressively, leading the way for change to meet
your set business requirements.
Click here to access the Kubler-Ross Change Curve Process Checklist!
Nudge Theory Change Management Model Process Checklist
The Nudge Theory for change is more of a theory – hence the name – than a change
management model. The idea is that individuals are nudged into making the desired
decision by altering the environment in which the individual is making that decision.
This environment is the choice architecture.
You can use the Nudge Theory to introduce changes needed to meet your defined
business requirements.
Click here to access the Nudge Theory Change Management Model Process Checklist!
For more information on Nudge Theory and Choice Architecture, read: Choice
Architecture Explained: How To Remove Human Bias From Your Business Today!
Satir Change Management Model Process Checklist
Developed by Virginia Satir, the Satir Change Management Model explores five stages
of grief that employees are predicted to feel during organizational change.
These grief stages are:
Stage 1: Late status quo
Stage 2: Resistance
Stage 3: Chaos
Stage 4: Integration
Stage 5: New status quo
The stages are designed to track the impact of change on employee performance. In the
long run, meeting your newly defined business requirements will mean your business is
more aligned with the needs of your stakeholders. Therefore, despite the initial
15/17

16. emotional turbulence, by managing this appropriately, the benefits of the introduced
business requirements will be realized in the long-run.
Click here to access the Satir Change Management Model Process Checklist!
New to Process Street? A quick tour to help you get started
Process Street is superpowered checklists.
How are our checklists superpowered?
Well, as you shall witness via using our change management model checklists and our
Business Requirements Template, our checklists are jam-packed-full of first-class,
fabulous, functional features. These include (but are not limited to):
Stop tasks to ensure task order.
Dynamic due dates, so no deadline is missed.
Conditional logic, creating a dynamic template that caters to your needs.
Role assignments, to ease task delegation within your team.
Approvals, allowing decision-makers to give the go-ahead (or rejection) on
important items. Also, the necessary comments can be provided.
Webhooks, so apps can send out automated messages or information directly to
other apps. A great feature keeping your other tools notified about the status of
checklists and tasks in Process Street.
Task assignments, to assign users and groups to individual tasks in your
checklists, making it easy to see who is responsible for what.
Embed Widget allowing you to view and interact with other apps without leaving
your checklist.
I bet you’re itching to get started! Sign up to Process Street, for free, today!
Start defining your business requirements today, and
consistently meet the needs of your stakeholders
Establishing business requirements early on is vital for the success of a new
product/project/service/software or system. Clearly defined business requirements
will:
Save you money,
Save you time,
Significantly reduce the probability of failure,
Contribute to the development of your business case,
Help you stay in sharp focus to deliver on your stakeholder needs.
What’s there to lose?
With Process Street’s Business Requirements Template, setting business requirements
16/17

17. has never been easier. Use our Business Requirements Template to create a BRD. Use
your BRD along with our change management model checklists for the successful
implementation of your new product/project/service/software or system.
17/17