Online Registration at Chico State (ORACS)

 

 

 

 

 

Project Proposal

Todd Tran

February 22, 2001

CSCI 211

Instructor: Dr. Melody Stapleton

 

 

 

 

 

 

 

 

Table of Contents

 

Sections                                                                              Page

1.                 Background                                                                           3

2.                 Requirements Definition                                                          6

3.                 Use Cases                                                                              8

4.                 CRC Cards                                                                            13

5.                 Class Model                                                                           15

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Background

The Telephone Registration at Chico State (TRACS) system has been used at CSU Chico for a number of years now.  The process allows students to add and drop courses by entering their identification number (social security number), and student password (date of birth) through the telephone.  Pressing numbers on the telephone keypad initiates all selections and actions.  This system performed well in respect to its initial requirements.  However, in recent years, new technological advances have rendered it obsolete.  As a result, TRACS can no longer satisfy the needs of its student users.

 

Many performance and usability problems exist within the current registration process.  1.          One such problem is that during peak registration periods, access to TRACS is not always guaranteed.  TRACS is limited in its availability, as its hours of operation are eight to seven on weekdays and noon to seven on weekends.  Because there is such a limited window for access, students often enroll or drop courses during the same time.  If traffic is too high, there are not enough points of access to satisfy all users.  As a result, students are often left to repeatedly dial in or wait for a less constricted time.  A problem that contributes to this traffic may be the high levels of time consumption inherit in an audio information medium.  For instance, it is time consuming when a student wants to hear all information for courses on their study list.  A visual representation of this data would go a long way to speeding things up.

2.         An inefficiency with the current system is that the punching in of numbers on the telephone keypad may lead to a number of hassles.  For instance, every number that is pressed is a final decision and cannot be retracted.  If one wrong digit is pressed in a social security number (SSN), then the whole sequence has to be retyped.  Also, there is just too many levels of authentication.  For a typical user to access TRACS,  a SSN has to be punched in correctly.  After about a 10 second verification wait, the user is then allowed to type in his student password.  Another verification wait occurs, and the process continues as you then must specify a code for the current semester.  A system that takes in all this information at once, and makes one authentication check, would greatly improve time management and allow students to quickly finish their business so others can enter. 

3.         One of the more glaring problems of the current registration process is that it is in fact telephone based.  This proves as a major burden to students who do not live locally and who may be from other countries.  Many times registration occurs when a student is home on vacation away from Chico.  In order for these users to register, they must incur expensive long distance charges.  A medium of registration that overcomes this problem would greatly ease the process of registration.

4.         Lastly, registration at Chico State is greatly hindered because TRACS does not have a waiting list option for courses.  We find that once a course is full, students who want to add a course have to repeatedly dial in to the system.  They are hoping that a spot has opened just as they have called.  This adds to the problem of increased phone traffic and can be resolved by a waiting list that adds a user to a course immediately after someone has dropped.  In addition, TRACS is not real-time registration.  Databases are not updated immediately but at the end of the day.  An up to the second display of course info would be extremely helpful in determining a course’s availability and reducing multiple call-ins.

It is my opinion, that the implementation of an Online Registration at Chico State (ORACS) system will alleviate many of TRACS’ shortcomings.  With a high enough bandwidth, the system can handle all the traffic at Chico State from its web interface.  Also, usability is improved as students can check all their data for errors before submitting it for verification.  It is conceivable that more than one option can be entered at once.  Thus, speed of operation will definitely be enhanced.  In addition, high phone charges will be a non-factor since Internet access is fairly cheap and common.  Registration can now take place anywhere in the world.  Lastly, with the creation of a new registration software, we can conveniently add in functions for waiting lists and instantaneous database updating.

 

 

 

 

 

 

 

 

 

 

 

Requirements Definition

In overview, this purpose of this project is to create an online system to be used for course registration on a college campus.  It is tailored for the needs of the students at CSU Chico and funded exclusively by the university.  In general, the goal of the system is to provide a faster, more convenient, more efficient, and all together, better means to register for courses at Chico State.  Specifically, this includes:

• Quick system log in and completion of tasks.
• Increased functionality, including waiting lists and study list displays.
• Instantaneous database updating.

 

In addition, the system requires these functions and attributes.

 

Ref #	Function	Cat.	Attribute	Details and Constraints	Cat.
R1.1	Record student enrollments and drops.	evident	fault tolerance	within 5 minutes	want
			reponse time	20 second max	must
R1.2	Display student's study list with course info.	evident	response time	20 second max	must
			interface metaphor	simple text in webpage	want
R1.3	Display student options.	evident	reponse time	10 second max	must
			interface metaphor	colorful webpage	want
R1.4	Display request for login info.	evident	response time	5 second max	must
			interface metaphor	graphical, colorful	want
R1.5	Display administrator options.	evident	reponse time	10 second max	must
			interface metaphor	simple webpage	want
Ref #	Function	Cat.	Attribute	Details and Constraints	Cat.
R1.6	Student or Administrator must log in to use system.	evident	response time	20 second max	must
R1.7	Record administrator's creation of new course or student.	evident	fault tolerance	within 5 minutes	want
			reponse time	20 second max	must
R1.8	Record administrator's change of student info.	evident	fault tolerance	within 5 minutes	want
			reponse time	20 second max	must
R1.9	Record administrator's deletion of course or student.	evident	fault tolerance	within 5 minutes	want
			reponse time	20 second max	must
R1.10	Record administrator's change of course info.	evident	fault tolerance	within 5 minutes	want
			reponse time	20 second max	must
R1.11	Add student from waiting list after a drop in full course	hidden	fault tolerance	within 24 hours	want
			reponse time	20 second max	must
R1.12	Update databases with change.	hidden	fault tolerance	within 5 minutes	want
			reponse time	20 second max	must
R1.13	Reduce or increase enrollment number after add or drop.	hidden	reponse time	20 second max	must
R1.14	Calculate total number of units in study list to not exceed 15.	hidden
R1.15	Prevent student from registering.	hidden
R1.16	Display complete course schedule	frill	response time	20 second max	must
			interface metaphor	simple text in webpage	want
R1.17	Display up to the minute course info involving enrollment number.	frill	response time	20 second max	must
			interface metaphor	simple text in webpage	want

 

 

Use Cases

Use case:          Log-in

Actor(s):           Student, Administrator

Type:                Primary

Description:      A student or administrator arrives at ORACS website login page and submits an i.d. number and password.  ORACS program checks for validity in their student or administration records.  If combination found and there is no hold on student then user allowed access.

Use case:          Add Course

Actor(s):           Student

Type:                Primary

Description:      Student arrives at student options page and submits request to add a course by typing in correct option and course i.d.  ORACS checks to see if course is a valid one.  If it is and there is room in the course, system adds the student to course’s enrollment list, and the course to student’s study list.

Use case:          Drop Course

Actor(s):           Student

Type:                Primary

Description:      Student arrives at student options page and submits request to drop a course by typing in correct option and course i.d.  ORACS checks to see if course is a valid one and if student is enrolled in course.  If validity holds, then student dropped form course’s enrollment list, and course dropped form student’s study list.

Use case:          Display Study List

Actor(s):           Student

Type:                Primary

Description:      Student arrives at student options page and submits request to display student’s study list.  ORACS displays on screen all courses in study list and any of their relevant information.

Use case:          Change Student Info

Actor(s):           Student, Administrator

Type:                Primary

Description:      Student or administrator arrives at their options page and submits request to change student info.  For administrator, ORACS prompts for student i.d. and checks it’s validity.  For both actors, a screen with information about student that can be altered will be displayed.  Can change info and resubmit page to ORACS for execution of update in student records.

Use case:          Create New Course

Actor(s):           Administrator

Type:                Primary

Description:      Administrator arrives at administrator options page and submits request to create new course.  ORACS displays on screen all information that needs to be entered to create a new course.  Administrator enters all information needed and submits.  ORACS executes update by putting new course in course catalog.

 

Use case:          Cancel Course

Actor(s):           Administrator

Type:                Primary

Description:      Administrator arrives at administrator options page and submits request to cancel course.  ORACS prompts for course to drop.  Administrator enters course i.d. and submits.  ORACS executes update by going into study list of every student in course’s enrollment list and deleting course.  Finally, course is deleted from course catalog.

Use case:          Create New Student

Actor(s):           Administrator

Type:                Primary

Description:      Administrator arrives at administrator options page and submits request to create new student.  ORACS displays on screen all information that needs to be entered to create a new studet.  Administrator enters all information needed and submits.  ORACS executes update by putting new student in student records.

 

 

 

 

 

 

 

Use case:          Remove Student

Actor(s):           Administrator

Type:                Primary

Description:      Administrator arrives at administrator options page and submits request to remove student.  ORACS displays on screen prompt for student i.d.  Administrator enters i.d. and submits.  ORACS executes removal by going through student’s study list and deleting student from every enrollment list of every course in study list.  Finally, student and study list are deleted from student records.

Use case:          Change Course Info

Actor(s):           Administrator

Type:                Primary

Description:      Administrator arrives at administrator options page and submits request to change course info.  ORACS displays on screen all information that can be changed in a course.  Administrator makes all necessary changes to course and submits.  ORACS then executes update.

 

 

 

 

 

 

 

Use Case Diagram:

 

 

 

 

 

 

 

CRC Cards

 

ORACS
Responsibilities	Collaborators
Maintains CourseCatalog	CourseCatalog
Maintains StudentList	StudentList

 

 

CourseCatalog
Responsibilities	Collaborators
Maintains all CourseRecords

 

 

CourseRecord
Responsibilities	Collaborators
Maintains data on courses
Meet requests to add to or drop from EnrolledList	EnrolledList

 

 

EnrolledList
Responsibilities	Collaborators
Maintains data on courses in students current term
Meets requests to add or drop students	StudentRecord

 

 

StudentList
Responsibilities	Collaborators
Maintains all StudentRecords

 

 

 

StudentRecord