Online Registration System Use Case Narrative Author (s): Sunday Adesanya

USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PARTICIPATING ACTORS: DESCRIPTION: Course Registration ORS -UC1 High Requirement Students Administrative Office This Use Case describes how Student registers for courses using the online registration system. It also describes how the Admin register for course in case the student are nit able to register for courses. This system allows the Students to go in and add, delete or modify the courses in which they plan to take before the beginning of each semester. This system also updates the database with up to date number of classes the student have taken and send out a notification to the billing system. This system also notifies the student if a pr-requisite to a particular course has not been taken and also updates the Students Grade once the class has come to completion. PRE-CONDITION: Student can only and are only allow registering until they are enrolled with Keller Graduate School. This use case is initiated when a Student is enrolled. Actor Action Step 1: The student indicates themselves by entering username and password into the registration system System Response Step 2: The system retrieve student account from the student file Step 3: The system check whether the student is enrolled or not enrolled Step 4: The system check or validate the students financial status Step 6 : The system retrieve courses information form course data file Step 7: The system display the course availability, campus location, courses class full or not Step 9: The system check if the student has taken or meet the pre-requisite for course selected. Step 10: The system successfully register the student and display a receipt of confirmation. Step 11: The system send the confirmation receipt or invoice to the students email. Step 12: The system record the students registration to student and course data file. ALTERNATE COURSES: POST-CONDITION:

Date: 09/25/2009 Version: 00.01

USE CASE TYPE Abstract: Extension:

TRIGGER: TYPICAL COURSE OF EVENTS:

Step 5: The student request to look up courses information Step 8: Student select the desire course, location and section they want to register for.

The system send notifications to the student for course(s) registered. Criteria of maximum of two classes or course are allow per semester

Online Registration System Use Case Narrative Author (s): Sunday Adesanya
USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PARTICIPATING ACTORS: DESCRIPTION: Maintain Course Information ORS UC2 High Requirement Administrative Office This Use Case describes the event of administrative staff maintaining courses information. The administrative staff identifies themselves by entering username and password, and the system verifies the username and password and pulls course information from course data store. The Administrative Staff can add and or delete and submits changes of courses information. When the course information changes is completed, the system send a confirmation to the Administrative staff and the system records the changes in the course data store PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS: The Administrative staff must be currently employed and have the ability to add, delete and/or change course information. Staff prepare list of courses offered. Actor Action Step 1: The Administrative staff indicates themselves by entering username and password into registration system Step 4: Admin Staff select the course that he/want to change or add or delete new courses System Response Step 2: The system verify the administrative username and password

Date: 09/25/2009 Version: 00.01

USE CASE TYPE Abstract: Extension:

Step 3: The system pull or retrieve course information from course data store Step 5: The system displays courses that are available for the admin to change or Added Step 6: The system check the admin security level to perform delete, add or make changes to course information. Step 7: The system allows the admin to perform add delete, or changes to course information. Step 8: The system send a confirmation to the Admin staff Step 9: The system record the changes to the course information data store.

ALTERNATE COURSES: POST-CONDITION:

Notifications are sent to faculty member about course.

Online Registration System Use Case Narrative Author (s): Sunday Adesanya
USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PARTICIPATING ACTORS: DESCRIPTION: This use case allows the Admin to maintain Faculty information in the registration system. This includes adding, modifying, and deleting Faculty from the system. PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS: The Administrative staff must be currently employed and have the ability to add, delete and/or change faculty information. This use case starts when the Administrative wishes to add, change, and/or delete Faculty information in the system.. Actor Action Step 1: The system requests that the Admin specify the function he/she would like to perform (either Add a Faculty, Update a Faculty, or Delete a Faculty) System Response Step 2: Once the Admin provides the requested information, one of the sub flows is executed. If the Admin selected Add a Faculty, the Add a Faculty subflow is executed Maintain Faculty Information ORS UC3 High Requirement -

Date: 09/25/2009 Version: 00.01

USE CASE TYPE Abstract: Extension:

Administrative

Step 3: The system requests that the Admin enter the Faculty information. This includes: name status department course taken locations Step 4: The system generates and assigns a unique id number to the Faculty and the Faculty is added to the system. The system provides the Admin with the new Faculty id. Step 5: If the Admin selected Update a Faculty, the Update a Faculty subflow is executed Step 6: The system requests that the Admin enter the Faculty ID. Step 7: The Admin enters the Faculty id. The system retrieves and displays the Faculty information. Step 8: The Admin makes the desired changes to the Faculty information. This includes any of the information specified in the Add a Faculty sub-flow. Step 9: If the Admin selected Delete a Faculty, the Delete a Step 10: The Admin enters the Faculty id. The system retrieves and displays the Faculty

Faculty subflow is executed.

information. Step 11: The system prompts the Admin to confirm the deletion of the Faculty. Step 12: The Admin verifies the deletion. The system deletes the Faculty from the system. Step 13: : The system send a confirmation to the Admin staff Step 14: The system record the changes to the Faculty information data store.

ALTERNATE COURSES: POST-CONDITION:

If the use case was successful, the Faculty information is added, updated, or deleted from the system.

Online Registration System Use Case Narrative Author (s): Sunday Adesanya
USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PARTICIPATING ACTORS: DESCRIPTION: This use case allows the Admin to maintain Students information in the registration system. This includes adding, modifying, and deleting Students from the system. PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS: The Administrative staff must be currently employed and have the ability to add, delete and/or change student information This use case starts when the Admin wishes to add, change, and/or delete Students information in the system. Actor Action Step 1: The system requests that the Admin specify the function he/she would like to perform (either Add a Student, Update a Student, or Delete a Student) System Response Step 2: Once the Admin provides the requested information, one of the sub flows is executed. If the Admin selected Add a Student, the Add a Student subflow is executed Maintain Student Information ORS UC4 High Requirement -

Date: 09/25/2009 Version: 00.01

USE CASE TYPE Abstract: Extension:

Administrative staff

Step 3: The system requests that the Admin enter the Student information. This includes: name date of birth social security number status program Step 4: The system generates and assigns a unique id number to the Student and the Students is added to the system. The system provides the Admin with the new Student id. Step 5: If the Admin selected Update Student, the Update a Student subflow is executed Step 6: The system requests that the Admin enter the Student ID. Step 7: The Admin enters the Student id. The system retrieves and displays the Student information. Step 8: The Admin makes the desired changes to the Student information. This includes any of the information specified in the Add a Student sub-flow. Step 9: If the Admin selected Delete a Student, the Delete a Step 10: The Admin enters the Student id. The system retrieves and displays the Student

Student subflow is executed.

information. Step 11: The system prompts the Admin to confirm the deletion of the Student. Step 12: The Admin verifies the deletion. The system deletes the Student from the system. Step 13: : The system send a confirmation to the Admin staff Step 14: The system record the changes to the Student information data store.

ALTERNATE COURSES: POST-CONDITION:

If the use case was successful, the Student information is added, updated, or deleted from the system.

Online Registration System Use Case Narrative Author (s): Sunday Adesanya
USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PARTICIPATING ACTORS: DESCRIPTION: Select Course To Teach ORS UC5 High Requirement Faculty This use case allows a Faculty to select the course offerings from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.

Date: 09/25/2009 Version: 00.01

USE CASE TYPE Abstract: Extension:

PRE-CONDITION: The Faculty Staff must be logged onto the system before this use case begins. TRIGGER: TYPICAL COURSE OF EVENTS: This use case starts when a Faculty wishes to sign up to teach some course offerings for the upcoming semester. Actor Action Step 1: The Faculty successfully login into the system to select course(s) to teach System Response Step 2: The system retrieves and displays the list of course offerings the Faculty is eligible to teach for the current semester. The system also retrieves and displays the list of courses the Faculty has previously selected to teach. Step 3: The Faculty selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester. Step 4: The system removes the Faculty from teaching the de-selected course offerings. Step 5: The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with each other or any course offerings that the Faculty has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the Faculty selects (i.e., records the Faculty as the instructor for the course offering). ALTERNATE COURSES: POST-CONDITION:

If the use case was successful, the course offerings a Faculty is scheduled to teach have been updated. Otherwise, the system state is unchanged.

Online Registration System 7

Use Case Narrative Author (s): Sunday Adesanya

USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PARTICIPATING ACTORS: DESCRIPTION: PRE-CONDITION: The Faculty Staff must be logged onto the system before this use case begins. TRIGGER: TYPICAL COURSE OF EVENTS: This use case starts when a Faculty wishes to submit student grades for one or more classes completed in the previous semester. Actor Action Step 1: The faculty identifies themselves by entering username and password Step 3: The faculty look up course list Step 5: The Faculty selects a course offering that he/she want to submit the Grade for. Step 7: For each student on the list, the Faculty enters a grade: A, B, C, D, F, or I. If the Faculty wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Faculty may also change the grade for a student by entering a new grade. ALTERNATE COURSES: POST-CONDITION: System Response Step 2: The system verifies the faculty. Step 4: The system displays a list of course offerings the faculty taught in the previous semester. Step 6: The system retrieves a list of all students who were registered for the course offering. The system displays each student and any grade that was previously assigned for the offering Step 8: The system records the students grade for the course offering and display the list of grade for faculty to confirm Submit Grade ORS UC6 Low

Date: 09/25/2009 Version: 00.01

USE CASE TYPE Abstract: Extension:

Requirement Faculty Student Administrative staff This use case allows a Faculty to submit student grades for one or more classes completed in the previous semester.

Step 9: The system records the grade to course data store

If the use case was successful, student grades for a course offering are updated. Otherwise, the system state is unchanged.