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 everybody involved what is the driver of the whole initiative; for example, why the new system is needed and what business problem it is expected to solve. It also helps gain agreement with stakeholders and provides a foundation for communication with technical teams regarding the purpose of the solution they are asked to build. Besides the business goals, the essential part of BRD is the definition of the limitations, assumptions, and risks and how the success of meeting the business need will be measured.

BRD can have many forms depending on the environment, from a couple of slides to a formal document. But no matter the environment, each strategic or tactical need should be described upfront, including the problem the business is facing, the current state description, constraints, assumptions, dependencies and risks, and how the organization should look and behave in the future to satisfy the need. BRD describes how the organization needs to change as a whole, not how the particular component, such as an information system must change.

Besides the needs of strategic or tactical importance, each organization must also solve its day-to-day problems - the operational needs. For example, if the user requires to swap two data fields on the screen because this order reflects better how the 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 just a brief description of the change is sufficient. However, if the small change is a part of a bigger strategic change, it should be possible to trace the change request to the main project, so that it is clear in the future that the two data fields were swapped as a part of a bigger activity.

OPERATIONAL NEEDS

In this chapter, we described that besides strategic or tactical needs whose solutions require significant changes to the whole organization, there are also operational needs which solve operational, day-to-day problems. Solutions to the operational needs are usually just small modifications that do not require comprehensive business analysis and often include just a description of what must be changed in the target process or system. What causes confusion among analysts, though, is that in many organizations, the BRD is often considered the only document. It is then used to describe all types of needs, regardless of their nature. However, most of the tasks analysts are assigned to are operational needs which are more frequent than strategic needs as strategic needs are long-term and do not occur on daily basis. All specifications are then called BRDs, include a mix of high-level business goals and solution designs, and the whole idea of separating the goals from their solutions is ruined.

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

Content of BRD

The following section shows the typical information included in BRD. It should not be considered a template, but rather a list of aspects which are usually important to know to describe the initiative. Only the parts relevant to the given situation should be used and organized in the structure which suits best the needs.

1. Introduction

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

2. Business Requirements

The aim of this section is to describe what business problem the organization is facing. It states what changes the organization shall perform to solve the problem and under which conditions. It should also provide a short history of the initiative, why the changes are needed along with the current state of things.

2.1 Background and Business Needs

Describe the problem or opportunity. If it is relevant, describe how the need has been evolving during the time, and optionally include any other information which will provide the context of the need.

2.2. Context and Current State

At the high-level, articulate 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, the description includes what tasks people perform, in which systems the individual tasks are performed, what processes the tasks are part of, how the organization is structured, what are the company policies and business rules, what assets the company holds, etc.

2.3 Business Goals and Objectives

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

2.4 Success Criteria

To objectively assess whether the objectives have been achieved, expected outcomes must be defined along with the metrics of the success. The metrics could be either specific, expressed with money or time, or the results might be just loosely defined, yet it must still be clear when the outcomes will be considered successful or not.

2.5 Constraints and Restrictions

This section lists the constraints and restrictions which could impact decisions regarding how the business goals will be implemented. Constraints and restrictions are aspects that may not be changed by the solution and which shape somehow 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 of scenarios describing what might happen when something does not go according to the plan regarding the implementation of the business goals. State how probable it is to happen and what action will be taken to mitigate or avoid the risk.

3 Business Context

Include any information considered to be important to understand the content of the BRD. The extent and level of detail depend on the audience. But keep it as relevant to the content of the BRD as possible without specifying too many details. Too detailed information will cause frequent rework throughout the lifecycle of the document.

3.1 Stakeholder Profiles

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

Antipatterns

Here we are going to present antipatterns to avoid when analyzing business needs.

Antipattern: BRD Containing Solution Description

BRD defines business requirements which do not include solution - that must be yet found. It is a common practice in many organizations to use BRD as an overall container for holding business goals, solution description and the functional specification together. In most cases, the reason for this is that the business needs often come from stakeholders along with presumed solutions. Business analysts are then very likely to fail to recognize what is the actual problem the business is facing and what is the proposed solution.

Antipattern: BRD as a Temporary Artifact

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