You can’t achieve success if you don’t know what success is. This is why a well-written business requirements document is the foundation of any project.
In this article, we will explain what this document should contain, its typical structure, the differences between the types of requirements, and how to document business requirements like the pros.
What is a business requirements document?
A business requirements document (BRD) contains the objectives, assumptions, and expectations that the client and the vendor have before starting a project.
Its core function is to serve as a set of guidelines to keep the work on the right track, on time, and within budget.
Writing an effective BRD is in the interest of both parties: the vendor becomes confident about the conditions of work and payouts, and the client gets reassured that the project will bring in the results they’re expecting.
Note that BRD is intended for the project’s stakeholders who may or may not have the technical expertise to understand the nuances.
For the most part, it should be written in plain English.
Let’s use a couple of fictional personas to illustrate the real-world particulars of a BRD in action: Meet Alice the Analyst and Bob the Businessman.
Alice is a promising university graduate who just landed her first big job at ACME Consulting. Bob has a small but quickly expanding pizza chain.
They will be our guides through the requirements-gathering process.
Bob contracted ACME to develop a custom system that would help his company scale its delivery operations.
This new system should incorporate a client-facing mobile app for iOS and Android, as well as an admin panel for both the restaurant management and corporate teams.
Alice was assigned to his project and got to work.
Here is a list of what she might include in the business requirements document.
Executive summary
A brief overview of the project, its goals, and its limitations.
One of the issues faced by Bob’s Pizza Inc. is the low capacity for processing delivery orders due to the absence of a mobile app. Bob’s been in the pizza game for ten years, has successfully expanded his chain to rave reviews across two states, and now requires a tech solution to help him properly scale with the demand that has accompanied growth. The goal of this project is to incorporate an app that allows Bob’s Pizza Inc. to take and process more delivery orders, upping the volume of pizzas sold while providing more ordering options for all customers. Challenges will revolve around getting the app successfully built and deployed, and making sure Bob’s staff familiarizes themselves with all aspects of the tech capabilities that pertain to their respective duties.
Business objectives
What the project intends to accomplish for its stakeholders. The goals should be set according to the SMART model (specific, measurable, achievable, relevant, and time-bound).
Within 6 months of the project release, the number of delivery orders for Bob’s Pizza should increase by 23%.
Background
How the client conducts business at the moment and what is the business need that led to the project initiation.
Currently, Bob’s Pizza Inc. only accepts delivery orders by phone calls. The calls are taken by anyone on duty in a specific restaurant. With demand steadily increasing, two problems have arisen: a) employees that have to spend time on the phone writing down orders are employees that aren’t making pizzas, delivering pizzas, or managing staff making or delivering pizzas; and b) any customer that calls, is put on hold or gets a busy signal, is a less-happy customer than when they first thought about Bob’s delicious pizza. Ordering through an app is expected to solve both problems.
Project scope
What the vendor needs to do to achieve the objectives. This section also includes deliverables, acceptance criteria, assumptions, and constraints.
The scope of the project initiated by Bob’s Pizza Inc. should cover the following changes to business processes:
1. Accepting delivery orders by a software system
2. Tracking of order status through a client-facing mobile app
3. …
Functional requirements
Description of what the project must do. For example, “Sales reports must be generated every 24 hours.”
They are often supported by non-functional requirements — how the project does it, e.g. “Report must be generated within 1 second.” This is also the place to include the methodology of work (e.g. Agile, Waterfall, etc.).
The system must send a push notification whenever the order is ready.
Personnel requirements
In projects where technical support is required, spelling out the number of specialists and their hourly costs could be necessary.
Bob’s Pizza Inc. will require the following personnel to deliver the project:
1. A business analyst (X dollars/hr)
2. Two React Native developers (X dollars/hr)
3. …
Reporting and QA
Outlining the milestones, the parameters to which the project needs to perform, and how often should the contractor give progress updates to the stakeholders.
Bob’s Pizza Inc. requires that ACME provides bi-weekly progress reports via email.
Delivery schedule
The estimated dates for delivering specific features.
1. Admin panel – 03/04/202…
2. iOS app MVP – 06/07/202…
3.
Limitations
Physical, legal, geographical, and other things can affect the project’s resources and execution.
Law number 143.14 prevents Bob’s Pizza Inc. from accepting payment through ACME Pay.
Risks
All possible events or occurrences that could pose a threat to the project’s timeline, budget, and completion.
If Bob’s Pizza Inc. fails to onboard its restaurant managers with the admin panel, then the capacity for taking delivery orders will not increase to its full potential.
Glossary
A list of clearly-defined terms that might otherwise cause confusion if not explained.
The exact structure of your business requirements document will depend on the project at hand. Don’t hesitate to take a look at our free business requirements document template for more details.
Business Requirements Document Template (BRD)
Used 7991 times
4.4 rating (7 reviews)
BRD vs FSD vs SRS
Alice will need to write more than one document when working on the project for Bob’s Pizza.
This is so there is a clear distinction between why this is happening (the BRD we’ve been talking about so far), what requirements must be met to proceed (the software requirement specifications, or SRS), and how she and Bob get there with the projected software solution (the functional specifications document, or FSD). All three contain business requirements in some form.
Each has a specific purpose and target audience, and all three will be required for the project to run smoothly. Alice knows the difference.
A BRD is intended for managers, decision-makers, and stakeholders.
While it can contain some technical information, its main goal is to help non-technical people understand the process, the needs, and the scope.
So it is written in layperson terms.
A functional specification document (FSD) is intended for a technical team. It contains a detailed description of how each feature should perform.
This is the starting point for the developers to decide on the exact way of implementing the said feature.
3.1 Use Cases
| UC-1 | Registered user login – from cart |
| Primary actor | Registered user |
| Stakeholders and interest | N/A |
| Trigger | User proceeds to the checkout screen |
Software requirement specifications (SRS) refer to a detailed document with both functional and non-functional requirements, as well as use cases.
It is technical, extensive, and intended for the use of the developers.
2.4.1 Payment Time
[Bob’s Pizza-174] The application should process the credit/debit card payment within 5 seconds after the “complete order” button is pressed.
Who works on the BRD?
Initially, Alice thought she would do most of the work on the BRD for Bob’s Pizza app herself.
Before starting the project, Bob expected to hand over everything he had and wait until he received the finished app from Alice — both parties thinking that would be enough significant interaction to get the job done.
Shortly thereafter, however, Alice soon contacted Bob and asked him for an interview, realizing he was the best subject matter expert and the one who held the key to making the app outstanding.
The company is, after all, his “baby,” and who else would be better suited to provide a comprehensive overview of everything that plays into executing a superb finished product?
Alice realized early on that assembling just the “bare bones” tech requirements, while obviously necessary, will result in an app that has aspects not fully optimized if she didn’t get to know the story behind Bob’s Pizza Inc.
Not only was Bob the person who could clarify most requirements; he was also the one to add personalized, influential details — how he started as a delivery driver and worked his way through college, how his famous pizza uses a family sauce recipe that goes back generations, why he wants to leave a legacy for his children, etc. — which only sharpened Alice’s approach toward the task at hand.
With this foundational backstory about how and why Bob developed his successful business now in place, Alice was on firm footing to reach out to other participants, seeking their input.
These included:
- Stakeholders. Restaurant managers, accountants in the central office, and delivery driver supervisors all shared their needs, with each entity able to contribute to the BRD, since each could clearly define what their aspect of the operation would require to “level up” effectively.
- Subject matter experts. Bob was the main SME, as he founded the company and later initiated the project. He then reached out to his friend Monica, asking her to share the expertise she gained working for one of the major chains. This proved extremely helpful, as she had first-hand knowledge of what scaling efficiently in the take-out and delivery market looks like — and what to avoid when trying to do too much too quickly as a small business owner poised for significant growth.
- Technical team. The developers at ACME assessed risks, provided information on implementation, and shared their knowledge.
How to document business requirements
This is how Alice went about the documentation process.
Step 1. Preparation
Alice knew that before she could start writing she needed to prepare. This stage included:
- Studying the project. She read up on Bob’s pizza chain and even ordered a double pepperoni with a Coke. And she wasn’t disappointed — Bob’s team makes a delicious pizza. She has also read about the regulations for food businesses in Kansas and Missouri, states where the client currently operates. Once she participated in a meeting with Bob, she knew enough to lay the groundwork and understand some of the nuances of the upcoming project.
- Getting acquainted with the stakeholders. Alice talked to the personnel from Bob’s Pizza over Zoom. These people included Jim, the manager of a restaurant in Kansas City; Kate, the accountant in the company’s head office; and Fred, a supervisor of delivery drivers for another restaurant in MO. These meetings were just to get to know them, and in the subsequent months Alice spent more and more time picking their brains for details, learning who to contact regarding each aspect of the project
- Preparing for the long game. Being a realist, Alice knows that no ill-prepared plan survives contact with the enemy. Mentally, she was ready to make adjustments and changes as needed over the course of the project.
Step 2. Elicitation
This is Alice’s favorite part of the job.
According to the Business Analysis Body of Knowledge (BABOK), there are nine ways of determining the requirements:
- Brainstorming. A team effort where you play around with ideas and write down the useful ones. It provides a lot of information, which helps decide which direction to follow later on.
- Document analysis. Studying BRDs of competitors or past projects can help find the requirements you haven’t thought of. Other useful documents could include user guides, client’s process descriptions, laws, etc.
- Focus groups. As long as the group is representative of the target audience and can freely express their opinions, it is a solid method to get a lot of information quickly.
- Interface analysis. If there are a lot of components to a solution or it needs to be integrated with other systems, studying the potential interface points is useful.
- Interviews. While a lot depends on the skill of the interviewer, it is an invaluable tool to learn how stakeholders and future users think.
- Observation. See how the target audience works, pick up requirements from their behavior, record them. This works best in the initial stages.
- Prototyping. Developing a prototype is a way to let people try the product without actually building it. This helps a business analyst determine the potential requirements that could otherwise surface only after a release.
- Requirements workshops. A day or two together with the key stakeholders will let you probe them for most if not all the things they need. This gives some security against unexpected additions required in the future.
- Survey/questionnaire. Useful when you need to question many people and you already have an idea of where you should direct your efforts.
Alice looked everything over.
First, she decided to review ACME’s previous projects and found an app from last year that the company built for a similar fast-food chain in Arizona.
Many of the requirements were noticeably similar, so Alice wrote them down for reference while assembling the doc tailored specifically for Bob’s Pizza.
During the preparation phase, she noticed that Bob and his team were proactive in sharing knowledge.
So Alice invited them for a two-day requirements workshop where she collected a treasure trove of requirements, trimming them down as needed — she knew it is better to start small and expand later, rather than do the opposite.
The invitation to brainstorming sessions and workshops paid off handsomely: Alice now had a lot of useful information to work with, and firsthand knowledge of what needed to be on the BRD so that the new web and mobile app would continue elevating Bob’s business throughout Kansas, Missouri and beyond.
In short, Alice had done her homework, stayed agile and responsive to receiving input, and was now perfectly positioned to help Bob’s brand shine as he kept building out his pizza empire.
Using a specialized app, Alice quickly created clickable prototypes of a mobile app and an admin panel.
They weren’t very pretty at first, but that’s ok — they demonstrated precisely how the process should work.
Bob and other stakeholders checked them out and let Alice know what changes needed to be made.
Step 3. Writing
Once the preliminary work was done, Alice only had to set everything down in writing. She decided to use a BRD template from PandaDoc to save time.
It was free and had most of the boilerplate text already down, so she mostly had to formulate the requirements specific to the case of Bob’s Pizza.
Soon she had a 9-page document, illustrated with diagrams, graphs, and screenshots of prototypes.
It was written in plain English, as Bob and his team weren’t software development specialists.
They began reading and reviewing it, and soon accepted it without issues. The BRD illustrated their requirements well.
Alice also translated this information into developer-friendly language and made an SRS and an FSD.
Later, as the app was being built and delivered, Alice contacted Bob and his team a few more times for clarifications and made amendments to the document.
Once, after Bob’s Pizza filed a change request (they needed integration with their accounting software), she quickly added another section to the BRD.
Conclusion
Well-documented business requirements are an asset to both the project team and the client.
With this article, you now have a firm understanding of what you need to create such an asset.
And if you desire to ease the workload (what business owner doesn’t want that?), feel free to use the tools that PandaDoc provides.
Disclaimer
Parties other than PandaDoc may provide products, services, recommendations, or views on PandaDoc’s site (“Third Party Materials”). PandaDoc is not responsible for examining or evaluating such Third Party Materials and does not provide any warranties relating to the Third Party Materials. Links to such Third Party Materials are for your convenience and do not constitute an endorsement of such Third Party Materials.
