Software Requirements Specification

Registration Service
Version 1.0

Myles Lopez

CST 438 Software Engineering

Spring 2023
1.0 - Introduction
1.0.1 - Overview:

This report covers a project foundation for administrators and students to interact with a

database storing data consisting of registration records. The scope of this specification focuses on

the addition of students to a registry as well as the enrollment of those students into courses. The

database described in this specification does also cover columns within tables which are defined

for further specifications that exceed the functional requirements, but are included for assumed

use in other software requirements specifications. There is included diagrams describing in

further detail the specifications in conjunction with explanations, functional and non-functional

requirements. This Registration Service is assumed to be linked to a Gradebook Service through

some controllers.

Version 1.0 April 18, 2023 Lopez, 1

2.1 – System Environment
2.1.1 – UML Diagram:

2.1.2 – UML Diagram Explanation:

The diagram above provides a visual representation of the functionality the created

service currently provides. The Registration Service has two actors and one database connection.

The actor of Student is able to enroll in courses, drop courses, and view all courses they are

currently enrolled in. The Administrator actor is able to add students to the database. When a

Student enrolls in a course, data from the Registration Database is the passed to the Gradebook

Service and stored in the Gradebook database. The data that is sent to the Gradebook Service is

the course ID and student ID from the Registration database. If faulty information is used in the

case of enrolling in a course, there is an output error generated by the Registration Service; The

Version 1.0 April 18, 2023 Lopez, 2

same result is given in the case of inputting faulty data when dropping a course or adding a new

student to the system. Each case of enrolling in a course, adding a student to the database, and

viewing all current enrolled courses, call a case of finding a student by their unique email value.

When we look at the Gradebook Service actor that is receiving data from the Registration

Service, there is data being passed between the databases as well. For the Gradebook Service,

there is implied cases with which that service interacts with the database tables described in

section 3.4 of this specification. It is also important to note that in the UML diagram there are

other functions within the cases illustrated. Those functions are not illustrated because they are

imported from libraries that are not created within the Registration Service described here.

3.2 – Functional Requirements

It is important to note that when referencing any element from section 3.4, I am implying

that the functional services is directly interacting with that table from the database described in

section 3.4.

3.2.1 – UML Base Cases:

Use Case Name View Scheduled Courses

XRef Find Student by Email (3.2.2), Enrollment (3.4)

Trigger The student clicks the button “Get Schedule”.

Precondition The student has accessed the main page and selected a semester and year.
1. The system presents the homepage and a grid of semesters with years.

Basic Path 2. The student selects which semester and year they want.

3. The student then clicks the “Get Schedule” button.

Alternative Paths Step 2. The student does not have to select an option, one is already

Version 1.0 April 18, 2023 Lopez, 3

 preselected when the page is loaded.
The webpage containing the courses for which the student is/was enrolled
in for that semester and year are displayed.
Postcondition
URL addition from homepage is “/schedule”.
Exception Paths The student does not have to click the button, or closes the webpage.
The data is selected from the enrollment table and their email is verified
Other
under the Find Student by Email.

Use Case Name Enroll In A Course

Output Error (3.2.2), Find Student by Email (3.2.3), Enrollment (3.4),
XRef
Student (3.4)
Trigger Student clicks the “Add Course” button.
Precondition The student has navigated to the schedule page.
1. The system presents the homepage and a grid of semesters with years.

2. The student selects which semester and year they want.

Basic Path 3. Student clicks on the “Add Course” button.

4. Student fills in the course number in the pop-up window.

5. Student clicks the “Add” button.

Step 2: student does not select the semester, one is already loaded as a
Alternative Paths
preset.
Message is displayed at the bottom indicating student has been added to
Postcondition
the course. Course is displayed on page under the schedule.
Student may click “Cancel” button instead of Add.
Exception Paths
If the Student inputs incorrect information and receives error message
instead of added course message as postcondition.
The student is able to add any courses that are able to be enrolled in them
Other
as long as they do not have any registration holds.

Use Case Name Drop A Course

XRef Output Error (3.2.2), Enrollment (3.4)

Trigger Student clicks the “Drop” button

Precondition The student has navigated to the schedule page and is enrolled in at least

Version 1.0 April 18, 2023 Lopez, 4

 one class for that term.
1. The system presents the homepage and a grid of semesters with years.

Basic Path 2. The student selects which semester and year they want.

3. Student clicks on the “Drop” button.

Step 2: student does not select the semester, one is already loaded as a
Alternative Paths
preset.
Student receives a message stating the course has been dropped. The term
Postcondition
then deletes the course from the page the Student is viewing.
The Student may stop the process at any step before clicking the “Drop”
button.
Exception Paths
If the student has already completed the class then an error message will
appear when attempting to drop the class.
The data in the Gradebook Service is also updated along with the database
Other
for this service.

Use Case Name Add Student To System

XRef Output Error (3.2.2), Find Student By Email (3.2.3), Student (3.4)

Trigger Administrator clicks on the “Add Student” Button.

Precondition The student has navigated to the Student page or the home page.
1. The system has loaded the home page.

2. The Administrator clicks on the “Add Student” button.

Basic Path
3. The Administrator fills out the “Student Name” and “Student Email”
Field.

4. The Administrator clicks the “Add” Button.

Between step 1 and 2, the Administrator clicks on the “Student Page”
Alternative Paths
button.
Postcondition The system outputs a message stating the student was successfully added.
The Administrator may click the “Cancel” button instead of the “Add”
Button.
Exception Paths
If the student email is not unique it will return an error message.
Other Only the Administrator is capable of adding students to the database.

Version 1.0 April 18, 2023 Lopez, 5

3.2.2 – UML Extended Case:

Use Case Name Output Error

XRef Student (3.4)

Trigger Student or Administrator inputs faulty data

Precondition Database contains conflicting data with input
1. The system has loaded the home page.

2. The Administrator clicks on the “Add Student” button.

3. The Administrator fills out the “Student Name” and “Student Email”
Basic Path
Field.

4. The information in “Student Email” already exists in the database.

5. The Administrator clicks the “Add” Button.

Step 1. The Student navigates to the Schedule page.

2. The student clicks the button “Add Course”.

3. The Student inputs a course number that does not exist in the database

4. The student clicks the button “Add”

OR
Alternative Paths
Step 2. The Student clicks the “Get Schedule” button.

3. The Student repeats step 1 and 2 on a separate window.

4. The student clicks “Drop” button.

5. The Student clicks “Drop” button on second window for already

dropped course.
Postcondition The system outputs a message displaying an error.
The Student or Administrator inputs correct data described in section
Exception Paths
3.2.1.
Other The error does not alter any information in the database.

Version 1.0 April 18, 2023 Lopez, 6

3.2.3 – UML Included Cases:

Use Case Name Find Student By Email

Add Student To System (3.2.1), Enroll In A Course (3.2.1), View
XRef
Scheduled Courses (3.2.1), Student (3.4), Course (3.4)
The Student or Administrator follows cases Add Student To System
Trigger
(3.2.1), Enroll In A Course (3.2.1), or View Scheduled Courses (3.2.1)
Precondition The Student or Administrator has logged into the service
1. The system presents the homepage.

2. The student selects which semester and year they want.

Basic Path 3. Student clicks on the “Add Course” button.

4. Student fills in the course number in the pop-up window.

5. Student clicks the “Add” button.

Step 2. The student selects which semester and year they want.

3. The student then clicks the “Get Schedule” button.

OR
Alternative Paths
Step 2. The Administrator clicks on the “Add Student” button.

3. The Administrator fills out the “Student Name” and “Student Email”
Field.

4. The Administrator clicks the “Add” Button.

The system runs the function “Find Student By Email” and returns a row
Postcondition
from the Student table in the database.
The Student or Administrator does not click the “Add” or “Get Schedule”
Exception Paths
buttons.
This function is included when running Add Student To System (3.2.1),
Other
Enroll In A Course (3.2.1), or View Scheduled Courses (3.2.1) cases.

3.3 – Non-Functional Requirements

Version 1.0 April 18, 2023 Lopez, 7
Overview:

The Registration System can execute all of these programs rapidly since the database

architecture is quite small, requiring only a few milliseconds at most to execute a command.

Each individual using the system will be required to be logged in, if they are not then none of the

interfaces for the system will load. This is the main implemented security feature, along with the

built-in security of the Spring Boot server operating the service. To use this system a user must

be operating a Chrome browser with at version 112 installed. Other versions have not been tested

on this service, and further compatibility will require further implementation. For each actor

(Student and Administrator), each homepage and access to functions in the service will be

different, and determined by their login information.

3.4 – Database Logic

3.4.1 – Logical Database ER Diagram:

Version 1.0 April 18, 2023 Lopez, 8

3.4.2 – Logical Database ER Diagram Tables:

Course

Data Item Type Description Comment

Version 1.0 April 18, 2023 Lopez, 9

 Course ID Integer ID number for the course Unique, Primary Key
Semester Text Semester for the course, separated
by seasons
Year Integer Year for the Course
Section Integer Separate section for course if two
of same are in the same semester
Title Text Course name, includes discipline
abbreviation and number
Times Text Scheduled meeting times for
course
Building Text Building housing course Can be TBA, number
or building name
Room Text Room Number Can be empty
Instructor Text Instructor’s name
Start Date Date Date course begins
End Date Date Date course ends

Enrollment

Data Item Type Description Comment

Enrollment ID Integer ID number for specific enrollment Unique, primary key
Student ID Integer ID number for student Foreign key to
Student table. Data
sent to Gradebook
Service
Course ID Integer ID number for course Foreign key to
Course table. Data
sent to Gradebook
Service
Year Integer Year that the enrollment takes
place in
Semester Text Semester that the enrollment takes
place in
Course Grade Text Grade student receives for the Data received from
course Gradebook Service
(outside scope of this
service)

Student

Data Item Type Description Comment

Student Id Integer Unique ID for each student Auto-Incremented,
Primary Key

Version 1.0 April 18, 2023 Lopez, 10

 Name Text Student’s name
Email Text Student’s Email Unique
Registration Text Description of what registration Empty if no hold
Hold hold is for the student
Hold Status Integer Hold status number Prohibits registration
if not equal to 0

3.4.3 – Logical Database ER Diagram Explanation:

For the Diagram above it is important to note that for the Enrollment table there is only

one student ID and course ID for each row. This table acts as the intermediary with which each

student can have a specific grade for each course they are enrolled in. This grade is set to be

retrieved from a Gradebook Service that is beyond the scope of this paper. The Enrollment table

passes information to the Gradebook Service as well each time a student is enrolled in a course.

This is achieved through a REST or RabbitMQ controller within the Registration Service. The

Student table does implement a student ID as the primary key. However, throughout the service

itself, the email field of the Student table acts as the key for retrieving information from the

Student table. When looking at the table for Course, the reason why the room number can be

empty is because some courses can be held online or in the library, which eliminates the need for

that field to be filled.

Version 1.0 April 18, 2023 Lopez, 11