Imagine fictitious people who want to use your product.
Who are they? What are their goals for your product?
We can describe each user and goal in a "Use Case".
Here are some examples of users and goals for education software:
Students want to participate in a lesson, answer test questions, and send in homework.
Teachers want to take attendance, assign lessons, view students' progress, and grade tests.
What should be in a use case?
Brief Description: a paragraph that describes who interacts with the use case, what happens, when, etc.
Normal Flow of Events: the typical steps that happen
Alternate Flow(s) of Events: any atypical steps, unusual variations, odd cases, or errors
To improve your use case
Iteratively add more detail to the outline to specify the steps of the use case.
Each step should clearly state who is performing the action and the result of the action
For loops, you can use phrasing like: "User can continue adding items until he indicates he's done."
Beware of "if... then..." phrase because it is harder to follow. Instead, consider using an alternate flow
Question to ask: Is there enough information specified to complete the system analysis, design and test?
You are done when the use case has a complete flow of events, has terminology described in a support glossary and defines all inputs to and outputs from the use case.
To make your use case easier to read
Formal: you describe in third person, e.g. "Student signs in. Student edits his profile. Student chooses a classroom."
Easier: you decribe in first person, e.g. "I sign in. I choose a classroom. I edit my profile."
Formal: you describe what the system does, e.g. "The system retreives a list of classrooms."
Easier: you describe what the user sees, e.g. "I see a list of classrooms."
Formal: passive voice, e.g. "The Add Course use case is initiated by the Student."
Easier: active voice, e.g. "I initiate the Add Course use case."
To descibe you user interface
Put your user interface details in a separate document.
Use visual or even physical mock-ups to describe UI
Describe navigation using storyboards
UML class and sequence diagrams are great aids here
To describe your data validations
Put your data validations in a separate document.
"Student identification numbers are numbers that are used to verify that a student is eligible to register for courses."
"The student indentification number must be unique."
"The student identification number must be 6 to 8 alpha-numeric characters."
Example Use Case
Title: Student creates a course schedule
Primary Actor: Student
Secondary Actor: Course Registration System
A student wants to choose course for a specified semester.
I sign in. (Detailed in diferent use case)
I see choices: Create A Schedule, Modify A Schedule, Delete A Schedule.
I choose Create A Schedule.
I see choices: Fall Semester, Spring Semester, Summer Semester.
I choose Fall Semester.
I see a list of available fall semester courses from the Course Catalog System.
I can sort the list by the course titles and classroom locations.