System/Software Requirements

Specification
about

Accommodation management booking

Version 1.0 approved

FPT University

July, 7, 2024
Table of Contents
Introduction 6
Purpose 6
System Purpose 6
Definitions, Acronyms and Abbreviations 6
Document Conventions 7
Project Scope 7
References 7
Software requirement specification form 7
SRS of Cafeteria Ordering System (by Karl Wiegers) 7
Software engineering – Ninth Edition (by Ian Sommerville) 7
Checklist 7

Overall Description 9
Product/System Perspective 9
System/Product Features 9
User requirements 9
User Classes and Characteristics 9
Operating Environment 10
Distributed database 10
Design and Implementation Constraints 10
Assumptions and Dependencies 10
Apportioning of Requirements 10

Specific Requirements 10
Functional Requirements Specification 10
Function1 /Use-case 1 12
UC01 - Register 13
Screen Design 13
Use Case Specification 15
UC02-Login 16
Screen Design 17
Use Case Specification 17
UC3 - Logout 19
Screen Design 19
Use Case Specification 20
UC04-Search 21
Screen Design 22
Use Case Specification 23
UC05 - Choose Language 24
Screen Design 24
 Use Case Specification 25
UC06 - Learn quiz flashcard 26
Screen Design 27
Use Case Specification 28
UC07 - Learn quiz write 29
Screen Design 30
Use Case Specification 31
UC08 - Learn quiz spell 32
Screen Design 33
Use Case Specification 33
UC09 - Learn quiz play game 35
Screen Design 35
Use Case Specification 36
UC10 - Test quiz 37
Screen Design 38
Use Case Specification 38
UC11 - View profile 40
Screen Design 40
Use Case Specification 41
UC12 - Edit profile 42
Screen Design 43
Use Case Specification 44
UC13 - Report 45
Screen Design 46
Use Case Specification 46
UC14 - Add quiz 48
Screen Design 48
Use Case Specification 49
UC15 - Edit quiz 50
Screen Design 51
Use Case Specification 52

UC16 - Delete quiz 53

Screen Design 54
Use Case Specification 55
UC18 - View my quiz 56
Screen Design 57
Use Case Specification 58
 UC19 - Delete user 59
Screen Design 60
Use Case Specification 61
3.3 Non-Functional Requirements Specification 62
3.3.1 External Interface Requirements 62
3.3.1.1 Hardware Interface 62
3.3.1.2 Software Interface 62
3.2.1.3 Communications Interface 62
3.3.2 Other Nonfunctional Requirements 63
3.3.2.1 Safety Requirements 63
3.3.2.2 Performance Requirements 63
3.3.2.3 Security Requirements 63

Revision History

1. Introduction
1.1 Purpose

In the context of student housing and accommodation, finding suitable living arrangements can be
challenging and time-consuming for students. To address this, we are developing an Accommodation
Management Booking website to facilitate the process of finding and reserving dormitory rooms. With
the increasing number of students pursuing higher education and the limited availability of on-campus
housing, there is a growing need for an efficient and user-friendly platform to connect students with
available dorm rooms. Our system aims to streamline the booking process and provide a
comprehensive solution for student accommodation needs.

1.2 System Purpose

"FPTDorm" is a web-based application for booking dormitory accommodations. Users can search for
available rooms, view details, and create reservations.

1.3 Definitions, Acronyms and Abbreviations

Acronym Definition
 ABS Accommodation Booking System
DBMS Database Management System
DMS Dorm Management System
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IDE Integrated Development Environment
N/A Not Available
OS Operating System
RMS Room Management System
UC Use Case
UI User Interface
UML Unified Modeling Language
URL Uniform Resource Locator
UX User Experience

1.4 Document Conventions

- Font family: Times New Roman,
- Font weight: Regular.
- Font size: 11.
- Font weight heading 1: bold.
- Font size heading 1: 18.
- Font weight heading 2: bold.
- Font size heading 2: 14.

1.5 Project Scope

This web application is intended for use by students seeking dormitory accommodation and administrators
managing dorm facilities. The system will allow students to search for available rooms, view details, make
reservations, and manage their bookings. Administrators will be able to oversee room inventory, process
bookings, and generate necessary reports.

Key features include user registration, room search and booking, payment processing, and a user-friendly
interface for both students and administrators. The system aims to improve the efficiency of the dorm booking
process, enhance the student experience, and provide better management tools for dorm administrators.

1.6 References
- Software requirement specification form
- SRS of Cafeteria Ordering System (by Karl Wiegers)
- Software engineering – Ninth Edition (by Ian Sommerville)

1.7 Checklist

Correct and - All functional capabilities of the Accommodation Management Booking

Complete system are documented.
- User roles (user, employee, admin) and their respective functionalities are
clearly defined.
- The room search and booking process is fully described, including all steps
and options.
- Room inventory management features for administrators are completely
specified.
- All data flows, including user inputs and system outputs, are identified and
described.
- Payment processing requirements and integration are fully outlined.
- Security measures for user data and payment information are specified.
- Notification system requirements (email, in-app) are detailed.
- Reporting and analytics functionalities for administrators are
comprehensively described.
- User interface requirements for both web and mobile platforms are
specified.
- Performance requirements (e.g., response time, concurrent users) are
identified.
- Data storage and retrieval processes are fully described.
- Integration requirements with existing university systems (if any) are
specified.
- All system constraints and limitations are clearly stated.
- Error handling and system recovery processes are documented.
- Scalability requirements to handle increasing user numbers are addressed.
- Compliance with relevant educational and housing regulations is ensured
and documented.
- Maintenance and support requirements are specified.
- All non-functional requirements (reliability, usability, performance) are
identified.
- The system's behavior under various operational conditions is described.
Consistent - All software requirements for the Accommodation Booking Dorm system
are derived from the overall system specification.
- Each component of the system (e.g., user accounts, room listings,
bookings) is referred to by a unique name.
- Each component is defined by a consistent set of characteristics that do not
conflict with one another.
- All requirements are free of logical conflicts within the context of dorm
booking and management.
- All requirements are free of timing conflicts, especially regarding the
booking process and room availability updates.
- Each requirement is specified only once to avoid redundancy and potential
inconsistencies.
- Requirements for different user roles (students, administrators) do not
conflict with each other.
- The Software Requirements Specification (SRS) is consistent with the user
interface requirements and any higher-level specifications for the
 university's IT systems.
- All data structures and messages within the system are specified only once
and used consistently throughout.
- The room search, booking, and management processes are described
consistently across all relevant sections of the SRS.
- Terminology related to accommodation, bookings, and dorm management
is used consistently throughout the document.
Feasible - Data expected from external sources exists at those sources.
- Data sent to external destinations is expected at those destinations.
- Requirements are achievable with available technology.
- Necessary implementation tools are available.
- Scope of requirements is realistic, considering software estimates,
schedules, and support facility plans
Meets Standards - Major software functions are described in relation to system operation.
- Requirements are clearly stated and unambiguous.
- Terminology is understandable and consistent.
- All notation and naming conventions are defined.
- Glossary is adequate.
- SRS adheres to required format.

Testable - All requirements are specified against the software

- All requirements can be verified by some (implicit, explicit, analytical,
empirical) means.
- Test procedures can be written against all requirements, using existing or
planned resources.
- Test results can be evaluated against predetermined acceptance criteria.

2. Overall Description
2.1 Product/System Perspective
This software product is ultimately designed for everyone who wants to rent a dormitory because there
are a lot of things people want to rent online for the convenience of paying, so they will need a good
app. However, not many websites offer this feature so our team decided to build a website based on that
need.

The product will be deployed on the website and all users of the product will access it using the website.
The website will be the main user interface where users can operate all the functions provided

Users can easily view the website using their personal computer, iPad or phone and rent a room, but to
rent a pharmacy, they need to create an account and log in. User information and rental lists will be kept
in the database
2.2 System/Product Features
The Accommodation Management Booking web application offers the following features:

● Cross-Platform Accessibility:
○ The web application is accessible on any operating system with a compatible web browser and
internet connectivity. This includes devices such as computers, iPads, and smartphones,
providing users with flexibility in accessing the service.
● User Registration and Authentication:
○ Users can easily register for accounts, securely log in, and manage their profiles directly through
the web interface. This includes functionalities for updating personal information and managing
account settings.
● Room Booking and Payment:
○ The primary function of the web application is to facilitate quick and convenient room rental
within university dormitories. Users can search for available rooms, view details, make
reservations, and securely complete payments online.
● User-Friendly Interface:
○ The website is designed to be intuitive and user-friendly, ensuring that users can navigate
seamlessly through the booking process, from selecting a room to completing payment.
● Responsive Design:
○ The interface is responsive, adapting smoothly to different screen sizes and devices, enhancing
the user experience across desktops, tablets, and mobile phones.
● Integration with Payment Gateways:
○ Secure payment integration allows users to make transactions using preferred payment methods,
ensuring convenience and trust in financial transactions.
● Administrative Dashboard:
○ Administrators have access to a dashboard for managing room listings, availability, pricing, and
user accounts. This administrative interface facilitates efficient management of accommodation
resources and user interactions.

By incorporating these features, the Accommodation Management Booking web application aims to provide a
seamless and efficient platform for renting university dormitory rooms, catering to the needs of both users and
administrators.

2.3 User requirements

2.3.1. User

Account Management:

- Ability to create a new account with basic personal information

- Option to log in securely using email and password
- Functionality to reset password if forgotten
- Capability to update personal profile information

Room Search and Booking:

 - Search for available rooms using various filters (e.g., date range, room type, price)
- View detailed information about each room, including photos and amenities
- Check room availability for specific dates
- Make room reservations for desired dates
- Receive instant booking confirmation

Payment:

- Secure online payment for room bookings

- Multiple payment options (e.g., credit card, debit card, online banking)
- View and download payment receipts

Booking Management:

- View all current and past bookings

- Cancel or modify bookings (subject to cancellation policy)
- Extend stay if room is available

Communication:

- Receive email notifications for booking confirmations and reminders

- In-app messaging system to communicate with dorm administration
- Access to FAQ and help documentation

Review and Feedback:

- Ability to rate and review their stay after check-out

- View ratings and reviews from other students

2.3.2. Employee

Account Management:

- Secure login with employee-level privileges

- Manage own account details

Room Management:

- View room listings and availability

- Update room status (e.g., clean, needs maintenance)
- Report issues with specific rooms

Booking Support:

- View current and upcoming bookings

- Assist with check-in and check-out processes
 - Handle basic booking modifications or cancellations

Customer Service:

- Respond to student inquiries through the messaging system

- Address and escalate complaints when necessary
- Provide information about dorm facilities and policies

Maintenance Coordination:

- Create and manage maintenance requests

- Update the status of maintenance tasks
- Communicate with maintenance staff about room issues

Reporting:

- Submit daily reports on room status and occupancy

- Report any incidents or issues that occur during shifts

2.3.3. Administrator

Account Management:

- Secure login with admin privileges

- Manage own account details

Room Management:

- Add, edit, or remove room listings

- Update room availability and pricing
- Set special offers or discounts

Booking Oversight:

- View all current and upcoming bookings

- Process booking modifications or cancellations
- Handle special requests from students

User Management:

- View and manage student user accounts

- Address user complaints or issues

Reporting and Analytics:

- Generate occupancy reports

- View financial summaries
 - Access user activity and booking trends

Communication:

- Send mass notifications to all users or specific groups

- Respond to user inquiries through the messaging system

2.4 User Classes and Characteristics

Object Description

Admin Users with administrative privileges who can manage the entire system.
They can add, edit, or remove room listings, manage bookings, users, and view reports
and analytics.

Employee Staff with access to room management functions, booking support, customer service,
and maintenance coordination. They can view and update room status, handle booking
requests, and assist students.

User Users who log into the system to utilize functions such as searching and booking rooms,
managing personal accounts, making payments, and viewing current and past bookings.

Guest Visitors who have not logged into the system. They can view detailed information about
rooms and amenities but cannot make bookings or access other functions until they
register and log in.

All users need to log in to the system to book room but guests can see room but cannot book room.
Admin and employees are required to log in to access the management page

Characteristics: No special user characteristics required: The software does not require any special user
characteristics. Any user can create an account and become a member of the system.
Easy registration and usage: Users can easily register an account, log in, and use the system's functions. They
only need basic web usage knowledge.
Secure account management and access: All users, including Admin, Employee, and User, must log in to use the
system. Guests can view room details without logging in but need to register and log in to make bookings and
access other functions.

2.5 Operating Environment

Architecture: Client / Server system

Database: MySQL
Backend Framework: Java Spring Boot
Frontend:

- Template Engine: Thymeleaf

 - Markup: HTML
- Styling: CSS
- Frontend Framework: Bootstrap

Operating System: Any OS (cross-platform compatibility)

Runtime Environment: Java Runtime Environment (JRE)
Web Server: Apache Tomcat (embedded in Spring Boot)
Development Tools: Java Development Kit (JDK)

Integrated Development Environment (IDE) supporting Java and Spring Boot (e.g., IntelliJ IDEA,
Eclipse)

2.6 Design and Implementation Constraints

Developers should also be careful about the privacy of users. All user data will be kept on the database
and necessary precautions should be taken to protect user data.

The Internet connection is a constraint for the application. Since the application fetches data from the
database over the Internet, it is crucial that there is an Internet connection for the application to
function.

2.7 Assumptions and Dependencies Also has knowledge about using it at a

minimum level (access, fill in field).

One assumption is that some library that developers team use for development like “thymeleaf” or
database Mysql we use have an issue, bug, down or update, it will affect the website’s performance or
even make the website down.

2.8 Apportioning of Requirements

Assume the user has an internet connection and the computer has a web browser, and the user
User Interaction and Administrative Functions:

● Users can submit reports to administrators, request permissions, and track financial
transactions, including profit distribution.
● Administrative tools will facilitate efficient management of user requests and financial
operations.

Notification System:

● Implementation of a robust email notification system for users and administrators. Notifications
will cover booking confirmations, status updates, payments, and promotional offers.

Enhanced User Experience:

 ● Development of an interactive user dashboard for managing bookings, preferences, and
feedback mechanisms to improve user engagement.

Security and Compliance:

● Strengthening data protection measures and ensuring compliance with relevant regulations to
protect user privacy and secure financial transactions.

Continuous Improvement:

● Adoption of agile practices for iterative development, allowing for ongoing enhancements
based on user feedback and technological advancements.

Functional Requirements Specification

Business Rules

ID Descriptions
B01 Account’s email address must be valid
B02 Account’s password must be at least 8 characters in length and must contain at least 1 uppercase letter,
1 lower case letter and 1 digit.
B03 Account’s password must not be stored as plain text. Instead it must be hashed using a secure hash
algorithm.
B04 When registering or changing password, user must enter new password twice
B05 A guest must provide their email address and password when registering an account.
B06 A guest cannot register with an email that has already been registered.
B07 After registering, guest must activate their account with the activation link sent to the account’s email
address.
B08 User must provide their account’s email address and password when logging into the app
B09 User cannot login to their account unless the account is activated
B10 Access token must be encrypted when saving into browser’s storage.
B11 User must provide their account’s username address when resetting the account’s password
B12 A guest can search any public quiz
B13 User cannot search when input empty
B14 Users can search options like users, numbers, ...
B15 A guest can search quiz without login
B17 A user can search any public quiz
B18 User can switch language when that language was supported
B19 User can learn flash card any public quiz
B20 A guest can learn flash card without login

B21 User can learn write card any public quiz.

B22 A guest can learn write without login
B23 User can learn spell any public quiz.
B24 A guest can learn spell without login
B25 User can learn play game any public quiz.
B26 A guest can learn play game without login
B27 User can test any public quiz.
B28 A guest can test without login

2.8.1 Function1 /Use-case 1

Use case Diagram

 ID Actor Name
UC-1 Guest Register
UC-2 Guest, User, Admin Login
UC-3 User, Admin Logout
UC-4 Guest, User, Admin Search quiz
UC-5 Guest, User, Admin Choose Language
UC-6 Guest, User, Admin Learn quiz with Flash Card
UC-7 Guest, User, Admin Learn quiz with write
UC-8 Guest, User, Admin Learn quiz with spell
 UC-9 Guest, User, Admin Learn quiz with play game
UC-10 Guest, User, Admin Test quiz
UC-11 User, Admin View profile
UC-12 User, Admin Edit profile
UC-13 User Report
UC-14 User Add quiz
UC-15 User Edit quiz
UC-16 User Delete quiz
UC-18 User View my quiz
UC-19 Admin Delete user

2.8.2 UC01 - Register

2.8.2.1 Screen Design

Table 3-1: Screen Definition

# Field Name Type Mandator Max Length Description
y

1 User Name Input/Text Yes 20

2 Full name Input/Text Yes 255
3 Job Combo box Yes Student and teacher
4 Date of Birth Date picker Yes
5 Address Text Area Yes 255
6 Password Input/ Yes 20
Password
7 Repassword Input/ Yes 20 Value must be the same
Password Password
7 Register Button Go to home page
4 Close Button
 Figure 3-1: Screen Design of Register

2.8.2.2 Use Case Specification

 Figure 3-2: Register Use-Case Diagram

Use Case ID UC-1

Use Name Register

Actor Guest
Description The function allows a user to be able to register in the software when he/she haven’t
registered an account and his/her account is still active.
Precondition PRE-1.1 Guest has a valid email
Trigger
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System
Normal Flow 1.0 Register
1. Guest open desktop application.
2. System display QuizSharp home page.
3. Guest clicks Register menu on navigation bar.
4. System displays login/register dialog box.
5. System displays the registration form in the dialog box.
6. Guest enters username, full name, job, date of birth, address, password,
repassword on the registration form.
7. Guest clicks Sign Up button on the registration form.
8. System creates a new QuizSharp’s account with field provided.
9. System generates an activation link for the account.
10. System sends an email with the activation link to provided email address.
11. System displays a message to notify that account has been created and
activation email has been sent to the registered email address.
12. Guest visits his/her email account and open the activation email.
13. Guest clicks the activation link.
14. System activates the new account, then deletes the activations link from
database.
15. System display a message to notify that the account has been activated.
16. System display the QuizSharp home page.

Alternative flows N/A

Exceptions 1.0-E1 – Cannot communicate with API server.

System displays error message.
1.0-E2 – Input data in step 7 violates one or some of the business rules.
System displays error message on the registration form.
1.0-E3 – 24 hours since the activation email is sent, the Guest does not click the
activation link.
System will deletes the account and the activation link from database.

Priority Height

Frequency of Use Height

Business Rules B01, B02, B03, B04, B05, B06, B07, B08

Other Information N/A

Assumptions Guest can access his/her email account.

2.8.3 UC02-Login

2.8.3.1 Screen Design

Figure 3-3: Screen Design of Login

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description
Length
1 User Name Text/ Yes 20
2 Password Text Yes 20 Display "*" instead of
clear character
3 Login Button Go to home page
4 Close Button
5 Redirect Register Link Yes Click login then
redirect to login page

2.8.3.2 Use Case Specification

 Figure 3-4: Login Use-Case Diagram

Use Case ID UC-2

Use Name Login
Actor User, Admin
Description The function allows a user to be able to login in the software when he/she have
registered an account and his/her account is still active.
Precondition PRE-1.1 User has ASN account
Trigger
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Login
1. Type URL into location field of internet browser and then press enter
2. QS display Login screen with the following fields: user name,
password, login and close button
3. Users enter username & password into Username & Password fields
on the Login screen, then click on the Login button.
4. QS validate the entered user name & password and then display Home
screen

Alternative flows QS display "Error" page with message "Internal System Error, please contact
with administrator"
Priority Height

Frequency of Use Height

Business Rules
Other Information N/A

Assumptions

2.8.4 UC3 - Logout

2.8.4.1 Screen Design

Figure 3-5: Screen Design of Logout

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 Logout Button When user click
Button Logout, web
redirect to Home Page
2.8.4.2 Use Case Specification

Figure 3-6: Logout Use-Case Diagram

Use Case ID UC-3

Use Name Logout
Actor User, Admin
Description The function allows a user to be able to logout in the software when he/she have
logged an account and his/her account to QS
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger
Post-Condition POST-1.1 When the normal flow completes successfully
Normal Flow 1.0 Logout
1. User login on QS system successful
2. User click to Button Logout
3. User will exit the system
4. QS will redirect user to Home Page

Alternative flows QS display "Error" page with message "Internal System Error, please contact
with administrator"
Exceptions N/A

Priority Medium

Frequency of Use Height

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.5 UC04-Search

2.8.5.1 Screen Design

Figure 3-7: Screen Design of Search

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 Search Input/ Yes 255
Text
2 Search Button When user click
search, QS redirect to
Search Page show list
quiz with key word in
box search
2.8.5.2 Use Case Specification

Figure 3-8: Search Use-Case Diagram

Use Case ID UC-4

Use Name Search
Actor User, Admin, Guest
Description The function allows a everyone in QS can search quiz to learn
Precondition N/A
Trigger N/A
Post-Condition N/A
Normal Flow 1.0 Search
1. Guest enters search keyword on search box in navigation.
2. Guest clicks search button.
3. System displays the list of issuers matched with the search
keyword. Each quiz is presented with title and content

Alternative flows N/A

Exceptions N/A

Priority Low

Frequency of Use Medium

Business Rules B12, B13, B14, B15, B16, B17

Other Information N/A

Assumptions N/A

2.8.6 UC05 - Choose Language

2.8.6.1 Screen Design

Figure 3-9: Screen Design of Choose Langue

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description
Length
1 Choose language Button
2 List language Combo
box

2.8.6.2 Use Case Specification

 Figure 3-10: Search Use-Case Diagram

Use Case ID UC-5

Use Name Choose language
Actor User
Description The function allows a user can switch to other language
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, user must be login to
system before choose language
Normal Flow 1.0 Choose language
1. User click to button Choose Language
2. QS show list language system support for user choose
3. User click to Language want to switch
4. Immediately, all QS wen translate to that language

Alternative flows N/A

Exceptions N/A

Priority Low

Frequency of Use Medium

Business Rules B18

Other Information N/A

Assumptions N/A

2.8.7 UC06 - Learn quiz flashcard

2.8.7.1 Screen Design

Figure 3-11: Screen Design of Learn quiz Flashcard

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 Flash card Box Box flashcard have 2
face can switch
2 Next Button User can next term
quiz to learn
3 Previous Button User can previous term
quiz to learn
4 Flip Button User can switch face
by this button
2.8.7.2 Use Case Specification

Figure 3-12: Learn quiz flashcard Use-Case Diagram

Use Case ID UC-6

Use Name Learn quiz flashcard
Actor User, Amdin, Guest
Description The function allows learn quiz with flashcard.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Learn quiz flashcard
1. QS show page learn with flashcard successfully
2. User can see one face of flashcard
3. User can next or previous term by click button Next or Previous, arrow key
left, arrow key right
4. User can switch 2 face by button Turn or arrow key up, arrow key down

Alternative flows N/A

Exceptions N/A

Priority Height

Frequency of Use Medium

Business Rules B19, B20

Other Information N/A

Assumptions N/A

2.8.8 UC07 - Learn quiz write

2.8.8.1 Screen Design

Figure 3-13: Screen Design of Learn quiz write

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description
Length
1 One face Box One face of term
2 Answer Input Yes 255
3 Next Button User can next term
quiz to learn
4 Previous Button User can previous term
quiz to learn
5 Check Button Check answer correct
or not
2.8.8.2 Use Case Specification

Figure 3-14: Learn quiz write Use-Case Diagram

Use Case ID UC-7

Use Name Learn quiz write
Actor User, Admin, Guest
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Learn quiz flashcard
1. QS show page learn with write successfully
2. User can see one face of term quiz
3. Input answer of the other side in input check
4. User can next or previous term by click button Next or Previous, arrow key
left, arrow key right
5. Press Enter to check answer correct or not

Alternative flows N/A

Exceptions N/A

Priority Height
Frequency of Use Medium

Business Rules B21, B22

Other Information N/A

Assumptions N/A

2.8.9 UC08 - Learn quiz spell

2.8.9.1 Screen Design

Figure 3-15: Screen Design of Learn quiz spell

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 Answer Input Yes 255
2 Next Button User can next term
quiz to learn
3 Previous Button User can previous term
quiz to learn
5 Speaker Button Used to listen again
2.8.9.2 Use Case Specification

Figure 3-16: Learn quiz write Use-Case Diagram

Use Case ID UC-7

Use Name Learn quiz spell
Actor User, Admin, Guest
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Learn quiz spell
1. QS show page learn with spell successfully
2. QS will emit the sound of one side of that term
3. User input answer of the other side in input check
4. User can next or previous term by click button Next or Previous, arrow key
left, arrow key right
5. Press Enter to check answer correct or not

Alternative flows N/A

Exceptions N/A
Priority Medium

Frequency of Use Medium

Business Rules B23, B24

Other Information N/A

Assumptions N/A

2.8.10 UC09 - Learn quiz play game

2.8.10.1 Screen Design

Figure 3-17: Screen Design of Learn quiz play game

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 List answer Box
2 List question Box
2.8.10.2Use Case Specification

Figure 3-18: Learn quiz write Use-Case Diagram

Use Case ID UC-9

Use Name Learn quiz play game
Actor User
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Learn quiz play game
1. QS show page learn with spell successfully
2. QS show list answer and list question random mix up together
3. User can click any box and drag to other box to check answer correct or not.

Alternative flows N/A

Exceptions N/A

Priority Medium

Frequency of Use Medium

Business Rules B25, B26

Other Information N/A

Assumptions N/A

2.8.11 UC10 - Test quiz

2.8.11.1Screen Design

Figure 3-19: Screen Design of test quiz

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 List question Text Each question have list
answer
2 List answer Select
Box
3 Submit Button

2.8.11.2Use Case Specification

 Figure 3-20: Learn quiz write Use-Case Diagram

Use Case ID UC-10

Use Name Test Quiz
Actor User
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Test Quiz
1. QS show page test quiz successfully
2. QS show list question and list answer.
3. User choose answer for each question
4. Click button submit to submit

Alternative flows N/A

Exceptions N/A

Priority Medium

Frequency of Use Medium

Business Rules B27, B28

Other Information N/A

Assumptions N/A
2.8.12 UC11 - View profile

2.8.12.1Screen Design

Figure 3-21: Screen Design of view profile

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 List question Text Each question have list
answer
2 List answer Select
Box
3 Submit Button
2.8.12.2 Use Case Specification

Figure 3-22: Learn quiz write Use-Case Diagram

Use Case ID UC-11

Use Name View profile
Actor User
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 View profile
1. Guest and User click on avatar of owner
2. System will redirect the owner’s profile
3. Guest and User can see detail profile of owner

Alternative flows N/A

Exceptions N/A

Priority Medium

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.13 UC12 - Edit profile

2.8.13.1Screen Design

Figure 3-23: Screen Design of edit profile

Table 3-1: Screen Definition

# Field Name Type Mandator Max Length Description

y
1 User Name Input/Text Yes 255
2 Full name Input/Text Yes 255
3 Job Input/Text Yes 255
4 Date of Birth Date Yes 255
5 Address Text Area Yes 255
6 Password Password Yes 255
7 Update Button
2.8.13.2 Use Case Specification

Figure 3-24: Learn quiz write Use-Case Diagram

Use Case ID UC-12

Use Name Update profile
Actor User
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Update profile
1. User open QuizSharp web.
2. System display QuizSharp home page.
3. Guest clicks button edit profile menu on navigation bar.
4. System displays the update form in the dialog box.
5. Guest enters full name, job, date of birth, address, password, repassword on
the registration form.
6. Guest clicks Update button on the registration form.
7. System update account with field provided.
8. System generates an activation link for the account.
9. System displays a message to notify that account updated
Alternative flows N/A
Exceptions N/A

Priority Medium

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.14 UC13 - Report

2.8.14.1Screen Design

Figure 3-25: Screen Design of edit profile

Table 3-1: Screen Definition

# Field Name Type Mandator Max Length Description

y
1 Title Text Yes 255
2 Content Textarea Yes 255
3 Submit Button

2.8.14.2 Use Case Specification

Figure 3-26: Learn quiz write Use-Case Diagram

Use Case ID UC-13

Use Name Report
Actor User
Description The function allows learn quiz with write.
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Report
1. User open QuizSharp web and go to page report
2. System display report page with input title, textarea context and button
submit.
3. User write all field and click button submit.
4. QS send and show display status done or not.
Alternative flows N/A
Exceptions N/A

Priority Medium

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.15 UC14 - Add quiz

2.8.15.1Screen Design

Figure 3-27: Screen Design of edit profile

Table 3-1: Screen Definition

# Field Name Type Mandator Max Length Description

y
1 Title quiz Input/ Text Yes 255
2 Face one Input/ Text Yes 255
3 Face two Input/ Text Yes 255
4 Add Button Add more term quiz
5 Done Button

2.8.15.2 Use Case Specification

Figure 3-28: Add quiz Use-Case Diagram

Use Case ID UC-14

Use Name Add quiz
Actor User
Description The function allows user create new quiz to learn
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Add quiz
1. User open QuizSharp web and go to page create quiz
2. QS create one term automatic in page create quiz
3. User fill title and two face of term, if user want to add more term then click
button Icon add to add more
4. User click button done to submit create quiz.
5. QS create new quiz to database and create url of that quiz then redirect user
 to link quiz created.

Alternative flows N/A

Exceptions N/A

Priority Slow

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.16 UC15 - Edit quiz

2.8.16.1Screen Design

Figure 3-29: Screen Design of edit quiz

Table 3-1: Screen Definition

# Field Name Type Mandator Max Length Description

y
1 Title quiz Input/ Text Yes 255
2 List quiz Box
3 Update Button

2.8.16.2 Use Case Specification

Figure 3-30: Add quiz Use-Case Diagram

Use Case ID UC-15

Use Name Edit quiz

Actor User
Description The function allows user create new quiz to learn
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Edit quiz
1. User open QuizSharp web and go to page edit quiz.
2. User can modifier title or content of list quiz
 3. User click Update to submit done edit quiz
4. QS will update change to database then redirect user to link of quiz after
change.

Alternative flows N/A

Exceptions N/A

Priority Slow

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.17 UC16 - Delete quiz

2.8.17.1Screen Design

Figure 3-31: Screen Design of delete quiz

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description
Length
1 Title quiz Text
2 List quiz Box
3 Delete Button

2.8.17.2 Use Case Specification

Figure 3-32: Delete quiz Use-Case Diagram

Use Case ID UC-17

Use Name Delete quiz
Actor User
Description The function allows user create new quiz to learn
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Delete quiz
1. User open QuizSharp web and go to page quiz .
2. User click button Delete to remove the quiz from the system
3. QS delete this quiz in database and redirect home page
Alternative flows N/A
Exceptions N/A

Priority Slow

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.18 UC18 - View my quiz

2.8.18.1Screen Design

Figure 3-33: Screen Design of delete quiz

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 List quiz Box List quiz wrap title,
 number term, author
2 Title Text
3 Number Term Text Number term of lesson
quiz
4 Author Text

2.8.18.2 Use Case Specification

Figure 3-34: View my quiz Use-Case Diagram

Use Case ID UC-18

Use Name View my quiz
Actor User
Description The function allows user create new quiz to learn
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Delete quiz
1. User open QuizSharp web and go to page view my quiz
2. QS show list quiz to user
Alternative flows N/A
Exceptions N/A

Priority Slow

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

2.8.19 UC19 - Delete user

2.8.19.1 Screen Design

Figure 3-35: Screen Design of delete user

Table 3-1: Screen Definition

# Field Name Type Mandatory Max Description

Length
1 List quiz Box List quiz wrap title,
number term, author
2 Title Text
3 Number Term Text Number term of lesson
quiz
4 Author Text
5 Delete Button

2.8.19.2 Use Case Specification

Figure 3-2: Delete user Use-Case Diagram

Use Case ID UC-19

Use Name Delete user
Actor Admin
Description The function allows user create new quiz to learn
Precondition PRE-1.1 User has account on QS web
PRE-1.2 User has logged on QS web
Trigger N/A
Post-Condition POST-1.1 When the normal flow completes successfully, a new account is created
on the QuizSharp System and user or admin must be login to system
Normal Flow 1.0 Delete user
1. Admin open QuizSharp web and go to page view list user
 2. Admin click delete to delete user
3. QS delete user from database and refresh page list user

Alternative flows N/A

Exceptions N/A

Priority Slow

Frequency of Use Medium

Business Rules N/A

Other Information N/A

Assumptions N/A

3.3

3.3.1 External Interface Requirements

If there is extensive damage to a wide portion of the database due to catastrophic failure, such as a disk
crash, the recovery method restores a past copy of the database that was backed up to archival storage
(typically tape) and reconstructs a more current state by reapplying or redoing the operations of
committed transactions from the backed up log, up to the time of failure.

3.3.2.2 Performance Requirements

Any response must be within 2 seconds or less

After press any button, there’re always respond within 1 seconds (loading process, save success, etc)

3.3.2.3 Security Requirements

No user’s information, properties loss, insult from thirds party for bad behaviors

When signup, guest need to create account with real name, username must have more than 6 character,
password must have more than 8 character included: letter, number. Guest need to agree with web site
‘s privacy

3.3.1 External Interface Requirements

3.3.1.1 Hardware Interface

● Any web browers available now: Chorme, Firefox, Coc Coc, Ie.
 ● Internet
● Device that can connect website

3.3.1.2 Software Interface

ID Software Used Description

1 OS Any OS available now

2 ReactJs, HTML, CSS Javascript library to build front-end

3 NodeJs, ExpressJs Build backend

3.2.1.3 Communications Interface

This project supports all types of web browsers. We are using Facebook API to share post /our web to facebook
The communication between the different parts of the web is important since they depend on each other.
However, in what way the communication is achieved is not important for the web and is therefore handled by
the underlying operating systems for the web portal

3.3.2 Other Nonfunctional Requirements

3.3.2.1 Safety Requirements

If there is extensive damage to a wide portion of the database due to catastrophic failure, such as a disk
crash, the recovery method restores a past copy of the database that was backed up to archival storage
(typically tape) and reconstructs a more current state by reapplying or redoing the operations of
committed transactions from the backed up log, up to the time of failure.

3.3.2.2 Performance Requirements

Any response must be within 2 seconds or less

After press any button, there’re always respond within 1 seconds (loading process, save success, etc)

3.3.2.3 Security Requirements

No user’s information, properties loss, insult from thirds party for bad behaviors

When signup, guest need to create account with real name, username must have more than 6 character,
password must have more than 8 character included: letter, number. Guest need to agree with web site
‘s privacy