User stories & use cases
You've talked to your stakeholders (see Understanding Stakeholders) and done your requirement analysis. Now you have a pile of things people want. The next problem: how do you turn "the client wants students to be able to sign up for courses easily" into something your team can actually design, estimate, and build?
Two tools do most of the heavy lifting here: user stories and use cases. They look similar, get confused constantly, and are genuinely good at different things.
User stories
A user story is a short, informal description of a feature from the point of view of the person who wants it. The standard template, popularised by Mike Cohn and the early Extreme Programming/Scrum community, is:
As a <type of user>, I want <some goal>, so that <some reason/benefit>.
For example: "As a student, I want to see which courses still have open spots before I try to sign up, so that I don't waste time picking a course I can't actually join."
The key thing to understand about user stories is that they are deliberately incomplete. The original idea (the "Three C's": Card, Conversation, Confirmation) was that a story is a placeholder for a conversation, not a finished specification. The card just reminds you to have the conversation with the stakeholder before you build it. That's why stories are usually followed by a short list of acceptance criteria — specific, testable conditions that define "done":
- Available course spots are shown as a number next to each course.
- Courses with zero spots left are visibly disabled, not just greyed out slightly.
- The spot count updates within 5 seconds of another student signing up.
Use cases
A use case is a more structured, detailed description of how an actor (usually a user, but it can be another system) interacts with the system to achieve a goal, including what happens when things don't go according to plan. Use cases predate user stories by about a decade — they come from Ivar Jacobson's work in the late 1980s/early 1990s and were later formalised by Alistair Cockburn.
A typical use case includes:
- Actor — who or what initiates the interaction (e.g. "Student").
- Goal — what they're trying to achieve.
- Preconditions — what must be true before this can happen (e.g. "student is logged in").
- Main flow (happy path) — the step-by-step sequence when everything goes right.
- Alternate / exception flows — what happens when things don't: the course fills up mid-signup, the payment fails, the session times out.
- Postconditions — what's true once the use case completes successfully.
Example — "Sign up for a course":
Actor: Student | Precondition: Student is logged in and the course has open spots
Main flow:
- Student searches for or browses to a course.
- System displays the course details and remaining spots.
- Student selects "Sign up."
- System checks that a spot is still available.
- System confirms the sign-up and updates the student's schedule.
Exception flow (3a): if no spots remain by the time the student confirms, the system shows an error and offers to add them to a waitlist instead.
Postcondition: the student is enrolled and the available spot count is decremented.
So which one do I use?
Honestly — often both, for different purposes. A rough guide:
- Use user stories when requirements are still evolving, when you're working in short sprints, and when the point is to spark a conversation with the client rather than lock in every detail up front. Great for early-stage and agile-style student projects.
- Use use cases when the interaction is complex, when what happens in edge cases genuinely matters (payments, authentication, anything safety- or compliance-related), or when you need a precise artifact to test against later. They're also useful even inside an agile process, as a way to think through a feature properly before you write the story and acceptance criteria for it.
A useful habit: when a user story feels too flimsy to build from — when your team keeps disagreeing about what "sign up for a course" actually means step by step — that's usually a sign you need to write out the use case behind it before you touch any code.
Why is this important?
Without some intermediate format like this, requirements stay as vague sentences in someone's head (or worse, in a two-month-old email thread), and every team member fills the gaps with their own assumptions. User stories and use cases force those assumptions into the open, in a shape that's small enough to estimate, build, and test one piece at a time. They're also the artifact your supervisor will most likely want to see as evidence that you actually analysed the problem before building — a page of well-written user stories with acceptance criteria says a lot more about your process than a finished feature with no documented reasoning behind it.
Tips
- Keep user stories small. If you can't picture building and testing it in a few days, it's probably several stories pretending to be one ("epic" is the usual term for that bundle).
- Always write acceptance criteria. A story without them is just a vague wish with a nicer sentence structure.
- Don't write a use case for every trivial interaction — save the full structured format for the ones where the edge cases actually matter. For simple CRUD-style features, a user story is usually enough.
- Involve the actual stakeholder when writing these, not just your team's assumptions about them. Remember: the whole point of a user story is to trigger a real conversation, not replace one.
References
Sethi, R. Software Engineering: Basic Principles and Best Practices — good grounding in requirements specification techniques, including use case modelling.
Cohn, M. User Stories Applied: For Agile Software Development — the book that popularised the modern user story format.
Cockburn, A. Writing Effective Use Cases — the standard reference for structured use case writing.
Visual Paradigm — User Story vs Use Case for Agile Software Development