Description

Identifier (A unique identifier for this use case, e.g. UC10)

Description (A couple of sentences or a paragraph describing the basic idea of the use case)

Goal (The business goal of the initiating actor)

Preconditions (List the state(s) the system can be in before this use case starts)
1.

Assumptions (Optional, List all assumptions that have been made)
1.

Frequency (Approximately how often this use case is realized, e.g., once a week, 500 times a day, etc.)

Basic Course (Describe the “normal” processing path, aka, the Happy Path) 1. Use case begins when …
2.
3. Use case ends when …

Alternate Course A: Description of the alternate course
Condition: Indicate what happened
A.6 List the steps

Post conditions (List the state(s) the system can be in when this use case ends) 1.
Actors (List of actors that participate in the use case)
Included Use Cases (Optional, List of use cases that this use case includes)
1.

Extended Use Case (Optional, The use case, if any, that this use case extends)

Notes
List any “to dos”, concerns to be addressed, important decisions made during the development of this use case, …

Sample Use Case

Name: Enroll in Seminar
Identifier: UC 17 Description:
Enroll an existing student in a seminar for which she is eligible.

Preconditions:

Postconditions:
The Student will be enrolled in the course she wants if she is eligible and room is available.

Basic Course of Action:
1. The use case begins when a student wants to enroll in a seminar.
2. The student inputs her name and student number into the system via UI23 Security Login Screen.
4. The system displays UI32 Seminar Selection Screen, which indicates the list of available seminars.
5. The student indicates the seminar in which she wants to enroll. [Alt Course B: The Student Decides Not to Enroll]
6. The system validates the student is eligible to enroll in the seminar according to the business rule BR130 Determine Student Eligibility to Enroll in a Seminar. [Alt Course C]
7. The system validates the seminar fits into the existing schedule of the student according to the business rule BR143 Validate Student Seminar Schedule.
8. The system calculates the fees for the seminar based on the fee published in the course catalog, applicable student fees, and applicable taxes. Apply business rules BR 180 Calculate Student Fees and BR45 Calculate Taxes for Seminar.
9. The system displays the fees via UI33 Display Seminar Fees Screen.
10. The system asks the student if she still wants to enroll in the seminar.
11. The student indicates she wants to enroll in the seminar.
12. The system enrolls the student in the seminar.
13. The system informs the student the enrollment was successful via UI88 Seminar Enrollment Summary Screen.
14. The system bills the student for the seminar, according to business rule BR100 Bill Student for Seminar.
15. The system asks the student if she wants a printed statement of the enrollment.
16. The student indicates she wants a printed statement.
17. The system prints the enrollment statement UI89 Enrollment Summary Report.
18. The use case ends when the student takes the printed statement.

Alternate Course A: The Student is Not Eligible to Enroll in Seminars.
A.3. The registrar determines the student is not eligible to enroll in seminars.
A.4. The registrar informs the student he is not eligible to enroll.
A.5. The use case ends.

Alternate Course B: The Student Decides Not to Enroll in an Available Seminar
B.5. The student views the list of seminars and does not see one in which he wants to enroll.
B.6. The use case ends.

Alternate Course C: The Student Does Not Have the Prerequisites
C.6. The registrar determines the student is not eligible to enroll in the seminar he chose.
C.7. The registrar informs the student he does not have the prerequisites.
C.8. The registrar informs the student of the prerequisites he needs.
C.9. The use case continues at Step 4 in the basic course of action.