COLLEGE MANAGEMENT SYSTEM FOR INTERMEDIATE

LEVEL (1st & 2nd Year) USING MERN STACK

SUBMITTED BY

Nadeem Ahmad

Muqaddas Habib

Sajid khan

SUPERVISED BY

Mr. Syed Pirzada

Lecturer

SESSION: 2021–2025

DEPARTMENT OF COMPUTER SCIENCE

Government Postgraduate College Timergara

District Dir Lower

Affiliated With University of Malakand, Pakistan

I
 Author's Declaration

I, Nadeem Ahmad (Registration No. 2115126), Muqadas Habib (Registration No. 2115104)

and Sajid khan (Registration No. 2115119), hereby declare that our BS-CS Final Year Project

thesis entitled "College Management System for Intermediate Level (1st & 2nd Year) Web

Application using MERN Stack is substantially based upon our own work and has not been

previously submitted by anyone for any degree at the Department of Computer Science, GPGC

Timergara, Dir Lower, affiliated with University of Malakand, Pakistan, or any other institution

in the country or elsewhere.

We acknowledge that if our statement is found to be false at any time in the future (even after

graduating), the university can revoke our BS-CS degree.

Signed by:

Nadeem Ahmad

Signature & Date: _____________________________

Muqadas Habib

Signature & Date: _____________________________

Sajid khan

Signature & Date: _____________________________

II
 Certificate of Approval

We certify this is to be the right format and contents of the thesis entitled, "College
Management System for Intermediate Level (1st & 2nd Year), Web Application using
MERN Stack", submitted by Nadeem Ahmad (Registration No. 2115126), Muqadas Habib
(Registration No. 2115104) and Sajid khan (Registration No. 2115119), is examined and
accepted. The thesis is accepted for the award of a BS Degree in Computer Science.

External examiner:

Name: ___________________________

Designation and affiliation: ________________________________

Sign and Date: _____________________

Internal Supervisor:

Name: ___________________________

Designation and affiliation: ________________________________

Signed and Date: ______________________

Chairman, Department of Computer Science:

Name: ___________________________

Signed and Date: ____________________

III
 Dedication

We dedicate this entire work to our cherished parents.

It is because of their overwhelming support, care, guidance and prayers, we have

accomplished our goals and we have tread the path of success. The sacrifices they have made

are immeasurable and we will be thankful for every single thing they have done for us for the

rest of our lives.

IV
 Acknowledgments

In the name of Allah, the Clement and Merciful. There is no god but Allah and Muhammad

(peace be upon him) is His prophet. We would like to express our profound gratitude to our

project supervisor, Mr. Syed Pir Zada, Lecturer Department of Computer Science, Government

Postgraduate College Timergara whose commitment to our project, wise insights, guidance and

continued support was an immense help in particular, he has been a valuable resource in giving

us information to develop and finalize our project. His knowledge and detailed approach, along

with his counsel ultimately amalgamated and encouraged us to seek, tackle and achieve our

goals.

We also want to acknowledge our families for encouraging us through their silent prayers,

encouragement and support. They have contributed much through their confidence in us and

by making emotional and natural sacrifices towards reaching our goals. A special thanks to our

parents whose love and trust in us gave us the power to deal with the unfortunate circumstances

and motivated us to succeed.

V
 Abstract

The College Management System (CMS) is a web application based on the MERN Stack
(MongoDB, Express.js, React.js, Node.js) for educational institutions at the intermediate level
to digitize their administrative process. The CMS was designed for educational institutions to
overcome specific challenges in scalability, access to data in real time and a multi-stakeholder
process given current education management approaches implemented via paper-based
administrative processes. The CMS features a secure and responsive architecture that serves
four student actual users like Admins, Teachers, Students and Parents. Each functioning with
specific purposes within the system or platform to create efficiencies in their academic
journeys.

The CMS relies on React.js and builds a frontend, provides interactive user interfaces and
functionalities through dynamic UI, operates using Node.js and Express.js with robust REST
APIs, uses MongoDB to represent a NoSQL-based flexible database that can scale with future
updates and changes or processes of educational operations ultimately moving academic
records or academic information around the system. The CMS consolidates automatic
recordkeeping and attendance, which cannot be understated for academic environments, with
key features role-based, automatic attendance, distribution of assignments, submission of
grades and notifications all in one system or process.

This thesis reviews the technical architecture of the CMS by reflecting on the gained
experiences creating and building the CMS including important design considerations
regarding NoSQL database modeling given the key data structures within an educational
setting, authentication of secured connections using JWT (JavaScript Tokens). The
implementation part and period of study also provided prominent challenges in the required
knowledge base of data formats to share with the other information.

Relative to traditional college management systems, this project shows substantially improved
user experience with its clear interface design, operational efficiency using automated
functions and scalability with a cloud-ready deployment structure. The MERN stack is
particularly useful in developing a maintainable, cost-effective project that reduces the
administrative burden while also supporting institutional transparency.

VI
 TABLE OF CONTENT

...................................................................................................................... 1

INTRODUCTION............................................................................................................. 1

1.1 Introduction ................................................................................................................... 1

1.2 Background of the Study .............................................................................................. 1

1.3 Problem Statement ........................................................................................................ 2

1.4 Aims and Objectives ..................................................................................................... 2

1.5 Project Scope ................................................................................................................ 3

1.6 Significance of the Study .............................................................................................. 4

1.7 Methodology Overview & Technology Stack .............................................................. 4

...................................................................................................................... 5

SYSTEM ANALYSIS AND REQUIREMENTS GATHERING ................................. 5

2.1 System Overview .......................................................................................................... 5

2.2 Feasibility Study ........................................................................................................... 5

2.3 Functional and Non-Functional Requirements ............................................................. 6

2.4 Requirement Gathering Techniques ............................................................................. 6

2.5 Use Case Diagrams & Narratives ................................................................................. 7

2.6 Stakeholder Analysis .................................................................................................... 8

2.7 Analysis of Existing Systems........................................................................................ 8

2.8 Issues with the manual system ...................................................................................... 8

2.9 Proposed system structure............................................................................................. 9

2.10 Key Benefits of the CMS ............................................................................................ 9

VII
 .................................................................................................................... 10

LOGICAL DATABASE DESIGN................................................................................. 10

3.1 Introduction ................................................................................................................. 10

3.2 Objectives of the Database.......................................................................................... 10

3.3 Identification of All Entities in the Database .............................................................. 11

3.3.1 Entity ........................................................................................................................ 11

3.3.2 Entity Class .............................................................................................................. 11

3.3.3 Entity Instance: ........................................................................................................ 12

3.3.4 Strong Entity: ........................................................................................................... 12

3.3.5 Weak Entity: ............................................................................................................ 12

3.3.6 Attributes: ................................................................................................................ 13

3.3.7 Relationship: ............................................................................................................ 14

3.3.8 Cardinality: .............................................................................................................. 14

3.4 Entity Relationship Diagram (ERD) ........................................................................... 15

3.5 Data Flow Diagram ..................................................................................................... 17

3.5.1 Level 0 DFD - Context Diagram ............................................................................. 18

3.5.2 Level 1 DFD - Functional Breakdown Diagram...................................................... 19

.................................................................................................................... 21

PHYSICAL DATABASE DESIGN ............................................................................... 21

4.1 Introduction ................................................................................................................. 21

4.2 Overview of MongoDB in CMS ................................................................................. 21

4.3 Key Tools Used........................................................................................................... 21

4.4 Physical Schema & Collection Design ....................................................................... 22

VIII
4.4.1 Admins Collection ................................................................................................... 22

4.4.2 Teachers Collection ................................................................................................. 23

4.4.3 Students Collection .................................................................................................. 23

4.4.4 Parents Collection .................................................................................................... 24

4.5 Authentication & Security Considerations ................................................................. 24

.................................................................................................................... 25

USER INTERFACE DESIGN ....................................................................................... 25

5.1 UI Design Principles ................................................................................................... 25

5.2 Design Goals: .............................................................................................................. 25

5.3 Layout Structure and Components.............................................................................. 26

5.4 UI for Each Role ......................................................................................................... 28

5.4.1 Admin panel ............................................................................................................. 28

5.4.2 Teacher panel ........................................................................................................... 28

5.4.3 Student dashboard .................................................................................................... 29

5.4.4 Parent view............................................................................................................... 29

.................................................................................................................... 30

SYSTEM TESTING ....................................................................................................... 30

6.1 Introduction ................................................................................................................. 30

6.2 Goals of Testing and the Importance of Identification ............................................... 30

6.3 Testing Strategies ........................................................................................................ 30

6.3.1 Unit Testing ............................................................................................................. 30

6.3.2 Integration Testing ................................................................................................... 31

6.3.3 System Testing ......................................................................................................... 32

IX
6.3.4 Black Box Testing.................................................................................................... 33

6.3.5 White Box Testing ................................................................................................... 34

.................................................................................................................... 36

IMPLEMENTATION OF THE CMS .......................................................................... 36

7.1 Overview ..................................................................................................................... 36

7.2 Development Environment ......................................................................................... 36

7.3 Phases of Implementation ........................................................................................... 37

7.4 Setup Process .............................................................................................................. 39

.................................................................................................................... 40

CONCLUSION ............................................................................................................... 40

X
 LIST OF FIGURES

FIGURE 1: USE CASE DIAGRAM FOR CMS SYSTEM .................................................................................................. 7

FIGURE 2: CMS ENTITY ........................................................................................................................................ 11

FIGURE 3: STRONG ENTITY ................................................................................................................................... 12

FIGURE 4: WEAK ENTITY ...................................................................................................................................... 13

FIGURE 5: ATTRIBUTE ........................................................................................................................................... 13

FIGURE 6: RELATIONSHIP ...................................................................................................................................... 14

FIGURE 7: CARDINALITY ....................................................................................................................................... 15

FIGURE 8: ERD FOR CMS DATABASE ................................................................................................................... 16

FIGURE 9: PROCESS ............................................................................................................................................... 17

FIGURE 10: DATA STORE ....................................................................................................................................... 17

FIGURE 11: EXTERNAL ENTITY .............................................................................................................................. 17

FIGURE 12: DATA FLOW ........................................................................................................................................ 18

FIGURE 13: LEVEL 0 DFD, OVERVIEW OF CMS .................................................................................................... 19

FIGURE 14: LEVEL 1 DFD, INTERNAL WORKFLOWS OF CMS ............................................................................... 20

FIGURE 15: MONGODB CONNECTED TO THE LOCAL CMS DATABASE ................................................................... 22

FIGURE 16: ADMIN DOCUMENT SAMPLE OF THE CMS ........................................................................................... 22

FIGURE 17: TEACHER DOCUMENT OF THE CMS .................................................................................................... 23

FIGURE 18: STUDENT DOCUMENT OF THE CMS ..................................................................................................... 23

FIGURE 19: PARENT DOCUMENT OF THE CMS ....................................................................................................... 24

FIGURE 20: MONGODB INTERFACE SHOWING THE CMS ADMINS HASHED PASSWORD & ROLE FIELDS ................... 24

XI
FIGURE 21: LOGIN PAGE - REDIRECT FORM FOR ROLE-BASED ACCESS ................................................................... 26

FIGURE 22: ADMIN DASHBOARD, WIDGET CARDS, SIDE NAVIGATION AND STATS ................................................. 26

FIGURE 23: TEACHER VIEW, ATTENDANCE RESULTS PORTAL FOR SUBMISSION ..................................................... 27

FIGURE 24: STUDENT VIEW, ACADEMIC RESULTS AND OVERVIEW DETAILS .......................................................... 27

FIGURE 25: NADEEM IS AN ADMIN OF THE CMS .................................................................................................... 28

FIGURE 26: SIR PIRZADA IS A TEACHER OF THE CMS ............................................................................................ 28

FIGURE 27: MUQADAS HABIB IS A STUDENT OF THE CMS .................................................................................... 29

FIGURE 28: SAJID KHAN IS A PARENT OF THE CMS .............................................................................................. 29

FIGURE 29: POSTMAN TEST OF FEE SUBMIT ........................................................................................................... 31

FIGURE 30: MONGODB VIEW OF TEACHER (SIR PIRZADA) → SUBJECT REFERENCE.............................................. 32

FIGURE 31: ADMIN DASHBOARD VIEW (STUDENTS, RESULTS, FEES)..................................................................... 33

FIGURE 32: ADMIN LOGS IN WITH INCORRECT CREDENTIALS UI ALERT................................................................. 34

FIGURE 33: SHOW JWT-BASED RBAC CHECK IN EXPRESS MIDDLEWARE ............................................................. 35

FIGURE 34: VS CODE PROJECT DIRECTORY STRUCTURE. ..................................................................................... 37

FIGURE 35: ADMIN DASHBOARD UI WITH BUTTON. ............................................................................................... 38

FIGURE 36: SHOWING THE TERMINAL OUTPUT AFTER SUCCESSFULLY STARTING FRONTEND AND BACKEND ......... 39

XII
 INTRODUCTION

1.1 Introduction

The 21st century is witnessing an unprecedented shift in education as digital transformation is

influencing educational institutions to apply smart solutions for their academic, administrative
and operational tasks. Today colleges are encountering challenges that their administrators
have never faced before such as large student volumes, administrative complexity, data
accuracy, etc. In addition to these demands, it is becoming increasingly difficult for institutions
to continue using traditional means of completing college processes, which include paperwork,
Excel files and fragmented digital solutions that do not provide real-time access, centralized
authority, or collaborative features.

Our project presents a College Management System (CMS) that addresses the needs
specifically of intermediate-level colleges incorporating automation, separation of roles for
users and real-time access to data. The project is developed using the MERN stack (MongoDB,
Express.js, React.js, Node.js) and there is a path to a fully digital experience for an
administrator, faculty, students and parents to engage with academic data with customized,
secured dashboards.

The CMS proposes all the academic work-flow-related to students including enrollment,
scheduling, attendance, assignments, examinations, fees and performance reporting, all in one
place. The CMS has role-based access control that ensures users can only engage with
permitted features, therefore offering additional security.

1.2 Background of the Study

Historically, Pakistani intermediate colleges and institutions around the world have utilized
manual processes and stand-alone tools to handle central academic functions. Paper folders,
Excel lists and physical ledgers remain common in most institutions, especially in semi-urban
and rural institutions. Although such systems served previously, they are no longer compatible
with the growing administrative load that comes with expanding student enrollment, diversified
Subjects and the need for more open performance monitoring.
1
Manual processes are prone to duplicate data input, delayed retrieval of historical records,
variability in attendance and grading formats and inadequate communication among the
stakeholders. These issues contribute to delayed decision-making, student discontentment and
lack of accountability. Parents in most instances are excluded from the loop in relation to their
child's academic achievement because they lack access to real-time information. To defeat
these shortcomings, contemporary schools are shifting towards central digital systems. The
MERN stack has developed as one of the strongest full-stack JavaScript-based tools for
creating scalable web applications. Its strengths involve high performance, flexibility, cross-
platform compatibility and a lively development environment. CMS systems developed in
MERN are capable of managing user authentication, real-time updates, data visualizations and
safe file storage, all of which are integral parts of a contemporary academic management tool.

1.3 Problem Statement

The main problem that this project addresses is inefficiency, inaccuracy and lack of integration
in manual and half-digital college management systems being applied by intermediate
institutions. The primary concerns are:

• Manual Data Handling: Manual handling of student records, attendance and results
in constant errors, duplication of data and information loss.
• Lack of Real-Time Access: Students, teachers and parents lack real-time access to
academic information, hindering important decisions.
• Security Risks: Lack of role-based access control heightens the danger of unauthorized
access to data.
• Difficulty in Reporting: Academic grades data and fee payment data cannot be readily
summarized or analyzed. To address these shortcomings, a role-specific, real-time and
integrated College Management System is envisioned. It seeks to cut paper-based
inefficiencies, institutional transparency and computerize academic processes with
security and scale at its center.

1.4 Aims and Objectives

The project's overall objective is to design a centralized, scalable and role-based College
Management System (CMS) using the MERN stack to automate and simplify the intermediate
level of college academic operations.
2
The specific objectives include:

• To design a secure user authorization and role-based access system for Admin, Teacher,
Student and Parent users.
• To design frontend user interfaces with React.js using Tailwind CSS to generate
responsive interface layouts across tones.
• To implement RESTful APIs for the backend using Node.js and Express.js for data
requests, updates and validations.
• To choose MongoDB as our primary database to store structured, semi-structured
documents representing students, teachers, classes, subjects, exams, results and fee
transactions.
• To produce real-time updates for some features such as attendance, exam schedule and
results announcement.
• To provide administrators mechanisms using the CMS for producing performance
reports with access to system activity logs and updating institutional settings.
• To provide scalability in terms of adding more user roles, institutions, or field later
down the line.

1.5 Project Scope

The College Management System project scope is for intermediate level colleges (1st Year &
2nd Year). The system will have the following modules:

• Student Management: Register students, update profiles and group students on a field,
classroom, or section level.
• Faculty Management: Register teachers, assign subjects, manage classroom activity
like attendance, assignment.
• Parent Interface: Allow parents to see their children academic progress and fee
payment status.
• Assignments: Assignments can be issued and submitted by teachers and students
• Attendance Tracking: Teachers can record and update student attendance daily
• Exam & Results: Manage exam scheduling, record marks and produce DMC's
automatically.

3
 • Fee Management: Record fees collected, issue receipts to students, viewable by
parents.

1.6 Significance of the Study

The benefits of the proposed CMS cover all stakeholders:

• Administrators: Control the central point of access for all students, staff and Subject
data; handle institutional records more efficiently; and make better decisions.
• Teachers: No paperwork, report automation and a straightforward process and
solution to track students.
• Students: Access their academic information in real-time: attendance, exam results
and fee status. There is added transparency and motivation.
• Parents: Connect with their child's education via a dedicated portal containing
performance results and updates on all school-related events.

Overall, from a technology perspective, this project supports the effort to digitize the
educational system in Pakistan which still has many sections, including the intermediate level
system, that are operated manually.

1.7 Methodology Overview & Technology Stack

This project adopts an Agile development approach, emphasizing incremental sprints with
weekly deliverables and testing. Development tools and stack are:

• Frontend: React.js (with JSX, Hooks, Context API), styled using Tailwind CSS.
• Backend: Node.js with Express.js for building scalable APIs and middleware.
• Database: MongoDB Atlas, a cloud-hosted NoSQL database suitable for document
storage.
• Authentication: JSON Web Token (JWT) for handling login/session.
• Deployment: GitHub for version control, Render/Vercel for deployment.

This architecture supports rapid iteration, strong security and smooth user experience on
devices.

4
 SYSTEM ANALYSIS AND REQUIREMENTS GATHERING

2.1 System Overview

College Management System (CMS) is a role-based, module-web application developed using

the MERN stack (MongoDB, Express.js, React.js, Node.js) to facilitate modern educational
processes for medium-level institutions. It computerizes and automates academic processes
like student registration, class timetabling, attendance, tests, results and fee tracking. The
system is built with cloud-native scalability, reusable modules and a secure REST API
foundation, allowing real-time communication between administrators, faculty, students and
parents in the most seamless way. Each role communicates through a unique interface specific
to their roles for concentrated access and data confidentiality.

2.2 Feasibility Study

1. Technical Feasibility: The CMS is technically feasible and maintainable because it

employs the MERN stack. The solution makes use of open-source technology to
construct a modular and scalable system that can efficiently manage simultaneous
users. MongoDB Atlas provides cloud-hosted, secure storage of NoSQL data, while
Express.js and Node.js constitute a strong backend API. React.js provides high-
performance UI and facilitates component reusability and cross-browser compatibility.
The technology is seamlessly compatible with current institutional infrastructure
including computer labs and LAN setups.
2. Operational Feasibility: CMS is user-friendly for those with minimal digital literacy.
React-based UI simulates actual academic workflows to minimize training needs. Pilot
testing has revealed successful transfers of paper-based workflows to digital workflows
with minimal disruption. Auto-validation, form hints and confirmation messages are
incorporated into the system to scaffold users through every interaction. Integration
with institution support teams makes it maintainable and sustainably adoptable.
3. Economic Feasibility: Free-tier services such as MongoDB Atlas, Vercel and Render
are utilized to keep costs of hosting low. The MERN stack being open-source means
no licensing cost. CMS minimizes paper, print and administrative costs.
5
2.3 Functional and Non-Functional Requirements

Functional Requirements

• Secure login for Admin, Teacher, Student and Parent roles

• CRUD operations for managing student, teacher, class and subject data
• Faculty attendance and assignment management
• Exam creation and result processing by admin/teachers
• Fee management with receipt generation and dashboard summaries
• Real-time notifications for academic events and updates

Non-Functional Requirements
• Security: JWT authentication, encryption and role-based access
• Performance: Sub-second response time for core modules
• Usability: Simple, responsive UI.
• Scalability: Institutional expansion support; modular backend APIs
• Maintainability: RESTful API documentation; version control using Git

2.4 Requirement Gathering Techniques

To guarantee system capabilities respond directly to stakeholder issues, several research
methods will be utilized:

• Structured Interviews: Will be executed with stakeholders to identify inefficiencies

in enrollment, attendance and result processing.
• Online Surveys: Will be distributed among participants to collect expectations, ranked
through Likert-scale feedback.
• Observation: Hours of observation of administrative personnel during admissions,
result compilation and fee collection processes will be performed.
• Analysis of Documents: Will be analyzed institutional SOPs, record-keeping
templates and policy guides from the previous academic years to determine obligatory
compliance requirements.

6
2.5 Use Case Diagrams & Narratives
The system comprises several actors and modules, represented here by a UML use case
diagram.

Figure 1: Use case diagram for CMS system

The diagram illustrates functional relationships between the Admin, Faculty, Students and
Parents with key modules of Attendance, Exams, Assignments, Fee and Results.

Use Case Narratives

• Admin (Manage Students): Logs into to the system securely, accesses the student
dashboard, adds and edits records, upload documents and assigns class.
• Faculty (Mark Attendance): Chooses class and date, marks attendance through fields
on a form and records attendance data in the system by submitting data to the backend.
Alerts sent when students have excessive consecutive absences.
• Students (Result): Logs into to their personal dashboard, chooses term, examines
marks obtained for exams, they may also download their marks in transcript form.
7
 • Parents (Monitors): Monitors children performance

2.6 Stakeholder Analysis

Administrator
• Role & Functions: Manages academic and administrative processes.
• System Needs: Single console manager, access control, report exporting.

Teacher
• Role & Functions: Delivers academic programs and monitors student performance.
• System Needs: Grade book, assignments/attendance forms.

Student
• Role & Functions: System end-user accessing academic performance.
• System Needs: Student Dashboard (results, notifications, timetable, documents).

Parent
• Role & Functions: Monitors child’s academic performance.
• System Needs: Read-only portal displaying child’s academic and fee status.

IT Staff
• Role & Functions: Handles system roll-out, deployment, and maintenance.
• System Needs: Effective logs, monitoring tools, and update control.

2.7 Analysis of Existing Systems

Most intermediate colleges are still using fragmented manual processes relying on hand-written
registers, printed time-tables and results in the form of Excel spreadsheets. These legacy
systems have the following pain points:

• Delayed access to data (take hours to access attendance or grades)

• High degree of probable human error and data loss
• Increase in the costs for paper, archiving and reporting and data entry people
• Lack of accountability or audit trails
• Disconnected departments, no real-time data sharing

2.8 Issues with the manual system

• Student records are inaccurate most of the time due to manual errors
• Results or attendance reports are published in many days down the line
8
 • Costly stationary required.
• More data sources are isolated and require repetitive syncing.
• No security protocols and no checks in place, if a physical record is deleted it cannot
be audited to confirm what the deletion was of, to query or photo type what the data
was.

2.9 Proposed system structure

The CMS architecture is built with modern technologies for reliability and speed:

• MongoDB Atlas: Secure cloud document storage.

• React.js: Interactive, real-time front end that renders components as needed.
• Express.js: A layer for our API, with user authentication via JWT.
• Node.js: An asynchronous event-driven back end.
• Render: Cloud hosting autoscaling deployment pipelines.

2.10 Key Benefits of the CMS

• Time Saving: Reduction in administrative time
• Accuracy: Validation rules keep the error rate
• Real-Time: The academic dashboards are available 24/7 on mobile.
• Security: Sensitive data is protected by RBAC policies.
• Financially: Estimated savings per year.
• Transparency: Logs and audit trails

9
 LOGICAL DATABASE DESIGN

3.1 Introduction

Logical database design identifies the structures, relationships and controls of an information
system. This step of the CMS (which is for Intermediate Level Institutions) identifies that the
phase of abstract data model (meaning defines data will be used consistently, accurately and
performantly in the application).

Logical design is different from the physical design, since logical design surrounds data
structures, attributes and relationships with no consideration of data storage. Each of these
abstractions leads to increased flexibility, an understanding of the system and long-term
maintainability (especially critical for a modular, JavaScript based MERN stack (MongoDB,
Express.js, React.js, Node.js) project.

This section identifies the flow of structured data through the interactions of the system's core
entities: students, teachers, admins, parents, classes, subjects, exams, attendance, results and
fees. The goal is to establish data operations that can be executed reliably, based on defined
roles and along established institutional practices.

3.2 Objectives of the Database

The CMS database utilizes the MongoDB platform to efficiently, securely and reliably store
and retrieve administrative and academic information, which includes a wide array of
objectives including:

• Security: To safeguard sensitive records with established authentication and role-

based access.
• Independence: To keep data and application logic independent to support greater
flexibility.
• Redundancy avoidance: To avoid redundant data across many modules, including
attendance and results.

10
 • Efficiency: To ensure timely and reliable access to records of students, staff and
exams.
• Multi-user: To support multiple concurrent accesses by admin users, teachers,
students and parents.
• Scalability: To accommodate greater system data volume and functionality as time
passes.
• Decision Support: To provide data that add structure to the evaluation of performance
reports and academic insights.

3.3 Identification of All Entities in the Database

Entities are the basic components of a database schema. Each entity constitutes an important
aspect in the educational and administrative pathway in the College Management System
(CMS). Each entity is defined by a primary key and it has attributes that define what the entity
does and how it interacts with data in the CMS.

3.3.1 Entity
An entity in a College Management System (CMS) is any object or concept that needs to be
represented in the database (e.g., students, teachers, classes, exams, or assignments). Entities
represent essential administrative and academic functions of the system and form the basis for
the database structure.

Entity
Figure 2: CMS Entity

3.3.2 Entity Class

An entity class is a grouping of entities which share similar characteristics. All entities in an
entity class have the same attributes, but different values. Some examples are:

• All students belong in the Student Class, every student will have attributes like
studentId, fullName and class.

11
 • All faculty belong in the Teacher class each, figure will have attributes like teacherId
and subject.

Entity classes model for the academic and operational data in the institution's environment.

3.3.3 Entity Instance: An entity instance is a single record in an entity class and contains the
actual values for the attributes.

Example (Student):
• username: "nadeem.ahmad"
• rollNumber: "21FCS034"
• class: "2nd Year"
• field: "Computer Science"
• section: "A"
Every specific student, teacher or record is an instance of that class.

3.3.4 Strong Entity: A strong entity is not dependent and has a primary key for unique
identification. In the case of the CMS, the strong entities include

• Administrator (adminId or username)

• Student (studentId or rollNumber)
• Teacher (teacherId or email)
• Class (Field, className, section, composite key)
• Subject (subjectId within a class/field)

Strong entities will operate independently and represent the primary operations of the system.

Strong entity

Figure 3: Strong Entity

Rectangle with entity name and primary key underlined.

3.3.5 Weak Entity: A weak entity cannot be uniquely identified without reference to a strong
entity and is generally used to represent dependent or child records. For example, in CMS

12
 • Attendance (needs studentId, subjectId)
• Result (dependent on studentId, examId, subjectId)
• Fee (dependent on studentId, session)
• Assignment (dependent on class, subject and teacher)

Weak entities will utilize composite keys (as a key) or ObjectId (MongoDB) with a parent
reference for uniqueness.

Weak Entity

Figure 4: Weak Entity

Double rectangle, reference to strong entity, primary key part and incomplete, dashed
underline.

3.3.6 Attributes: An attribute specifies an identifier or property of the entity and contains the
actual data values, such as:

• Simple attributes (email, fullName)

• Composite attributes (address could be split into city, postal code)
• Derived attributes (derived from some other attribute like age could be derived from
dateOfBirth)
• Multi-valued (like subjectsSchedule when there are exams)
• An attribute defines the specific values of an entity instance. Example:
• Entity: Student username, rollNumber, className, section.
• Entity: Exam title, startDate, subjectsSchedule.

Attribute

Figure 5: Attribute

Shows ovals connected to the rectangle for the entity with the primary key underlined.

13
3.3.7 Relationship: A relationship is a logical connection or association between two or more
entities (example: Student–Subject, Teacher–Subject). Relationships are an important aspect
of the model as they help ensure data integrity and allow for efficient data retrieval.

Examples of relationships:

• One class has multiple Teachers

• One Student can be enrolled in many Subjects
• One Teacher can teach many Subjects

Relationships can be represented using foreign keys, which allow you to reference other entities
through an identifier.

Relationship

Figure 6: Relationship

Shows lines/arrows connecting multiple entities (Students/Subject/Teacher).

3.3.8 Cardinality:
Cardinality defines the amount of instances of one entity related to another.

Examples of Cardinality:

• A Teacher can teach many subjects (1 to many)

• Many students can enroll in one class (many to 1)
• A class could have many Teachers (1 to many)

Understanding cardinality is critical in CMS to ensure proper enforcement of business rules

and logical data modeling, avoiding anomalies and ensuring robust data relationships.

14
 Figure 7: Cardinality

3.4 Entity Relationship Diagram (ERD)

An Entity-Relationship Diagram (ERD) is a graphical representation of the structure of the

CMS database. The ERD depict relationships between entities, attributes and the relationships
within the CMS. The ERD for CMS shows the relationships between Students, Teachers,
Subjects, Attendance, Exams and Results. The ERD logically organizes entities, minimizes
redundancy and refers to the conceptual premise of referential integrity that specific student
records relate to specific teachers, related by attendance, related to exams, related to reports or
results.

Some Examples:

• Students enroll in Subjects, so students can register for multiple Subjects

• Teachers are assigned to subjects, so a teacher can be associated with multiple subjects
• Attendance is recorded for each Student for each Subject
• Results are related to students and an exam

Note: The admin represents a separate entity from all others and represents the administration
component of the system. The admin will manage but not necessarily relate to other entities. It
is possible to capture admin actions, such as inserting a record into an audit table or log table.
In the ERD, the Admin is represented as an independent entity.
15
Figure 8: ERD for CMS Database

16
3.5 Data Flow Diagram

The Data Flow Diagram (DFD) depicts the way information flows through the College
Management System (CMS). DFDs illustrate inputs, processes, data storage and outputs. DFDs
help recognize what the system can do (what functions are offered), which data is related
(dependencies) and how & where users interact with the system.

Primary Components of the CMS DFD.

1. Processes:
Processes are indicated when a system operation transforms inputs to outputs.
o Registering Student
o Recording Attendance
o Uploading Result
o Generating Report Card
Process

Figure 9: Process

2. Data stores:
Data stores are defined structures for storage of academic and administrative data.
o Student Records
o Teacher Data
o Subjects
o Archive of Results
Data Store

Figure 10: Data store

3. External Entities:

Interaction with the CMS from an actor outside the system.

• Admin
• Student
• Teacher
• Parents Entity
• Exam Department

Figure 11: External entity

17
 4. Data flows:
The arrows showing how data moves between entities, processes and stores.

Student → Submit Assignment → CMS

CMS → Data Relating to Results → Student

Figure 12: Data flow

3.5.1 Level 0 DFD - Context Diagram

The Level 0 DFD (context diagram) provides a high-level view of CMS as a singular process,
with a series of input and output data flows to various external entities as part of the systems
context. Compared to lower level DFDs, it clearly shows how the system operates in a more
holistic view of system communication and data movement without showing internal processes
and the processes' internal logic.

Important Features

• External Entities:
o Admins
o Teachers
o Students
o Parents

• Central Process:
o College Management System

• Some Sample Data Flows:

o Admin → Manage Student, Teacher, Parents Data → CMS
o Student → Login/Register → CMS
o CMS → Send Reports → Admin/Parents
• Data stores:
o Teachers
o Students
o Subject
o Results
o Attendance
o Assignments

18
 Figure 13: Level 0 DFD, Overview of CMS

3.5.2 Level 1 DFD - Functional Breakdown Diagram

Level 1 provides a more in-depth breakdown of the College Management System (CMS) core
or main process into functional subprocesses or processes analogous to a functional breakdown,
showing how core processes interact with each other, with each external user and how they are
potentially supported by internal data stores.

• Processes:
o Registration
o Authorization
o Result downloading
o Reports generation
o Admin panel
• Data Stores:
o Students
o Results
o Admins

• Some Sample Data Flows:

• Students:
o Register → Save to Students DB
o Download Result → Store in Assignments
o View DMC → Fetched from marks DB
• Admins:
o Manage Users → Update student/teacher/parent information
o Generate Reports → Output stored in reports DB

19
 Figure 14: Level 1 DFD, Internal Workflows of CMS

Level 1 DFD figure illustrates that the main system is broken down into functional
subprocesses, that illustrate core processes and their workflows.

20
 PHYSICAL DATABASE DESIGN

4.1 Introduction

Physical database design means the transition from a logical data model to a physical
representation that is implemented on the target database platform. While the logical design
refers to the design of abstract entities and relationships, physical design covers actual storage,
indexing, security and performance of the data. The CMS works for intermediate level (1st and
2nd Year) academic institutions and physical database design ensures that we are efficient with
data-handling to ensure its speed and scalability. There are frequent queries to handle for
instance student performance, however there will also be queries for managing classes,
handling teachers, student attendance logs and financial records. Physical database design will
influence fast integrity retrievals, secure data retrieval, secure access to data environments for
colleges. This chapter discusses how the design of CMS was in MongoDB for the collection
structures, document structures, authentication handling and indexing.

4.2 Overview of MongoDB in CMS

MongoDB would not be the first database selected for selection. A document-oriented NoSQL
database was chosen as it has flexibility, scalability and uses a BSON document model which
resembles JSON. We are all familiar with JSON a flexibly structured data format, so MongoDB
supports use with a dynamic schema, allowing agile development and effectively scaling the
management of educational records that could be structured in numerous ways.

4.3 Key Tools Used

• MongoDB Atlas: Hosted in the cloud, MongoDB Atlas is the product deployed on the
land for production use. It allows for the setup of automated backups, real-time
performance monitoring, as well as global zones of availability.
• MongoDB Compass: Graphical interface developed for collections visualization,
document structure validation and query testing.
• Mongoose ODM: Integrates with the Express.js framework and enables developers to
define schemas to validate documents as well as middleware functions for transactions
on the database.

21
 Figure 15: MongoDB connected to the local CMS database

4.4 Physical Schema & Collection Design

In MongoDB, data is structured into collections (similar to the concept of tables) and every collection
consists of multiple documents (records). For the CMS, there are parts collection to retrieve logically
separated entities. The following are some of the main collections and samples of document fields:

4.4.1 Admins Collection

Holds data for system administrators.

Figure 16: Admin document sample of the CMS

22
4.4.2 Teachers Collection
Records teacher particulars and registering information.

Figure 17: Teacher document of the CMS

4.4.3 Students Collection

Records student particulars and enrollment information.

Figure 18: Student document of the CMS

23
4.4.4 Parents Collection

Figure 19: Parent document of the CMS

4.5 Authentication & Security Considerations

In the CMS, user authentication occurs via secure credentials stored in the admins, teachers,
students and parents, collections. Security considerations for authentication include:

• Password Hashing: User passwords are hashed with bcrypt before they are stored
• JWT (JSON Web Token): Secure tokens are issued on each login to support session-based
handling of users
• RBAC (Role-Based Access Control): Users have specific access to API routes and UI
components based on the user's role
• Field-level validation: Field-level validation is performed using Mongoose schema rules (e.g.
the local Email must be the correct email format, password must be of a certain length etc.)

Figure 20: MongoDB interface showing the cms admins hashed password & role fields
24
 USER INTERFACE DESIGN

5.1 UI Design Principles

The User Interface (UI) of the College Management System (CMS) has been intentionally
designed to ensure a seamless user experience within context of each respective role such as
Administrator, Teacher, Student and Parent. For implementation, the UI has been developed
with React.js and styles applied using Tailwind CSS. Aspects of the UI are intended to support
clarity, role-based workflows, responsiveness and accessibility for all users to properly serve
the shifting environments experienced by community colleges and their intermediate-level
educational practices.

5.2 Design Goals:

1. Role-based Experience: The CMS will automatically discern user roles at login and
upon logging in will render a dashboard to access a role-specific workflow. For
example, the Teacher will see modules related to attendance and results, an
Administrator will see modules related to user creation and academic controls. Each of
these dashboards consist of modular routing design which keeps the UI organized while
mitigating cognitive load associated with routing.
2. Usability and Simplicity: Every interface was designed for usability and does not require
formal training, this was purposeful. The usability features include: Standardized
Iconography and Color Palette. Adherence to Labelled Buttons and Tooltips, Actions
and Data grouped logically
3. Mobile Responsiveness: All views have been made as responsive as possible using
Tailwind CSS responsive utilities and Flex/Grid layouts so that all screens can
adaptively support devices like smartphones, tablets and laptops.
4. Visual Consistency: UI elements (navbar, sidebar, input fields, cards and buttons) are
reused across the system. By adhering to component base structures for its visual
interface, CMS improves maintenance of the codebase consistency, while providing
users with predictable UI interactions.

25
5.3 Layout Structure and Components
The composing is broken into reusable layouts and components for each role. The major
components are:
• Navbars & Sidebars: Static navigations for role-based access
• Dashboard Cards: Quick access widgets for analytics and summaries
• Tabular Views: Responsive tables for attendance, fees and student listings respectively
• Form Components: Reusable input forms for CRUD operations across modules

Figure 21: Login page - redirect form for role-based access

Figure 22: Admin Dashboard, widget cards, side navigation and stats

26
Figure 23: Teacher View, attendance results portal for submission

Figure 24: Student View, academic results and overview details

27
5.4 UI for Each Role
5.4.1 Admin panel
• Modules: Teachers, students & parents management, class/subject, fee tracking, exams and
result generation.
• Layout: Sidebar navigation, tabbed content area and action buttons

Figure 25: Nadeem is an admin of the CMS

Description: In the figure, admin has full control with dynamic CRUD access options and
analytics summary cards.

5.4.2 Teacher panel

• Modules: Attendance, Assignments, Subject view etc.

Figure 26: Sir Pirzada is a teacher of the CMS

Description: In the figure, Sir Pirzada has taken attendance for different classes, while he can
create assignments for students.

28
5.4.3 Student dashboard
• Modules: Fee, Exams, Results, Attendance, Assignments
• Features: DMC, Fee Receipt PDF download, timeline view of assignments

Figure 27: Muqadas Habib is a student of the CMS

Description: In the figure, she can see her result, while she can also see fee status, exams
schedule, attendance and assignments.

5.4.4 Parent view

• Modules: View child fee status, exams, results, attendance and assignments.
• Features: Read-only with real time data synced with the student profile, alerts for academic
events

Figure 28: Sajid Khan is a Parent of the CMS

Description: In the figure, parents can see attendance of his children, also exams schedule,
results, assignments and fee status.

29
 SYSTEM TESTING

6.1 Introduction

System testing was essential in validating the performance and function of the College
Management System (CMS), which was developed using the MERN stack. The purpose was
to validate that each module for all four user types (Admin, Teacher, Student and Parent) was
functioning properly as it would in everyday use and to examine the system for data
consistency, secure access, responsive design and for how well it fits within institutional
workflows.

6.2 Goals of Testing and the Importance of Identification

• The goal of testing aimed to determine:
• If each feature actually worked in normal and edge-case conditions.
• Identify and rectify validation, logic and integration errors.
• Require the proper and secure role-based access for Admins, Teachers, Students and
Parents.
• Assert the real-time data sync across the MERN stack.
• Guarantee that no one could manipulate or lose results, attendance or fee management.

6.3 Testing Strategies

6.3.1 Unit Testing

Unit testing involves verifying individual components (functions, APIs or UI elements) in

isolation to ensure they behave as expected.

For this project, unit tests were implemented for critical modules, such as:

• StudentForm.jsx: Validated input fields.

• POST /api/teachers/add: Would reject duplicate emails.
• ResultService.js: Validated calculations for grades.
• MongoDB schema: Enforced required fields (like studentName, subject, className).

30
 • POST /api/fee/submit: Validated fee submission, checking for correct payload handling and
error responses for invalid data.

Figure 29: Postman test of fee submit

6.3.2 Integration Testing

Integration testing confirmed the transition between front-end components, Express routes and
MongoDB:
31
 • Admin created classes → assigned students → Teacher recorded attendance.
• Subject assignments appeared correctly in both Teacher and Student views.
• Parent saw correct academic data of linked students.

Figure 30: MongoDB view of teacher (Sir Pirzada) → Subject reference

6.3.3 System Testing

System testing is a high-level validation phase where the fully integrated application is
evaluated against end-to-end workflows to ensure all modules function cohesively. It verifies
complete flows through all 11 entities were tested. Here are a few examples:

Entity Test Focus:

• Student: Login, result access, attendance view
• Teacher: Subject assignment, attendance, grade entry
• Admin: User management, class creation, fee assignment
• Parent: View their children's result, attendance and individual fee view
• Fee Module: Confirmed late fee logic, filter by month
• Exam/Result: Confirmed DMC created and access rules
32
 Figure 31: Admin dashboard view (Students, Results, Fees).

6.3.4 Black Box Testing

Black box testing concentrated on front-facing behavior without any observation of internal
code logic.
Testing was performed without observing the internal code:
Scenarios:

33
 • Admin logs in with incorrect credentials → displays login error
• Teacher submits duplicate attendance → rejects duplicate entity
• Parent views unrelated student's record → denied access
• Student submits assignment without content → required field alert

Figure 32: Admin logs in with incorrect credentials UI alert.

6.3.5 White Box Testing

The internal logic and conditions were tested to verify:

• Attendance API: No duplicate entry was possible for the same subject in a single day.
• Fee Module: Fine was only applied to late accounts past the due date.
• RBAC Middleware: Protected routes for certain roles transitioned as expected with JWT
tokens.
• Result DMC: Grades aggregated accurately all worked as intended.

34
Figure 33: Show JWT-based RBAC check in Express middleware

35
 IMPLEMENTATION OF THE CMS

7.1 Overview
This chapter discusses the implementation of the College Management System (CMS) for
Intermediate students developed on the MERN stack (MongoDB, Express.js, React.js,
Node.js). This chapter includes the development environment as well as the order of
implementation of each of the following phases, deployment of the project, installation
instructions for the user and problems that arose during the development. The CMS is designed
to be scalable, easy to use, feature secure role-based access for users such as Admin, Teacher,
Student and Parent.

7.2 Development Environment

To build and deploy the CMS, the following tools/technologies were employed:
• OS: Built in window 11 (previous versions also compatible with proper setup).
• Code editor: Visual Studio Code (VS Code).
• Version control: Git + GitHub.
• Frontend: React.js, Tailwind CSS, React Router.
• Backend: Node.js, Express.js, JWT to authenticate.
• Database: MongoDB Atlas (Cloud).
• State management: Local state + Redux (designated modules).
• Deployment Platforms:
o Frontend - Vercel.
o Backend - Render.
o Database - MongoDB Atlas.

36
 Figure 34: VS Code Project Directory Structure.

7.3 Phases of Implementation

Phase 1: Project Set up and Dependencies
• Backend and frontend projects were created with npm init.
• All necessary libraries (Express, Mongoose, JWT, Axios, React Router Dom and
Tailwind CSS) were installed.
Phase 2: Auth/Authorization
• JWT-based auth was implemented for login and registration.
• Took the necessary steps to secure role-based access using Express middleware.
Phase 3: Module Development
The project was broken down into modules that represented the primary entities.
These were:
• Admin: User management, dashboard stats, CRUD for all entities
• Teacher: Assignment, attendance.
• Student: View assignments, attendance, exams, results and fee status

37
 • Parent: Track their child for academic performance
• Other Modules: Fees, exams, results, attendance, assignments.

Figure 35: Admin dashboard UI with button.

Phase 4: Role-Based Dashboard

• Conditionally render in React to show the correct interface that corresponds with each
of the user roles
• The respective custom navigation and permissions per role were configured.
Phase 5: Testing and Optimization
• Used Postman for testing the backend API.
• Conducted manual UI testing to check the function of each role in the UI.
• Checked the database via the MongoDB Compass.
Phase 6: Deployment
• Frontend deploy using Vercel with continuous deployment triggered by GitHub.
• Backend deployed using Render with the JWT secret and the database URI configured
using environment variables.
• Backend service connected to the MongoDB Atlas which is setup as the remote cloud
database.

38
Screenshot: The Vercel Deployment Dashboard confirming that the build was performed and
the domain has been deployed.

7.4 Setup Process

If you wish to run the CMS locally please follow these steps:
1. Clone the repository:
2. git clone https://github.com/username/cms-project.git
3. Go to the backend folder:
4. cd backend
5. Install the dependencies:
6. npm install
7. Start the backend server:
8. npm run dev
9. Go to the frontend folder:
10. cd ../frontend
11. Install the dependencies:
12. npm install
13. Start the React app:
14. npm start

Figure 36: Showing the terminal output after successfully starting frontend and backend

39
 CONCLUSION

The College Management System (CMS) for Intermediate Level (1st and 2nd Year) has
fulfilled its stated purpose to improve and digitalize then traditional working cycle of college
as a scalable, secure, and user-friendly web application. CMS has been developed using the
MERN stack - MongoDB, Express.js, React.js, and Node.js - and is in a modular design, cloud-
ready application customized from the operating needs of the academic institutions in Pakistan.

Modules implemented in CMS include modules for student registration, management of classes
and subjects, attendance, assignment, scheduling exams, monitoring fees, and generating
results. The CMS platform has provided secure access, through JWT authentication and role-
based access control (RBAC) to all users Admins, Teachers, Students and Parents. Each user
role has a set dashboard from which they can only complete assigned tasks managing usability
and system security simultaneously.

The design of the logical and physical database, configured by MongoDB's flexible schema,
with normalization completed to ensure consistency, performance and maintainability. The
user interface was designed in React.js with complete styling and responsive view using
Tailwind CSS for all devices. Testing performed incorporated unit testing, integration test,
system testing and user acceptance testing, and we were satisfied that the system was correct,
adequate performance criteria and ready for production release. The system itself was deployed
using Vercel (frontend), Render (backend) and MongoDB Atlas (cloud database).

The project offered substantial learning in full-stack web development, UI/UX development,
database modelling, application programming interface integration and real-life testing, and
validated the value of iterative development, version control, and documentation.

In summary, the CMS fulfills its intended academic purpose and provides an effective
countermeasure to perceptions made by intermediary institutions but instead offers a digital
model that is efficient, scalable, and contemporary.

40