CST-438 Registration Service

Janet Pham

Software Requirements Specification

Abbreviated Document

Version: 1.0 Date: 08/08/2023

2.1 UML System Environment

The system consists of two services with three main roles involved. Students have the
ability to add or drop courses, while admins possess addition privileges to manage
student records and handle assignments and grades. The communication between these
services is facilitated through a message queue. Notably, when students enroll in a
course, this enrollment information is seamlessly integrated to gradebook service,
ensuring enrollment table is updated accurately.
3.2 Functional Requirements
3.2.1 Adminstrator Use Case

Use Case Name Add Student

XRef

Trigger The Admin selects Add Student button

Precondition The Admin has to be signed in and on the index page

Basic Path 1. Admin clicks on the Add Student button

2. Frontend presents admin with add student dialog box
3. Admin enters valid student email and name
4. System checks for whether or not the student is in the
database
5. If student was not found, system adds the student and
if student was found, system returns message for found
student.
6. Present a success toast message to Admin

Alternative Paths If in step 3, both field is blank, an error toast message will be
presented

Postcondition The Student has been added and a success toast message is
displayed

Exception Paths Admin may cancel adding new student

Other

3.2.2 View Student Schedule

Use Case Name Student Views Schedule

XRef

Trigger The Student selects radio button for a specific semester and
presses Get Schedule

Precondition The Student has to be signed in and enrolled in the courses for
the semester

Basic Path 1. Students select the radio button for the semester they
are trying to view
 2. Then press Get Schedule
3. The system will get the records of all the courses the
student is enrolled in for that selected semester.

Alternative Paths

Postcondition The Students are presented with the schedule

Exception Paths The Student may not click get schedule

Other The schedule may be empty if the student is not enrolled in

any courses

3.2.3 Enroll Student Into Course

Use Case Name Student Enrolls in a Course

XRef See 3.2.2 View Student Schedule

Trigger The Students select a radio button for a specific semester and
select Get Schedule

Precondition The Student has to be signed in and has no holds for

registration

Basic Path 1. Student gets schedule for a specific semester that they
are cleared to enroll for
2. Student click on Add Course button
3. Student enter valid Course ID
4. Student click on Add button
5. On success, student is presented with success toast
message, the dialog then closes
6. Course has been enrolled

Alternative Paths If in step 3, students enter incorrect or invalid Course ID, an

error toast message will appear.

Postcondition The Students are presented with their schedule

Exception Paths The Student may not click Get Schedule

The Students may select a semester they are not cleared to
enroll in/on hold.

Other
3.2.4 Drop Student’s Course

Use Case Name Student Drops a Course

XRef See 3.2.2 View Student Schedule and 3.2.3 Enroll Student Into
Course

Trigger The Student clicks on the Drop button next to a course

Precondition The Students have to be signed in and are enrolled in courses.

Basic Path 1. Students click the View Schedule button for a valid
semester they can drop classes from
2. Students then click the Drop button next to a course
3. Students are then prompted to click Cancel/Ok to
confirm whether or not they want to drop the course.
4. A success toast message will be displayed upon success

Alternative Paths In step 3, student may click cancel to not drop the course

Postcondition The Students are presented with their schedule without the
course that was dropped

Exception Paths The Students may not click Get Schedule.

The Sutdents may select a semester they are not cleared to
drop course from.

Other If drop data has alread passed, students may not be able to
drop courses.
3.3 Non-Functional Requirements

3.3.1 Performance
To ensure optimal performance, the frontend and backend services should have multiple
instances distributed across multiple servers and be equipped with a load balancer to efficiently
handle traffic. The application must be designed to handle thousands of simultaneous requests,
especially during peak times like class registration when numerous students have access to the
services. Caching mechanisms can be employed to store frequently accessed data, reducing the
need to fetch the same information repeatedly.

3.3.2 Security
The registration backend must comply with stringent security measures including restring
access to API endpoints to only authorized users and allowing administrative actions only for
authenticated users/admins. Robust user authentication should implemented to guard against
unauthorized attack vectors like SQL injection and cross-site scripting. Additionally, all
communcations between the client and server should be encrypted using HTTPS, and a
comprehensive logging systems must be in place for auditing and debugging purposes.

3.3.3 Browsers and Minimum Versions

The frontend of this service is built using React and is designed and tested to work seamlessly
on modern mobile and desktop browsers with touch and mouse keyboard interactions. The
frontend is optimized to provide smooth and intuitive navigation and interactions, irrespective
of the device’s input method. Compatibility was taken into account for various modern
browsers, and the minimum versions required to ensure proper functioning were defined. The
known support browsers and their minimum versions are as follows:
● Google Chrome: Version 80 and above
● Mozilla Firefox: Version 72 and above
● Apple Safari: Version 13 and above
● Microsoft Edge: Version 80 and above
3.4 Logical database diagram and accompanying details on tables, keys, and
attributes
3.4.1 Registration Database
3.4.2 Student Data Table

Data Item Data Type Description Comment

student_id int Unique id for student

name varchar(255) Name of student

email varchar(255) Student email

status varchar(255) Hold type and reason

status_code int Integer code associated with

hold type

3.4.3 Course Data Table

Data Item Data Type Description Comment

course_id int Unique id for course

year int Year of semester

semester varchar(10) Semester Fall, winter, spring,

summer

section int Course section Allows for multiple

instances of a course

title varchar(255) Name of the course

times varchar(50) Time and Day the course is

being taught at.

building varchar(20) Building the course is

located at

room varchar(20) Room the course is at within

the building

instructor varchar(50) Instructor teaching the

course

start date Start date of course

end date End date of course

3.4.4 Enrollment Data Table

Data Item Data Type Description Comment

enrollment_id int Unique id for a specific

students enrollment in the
course

student_id int Unique id for student Foreign key from

student table

course_id int Unique id for course Foreign key from

course table

year int Year of semester

semester varchar(10) semester

course_grade varchar(255) Student grade Grade reported from

gradebook