Skip to main content
Version: 10.3.1

Business requirements document

Business Requirements Document (BRD) is a document to record the functional, quality, and usability requirements in formats easily consumable for future analysis, architectural and design activities, and, most importantly, in a format understandable by all business stakeholders.

Typically, BRD can have a general part and appendix or attachments. It is designed to take readers from a high-level understanding of Business Processes to detailed business requirements. Let's consider the structure of this document.

General​

A general part of BRD contains the following items:

  • Introduction and business need
  • Glossary
  • Business process background
  • Assumptions and constraints
  • Success metrics
  • Out-of-scope functionality

Let's consider items in detail.

Introduction​

In the beginning, BRD states a business objective for automation. The business objective should reveal a business problem and opportunity, which helps to create the focus for automation. The business objective should detail why this project is required and clearly state the strategic outcome of the project. It significantly impacts the selected approach for automation, target automation metrics, requirements prioritization, and so on.

Background​

The background section includes a description of the as-is business process, which provides a basis for the requirements and solution. That helps to understand the project's context, stakeholders' actual needs, process bottlenecks, and find the most optimal ways to improve this experience. The as-is process also serves as a reference point to measure success at the end of the project, especially when metrics are bound to an actual process, such as 20% manual handling time reduction, and so on.

Boundaries​

For better alignment with stakeholders on the project scope and boundaries, it is worth stating separate items that will not be included in the scope of implementation and hence are out of scope. That helps to keep to the limits defined by the project time and budget, and even if out-of-scope features are added to the project scope, handle them as change requests and add additional resources for that. Also, list any technical or business constraints and, thus, shape the scope. Major assumptions that impact the solution and cannot be verified at this stage should be listed and included in estimations following the worst-case scenario of this assumption fulfillment.

Metrics​

If there are no indicators to measure the progress and outcome of the project, it will not be easy to decide if the project is successful or not and prove it to project sponsors. Metrics should be bound to the business objective or the project and allow measuring the project's outcomes by a defined sequence of actions, in exact numbers, or achieve expected results.

Main part​

  • Solution overview
  • Functional requirements
  • Non-functional requirements
  • Business rules
  • Dependencies and risks

Solution​

The solution is a high-level description of the to-be processes, usually presented as a diagram that provides a valuable scope depiction. The description of the solution is intended to introduce project transformation on a high level and give an overview of the functionality to be detailed in particular functional and non-functional requirements below.

Requirements​

Functional requirements are usually captured as user stories or use cases and represent product features that describe what the product does. Functional requirements define what software does and how the system responds to inputs. Non-functional requirements are not related to the system functionality. They determine how the system should perform and are related to the system's performance, reliability, and usability.

Functional requirements form the system's backbone, while non-functional requirements set quality attributes of system performance. Specifically, the system will still work if the non-functional requirements are not met, but it will affect the user experience and overall project success. That's why it is essential to reveal all functional and non-functional requirements.

An optional section to include in a BRD is business rules. Sometimes, requirements can be complex and sophisticated and a section describing business rules can be helpful. Another optional section is listing any risks, issues, or dependencies for the implementation.

Appendices​

  • Document samples
  • List of fields
  • Dictionaries and mappings
  • And many more

Appendices are an optional part of BRD. Usually, they contain all other useful information not included in the requirements but applicable for the project, such as document samples with highlighted fields, UI mockups, dictionaries, and mappings if there are any, additional schemas to describe the solution, reference documents, and so on.