How to Write a Business Requirements Document

How to Write a Business Requirements Document

What Is a Business Requirements Document?

Most successful business projects start with a well-written business requirements document (BRD).

A BRD is a document agreed by the client and those responsible for delivering a project. The BRD outlines what the project is about, what success looks like and the steps that need to be taken to achieve a successful outcome, i.e., what the solution is.

Once the BRD is finalized, it serves to provide guidelines for those working on the project.

In most cases, the BRD is written by a business analyst in collaboration with the client and key project stakeholders.

A well-written BRD:

  • Keeps everyone on track and within the project's scope
  • Limits distractions
  • Aids decision-making
  • Helps to ensure a successful project outcome

What Should a BRD Include?

A BRD is a document that outlines a project, those involved and the steps needed to reach a successful outcome. It should stand on its own, remove any concerns or doubts and be used as a roadmap for the project's success.

It clearly sets out the scope of a project, including the main aims and objectives.

Within this, the BRD document must outline several variables that help keep those involved focused on the project:

  • Requirements of the client – This includes their expectations and needs
  • Project personnel – Stakeholders involved, teams, client and any anticipated specialist personnel
  • Timelines – Anticipated timelines for project completion
  • Project considerations – This includes any factors that those working on the project need to be mindful of, such as budget constraints or anticipated shortages with materials or resources that would adversely affect a successful outcome. You may also want to include a SWOT analysis in this section of the BRD.
  • Solution details – What the solution is or what the final product should achieve
  • Extent of the solution – An indication of what success looks like

These points can be summarized in the BRD's executive summary at the start of the BRD.

Depending on the type of project, some BRDs may include information on training needs and what future processes could look like once the project has been delivered.

How to Create a BRD

A well-documented BRD is an essential resource that helps keep a project on time, within scope and on budget. Those writing a BRD need to consider and consult a number of resources.

Here is a step-by-step guide to help write an effective BRD.

1. Collect Information

The first step in creating a well-thought-out and functional BRD is to collect the information you need to inform your project.

This includes:

  • Speaking to stakeholders to gain their views
  • Reviewing any information that applies to the project
  • Holding workshops and focus groups to gain perspectives and information
  • Confirming budgets and resources available
  • Ensuring that all information that could contribute to the project's success has been gathered and documented

2. Define Objectives, Needs and Project Requirements

Once you have all the data relevant to the project, in consultation with the client, you can define the objectives, needs and requirements.

This section is key to the overall success of your project, so ensure that you clearly define the project's objectives and have given due consideration to the project requirements.

Using jargon-free language ensures that your document can be understood by those who do not have a technical background. Using visuals to document timelines and organizational charts ensures an easy-to-read, valuable document.

3. Look Through Past Project Documentation

Reviewing past project documentation can help inform the content and format of your BRD.

Not only can checking past documents provide insight into whether the new project is feasible, but it can also indicate project limitations such as budget or factors you haven't considered.

Past project documentation can also act as a template for your new BRD, saving you the time and trouble of creating a new document.

4. Involve Team Members

Involving those on the project helps the process of constant information-gathering and makes the BRD more realistic and feasible.

Getting to know team members also starts the process of building an excellent working team relationship, as they will have contributed to the BRD and will feel part of the project from the outset.

5. Define Scope and Phases

Ensuring that you have a clearly defined and documented project scope helps stakeholders and team members understand what is inside or outside scope and keeps everyone on track.

Breaking down the project into phases also enables adequate budget and resource allocation. When defining each phase of the project, it is essential to include the work involved and achievements expected after each phase has been completed.

6. Identify Standards and Metrics

Establishing the standards expected for work output helps project collaborators understand the quality of work required and helps project stakeholders to trust those involved.

Including metrics in your BRD allows you to track project progress, keeps the project team on track and helps chart progress toward the deliverables of the project.

What to Remember When Making a Business Requirements Document

A clearly articulated BRD provides a template for all project collaborators to use, so that the project remains on track and within budget.

When drafting a BRD, there are several points you can consider to ensure the document is clear and user-friendly.

Gather the Necessary Requirements

Get to know your stakeholders for an accurate insight into the work needed to achieve project success.

Don't limit information-gathering to the pre-planning stage. Keep the dialogue going with stakeholders, and if any new, relevant information comes to light, ensure this is included as appropriate.

Research Past Projects

Reviewing previous similar projects can give you an idea of what to expect, a template you can use to inform your BRD and factors to consider for mitigation or inclusion.

Define One Requirement at a Time

The key to a good BRD is clearly articulated project requirements. Documenting one requirement at a time helps those involved in the project understand the project deliverables.

It also ensures that the BRD can be used as a standalone document that informs the project's scope and successful outcomes.

Use Action Verbs

Writing a concise BRD can be achieved by using action verbs. Using action verbs when articulating project requirements makes your words persuasive and encourages action.

This approach can also provide the reader with the assurance that, as the writer of the BRD, you are clear on what project is about, know what is required to achieve the project's objectives, and believe in the achievement of the project outcomes.

Avoid Jargon and Acronyms

A BRD needs to be straightforward to read. It is best to assume that some readers may not have a technical background.

Using easy-to-read and jargon-free language not only makes the BRD helpful for all, it also makes the document a standalone piece that can be read and understood by any stakeholder.

Include Visuals

When writing a BRD, consider all formats of documentation, including visuals. Using visual representations such as flow charts, diagrams or organization charts is a clear and powerful way of representing information.

Validate the Document

Before circulation to stakeholders, all BRDs should be reviewed. This checks that the information documented is accurate, free from errors and includes all essential project requirements.

How to Write a Business Requirements Document (With Templates)
How to Write a Business Requirements Document (With Templates)

Template BRD

A BRD should include:

Executive Summary

Include the project's purpose and outline the success measures. Try and keep the executive summary to no more than two pages (sides).

Project Introduction

Provide a brief outline to introduce the project so that readers know the background to the project.

Project Scope

Include a clear definition of what the project is about, what success looks like and the work needed to complete the project.

Project Objectives

Document clear objectives using the SMART (specific, measurable, achievable, realistic, time) framework.

This helps with the continual measurement and progress of the project and ensures it is set up for success.

Project Needs

The project needs statement documents the factors that must be considered and accounted for.

It also demonstrates to stakeholders that any potential issues that may affect the progress or success of the project have been reviewed and mitigated.

Project Requirements

This outlines all the resources and budgets required for the project.

It is advisable to use visuals in this section to represent project timelines, organizational charts or any flow charts that help depict information in an easy-to-read way.

Project Stakeholders

Document all those involved in achieving the project deliverables. This not only ensures due consideration to the resources required, but gives a sense of ownership to those involved.

Timelines and Project Schedule

Document each phase of the project, allocating the agreed timeline for completion. Using a flowchart or diagram can help monitor progress against timelines, reduce misinterpretation of deadlines and ensure each stakeholder knows what is required of them and when.

Budget

The project budget outlines the funds required for the completion of the project. If the funding is phased, ensure that this is documented alongside each project's phase so the dependency is explicit.

Project Limitations

Outline project limitations and any factors that may prevent the project's success. This allows stakeholders to research viable solutions to these limitations.

SWOT Analysis

If appropriate, include a brief summary of your findings from the SWOT analysis.

Frequently Asked Questions

A BRD is a written representation of a business project. The BRD outlines why a project is being undertaken, the factors that need to be considered, the people involved and the budget required to complete the work.

It is a document used by those working on the project and people interested in the project's outcome.

A well-written BRD brings many benefits to a project's stakeholders. These include keeping the project on track and on budget, and defining what project success looks like.

A BRD also details factors that could derail the project and enables those working on the project to be clear on what is included in the project and what isn't.

The BRD outlines the high-level project deliverables as a whole. Within a BRD, additional documentation often outlines how the project will be delivered.

This can include the following:

  • Functional requirements document (FRD) – Outlines the functions required to complete the project
  • Technical requirements document (TRD) – Outlines what is required technically to achieve project success
  • Software requirements specification (SRD) – Used specifically for software projects outlining the purpose of the software being developed.

Typically, a business analyst will create the BRD. It is worth remembering that a BRD isn't completed in isolation by one person.

All project stakeholders should be involved in preparing the BRD. Ensuring that the document clearly represents the work required is achieved by collaboration with those involved in the project.

When writing a business requirements document, ensure that the document remains relevant to the project and use jargon-free language.

Representing your information using appropriate formats such as diagrams, organizational charts and flowcharts means that any text-heavy information can be presented in an easier-to-read way.

When writing your BRD, keep in mind that you want the document to be read in its entirety. Using a BRD template or following previous project documentation formats will ensure that your BRD is appropriate in length to past documentation.

Final Thoughts

A BRD is an essential project document that sets out scope, objectives, requirements, timescales, stakeholders and more. It should be written in jargon-free language and be accessible as a standalone document, able to be understood by anyone who reads it.

Involving key stakeholders in preparing your BRD and carefully researching and preparing all the necessary information will ensure that your project gets off to a good start.


Read This Next

You might also be interested in these other WikiJob articles:

Or explore the Jobs & Careers / Employment sections.