How do you capture error scenarios in requirements?

Direct answer

What a strong answer covers

How it works

Every flow has more ways to fail than to succeed, and requirements that describe only success leave those failures to be invented under deadline. For each step, ask what happens with invalid or missing input, an unauthorised actor, a dependency that times out or returns an error, a request that arrives twice, two actors changing the same thing at once, and a process that stops halfway. For each, the requirement states what the user sees, whether the system retries or waits for a human, and what state the data is left in. Writing these as a table next to the main flow keeps them visible in review and testable later.

Example

For the invoice payment flow, the error table listed: card declined, show the reason and allow another card, invoice stays unpaid; payment provider timeout, mark the attempt as pending and reconcile through the provider’s status API within 15 minutes, do not show a failure; duplicate submission with the same idempotency key, return the first result; invoice already paid by another user, show that it was settled and by whom.

Common mistakes

• Documenting only validation errors and skipping timeouts and partial failures.
• Specifying an error message without the resulting system state.
• Leaving retry behaviour to the implementer and getting double charges.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.