A BA is documenting a simple resident dog-license renewal and a multi-actor tow-hearing workflow. How should the tools be matched?
Select an answer to reveal the explanation.
Short Explanation
Renewing a dog license is a neat little story card; a tow hearing with many players and branches wants a use case. Match the tool to the shape of the work.
Full Explanation
Tool selection should match problem shape. A simple resident dog-license renewal is well served by a user story that captures a concise outcome, while a multi-actor tow-hearing workflow with alternate paths needs a use case that documents actors, main flow, and branches. Matching a user story to the renewal and a use case to the tow hearing respects both lightweight adaptive expression and structured analysis where complexity warrants it.
Using only one-line user stories for the multi-actor tow hearing and skipping alternate paths fails conceptually because complex branching will be omitted and later surprise builders and clerks. Using a full use case for the one-step dog-license renewal and avoiding user stories entirely fails because heavyweight modeling adds little value for a simple flow and slows delivery. Replacing both with an unprioritized brainstorm list fails because brainstorms neither specify actors and outcomes clearly nor order work for delivery.
Exam caveat: Associates should choose requirements tools by complexity and branching need, not by a single favorite format. Operational check: write the dog-license renewal as a story with acceptance criteria and model the tow hearing as a use case with alternate paths, then confirm both are linked into the backlog or RTM before build.