FREE BUSINESS REQUIREMENTS DOCUMENT PRACTICE
Business Requirements Document Example: Scope a Studio Booking Service
A business requirements document (BRD) records the business problem, intended result, scope and decisions that people need to agree. This worked example takes one small booking problem through those sections. Use the outline to draft your own document, then compare your reasoning with the supplied cases.
Harbor Community Studio and every person, request and rule below are fictional. This is original self-guided practice, with no customer research, implemented service or professional assessment behind it. Document status: exercise draft v0.1; no stakeholder approval recorded.
1. State the problem without inventing evidence
The fictional coordinator says, “Our separate booking notes sometimes promise the same projector to two members.” That is the problem statement supplied for the exercise. It does not establish a measured error rate, the cost of a conflict or whether new software is the best response.
Proposed business objective: give members a dependable reservation decision for a shared projector while preventing conflicting commitments. Investigate the current booking process before selecting a solution. A shared manual register is an alternative worth comparing with an online service.
A possible operational measure is the number of asset-and-slot combinations with more than one confirmed reservation during a defined observation period. Agree the period, source records and denominator before reporting a rate. This guide provides no baseline or measured improvement.
2. Make the proposed scope small enough to decide
The draft covers active members booking one projector, Projector-A, for one offered 60-minute slot. In this exercise, slots start on the hour from 10:00 through 15:00 UTC and end by 16:00 UTC. Each reservation belongs to its signed-in member. All examples use 12 November 2026 and server receipt time.
- Included: check membership and an offered future slot, decide availability, store one successful reservation and show its outcome.
- Excluded: payments, refunds, cancellations, recurring bookings, proxy bookings, multiple projectors and staff overrides. A request to add one needs a scope decision.
- Assumptions needing confirmation: the membership list is current; every offered slot has capacity one; the studio can supply the listed projector.
- Dependencies: a reliable membership source, an offered-slot list, a server clock and an agreed operator for correcting bad source data.
Do not silently treat “future” as “at least a day ahead.” Draft v0.1 only requires the server to receive a request before the slot starts. A minimum notice period is a separate policy decision.
3. Identify the decisions each role owes
| Role | Decision or input | Current status |
|---|---|---|
| Studio coordinator | Approve eligibility, offered slots and the conflict rule. | Not approved |
| Member representative | Review whether the booking outcome and refusal explanation are understandable. | Feedback not collected |
| Membership operator | Confirm where active membership comes from and how corrections work. | Source not confirmed |
| Technical maintainer | Assess how concurrent requests and stored outcomes can meet the requirements. | Feasibility not assessed |
The BA can record a decision and its rationale; listing a role does not mean that person has agreed. Add the actual decision date, owner and unresolved objection when the review occurs.
4. Write the business requirements and their boundaries
| ID | Required business behavior | Reason |
|---|---|---|
| BR-01 | Accept a reservation only for an active signed-in member and an offered slot whose start is later than server receipt time. | Honor the proposed membership and booking-time policy. |
| BR-02 | Confirm at most one reservation for Projector-A in each slot, including when requests arrive concurrently. A refused request must not replace an existing confirmation. | Avoid conflicting commitments for the same resource. |
| BR-03 | Give the requesting member a clear confirmation or refusal reason. A successful reservation remains visible after reloading; an availability refusal reveals no other member's identity. | Let members understand and rely on their own booking outcome. |
These requirements describe business behavior. A screen design, endpoint contract or database constraint belongs in related functional or technical detail. Those artifacts must explain how they satisfy the requirement; choosing a tool does not prove the outcome.
5. Add acceptance cases that expose ambiguous wording
- AC-01, BR-01: An active member requesting an offered, empty future slot receives one confirmation with a reservation ID.
- AC-02, BR-01: An inactive member is refused, receives an eligibility explanation and creates no reservation.
- AC-03, BR-01: A request received exactly at or after slot start is refused; the request does not change slot occupancy.
- AC-04, BR-02 and BR-03: A second request for an occupied slot is refused; the first confirmation remains and the message reveals no other member's identity.
- AC-05, BR-02: Two concurrent valid requests for one empty slot produce exactly one confirmation and one availability refusal.
- AC-06, BR-03: After a successful request, the member reloads and sees the same reservation ID and slot in their own bookings.
For a declined request, “show an error” is insufficient. State which rule prevented the booking and which stored facts must remain unchanged. AC-05 also needs coordinated concurrency verification; two sequential clicks do not exercise simultaneous decisions.
6. Work the sample before opening the answer
Projector-A starts with no bookings. Process H01 before H02; H03 and H04 use other slots. The member is signed in as themselves in every row. All listed slots are offered. Predict the outcome and cite the acceptance case.
| Request | Membership | Server receipt | Slot |
|---|---|---|---|
| H01 | Active | 10:00 | 11:00–12:00 |
| H02 | Active, different member | 10:01 | 11:00–12:00 |
| H03 | Inactive | 10:02 | 12:00–13:00 |
| H04 | Active | 14:00 | 14:00–15:00 |
Compare the expected answers and identify the missing cases
- H01: confirm once, AC-01. The slot is offered, empty and in the future; the member is active.
- H02: refuse, AC-04. H01 already occupies the slot. Keep H01 unchanged and do not identify its member in the refusal.
- H03: refuse, AC-02. A future empty slot does not override inactive membership.
- H04: refuse, AC-03. Server receipt equals slot start; “later than” excludes equality.
Missing-case rationale: none of these four requests tests concurrent decisions under AC-05 or a reload under AC-06. H02 is sequential, so it cannot establish concurrency behavior. A confirmation shown once cannot establish that it was stored. An unoffered-slot case and a request after start would also strengthen the suite.
These are expected answers derived from the draft, not results from an implemented booking system.
7. Reuse this BRD outline and record the next decision
Document title, version and status:
Problem statement and available evidence:
Business objective and proposed measure:
Stakeholders, decision owners and pending decisions:
In scope / out of scope:
Business requirements: ID, statement, rationale, owner:
Business rules, assumptions and dependencies:
Acceptance cases and linked test IDs:
Risks, unanswered questions and proposed checks:
Decision log: date, approver, decision, rationale:
Change log: request, affected IDs, decision, version:Try adding a 30-minute minimum notice rule. Do not overwrite v0.1 and imply it was always agreed. Record a proposed change, identify BR-01 and its affected acceptance cases, obtain the responsible decision and retain the earlier version.
The companion requirements traceability matrix and UAT exercise works that change and the missing concurrency case. For a smaller first task, use the cancellation requirement example. Browse the resource collection or try the free demo. Sales remain closed.