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

Software Requirements Specification

The document provides requirements for a registration service system including: 1) An overview of the system environment with two active actors (Administrator and Student) and one cooperating system. 2) Four functional requirements (Add Student, View Schedule, Enroll Course, Drop Course) defined by use cases. 3) Two non-functional requirements related to performance and security. 4) Minimum browser specifications. 5) Logical database requirements including data entities for Courses, Enrollments, and Students.

Uploaded by

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

Software Requirements Specification

The document provides requirements for a registration service system including: 1) An overview of the system environment with two active actors (Administrator and Student) and one cooperating system. 2) Four functional requirements (Add Student, View Schedule, Enroll Course, Drop Course) defined by use cases. 3) Two non-functional requirements related to performance and security. 4) Minimum browser specifications. 5) Logical database requirements including data entities for Courses, Enrollments, and Students.

Uploaded by

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

Software Requirements Specification

Version 1.0

August 8, 2023

Registration Service

Angela Cheng

Submitted in partial fulfillment


Of the requirements of
CS 438-40 Software Engineering
2.0. Overall Description

2.1. System Environment

(Figure 1 - System Environment)

The Register Service System (fig.1) has two active actors and one cooperating

system. The Administrator and Student, integral components of the system, actively

interact with its functionalities and access the entire system directly. This dynamic

2
interaction enables seamless management and utilization of the course registration

process. The cooperating system complements their actions, supporting

behind-the-scenes processes that contribute to the system's overall functionality and

effectiveness.

3.0. Requirements Specification

3.2. Functional Requirements

Functional requirements define the fundamental actions that must take place in

the software in accepting and processing the inputs and in processing and generating the

outputs. The following four functional requirements are for registration service.

3.2.1. Add Student

Use Case Name Add Student

XRef AddStudent.js - frontend

Trigger The Administrator selects to add a student to the database.

Precondition The Administrator has accessed the Student Roster main


screen.

Basic Path 1. The system presents the Add Student page.


2. The Administrator enters the student information,
including name and email address, and submits the form
by clicking the Submit button.
3. The system checks that the name and email address
fields are not blank and updates the database.

Alternative If in step 2, either field is blank, the Administrator is


Paths instructed to add an entry. No validation for correctness is
made.

Postcondition The Student has been added to the database.

Exception Paths The Administration may abandon the operation at any


time.

Other The student information includes name and email address.

3
3.2.2. View Schedule

Use Case Name View Schedule

XRef SchedList.js - frontend

Trigger The Student has selected to view the status of the course
schedule.

Precondition The Student has accessed the Schedule main screen.

Basic Path 1. The system creates and presents a list of all active
course on the Student’s schedule.
2. The Student may request to Enroll Course to the
schedule or Drop Course from the schedule.

Alternative None.
Paths

Postcondition The requested information has been displayed.

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

Other None.

3.2.3. Enroll Course

Use Case Name Enroll Course

XRef AddCourse.js - front end

Trigger The Student has selected to enroll the course.

Precondition The Student has accessed the Add Course main screen.

Basic Path 1. The system access the db_register database.


2. The Student enters the course ID and submits the form
by clicking the Add button.
3. The system checks that the course ID is valid and
updates the database.

Alternative If in step 2, the course ID is invalid, the system will display


Paths the error message and the Student will need to resubmit a
new request.

Postcondition The Course has been added to the Student’s schedule on

4
the database.

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

Other The course information includes course ID.

3.2.4. Drop Course

Use Case Name Drop Couse

XRef AddCourse.js - frontend

Trigger The Student has selected to drop the course.

Precondition The Student has accessed the Schedule main screen (which
is the page to drop the course).

Basic Path 1. The system presents the course list on the Videw
Schedule main screen.
2. The Student clicks on the Drop button next to the course
the Student intended to drop.
3. The system verifies the action and updates the database.

Alternative None.
Paths

Postcondition The Course has been dropped from the Student’s schedule
on the database.

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

Other The course information includes course ID.

3.3. Non-Functional Requirements

The non-functinal requirements specify both the static and the dynamic numerical

requirements placed on the software or on human interaction with the software, as a

whole.

3.3.1. Performance

5
Non-functional performance requirements pertain to the system's ability to

meet certain performance criteria beyond its core functionality. These criteria

encompass aspects such as response time, scalability, and throughput. Ensuring

optimal performance guarantees that the system can handle varying loads

efficiently, maintains responsiveness, and accommodates growth without

compromising user experience or system stability. For example, 95% of the

registration activity shall be processed in less than 1 second.

3.3.2. Security

The server on which the Online System resides will have its own security

to prevent unauthorised write/deliete access. There is no restriction on read

access. Both Administrator and Student will have the read access to view the

status of the database.

3.3.3. Minimum Browser Specifications

The minimum specifications to the front end of this service includes: 1)

Browser: Google Chrome, and 2) Minimum Version: 115.0.5790.166. The

recommended specifications to the front end of this service is 1) Browser: Google

Chrome, and 2) Version: 115.0.5790.170.

3.4. Logical Database Requirements

The logical database requirements specify the logical requirements for any

information that is to be placed into the database. The logical structure of the data to be

stored in the database is given below.

6
The data descriptions of each of these data entities is as follows:

Course Data Entity

Data Item Type Description Comment

course_id int Course ID

year int The year of the course

semester string The semester of the course

section int The section of the course

title string The title of the course

times string The time of the course

building string The building of the course

room string The room of the course

instructor string The instructor of the course

start date The start date

7
end date The end date

Enrollment Data Entity

Data Item Type Description Comment

enrollment_id int The enrollment ID

student_id pointer (int) Student ID - Join column from


Student data entity.

course_id pointer (int) Course ID - Join column from


Course data entity.
year pointer (int) The year of the course

semester pointer The semester of the course


(string)

courseGrade pointer The grade of the course


(string)

Student Data Entity

Data Item Type Description Comment

student_id int Student ID

name string The name of the student

email string The email of the student

statusCode int The status code of the


student

status string The status of the student


(hold or no hold)

You might also like