Business Requirements Document

The aim of the Business Requirements Document (BRD) is to describe business goals and expectations in response to a known business problem or shortcoming. It states what the organization wants or needs to achieve while remaining solution-independent. The benefit of having such a document is that it makes clear to everyone involved what is driving the initiative—for example, why a new system is needed and what business problem it is expected to solve. It also helps secure agreement among stakeholders and provides a foundation for communicating with technical teams regarding the purpose of the solution they are being asked to build. Along with business goals, an essential part of the BRD is defining limitations, assumptions, and risks, as well as how success in meeting the business need will be measured.

A BRD can take many forms depending on the environment, ranging from a few slides to a formal text document. But regardless of the environment, any strategic or tactical need should be described upfront. This includes the problem the business is facing, the current state, constraints, assumptions, dependencies, risks, and how the organization should look and behave in the future to satisfy that need. The BRD describes how the organization needs to change as a whole, rather than how a specific component, such as an information system, must change.

In addition to needs of strategic or tactical importance, every organization must solve its day-to-day problems—operational needs. For example, if a user asks to swap two data fields on a screen because that order better reflects how their actual work is done, there is no strategic need associated with it, and the solution is straightforward. These operational requirements do not need a dedicated BRD. In the context of the target system, it is just a minor change, and a brief description is sufficient. However, if a small change is part of a larger strategic initiative, it should be traceable back to the main project, making it clear in the future that the two data fields were swapped as part of that larger effort.

OPERATIONAL NEEDS

Aside from strategic or tactical needs whose solutions require significant changes to the entire organization, there are also operational needs that address day-to-day problems. Solutions to operational needs are usually just small modifications that do not require a comprehensive business analysis and often include only a description of what must change in the target process or system. What causes confusion among analysts, though, is that in many organizations, the BRD is considered the only template available. It is then used to describe all types of needs, regardless of their nature. However, most tasks assigned to analysts are operational needs, which are more frequent than strategic ones, since strategic needs are long-term and do not occur daily. As a result, all specifications end up being called BRDs and include a mix of high-level business goals and solution designs, which ruins the whole concept of separating goals from their solutions.

So, if the BRD is not intended to describe operational needs, what type of document should be used? Operational needs are fundamentally the same as other needs, and finding the best way to solve them requires following the same procedure as for strategic and tactical ones. The analyst must understand "what" the problem is, how things work at the moment, and the gap between the current state and the future state. The only difference is that the drivers of operational needs are not senior managers; instead, operational issues are commonly raised by frontline employees. As a result, the structure of the BRD described in the following section is perfectly applicable to operational needs too—it just shouldn't claim to describe “business” requirements or “business” goals when it does not. Even behind swapping two buttons, there is a goal users want to achieve, so the basic structure can be reused.

Content of a BRD

The following section shows the typical information included in a BRD. It should not be considered a rigid template, but rather a checklist of aspects that are usually important for describing an initiative. Only the parts relevant to a given situation should be used and organized in the structure that best suits your needs.

1. Introduction

This section should state the purpose of the document, define how the audience can benefit from reading it, and explain the terms, abbreviations, and acronyms used throughout.

2. Business Requirements

The aim of this section is to describe the business problem the organization is facing. It states what changes the organization must perform to solve the problem and under what conditions. It should also provide a brief history of the initiative, explaining why changes are needed alongside the current state of affairs.

2.1 Background and Business Needs

Describe the problem or opportunity. If relevant, describe how the need has evolved over time, and optionally include any other information that provides helpful context.

2.2 Context and Current State

Articulate at a high level what the organization has now (business functions, processes, systems, etc.) and state why the current state needs improvement in relation to the described business need. Usually, this description includes what tasks people perform, which systems they use for individual tasks, what processes those tasks are part of, how the organization is structured, what company policies and business rules apply, and what assets the company holds.

2.3 Business Goals and Objectives

This section describes the primary business objectives and benefits to be achieved. At a strategic enterprise level, describe the ends the organization is seeking to reach. State the concrete changes the organization wants to accomplish.

2.4 Success Criteria

To objectively assess whether objectives have been achieved, expected outcomes must be defined along with success metrics. These metrics can be specific—expressed in terms of money or time—or outcomes can be more loosely defined, provided it is still clear what constitutes a success or a failure.

2.5 Constraints and Restrictions

This section lists the constraints and restrictions that could impact decisions on how business goals will be implemented. Constraints and restrictions are aspects that cannot be changed by the solution and which shape the environment of the change.

2.6 Assumptions

List any assumed factors (as opposed to known facts) that could affect the requirements stated in the BRD.

2.7 Business Risks

List scenarios describing what might happen if things do not go according to plan regarding the implementation of business goals. State how likely these scenarios are to occur and what actions will be taken to mitigate or avoid the risks.

3. Business Context

Include any information considered important for understanding the content of the BRD. The extent and level of detail depend on the audience, but keep it as relevant to the core content of the BRD as possible without specifying too many technical details. Overly detailed information will cause frequent rework throughout the lifecycle of the document.

3.1 Stakeholder Profiles

List the stakeholders, their roles, power, influence, and the relationships among them.

Antipatterns

Here we present common antipatterns to avoid when analyzing business needs.

Antipattern: BRD Containing a Solution Description

A BRD defines business requirements that do not include the solution—which is yet to be found. It is common practice in many organizations to use a BRD as an overall container for holding business goals, the solution description, and the functional specification all together. In most cases, this happens because business needs come from stakeholders alongside an assumed solution. Business analysts are then highly likely to fail to recognize what the actual problem is versus what the proposed solution is.

Antipattern: BRD as a Temporary Artifact

The BRD is not a temporary document for collecting random ideas. It is a final document describing information that has been analyzed and confirmed. Therefore, it should not include initial ideas, guesses, or speculations, apart from formal assumptions, which are a legitimate part of the BRD.