Google Search

Friday, April 1, 2011

COURSE REGISTRATION SYSTEM


COURSE REGISTRATION SYSTEM

Problem Statement

            As the Head of Information Technology for Rajalakshmi Engineering College you are tasked with developing a new students registration system. The college would like a new client-server system to replace its much older system. The new system will allow students to register for courses and view report cards from personal computers attached to the campus LAN. Professors will be able to access the system. To sign up to teach courses as well as record grades.

            At the beginning of each semester, students may request a course catalogue containing list course offerings for the semester. Information about each course, such as professor, department and prerequisites, will be included to help students make information decisions.

            The new system will allow students to select four course offerings for the coming semester. Course offerings will have a maximum of ten students and minimum of three students. A course offering with fewer than 3 students will be cancelled. If a course is cancelled, the students will be intimated and they will be requested to change their course choices.

            At the end of the semester, the students will be able to access the system to view an electronic report card. Since student grades are sensitive information, the system must employ extra security measures to prevent unauthorized access.

            Professors must able to access the online system to indicate which courses will be teaching. They will need to see which students signed up for their course offerings. In addition, the professors will be able to record the Grades for the students in each class.


2. LOGIN

2.1Brief Description

The use case describes how a user logs into the Course Registration System.

2.2 Flow of Events

2.2.1 Basic Flow

This use case starts when the user wishes to Login to the Course Registration System
1. The System requests that the user enter his/her name and password
2. The user enters his/her name and password
3. The System validates the entered name and password and logs the user into the System

2.2.2Alternative Flows

Invalid Name/Password
If, in the Basic flow, the user enters an invalid name and/or password, the system displays an error message. The user chooses to either return to the beginning of the Basic flow or cancel the login, at which point the use case ends.

2.3Special Requirements

None

2.4Pre-Conditions

None

2.5Post-Conditions

If the use case was successful, the user is now logged into the system. If not, the System State is unchanged.

2.6Extension Points

None

3. Maintain Professor Information

3.1 Brief Description

             This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying and deleting professors from the system.

3.2 Flow of Events

3.2.1 Basic Flow

      This use case starts when the Registrar wishes to add, change, and /or delete professor information in the system.

  1. The system requests that the Registrar specify the function he/she would like to perform (either Add a Professor, Update a Professor, Or Delete a Professor)
  2. Once the Registrar provides the requested information, one of the sub flows is executed.
If the Registrar selected “Add a professor “, the Add a Professor sub flow is executed.
If the Registrar selected “Update a professor “, the Update a Professor sub flow is executed.
If the Registrar selected “Delete a professor “, the Delete a Professor sub flow is executed.

3.2.1.1 Add a Professor

The system requests that the Registrar enter the professor information. This includes: - name
-         Department

1.      Once the Registrar provides the requested information, the system generates and assigns a unique id number to the professor. The professor is added to the system.
2.      The system provides the Registrar with the new professor id

3.2.1.2 Update a Professor

  1. The system requests that the Registrar enter the professor id
  2. The Registrar enters the professor id. The system retrieves and displays the professor information.
  3. The Registrar makes the desired changes to the professor information. This includes any of the information specified in the Add a Professor sub-flow
  4. Once the Registrar updates the necessary information, the system updates the professor record.

3.2.1.3 Delete a Professor

1.      The system requires that the Registrar enter the professor id
2.      The Registrar enters the professor id. The system retrieves and displays the professor information.
3.      The system prompts the Registrar to confirm the deletion of the professor.
4.      The Registrar verifies the deletion.
5.      The system deletes the professor from the system.

3.2.2 Alternative Flows

3.2.2.1 Professor Not Found

If, in the Update a Professor or Delete Professor sub-flows, a professor with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends.

3.2.2.2 Delete Cancelled

        If, in the Delete A Professor sub-flow, the Registrar decides not to delete the professor, the delete is cancelled, and the Basic Flow is re-started at the beginning.

3.3 Special Requirements

None.

 

3.4 Pre-conditions


          The Registrar must be logged onto the system before this use case begins.
3.5 Post-conditions

If the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.

3.6 Extension Points

       None

4. Maintain Student Information

4.1 Brief Description

             This use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying and deleting students from the system.

4.2 Flow of Events

4.2.1 Basic Flow

      This use case starts when the Registrar wishes to add, change, and /or delete student information in the system.

1. The system requests that the Registrar specify the function he/she would like to perform (either Add a Student, Update a Student, Or Delete a Student)
2. Once the Registrar provides the requested information, one of the sub flows is executed.
If the Registrar selected “Add a student “, the Add a Student sub flow is executed.
If the Registrar selected “Update a student “, the Update a Student sub flow is executed.
If the Registrar selected “Delete a student “, the Delete a Student sub flow is executed.

4.2.1.1 Add a Student

  1. The system requests that the Registrar enter the student information. This includes: - name
-         Department

    2. Once the Registrar provides the requested information, the system generates and assigns a unique id number   to the student. The student is added to the system.
    3. The system provides the Registrar with the new student id
4.2.1.2 Update a Student
1.      The system requests that the Registrar enter the student id
2.      The Registrar enters the student id. The system retrieves and displays the student information.
3.      The Registrar makes the desired changes to the student information. This includes any of the information specified in the Add a Student sub-flow
4.      Once the Registrar updates the necessary information, the system updates the student record.

4.2.1.3 Delete a Student

1.      The system requires that the Registrar enter the student id
2.      The Registrar enters the student id. The system retrieves and displays the student information.
3.      The system prompts the Registrar to confirm the deletion of the student.
4.      The Registrar verifies the deletion.
5.      The system deletes the student from the system.

4.2.2 Alternative Flows

4.2.2.1 Student Not Found

              If, in the Update a Student or Delete a Student sub-flows, a student with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends.

4.2.2.2 Delete Cancelled

        If, in the Delete A Student sub-flow, the Registrar decides not to delete the student, the delete is cancelled, and the Basic Flow is re-started at the beginning.

4.3 Special Requirements

None.

4.4 Pre-conditions

          The Registrar must be logged onto the system before this use case begins.

4.5 Post-conditions

If the use case was successful, the student information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.

4.6 Extension Points

      None
5. Register For Courses

5.1 Brief Description

This use case allows a student to register for course offering in the current semester. The Student can also update or delete course selection if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the Course offerings for the current semester.

5.2 Flow of Events.

5.2.1 Basic Flow

This use case starts when a Students wishes to register for course offerings, or to change his/her existing course list.

1. The system requests that the students specify the function he/she would like to perform (either add a Course, Modify the Course list). Once the Students provide the requested information, one of the sub flows is executed.
If the Student Selected “Add a Course”. The Add a Course sub flow is executed.
If the Student Selected “Modify the Course List”. The Modify the Course List sub flow is executed

5.2.1.1  Adding a Course

1.      The system retrieves a list of available course offering from the Course Catalog System and displays the list to the Student.
2.      The Student selects 4 primary course offering and 2 alternate course offerings from the list of available offerings
3.      Once the student has made his/her selections, the system creates a list for the Student containing the selected course offerings.
4.      The submit Form sub flow is executed

5.2.1.2 Modify the Course List

1.      The system retrieves and displays the student’s current Course list( e.g. , the course list for the current semester)
2.      The system retrieves a list of available course offering from the Course Catalog System and displays the list to the students
3.      The Student may update the course selection on the current selection by deleting and adding new course offerings. The students select the course offerings to add from the list of available course offering. The students also selects any course offerings to delete from the existing schedule
4.      Once the student has made his/her selection , the system modify the schedule for the students using the selected course offerings
5.      The Submit list sub flow is executed

5.2.1.2  Submit List

For each selected course offering on the list not already marked as “enrolled I ‘ the system verifies that the Student has the necessary prerequisites, that the course offering is open, and that there are no schedule conflicts. The system then adds the student to the selected course offering. The course offering the schedule is saved in the system.

5.2.2 Alternative Flows.

5.2.2.1 No Schedule Found

If, in the Modify the   Course list sub flow, the system is unable to retrieve the student’s schedule, an error message is displayed. The Students acknowledges the error, and the Basic Flow is restated at the beginning.

5.2.2.2 Course Catalog System Unavailable

If the system is unable to communicate with the Course Catalog System, the system will display an error message to the student. The Student acknowledges the error message, and the case terminates.

5.2.2.3 Course Registration Closed

When the use case starts, if it is determined that registration for the current semester has been closed, a message is displayed to the Student, and the use case terminates. Students cannot register for course offerings after registration for the current semester has been closed.

5.3 Special Requirements.

None

5.4 Pre-Conditions

The Student must be logged onto the system before this use case begins.

6. Select Courses to Teach

6.1 Brief Description

       This use case allows selecting the course offerings from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.

6.2 Flow of Events

6.2.1 Basic Flow

         This use case starts when a professor wishes to sign up to teach some course offerings for the upcoming semester.
1.      The system retrieves and displays the list of course offerings to the professor. The system also retrieves and displays the list of courses the professor has previously selected to teach.
2.      The professor selects and/or deselects the course offerings that he/she wishes to teach for the upcoming semester.

6.2.2 Alternative Flows

6.2.2.1 No Course Offerings Available

            If in the basic flow, the professor is not eligible to teach any course offerings in the upcoming semester, the system will display an error message. The professor acknowledges the message band the use case ends.

6.2.2.2 Course Catalog System Unavailable

           If the system is unable to communicate with the Course Catalog  System, the system will display an error message to the student. The student acknowledges the error message and the use case terminates.

6.3 Special Requirements

       None

6.4 Pre-Conditions

      The professor must be logged on to the system before this use case begins.

6.5 Post-Condition

       If the use case was successful, the course offerings a professor is scheduled to teach should have been updated.

6.6 Extension Points

None

7. Submit Grades

 7.1 Brief Description

                  This use case allows a professor to submit student grades for one or more classes completed in the previous semester.

7.2 Flow of Events

7.2.1 Basic Flow

               This use case starts when a professor wishes to submit grades for one or more classes completed in the previous semester.
1.      The system displays a list of course offerings the professor taught in the previous semester.
2.      The professor selects a course offering
3.      The system retrieves a list of all the students who were registered the course offering. The system displays each student and any grade that was previously assigned for the offering.
4.      For each student on the list, the professor enters the grade: A, B, C, D, F, I. The system records the student’s grade for the course offering. If the professor wishes to skip a particular student, the grade information can be left blank and filled in at later time. The professor may also change grades for a student by entering a new grade.

7.2.2 Alternative Flows

 

7.2.2.1 No course offerings thought


               If in the basic flow, the professor did not teach, any course offerings in the previous semester, the system will display an error message. The professor acknowledges the use case and the use case ends.

7.3 Special Requirements

None

 

7.4 Pre-conditions


             The professor must be logged on to the system before this use case begins

7.5 Post-Conditions

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

7.6 Extension Points

          None

8. View Report Card

8.1    Brief Description

                  This use case allows a student to view his/her report card for the previously completed semester.

8.2    Flow of Events

8.2.1        Basic Flow

               This use case starts when a student wishes to view his/her report card for the previous semester.

1.The system retrieves and displays the grade information for each of the course offerings the student completed during the previous semester.
2.      When the student indicates that he/she is done viewing the grades the use case terminates.

8.2.2        Alternative Flows

8.2.2.1  No grade information available

               If in the basic flow, the system cannot find the any grade information from the previous semester for the student, a message is displayed. Once the student acknowledges the message, the use case terminates.

8.3    Pre-conditions

             The student must be logged on to the system before this use case begins

8.4     Post-Conditions

The system state is unchanged by this use case.

 8.5 Extension Points
      
   None

Course Registration System Glossary

1.Intrdouction

            This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use – case description or
Other project documents. Often this document can be used as an informal data directory,
Capturing data definitions so that use – case descriptions and other project documents can
Focus on what the system must do with the information.

2.Definitions

            The glossary contains the working definition for the key concepts in the course registration system.

2.1.Course
            A class offered by the university

2.2 Course Offering

            A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it offered.

2.3 Course Catalog

            The unabridged catalog of all courses offered by the university.

2.4 Faculty

            All the professors teaching at the university

2.5 Finance System

      The system used for processing billing information.

2.6 Grade

      The evaluation of a particular student for a particular course offering.

2.7 Professor

       A person teaching class at the university.

2.8 Report Card

      All the grades for all courses taken by a student in a given semester.

2.9 Roster

     All the students enrolled in a particular course offering.

2.10 Student

        A person enrolled in a class at the university.

Course Registration System Supplementary Specification

1. Objectives

The purpose of this document is to define requirements of the Course Registration System. This Supplementary Specification lists the requirements that are not readily captured in the use cases of the use case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system.

2. Scope

This Supplementary Specification applies to Course Registration System, which will be developed by the OOAD students.
This Specification defines the non-functional requirements of the system; such as reliability, usability, performance, and supportability, as well as functional requirements that are common across a number of use cases.

3. References

None

4. Functionality

Multiple users must be able to perform their work concurrently If a course offering becomes full while a student is building a schedule include that offering, the student must be notified.

5. Usability

The desktop user-interface shall be Windows 95/98/2000/xp compliant.

6. Reliability

The System shall be available 24 hours a day 7 days a week, with no more than 10% down time.

7. Performance

1. The System shall support up to 1000 simultaneous users against the central database at any given time and up to 500 simultaneous users against the local servers at any one time.
2. The System must be able to complete 80% of all transactions within 2 minutes.

8. Supportability

None.

9. Security

1.The System should prevent students from changing any schedules other than their own, and professors from modifying assigned course offerings for other professors.
  1. Only Professors can enter grades for students.
  2. Only the Registrar is allowed to change any student information.

10. Design Constraints.

The system shall integrate with an existing legacy system, the Course catalog system, which is an RDBMS database.
The system shall provide a window-based desktop interface.

Use case diagram for Course Registration System:



0 comments:

Post a Comment