A business requirements document (BRD) is a reflection of the main idea behind a project. It describes the goals and objectives of the project and the results it is designed to achieve.
No matter what field you are working in, you need a robust BRD to manage and align all the activities within the project. Without a principal guiding document, the workflow becomes disorganized, and it can quickly ruin your plans.
This blog will explain what a business requirement document is and give you a few tips for writing consistent and relevant BRDs.
Definition of Business Requirements Document (BRD)
A Business Requirements Document (BRD) is important for every business as it integrates the three aspects of any software project or business solution. It answers the three main questions that are sure to arise in the course of project implementation. They are:
- What? (what software to build),
- Why? (why to build it),
- How? (how to do it).
Putting it differently, a BRD contains the philosophy of the project. Speaking the language of science, it is about:
- the object of the business activity (what to build),
- the rationale behind the activity (why this project should be implemented or why a company needs to build new software, what problems the software will solve for users, and how much money it will bring to stakeholders),
- the method (the ways of implementation).
The document is a description of an upcoming project. In the field of engineering and construction, it can be compared to pre-FEED documents that are issued before the start of a large EPC project and contain an outline of its concept.
At the same time, a BRD is part of the overall documentation strategy of the company. It should not be limited to one project only. As a minimum, it should be linked to the documentation concerning previous similar projects. It should also be in line with the main company policies set out in other docs. These links will make the business activity of the company appear logical and consistent.
Key Components of a Business Requirements Document
Your BRD structure should not be rigid. Some elements, like functional requirements, for instance, are optional. The best practices for creating measurable BRDs include the following components:
- Business goals and objectives. This section includes information on the market situation, an analysis of the company's strengths and weaknesses, the proposed solution, the expected return on investment, and more.
- Scope of the project. This section mostly focuses on the project deliverables or results that stakeholders will obtain once the project is implemented. It describes the scope of work required to achieve these goals and often includes a schedule with milestones and deadlines to meet.
- Functional and non-functional requirements. This section is often regarded as optional. Some companies formulate functional requirements in a Product Requirements Document (PRD). It is written especially for the development team and contains instructions on how the product must be built, what functions it must feature, and how it must be designed.
The “how” information is called functional requirements, as it contains the description of how the product has to work (its functionality). Non-functional requirements are more general and concern overall business requirements or company strategy (such as whether the company plans to stay on the old market or switch to new products)
- Assumptions and dependencies. This section is more like a forecast. It attempts to predict what will happen, if the new software product is launched, if it is in demand, if the ROIs meet the expected values, and so on.
- Acceptance criteria. It is important that the acceptance criteria are formulated at the preliminary stage. Formulating criteria is part of strategic thinking. It is like putting a dartboard on the wall and checking how close the shots were to the bullseye.
- Constraints. These are the various limitations that can hinder or even make the implementation of the project impossible. They can include anything from budget limitations to competition activity or force majeure events.
- Risks and mitigation strategies. Risks can be related to the field of finance (company liquidity on the market), labor (availability of high-caliber employees required to build the software), PR (information coverage the product will get), and more. No matter what the risks are, you have to develop a mitigation plan for the most probable situations.
With this list in mind, you can proceed to create a comprehensive and effective business requirements document.
Creating a Business Requirements Document
The creation of a BRD typically includes several stages.
Gathering information is the first stage. Suppose your company wants to launch a new game design project based on AI art. You know that this issue is ‘tops’ and you want to be part of this trend. However, before starting you need to conduct extensive research on market trends and industry-specific issues such as AI art, neural networks, how they work, and how they can be used in game design. Only after completing the research phase can you formulate the main idea of your project. It has to be set out very clearly in the BRD. For example:
The idea is to build an online game design environment that integrates a text-to-image neural network with tools for image enhancement (finalization), for further use in game development.
Once you have completed this step, you can move on to the next stage of the process.
Analyzing and prioritizing requirements is crucial. The requirements can be derived from the main idea statement. based on the given idea, your project will require the integration of three elements into a single online platform:
- a text-to-image neural network,
- tools for image enhancement,
- tools to integrate general images into game development.
However, these points may seem complex to the readers of your BRD. Therefore, it is essential to explain them in simple language using examples and analogies. You may consider writing the following for clarification:
Our new online game design environment based on AI art will be like Google Translate for artists. The artist will formulate the idea (prompt) and get an image generated by the neural network. However, just like a translation from GT, an AI-generated image might not be perfect. It could have flaws such as incorrectly painted hands or fingers. These drawbacks have to be corrected. That is why our platform provides designers with the right tools to enhance and refine AI-generated images, so users don’t have to switch between multiple resources or waste time searching for tools.
Defining acceptance criteria is the next stage of BRD development. Acceptance criteria ensure requirement consistency in a business requirements document and help to check the efficiency of the work done. This check is typically performed using a set of metrics that evaluate the effectiveness of project implementation. For instance, metrics can identify the percentage of escaped defects (post-production defects found by users), defect density (1 defect per 1000 lines of code is considered “good” quality), deployment duration (i.e. the time it takes to make a release), among others.
Structuring the BRD is the next step that involves content creation, which means actually writing the entire document. In the past, this required a significant amount of work for technical writers, as BRDs could be quite large. Furthermore, finding related documents in company documentation silos to make references or reuse previously created content in the new BRD increased the writer’s workload. Often, writers had to start from scratch because it was impossible to find the necessary information.
ClickHelp is an online technical documentation tool that will help your tech writers avoid these issues. Firstly, ClickHelp allows a team of writers, not just one person, to work on a single document simultaneously. Working online, they can develop different sections of the BRD at the same time.
Next, ClickHelp is based on the principle of content reuse and single sourcing. This means that all the documents in your company's online portal are stored in a cloud and can be utilized for creating new documents. This eliminates the need for writers to create new content that is already available.
The review and approval process is the last stage in creating your BRD, and ClickHelp can provide great assistance in this regard by offering best practices for reviewing and approving a BRD. In ClickHelp, you can assign different roles to the users, allowing not only writers but also reviewers to work on new content. Reviewing can be conducted online and in parallel with the writing process.
Conclusion
You may argue that a project can commence without a Business Requirements Document (BRD). You may also argue that a combination of a Market Requirements Document (MRD) and a Product Requirements Document (PRD) suffice. These two documents outline the project from the perspective of the end-user and developer. But is this enough? Perhaps, if your company policy is solely altruistic. However, if you consider not only the users and developers but also other stakeholders such as yourself (the company owner) and shareholders, then you will require another document that details the project’s alignment with your business goals and objectives. A Business Requirements Document will elucidate how the project will address the company’s issues and what advantages it will provide them.
Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices