Use-Case Model

Version	Date	Description	Author
Inception Draft	July 15, 2003	High ranking use cases to be refined before first Inception iteration.	Mathews
Inception Draft	July 17, 2003	Refined high-ranking use cases.	Mathews

Use Case 1: Offer Courses

Department offers courses for a semester. Department supplies course name, number of sections, class size, and professor. Department must offer classes before registration begins. If too few students have registered for a course, the Department may cancel the course.

Primary Actor: Department Staff (Staff hereafter)

Stakeholders and Interests:

- Staff: Wants to offer a set of courses for a given semester.

- Registrar: Wants number of sections and class sizes before start of registration.

Preconditions: Staff is authenticated to the system.

Success Guarantee (Postconditions): Offered courses are recorded.

Main Success Scenario:

1. Staff arrives at terminal with list of courses to be offered for a given semester.

2. Staff starts offering courses.

3. System requests semester.

4. Staff enters semester.

5. Staff enters course designator.

6. Staff enters number of sections.

7. Staff enters maximum enrollment per section.

8. Staff enters instructing professor.

Staff repeats 4-8 until indicates finished.

9. System indicates course offerings have been recorded.

Extensions:

4a. Invalid semester:

1. System indicates error and requests new semester.

4b. Too early or too late to offer courses for semester:

1. System indicates error and requests new semester.

5a. Invalid course designator:

1. System indicates error and requests new course designator.

9a. System cannot record course offerings:

1. System indicates error.

Special Requirements:

-

Technology and Data Variations List:

-

Frequency of Occurrence:

Each Department offers courses before registration for the next semester.

Open Issues:

-

Use Case 2: Compile Course Offerings

System compiles a list of course offerings for Registrar to use in determining schedule.

Use Case 3: Create Course Enrollment Report

Professor gets a list of students enrolled in a course and any adds or drops since the start of the semester.

Use Case 4: Student Registration

Student adds an available course section. May also drop courses or get a schedule of classes in which Student is enrolled. Students can be registered for variable credit classes, pass/fail, or R credit.

Primary Actor: Student

Stakeholders and Interests:

- Student: Wants to add and drop courses. Wants to see personal course schedule.

- Registrar: Wants accurate enrollment records for billing purposes.

- Professor: Wants accurate enrollment records for teaching purposes.

Preconditions: Student is authenticated.

Success Guarantee (Postconditions): Registration changes are recorded.

Main Success Scenario:

1. Student enters semester.

2. Student enters a course section to add or drop.

3. System records registration change.

Repeats 1-3 until Student indicates finished.

Extensions:

1a. Invalid semester:

1. System indicates error and requests new semester.

1b. Too early or too late to register:

1. System indicates error.

2a. Student tries to add a full course:

1. System indicates error and requests new course designator.

2b. Invalid course designator.

1. System indicates error and requests new course designator.

3a. System cannot record change:

1. System indicates that Student should try again later.

Special Requirements:

-

Technology and Data Variations List:

- Semester and course designator could be selected from a list to reduce data entry errors.

Frequency of Occurrence:

- Nearly continuous during registration period.

Open Issues:

-

Use Case 5: Schedule Course Offerings

Registrar enters scheduling information (times & places) into System. Some courses may not have a meeting time or place.

Use Case 6: Create Billing Information

Registrar directs system to send billing information to University’s Billing System.

Use Case 7: Manage Users

System Administrator can add or remove users, or alter the security access for users.

Use Case 8: Manage Registration and Course Offering Access

Time will play a role in registration access for Students. There will be a start and end date during which a Student can use the registration system directly. Time also plays a role in when Departments can offer courses.

Use Case 9: Start Up

The System Administrator can start the system, which initializes subsystems as necessary.

Use Case 10: Shut Down

The System Administrator can shut down the system, which takes the system down in a clean state (no unfinished transactions).

Use Case 11: Advisor/Registrar Manages Registration for Student

Advisor/Registrar adds/drops courses on Student’s behalf.

Use Case 12: Search for Courses

Student/Advisor searches for courses by various criteria.