Tutor Searching Portal

By

Supervisor:
 1

Acknowledgments
 2

Their dedication to education and research has greatly contributed to my learn-

ing experience.
 3

Abstract

Education plays a decisive role in shaping the future and finding the right tutor can
very importantly impact a student’s learning capabilities. This Project aims to
develop a web-based system which helps the students to find the tutors providing
their services all over Pakistan. This web base system will search the tutors in
nearby areas. The System will enable students to search for tutors and gives them
the option to communicate with them through a built-in chat system.
To ensure reliability, there will be a proper admin panel through which experts
will review the application of tutor registrations. And, the platform will provide
the study-related materials that will be verified before delivering it to students.
This will make sure that students will have access to quality learning materials.
By developing this software, which would be interactive and user friendly, it will
provide students to tutor search in areas where it is really hard to find someone.
This project aims to make education more accessible and reachable for students
who want academic assistance.
 4

Contents

Acknowledgments 1

Abstract 3

List of Figures 8

1 Software Project Management Plan 9

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Existing Systems and Differentiation . . . . . . . . . . . . . 10
1.3 Project Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Project Organization . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Software Process Model . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . 11
1.4.3 Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.4 Software Tools . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Project Management Plan . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.3 Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Software Requirements Specifications 15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Major Functions . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Major Inputs and Outputs . . . . . . . . . . . . . . . . . . . 16
2.2.4 Definitions, Acronyms, and Abbreviations . . . . . . . . . . 16
2.3 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Software Product Features . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Software System Attributes . . . . . . . . . . . . . . . . . . . . . . 17
2.6 List of Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8 Use Case Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 20
CONTENTS 5

2.9 System Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . 20

3 Software Design Description 29

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Alternative Design Considerations . . . . . . . . . . . . . . . 30
3.1.3 Key Objectives for Design . . . . . . . . . . . . . . . . . . . 30
3.1.4 Requirements Traceability Matrix . . . . . . . . . . . . . . . 31
[Link] Functional Requirements . . . . . . . . . . . . . . . 31
[Link] Non-Functional Requirements . . . . . . . . . . . . 32
3.2 System Architecture Design . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Alternate Approach . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Architectural Diagram . . . . . . . . . . . . . . . . . . . . . 33
3.3 Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Activity Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Software Implementation 44
4.1 System Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Backend Technologies . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Frontend Technologies . . . . . . . . . . . . . . . . . . . . . 45
4.2.3 Development & Deployment Tools . . . . . . . . . . . . . . . 45
4.3 Data Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 API Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 UI Screen Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Software Test Documentation 52

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Test Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 User Authentication Test Cases . . . . . . . . . . . . . . . . 53
5.3.2 User Registration and Approval Test Cases . . . . . . . . . . 54
5.3.3 Tutor Search Functionality Test Cases . . . . . . . . . . . . 55
5.3.4 Chat Between Student and Tutor Test Cases . . . . . . . . . 55
5.3.5 Session Scheduling Test Cases . . . . . . . . . . . . . . . . . 55
5.3.6 Learning Resources Test Cases . . . . . . . . . . . . . . . . . 56
5.4 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
CONTENTS 6

6 Conclusion and Future Work 58

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.1 DevOps and Deployment . . . . . . . . . . . . . . . . . . . . 58
6.2.2 Performance and Optimization . . . . . . . . . . . . . . . . 59
6.2.3 Platform Expansion . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.4 Security Enhancements . . . . . . . . . . . . . . . . . . . . . 59
6.2.5 User Engagement . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliography 60
 7

List of Figures

1.1 Gantt Chart illustrating project timeline and phases . . . . . . . . . 14

2.1 System Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Sequence Diagram for Login . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Sequence Diagram for Search for Tutor . . . . . . . . . . . . . . . . 21
2.4 Sequence Diagram for Chat Between Student and Tutor . . . . . . 22
2.5 Sequence Diagram for Request to Schedule a Session . . . . . . . . 23
2.6 Sequence Diagram for Approve or Reject Session Request . . . . . . 24
2.7 Sequence Diagram for Access Resources . . . . . . . . . . . . . . . . 24
2.8 Sequence Diagram for Submit Subject Resources . . . . . . . . . . . 25
2.9 Sequence Diagram for Approve or Reject Subject Resources . . . . 25
2.10 Sequence Diagram for Reporting Issues to Admin . . . . . . . . . . 26
2.11 Sequence Diagram for Register as Tutor . . . . . . . . . . . . . . . 26
2.12 Sequence Diagram for Approve or Reject Tutor Application . . . . . 27
2.13 Sequence Diagram for Create and Post Quiz . . . . . . . . . . . . . 27
2.14 Sequence Diagram for Submit Quiz . . . . . . . . . . . . . . . . . . 28
2.15 Sequence Diagram for Pay Fee . . . . . . . . . . . . . . . . . . . . . 28

3.1 Architectural Design of Tutor Search Platform . . . . . . . . . . . . 33

3.2 Domain Model of Tutor-Student Platform . . . . . . . . . . . . . . 34
3.3 Activity Diagram for Login . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Activity Diagram for Search for Tutor . . . . . . . . . . . . . . . . 37
3.5 Activity Diagram for Chat between Student and Tutor . . . . . . . 37
3.6 Activity Diagram for Request to Schedule a Session . . . . . . . . . 38
3.7 Activity Diagram for Approve or Reject Session Request . . . . . . 38
3.8 Activity Diagram for Access Resources . . . . . . . . . . . . . . . . 39
3.9 Activity Diagram for Report Issues to Admin . . . . . . . . . . . . 39
3.10 Activity Diagram for Submit Subject Resources . . . . . . . . . . . 40
3.11 Activity Diagram for Approve or Reject Subject Resources . . . . . 40
3.12 Activity Diagram for Register as Tutor . . . . . . . . . . . . . . . . 41
3.13 Activity Diagram for Approve or Reject Tutor Application . . . . . 41
3.14 Activity Diagram for Pay Fees . . . . . . . . . . . . . . . . . . . . . 42
3.15 Activity Diagram for Create and Post Assessment/Quiz . . . . . . . 43
LIST OF FIGURES 8

4.1 Admin Portal UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Tutor Portal UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Student Portal UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Tutor Application Portal UI . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Pending Application View in Admin Portal . . . . . . . . . . . . . . 50
4.6 Chatbot UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
 9

Chapter 1

Software Project Management Plan

1.1 Introduction
It is essential to find the right tutor for effective learning, and most of the time
students do not know how to search for them, which hinders their communication.
This project introduces a tutor search platform to connect students with qualified
tutors in their locality to help such students, communicate with each other, and
access verified educational resources.
Thus, for making finding the tutor easy, direct interaction possible, and quality
study material assured, this system purports to make academic support more
accessible, efficient, and reliable for students.

1.2 Problem Definition

Students find availability of tutors for the academic requirements hard and a
real-time issue. The old traditional ways, like recommendations of some people
or through some posters in the city walls, are actually outdated, less reliable,
and take significant time to find a tutor. Besides, an absence of communication
between student and tutor can be deafeningly effective in learning hurdles.
The unavailability of Valid and trusted subject materials is another problem.
Most of the study material found online is of inferior quality, which means that
students can hardly understand the intricacies of certain topics. There should be
a System that provides a reliable environment for providing help to the students
and is also useful in making the online learning resources available and cheap.
Additionally, without a proper registration and verification process, students
may struggle to find tutors who meet their academic needs. A platform where
students are able to search for verified tutors to quickly and real-time communicate
with any such tutor can view authenticated study materials that can augment the
overall learning experience significantly.
This project seeks to solve these problems by creating an online tutor search
system that has a simple interface for students, a tutor verification system and
CHAPTER 1. SOFTWARE PROJECT MANAGEMENT PLAN 10

a database for educational resources verified by teachers, this project hopes to

alleviate these problems and establish a well-organized and effective learning en-
vironment.

1.2.1 Existing Systems and Differentiation

This platform focuses on immediate interaction between tutor and student rather
than live scheduled sessions or recorded courses, which makes it different from the
traditional e-learning platforms like Coursera, Udemy, or Khan Academy, or from
the tutoring marketplaces such as Wyzant or Preply. It allows students to find
a tutor in their area or online and chat with them instantly through a built-in
chat system. They get easy access to credible learning resources. In general, this
platform provides a more interactive, reliable, and personalized learning experience
compared to existing solutions by providing on-demand and flexible tutoring with
a focus on verification and affordability.

1.3 Project Deliverables

The project consists of the following key deliverables:

1. SPMP and SRS Documentation – Detailed Software Project Man-

agement Plan (SPMP) and Software Requirements Specification
(SRS) outlining the project’s scope, objectives, and functional require-
ments.

2. Complete Project Documentation – Comprehensive documentation cov-

ering all aspects of the project, including system architecture, design deci-
sions, and user guidelines.

3. Implementation and Development – This will involve fully integrated

execution of the program creating all intended functionalities.

4. Source Code – Complete code of the project will be shared via GitHub.

5. Final Product – A ready product for end users and tested platform with
deployment and usage in mind.
CHAPTER 1. SOFTWARE PROJECT MANAGEMENT PLAN 11

1.4 Project Organization

1.4.1 Software Process Model

The system is in development using Agile methodology which can be described to
have an iterative and incremental approach. As it is an individual project, I will
manage by continuously refining the features based on feedback and testing. The
process includes:

• Requirement Gathering & Analysis – Understanding system needs and

defining core functionalities.

• Design Phase – Creating wireframes, defining database schema, and plan-

ning API endpoints.

• Implementation – Developing frontend, backend, and database modules.

• Testing & Debugging – Ensuring system reliability and fixing issues.

• Deployment & Documentation – Hosting the final system and preparing

project documentation.

1.4.2 Roles and Responsibilities

I am the sole developer responsible for the entire project, with guidance from my
supervisor regarding best practices and system refinements.

1.4.3 Responsibilities
• Understanding and defining the project scope.

• Designing and developing both frontend and backend components.

• Implementing authentication and communication features.

• Ensuring smooth integration between different modules.

• Testing and debugging to enhance performance.

• Documenting the complete system for future reference.

CHAPTER 1. SOFTWARE PROJECT MANAGEMENT PLAN 12

1.4.4 Software Tools

• Frontend: [Link]

• Backend: [Link] with [Link]

• Database: MongoDB

• Authentication: JWT (JSON Web Token)

• Styling: CSS / Bootstrap / Tailwind CSS

• Version Control: Git and GitHub

1.5 Project Management Plan

1.5.1 Tasks
The project consists of several major tasks distributed across different phases:

1. Analysis Phase (Dec 2024 – Feb 10, 2025)

• Requirement Gathering
• Project Scope
• Use Case & Sequence Diagrams
• Software System Design & Architecture
• SRS Documentation Submission: Completing the Software Require-
ment Specification (SRS) document by Feb 10, 2025.
• Test Planning: Deciding on unit, acceptance, and API test cases before
implementation.

2. Design Phase (Feb 2025 – March 2025)

• High-Level System Design: Defining modules, data flow, and API end-
points.
• Database Schema Finalization: Structuring the MongoDB collections
and relationships.
• Low-Level Design: Creating detailed technical documentation for de-
velopers.

3. Implementation Phase (March 2025 – June 2025)

CHAPTER 1. SOFTWARE PROJECT MANAGEMENT PLAN 13

• Database & API Development: Building backend with [Link] and

[Link].
• Frontend Development: Creating UI components and state manage-
ment in [Link].
• Feature Integration: Implementing authentication, search, and messag-
ing.
• Enhancements & UI Improvements: Refining the system for better us-
ability.

4. Testing & Deployment Phase (June 2025 – July 2025)

• Executing Unit, Acceptance, and API Tests: Ensuring functionality

and reliability.
• Bug Fixes & Optimizations: Addressing issues and improving perfor-
mance.
• Final Documentation & Deployment: Preparing the system for submis-
sion.
• Project Submission: Completing and submitting the project by July
2025.

1.5.2 Description
The methodology utilized in the project follows a carefully defined Software De-
velopment Lifecycle (SDLC) to manage the progress of the project smoothly and
allow timely finishing. The First phase will be Analysis Phase (Dec 2024 – Feb 10,
2025), which is concerned with requirements gathering, project scope definition,
and preparing system diagrams, with the final submission of the SRS document on
Feb 10, 2025. After this, the Design Phase (Feb – March 2025) establishes a good
and solid foundation for the system architecture, which prepares itself for the way
to the actual coding. Then comes the real Implementation Phase (March – June
2025), which gives life to the project through the development of the frontend,
backend, and database using the MERN stack. Finally, the Testing & Deploy-
ment Phase (June – July 2025) secures a reliable system that has been rigorously
tested before the final submission scheduled in July 2025.

1.5.3 Gantt Chart

CHAPTER 1. SOFTWARE PROJECT MANAGEMENT PLAN 14

Figure 1.1: Gantt Chart illustrating project timeline and phases

 15

Chapter 2

Software Requirements Specifica-

tions

2.1 Introduction
This chapter defines and discusses the fundamental factors affecting the growth
and operation of the project. It gives a detailing high-level view of the aim of the
software, user capabilities, and functionalities.

2.2 Product Overview

The platform is a web-based system that can help students find tutors across
different subjects. The services will include a way for students and tutors to com-
municate easily through a user interface. The teachers will have the responsibility
of approving the resources prior to assigning them to students.

2.2.1 Stakeholders
• Users (Students): Seek and interact with tutors.

• Tutors: Register to offer their services and interact with students.

• Admin: Manages user registrations and monitors system activities.

• Teachers: Approve resources before sharing them with students.

2.2.2 Major Functions

• Search for Tutors: Students can search for tutors based on subjects and
availability.

• Tutor Registration: Tutors can register and provide their information.

• Resource Approval: Teachers approve resources related to subjects.

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 16

• Chatting: Students and tutors can communicate in real-time.

• Notifications: Admin notifies tutors about registration or required actions.

2.2.3 Major Inputs and Outputs

Major Inputs:

• Users input specific search criteria (subject, location, availability).

• Tutors provide details during registration.

• Teachers input criteria for approving resources.

Major Outputs:

• Students receive a list of available tutors matching their search criteria.

• Tutors receive notifications about their registration or actions.

• Approved resources are displayed to students.

• Real-time chat is provided for student-tutor interactions.

• Teacher can view the student requests.

2.2.4 Definitions, Acronyms, and Abbreviations

• UC: Use Case

• Users: Students using the platform to find tutors.

• Admin: The administrator responsible for managing the platform, includ-

ing approving tutors (resources) and overseeing platform settings.

• Tutor: The person offering tutoring services.

• Chat: The real-time messaging service between students and tutors.

2.3 Specific Requirements

The platform is accessible through any modern web browser on any operating sys-
tem, with responsive interfaces designed using Bootstrap. It uses HTTP/HTTPS
for secure communication, and optimal performance depends on a stable internet
connection and modern browser capabilities.
CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 17

2.4 Software Product Features

User Features:

• Browse Available Tutors: Users can search for tutors based on subjects,
availability, and ratings.

• Real-Time Chat with Tutors: Students can engage in real-time messag-

ing with tutors for discussions and clarifications.

• Schedule Sessions: Students can view tutor availability and schedule ses-
sions directly through the platform.

• Manage Tutor Profiles: Tutors can update their profiles with qualifica-
tions, available times, and subjects offered.

• Admin Panel for Management: Admin users can manage user accounts,
approve tutors, and oversee platform operations.

• Assignment and Work Submission: Students can upload assignments

and other coursework for tutors to review and provide feedback.

2.5 Software System Attributes

• Reliability: Ensures accurate query responses and smooth interaction be-
tween students and tutors.

• Availability: Accessible online from various devices, with prompt recovery

mechanisms in case of downtime.

• Security: Implements authentication and basic security measures to pre-

vent unauthorized access and common web attacks. Future enhancements
may include advanced encryption.

• Maintainability: The system is modular, making updates and issue reso-

lution easier for administrators.

• Portability: Works across different operating systems and browsers without

dependency on a specific platform.

• Performance: Optimized for real-time interactions and efficient data re-

trieval, ensuring smooth performance even under high user loads.
CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 18

2.6 List of Use Cases

1. Login

2. Search for Tutors

3. Chat between Student and Tutor

4. Request to Schedule a Session

5. Approve or Reject Session Request

6. Access Resources

7. Report Issues to Admin

8. Submit Subject Resources

9. Approve or Reject Subject Resources

10. Register as Tutor

11. Approve or Reject Tutor Application

12. Pay Fees

13. Create and Post Assessment/Quiz

14. Submit Assessment/Quiz

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 19

2.7 Use Case Diagram

Figure 2.1: System Use Case Diagram

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 20

2.8 Use Case Descriptions

Use Case 1: Login

Primary Actor: Student, Tutor, Admin
Pre-Conditions: The user must have a registered account.
Post-Conditions: The user is logged in and redirected to their dashboard.
Main Scenario:
1. The user selects the ”Login” option.

2. The system prompts for email and password.

3. The user enters valid credentials.

4. The system authenticates the user.

5. The user is redirected to their respective dashboard.

Alternative Scenario:
• If the user provides incorrect credentials: The system displays an error mes-
sage. The user may retry login or use the password recovery option.

Use Case 2: Search for Tutors

Primary Actor: Student
Pre-Conditions: The student must be logged in.
Post-Conditions: A list of tutors is displayed based on search criteria.
Main Scenario:
1. The student selects ”Search for Tutors”.

2. The system displays a search bar and filters (e.g., subject, availability, rat-
ing).

3. The student enters search criteria.

4. The system processes the request and displays a list of matching tutors.
Alternative Scenario:
• If no tutors match the search criteria: The system displays a ”No results
found” message. The student may modify the search filters.

2.9 System Sequence Diagrams

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 21

Figure 2.2: Sequence Diagram for Login

Figure 2.3: Sequence Diagram for Search for Tutor

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 22

Figure 2.4: Sequence Diagram for Chat Between Student and Tutor
CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 23

Figure 2.5: Sequence Diagram for Request to Schedule a Session

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 24

Figure 2.6: Sequence Diagram for Approve or Reject Session Request

Figure 2.7: Sequence Diagram for Access Resources

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 25

Figure 2.8: Sequence Diagram for Submit Subject Resources

Figure 2.9: Sequence Diagram for Approve or Reject Subject Resources

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 26

Figure 2.10: Sequence Diagram for Reporting Issues to Admin

Figure 2.11: Sequence Diagram for Register as Tutor

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 27

Figure 2.12: Sequence Diagram for Approve or Reject Tutor Application

Figure 2.13: Sequence Diagram for Create and Post Quiz

CHAPTER 2. SOFTWARE REQUIREMENTS SPECIFICATIONS 28

Figure 2.14: Sequence Diagram for Submit Quiz

Figure 2.15: Sequence Diagram for Pay Fee

 29

Chapter 3

Software Design Description

3.1 Introduction
This chapter presents the design of the Tutor Search Platform. It will describe the
overall system architecture, including the components and their interactions. We
will also explore alternative architecture designs and justify the selected one. The
system interface design will be detailed, highlighting how users (students, tutors,
admins, teachers) will interact with the platform.
In this chapter, the following design aspects are covered:

• System Architecture: An overview of the architecture, including the high-

level components of the system and their relationships.

• Alternative Architecture Designs: A discussion on alternative approaches

to the system architecture and the rationale behind the chosen design.

• System Interface Description: A detailed description of how each user

type (student, tutor, admin, teacher) will interact with the platform.

• Diagrams: Architectural diagrams, domain models, and activity diagrams

to visualize the system components and workflows.

• User Interface Screenshots: A representation of the user interface design

to demonstrate how the users will engage with the system.

3.1.1 Design Overview

The Tutor Search Platform is a web-based system designed to connect students
with qualified tutors. The system architecture is built using the MERN stack
(MongoDB, [Link], [Link], [Link]) to provide scalability, flexibil-
ity, and ease of development. The platform allows students to search for tutors,
request tutoring sessions, and access study resources, while tutors can manage
their profiles, accept requests, and upload educational materials. Administrators
manage users and ensure the smooth functioning of the platform.
CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 30

Key design components include:

• Frontend ([Link]): The client-side of the platform, providing an inter-

active and responsive user interface for students, tutors, and admins.

• Backend ([Link] with [Link]): Handles API requests, authentica-

tion, and business logic for user interactions.

• Database (MongoDB): Stores user data, tutor profiles, session histories,

and study materials.

• Authentication (JWT): Ensures secure user login and access control for
different user roles (students, tutors, admins, teachers).

3.1.2 Alternative Design Considerations

While the client-server architecture with the MERN stack was chosen for its scal-
ability and flexibility, alternative designs such as a monolithic architecture or
serverless architecture was also considered. The chosen architecture provides a
balance of modularity, performance, and ease of management.

3.1.3 Key Objectives for Design

• Modularity: Separate components for easy management.

• Scalability: Handle growing user base.

• Security: Use JWT for authentication, HTTPS for encryption.

• Usability: Ensure responsive design across devices.

• Maintainability: Allow for future updates.

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 31

3.1.4 Requirements Traceability Matrix

[Link] Functional Requirements

Table 3.1: Functional Requirements Traceability Matrix

ID Requirement Design Element Verification

FR1 Students should be able to search Tutor Search Fea- Manual
for tutors by subject and avail- ture in the Student Testing,
ability. Interface User Ac-
ceptance
Testing
(UAT)
FR2 Tutors can create and manage Profile Management Manual
their profiles. in the Tutor Inter- Testing,
face UAT
FR3 Admins can approve or reject tu- Admin Interface for Admin
tor profiles. Tutor Management Testing,
UAT
FR4 Students can request tutoring Request Functional- Manual
sessions from tutors. ity in the Student Testing,
Interface UAT
FR5 Tutors can upload study materi- Resource Upload Manual
als for student access. Feature in the Tutor Testing,
Interface UAT
CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 32

[Link] Non-Functional Requirements

Table 3.2: Non-Functional Requirements Traceability Matrix

ID Requirement Design Element Verification

NFR1 The platform should support Client-Server Ar- Load Test-
concurrent users (scalable). chitecture (MERN ing, Perfor-
Stack) mance Test-
ing
NFR2 The platform should be secure, JWT Authentica- Security
with encrypted user data. tion, HTTPS, Data Testing,
Encryption Penetration
Testing
NFR3 The platform should be respon- Responsive Fron- User Test-
sive and user-friendly. tend ([Link]) with ing, Re-
Mobile and Desktop sponsive-
Support ness Testing

3.2 System Architecture Design

The Model-View-Controller (MVC) architecture is chosen for its clear sep-
aration of concerns, improving modularity, scalability, and maintainability. The
Model handles data and business logic, the View manages UI presentation, and
the Controller acts as an intermediary, processing user input and updating the
Model or View accordingly. This structure enhances code reusability, parallel
development, and ease of testing.

3.2.1 Alternate Approach

An alternative architecture, such as MVP, is considered to provide flexibility
in case specific project requirements demand a different separation of concerns.
Factors like scalability, testability, and maintainability influence the choice. If
the primary architecture faces challenges in UI management, data handling, or
performance, switching to an alternative approach ensures better adaptability to
future modifications.
CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 33

3.2.2 Architectural Diagram

Figure 3.1: Architectural Design of Tutor Search Platform

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 34

3.3 Domain Model

Figure 3.2: Domain Model of Tutor-Student Platform

Relationships:

• User → Student/Tutor (1:1)

• Student → Session (1:M)

• Tutor → Session (1:M)

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 35

• Session → Chat (1:M)

• Student → TutorApplication (1:M)

• Admin → TutorApplication (1:M)

• Student → IssueReport (1:M)

• Admin → IssueReport (1:M)

• Tutor → Resource (1:M)

• Admin → Resource (1:M)

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 36

3.4 Activity Diagrams

Figure 3.3: Activity Diagram for Login

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 37

Figure 3.4: Activity Diagram for Search for Tutor

Figure 3.5: Activity Diagram for Chat between Student and Tutor
CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 38

Figure 3.6: Activity Diagram for Request to Schedule a Session

Figure 3.7: Activity Diagram for Approve or Reject Session Request

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 39

Figure 3.8: Activity Diagram for Access Resources

Figure 3.9: Activity Diagram for Report Issues to Admin

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 40

Figure 3.10: Activity Diagram for Submit Subject Resources

Figure 3.11: Activity Diagram for Approve or Reject Subject Resources

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 41

Figure 3.12: Activity Diagram for Register as Tutor

Figure 3.13: Activity Diagram for Approve or Reject Tutor Application

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 42

Figure 3.14: Activity Diagram for Pay Fees

CHAPTER 3. SOFTWARE DESIGN DESCRIPTION 43

Figure 3.15: Activity Diagram for Create and Post Assessment/Quiz

 44

Chapter 4

Software Implementation

This chapter describes the software creation of the Tutor Portal system. It names
the tools frameworks next to technologies used in development, supports tutor
student talks, manages session times, shares study material and handles error
reporting. The program divides into several parts that check user identity, manage
sessions, organize study material and open channels for talking.

4.1 System Definition

The Tutor Portal acts as a web platform built with the MERN stack (MongoDB,
[Link], [Link], [Link]). A student uses the site to ask for help, check study
material or report errors. A tutor reviews session asks, adds material next to
replies using clear steps. The system splits into these parts:

• User identity part: Manages sign-ups, sign ins next to role-based limits
for students, tutors along with admins.

• Session part: Lets students ask for sessions, lets tutors accept or decline
and lets admins watch over session times.

• Study material part: Tutors add study guides (PDFs, videos, notes) and
admins decide on uploads.

• Error report part: Students and tutors send reports about problems to
administrators.

4.2 Development Tools

4.2.1 Backend Technologies

• [Link]: The backend runtime environment for executing JavaScript.

• [Link]: A minimal and flexible [Link] web application framework used

for building the server-side API.
CHAPTER 4. SOFTWARE IMPLEMENTATION 45

• MongoDB: A NoSQL database used for storing user details, session data,
and learning resources.

• Mongoose: An ODM (Object Data Modeling) library for MongoDB, used

for schema validation and database interaction.

• JWT (JSON Web Token): Used for secure authentication and autho-
rization.

• Cloudinary: Integrated for storing and managing uploaded resources such

as PDFs and videos.

4.2.2 Frontend Technologies

• [Link]: The frontend library used for building an interactive user inter-
face.

• Redux (or Context API): Used for state management across components.

• Material-UI (or Tailwind CSS): Ensures a responsive and modern UI

design.

• Axios: Handles API requests between the frontend and backend.

4.2.3 Development & Deployment Tools

• Postman: Used for API testing and debugging.

• Git & GitHub: For version control and collaboration.

• Docker (if used): For containerizing the application.

• Heroku/Vercel: Deployment platforms for hosting the application.

• Nodemon: A development dependency for live-reloading during backend

development.

Note: There can be a certain or little change in technologies during

implementation time because of the specific needs or change in some
idea.
CHAPTER 4. SOFTWARE IMPLEMENTATION 46

4.3 Data Handling

The system checks user login, takes session requests and gives access to study
materials. MongoDB serves as the main place to keep both organized and mixed-
up data. The system Handles data using restAPIs.

• Sessions Collection: Holds session requests, acceptances plus refusals.

• Users Collection: Keeps tutor and student profiles with hidden passwords.

• Resources Collection: Keeps uploaded study materials along with their

approval details.

• Issues Collection: Holds reported problems plus their fixes.

4.4 API Endpoints

The backend gives several API routes for different tasks:

Auth Routes (/api/auth)

• POST /register → User registration.

• POST /login → User authentication.

Session Routes (/api/sessions)

• POST /request → Student requests a session.

• GET /pending → Tutor views pending session requests.

• PUT /approve/:id → Tutor approves a session.

• PUT /reject/:id → Tutor rejects a session.

Resource Routes (/api/resources)

• POST /upload → Tutor submits a resource.

• GET /pending → Admin views pending resource approvals.

• PUT /approve/:id → Admin approves a resource.

• PUT /reject/:id → Admin rejects a resource.

CHAPTER 4. SOFTWARE IMPLEMENTATION 47

Issue Reporting Routes (/api/issues)

• POST /report → User submits an issue.

• GET /all → Admin views reported issues.

4.5 User Interface

The Tutor Portal features a user-friendly interface that enables students and tutors
to efficiently interact with the system.

Students Portal:
• Search for tutors based on subject, availability, and expertise.

• Request and manage tutoring sessions.

• Access approved learning resources.

• Report issues or concerns to the admin.

Tutors Portal:
• Manage submitted resources and track approvals.

• View and accept/reject session requests from students.

Admin Portal:
• Manage reported issues and oversee system functionality.

• Approve or reject tutor registrations and submitted resources.

CHAPTER 4. SOFTWARE IMPLEMENTATION 48

4.6 UI Screen Images

Figure 4.1: Admin Portal UI

Figure 4.2: Tutor Portal UI

CHAPTER 4. SOFTWARE IMPLEMENTATION 49

Figure 4.3: Student Portal UI

Figure 4.4: Tutor Application Portal UI

CHAPTER 4. SOFTWARE IMPLEMENTATION 50

Figure 4.5: Pending Application View in Admin Portal

CHAPTER 4. SOFTWARE IMPLEMENTATION 51

Figure 4.6: Chatbot UI

4.7 Summary
The Tutor Portal system uses MERN stack technology, which makes use of Modern
and effective techniques for this type of system. The backend is responsible for
data with a system that handles tutoring sessions neatly plus the frontend gives a
design that reacts to user needs with a clear look. The next chapter talks about
system tests and checks to confirm that the app works as expected.
 52

Chapter 5

Software Test Documentation

5.1 Overview
The purpose of this test document to decide the testing stages, procedures, and
techniques that will be applied to ensure reliability, efficiency, and functionality
of the system. This document will be used as a reference to make sure that every
component of the system is fully tested and satisfies the requirements.
Testing is a crucial stage in the software development lifecycle, and it’s purpose
is to find loopholes and bugs in the system, and to make sure that functional and
non-functional requirements are met, and provide users with a high quality prod-
uct. The Tutor Portal will follow this Test document to ensure every requirement
is met properly.

5.2 Test Approach

The testing approach for tutor system will contain both manual and automated
testing techniques. The following testing types will be used to ensure the system
meets its requirements:

1. Unit Testing: Each component and module will be tested separately to

check their correctness.

2. Integration Testing: Interactions between modules will be tested to make

sure they work together or cause problems.

3. System Testing: The whole system will be tested to confirm end-to-end

functionality.

4. Acceptance Testing: The system will be tested against user requirements

to ensure it meets the needs of stakeholders.

5. Performance Testing: load and scalability tests will be performed in it to

check whether the test is reliable or not under heavy traffic.
CHAPTER 5. SOFTWARE TEST DOCUMENTATION 53

The tests will be conducted in an iterative approach, where testing is conducted

along with development. Test cases will be written from functional and non-
functional requirements, and defects will be logged, tracked, and resolved using a
defect management tool.

5.3 Test Cases

5.3.1 User Authentication Test Cases

Table 5.1: User Authentication Test Cases

Test Cases Steps to Execute Expected Result

Login with valid cre- Enter correct email and pass- User is successfully
dentials word and click Login logged in and redi-
rected to dashboard
Login with invalid Enter incorrect email or pass- Error message is dis-
credentials word and click Login played
Register a new user Enter valid registration details User account is cre-
and click Register ated successfully
Login without inter- Disable internet and attempt lo- Error message indi-
net connection gin cating no internet
connection is dis-
played
CHAPTER 5. SOFTWARE TEST DOCUMENTATION 54

5.3.2 User Registration and Approval Test Cases

Table 5.2: User Registration and Approval Test Cases

Test Description Steps to Execute Expected Result

Student signs up with Navigate to Sign-Up page, Student account is
valid details select Student role, enter created successfully
valid details, and submit
Student record visibility Login as Admin and open Newly registered
in admin portal Users/Students section student is visible in
admin portal
Student login after suc- Login using registered stu- Student is logged
cessful registration dent credentials in and redirected to
student dashboard
Tutor signs up and se- Navigate to Sign-Up page, System redirects tu-
lects tutor role select Tutor role, and submit tor to application
basic details form
Tutor submits applica- Fill application form with Tutor application
tion successfully qualifications and expertise is submitted and
and submit marked as pending
Tutor login while appli- Login using tutor credentials Application status is
cation is pending displayed as ”Pend-
ing”
Admin approves tutor Login as Admin, review tu- Tutor status is up-
application tor application, and approve dated to approved
Tutor login after appli- Login using tutor credentials Tutor is redi-
cation approval rected to tutor
portal/dashboard
Admin rejects tutor ap- Login as Admin, review tu- Tutor application is
plication tor application, reject with rejected and reason
reason is saved
Tutor login after appli- Login using tutor credentials Rejection reason is
cation rejection displayed to tutor
CHAPTER 5. SOFTWARE TEST DOCUMENTATION 55

5.3.3 Tutor Search Functionality Test Cases

Table 5.3: Tutor Search Functionality Test Cases

Test Description Steps to Execute Expected Result

Search tutors with valid Enter subject and availabil- List of matching tu-
criteria ity filters tors is displayed
Search tutors with no Enter uncommon or invalid ”No results found”
matching results search criteria message is displayed
Modify search filters Update subject or availabil- Updated list of tu-
ity filters tors is displayed

5.3.4 Chat Between Student and Tutor Test Cases

Table 5.4: Chat Functionality Test Cases

Test Description Steps to Execute Expected Result

Start chat with tutor Select tutor and click ”Chat” Chat interface opens
successfully
Send and receive mes- Send messages from both Messages are ex-
sages student and tutor changed in real time

5.3.5 Session Scheduling Test Cases

Table 5.5: Session Scheduling Test Cases

Test Description Steps to Execute Expected Result

Request a tutoring ses- Select tutor, choose date and Session request is
sion time, and submit sent to tutor
Request session at un- Select unavailable time slot System prompts
available time student to choose
another time
Approve session request Tutor approves pending re- Student receives ap-
quest proval notification
Reject session request Tutor rejects request Student is notified of
rejection
CHAPTER 5. SOFTWARE TEST DOCUMENTATION 56

5.3.6 Learning Resources Test Cases

Table 5.6: Learning Resources Test Cases

Test Description Steps to Execute Expected Result

Access available re- Navigate to Resources sec- Approved resources
sources tion are displayed
Download learning re- Select a resource and down- Resource downloads
source load successfully
Submit resource by tu- Upload resource with valid Resources are sub-
tor details mitted for admin ap-
proval
Upload unsupported file Upload invalid file format Error message is dis-
format played

5.4 Test Environment

The testing of the system was conducted in a controlled environment to ensure
reliability, consistency, and accuracy of results. The project is developed using
the MERN stack, and the following hardware and software configurations were
used during testing:

Hardware Environment
• Processor: Intel Core i5 or equivalent

• RAM: 4 GB or higher

• Display: 1366 × 768 resolution or higher

Software Environment
• Operating System: Windows 10 / Windows 11 / Linux (Ubuntu)

• Frontend: [Link]

• Backend: [Link] with [Link]

• Database: MongoDB

• Runtime Environment: [Link] (LTS version)

• Package Manager: npm / yarn

CHAPTER 5. SOFTWARE TEST DOCUMENTATION 57

• Web Browser: Google Chrome / Mozilla Firefox

Development & Testing Tools

• Code Editor: Visual Studio Code

• API Testing Tool: Postman

• Version Control: Git

• Database Management: MongoDB Compass

• Testing Approach:

– Manual testing for functional validation

– Role-based testing for Student, Tutor, and Admin modules

5.5 Conclusion
This chapter presented a comprehensive testing strategy for the system, focus-
ing on validating core functionalities such as user registration, authentication,
role-based access, tutor application processing, and administrative controls. Test
cases were designed to cover all major user roles, including Students, Tutors, and
Admins, ensuring that the system behaves as expected under normal operating
conditions.
The testing process confirmed that the system meets the specified functional
requirements and maintains data integrity across different user interactions. All
critical workflows—such as student registration, tutor application submission, ap-
plication review, and status-based redirection—were successfully validated.
Overall, the testing results indicate that the system is stable, reliable, and
ready for deployment. The modular architecture of the MERN stack further sup-
ports scalability, maintainability, and future enhancements.
 58

Chapter 6

Conclusion and Future Work

6.1 Conclusion
TutorPortal has been developed as a platform to connect tutors and students,
providing features such as tutor registration, course listings, session scheduling,
and notifications. The platform has been tested to ensure that the core function-
alities, such as user authentication, tutor registration, and session management,
are working as expected.
Key achievements so far include:

• User Accounts: Students and tutors can register, log in, and manage their
accounts.

• Course and Session Management: Tutors can add courses, and students
can view and book sessions.

The platform is functional, user-friendly, and ready for initial deployment.

While the core features are in place, TutorPortal is designed with scalability and
future growth in mind.

6.2 Future Work

Although the platform is functional, there are several key improvements planned
to enhance its performance, reliability, and reach:

6.2.1 DevOps and Deployment

• Automated Deployments: Plan to implement automated deployment
pipelines to staging and production environments.

• Docker & ECR Registry: Containerize the application using Docker and
store images in AWS ECR for easy management.
CHAPTER 6. CONCLUSION AND FUTURE WORK 59

• Kubernetes Orchestration: Deploy TutorPortal on Kubernetes clusters

with master and worker nodes, enabling high availability and scalability.

• GitLab CI/CD: Set up CI/CD pipelines for automated testing, staging,

and production deployments.

6.2.2 Performance and Optimization

• Improve load times and memory usage as the platform scales.

• Implement caching and background data fetching for smoother user experi-
ence.

6.2.3 Platform Expansion

• Launch mobile apps for iOS and Android in the future using cross-platform
frameworks like React Native or Flutter.

• Expand features like calendar sync, advanced search, and session reminders.

6.2.4 Security Enhancements

• Implement strong encryption for sensitive user data.

• Introduce optional two-factor authentication (2FA) for accounts.

• Conduct regular security audits to identify and fix vulnerabilities.

6.2.5 User Engagement

• Contact and onboard tutors to register on the platform.

• Collect user feedback and monitor usage analytics to guide future improve-
ments.

6.3 Conclusion
Tutor Portal is a functional and scalable platform that successfully connects stu-
dents with tutors. While the current version provides the essential features for
registration, session management, and notifications, the planned DevOps prac-
tices, automated deployments, and advanced features will ensure the platform can
grow efficiently, remain secure, and provide a high-quality user experience. Note:
DevOps practices, automated deployments, etc., are future plans, not
done yet.
 60

Bibliography

1. Shama Hoque – Full-Stack React Projects: Modern Web Development Us-

ing React 16, Node, Express, and MongoDB, Packt Publishing, 2018. Covers
MERN stack development, including React, [Link], [Link], and Mon-
goDB.

2. Ethan Brown – Web Development with Node and Express: Leveraging the
JavaScript Stack, O’Reilly Media, 2019. Discusses backend development
using [Link] and [Link].

3. Grady Booch, James Rumbaugh, Ivar Jacobson – The Unified Mod-

eling Language User Guide, Addison-Wesley, 2005. A comprehensive guide
to UML for software design.

4. Ian Sommerville – Software Engineering (10th Edition), Pearson, 2015.

5. Karl E. Wiegers, Joy Beatty – Software Requirements (3rd Edition),

Microsoft Press, 2013.

6. Martin Fowler – UML Distilled: A Brief Guide to the Standard Object

Modeling Language (3rd Edition), Addison-Wesley, 2003.