Thought: use “user story” with acceptance criteria is a best practice in scrum process, no one use “use case”.
User story
lightweight
a short description of something that can be written on a card,
focused on the value or result they get from doing this thing
Format: As an [actor] I want [action] so that [achievement]
A User Story doesn’t capture all the details, it’s an informal support for the discussion.
Acceptance criteria
Writing the acceptance criteria is the first step of fleshing out the details of your user story.
define the boundaries of a user story, and are used to confirm when a story is completed and working as intended
example
As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:
- A user cannot submit a form without completing all the mandatory fields
- Information from the form is stored in the registrations database
- Protection against spam is working
- Payment can be made via credit card
- An acknowledgment email is sent to the user after submitting the form.
Use case
heavyweight
use case describes a “Normal Flow” of steps and/or actions and “Alternative Flows” which are detailed.
formal specification, usually created as a formal document, detail description of a set of interactions between a system and and one or more roles, roles can be people or systems, including something as below,
- Use case title
- Rationale/description/goal
- Actor/user
- Preconditions (the things that must have already happened in the system)
- Standard path or Main success scenario (what will usually happen, described as a series of steps)
- Alternate paths or Extensions(variations on the above/edge cases)
- Post conditions (what the system will have done by the end of the steps).