Replace a vague promise with a checkable result
| Requirement | Why it matters |
|---|---|
| The booking system works well | Too broad to determine a pass |
| When a room is already occupied, a second request for the same time is refused without changing the first booking | The input, action and retained state can be checked |
Separate ordinary use from exceptions. A valid booking and a conflicting booking should not share one expected result. Identify what the customer sees and which records should remain unchanged when the task fails. Keep the wording about behaviour rather than a particular button colour or internal implementation.
Try a missing-field case
An invoice has no currency. What must happen before import, and what must remain unchanged?
Show the worked answer
Require review of the missing value and leave the accounting record unchanged. After a verified correction, resume the same invoice identity and check that only one record is created.
An example becomes useful when another colleague can run it and agree whether it passed. Include enough starting data to reproduce the situation, but keep real customer information out of a public example. The downloadable workbook provides fields for that record.