Turning an ambiguous business request into a defined process, testable requirements, business rules, acceptance criteria and UAT scenarios.
Business need
“We want customers to be able to cancel their reservation from the application and receive a refund automatically.”
It sounds clear until we try to define exactly when cancellation is allowed, how much is refunded, which state changes first and what happens when payment operations fail.
Discovery
Process analysis
Requirements
Allow an authenticated customer to request cancellation of an eligible reservation.
Evaluate cancellation eligibility according to the applicable cancellation policy.
Calculate the refundable amount before confirmation.
Display refund amount and cancellation conditions before confirmation.
Require explicit customer confirmation before executing cancellation.
Request refund through the original payment method when supported.
Transition reservation to CANCELLED only after cancellation is successfully registered.
Track refund state independently from reservation state.
Expose current cancellation and refund status to the customer.
Notify the customer when the cancellation request is registered.
Business rules
Self-service cancellation is available until 24 hours before service start.
Eligibility uses the local timezone of the booked service.
NON_REFUNDABLE reservations cannot be cancelled through self-service.
More than 72 hours before service: 100% of refundable base.
Between 24 and 72 hours: 50% of refundable base.
Less than 24 hours: self-service cancellation unavailable.
Promotional discounts are already reflected in the amount actually paid.
Service fees are non-refundable.
A cancellation request cannot be processed twice.
A refund failure must not create a second cancellation request.
Executable rule model
Paid €120 · Fee €10
FULL_REFUNDPaid €120 · Fee €10
PARTIAL_REFUNDPaid €120 · Fee €10
LESS_THAN_24HUser story
As a customer, I want to cancel an eligible reservation from the application, so that I can manage my booking without contacting customer support.
Acceptance criteria
Given a refundable reservation >72h before service, when cancellation is requested, then display a 100% refund of refundable base excluding service fees.
Given a reservation 24–72h before service, when cancellation is requested, then display a 50% refund of refundable base.
Given a reservation <24h before service, when cancellation is attempted, then self-service cancellation is unavailable and the policy is explained.
Given a NON_REFUNDABLE reservation, when cancellation options are shown, then the cancellation action is disabled.
Given an eligible reservation, when the refund request fails before completion, then no inconsistent reservation state is created and the user receives an explanatory message.
Given a cancellation already submitted, when the user submits again, then duplicate processing is prevented.
System states
Impact analysis
Traceability
| Requirement | Business Rule | Acceptance Criteria | UAT |
|---|---|---|---|
| FR-02 | BR-01, BR-02, BR-03, BR-06 | AC-01, AC-02, AC-03, AC-04 | UAT-01, UAT-02, UAT-03 |
| FR-03 | BR-04, BR-05, BR-08 | AC-01, AC-02 | UAT-01, UAT-02, UAT-04 |
| FR-06 | BR-10 | AC-05 | UAT-05 |
| FR-05 | BR-09 | AC-06 | UAT-06 |
UAT
Reservation cancelled · correct refundable amount · refund initiated · confirmation visible
50% refund calculated correctly
Cancellation unavailable · policy explained
Non-refundable fee excluded correctly
No inconsistent reservation state
Only one cancellation processed
Reservation CANCELLED · Refund PROCESSING · correct user status
Scenario: Full refund more than 72 hours before service Given a refundable reservation starts in 96 hours And the customer paid 120 EUR including a 10 EUR non-refundable service fee When the customer requests cancellation Then self-service cancellation is available And the refundable amount is 110 EUR
Risk-based validation
Analysis outcome
Cancellation windows, refund calculation and eligibility conditions were translated into explicit, testable rules.
The exact behaviour around the 24h and 72h thresholds was identified as a critical area requiring unambiguous definition.
Reservation and refund states were separated to prevent inconsistent combinations and unclear transitions.
The analysis connected cancellation behaviour with payment, refund, notification and reservation status.
Business need → requirements → rules → acceptance criteria → test scenarios → UAT.
Testing effort was prioritised around financial impact, boundary conditions, duplicate actions and state consistency.
Takeaway
Testing asks: “Does the system work?” Functional analysis also asks: “Have we defined the right behaviour in the first place?”