N E W   T R A C S

HAWARD SOFT DESIGN UNIVERSITY

Goal

Goal

The project goal is to design and analyze a new web base tracs software for Haward Soft Design Unviersity (not real). This system allow the the users to access, update, or even create course information (depend on who users they are) in real time from internet browser.

 

General Background

Ten years ago, Haward Soft Design University (HSD University) had 4.001 students, who 156 students were international students. Because the HSD University is wellknown in the world, now; it has 45.893 students with 15.523 International students.

 

The existing system for adding, dropping course(s), updating students’ grades is through TRACS System which can only access by local phone. With this current system. This system cannot allow the students or instructors to add or modify something (unless they make a international or long distance calls). It also won’t give any information about the current seats available for a specific couse. The other thing who is also concerned by HSD University is about the limitied seats for courses while the students intend to hold the courses until it almost close to dropping course deadline, this doesn’t give any chance for those students who want to enroll the same courses.

 

Realizing there are huge students want to enroll the courses and the existing system doesn’t give an equal opportunity for those students who are not currently in the university nearby by the course request period, the university make a decision to change the old TRACS System to a new web base TRACS System.

 

The New TRACS System provides year-round access for requesting courses for every semesters and to inform students of registration and other important academic status messages and holds. The New TRACS System has a new feature which can let students in waiting list if the courses are fulled. The System let the students check their study list and check for holds and other messages.

 

For the Instructor Part, the New TRACS System enable the instructors to input the students’ grades online, giving assignments, making notes at any part in the world. This make the instructors’ lifes more easily.

 

Tools Description

I believe by using the virtual model as the backbone design, it ensures better control on software development. For designing the system, I use Rational Software.

 

The reasons for using the Rational Software are: 

  1. Develop iteratively to mitigate risk early in the project
  2. Effectively manage requirements
  3. Model visually to manage complexity
  4. Verify quality.
  5. Control changes to software

 

More over, I have selected ORACLE and JAVA language for platform independence. With all the risks of being too early to decide, I feel that in the present and the near future there is no other feasible alternative yet.

 

 

 

 

REQUIREMENTS

 

 

 

Overview

In New TRACS System, the Course Request Period is provided for many weeks through the orientation and advisng periods each semester. This allow the students plenty of time to meet with the adviser, clear all holds, take or verify required test statuses, and make additional changes to students’ requests as well.

 

The Course Add/Drop Course Period is schedule for five weeks, the three weeks before classes begin and the first two weeks of the semester. This is a “real-time or live registration,”  first-come, first served, add and drop period using the same TRACS system. The students will be able to add classes which are still opend after the Scheduler is run and drop most classes without special permission during the period.

 

There is a new feature that allow students to put themselves in waiting list if they still hope to get seats in specific courses. Realizing that many students will apply to waiting list without other considerations, the system will make the students to think twice before putting themselves in waiting list. I’ll discuss more detail after this.

 

 

Users

Administrator, course manager, intructors, and students .

 

 

Requirements

The hardware to access the New TRACS is the complete PC or Mac which connects with the internet. This PC or Mac can be anywhere, in Library or home.

 

The software I am going to design must be platform browser independent, reasonable response time, can uses GUI.

 

Before the users can get through the New TRACS System, they need to have unique Personal Identification Number (PIN). At the first time registering the system, they need their Social Security Numbers and Student Card Numbers. (for Students) / Employee Card Numbers (for Administrator, Course Manager, Intructor). This is only one time use. After that, they can choose the unique user name and password for each student. The user can’t modify the user name, but he/she can change his/her own password.

 

Mainly, there are four types of users who can access the system. They are the admistrator, course manager, instructors, and students. I devide the users by limiting the features they can have.

 

The Administrator is the person who can start up / shut down the system, create / remove account, manage files, and login to the system.

 

The Course Manager can:

1. Add student to students records.

2. Delete a student.

3. Add a course to the course records.

4. Update a course.

5. Delete a course.

 

If a student is being deleted, then all the courses which he/she is currently enrolled must also be removed.

 

The Instructors features are:

1. Display the course list.

2. Input the Students’ Grades.

3. Giving notes.

4. Giving assignments.

5. Giving quizzes.

 

If the instructor wants to drop his/her class, he/she must make a written request to the Course Manager with Chair’s approval.

 

The Students features are:

1. Displaying Courses Information.

2. Displaying Grades.

3. Attempting to Add a course.

4. Dropping a course.

5. Adding their own id# to waiting list.

6. Removing their own id# to waiting list.

7. Sending Assignments.

8. Taking quizzes.

 

If there are students in waiting list, then the first priority in waiting list is the person who in the first waiting line on the list. If somebody drop the course, then the first priority waiting list student automatically assigns to that course. Those who get enroll in the course from wating list, cannot drop the course if it is already accepted in the course, except they are still in waiting list.

Use Case Documentation

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Use Case: Login

Actors

Administrator, Course Manager,  Instructor, Admission, Student.

Purpose

To access the system according to user categories with each privileges.

Overview

Before the system can be access, the user must enter login name and password to know whether the user is a valid user and what previleges he/she can have.

Type

Primary and essential

Note

Each user must has their own unique name and password to login the system.

 

 

 

 

Typical Course of Events

Actor Action

System Response

1.   This use case begins when the user starts to access the tracs system.

 

2.   The user input the user’s name.

3. Store the user’s name in variable userName.

4.   The user input his/her password.

5. Store the user’s password in variable userPassword.

 

6. The system checks whether the userName and userPassword exists in the userList.

 

7. The system gives the valid user notification that he/she can start accessing the system with the specific previleges.

 

 

 

Alternatif Courses

Line 6

Invalid username and password entered. Indicate error.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Use Case: Start Up / Shut Down

Actors

Administrator.

Purpose

To start up / shut down the tracs system.

Overview

The administrator can start up the system after his/her user name and password has been verified. After the system has been started up, other users can access the system. But if the system has been shut down, no other users can access the system.

Type

Primary and essential

Note

Although the admistrator has privileges to shut down the system, but if it is not indeed important to shut down (for example: for maintenance purpose), the administrator will keep the system on.

 

 

 

Typical Course of Events – Start Up

Actor Action

System Response

1.   The Administrator starts to make the system works by turning on the computer network.

 

2.   The Administrator input his/her user’s name.

3.   Store the user’s name in variable userName.

4.   The Administrator input his/her password.

5.   Store the user’s password in variable userPassword.

 

6.   The system checks whether the user is the Administrator.

 

7.   The system gives the administrator notification that he/she can start using the system.

8.   The Adminstrator connects the system to the network.

9.   The system gets connection through the network and make other users able to access the system.

 

10. Indicates Start Up success.

 

 

 

Alternatif Courses

Line 6

Invalid username and password for adminstrator entered. Indicate error.

Line 9

Network down and cannot be accessed. Indicate error.

 

 

 

 

 

 

 

 

 

 

Typical Course of Events – Shut Down

Actor Action

System Response

1.   The Administrator chooses an option to shut down the system.

 

2.   The Administrator reinput his/her user’s name.

3.   Store the user’s name in variable userName.

4.   The Administrator reinput his/her password.

5.   Store the user’s password in variable userPassword.

 

6.   The system checks whether the user is the Administrator.

 

7.   Determine no important application(s) still processing in the system.

 

8.   The system asks the administrator to reconfirm shutting down the system.

9.   The Adminstrator makes a confirmation that he/she wants to shut down the system.

10. The system was shutted down.

 

 

 

Alternatif Courses

Line 6

Invalid username and password for adminstrator entered. Indicate error.

Line 7

If there is/are important application(s) still in process. Give options to the administrator to wait or terminate the process.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Use Case: Manage Files

Actors

Administrator.

Purpose

To manage the files in the system hardisk.

Overview

The Administrator manage the files by creating, modifying, deleting files, changing the files status to make the files accessible by the group members or everyone in the world.

Type

Primary and essential

Note

This feature available for Administrator after he/she has logged in to the system.

 

 

 

Typical Course of Events

Actor Action

System Response

1.   The Administrator chooses an option to create / modifying / delete files / changing files status.

2.   The system read the administrator’s option and ready to invoke the option’s command.

3.   The Administrator assigns target for that the option he/she has chosen.

4.   The system invokes the option’s command (to create / modiying / delete / changing file(s) status.

 

5.    Indicate action success.

 

 

 

Alternatif Courses

Line 4

If the target file has an important constraint integrity with another file in the system. Indicate error.

 

 

 

 

 

 

 

 

 

 

 

 

 


Use Case: Create / Remove Account

Actors

Administrator.

Purpose

To create user account  in the system and remove the existing account.

Overview

The Administrator creates new account that hasn’t existed in the system and removes the existing account in the system.

Type

Primary and essential

Note

This feature available for Administrator after he/she has logged in to the system.

 

 

 

 

Typical Course of Events – Create Account

Actor Action

System Response

1.   The Administrator chooses an option to create a new account for a new user.

2.   The system read the administrator’s option and ready to invoke the option’s command.

3.   The Administrator assigns new user name and password and user type (instructor/student) for the new user.

4.    Determine that the new user that input by the administrator is not existed in the system.

 

5.    Create an account for the new user.

 

6.    Indicate that the account has been created.

 

 

 

Alternatif Courses

Line 4

The user name has already existed in the system. Indicate error.

 

 

 

 

 

 

Typical Course of Events – Remove Account

Actor Action

System Response

1.   The Administrator chooses an option to remove an existing account in the system.

2.   The system read the administrator’s option and ready to invoke the option’s command.

3.   The Administrator input new user name and user type (instructor/student) for that exists in the system.

4.    Determine that the user is existed in the system.

 

5.    Display all the user information including the courses and sections that he/she has.

 

6.    Ask the administrator deletion confirmation.

7.   The administrator confirm for that user target.

8.    Remove the account from the system and the courses & sections that relate with him/her.

 

9.    Indicate that the account has been removed.

 

Additional Note:

 

 

Alternatif Courses

Line 4

The user name is not existed in the system. Indicate error.