For a photography studio, “reduce the time spent arranging bookings” is a business requirement. “Let a customer reserve an available hour” is a functional requirement. “When two customers request the last slot, only one receives a confirmed booking” is an acceptance criterion. Below, we turn that same project into a brief you can adapt.
The project: book one photography studio without a message thread
Imagine a studio owner who takes reservations through messages. Customers ask which hours are free; the owner checks a calendar, replies and manually records the booking. Two conversations can refer to the same hour. A cancellation means another manual update.
Our first version serves two people: the customer reserving a room and the owner managing availability. The example decisions below are a starting point for a requirements conversation, including the sample target and cancellation policy.
- One room, fixed one-hour slots, and times displayed in the studio’s named time zone. Customers must sign in to book or cancel their own reservation.
- The owner can publish or close unbooked future slots and see confirmed bookings. Closing an occupied slot is blocked; it does not cancel someone’s reservation.
- Customers can view future availability, reserve a slot, see their confirmation and cancel their own booking at least 24 hours before its start.
- No payments, refunds, recurring bookings, calendar sync or self-service rescheduling in version one. Late cancellation requests go to the owner outside this app.
Compare the three kinds of requirement on the same task
Keep each statement at the level where someone can make a decision. The owner approves the business outcome, the team agrees on the product behavior, and the owner and tester agree on examples that establish whether that behavior works. A single goal will usually need several functions and several checks.
| Type and question | Studio booking example | How you evaluate it |
|---|---|---|
| Business requirement: what must improve, and for whom? | BR-01: Reduce the owner’s hands-on work to confirm standard bookings. Sample target: median active handling time of no more than two minutes per confirmed booking in launch week four. | Compare a pre-launch time log with week four. Count the owner’s active work, not the customer’s waiting time. |
| Functional requirement: what must the system do? | FR-02: When a signed-in customer submits an available slot, confirm one reservation and show its reference, date, time and studio time zone. | Review the behavior and its exceptions before building. It must specify what happens when the slot has just been taken. |
| Acceptance criterion: what exact example must pass? | AC-02: Given two customers see the same available slot, when both request it concurrently, then exactly one is confirmed; the other sees that it is unavailable and can choose again. | Run the scenario with two separate customer sessions. Check both results and the owner’s booking list. |
1. Write the business requirement before choosing screens
“Build a booking dashboard” does not tell you what success looks like. The owner might still spend every afternoon resolving messages after that dashboard ships. Write the operational problem and the intended improvement first, then decide which screens earn their place.
Use this filled example as the business part of your brief: BR-01 — Studio owner. Problem: standard bookings require repeated availability and confirmation messages. Desired outcome: customers complete standard reservations without manual confirmation. Sample success target: median owner handling time at or below two minutes per confirmed booking in launch week four. Owner: studio manager.
Measure it consistently: during the two weeks before launch and during week four, record active owner minutes for every confirmed standard one-hour booking, including bookings that still arrive through messages. Divide neither by visitors nor by all inquiries: compare the median minutes per confirmed booking in each window and show the booking counts. Record exceptions separately, so an easier mix of bookings does not masquerade as improvement.
BR-02 adds a second need: the owner must be able to honor every confirmed reservation for the one room, without promising the same slot to different customers. Review the owner’s booking list and any conflict complaints weekly. Zero conflicting confirmations is the sample operational success condition; the concurrent-booking acceptance test checks one way the product must protect it.
- Keep the baseline as “to be measured” until the owner has collected it. The two-minute figure is a proposed target to agree on, not a result.
- Dependency: the owner must publish all bookable hours and direct standard requests to the booking page. An unused app cannot reduce message handling.
- Scope decision: payments are deferred because this version tests whether reservation and confirmation can work without owner intervention.
2. Turn those outcomes into functional requirements
For each function, name the actor, the trigger, the result and what happens when the request cannot succeed. A user story such as “As a customer, I want to book a room” is a useful starting sentence, but it leaves the behavior below undecided.
POL-01 is the agreed business rule for this example: customer cancellation is allowed when the server receives the request at least 24 hours before the booking starts, including exactly 24 hours. The owner chooses this policy; the functions enforce it. Display dates in the studio’s time zone, and calculate the cutoff as 24 elapsed hours before the start instant.
| ID and business link | Trigger and required behavior | Exception or limit |
|---|---|---|
| FR-01 → BR-01, BR-02 | The signed-in owner publishes or closes future unbooked slots. Customers viewing a date see only future published slots without a confirmed booking, labeled with the studio time zone. | The owner cannot close an occupied slot. Viewing a free slot does not hold it for the customer. |
| FR-02 → BR-01, BR-02 | A signed-in customer submits a slot. If it remains bookable, create one confirmed booking and show a reference, date, time, time zone and status in My bookings. The owner sees it in the booking list. | If it has been taken or closed, create no booking for that request. Explain that it is unavailable and offer another slot. A repeat of the same submission must not create an extra reservation. |
| FR-03 → BR-01, BR-02, POL-01 | A signed-in customer cancels their own confirmed booking within POL-01. Show Cancelled in My bookings, update the owner’s list and release the future slot for another customer. | Reject a late cancellation and leave the reservation confirmed. A different customer cannot view private booking details or cancel it. Repeating a successful cancellation leaves it cancelled. |
3. Write acceptance criteria with inputs and visible outcomes
“Booking works correctly” cannot settle an argument about a failed build. Set the starting state, perform one action and state what each affected person should see. Cucumber’s Given/When/Then structure is useful here: Given describes context, When the action, and Then an observable outcome. You can use these sentences as manual checks without installing a test framework.
Use a future published slot from 14:00 to 15:00 in the studio’s named time zone. Alice and Ben have separate customer accounts; the owner has a separate owner account. Reset the booking state between independent scenarios.
| Scenario | Given / When | Then |
|---|---|---|
| AC-01 — Successful booking (FR-02) | Given the slot is published and unbooked, when Alice submits it once. | Alice sees one confirmed booking with its reference, date, time and time zone in My bookings. The owner sees the same reservation. A fresh availability view no longer offers that slot. |
| AC-02 — Concurrent requests (FR-02) | Given Alice and Ben both loaded the slot while it was free, when their booking requests arrive concurrently. | Exactly one customer receives a confirmed reservation. The other is told the slot is unavailable and can select another. The owner sees only one confirmed reservation for the slot. |
| AC-03 — Repeat submission (FR-02) | Given Alice’s booking succeeded, when the same booking submission is retried after a slow response. | There is still only one reservation. My bookings lets Alice recover the existing confirmation rather than implying she needs to book again. |
| AC-04 — Owner closes a slot (FR-01, FR-02) | Given Ben loaded an unbooked slot, and the owner closes it before Ben submits, when Ben submits his stale selection. | Ben receives an unavailable message and no reservation. The closed slot stays unavailable to new visitors. |
| AC-05 — Other customer’s booking (FR-03) | Given Alice owns a confirmed booking, when Ben tries to view its private details or submit a cancellation for it. | Access is denied without exposing Alice’s details. Her reservation remains confirmed and the slot remains unavailable. |
| AC-06 — Owner closes an occupied slot (FR-01) | Given Alice owns a confirmed booking, when the owner tries to close that occupied slot. | The app rejects the closure and explains that an existing reservation occupies it. Alice’s confirmation and the owner’s booking entry are unchanged. |
4. Make the cancellation boundary impossible to misread
“Customers can cancel before the appointment” leaves a large product decision to whoever writes the code. For a booking starting at 14:00 on November 10, 2026, POL-01 puts the cutoff at 14:00 on November 9 in this example’s studio time zone, Asia/Singapore (UTC+08:00). The server’s request-receipt time decides eligibility, not when the customer opened the page.
These are acceptance examples for FR-03, using a confirmed booking owned by Alice. For AC-07 and AC-08, the owner’s list must show Cancelled and a fresh availability view must offer the slot again. For AC-09, both views must still reflect the confirmed reservation. AC-10 checks that retrying an old cancellation cannot affect a new booking.
| Scenario | Request received at studio time | Expected result |
|---|---|---|
| AC-07 — Before cutoff | November 9, 13:59:59 | Allow cancellation. |
| AC-08 — Exactly at cutoff | November 9, 14:00:00 | Allow cancellation: exactly 24 hours qualifies. |
| AC-09 — After cutoff | November 9, 14:00:01 | Reject cancellation. Show the cutoff and owner contact instructions; keep the booking confirmed. |
| AC-10 — Repeated cancellation | After AC-07 succeeded, Alice sends the cancellation again. | Keep the original booking cancelled. If Ben has since booked the released slot, his reservation must remain confirmed. |
What real community examples add to this brief
In Cal.com’s community issue #22801, a user reported duplicate reservations through recurring booking links and described both the observed and expected calendar states. That issue contributes a useful failure pattern: availability shown earlier is not a guarantee at submission. Our version excludes recurring bookings, but AC-02 and AC-03 adapt that concern to concurrent requests and retries; they are our example scenarios, not quotations from the report.
Issue #30258 requests a cancellation cutoff and gives a concrete 60-minute example. The author points out that restricting rescheduling alone can leave a cancellation-and-rebooking route open. The useful lesson is to ask which actions a policy actually governs. Our sample uses a different, explicitly chosen 24-hour cancellation rule and excludes self-service rescheduling.
In a Scrum.org forum discussion, a practitioner describes being asked for a business requirements document during user acceptance testing, after work had been organized as backlog items and acceptance criteria. Participants discuss where field definitions and rules should live. Apply that to this project before building: agree who approves POL-01 and keep its wording in one place, then link the functional requirements and boundary examples to it.
A template you can paste into your project brief
Copy the rows below into requirements.md or your shared document. Replace the brackets with one real problem, one supporting behavior and the examples needed to accept it. Keep unresolved business decisions visible; an AI assistant or developer should ask the owner rather than silently choosing a cancellation or payment policy.
| Record | Fill-in template |
|---|---|
| Business requirement | BR-[ID] | Owner: [decision-maker] | Affected person: [who] | Current problem: [what happens today] | Desired outcome: [what improves] | Baseline: [measurement or to be measured] | Target and date: [agreed result] | Measurement: [unit, population, time window] | Scope and dependencies: [limits and operational changes]. |
| Business rule | POL-[ID] | Decision: [allowed or forbidden behavior] | Boundary: [exact limit, inclusivity and time zone if relevant] | Approved by: [owner] | Open question: [anything not agreed]. |
| Functional requirement | FR-[ID] supports BR-[ID] | Actor: [who] | Trigger: [action] | Preconditions: [what must already be true] | Behavior and visible result: [what the system does] | Failure result: [what the person sees and what remains unchanged] | Applicable rule: POL-[ID]. |
| Acceptance criterion | AC-[ID] checks FR-[ID] | Given [specific starting state and sample data], when [one action occurs], then [visible result]. Include the normal case, a rejection, an exact boundary, a retry and competing requests wherever they affect this function. |
| Acceptance evidence | AC-[ID] | Version checked: [build or preview] | Expected: [result] | Actual: [observed result] | Evidence: [recording, screenshot or test output] | Status: [pass/fail] | Reviewer: [name]. |
Use the brief to decide what to build next
For this project, the first build needs an availability page, a booking confirmation and My bookings view, and an owner view for slots and reservations. A revenue dashboard and recurring-booking wizard have no job in this version because payments and recurring bookings are out of scope. That is a concrete scope decision the requirements should make possible.
Before handing the brief to a developer or AI, ask the owner to approve the outcome target, scope and POL-01. Then walk through the booking and cancellation tables together. If the owner changes the cutoff to 12 hours, change POL-01 and the cancellation examples before implementation so everyone is building and checking the same decision.
Passing AC-01 through AC-10 establishes the specified behavior for those cases. BR-01 still needs the week-four handling-time review. If the checks pass but the owner is still answering every booking message, inspect adoption and the remaining manual steps before adding more features.