A Business Requirements Document (BRD) is a formal document that effectively provides an agreement between a vendor and a user. The user is typically a business department and the vendor is the company or other business department that will create and deliver the new product, system or process.
Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent. The document describes in detail every business needs and expectations and is written in response to a known business problem or shortcoming. The BRD is not expected to describe in detail the solution to the business needs but to describe what the business wants and needs, i.e., the BRD should answer the question, “What does the business want to do?” and describes what the system would look like from a business perspective. For technical products, such as new or modified software systems, further technical specifications will be prepared.
The most common objectives of the BRD are:
• To gain agreement with stakeholders
• To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs
• To provide input into the next phase for this project
• To describe how the customer/business needs will be met by the solution
Various techniques, such as brainstorming, story boarding, use cases and interviews, will have been used to gather the requirements during a business requirements analysis process. That information needs to be written down in a clear, concise format in language familiar to the business users. The process of documenting and refining the business requirements helps to identify conflicting requirements and potential issues early on in the project lifecycle. It is the key document in the effective project management of any type of project.
The following should be involved in creation of the BRD:
- Business Partners / Product Management
- BAs / SMEs
- QA/Change Management
The BRD is aligned to review the project charter to ensure that the objective, goals and scope are intact.
The BRD should review the “as is” process maps with the following details:
- Clearly defined start and end points of the process
- Level two and three process functions
- Baseline for each Critical-To-Quality process for the current environment
The BRD shall consider the following issues from a holistic project perspective:
- Any regulatory or geographic constraints to be documented clearly
- Assumptions and Dependencies
- Business Rules
- Revenue Model
- Metrics / Reporting
The BRD effectively defines the Scope of a project. This is the description of what will be included in the project and also what is specifically excluded from the project.
Scope is a definition of the limits or boundaries of a project and the reason it is so important is because poor management of the project scope is one of the major causes of project failure. Good management of the project scope involves 3 key factors:
- devote adequate time to fully defining the requirements
- reach a formal agreement on the scope with the stakeholders
- avoid scope creep
Scope creep is when un-authorized or un-budgeted tasks lead to uncontrolled alterations to the documented requirements during the course of the project. The BRD should address the possibility of requests for additional tasks in a project and state how they will be dealt with. This usually involves a formal Change Request Procedure that requires the agreement of all stakeholders to any changes of specification, budget or delivery time. The fact that the BRD is a formally approved document assists the project manager in implementing and sticking to a Change Request Procedure.
There is, of course, a tendency for changes to be requested during the life of a project. As projects progress, the end-users inevitably see areas where additional features could provide increased benefits. And the purpose of scope management is not to prevent such changes either being requested or implemented, but to ensure that all changes bring substantial, well-defined benefits. And that the budget will be increased accordingly and that the extended duration of the project is acceptable to all parties involved. Failure on the part of the project manager to manage scope adequately undermines the viability of the whole project as approved in the BRD.
All changes to the requirements, budget and schedule must be approved by all stakeholders. In large projects it is common for end-users to see their opportunity to have all the “nice-to-have” elements added while major changes are underway – to some extent this is understandable but only if the new features add real business value such as efficiency or accountability and do not require the project to change in such a way as to lose sight of the original business needs that instigated the project in the first place
A BRD is likely to have several iterations before it is accepted and signed-off by all stakeholders. This is no reflection on the thoroughness of the analysis process but simple human difficulty in translating thoughts and speech into clear, unambiguous and thorough wording on the page. Whilst adequate detail is required to fully define the requirements. Conversely, too much detail prevents the readers from absorbing the key points. Writing such a balanced document can be a complex and intricate process and is a skill in itself.
Fortunately, there are a number of best practice approaches and industry standards that can be used to good effect when writing a BRD. These will assist in defining the project scope and managing scope creep once the project is underway.
Key Document Elements
The author of the business requirements should have an understanding of the different levels of requirements and the different elements within the requirements, and must be able to state the business needs clearly, understand the current business process and the key business objectives driving the project.
The following list covers the main areas to be documented in a BRD. Items from the below list are picked depending upon the the standards followed by the company. Details of all these elements are covered under project management, which is out-of-scope of this document.
|o Business Problem Statement
o Current Business Process
o Scope Statement(s)
o Key Business Objectives
o Project Completion Criteria
o Functional Requirements
o Non-Functional Requirements
|o Features and Functions
o Reporting Requirements
o Delivery Method
o New/Modified Business Process
o Data Retention/Archiving
o Stakeholder List
o Quality Measures
o Checklists (Process and Requirements)
Ensuring each of these elements is incorporated with sufficient detail and clarity is the first step to creating a perfect BRD. Techniques for writing effective business requirements are covered on both general project management and on specific business requirements.