Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Example: Close Registration Use Case Specification

Course Registration System

Use-Case Specification

Close Registration Use Case

Version 2.0

Revision History

DateVersionDescriptionAuthor
21/Dec/98DraftDraftS. Gamble
13/Feb/99Version 1.0Minor corrections based on reviewS. Gamble
15/Feb/99Version 2.0Modify section on use case extends. Final cleanup. Revise alternative flows. Resolve outstanding issues.S. Gamble

Table of Contents

  1. Brief Description
  2. Flow of Events

    2.1    Basic Flow - Successful Close Registration

    2.2    [Alternate Flows](#Alternate Flows)

    2.2.1    Less Than Three Students in the Course Offering

    2.2.2    [Cancel Course Offering](#Cancel Course Offering)

    2.2.3    No Professor for the Course Offering

    2.2.4    Billing System Unavailable
  3. Special Requirements
  4. Preconditions

    4.1    Login

  5. Postconditions
  6. Extension Points

Close Registration Use Case

- Brief Description

This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.

The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.

2.    Flow of Events

The use case begins when the Registrar selects the “close registration” activity from the Main Form.

2.1    Basic Flow - Successful Close Registration

The system checks to see if a Registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. .

For each open course offering, the system checks if three students have registered and a professor has signed up to teach the course offering. If so, the system closes the course offering and sends a transaction to the billing system for each student enrolled in the course offering.

2.2    Alternate Flows

2.2.1 Less Than Three Students in the Course Offering

If in the basic flow less than three students signed up for the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.

2.2.2Cancel Course Offering

The system cancels the course offering. For each student enrolled in the cancelled course offering, system will modify the student’s schedule. The first available alternate course selection will be substituted for the cancelled course offering. If no alternates are available, then no substitution will be made. Control returns to the Main flow to process the next course offering for the semester.

Once all schedules have been processed for the current semester, the system will notify all students, by mail, of any changes to their schedule (e.g., cancellation or substitution).

2.2.3No Professor for the Course Offering

If in the basic flow there is no professor signed up to teach the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.

2.2.4Billing System Unavailable

If the system is unable to communicate with the Billing System, the system will attempt to re-send the request after a specified period. The system will continue to attempt to re-send until the Billing System becomes available

    3.    Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1    Login

The Registrar must be logged onto the system in order for this use case to begin.

5.    Postconditions

There are no postconditions associated with this use case.

6.     Extension Points

There are no extension points associated with this use case.