Systems Analyst interview question
How do you write a useful use case?
A useful use case names the actor, goal, trigger, preconditions, main success flow, alternate and error flows, postconditions, and business rules without prescribing unnecessary interface implementation details.
Direct answer
What a strong answer covers
How it works
A use case describes how an actor achieves a goal through the system, written as interactions rather than screens. It names the actor and goal, the trigger, the preconditions that must hold, the main success scenario as numbered steps alternating actor and system, the extensions where things diverge with their own steps and outcomes, the postconditions that are guaranteed on success, and the business rules referenced along the way. Its value is in the extensions: they force the conversation about what happens when payment fails or stock runs out, which is where most defects and disagreements live.
Example
Use case: Customer returns an item. Precondition: order delivered within 30 days. Main flow: customer selects the item and reason, system checks eligibility, generates a label, and records the return as pending; on receipt the warehouse marks it received and the system refunds. Extension 3a: item not eligible, system shows the policy reason and offers support contact. Extension 6a: item arrives damaged, warehouse flags it and the refund requires review.
Common mistakes
- Describing buttons and field layouts instead of the interaction and its rules.
- Writing only the happy path and leaving every failure for developers to guess.
- Omitting postconditions so nobody knows what state the system guarantees at the end.
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.
Open the desktop workspace and rehearse a clear answer in your own words.