A BRD offers an overview of what a business does and why it needs the project deliverable to be undertaken. It outlines the business solutions for project requirements necessary for the project to deliver value and become the foundation of its life cycle.
The business requirements document highlights what the result of the project should be. When a change request is introduced to the project, the business requirements document must be revised to reflect this change.
Think of the business requirements document as the defined steps you should follow to reach a result that serves both the customers and stakeholders for the delivered product, system or service. The project team is involved in this process to help determine how to implement the delivery of the project and fulfill what the business needs. Stakeholders are also involved and must agree on the plan before it’s implemented.
A business requirement isn’t about offering or proposing a solution, only defining the task at hand. This includes defining the short and long-term goals, the company vision and the scope of the business problem. It reduces the chances that your project will fail due to misalignment with business requirements and connects the organization’s business goals with the project. It brings stakeholders and the team together and saves costs that accrue due to change requests, training, etc.
BRD contains:
————
1. Executive Summary
To begin, you’ll need to create an executive summary that provides an overview of the organization and the challenges facing the business. You’ll explain the issues and what the organization is trying to achieve to ensure everyone is on the same page.
2. Project Objectives
After summarizing the issue, you’ll want to clearly define the project’s objective. This helps define the project phases, creates a way to identify solutions for the requirements of the business and the customer, gains consensus from stakeholders and the project team and describes how you arrived at the objectives.
3. Project Scope
The project scope should define in detail what is covered in the project and what would make it run out of scope. This creates a clear boundary for the project and allows stakeholders and teams to agree on the business goals and high-level outcomes.
4. Business Requirements
Here you’ll want to list the business requirements or critical activities that must be completed to meet the organization’s objectives. These business requirements should meet both stakeholder and customer needs.
5. Key Stakeholders
Once you have the key stakeholders list, assign roles and responsibilities to each. These might be people outside of your department so you should define their role in the success of the project. This information must be distributed for everyone to know what’s expected of them in the project.
6. Project Constraints
Define the limitations of the project and share those with the project team so they know of any obstacles earlier than later. For them to clear those hurdles, you’ll want to provide any necessary training or allocate resources to help the project stay on track.
7. Cost-Benefit Analysis
You’ll also want to do a cost-benefit analysis to determine if the costs associated with the project are worth the benefits you’ll get. This requires first determining the associated costs of the project, such as upfront development costs, unexpected costs, future operating costs and tangible and intangible costs. You’ll also need to figure out what benefits derive from the project. This will always be a turnaround figure, as exact cost of involving each team varies, and will be provided by the involved teams (upstream / downstream teams) based on the tasks or characteristics required for the change or scope addressing in the BRD.
Tips to Write a Business Requirements Document
———————————————
- Start With Thorough Requirements Gathering
Requirements gathering is the process of identifying all requirements necessary for the project. That means everything from the start of the project to the end of the project. You’ll want to address the length of the project, who will be involved and what risks are possible.
- Be action-oriented: Don’t use complex jargon, rather use simple easy to understand language that encourages action.
- Engage stakeholders: Encourage all the other project stakeholders to get involved in activities such as brainstorming, surveys, focus groups, interviews, and ideas for prototyping.
- Do feasibility research: Research some of the past projects to determine the feasibility of your BRD. Evaluate your project to understand whether the solution desired can be developed within the constraints of time & cost.
- Include visuals: Include visuals and graphical representations, such as charts and diagrams, when necessary, as they can be powerful in making your point.
- Validate the contents: After writing the business requirements document, have it reviewed thoroughly before distribution. Obtain validation of the information and the contents–including the assumptions–and ensure that all errors or omissions are corrected.
Several teams and partners can create the BRD:
——————————————-
- Business Analysts
- Core team of the project
- Any or all business partner(s)
- Process owner(s) or representatives.
- Subject matter experts
- Change/project/product management, quality department and/or IT management.