FREE BUSINESS ANALYST REQUIREMENTS PRACTICE

Business Analyst Requirements Example: Make a Cancellation Rule Testable

A useful requirement connects a business need to behavior someone can check. In this original fictional exercise, Juniper Repair Workshop offers scheduled repair classes. Practise turning an unclear cancellation request into a scoped requirement, a user story and acceptance criteria.

This is self-guided Business Analyst (BA) practice. The scenario contains no customer records, completed user research or claim of professional assessment.

1. Separate a claim from the available evidence

A coordinator says, “People cancel too late, and we cannot fill their places.” Treat that as a stakeholder claim. It does not establish how often cancellations happen or whether a different rule would improve attendance.

The exercise supplies three invented requests below. They demonstrate timing and status cases; they are not a representative sample. All times use UTC. The proposed policy permits cancellation at least 24 elapsed hours before a class starts.

Ask the coordinator who approves the cutoff, whether exceptions are needed and how a released place is offered to someone else. Record unanswered questions instead of presenting the proposed policy as established fact.

2. Define the task and its boundaries

The task is to let a booking owner cancel an eligible confirmed booking. Include the eligibility decision, status change and release of one place. Exclude refunds, rescheduling, waiting-list invitations and exception approval from this requirement. Those may need separate decisions.

Before reading the revision, write your own response to this weak draft: “Customers should be able to cancel early enough.” Which words prevent a tester from knowing the expected result?

3. Write an explicit first attempt

User story: As a workshop participant, I want to cancel my eligible booking so that I can release a place I will not use.

Requirement R1: When the signed-in booking owner requests cancellation, allow it if the booking is confirmed and the class starts at least 24 elapsed hours after the server receives the request. On success, mark it canceled and release one place.

This is an authored proposal for the exercise. The story explains the purpose; R1 defines the decision. Neither replaces confirmation of the policy with its responsible owner.

4. Test the boundary and a negative case

• AC1 — exact cutoff: Given J01 and its booking owner, when the server receives the request at the stated time, then cancellation succeeds because exactly 24 hours remain.
• AC2 — late request: Given J02, when cancellation is requested, then it is refused, the booking remains confirmed and no place is released.
• AC3 — repeated request: Given J03 is already canceled, when its owner requests cancellation again, then the response confirms its existing status and releases no additional place.
• AC4 — wrong person: A request from someone who does not own the booking must not change its status or capacity.

These are proposed acceptance cases, not executed software tests. Trace the concern to R1 and each criterion. AC3 exposes a missing repeated-request rule, so add it explicitly before approving the requirement.

5. Explain what remains unresolved

Clarify how concurrent requests avoid releasing a place twice, how times are displayed locally and what happens if a class is canceled by its organizer. A correct cutoff calculation alone does not settle these questions.

Try changing the policy to “more than 24 hours.” J01 should now be refused. Identify every criterion and message affected before changing the wording.

Continue with the worked project guide, SQL counting exercise or free demo. Browse all Business Analyst resources. Sales remain closed.