Software Requirements Specifications Document

CST438 Software Engineering

Team 2a - Registration
Josh Hansen

Software Requirements Specification Document

Version: 1 Date: 10/08/2021

Page 1 of 10
 Software Requirements Specifications Document

1. System Environment UML diagrams

Page 2 of 10
Software Requirements Specifications Document

Page 3 of 10
 Software Requirements Specifications Document

2. Functional requirements
2.1 Add student

Use Case Name Add Student

XRef Section 2.2, View schedule

Section 2.3, Enroll course
Section 2.4, Drop course

Trigger The Admin selects to add a new Student to the database.

Precondition The Admin has logged in using Google with an account in

the CSUMB system and has accessed the Add Student
page by clicking the “Students” button on the main
Semester page. The Admin table of the database will be
checked to verify that the user is an Admin before allowing
access to the Students page.

Page 4 of 10
 Software Requirements Specifications Document

Basic Path 1. The page presents a button to “Add Student”.

2. The Admin selects the button and is presented with a
form for name and email.
3. The Admin enters the information and submits the form.
4. The system checks that the name and email address
fields are not blank and that a Student with the same
emails does not already exist, then updates the database.

Alternative Paths In step 3, if either field is blank, or the name has less than
3 characters, or the email does not contain an ‘@’ symbol,
the respective field and the ‘Add’ button turns red and does
not allow submission until these qualifications are met. If
there is an error adding the student or if the student
already exists, an error message will be displayed on the
bottom left.

Postcondition The Student has been added to the database, and the
added student information will be displayed on the
Students page.

Exception Paths The Admin may choose “CANCEL” to exit the form at any
time.

Other The Student information displayed includes the Student ID,

email, name, hold status code, and hold status description.

2.2 View schedule

Use Case Name View schedule

XRef Section 2.3, Enroll course

Section 2.4, Drop course

Page 5 of 10
 Software Requirements Specifications Document

Trigger The Student selects “View Schedule” at the Semester

page.

Precondition The Student has logged in using Google with an account in

the CSUMB system and has chosen the correct Semester
in the populated list. The Student table of the database will
be checked to verify that the user is an Student before
allowing access to the “GET SCHEDULE” button or page,
or the API on the backend.

Basic Path 1. The Semester page presents a list of year and

semester pairs.
2. The Student selects the desired semester and clicks the
“GET SCHEDULE” button.

Alternative Paths In step 3, if either field is blank, or the name has less than
3 characters, or the email does not contain an ‘@’ symbol,
the respective field and the ‘Add’ button turns red and does
not allow submission until these qualifications are met. If
there is an error adding the student or if the student
already exists, an error message will be displayed on the
bottom left.

Postcondition The Schedule page is populated with a list of enrollments

for the Student for the chosen semester.

Exception Paths The user can close out of the webpage at any time to stop
loading the schedule.

Other The enrollment information displayed includes the course

title, section, times, building, room, and grade.

2.3 Enroll course

Page 6 of 10
 Software Requirements Specifications Document

Use Case Name Enroll course

XRef Section 2.2, View schedule

Section 2.4, Drop course

Trigger The Student selects “ADD COURSE” at the Schedule

page.

Precondition The Student has logged in using Google with an account in

the CSUMB system, has accessed the Schedule page for
a given semester. The Student table of the database will be
checked to verify that the user is an Student before
allowing access to the “Schedule” page or the enroll API on
the backend.

Basic Path 1. The Student clicks the button to “ADD COURSE”.

2. A submission form appears and the Student enters the
desired Course ID.
3. The Student selects “ADD”.

Alternative Paths If there is an error adding the course, an error message will
be displayed on the bottom left.

Postcondition The list of enrollments is updated with the newly added

course for the Student for the chosen semester.

Exception Paths The Student may choose “CANCEL” to exit the form at any
time.

Other The enrollment information for the added course, as for all
courses, includes course title, section, times, building,
room, and grade.

2.4 Drop course

Page 7 of 10
 Software Requirements Specifications Document

Use Case Name Drop course

XRef Section 2.2, View schedule

Section 2.3, Enroll course

Trigger The Student selects the “DROP” button for a populated

enrollment at the Schedule page.

Precondition The Student has logged in using Google with an account in

the CSUMB system, has accessed the Schedule page for
a given semester, and enrollments have populated. The
Student table of the database will be checked to verify that
the user is a Student before allowing access to the
“Schedule” page or to the drop API on the backend.

Basic Path 1. The Student clicks the button to “DROP”.

2. A browser popup will prompt “Are you sure you want to
drop the course?.”
3. The Student selects “OK”.

Alternative Paths If there is an error dropping the course, an error message

will be displayed on the bottom left.

Postcondition The list of enrollments is updated with the course now

removed.

Exception Paths The Student may choose “CANCEL” at the browser popup
to exit out of the flow.

Other None.

Page 8 of 10
 Software Requirements Specifications Document

3. Non-functional Requirements
3.1 Performance
The registration service shall support no more than five simultaneous users due to
database limits. When deployed in Heroku, the service should perform all database
interactions in 10 seconds or less.
3.2 Security
Google OAuth2 authentication is in place, which requires a user to login before they
may access any aspect of the registration service. Email validation with the database is
used to ensure that a user is a student or an admin before access to specific features.
This validation is performed both on backend APIs and on the provision of frontend UI
elements.
3.3 Minimum system requirements
The registration frontend runs in React through Heroku, and is supported by all popular
browsers, including Internet Explorer 9 and above, Firefox, Chrome, Edge, and Safari.
However, some polyfills are required for older browsers such as IE 9 and IE 10. Older
browsers that do not support ES5 methods are not supported.

Page 9 of 10
 Software Requirements Specifications Document

4. Logical database diagram

Page 10 of 10