0% found this document useful (0 votes)
17 views

Software Requirements Specification

The document provides a software requirements specification for a school registration service. It describes the system environment which includes admin and student actors. It then outlines four key use cases - adding a student, viewing a schedule, adding a course, and dropping a course. Non-functional requirements around performance, security, and browser compatibility are also defined. Finally, database details are provided including a logical diagram and descriptions of tables for courses, enrollments, and students.

Uploaded by

api-594670325
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views

Software Requirements Specification

The document provides a software requirements specification for a school registration service. It describes the system environment which includes admin and student actors. It then outlines four key use cases - adding a student, viewing a schedule, adding a course, and dropping a course. Non-functional requirements around performance, security, and browser compatibility are also defined. Finally, database details are provided including a logical diagram and descriptions of tables for courses, enrollments, and students.

Uploaded by

api-594670325
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Software Requirements Specification

Version 1.0

July 26, 2023

School Registration Service

Alex O’Brien

Page 1 of 7
2.1 System Environment

The School Registration Service has two active actors, Admin and Student. Admins can

add a student. Students can enroll in a course, drop a course, and view their schedule. The school

registration service also communicates back and forth with the Gradebook service to alter the

Register database when certain tasks are completed.

Page 2 of 7
3.2 Functional Requirements

3.2.1 Add Student

Use Case Name Add Student

XRef None

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

Precondition The Admin has accessed the Course Registration screen.

Basic Path 1. The Admin clicks on “Add Student”.


2. The system presents a field to add a Student name and
Student email.
3. The Admin enters the Student name and Student email and
clicks on “Add”.
4. The system make sure the student name or email is not
blank and that the email address is not already in use and
updates the database.
Alternative Paths If in step 2, either field is blank, the Admin is instructed to enter a
valid name or email.
Postcondition Student has been added to the database.

Exception Paths The Admin can click “Cancel” to end the operation at any time.

Other The Student hold status is set to 0. This indicates that the student
does not have a hold preventing them to enroll in courses.

3.2.2 View Schedule

Use Case Name View Schedule

XRef See Add Course, Drop Course

Trigger The Student selects to view their course schedule from the
database.
Precondition The Student has accessed the Course Registration screen.

Basic Path 1. The system presents options to select the term consisting of
year and semester.
2. The Student clicks on “Get Schedule”.
3. The system fetches courses from the database that are
associated with the Student.

Page 3 of 7
Alternative Paths If in step 2, there are no courses that are associated with the
Student, no rows will be shown.
Postcondition The course schedule is shown to the Student.

Exception Paths The Student can abandon the operation at any time.

Other The course information includes Title, Section, Times, Building,


Room, and Grade.

3.2.3 Add Course

Use Case Name Add Course

XRef See Drop Course, View Schedule

Trigger The Student selects to add an enrollment to the database.

Precondition The Student has accessed the Course Registration screen.

Basic Path 1. The Student clicks on “Add Course”.


2. The system provides a text are for the Student to enter a
course id.
3. The Student enters the course id and clicks on “Add”.
4. The system adds an enrollment entry to the database which
includes the Student and Course.
Alternative Paths If in step 3, the course id is invalid, or the student has a hold on
their account, the system notifies the Student and they are unable to
add the course.
Postcondition The course is added to the Student schedule and an enrollment
entry is added to the database.
Exception Paths The Student can abandon the operation at any time.

Other After adding a Course, the Course will be displayed when the
Student views their schedule for that term.

3.2.4 Drop Course

Use Case Name Drop Course

XRef See Add Course, View Schedule

Page 4 of 7
Trigger The Student selects to drop an enrollment from the database.

Precondition The Student has accessed their schedule and is viewing the term
that is associated with the course they would like to drop.
Basic Path 1. The Student clicks on “Drop”.
2. The system confirms with the Student that they would like
to drop the course.
3. The Student confirms with the system.
4. The system removes the enrollment that is associated with
the Student and Course being dropped.
Alternative Paths None

Postcondition The enrollment is removed from the database indicating that the
course is dropped.
Exception Paths The Student can abandon the operation at any time.

Other After dropping a Course, the Course will not be displayed when the
Student views their schedule for that term.

3.3 Non-Functional Requirements

3.3.1 Performance

The performance of the system will depend on the workstation being used. With modern

hardware and a strong internet connection, 95% of users will not have to wait more than 3

seconds for a transaction to be completed from the moment a confirmation button is clicked.

3.3.2 Security

The server where the system is running will have its own security to prevent unauthorized

access. The database server that the system uses will be protected from unauthorized write/delete

access. The Admin and Student accounts will be protected by hashed password authentication.

3.3.3 Web Browser Requirements

Page 5 of 7
Google Chrome is fully tested and is the recommended Web Browser for the frontend

web application. The recommended Google Chrome version is the latest non-beta version

available. Google Chrome version 110 and above is highly recommended.

3.4 Database Configuration Details

3.4.1 Logical Database Diagram

3.4.2 Database Table Details

Page 6 of 7
Course
Columns Description
course_id Course ID, Primary Key
title Title
year Year
semester Semester
times Time course is offered
building Building location
room Building room number
instructor Instructor
start Start date
end End date

Enrollment
Columns Description
enrollment_id Enrollment ID, Primary Key
year Enrollment year
semester Enrollment semester
course_grade Grade of course
student_id Student ID, Foreign Key
course_id Course ID, Foreign Key

Student
Columns Description
student_id Student ID, Primary Key
name Student first and last name
email Student email
status Hold status
Binary hold status, 0 (no
status_code
hold) or 1 (hold)

Page 7 of 7

You might also like