A Business Requirement Document: The Secret Ingredient to Every Successful Project

A Business Requirement Document: The Secret Ingredient to Every Successful Project

A project may look straightforward enough at the very beginning. Until you start asking questions.

Maybe initially the client asks you to build a widget, and says that it needs to be green. Ok, you think, clear enough.

But then in the second and third rounds of discussions, you begin to see the bigger picture. You understand the client’s expectations around the quality, usability and scalability of the widget, plus all the regulations that go into creating it. You understand the client’s company, their brand and their mission.

A project manager who doesn’t take the time to unearth these expectations and discover what they don’t know is headed for failure.

“Asking questions” is the process of gathering requirements. The objective of requirements gathering is to align everyone’s expectations about the project’s objective. Without this continuity, the team easily works toward a deliverable that doesn’t meet the client’s expectations at all.

A formal compilation of all of these requirements into a business requirements document further solidifies everyone’s focus around the project’s goal. This post is going to define a business requirement document, describe how to create one, and explain what it needs to include in order for a project to succeed.

What Is a Business Requirement Document?

A Business requirements document (BRD) is a primary tool for listing and structuring requirements. It’s a document that’s created in a project’s planning stage and provides the purpose, background and scope of a project.

It’s a major deliverable in this planning stage and requires formal review by the client and acceptor. Usually, it’s created by a senior business analyst or the project manager.

Generally, a business requirements document is created in stages, using feedback loops. With each meeting and consultation, the current version is updated.

During a project’s execution stage, the BRD is used as a guideline for stakeholders to make decisions and to prioritize requirements and objectives.

How is a BRD different from a Functional Requirements Document (FRD)?

The BRD is intended for all stakeholders and the client, so it’s written in a language that is easy to understand by everybody.

The FRD is an internal document that’s passed around the team. Oftentimes it’s written in technical language that isn’t accessible to a wide audience. It’s more granular than the BRD and may include charts and workflows.

What Types of Requirements Are in a BRD?

Requirements capture all of the expectations in a project. They include tangible deliverables as well as non functional requirements. Capturing and documenting requirements at the get-go ensures that the team and the client are on the same page

The requirements in the BRD start from a high level, then work down to greater specificity.

High Level Requirements

According to the PM Glossary, high-level requirements “explain the major requirements and characteristics of the final product, including its purpose as a product and within the company.”

High level requirements, distinct from detail requirements, describe the central objective of the project. They are stated at the beginning of a business requirement document along with the project’s overall purpose.

Business Requirements

The business requirements state the business goals of the project, including the ROI, the objectives and the reason the project is initiated in the first place.
For example, a goal of adopting new software might be to reduce processing times by 50%. Or the goal of adding an online store to a retail store might be to increase sales by 20%.

Stakeholder Requirements

The stakeholders can include subject matter experts, customers, product managers and other business units. This section includes things like functionality requirements and quality standards.

Solution Requirements

The solutions requirements get down to the nitty gritty and include the expected features and behavior of the product. Business rules are taken into account with solution requirements, including constraints around regulations or the mission of the company.

Solution requirements are broken down into functional and non functional requirements.

Functional requirements (FRs) are clear deliverables the product must have. If the project is a web page, then some functional requirements may be that it include a bio page, a login page, and a shopping page. Functional requirements generally are visible and quantifiable. They must comply with business rules, and work around the project’s constraints.

Non-functional requirements (NFRs) are just as significant as functional requirements, but harder to grasp, define and quantify. “Usability” and “high-quality” are two examples of non functional requirements. NFRs sometimes relate to the behavior of the system, so also include things like privacy, security access and documentation.

Non functional requirements are approached differently than FRs, as they can’t be quantified as easily. For example, a non functional requirement of “usability” for a website would affect several facets of the project. Since they’re nebulous and indefinable and bleed into all parts of a project, it’s difficult to determine when a non functional requirement has been met. It’s not so simple as checking a box on a list and pronouncing it “done.”

In a sense, NFRs are treated more like constraints than requirements. They’re the boundaries under which a project is executed; the parameters it works within at all times.

Transition Requirements

Many projects entail a transition period. Let’s say the project is to install a new software system within the company. Learning to use the new software is a significant and sometimes challenging transition, and this stage has requirements all of its own.

These requirements describe features and processes that facilitate the transition. They may include things like cheat sheets, training courses, and data migration from the old system into the new system. Once a transition is complete, these requirements are no longer needed; they’re only necessary during the interim period.

As you can see, there are many types of requirements, originating from different places and serving a variety of purposes within the project. Let’s look into how these requirements are gathered.

How to Capture Requirements for the BRD

Requirements, unfortunately, aren’t prepared in a nice neat checklist at the beginning of a project and presented to the project manager.

Rather, it takes a lot of research and digging to unearth all of a project’s requirements. Sometimes they can’t even be discovered by asking direct questions. Requirements include implicit aspects of a project, things like the culture and the mission of the company, so teasing them out means reading between the lines, talking to the right people and understanding resource constraints.

Successfully gathering all pertinent requirements requires a strategy. The objective for the project manager is to understand the expectations of all stakeholders.

Here are a few methods and approaches for capturing a project’s varied requirements, so as to compile them into one neat document.

Business Process Model

The business process model looks at a business process from two different perspectives. First, it examines the current process, and then it examines the process in a future desired state.

Take a coffee shop for example, whose objective is to shorten the customer’s order time. This method studies the process for how a customer currently completes an order, then contrasts it with a possible future process. Maybe in the current process, the store has only one cash register. But in the future desired processes, it adds a second register.

Two requirements for this project, then, would be to purchase the new cash register and to create space for it within the shop.

This approach to analyzing systems and workflows makes it easy to highlight critical areas and identify the requirements for achieving objectives.

User Story Sessions

A user story is a simple, easy to understand description of a product feature, written from the perspective of the end user. For example, if the feature is a website login page, the user story would read something like, “The login page asks for my username and password.”

A user story session brings the client, the team and other stakeholders together, to capture an assortment of requirements. The requirements may be functional or non functional, and some may be business related as well. After gathering requirements, the next step is to prioritize them.

A MoSCoW Meeting of Stakeholders

At a MoSCoW meeting, the stakeholders identify everything a project must have, what it should have, what it could have, and what it won’t have.

A MoSCoW meeting is helpful in the planning stage to identify a project’s high-level requirements, its constraints, and everything in between. It’s about clarifying and crystallizing what the project really is all about.

The simplicity of the method allows the customer, the team, and any other stakeholders to make meaningful contributions toward the project’s requirements.

Although MoSCoW is a great way to plot out a project at the beginning, this isn’t a stopping point and it is best combined with other requirement gathering methods.

Product Manager Consultation

A product manager researches the customer, and so understands who the product targets and what problems it needs to solve. Soliciting feedback and data from the product manager helps to identify key features to include in the deliverable in order to meet the end users needs.

1:1 With the Client

When a project is too focused on deliverables and checking boxes, it’s easy to miss non functional requirements. A one-on-one with a client allows the project manager to get an idea of his or her priorities with respect to areas such as usability, scalability, security, compatibility and performance.

For example, if a client says that first and foremost she wants a website that’s “usable,” it’s necessary to dig a little further to grasp what that really means. It may mean that the pages must load quickly, or the checkout procedure must be simple and fluid. But without asking for clarity, it’s easy to make assumptions around a vague requirement like this.

This summarizes several ways to gather requirements. Each method provides its own benefits and weaknesses. Using a variety of methods together ensures that all necessary requirements are gathered.

How to Create a Business Requirement Document

A BRD is developed in rounds, after meetings and consultations with various stakeholders. Its completion indicates that everyone has a firm understanding of what the project entails. Here are a few things to include in a business requirements document.

• Requirements Gathering Process and Participants
  A BRD clarifies the project’s requirements gathering techniques. These methods vary depending on the nature of the project and the size of the team, but they generally always include gathering user stores and communicating with the product manager, the client and other stakeholders.
• Document Approvers
  The BRD clarifies the processes around requirements approval. It states who signs off to indicate the fulfillment of a requirement, and may also include a definition of done.
• Requirements
  A BRD, of course, also includes all of a project’s requirements, listed from the broadest to the most specific.

Business Requirements:

This section states the business goal is of the project, as well as how this goal is measured. It means defining the problem the project seeks to solve, or the opportunity it seeks to create.

Stakeholder Requirements:

These are the needs of key stakeholders, including business units, the product manager and investors. It lists the criteria these groups want the product to meet.

Functional and Non Functional Requirements:

Functional requirements define what the deliverable looks like or what features it has. This section doesn’t propose a solution, but rather it indicates all of the boxes that the final deliverable must check off. It may include diagrams for clarity.

Non functional requirements are performance or quality standards such as capacity, speed and availability. It may include things like training and documentation as well. As mentioned, non functional are sometimes difficult to quantify, and the BRD seeks to break down and clarify the NFRs as much as possible.

• Requirement Dependencies
  Requirement dependencies are those things outside of the project manager’s control that affect the requirement delivery. For example, it may list equipment or skilled labor that is only available with the completion of another project.

• Assumptions
  Assumptions go over anything that’s implied with the completion of a deliverable. It includes things like resource availability (labor, materials, and equipment).

  Assumptions create risk. It may turn out, for example, that the resources aren’t available in the amount it was assumed.

• Constraints
  Constraints are internal and external limitations that affect project performance. These include regulations, industry standards and limitations on resources.
• Approval and Sign Off From Key Stakeholders.
  When everyone has looked at the document, stakeholders sign off to indicate it’s complete.

And these are some components to a BRD. As you can see, it is a lengthy document when it’s all said and done. But bringing it to completion benefits a project in several ways, as we’ll see next.

How Does a Project Benefit From a BRD?

A requirements document captures all of a project’s essential components and places it in a position to succeed. Here are a few benefits of a thorough BRD.

• The Project is Completed on Schedule
  With a BRD, all the expectations are clear from the get-go. This focuses the production process, and sometimes even speeds things up!
• Re-Work Is Eliminated
  A work process that emphasizes ongoing communication with the client, and continual reference to the BRD keeps the project focused on its goal. The team is less likely to have to back up and repeat work.
• Client is Please With the Deliverable
  When everything is written out and all of the stakeholders are on the same page, it’s likely that the team will meet expectations and the client will be pleased with the final deliverable.

These are just a few of the many benefits a requirements document brings to a project.