Online Learning System (OLS)

Version: 1.0

Group 2 - SE1813
Phạm Cát Tường - HE171654

Group members

Supervisor Thanh
Project code OLS

– Hanoi, May 2024 –

GAMS-SRS_v1.0 Page 1 / 20
Record of Changes
Version Date A* In charge Change Description
M, D
V1.0 15/05/2024 A HungHTHE I. Overview project:
1. User Requirements:
1.1 Actors
1.2 User Case

V1.1 16/05/2024 A HungHTHE I. Overview project:

2. Overall Functionalities:
2.1 Screens Flow
2.2 Screen Descriptions
2.3 Screen Authorization
2.4 Non-UI Functions

V1.1 16/05/2024 A AnhNTHE I. Overview project:

3. System Hig h Level Design:
3.1 Database Design

V1.2 17/05/2024 M TuongPCHE171654 I. Overview project:

AnhNTHE 3. System High Level Design:
HungHTHE 3.1 Database Design

V1.2 17/05/2024 A I. Overview project:

3. System High Level Design
3.2 Code Packages

V1.3 18/05/2024 A Nang IV. Appendix:

1. Assumptions & Dependencies
2. Limitation & Exclusions
3. Business Rules

V1.4

*A - Added M - Modified D - Deleted

GAMS-SRS_v1.0 Page 2 / 20
Contents
Record of Changes.........................................................................................................................................2
I. Overview....................................................................................................................................................4
1. User Requirements.................................................................................................................................4
1.1 Actors...............................................................................................................................................4
1.2 Use Cases.........................................................................................................................................4
2. Overall Functionalities...........................................................................................................................5
2.1 Screens Flow....................................................................................................................................5
2.2 Screen Descriptions.........................................................................................................................5
2.3 Screen Authorization.......................................................................................................................5
2.4 Non-UI Functions............................................................................................................................6
3. System High Level Design....................................................................................................................6
3.1 Database Design...............................................................................................................................6
3.2 Code Packages.................................................................................................................................7
II. Requirement Specifications.......................................................................................................................8
1. <<Feature Name>>................................................................................................................................8
1.1 <<UseCaseCode_UC Name>>........................................................................................................8
2. Common Functions..............................................................................................................................11
2.1 UC-2_Login System......................................................................................................................11
3. Patron Feature......................................................................................................................................12
3.1 UC-5_Order a Meal.......................................................................................................................12
3.2 UC-6_Register for Payroll Deduction...........................................................................................13
III. Design Specifications.............................................................................................................................14
1. <<Feature Name>>..............................................................................................................................14
1.1 <<SubFeature Name>>..................................................................................................................14
1.2 System Access...............................................................................................................................15
IV. Appendix................................................................................................................................................19
1. Assumptions & Dependencies.............................................................................................................19
2. Limitations & Exclusions....................................................................................................................19
3. Business Rules.....................................................................................................................................19
4. ..............................................................................................................................................................19

GAMS-SRS_v1.0 Page 3 / 20
I. Overview
Introduction

In the era of digital transformation, online education platforms have emerged as a revolutionary way to
acquire knowledge and skills. [Website Name] is an advanced e-learning platform designed to provide
learners with a comprehensive educational experience.

We understand the importance of accessibility and convenience in modern education. Our platform is
designed to cater to the diverse needs of learners, offering a wide range of courses across various fields,
from academic subjects to professional skill development.

1. User Requirements
1.1 Actors
[An actor is a person (or sometimes another software system or a hardware device) that interacts with
the system to perform a use case. Following are some questions you might ask to help user
representatives identify actors
 Who (or what) is notified when something occurs within the system?
 Who (or what) provides information or services to the system?
 Who (or what) helps the system respond to and complete a task?
This part gives the description of system actors, you can follow the table form as below]
N
Actor Description
o
1 Guest View the course list, descriptions of each course, and try out the courses.
2 Mentee View course information, and pay to enroll in courses.
3 Mentor Confirm information about the subjects that will be taught, and check the
student's progress in the course.
4 Manager Manage the list of mentors and the list of courses.
5 Admin Confirm the list of mentors.

1.2 Use Cases

[A use case (UC) describes a sequence of interactions between a system and an external actor that
results in the actor being able to achieve some outcome of value. The names of use cases are always
written in the form of a verb followed by an object. Select strong, descriptive names to make it evident
from the name that the use case will deliver something valuable for some user]
a. Diagram(s)
[Provide the UC diagram(s) to show the actor-UCs and UC-UC relationships like the sample below. You
can have multiple UC diagrams for the system]

GAMS-SRS_v1.0 Page 4 / 20
b. Descriptions
This part describes the use cases, you can follow the table form as below]
ID Feature Use Case Use Case Description
01 Menu Operations View Menu …
02 Order Meals Order a Meal …
03 … … …

2. Overall Functionalities
2.1 Screens Flow
[This part shows the system screens and the relationship among screens. You can draw the Screens Flow
for the system in the form of diagram as below. Please note that beside the normal flat screen, we might
have the oval notation for pop-up screen (Orders Import) or a screen with multiple information tab
(Order Update), etc. You may also use text or background format for different visuality purpose]

2.2 Screen Descriptions

[Provide the descriptions for the screens in the Screens Flow above]

GAMS-SRS_v1.0 Page 5 / 20
 # Feature Screen Description
1 Order Meals Create Order <<Screen Brief description>>
2 Order Meals Change Order
3 ..

2.3 Screen Authorization

[Provide the system roles authorization to the system features (down to screens, and event to the screen
activities if applicable) in the table form as below – replace Role1, Role2,… with your specific system
user role names]
Screen Role-Name1 Role-Name2 Role-Name3 …
<<Screen Name1>> X X X
<<Screen Activity>> X X
<<Screen Name2>> X X
Query All Data X
Query Own Data X
Query Managed Data X
Add New Data X X
Update All Data X
Update Own Data X
Update Managed Data X
Delete Data
…

2.4 Non-UI Functions

[Provide the descriptions for the functions which have no UI (or not screens), i.e batch/cron job, service,
API, etc.]
# Feature System Function Description
<<Feature <<Function
1 <<Function Name1 Description>>
Name>> Name1>>
2 …

GAMS-SRS_v1.0 Page 6 / 20
3. Database Design
3.1. Database Schema

GAMS-SRS_v1.0 Page 7 / 20
 3.2. Table Descriptions
No Table Description
01 tbl_account account_id: int -PK
managed_by: int references tbl_account (account_id) -FK
role_id: int references tbl_role (role_id) -FK
email: varchar(64)
password: varchar(64)
is_active: bit
02 tbl_role role_id: int -PK
role_name: varchar(64)

03 tbl_profile profile_id: int -PK

account_id: int references tbl_account (account_id) -FK
fullname: varchar(64)
gender: bit
avatar: text
money: float

04 tbl_content_type content_type_id: int -PK

content_type_name: varchar(64)
course_id: int references tbl_course(course_id) -FK
05 tbl_course course_id: int -PK
course_name: varchar(64)
description: text
image: text
price: float
course_category_id: int references
tbl_course_category(course_category_id) -FK
created_by: int references tbl_account(account_id) -FK
is_actice: bit

06 tbl_course_categor course_category_id: int -PK

y course_category_name: varchar(64)
07 tbl_enrollment enrollment_id: int -PK
course_id: int references tbl_course(course_id) -FK
account_id: int references tbl_account(account_id) -FK
enrollment_date: date
completion_status: bit
08 tbl_feedback feedback_id: int -PK
course_id: int references tbl_course(course_id) -FK
account_id: int references tbl_account(account_id) -FK
rating: int
comment: text
09 tbl_lesson lesson_id: int -PK
content_type_id: int references tbl_content_type(content_type_id) -FK
lesson_title: varchar(64)
lesson_detail: text
10 tbl_lesson_qna messages_public_id: int -PK
sender_id: int references tbl_account(account_id) -FK
lesson_id: int references tbl_lesson(lesson_id) -FK

GAMS-SRS_v1.0 Page 8 / 20
 message_text: text
timestamp: date
11 tbl_mentor_approv approval_id: int -PK
al mentor_id: int references tbl_account(account_id) -FK
approved_by: int references tbl_account(account_id) -FK
status_id: int references tbl_status_mentor(status_id) -FK
12 tbl_messages_priva message_private_id: int -PK
te sender_id: int references tbl_account(account_id) -FK
receiver_id: int references tbl_account(account_id) -FK
message_text: text
timestamp: date
13 tbl_payments payment_id: int -PK
account_id: int references tbl_account(account_id) -FK
course_id: int references tbl_course(course_id) -FK
amount: float
payment_method_id: int references
tbl_payment_method(payment_method_id) -FK
payment_date: date
14 tbl_payment_meth payment_method_id: int -PK
od payment_method_name: varchar(64)
15 tbl_quiz_content quiz_content_id: int -PK
quiz_question: text
quiz_option: text
quiz_id: int references tbl_quizzes(quiz_id) -FK
quiz_number: int
is_correct: bit
16 tbl_quiz_responses responses_id: int -PK
account_id: int references tbl_account(account_id) -FK
response_content: int
is_correct: bit
quiz_number: int
quiz_id: int references tbl_quizzes(quiz_id) -FK
17 tbl_quizzes quiz_id: int -PK
quiz_title: varchar(64)
content_type_id: int references tbl_content_type(content_type_id) -FK
18 tbl_status_mentor status_id: int -PK
status_name: varchar(64)
19 tbl_wishlist wishlist_id: int -PK
account_id: int references tbl_account(account_id) -FK
course_id: int references tbl_course(course_id) -FK

GAMS-SRS_v1.0 Page 9 / 20
II. Requirement Specifications
1. <<Feature Name>>
1.1 <<UseCaseCode_UC Name>>
a. Functionalities
Provide the functional description for the use cases using the template/guides below
Functional Description Template
UC ID and Name:
Created By: Date Created:
Primary Actor: Secondary Actors:
Trigger:
Description:
Preconditions:
Postconditions:
Normal Flow:
Alternative Flows:
Exceptions:
Priority: High (Medium, Low), Must Have (Should Have, Could Have),..
Frequency of Use:
Business Rules:
Other Information:
Assumptions:

Functional Description Contents

Use Case ID and Name
Give each use case a unique integer sequence number identifier. State a concise name for the use case
that indicates the value the use case would provide to some user. Begin with an action verb, followed by
an object.
Author and Date Created
Enter the name of the person who initially wrote this use case and the date it was written.
Primary and Secondary Actors
An actor is a person or other entity external to the software system being specified who interacts with
the system and performs use cases to accomplish tasks. Different actors often correspond to different
user classes, or roles, identified from the customer community that will use the product. Name the
primary actor that will be initiating this use case and any other secondary actors who will participate in
completing execution of the use case.
Trigger
Identify the business event, system event, or user action that initiates the use case. This trigger alerts
the system that it should begin testing the preconditions for the use case so it can judge whether to
proceed with execution.
Description
Provide a brief description of the reason for and outcome of this use case, or a high-level description of
the sequence of actions and the outcome of executing the use case.
Preconditions

GAMS-SRS_v1.0 Page 10 / 20
List any activities that must take place, or any conditions that must be true, before the use case can be
started. The system must be able to test each precondition. Number each precondition. Example: PRE-1:
User’s identity has been authenticated.
Postconditions
Describe the state of the system at the successful conclusion of the use case execution. Label each
postcondition in the form POST-X, where X is a sequence number. Example: POST-1: Price of item in the
database has been updated with the new value.
Normal Flow
Provide a description of the user actions and corresponding system responses that will take place during
execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead
to accomplishing the goal stated in the use case name and description. Show a numbered list of actions
performed by the actor, alternating with responses provided by the system. The normal flow is
numbered “X.0”, where “X” is the Use Case ID.
Alternative Flows
Document other successful usage scenarios that can take place within this use case. State the alternative
flow, and describe any differences in the sequence of steps that take place. Number each alternative
flow in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence number for the alternative flow.
For example, “5.3” would indicate the third alternative flow for use case number 5. Indicate where each
alternative flow would branch off from the normal flow, and if pertinent, where it would rejoin the
normal flow.
Exceptions
Describe any anticipated error conditions that could occur during execution of the use case and how the
system is to respond to those conditions. Number each alternative flow in the form “[Link]”, where “X”
is the Use Case ID, Y indicates the normal (0) or alternative (>0) flow during which this exception could
take place, “E” indicates an exception, and “Z” is a sequence number for the exceptions. For example
“5.0.E2” would indicate the second exception for the normal flow for use case number 5. Indicate where
in the normal (or an alternative) flow each exception could occur.
Priority
Indicate the relative priority of implementing the functionality required to allow this use case to be
executed. Use the same priority scheme as that used for the functional requirements.
Frequency of Use
Estimate the number of times this use case will be performed per some appropriate unit of time. This
gives an early indicator of throughput, concurrent usage loads, and transaction capacity.
Business Rules
List any business rules that influence this use case. Don’t include the business rule text here, just its
identifier so the reader can find it in another repository when needed.
Other Information
Identify any additional requirements, such as quality attributes, for the use case that may need to be
addressed during design or implementation. Also list any associated functional requirements that aren’t
a direct part of the use case flows but which a developer needs to know about. Describe what should
happen if the use case execution fails for some unanticipated or systemic reason (e.g., loss of network
connectivity, timeout). If the use case results in a durable state change in a database or the outside
world, state whether the change is rolled back, completed correctly, partially completed with a known
state, or left in an undetermined state as a result of the exception.
Assumptions
List any assumptions that were made regarding this use case or how it might execute.

GAMS-SRS_v1.0 Page 11 / 20
b. Business Rules
Provide the business rules those are applied only to the use case
ID Business Rule Business Rule Description
FR1 Password Encoding User’s password must be encoded with MD5 hashing

GAMS-SRS_v1.0 Page 12 / 20
2. Common Functions
2.1 UC-2_Login System
a. Functional Description
UC ID and Name: UC-2_Login System
Created By: MinhNNT Date Created: 16/Jun/2023
Primary Actor: Customer Secondary Actors: None
Trigger: User clicks Login button from the page header, or
User accesses an authenticated feature (from a link or type the page URL directly
into the address bar)
Description: As a user, I want to be able to log into the system so that I can use the system’s
authenticated features and access my personalized account.
Preconditions: User account has been created & authorized
Postconditions:  User logs in the system successfully
 The system tracked successful login into the Activity Log
Normal Flow 2.0 Login System
1. User accesses the User Login screen
2. User types in the login details or choo other login options (see 2.1 and 2.2)
3. User clicks the Login button
4. System validates the login details (see 2.0.E1)
5. System allows user to access
6. System tracks user’s success login to the Activity Log
7. System accesses the Home Page (or the previous calling page if any)
Alternative Flows: 2.1 Google Login
1. User chooses to login system using Google account
2. System redirects the user to the Google’s Login screen
3. User types in the Google account details and chooses to login
4. Google validates user’s login information successfully and redirect him/her
back to the system
5. Return to step 5 of normal flow.

2.2 Facebook Login

1. User chooses to login system using Facebook account
2. System redirects the user to the Facebook’s Login screen
3. User types in the Facebook account details and chooses to login
4. Facebook validates user’s login information successfully and redirect him/her
back to the system
5. Return to step 5 of normal flow.
Exceptions: 2.0.E1 System can’t authenticate the user
1. The Error Message screen is shown to the user
2. User cancels the logging in => UC stops, change to UC-1_View Home Page
3. User clicks “Forgot Password?” link => change to UC-3_Reset Password
4. User clicks “Register” link => change to UC-4_Register User Account
Priority: Must Have
Frequency of
Use:
Business Rules: FR1, FR2, FR3

GAMS-SRS_v1.0 Page 13 / 20
 Other
Information:
Assumptions:

b. Business Rules
ID Business Rule Business Rule Description
FR1 Password Encoding User’s password must be encoded with MD5 hashing
FR2 Invalid Logging In User can’t be authenticated to login the system if below cases
 His/her logging-in details are incorrect
 His/her account has not been verified
 His/her account has been locked or blocked
FR3 Account Locking If user inputs wrong logging-in details 6 times continuously,
his/her account would be locked in 30 minutes

3. Patron Feature
3.1 UC-5_Order a Meal
a. Functional Description
ID and Name: UC-5 Order a Meal
Created By: Prithvi Raj Date Created: 10/4/13
Primary Actor: Patron Secondary Actors: Cafeteria Inventory System
Description: A Patron accesses the Cafeteria Ordering System from the corporate intranet or
from home, views the menu for a specific date if desired, selects food items, and
places an order for a meal to be delivered to a specified location within a specified
15-minute time window.
Trigger: A Patron indicates that he wants to order a meal
Preconditions: PRE-1. Patron is logged into COS.
PRE-2. Patron is registered for meal payments by payroll deduction.
Postconditions: POST-1. Meal order is stored in COS with a status of “Accepted”.
POST-2. Inventory of available food items is updated to reflect items in this order.
POST-3. Remaining delivery capacity for the requested time window is updated.
Normal Flow: 5.0 Order a Single Meal
1. Patron asks to view menu for a specific date. (see 5.0.E1, 5.0.E2)
2. COS displays menu of available food items and the daily special.
3. Patron selects one or more food items from menu. (see 5.1)
4. Patron indicates that meal order is complete. (see 5.2)
5. COS displays ordered menu items, individual prices, and total price, including
taxes and delivery charge.
6. Patron either confirms meal order (continue normal flow) or requests to modify
meal order (return to step 2).
7. COS displays available delivery times for the delivery date.
8. Patron selects a delivery time and specifies the delivery location.
9. Patron specifies payment method.
10. COS confirms acceptance of the order.
11. COS sends Patron an email message confirming order details, price, and delivery
instructions.
12. COS stores order, sends food item information to Cafeteria Inventory System,

GAMS-SRS_v1.0 Page 14 / 20
 and updates available delivery times.
Alternative Flows: 5.1 Order multiple identical meals
1. Patron requests a specified number of identical meals. (see 5.1.E1)
2. Return to step 4 of normal flow.
5.2 Order multiple meals
1. Patron asks to order another meal.
2. Return to step 1 of normal flow.
Exceptions: 5.0.E1 Requested date is today and current time is after today’s order cutoff time
1. COS informs Patron that it’s too late to place an order for today.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests another date, then COS restarts use case.
5.0.E2 No delivery times left
1. COS informs Patron that no delivery times are available for the meal date.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests to pick the order up at the cafeteria, then continue with
normal flow, but skip steps 7 and 8.
5.1.E1 Insufficient inventory to fulfill multiple meal order
1. COS informs Patron of the maximum number of identical meals he can order,
based on current available inventory.
2a. If Patron modifies number of meals ordered, then Return to step 4 of normal
flow.
2b. Else if Patron cancels the meal ordering process, then COS terminates use case.
Priority: High
Frequency of Approximately 300 users, average of one usage per day. Peak usage load for this
Use: use case is between 9:00 A.M. and 10:00 A.M. local time.
Business Rules: BR-1, BR-2, BR-3, BR-4, BR-11, BR-12, BR-33
Other 1. Patron shall be able to cancel the meal ordering process at any time prior to
Information: confirming it.
2. Patron shall be able to view all meals he ordered within the previous six
months and repeat one of those meals as the new order, provided that all food
items are available on the menu for the requested delivery date. (Priority = M)
3. The default date is the current date if the Patron is using the system before
today’s order cutoff time. Otherwise, the default date is the next day that the
cafeteria is open.
Assumptions: Assume that 15 percent of Patrons will order the daily special (source: previous 6
months of cafeteria data).

b. Business Rules
None

3.2 UC-6_Register for Payroll Deduction

a. Functional Description
ID and Name: UC-6 Register for Payroll Deduction
Created By: Nancy Anderson Date Created: 9/15/13
Primary Actor: Patron Secondary Actors: Payroll System
Description: Cafeteria patrons who use the COS and have meals delivered must be registered for

GAMS-SRS_v1.0 Page 15 / 20
 payroll deduction. For noncash purchases made through the COS, the cafeteria will
issue a payment request to the Payroll System, which will deduct the meal costs
from the next scheduled employee payday direct deposit.
Trigger: Patron requests to register for payroll deduction, or Patron says yes when COS asks
if he wants to register
Preconditions: PRE-1. Patron is logged into COS.
Postconditions: POST-2. Patron is registered for payroll deduction.
Normal Flow: 6.0 Register for Payroll Deduction
1. COS asks Payroll System if Patron is eligible to register for payroll deduction.
2. Payroll System confirms that Patron is eligible to register for payroll deduction.
3. COS asks Patron to confirm his desire to register for payroll deduction.
4. If so, COS asks Payroll System to establish payroll deduction for Patron.
5. Payroll System confirms that payroll deduction is established.
6. COS informs Patron that payroll deduction is established.
Alternative Flows: None
Exceptions: 6.0.E1 Patron is not eligible for payroll deduction
6.0.E2 Patron is already enrolled for payroll deduction
Priority: High
Business Rules: BR-86 and BR-88 govern an employee’s eligibility to enroll for payroll deduction.
Other Expect high frequency of executing this use case within first 2 weeks after system is
Information: released.

b. Business Rules
None

III. Design Specifications

1. <<Feature Name>>
1.1 <<SubFeature Name>>
a. <<Screen/Function Name>>
[Provide brief description of the screen/function + related UC here and other details as in the sub-
sections]
UI Design
[This is to describe the UI layout (Mockup prototype) & descriptions for screen fields/components]
<<Mockup prototype>>
Field Name Field Type Description
Field Group Name
<<Field-Name>> <<Field type>> <<Field description & data initializing design>>

Database Access
[Provide the design description for the screen/function to access the database here: what table the
screen/function would access, which transactions does it make (C-Create, R-Read, U-Update, or D-
Delete), and how/purpose of the access (by providing Description and SQL commands)]
Table CRUD Description
<<Table Name>> <<transaction(s)>> <<Table access description: purpose, how,…>>
..

SQL Commands

GAMS-SRS_v1.0 Page 16 / 20
[Provide the detailed SQL (select, insert, update...) which are used in implementing the screen/function]

1.2 System Access

a. User Login
This screen allows user to be authenticated to the system screens/functionalities.
Related use cases:
 UC02_Login System

UI Design

Field Name Field Type Description

Email* Text Box This is for user to input valid email address for logging in
Password* Password Box This is for user to input password for logging in
Login Button User clicks to authenticate him/herself into the system with
provided email & password
Register Button User clicks to redirect to the User Register page for
registering new user account to access the system
Forgot Password? Hyperlink User clicks to redirect to the Password Reset page for
resetting his/her forgot password
Login with Google Hyperlink Allow user to login with his/her Google account
Login with Facebook Hyperlink Allow user to login with his/her Facebook account

Database Access
Table CRUD Description
User R Verify UserName & Password information
Setting, User R Specify the authorizations of the logged-in user

SQL Commands:
1/ Verify UserName & Password information
SELECT user_id, full_name, email, image_url, status
FROM user WHERE user_name = ? AND password = ?

GAMS-SRS_v1.0 Page 17 / 20
2/ Specify the authorizations of the logged-in user
SELECT mapped_values FROM setting WHERE setting_id = ?
SELECT setting_name, mapped_values FROM setting WHERE setting_id IN (?)

b. Setting List
UI Design

Field Name Field Type Description

Search Fields
Setting Type Combo Box Filled with the list of current active setting types
Single-Choice Allow to filter the list by setting type;
Default value is “All Types”
Setting Status Combo Box Values: All Statuses (default), Active, and Inactive
Single-Choice Allow to filter the list by status
Default value: “All Statuses”
Search Phase Text Box Allow to search using the name or map values
String (30) Default value: blank
Search Button Click to refresh the list with the defined filter(s) and search
phrase.
Add New Hyperlink Click to open the Setting Details page for adding new setting
(master data)
Data Table
ID Integer Auto-increased identifier of the setting
Name Text Name of the setting
Mapped Values Text Supplementary information for the setting
Type Text Type of the setting
Order Integer Display order of the setting: the order of the setting type,
displayed among the list of settings with the same type
Data Actions
Edit icon Click to open the Setting Details page for updating the
relevant setting (master data)
Activate icon Shown when the data status is inactive. This is to activate the
relevant setting (master data)
Deactivate Ion Shown when the data status is active. This is to deactivate the
relevant setting (master data)

GAMS-SRS_v1.0 Page 18 / 20
Database Access
Table CRUD Description
Setting RU Query the list of current settings from the database
Update status of a specific setting

SQL Commands:
1/ Query the list of current settings from the database
SELECT setting_id, setting_name, mapped_values, type_id, display_order, status
FROM setting WHERE (setting_type = ?) AND (status = ?) AND (setting_name LIKE ?)

2/ Update status of a specific setting

UPDATE setting SET status = ? WHERE setting_id = ?

c. Setting Details
UI Design

Field Name Field Type Description

Name* Text Box Name of the setting
String (20)
Type* Combo Box Type of the setting, filled with the list of setting types
(Single Choice) Default value: the first type in the list
Mapped Values Text Box Supplementary information for the setting (if any)
String (50)
Order Text Box Display order of the setting: the order of the setting type,
Integer (>=0) displayed among the list of settings with the same type
Status On/Off button Status of the setting: Active or Inactive
Default value: Active
Description Text Area Description of the setting
String (200)
Submit Button Click to store new or updated setting details
Reset Button Click to reset the changes use has made on the screen fields
back to the initial values when the screen is loaded

GAMS-SRS_v1.0 Page 19 / 20
Database Access
…

GAMS-SRS_v1.0 Page 20 / 20
IV. Appendix
1. Assumptions & Dependencies
AS-1: The user has an internet connection.

AS-2: Login information is protected.

AS-3: The system can handle concurrent requests without conflicts.

AS-4: Suppose there will be a notification when the mentor clicks on the delete lesson or quiz
button.

AS-5: Users can cancel courses or enrol from within the system.

AS-6: Suppose that without adding new course content, the course manager cannot create new
tests in the system.

AS-7: Suppose the user account list can be sorted by name, email, creation date, role, and status
for easy management.

AS-8: The size of the uploaded file should not exceed 10 MB to ensure fast download and
performance.

AS-9: Supposed course listings can be sorted by name, creation date, difficulty level, or number
of students to provide a better search experience

AS-10: Suppose that can sort the course list by name, email, address, total amount and status.

2. Limitations & Exclusions

- Users cannot view their learning progress and view courses they are taking if they cannot log in.
- Users cannot cancel the course once enrolled in the system.
- Admin cannot edit feedback and rating stars.
- There is no online support function (chat, video support) to answer questions or provide
technical support to users when needed.
- The system does not have the voucher and discount.
- The system will not participate in the user’s course participation.

3. Business Rules
[Provide common business rules that you must follow. The information can be provided in the table
format as the sample below]
ID Category Rule Definition
BR-01 Constraints Users must register an account and log in to access and
register for courses.

BR-02 Constraints the password will be hidden

GAMS-SRS_v1.0 Page 21 / 20
BR-03 Constraints Passwords include 1 capital letter and a minimum
length of 6 digits.
BR-04 Constraints User's email must exist.

BR-05 Constraints Users must pay tuition in full before starting the
course.
BR-06 Constraints The system must integrate payment gateway via
VNPay.
BR-07 Constraints Users cannot cancel purchased courses.

BR-08 Constraints Mentees who complete the course will receive a

certificate
BR-09 Constraints The system must provide 24/7 access to course
materials.
BR-10 Constraints Only Admins and Managers can access and view the
account list.
BR-11 Constraints The account information must be displayed in a secure

BR-12 Constraints Only logged-in mentors can delete quizzes.

BR-13 Constraints Deleted quizzes should be permanently removed from

the database and cannot be recovered.
BR-14 Constraints Only logged-in mentors can create quizzes

BR-15 Constraints The quiz must have at least one question.

BR-16 Constraints Quiz results are only visible to the user who took the
quiz and authorised personnel.
BR-17 Constraints The system should enforce quiz time limits where
applicable.
BR-18 Constraints Users cannot change their answers once the quiz is
submitted.
BR-19 Constraints The quiz interface should be accessible and navigable
on both desktop and mobile devices.
BR-20 Constraints Only logged-in users (Mentors/Mentees) can take
quizzes.

GAMS-SRS_v1.0 Page 22 / 20
GAMS-SRS_v1.0 Page 23 / 20