Use Cases allow requirements to be presented as a collection of stories from the user’s perspective. A Use Case can be used on its own or in addition to a User Story to provide more detailed descriptions of how users interact with a system.
Use Case Diagram
Use Case Diagrams can be used to help visualise the story described in a Use Case. A Use Case Diagram consists of 3 components:
- Actor – represented by a stick figure
- Use Case Name – represented by an ellipse
- Association – represented by a straight line that links an Actor with a Use Case Name
Example:
Conventions followed when creating a Use Case Diagram:
- The Use Case Name starts with a verb and (optionally) followed by a noun.
- The main / primary actor is usually drawn on the left and the supporting / secondary actor (if there is one) on the right.
Exercise
Course Registration
At the start of each semester a student can request a prospectus containing a course list. Information about a course is provided, such as the tutor, department and prerequisites.
The new system will allow students to create a schedule, then select four courses. Each student chooses two others in case their first choices become full or are cancelled. No course
can have more than 10 students. No course can have less than 3 students or it will be
cancelled. This will be the same functionality as available to other internal users of the
system.
When registration is complete, the registration system sends a message to the billing system
to send out a bill to the student.
Tutors use the system to find which classes they are teaching and who the students are. The registrar will administer the system.
For a period at the beginning of the semester the student can change their schedule.
Students must be allowed to access the system during this time to add or delete courses.
Task
Analyse the ‘Course Registration’ requirements above and represent them as a Use Case Diagram.
Example answer
Textual Use Case
A textual Use Case typically include:
- Use Case ID
- Use Case Name
- Actors (or Users)
- Description
- Pre-conditions
- Post-conditions
- Trigger
- Primary Flow
- Alternative Flows
- Exception Flows
The Primary Flow is usually quite simple and shows what normally occur in the most common scenario and when nothing out of the ordinary happens. Any possible variations to the normal story are then presented as Alternative Flows, while the Exception Flows describe what can go wrong and how the Use Case will handle it.
Example textual Use Case for ‘Register for Courses’:
| Use Case ID: | UC-101 |
|---|---|
| Use Case Name: | Register for Courses |
| Description: | This use case allows the student to register for courses by creating, viewing, modifying or deleting a schedule for a specified semester. Pertinent billing information is sent to the Billing System. |
| Primary Actor: | Student |
| Secondary Actor: | Billing System |
| Pre-conditions: | Registrations for the Semester are open to Students. |
| Post-conditions: | List of students enrolled in the course is updated. |
| Trigger: | Student submits the enrolment form. |
| Primary Flow: |
|
| Alternative Flow: | 1.a. The password has expired
|
| Exception Flow: | 1.a. Invalid student details entered
|
Further Learning
In Use Case Diagrams, apart from the simple association there can also be other relationships between an Actor and a Use Case that you can show, such as Extend, Include and Generalisation.
In textual Use Cases, there can also be more complex requirements, possible alternatives and exceptions.
Learn further about Use Cases and more, by attending one of the following IRM Training’s hands-on courses:
