(Đồ Án Hcmute) Developing A Lab Management System Using Mern Stack.pdf

MINISTRY OF EDUCATION AND TRAINING HO CHI MINH CITY UNIVERSITY OF TECHNOLOGY AND EDUCATION CAPSTONE PROJECT INFORMATION TECHNOLOGY Ho Chi Minh City, August, 2021 S KL0 0 9 1 5 9 LE DUC THINH DEVELOPIN[.]

CAPSTONE PROJECT INFORMATION TECHNOLOGY

Ho Chi Minh City, August, 2021

S KL0 09 1 5 9

LE DUC THINH

DEVELOPING A LAB MANAGEMENT SYSTEM

USING MERN STACK

INSTRUCTOR: THINH LE VINH, PhD STUDENT: TRINH MINH ANH

CAPSTONE PROJECT

Ho Chi Minh City, July 2021

DEVELOPING A LAB MANAGEMENT SYSTEM

USING MERN STACK

STUDENT NAME: ANH TRINH MINH

PROJECT CONTENT

Name of student: Anh Trinh Minh Student ID: 17110003 Name of student: Thinh Le Duc Student ID: 17110076 Major: Information Technology

Topic: Developing a lab management system using MERN Stack

Project title: Lab Management

Instructor: Thinh Le Vinh Ph.D

Content:

Theory:

- Survey the current needs of a system to manage the labs

- Investigate related systems that existed in the market

Practice: Apply earned knowledge to develop a system managing the labs

Execution time:

Phase 1 from October 5, 2020, to January 4, 2021

Phase 2 from February 22, 2021, to June 30, 2021

Signature of student:

Signature of student:

Ho Chi Minh, June 30, 2021

(Name and signature) (Name and signature)

COMMENTARY OF INSTRUCTOR

Student name: Anh Trinh Minh Student ID: 17110003

Thinh Le Duc 17110076

Major: Information Technology Topic: Developing a lab management system using MERN Stack Project title: Lab Management Name of instructor: Thinh Le Vinh Ph.D COMMENTARY 1 On content of topic & workload done:

2 Advantage:

3 Disadvantage:

4 Recommend for defense or not?

5.Rating type:

6 Mark: (By word: )

Ho Chi Minh, ……… 2021

INSTRUCTOR (Name and signature)

*** COMMENTARY OF REVIEWER

Student name: Anh Trinh Minh Student ID: 17110003

Thinh Le Duc 17110076

Major: Information Technology Topic: Developing a lab management system using MERN Stack Project title: Lab Management Name of reviewer:

COMMENTARY 1 On content of topic & workload done:

2 Advantage:

3 Disadvantage:

4 Recommend for defense or not?

5.Rating type:

6 Mark: (By word: )

Ho Chi Minh, ……… 2021

REVIEWER (Name and signature)

*** ACKNOWLEDGMENTS

The team would like to express our sincere thanks to Mr Thinh Le Vinh, the most enthusiastic lecturer that gave us the chance to meet this project He always stays close to our ideas to give us the best advice that helps our thoughts come to practical products Thank Mr Thinh, we have never given up on any challenging tasks and features

On behalf of the time, Mr Van Nguyen Tran Thi saved the project by giving precise requirements and adjusting the wrong features Without his help, we went on the wrong way so far

The system occurred in two phases, the initial idea has come from the course new technologies on software engineering, and Mr Thinh encouraged us to develop this potential material for the capstone project However, the limitation of experiences in technologies and social work might prevent us from making perfect software that satisfies everyone We would love to receive feedbacks to make the software better

Sincerely thanks

TABLE OF CONTENTS

Acknowledgments i

Table of Contents ii

List of figures v

List of tables x

Preface xiii

Chapter 1: Introduction 1

1.1 Related works 2

1.2 Project objectives 2

Chapter 2: Backgrounds 3

2.1 Overview of React 4

2.1.1 Introduction to React 4

2.1.2 Features 4

2.1.3 Advantages 4

2.1.4 Disadvantages 4

2.2 Redux 4

2.3 React Native 5

2.3.1 Introduction to React Native 5

2.3.2 Advantages 5

2.3.3 Disadvantages 5

2.4 Express.JS 5

2.5 MongoDB 5

Chapter 3: Requirements analysis 6

3.1 System description 7

3.1.1 Lab management web app 7

3.1.2 Mobile application 8

3.1.3 Node.JS server 9

3.1.4 Python Flask server 9

3.2 Requirement analysis 10

3.2.1 Administration web module 10

3.2.1.1 Business functional requirements 10

3.2.1.2 System functional requirements 14

3.2.1.3 Non-functional requirements 14

3.2.2 Lecturer web module 15

3.2.2.1 Business functional requirements 15

3.2.2.2 System functional requirements 16

3.2.2.3 Non-functional requirements 16

3.2.3 Lecturer mobile application 17

3.2.3.1 Business functional requirements 17

3.2.3.2 System functional requirements 17

3.2.3.3 Non-functional requirements 17

3.3 Requirement modeling 18

3.3.1 Use-case diagram 18

3.3.1.1 Administration web module 18

3.3.1.2 Lecturer web module 19

3.3.1.3 Lecturer mobile module 20

3.3.2 Scenarios 20

3.3.2.1 Administration web module 20

3.3.2.2 Lecturer web module 63

3.3.2.3 Lecturer mobile module 80

Chapter 4: Software design 87

4.1 Sequence diagrams 88

4.1.1 Administration web module 88

4.1.2 Lecturer web module 127

4.1.3 Lecturer mobile module 144

4.2 Class diagram 151

4.3 Database design 152

4.3.1 Logical diagram 152

4.3.2 Table detail 152

4.4 User interface design 164

4.4.1 Administration web module 164

4.4.2 Lecturer web module 206

4.4.3 Lecturer mobile module 221

Chapter 5: Implementation and testing 228

5.1 Implementation 229

5.2 Test plan 229

5.2.1 Test scenarios 229

5.2.2 Test result 231

Chapter 6: Conclusion 248

4.1 Results 249

4.2 Strengths 249

4.3 Drawbacks 249

4.4 Source code 249

4.5 Future works 250

References 251

Task Distribution 252

LIST OF FIGURES

Figure 1 Use case diagram (admin) 18

Figure 2 Use case diagram (lecturer web) 19

Figure 3 Use case diagram (lecturer mobile) 20

Figure 4 Search academic year sequence diagram 88

Figure 5 Start an academic year sequence diagram 89

Figure 6 Close an academic year sequence diagram 90

Figure 7 Edit an academic year sequence diagram 91

Figure 8 Start a semester sequence diagram 92

Figure 9 Close a semester sequence diagram 93

Figure 10 Edit semester sequence diagram 94

Figure 11 Search teachings sequence diagram 95

Figure 12 Open registration sequence diagram 96

Figure 13 Close registration sequence diagram 97

Figure 14 Generate schedule sequence diagram 98

Figure 15 Search courses sequence diagram 99

Figure 16 Create new course sequence diagram 100

Figure 17 Import courses sequence diagram 101

Figure 18 Export courses sequence diagram 102

Figure 19 Download courses template 102

Figure 20 Edit a course sequence diagram 103

Figure 21 Delete a course 104

Figure 22 Search labs 105

Figure 23 Create new lab 106

Figure 24 Import labs sequence diagram 107

Figure 25 Export labs sequence diagram 108

Figure 26 Download lab template sequence diagram 108

Figure 27 Edit a lab sequence diagram 109

Figure 28 Delete a lab sequence diagram 110

Figure 29 Search requests sequence diagram 111

Figure 30 View request detail sequence diagram 112

Figure 31 Approve request sequence diagram 113

Figure 32 Deny request sequence diagram 114

Figure 33 Add comment sequence diagram 115

Figure 34 View attendance sequence diagram 116

Figure 35 Export attendance sequence diagram 117

Figure 36 View schedule sequence diagram 118

Figure 37 Export schedule sequence diagram 119

Figure 38 Export theory rooms 119

Figure 39 Search users sequence diagram 120

Figure 40 Create new user sequence diagram 121

Figure 41 Edit user sequence diagram 122

Figure 42 Delete user sequence diagram 123

Figure 43 Delete face ID sequence diagram 124

Figure 44 Login sequence diagram 125

Figure 45 Logout sequence diagram 126

Figure 46 Search teachings (lecturer web) sequence diagram 127

Figure 47 Download teachings template (lecturer web) sequence diagram 128

Figure 48 Import teachings (lecturer web) sequence diagram 129

Figure 49 Add a teaching (lecturer web) sequence diagram 130

Figure 50 Edit teaching (lecturer web) sequence diagram 131

Figure 51 Delete teaching (lecturer web) sequence diagram 132

Figure 52 Search labs (lecturer web) sequence diagram 133

Figure 53 Search requests (lecturer web) sequence diagram 134

Figure 54 View request detail (lecturer web) sequence diagram 135

Figure 55 Add comment (lecturer web) sequence diagram 136

Figure 56 Search courses (lecturer web) sequence diagram 137

Figure 57 View schedule (lecturer web) sequence diagram 138

Figure 58 Export schedule (lecturer web) sequence diagram 139

Figure 59 Make request to add extra class (lecturer web) sequence diagram 140

Figure 60 Make request to change lab usage (lecturer web) sequence diagram 141

Figure 61 Login (lecturer web) sequence diagram 142

Figure 62 Logout (lecturer web) sequence diagram 143

Figure 63 View schedule (lecturer mobile) sequence diagram 144

Figure 64 Check in (lecturer mobile) sequence diagram 145

Figure 65 Check out (lecturer mobile) sequence diagram 146

Figure 66 View account info (lecturer mobile) sequence diagram 147

Figure 67 Verify face ID (lecturer mobile) sequence diagram 148

Figure 68 Login (lecturer mobile) sequence diagram 149

Figure 69 Log out (lecturer mobile) sequence diagram 150

Figure 70 Class diagram 151

Figure 71 Logical diagram 152

Figure 72 Select role in signin page 164

Figure 73 Select Google account to sign in 165

Figure 74 Sidebar (admin) 166

Figure 75 Navigation bar (admin) 168

Figure 76 Academic year page (admin) 169

Figure 77 Start academic year modal (admin) 171

Figure 78 Edit academic year (modal) 173

Figure 79 Start semester modal 175

Figure 80 Close semester modal (admin) 176

Figure 81 Edit semester modal (admin) 177

Figure 82 Registration page (admin) 179

Figure 83 Close registration modal (admin) 180

Figure 84 Start registration modal (admin) 181

Figure 85 Select course modal 183

Figure 86 Course page (admin) 184

Figure 87 Import course modal (admin) 185

Figure 88 New course modal (admin) 186

Figure 89 Edit course modal (admin) 187

Figure 90 Delete course modal (admin) 188

Figure 91 Lab page (admin) 189

Figure 92 Import labs modal (admin) 190

Figure 93 New lab modal (admin) 191

Figure 94 Edit lab modal (admin) 192

Figure 95 Delete lab modal (admin) 193

Figure 96 Request page (admin) 194

Figure 97 Request detail page (admin) 196

Figure 98 User page (admin) 197

Figure 99 New user modal (admin) 198

Figure 100 Edit a user modal (admin) 200

Figure 101 Delete face ID modal (admin) 202

Figure 102 Delete user modal (admin) 203

Figure 103 Attendance page (admin) 204

Figure 104 Schedule page (admin) 205

Figure 105 Sidebar (lecturer web) 206

Figure 106 Registration page (lecturer web) 208

Figure 107 Import teachings modal (lecturer web) 209

Figure 108 New teaching modal (lecturer web) 210

Figure 109 Request page (lecturer web) 212

Figure 110 Request detail page (lecturer web) 214

Figure 111 Schedule page (lecturer web) 215

Figure 112 Add extra class request (lecturer web) 217

Figure 113 Change lab usage request (lecturer web) 219

Figure 114 Login screen (lecturer mobile) 221

Figure 115 Schedule screen (lecturer mobile) 222

Figure 116 Check attendance modal (lecturer mobile) 223

Figure 117 Check attendance screen (lecturer mobile) 224

Figure 118 Account screen (lecturer mobile) 225

Figure 119 Verification modal (lecturer mobile) 226

Figure 120 Verification screen (lecturer mobile) 227

Figure 121 Expected & Actual result of TC_SA_01 232

Figure 122 Expected & Actual result of TC_SA_02 233

Figure 123 Expected & Actual result of TC_OR_01 235

Figure 124 Expected & Actual result of TC_IT_01 237

Figure 125 Expected & Actual result of TC_IT_02 238

Figure 126 Expected & Actual result of TC_GS_01 240

Figure 127 Expected & Actual result of TC_GS_02 241

Figure 128 Expected & Actual result of TC_GS_01 243

Figure 129 Expected & Actual result of TC_GS_02 244

Figure 130 Expected & Actual result of TC_CI_01 246

Figure 131 Expected & Actual of TC_CI_02 247

LIST OF TABLES

Table 1 Business functional requirements for admin web app 10

Table 2 System functional requirements (admin web app) 14

Table 3 Non-functional requirements (admin web app) 14

Table 4 Business functional requirements (lecturer web application) 15

Table 5 System functional requirements (lecturer web) 16

Table 6 Non-functional requirements (lecturer web) 16

Table 7 Business functional requirements (lecturer mobile) 17

Table 8 System functional requirements (lecturer mobile) 17

Table 9 Non-functional requirements (lecturer mobile) 17

Table 10 Academic year table 152

Table 11 Semester table 154

Table 12 Registration table 155

Table 13 Course table 156

Table 14 RegistrableCourse table 156

Table 15 Teaching table 157

Table 16 Lab table 158

Table 17 Lab usage table 159

Table 18 User table 160

Table 19 Request table 161

Table 20 Comment table 163

Table 21 Select role page operations table 164

Table 22 Login page operations table 165

Table 23 Sidebar (admin) operations table 166

Table 24 Navigation bar operations table 168

Table 25 Academic year page operations table 169

Table 26 Start academic year modal operations table 171

Table 27 Edit academic year operations table 173

Table 28 Start semester modal operations table 175

Table 29 Close semester modal operations table 176

Table 30 Edit semester modal operations table 177

Table 31 Registration page operations table 179

Table 32 Close registration modal operations table 180

Table 33 Start registration modal operations table 181

Table 34 Select course modal operations table 183

Table 35 Course page operations table 184

Table 36 Import course modal operations table 185

Table 37 New course modal operations table 186

Table 38 Edit course modal operations table 187

Table 39 Delete course modal operations table 188

Table 40 Lab page operations table 189

Table 41 Import course modal operations table 190

Table 42 New lab modal operations table 191

Table 43 Edit lab operations table 192

Table 44 Delete lab modal operations table 193

Table 45 Request page operations table 194

Table 46 Request detail page operations table 196

Table 47 User page operations table 197

Table 48 New user modal operations table 198

Table 49 Edit a user modal operations table 200

Table 50 Delete face ID modal operations table 202

Table 51 Delete user modal operations table 203

Table 52 Attendance page operations table 204

Table 53 Schedule page operations table 205

Table 54 Sidebar (lecturer web) operations table 206

Table 55 Registration page (lecturer web) operations table 208

Table 56 Import teachings (lecturer web) operations table 209

Table 57 New teaching modal (lecturer web) operations table 210

Table 58 Request page lecturer web operations table 212

Table 59 Request detail page (lecturer web) operations table 214

Table 60 Schedule page (lecturer web) operations table 215

Table 61 Add extra class request (lecturer web) operations table 217

Table 62 Change lab usage request (lecturer web) operations table 219

Table 63 Login (lecturer mobile) operations table 221

Table 64 Schedule screen (lecturer mobile) operations table 222

Table 65 Check attendance modal (lecturer mobile) operations table 223

Table 66 Check attendance screen (lecturer mobile) operations table 224

Table 67 AccountScreen (lecturer mobile) operations table 225

Table 68 Verification modal operations table 226

Table 69 Verification screen operations table 227

Table 70 Test scenarios 229

Table 71 Test result of start academic year function 231

Table 72 Test result open registration function 234

Table 73 Test result import teachings function 236

Table 74 Test results generate schedule function 239

Table 75 Test result make request to change lab usage function 242

Table 76 Test result check in function 245

Table 77 Task distribution 252

1

CHAPTER 1: INTRODUCTION

2

1.1 Related works

Information technology is changing the way people work significantly However, it is hard and time-consuming to apply modern technologies in a complicated field such as education

The first target of this project is the checking for attendance machine We find out some common solutions provided with varied costs

• Using fingerprint: cheapest, easy to use; however, the fingerprint reader usually fails to recognize, it takes each user about 3 to 5 minutes, or even more, to be accepted

• Using electromagnetic card: more expensive than using fingerprint, works well

in almost any condition Nevertheless, the point is that if the user forgets the card, he/she cannot check for attendance It is a problem of convenience

• Using face recognizer: high accuracy solution The user needs not wait for minutes or bring the card anymore Nevertheless, the problem now is financial investment about four times more than using fingerprints

Secondly, it is a crucial need that all lab usage must be tracked Since the checking for attendance machine is a standalone system Then to integrate more features will cost a lot of money and effort

Thirdly, lecturers, in some cases, might need to adjust their schedule, lab usage However, this work requires manually contacting the administrator to accept

Last but not least, it is painful to go to many places to solve a minor issue All users need

a solution to connect the feature in one place with full-featured extensions

The core feature of the system is scheduling The team must have an algorithm so that the labs will be distributed to the practical teachings This is a solution for reducing conflict in registering to teach

3

CHAPTER 2: BACKGROUNDS

React provides a few built-in hooks like useState, useContext, useReducer, and useEffect

[3] Others are documented in the Hooks API Reference useState and useEffect, which are the most used, control state and side effects, respectively

2.1.3 Advantages

- Virtual DOM in React makes the user experience better and developer’s work faster [4]

- Reusing React components saves time significantly

- One-direction data flow in ReactJS provides a stable code

2.1.4 Disadvantages

- The environment constantly changes, and developers must regularly relearn new ways of doing things Everything is evolving, and some developers are not comfortable with keeping up with such a pace [5]

- ReactJS uses JSX It is a syntax extension allowing mixing HTML with JavaScript It looks like an old spaghetti code

2.2 Redux

Redux is a predictable state management for JavaScript application As the application grows, it becomes challenging to keep it organized and maintain data flow Redux solves this problem by managing the application’s state with a single global object called Store Redux fundamental principles help in maintaining consistency throughout the application, which makes debugging and testing easier

5

More importantly, it gives live code editing combined with a time-traveling debugger It

is flexible to go with any view layer such as React, Angular, Vue

2.3 React Native

2.3.1 Introduction to React Native

In 2017 when ReactJS released, Facebook created React Native While the ReactJS library is developed to create web interfaces, React Native is a hybrid app-development framework for iOS and Android that allows developers to reuse up to 95 percent of code, leaving the rest to design platform-specific interfaces

2.3.2 Advantages

- React Native uses JavaScript – a fast and popular programming language [6]

- Native controls and native modules in React Native improve performance

- React Native contains all ReactJS features aimed at improving UI

2.3.3 Disadvantages

- React Native has to update when iOS or Android updates their SDKs React Native’s team should integrate a code library with new software Furthermore, despite working pretty fast, they cannot update every part of the APIs at the time Therefore, the complete synchronization between React Native and new SDKs often takes too long

- React Native inherits the main ReactJS disadvantage The community is young,

so the available documentation is lacking, especially for integration with additional tools

2.4 Express.JS

Express.js, or simply Express, is a backend web application framework for Node.js, released as free and open-source software under the MIT License It is designed for building web applications and APIs It has been called the de facto standard server framework for Node.js [7]

6

CHAPTER 3: REQUIREMENTS ANALYSIS

7

3.1 System description

The system has two main actors, and they are lecturers and administrators The system includes a web application called “Lab Management,” a Node.JS server, a Python Flask server (Face ID server), and a mobile application

3.1.1 Lab management web app

This web is for both lecturers and administrators

For administrator: The administrator has the right to access all features

• Manage academic year: when the admin creates a new academic year, the system automatically generates three semesters with 17 weeks, 17 weeks, and 8 weeks accordingly There is only one opening academic year at the time, so is the semester

To create a new academic year, the admin must close the opening academic year, if any The start day of an academic year must be Monday, and this day can be modified later on

• Manage semester: as mentioned, there is only one opening semester To open a new one, the opening must be closed The start day of a semester must be Monday, and this day can be modified later on

• Manage registration: there are many registrations batch in an academic year It is only available for the lecturers to submit their teaching schedule when registration

is open A registration batch might be opened for all courses or specific courses, the Admin must define the range of time and right after the deadline, the registration will close itself, and the system will disable lecturers from submitting the teaching schedule

• Manage courses: admin can add a single course by filling the popup Another way

is that the admin can create many courses by uploading an excel file The system provides a template, and the admin can base on that template to fulfill the form and submits it The system will parse the excel file and update accepted data only; the missing fields or leave empty data will be dropped Any course after being created can also be modified The web app can export an excel file including all courses’ information

• Manage labs: similar to the feature managing courses

• Manage users: Firstly, the admin must add the account information to the database

In this step, the user email must be an organization email, and the role is set to default

as the lecturer role The system implements a feature to allow users to sign in with a Google account Once the email is registered, the user can use the Google email of the organization to sign in Admin can delete user, delete user’s face id and modify user’s information

8

• Manage schedule: after the deadline of registration, the admin should have some teaching submitted by lecturers Then admin can use these teachings, along with the existing labs, to create the schedule In the schedule, each cell might be called a lab usage Admin can export the schedule for lab usage and export the idle theory room

• Manage request: If a lecturer needs to change the lab usage or add an extra class, the lecturer must raise the request and provide detailed information Now admin can decide whether the request is suitable and approve it, or else deny it Otherwise, the request will be in pending status

• Manage lab usage: this is a minor feature When the admin generates a schedule, lab usages are created Alternatively, when a request to change lab usage, that lab usage

is updated Admin cannot interact directly with the existing lab usages Only when

a lecturer raises a request, the admin can do

• Manage attendance: admin can view the attendance information filtered by week If the lecturer had checked in or checked out, the information now is available; if not,

it says pending Admin can export an excel file that includes all attendance information

For lecturer:

• Manage teachings: when a registration batch is open, the lecturer can add single teaching manually or upload a file to add many teachings Before the deadline of the registration batch, the lecturer can edit, remove any teaching

• View courses: this feature provides this information on all available courses The lecturer can use this information in order to add new teachings

• View labs: similar to viewing coursers

• Manage lab usage: lecturer can request to modify lab usage such as change lab room, change periods, change day or week occur By default, the lecturer has half of the semester time for the practical week to use the lab, but in case of needs, the lecturer can require to add an extra class After the request is raised, the admin will review and decide to approve it or deny it

3.1.2 Mobile application

Lecturers are provided a mobile application that can runs in Android and iOS with these features:

• Sign in/out of the application using a Google work account

• Verify Face ID: using the camera to capture the face and send it to the Face ID server The lecturer must send seven verified pictures A picture is verified when the server return result was saying successfully Once the user’s Face ID is verified (7 pictures are passed), on the screen account, the status will change to “Face ID: Verified,” and the lecturer can check-in and check-out

3.1.3 Node.JS server

By using the Express.JS framework, Node is a powerful engine This is also the primary system server which process request and response The team had implemented some middleware in order to keep the authentication function smoothly and correctly

The heart of the Node server is the scheduling algorithm The idea behind this is to sort the labs and teachings in order of priority, so that propose the best utilization strategy of the resources

3.1.4 Python Flask server

The team implements Face ID service in order to check for attendance using Deep Learning

It is no doubt that python is a powerful programming language to process data Since Node.JS cannot be merged with python because they are in a different platform, the team built another server called “Python Flask server” or “Face ID server.” This server is powered by Flask, a framework to handle HTTP requests The team implements a library named InsightFace

Face ID server receives input as a list of pictures or a single picture The server uses net50 architecture and ArcFace loss-function to process data into an array of 512 elements representing the features of a face

Res-The network used by InsightFace is pre-trained with a million faces, an accuracy of 97.64% After utilizing the pre-trained model with Deep Learning, the server has excellent results

in weight and loss value Then the team uses Machine Learning to classify the embedding data (array of 512 elements) Now the team uses SVM (support vector machine), which will classify different faces and return a number of prediction probabilities Only when the probability is greater than 75% then the server return accepting, else return failure

10

3.2 Requirement analysis

3.2.1 Administration web module

3.2.1.1 Business functional requirements

Table 1 Business functional requirements for admin web app

No Function Type Constraint /

Formula code

Form code

Note

1 Search academic

years

Search Show list of academic years

Sort item by newest first

2 Start an

academic year

Storage Can operate only where is no

opening academic year Start day must be on Monday

3 Close an

academic year

Storage Can operate only where there is

no opening semester Cannot edit anymore

academic year

Storage Can edit while the academic

year is opening Auto-generate three semesters; semester 1 is opening, semesters 2 and 3 are future semesters

5 Start a semester Storage Can operate only when there is

no opening semester Start only

on Monday Default values of 3 semesters are 17 weeks, 17 weeks, and 8 weeks

6 Close a semester Storage Close the opening semester

Cannot edit anymore Cannot open any registration until a new semester is opened

7 Edit semester Storage Update the number of weeks

and start day of the semester

8 Search teachings Search Display list of teachings

grouped by registration batch

By default, display the latest registration batch

registration

Storage Create a new registration

System auto assign name for

11

registration batch Admin cannot pick time in the past By default, all courses are selected

to be applied for new registration batch

10 Close

registration

Storage Admin can close manually or

leave it close after end time Admin cannot reopen registration after close it

11 Generate

schedule

Storage Create new schedule if no

schedule is existed Otherwise, update schedule and keep existing teachings unchanged Lecturers must submit teachings If there is no teaching, cannot generate schedule All registration batches must be closed to generate schedule

12 Search courses Search By default, display all courses

Admin can input name or ID of the course and press enter to search If found data, display it, else display a message saying there is nothing to show

13 Create new

single course

Storage Require admin to input all fields

before submitting Default type

of course is theory

14 Create a bundle

of new courses

Storage A template is available to

download All fields in the template must be filled out Web app must parse the excel file and show how many records are accepted and not accepted

15 Export courses Report Export existing courses

16 Download

course template

Report

17 Edit course Storage Cannot edit course id

18 Delete course Storage Mark the course as hidden, still

store it in database

12

19 Search labs Search By default, display all labs User

input lab name and press enter

to search If data found, display

it, otherwise, display message saying “nothing to show”

20 Create a new

single lab

Storage Lab name is unique User must

fill out all required fields before submit

21 Import lab Storage User have to fill out all required

fill in the excel file System must parse submitted data and display how many records are accepted and how many are not

22 Export labs Report Export excel file including

existing labs

23 Download lab

template

Report

24 Edit a lab Storage

25 Delete a lab Storage Mark the lab as hidden, still

store the lab on database

26 Search requests Search By default, display all pending

request User input request title and press enter to search Provide tools for filter by type (pending, approved, denied), time (newest, oldest) or by author

27 View request

detail

Report If request is to modify lab usage,

display current lab usage and expecting lab usage in 2 cards

If request to add extra class, display the expecting lab usage only Cannot edit information of request

28 Approve request Storage Mark the request as approved

Auto update that lab usage in schedule

29 Deny request Storage Mark the request as denied

32 Search users Search By default, display all users

Admin input user email or id and press enter to search If found matched data, display it, else display message saying,

Storage Face ID server delete all face

records of that user User face id status now is not verified

36 Delete user Storage Mark user as hidden, but still

store in database

37 View schedule Report Display lab by capacity

descending Each teaching is a card with red, green, blue color standing for 3 shifts (morning, afternoon, and evening) Display the cell in a day fit with number of shifts, if there is no lab usage, minimize the cell Each lab usage must include course name, lecturer name, periods, checking in time and checking out time

38 Export schedule Report Export the existing schedule

39 Export theory

room

Report Export list of theory rooms

those are idle according today of week and shift

14

3.2.1.2 System functional requirements

Table 2 System functional requirements (admin web app)

1 Environment +The database is hosted in the cloud

+Internet access required

2 Authentication Using Google authentication service to login before

enter system

3.2.1.3 Non-functional requirements

Table 3 Non-functional requirements (admin web app)

1 The application can be updated to

meet user requirements

5 + UI component and source code can

be reused for future development

Re-usability

15

3.2.2 Lecturer web module

3.2.2.1 Business functional requirements

Table 4 Business functional requirements (lecturer web application)

No Function Type Constraint/

Formula code

Form code

Note

1 Search teachings Search By default, display all

teachings belong to the lecturer

2 Download teaching

template

Report

teachings based on the template provided by the system

the registration

teaching in a registration

6 Delete teaching Storage Delete an existing

teaching in a registration

Storage Create a request to

add extra class

15 Make request to change

lab usage

Storage Create a request to

change lab usage

16 Delete a pool Storage

3.2.2.2 System functional requirements

Table 5 System functional requirements (lecturer web)

1 Authentication Every user needs to login to use

the app

3.2.2.3 Non-functional requirements

Table 6 Non-functional requirements (lecturer web)

1 The application can be

updated to meet user

source code can be

reused for future

development

Re-usability

17

3.2.3 Lecturer mobile application

3.2.3.1 Business functional requirements

Table 7 Business functional requirements (lecturer mobile)

No Function Type Constraint/

Formula code

Form code

Note

lecturer

using their face ID

out using their face ID

information

5 Verify face ID Storage Lecturer can register

their face ID

3.2.3.2 System functional requirements

Table 8 System functional requirements (lecturer mobile)

1 Authentication Every user needs to

login to use the app

3.2.3.3 Non-functional requirements

Table 9 Non-functional requirements (lecturer mobile)

1 The application can be updated to

meet user requirements

4 + UI component and source code

can be reused for future

development

Re-usability

18

3.3 Requirement modeling

3.3.1 Use-case diagram

3.3.1.1 Administration web module

Figure 1 Use case diagram (admin)

19

3.3.1.2 Lecturer web module

Figure 2 Use case diagram (lecturer web)

20

3.3.1.3 Lecturer mobile module

Figure 3 Use case diagram (lecturer mobile)

3.3.2 Scenarios

3.3.2.1 Administration web module

1) Search academic years

Name Search academic years

Brief description Show list of academic years Sort item by newest first

Actor(s) Authorized web admin

Flow of events

1 The admin goes to the academic year page

2 The system displays a list of academic years

3 The admin enters academic year name in the search box

4 The system filters the academic list and displays it to admin

21

Authorized admin Admin has logged into the system

Exit condition(s)

Success The admin can see a list of academic years

Failed The admin cannot see a list of academic year

22

2) Start an academic year

Name Start an academic year

Brief description Can operate only where is no opening academic year Start

day must be on Monday

Actor(s) Authorized web admin

Flow of events

1 The admin clicks “Start academic year” button

2 The system displays “Start academic year” form

3 The admin enters academic year information Once the form is completed, the admin can submit the form

4 The system receives the form and sends it to server After starting an academic year, the system automatically creates three new semesters for the academic year After that, the system displays success message and close the form

Success Start academic year successfully

Failed Fail to Start academic year