NEC TUTOR SPACE – A STUDENT RECORD

MANAGEMENT SYSTEM

by

FIONA JORES MARSHAL S (2212089)

SBIYA JASEMINE M (2212086)
JAYA CHITHRA N (2212084)

19CS67C PRODUCT DEVELOPMENT LABORATORY

Submitted to the faculty of
COMPUTER SCIENCE AND ENGINEERING
In partial fulfillment of the requirements for the degree of

BACHELOR OF ENGINEERING
IN
COMPUTER SCIENCE AND ENGINEERING

ANNA UNIVERSITY, CHENNAI

NATIONAL ENGINEERING COLLEGE, KOVILPATTI
(An Autonomous Institution)

APRIL 2025
 CERTIFICATE

Certified that this project report titled “NEC TUTOR SPACE – A STUDENT
RECORD MANAGEMENT SYSTEM” is the bonafide work of Fiona Jores Marshal S
(2212089), Sbiya Jasemine M (2212086), Jaya Chithra N (2212084) who carried out the
project under my supervision for the partial fulfilment of the requirements for the award of the
degree of Bachelor of Engineering in COMPUTER SCIENCE AND ENGINEERING.
Certified further, that to the best of my knowledge the work reported here in does not form part
of any other project report or dissertation on the basis of which a degree or award was conferred
on an earlier occasion on this or any other candidate.

Place K.R.Nagar, Kovilpatti Supervisor

Date Ms.D.Thamarai Selvi
Assistant Professor (Sr.Grade),
Computer Science and Engineering,
National Engineering College,
K.R.Nagar, Kovilpatti – 628 503

Head of the Department

Dr.V.Gomathi
Professor & Head,
Computer Science and Engineering,
National Engineering College,
K.R.Nagar, Kovilpatti – 628 503

Submitted to 19CS67C - Product Development Laboratory viva voce examination held on

_____________

Internal Examiner Co / External Examiner

 TABLE OF CONTENTS

CHAPTER TITLE PAGE

NO. NO.

ABSTRACT i
ACKNOWLEGEMENT ii
LIST OF FIGURES iii
LIST OF ABBREVIATIONS vi
1 INTRODUCTION 1
1.1 Background of the Existing Software/System 2
1.2 Problem Statement 3
1.3 Need for Innovation 4
1.4 Objectives of the Project
5
1.5 Expected Outcomes
6
2 REVERSE ENGINEERING OF EXISTING SOFTWARE 7
2.1 Existing System Overview 8
2.2 Source Code Analysis
9
2.3 Functional Analysis
10
2.4 Performance Analysis
2.5 Security and Privacy Analysis
11
2.6 Identified Limitations 12
3 FORWARD ENGINEERING PROCESS 13
3.1 PROBLEM IDENTIFICATION AND USER 13
ANALYZE
3.1.1 Problem Understanding 13
3.1.2 Identifying Users & Stakeholders 13
3.1.3 Empathizing with Users 14
3.1.4 Defining the Problem 15
3.2 SOFTWARE ARCHITECTURE & DESIGN 16
3.2.1 Software Requirements Specification (SRS) 16
3.2.2 Architectural Design 16
 3.2.3 Technology Stack Selection 17
3.2.4 Database Design 18
3.3 DEVELOPMENT & IMPLEMENTATION 25
3.3.1 Algorithm & Data Flow Design 25
3.3.2 Modules 28
3.3.3 Feature Implementation 34
3.3.4 UI/UX Considerations 34
3.3.5 Security & Privacy Enhancements 34
3.4 TESTING & VALIDATION 35
3.4.1 Unit Testing 35
3.4.2 Functional Testing 36
3.4.3 Performance Testing 37
3.4.4 User Testing & Feedback 38
3.4.5 Iterative Improvements 38
3.5 COMPARATIVE ANALYSIS & RESULTS 38
4 CONCLUSIONS AND FUTURE SCOPE 39
4.1 Summary of Key Findings 39
4.2 Future Enhancements 40
5 OUTCOME 41
6 REFERENCES 42
 ABSTRACT

The Student Record Management System (SRMS) is a web-based platform developed

to digitize and streamline the management of student information within educational
institutions. It handles a wide range of student-related data, including personal details, events
attended and organized, online courses, achievements, internships, scholarships, and leave
requests. The system features a role-based access control model, where students can submit
and view their data, faculty can review records, and administrators can manage users and
oversee system operations. To maintain data integrity and accountability, SRMS includes an
approval workflow in which any updates made by students require faculty verification before
being finalized. Real-time notifications, powered by Node-mailer, alert users regarding
submissions, approvals, or rejections, improving communication and responsiveness. Built
using modern technologies—Vite React for the frontend, Express.js and Node.js for the
backend, and MySQL for database management—the system ensures speed, security, and
scalability. With a responsive, mobile-friendly interface, SRMS enhances accessibility,
transparency, and operational efficiency, offering a centralized solution for managing all
aspects of student records.

i
 ACKNOWLEDGEMENT

First and foremost, we would like to thank God Almighty for showering his blessings
throughout our life. He has been the tower of our strength in each step of our work. We take
the privilege to express hearty thanks to our parents for their valuable support and effort to
complete the project work.

We would like to express our deep sense of gratitude and respectful regards to our
director Dr. S. Shanmugavel B.Sc., D.M.I.T., Ph.D., for giving an opportunity to do this work.

We have great pleasure in acknowledging our Principal

Dr.K.Kalidasa Murugavel, M.E., Ph.D., for extending his full support to undergo this work.

We express our profound thanks to our beloved Head of the Department

Dr.V.Gomathi., M.Tech., Ph.D., for extending her full support and providing various facilities
during the project work.

We would like to thank our project guide Ms.D.Thamarai Selvi M.E., Assistant
Professor (Sr.Grade), Department of Computer Science and Engineering, whose valuable
guidance, technical support and suggestions helped us in doing the project work.

We express our gratitude to our project coordinator Mr.K.Rajkumar M.E.,, Assistant

Professor (Sr.Grade), Department of Computer Science and Engineering for her valuable
guidance at each and every stage of the project.

We extend our hearty thanks to our tutors and class in-charges for their valuable
guidance. We are grateful to all the staff members and our dear friends for their valuable
suggestions and co-operation for this work.

ii
 LIST OF FIGURES

FIGURE FIGURE DESCRIPTION PAGE

NO. NO.

2.1 ERP SYSTEM DASHBOARD 8

2.2 HTML/JAVASCRIPT ELEMENTS OF ERP MODULE 9

2.3 FUNCTIONAL OVERVIEW OF EXISTING ERP 10

2.4 PAGE LOAD TIME ANALYSIS 11

2.5 SECURITY HEADERS INSPECTION 12

3.1 EMPATHY MAP FOR STUDENT AND FACULTY USERS 14

3.2 STAKEHOLDER INTERACTION DIAGRAM FOR SRMS 15

3.3 ARCHITECTURE DESIGN OF SRMS 17

3.4 TECHNOLOGY STACK DIAGRAM USED IN THE 18

DEVELOPMENT OF SRM

3.5 DATABASE ER DIAGRAM FOR SRMS 19

3.6 FLOW DIAGRAM OF SRMS OPERATIONS 20

3.7 STUDENT_DETAILS TABLE ENTRY 21

iii
3.8 USERS TABLE ENTRY 21

3.9 DEPARTMENTS TABLE ENTRY 22

3.10 ONLINE_COURSES TABLE ENTRY 22

3.11 EVENTS_ORGANIZED TABLE ENTRY 23

3.12 EVENT_ATTENDED TABLE ENTRY 23

3.13 INTERNSHIP TABLE ENTRY 24

3.14 STUDENT_LEAVE TABLE ENTRY 24

3.15 SCHOLARSHIPS 24

3.16 STUDENT WORKFLOW – DATA FLOW DIAGRAM 26

3.17 FACULTY WORKFLOW – DATA FLOW DIAGRAM 27

3.18 ADMIN WORKFLOW – DATA FLOW DIAGRAM 28

3.19 STUDENT DASHBOARD SHOWING PROFILE UPDATE, 30

DOCUMENT SUBMISSION, AND STATUS ALERTS

3.20 TUTOR INTERFACE WITH STUDENT LIST, APPROVAL 31

PANEL, AND MESSAGING TOOL

3.21 DEPARTMENT ADMIN PANEL WITH LISTINGS, BULK 32

UPLOAD, AND FILTERS

iv
3.22 COLLEGE ADMIN DASHBOARD WITH CROSS- 33

DEPARTMENTAL ANALYTICS

3.23 JWT AUTHENTICATION AND BCRYPT HASHING PROCESS 35

3.24 UNIT TESTING OUTPUT USING THUNDER CLIENT 36

3.25 FUNCTIONAL TESTING OUTPUT SHOWING COURSE 37

UPDATE

3.26 PERFORMANCE TESTING OUTPUT WITH RESPONSE TIME 38

METRICS

5.1 EMAIL CONFIRMATION SCREENSHOT FOR CONFERENCE 42

PAPER SUBMISSION

v
 LIST OF ABBREVIATIONS

S.NO ABBREVIATION FULL FORM

1 SRMS Student Record Management System

2 ERP Enterprise Resource Planning

3 UI/UX User Interface / User Experience

4 RBAC Role-Based Access Control

5 API Application Programming Interface

6 SPA Single Page Application

7 JWT JSON Web Token

8 MFA Multi-Factor Authentication

9 CSFRF Cross-Site Request Forgery

10 XSS Cross-Site Scripting

11 SRS Software Requirements Specification

12 HOD Head of the Department

13 PWA Progressive Web Application

vi
14 AES Advanced Encryption Standard

15 GDPR General Data Production Regulation

16 FERPA Family Educational Rights and Privacy Act

17 TTFB Time To First Byte

18 LMS Learning Management System

vii
 CHAPTER 1

INTRODUCTION

In an age where digital transformation is redefining the educational landscape, effective

management of student data has become a cornerstone of academic and administrative
excellence. Institutions around the world are embracing technology to streamline their
operations, and student record management is at the forefront of this shift. Managing student
records involves far more than just storing data; it encompasses admission tracking, course
registration, attendance management, grade history, disciplinary actions, document
submissions, and communication logs. A robust and interactive Student Record Management
System (SRMS) should serve as a central nervous system for academic institutions, enabling
seamless data exchange, transparency, and real-time collaboration among students, faculty, and
administrators.

Despite the increasing availability of digital platforms, many systems still follow
outdated access models, restricting users to limited capabilities and creating inefficiencies
across the academic workflow. A prime example is the current ERP system in use at institutions
like https://erp.nec.edu.in/std/, where the functionality is largely skewed towards
administrative control. In such systems, students are relegated to passive users, merely able to
view academic data that has already been entered and validated by faculty or administrative
staff. While this provides a degree of centralized control, it fails to capitalize on the full
potential of digital engagement and real-time collaboration.

This project proposes an advanced SRMS that overcomes the inherent limitations of
such traditional models. Designed to be dynamic, scalable, and user-inclusive, the proposed
system empowers students to actively participate in their academic data lifecycle — including
document submissions, status tracking, and communication with faculty — while ensuring
secure, multi-level approval and audit mechanisms. Built using modern frameworks such as
React (Vite) for the frontend and Node.js with MySQL for the backend, the system introduces
real-time notifications, automated workflows, and role-based access control. This enhanced
SRMS aims to create an ecosystem where data flows securely and efficiently, accountability is
embedded, and both students and faculty are empowered to collaborate more effectively.

1
1.1 BACKGROUND OF THE EXISTING SOFTWARE/SYSTEM

The existing system implemented at institutions like NEC, accessible via

https://erp.nec.edu.in/std/, is a web-based ERP solution primarily managed and controlled by
administrative staff. While the system provides access to academic records such as attendance,
internal assessment marks, timetables, and examination results, it follows a highly centralized
model. In this architecture, all updates whether they relate to academic scores, document
approvals, or personal record modifications are exclusively handled by faculty or admin users.
Students have no capability to submit or initiate updates within the system. Their interaction is
limited to viewing their existing records.

Though this approach ensures tight control over data integrity and minimizes erroneous
inputs from students, it introduces significant drawbacks in terms of scalability, student
engagement, and administrative efficiency. When students need to submit documents such as
bonafide certificate requests, internship approvals, or leave applications the process typically
occurs outside the ERP platform via email or paper forms. Faculty and administrative staff are
then responsible for manually verifying the documents and updating the ERP accordingly. This
manual intervention leads to operational bottlenecks, especially during high-volume periods
like examination registrations or result processing.

Moreover, the current ERP lacks features like real-time status updates, automated
notifications, and dynamic validation. Students often have no visibility into the progress of
their requests unless they personally follow up with faculty or administration. The lack of
interaction leads to delays, miscommunication, and in some cases, duplication of efforts. While
the ERP is functionally stable and reliable for data storage and display, its rigid structure does
not accommodate modern academic workflows that require agility, collaboration, and
transparency.

This centralized structure also poses limitations for institutions aiming to implement more
interactive features, such as student feedback integration, smart progress trackers, or AI-driven
academic advising. With growing institutional demand for digital transformation and
compliance with data privacy and transparency standards, the current system shows clear
limitations that warrant a reimagination of student record management processes.

2
1.2 PROBLEM STATEMENT

The core challenge with the existing ERP system lies in its restricted user participation and
administration-heavy workflows. In an educational environment that increasingly demands
speed, transparency, and student-centric processes, relying solely on administrative personnel
to manage all academic data presents a fundamental bottleneck.

Students, who are primary stakeholders in their educational journey, are unable to submit,
track, or interact with their academic records. All data updates including personal details, grade
corrections, certificate requests, or disciplinary appeals must be routed through faculty or
admin staff, typically via offline or disconnected channels like emails, handwritten
applications, or one-on-one meetings. This leads to data silos, miscommunication, missed
deadlines, and often dissatisfaction among students due to lack of status visibility.

Faculty members, too, are burdened with redundant administrative tasks such as document
verification, manual data entry, and responding to status inquiries. These distractions take away
from their core academic responsibilities. The absence of automation means that approval
workflows are inconsistent and dependent on individual staff availability, resulting in delays
and potential errors in academic records.

Moreover, the existing system lacks real-time communication mechanisms. Students are
not notified when their requests are processed, and faculty have no easy way to escalate issues
or revert inaccurate submissions. Without a standardized workflow, approvals can be delayed
indefinitely, and accountability is lost in the process.

From a technological standpoint, the current ERP is also not designed for modular growth.
Integrating AI modules, adding mobile support, or applying advanced analytics would require
considerable redevelopment, making the system inflexible in the long term. There is no built-
in mechanism for audit trails, multi-level access control, or intelligent alerts all of which are
essential in a modern, regulation-compliant academic system.

3
 These limitations underscore the need for a re-engineered system that enables
decentralized collaboration with centralized oversight, bringing in automation, real-time
updates, and accountability into student record management.

1.3 NEED FOR INNOVATION

The current era of digital transformation in education calls for smarter, more adaptable
systems that can meet the evolving needs of institutions, faculty, and students. The
shortcomings of the traditional ERP systems particularly in institutions like NEC present a
compelling case for innovation in the field of student record management.

One of the primary drivers of innovation is the need for role-based interactivity. Students
should not be passive recipients of academic information but active participants in the
administrative processes that affect them. Enabling students to submit records, request changes,
upload documents, and track the progress of their submissions fosters transparency,
accountability, and engagement.

Another important consideration is automation. Manual workflows create dependencies,

inefficiencies, and delays. A modern SRMS should automate status changes, send real-time
alerts via email or SMS, and route requests through predefined workflows that ensure timely
resolution. This reduces administrative overhead while improving the user experience for both
staff and students.

Innovation is also required in terms of security and compliance. With increasing scrutiny
on data privacy, institutions must adopt systems that provide encrypted storage, audit trails,
and customizable access permissions. Regulatory bodies expect academic systems to offer full
traceability of actions, a feature that legacy ERPs often lack.

Further, there is a growing demand for interoperability. Academic systems must now
connect seamlessly with Learning Management Systems (LMS), examination platforms,
placement portals, and external verification agencies. A modular and API-ready SRMS enables
such integrations with ease.

4
 Finally, innovation should aim to improve communication. By integrating tools like
automated notifications (e.g., using Nodemailer), in-system messaging, and status dashboards,
stakeholders can stay informed without needing constant follow-ups.

The proposed SRMS addresses all these needs by providing a secure, modular, real-time,
and user-inclusive system that aligns with modern institutional goals and global standards for
academic record management.

1.4 OBJECTIVES OF THE PROJECT

The primary objective of this project is to design and implement a robust, web-based
Student Record Management System (SRMS) that effectively overcomes the limitations of the
current ERP systems and aligns with the growing technological and operational demands of
modern educational institutions. The system aims to decentralize certain administrative
workflows by empowering students to directly participate in their academic processes. This
includes the ability to submit personal documents, academic forms, and service requests
through the platform, while ensuring that proper administrative and faculty approval
mechanisms are in place to maintain oversight and data accuracy.

To support secure and efficient operations, the system will incorporate Role-Based
Access Control (RBAC), which establishes a tiered access structure for different user
categories — such as students, faculty, and administrators each with well-defined permissions.
This structure allows for greater accountability and traceability of all interactions within the
system. Another key objective is the implementation of real-time notification and tracking
mechanisms. By integrating tools like Nodemailer, the system will deliver automated email
alerts to users at every stage of their submission and approval lifecycle, thereby reducing delays
and eliminating the need for manual follow-ups.

The SRMS will also promote improved communication and collaboration between
students and faculty by providing in-app dashboards that allow users to monitor submission
statuses, provide feedback, and escalate unresolved issues in a transparent, traceable manner.
From a technical standpoint, the system will be built using scalable, modern technologies such
as React, Node.js, and MySQL. This architecture ensures not only ease of maintenance but also

5
potential for integration with Learning Management Systems (LMS), digital identity platforms,
and other institutional tools. Security and data privacy will be integral to the system, with
features such as data encryption, audit logging, and compliance with regulations like GDPR
and FERPA. The user interface will be designed with a user-first approach — intuitive, mobile-
responsive, and accessible — ensuring a seamless experience across user roles. Altogether,
these objectives aim to establish a modern, efficient, secure, and student-friendly SRMS that
supports institutional goals and digital transformation.

1.5 EXPECTED OUTCOMES

The successful implementation of the proposed Student Record Management System

(SRMS) is expected to deliver a wide array of practical and transformative outcomes that will
benefit students, faculty, and administrative staff alike. One of the most immediate impacts will
be the streamlining of document submission and approval workflows. Students will be able to
directly upload their requests and necessary documents through the platform, after which the
system will route them automatically through predefined approval chains. This structured,
digitized process will significantly reduce turnaround time and minimize the administrative
burden on staff.

Real-time visibility and accountability will be introduced through the use of status
dashboards and automated email notifications, keeping both students and faculty informed
about the progress of submissions at each stage. This will foster a sense of transparency, reduce
confusion, and eliminate the need for repetitive follow-ups. The system's validation rules and
structured workflows will help minimize manual errors and ensure the integrity of records,
with every action traceable for future reference. Faculty productivity is also expected to
improve, as they will spend less time on routine administrative work and more on core
academic responsibilities.

From a data security perspective, the SRMS will offer enhanced protection through
encrypted storage, access control mechanisms, and audit logs, ensuring compliance with
national and international data privacy regulations. Technologically, the system will be built on
a scalable architecture that can adapt to future requirements and integrate with other digital

6
tools used within the institution. As a result, the platform will not only support current needs
but also be prepared for expansion across departments or campuses.

Student satisfaction is projected to increase due to the transparency, ease of access, and
quicker service delivery. With greater visibility into their academic processes and reduced
uncertainty, students will feel more connected and empowered within the institution.
Additionally, by centralizing and cleaning student data, the system lays the groundwork for
smart analytics, including AI-based insights into academic performance, engagement levels,
and advising opportunities. In conclusion, the SRMS is expected to revolutionize the
management of student records by introducing a comprehensive, intelligent platform that
elevates operational efficiency and enriches the academic experience for all stakeholders.

CHAPTER 2

REVERSE ENGINEERING OF EXISTING SOFTWARE

2.1 EXISTING SYSTEM OVERVIEW

The existing Student Record Management module currently in use is integrated within
the ERP platform available at https://erp.nec.edu.in/std/. This centralized web-based system
offers students access to a limited set of academic services such as viewing their academic
results, attendance records, internal marks, time tables, and fee payment details. While it
provides a comprehensive overview of academic data, it is heavily controlled by administrative
users, offering students little to no opportunity for interaction beyond the scope of viewing or
downloading static information.

A major limitation of the current system lies in its lack of user-driven functionality.
Students are unable to initiate academic or administrative requests, submit documents, or track
the real-time status of approvals. Actions such as submitting internal assessment corrections,
updating student details, or requesting official letters must be done offline—through physical
forms, email correspondence, or direct communication with staff. This manual approach
introduces delays, increases the risk of miscommunication, and leads to inefficient data
management workflows.

7
 As illustrated in Figure 2.1, ERP System Dashboard, the interface primarily supports a
read-only experience for students, while full control over data input, modification, and
validation remains in the hands of faculty or administrative personnel. While the system fulfils
its role as a centralized information hub, its lack of student engagement and transactional
features hampers real-time interaction and streamlined digital operations.

Figure 2.1: ERP System Dashboard

2.2 SOURCE CODE ANALYSIS

As the ERP system is proprietary and its source code is not publicly available, a full
code-level reverse engineering is restricted. However, based on front-end inspection through
browser developer tools and network tracking, it appears the system is built using traditional
server-side rendering technologies, possibly PHP or ASP.NET, paired with a relational database
backend such as Oracle or SQL Server.

JavaScript is minimally used in the frontend, with limited client-side interactivity. Pages
are loaded from the server upon every request, and no modern single-page application (SPA)
structure is observed. The layout is largely static and non-responsive, lacking mobile-first

8
design principles. Session management appears to be handled through cookies, and all business
logic is tightly coupled with the backend, limiting flexibility and scalability.

This is further confirmed through Figure 2.2, which displays HTML and JavaScript
elements from the browser developer tools. The figure reveals static DOM structures, minimal
use of JavaScript for dynamic interaction, and an absence of modular or component-based
design, suggesting an outdated tech stack.

Figure 2.2: HTML/JavaScript Elements of ERP Module

2.3 FUNCTIONAL ANALYSIS

Functionally, the existing ERP system provides a limited set of services that are mainly
passive in nature. These include viewing academic results, course registration status,
attendance summaries, and personal details. There is no feature for document uploads, no
request management module, and no student-to-faculty interaction tool within the system.
Faculty and admin members input data manually through backend panels that are not exposed
to the student view.

9
 There is no workflow automation; document approvals, leave applications, or feedback
handling must be conducted through external means. Students cannot raise tickets, monitor
progress, or engage in real-time communication with approvers. Additionally, role-based
functions are limited — admin users possess broad privileges while students are granted only
read access to selected modules.

This limited scope of functionality is mapped in Figure 2.3, which offers a functional
overview of the ERP platform. The figure demonstrates the clear segregation between student
and admin roles, indicating a unidirectional data flow and absence of role-based interactivity
or automation tools.

Figure 2.3: Functional Overview of Existing ERP

2.4 PERFORMANCE ANALYSIS

The performance of the ERP system is functional but not optimized. Page loads are
relatively slow due to server-side rendering and lack of asynchronous loading. Each page
reloads entirely on every interaction, creating a delay in user response time. On peak usage
hours such as result announcements or fee deadlines, the system occasionally becomes sluggish

10
or unresponsive, indicating backend performance constraints or lack of load balancing
mechanisms.

The performance issues are evident in Figure 2.4, which provides an analysis of page
load times. The figure highlights long TTFB (Time to First Byte) values and a complete reload
for every user interaction, reinforcing the inefficiency of the current rendering strategy.

The absence of caching, asynchronous data fetching, or content delivery optimization

affects the overall responsiveness. Additionally, the lack of progressive web app (PWA)
capabilities prevents offline access and limits mobile usability.

Figure 2.4: Page Load Time Analysis

2.5 SECURITY AND PRIVACY ANALYSIS

Security-wise, the ERP platform uses secure HTTPS connections, which helps protect
data during transmission. However, there is no visible implementation of multi-factor
authentication (MFA) or session timeout warnings, both of which are essential for sensitive
student data protection. The system uses basic form validation but lacks visible CSRF (Cross-

11
Site Request Forgery) or XSS (Cross-Site Scripting) protections on input fields based on
browser-side testing.

There is no audit trail or change log available to users, meaning there is no transparency
about who made changes or accessed specific records. This poses potential privacy risks and
makes it difficult to comply with data protection regulations such as GDPR or India’s Personal
Data Protection Bill.

Figure 2.5 illustrates the system’s HTTP security headers. It shows the absence of
advanced policies such as Content Security Policy (CSP) or HTTP Strict Transport Security
(HSTS), underlining the basic level of implementation and potential exposure to web-based
attacks.

Figure 2.5: Security Headers Inspection

2.6 IDENTIFIED LIMITATIONS

The reverse engineering of the current ERP system has highlighted several key
limitations. Firstly, the platform is highly centralized and rigid, offering no self-service
capabilities to students. Document workflows, form submissions, and communication must
occur through external channels, creating fragmentation and inefficiencies. Secondly, the
system is not scalable or adaptable to modern digital standards due to its static front-end, lack
of mobile optimization, and absence of real-time data exchange.

12
 From a security perspective, although encrypted connections exist, the lack of detailed
access control layers, user-level logging, and modern authentication methods limit the system’s
ability to securely manage sensitive information. Furthermore, the system is not compliant with
advanced data privacy frameworks and lacks modularity for integration with newer platforms
such as Learning Management Systems (LMS), AI-based analytics tools, or mobile apps.

CHAPTER 3

FORWARD ENGINEERING PROCESS

3.1 PROBLEM INDENTIFICATION AND USER ANALYZE

3.1.1 PROBLEM UNDERSTANDING

The development of a modern Student Record Management System (SRMS) was

initiated in response to the limitations observed in the existing ERP platform used at NEC,
accessible via https://erp.nec.edu.in/std/. The current system functions primarily as a read-only
interface, where students can access their academic information such as internal marks,
attendance, and timetables. However, all updates and changes to this data must be processed
exclusively by faculty or administrative staff. This centralized model has led to inefficiencies
in workflow, delays in processing requests, and a communication gap between students and
staff. Additionally, the absence of any request initiation or document submission feature for
students has created a passive user experience, reducing their autonomy and engagement within
the academic system.

3.1.2 IDENTIFYING USERS & STAKEHOLDERS

The SRMS was designed with the needs of diverse users in mind. These include
students, faculty members, administrative staff, and institutional decision-makers. Each group
interacts with student records in distinct ways. Students require the ability to upload academic
documents, request services, and track approval statuses. Faculty members need streamlined
workflows to validate and respond to student submissions. Administrative personnel require a
centralized platform to manage requests, maintain data integrity, and oversee compliance. The

13
development team ensured that each user group’s expectations and responsibilities were
carefully analyzed and documented as a foundation for the system design.

3.1.3 EMPATHIZING WITH USERS

Empathy mapping and user-centerd design techniques were applied during the early
stages of development. This involved conducting interviews, feedback sessions, and direct
observation of students and staff using the existing ERP system. These interactions helped
reveal pain points such as delays in document processing, lack of submission tracking, unclear
communication channels, and the repetitive nature of manual approvals. Through these
insights, it became clear that a system designed with active participation, clarity, and process
automation would significantly improve the academic experience for all users. The insights
gathered were visually organized using an empathy map to better understand what users think,
feel, see, and do during their interaction with the current system, as illustrated in Figure 3.1.

Figure 3.1: Empathy Map for Student and Faculty Users

14
3.1.4 DEFINING THE PROBLEM

Based on the observations and user inputs collected during the empathy and research
phases, the core problem was identified as a significant lack of autonomy, visibility, and
workflow automation in the management of academic records. The current ERP platform
restricts users to passive roles particularly students who have no means of initiating or tracking
their requests within the system. Furthermore, faculty and administrative personnel face
challenges in managing approvals and document verifications due to the absence of structured
digital workflows. This results in delays, inefficiencies, and frequent miscommunications. The
proposed solution, a Student Record Management System (SRMS), aims to overcome these
limitations by introducing a decentralized yet controlled environment. Within this framework,
students can initiate record-related actions, faculty members can validate and respond
efficiently, and administrators can maintain oversight with role-based access and process
finalization. The overall interaction among stakeholders is streamlined and structured, as
outlined in Figure 3.2, which illustrates the multi-directional communication and functional
relationships among system users.

Figure 3.2: Stakeholder Interaction Diagram for SRMS

15
3.2 SOFTWARE ARCHITECTURE AND DESIGN

3.2.1 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

The requirements for the SRMS were formally captured in a Software Requirements
Specification (SRS) document. Functional requirements included features such as user
authentication, document submission, approval lifecycle management, notification alerts, and
audit trails. Non-functional requirements focused on system scalability, data privacy, platform
independence, and performance efficiency. These specifications ensured that the SRMS would
not only fulfill its intended functions but also meet quality benchmarks in security,
maintainability, and user accessibility.

3.2.2 ARCHITECTURAL DESIGN

The architectural design of SRMS is based on a three-tier model consisting of a

presentation layer, application layer, and data layer. The frontend, developed using React.js and
Tailwind CSS, is responsible for delivering a responsive and intuitive user interface across
devices. The backend is built using Node.js and Express.js, offering an asynchronous and
scalable environment for handling business logic and API requests. The database layer is
powered by MySQL, chosen for its reliability in managing structured academic data.

As illustrated in Figure 3.3, the architectural diagram shows how each of these layers
interact: the Presentation Layer includes the React-based UI accessed by students and
administrators through browsers or mobile devices. These users interact with the Application
Layer, where the Express.js API server handles routing, authentication, business logic, and
integration with external services like Node-mailer for email notifications. Finally, the Data
Layer houses the MySQL relational database, structured to maintain consistency and integrity
across various academic and administrative entities. This architecture supports modular
development, simplifies maintenance, and ensures scalability.

Each module—user management, submission tracking, approvals, and notifications—

was designed as a loosely coupled service communicating through RESTful APIs, laying the
groundwork for a potential microservices-based transition in the future.

16
 Figure 3.3 Architecture Design of SRMS

3.2.3 TECHNOLOGY STACK SELECTION

The technology stack for the SRMS was carefully curated to ensure scalability, security,
and performance across all layers of the application. On the frontend, React.js was selected for
its modular, component-based architecture and its ability to efficiently manage dynamic state
changes, which is essential for interactive dashboards and real-time updates. The application
build and bundling were managed using Vite, which provided significantly faster development
and compilation times compared to traditional tools like Webpack.

As mentioned in Figure 3.4, On the server-side, Node.js was used in combination with
Express.js to build a lightweight, asynchronous backend architecture. This setup ensured non-
blocking request handling, making it highly responsive under concurrent workloads. For data
storage, MySQL was chosen due to its strong relational model and proven stability in managing
structured academic records. Complex relationships between students, departments, and

17
document workflows were efficiently handled through normalized schema design and foreign
key enforcement.

Security was a priority throughout the stack. JWT (JSON Web Tokens) enabled stateless
and secure authentication, ensuring protected API access for each user role. Additionally,
Nodemailer was integrated to handle automated email notifications for submission updates and
approval statuses, enhancing user engagement and process transparency.

Figure 3.4: Technology Stack Diagram used in the development of SRMS

3.2.4 DATABASE DESIGN

The database design for the Student Record Management System (SRMS) follows a
normalized relational model to maintain data consistency, integrity, and to support the
comprehensive functionality of the system. Through the use of primary and foreign keys, each
table maintains clear and logical relationships with other entities, ensuring streamlined
operations and referential integrity. The Entity-Relationship (ER) diagram, presented in Figure
3.5, illustrates the structural overview of the database, showing the interconnections between
essential entities such as student details, user accounts, departments, online courses, events,

18
internships, achievements, leave requests, scholarships, and approval logs. Additionally, the
flow diagram shown in Figure 3.6 depicts how different users interact with the system and how
data flows between modules for various processes such as approvals, event participation, and
profile management. These visual models help to understand the complex interactions in the
SRMS effectively and ensure clear mapping of functionalities.

Figure 3.5: Database ER Diagram for SRMS

19
 Figure 3.6 Flow Diagram of SRMS Operations

The student_details table (Figure 3.7) captures the personal and academic details of
every student in the institution. It includes fields such as student ID, name, department ID, date
of birth, email, phone number, and profile image. Admin users have full control over this table
and are permitted to add, update, delete, and view student records as required. Faculty members
are permitted to view student details for academic monitoring and guidance purposes, while
students themselves can view and update their personal details, particularly contact
informationa and profile images

20
 Figure 3.7 student_details Table entry

The users table (Figure 3.8) is critical for maintaining authentication details and role
assignments for all users of the SRMS platform. This table contains user ID, username, hashed
password, role (which could be Admin, Faculty, or Student), and a reference to the linked
student ID or faculty ID. Admin users manage the entire lifecycle of user accounts, including
creating new accounts, modifying existing ones, deleting users, and assigning roles. Faculty
and students can update their own credentials, such as changing passwords, and view their
profile information.

Figure 3.8 users Table entry

The departments table (Figure 3.9) lists all academic departments within the institution.
Each record includes the department ID and department name. Admins have complete control
to add, update, and remove department entries to keep the list current with institutional changes.

21
Both faculty members and students can view the department list to stay informed about
department details and offerings.

Figure 3.9 departments Table entry

The online_courses table (Figure 3.10) records details of approved online courses that
students can take as part of their academic or skill development journey. This table includes
the course ID, title, provider, and duration of the course. Admin users are responsible for
managing the full set of courses by adding, editing, and deleting entries. Faculty members have
the ability to suggest new courses and update existing ones to align with evolving academic
needs. Students are permitted to view the available courses and enroll in those relevant to their
field of interest.

Figure 3.10 online_courses Table entry

The event_organised table (Figure 3.11) contains records of events initiated by either
the institution or the student community. Fields include event ID, event name, organizer details,
date, and location. Admin users manage all events comprehensively, including creation,
updates, and deletions. Faculty members can propose and organize events, updating details as

22
necessary, while students primarily have viewing access and may participate in events based
on eligibility.

Figure 3.11 events_organized Table entry

Complementing this is the event_attended table (Figure 3.12), which tracks the
participation of students in various events. It includes attendance ID, student ID, event ID, and
participation status. Admins and faculty members are both able to add and verify student
participation records, while students can view their own participation history.

Figure 3.12 event_attended Table entry

The internship table (Figure 3.13) records the details of internships undertaken by
students, including internship ID, student ID, company name, duration, and role. Admin users
oversee this table to ensure correctness of entries, and faculty members can update records as
students progress in their internships. Students can add their internship details for faculty
review and later view the status of their entries.

23
 Figure 3.13 internship Table entry

The student_leave table (Figure 3.14) handles student leave applications, containing
leave ID, student ID, reason for leave, start date, end date, and status. Students submit leave
requests, which faculty members are responsible for reviewing and approving or rejecting.
Admin users can oversee all leave requests for auditing purposes.

Figure 3.14 student_leave Table entry

Finally, the scholarships table (Figure 3.15) maintains records of scholarships applied
for or awarded to students, including scholarship ID, student ID, scholarship name, amount,
and status. Admins manage this table comprehensively, while faculty members assist in
verifying scholarship eligibility. Students can submit applications and monitor their scholarship
status.

Figure 3.15 scholarships

Through this comprehensive relational structure, SRMS ensures efficient data

management, secure user interactions, and transparent approval workflows. The database

24
design supports scalability and future expansion while maintaining high levels of integrity and
performance.

3.3 DEVELOPMENT AND IMPLEMENTATION

3.3.1 ALGORITHM AND DATA FLOW DESIGN

The backbone of the SRMS lies in its state-driven document handling algorithm, which
ensures that every academic submission transitions through a controlled, role-specific
workflow. This workflow is governed by predefined states such as “Pending Review,” “Faculty
Verified,” “Admin Approved,” and “Rejected.” These transitions are enforced using backend
logic that validates user inputs, applies role-based access control, and updates status fields
accordingly. Additionally, a comprehensive logging mechanism captures every action in real-
time, enhancing transparency, auditability, and accountability across the system.

From the student’s perspective, the workflow initiates with the submission module.
Students upload necessary documents such as leave requests, internship certificates, or
scholarship forms through a validated input interface. Once a submission is successfully
verified for format and required fields, it is stored in the database and marked with the status
“Pending Review.” At this point, it becomes available to the respective faculty for review. The
system simultaneously sends a notification to the student and allows real-time tracking of the
submission through the student dashboard.

Figure 3.16 illustrates the Student Submission Workflow, highlighting each transition
from submission initiation to faculty visibility.

25
 Figure 3.16: Student Workflow – Data Flow Diagram

Once the submission enters the faculty layer, the review process begins. Faculty
members access a personalized dashboard listing pending student submissions. After reviewing
the documents, they can either approve the submission (transitioning the status to “Faculty
Verified”) or reject it, providing remarks explaining the decision. These actions trigger
corresponding updates in the system and notify the student of the outcome.

Figure 3.17 presents the Faculty Review Workflow. This diagram captures the decision
logic, status transitions, and system responses following faculty validation. It ensures that each
submission is processed in a timely and traceable manner, forwarding validated records to the
administrative tier for final approval.

26
 Figure 3.17: Faculty Workflow – Data Flow Diagram

In the final stage, administrators handle only those records that have been faculty-
verified. Using a centralized dashboard, administrators can further validate submissions and
either approve them (status updated to “Admin Approved”) or reject them with feedback.
Approved submissions are then securely stored in the institution’s digital repository. All
administrative actions are logged with a timestamp and user identifier to preserve traceability
and ensure compliance with institutional data governance policies.

27
 Figure 3.18 illustrates the Admin Approval Workflow. It details the restricted access to
pre-verified entries, the decision pathways available to administrators, and the logging
architecture that supports institutional accountability and long-term data integrity.

Figure 3.18: Admin Workflow – Data Flow Diagram

3.3.2 MODULES

The Student Record Management System (SRMS) is structured into four key functional
modules—Student, Faculty (Tutor), Department Administrator, and College Administrator.
Each module is designed to cater to the specific roles and responsibilities of its user group,
ensuring efficient workflows, controlled access, and accountability.

28
 The student module serves as the primary interface for students to manage their
academic records. Upon login, students are presented with a personalized dashboard, from
which they can update their profiles, upload academic documents (e.g., leave applications,
internship records), and submit formal requests. Each request enters a structured approval
workflow that begins with faculty validation. Students are notified of submission statuses
through system alerts and automated emails. Additionally, the dashboard allows access to
previously approved documents and feedback history. The intuitive UI is designed to improve
engagement and ensure a seamless user experience. As shown in Figure 3.19, the student
dashboard comprises fields for profile updates, sections for uploading documents, and visual
indicators for request status and approved mail alerts.

29
 Figure 3.19: Student dashboard showing profile update, document submission and status
alerts

Faculty members act as validators for student submissions. Through the tutor module,
faculty can access a filtered list of assigned students, organized by department and semester.
Incoming requests are displayed on the dashboard, where tutors can approve or reject them
with remarks. The system includes a built-in messaging tool for requesting clarifications
directly from students. Tutors also have access to historical approval logs, enabling traceability.
They do not alter student data but verify authenticity before forwarding approved requests to
the department level. As illustrated in Figure 3.20, the tutor interface includes a student list, a
request approval panel, and a communication console.

30
Figure 3.20: Tutor Interface with student list, approval panel, and messaging tool.

31
 The Department Administrator, typically the Head of the Department (HOD), oversees
records within their department. Their module offers tools to manage students, perform bulk
uploads, and monitor faculty activity. Dashboards are equipped with filters to sort records by
name, semester, or course. While they do not directly participate in the approval process,
department admins maintain oversight on workflows, ensuring compliance with institutional
policies. As depicted in Figure 3.21, the department admin panel allows access to detailed
student records, bulk upload functionalities, and department-specific filters.

Figure 3.21: Department admin panel with student listings, bulk upload and filters.

The college admin module is reserved for high-level users such as the Dean or Principal.
These users are granted read-only access to all department-level data across the institution.

32
Their dashboard provides summary analytics, including submission trends, faculty response
times, and student participation rates. They are responsible for institution-wide auditing and
reporting, but do not modify records or interfere in operational workflows. Though college-
level actions are observational, their insights are critical for academic planning and policy
implementation. The overview shown in Figure 3.22 highlights the aggregated dashboard for
cross-departmental data review and analytics.

Figure 3.22: College Admin Dashboard featuring with cross-departmental analytics.

33
3.3.3 FEATURE IMPLEMENTATION

Every module was implemented with an emphasis on simplicity and usability. Features
include drag-and-drop file uploads, visual status indicators for submissions, real-time alerts for
changes, and user-friendly forms with input validation. Backend APIs were secured and
designed for performance, with error handling and response standardization implemented
across the system.

3.3.4 UI/UX CONSIDERATIONS

User interface design followed mobile-first and accessibility-friendly principles. The

system was tested across various devices to ensure responsiveness. UI components were built
using Tailwind CSS, ensuring consistency and clarity. Each dashboard was tailored to the
specific needs of the user role it serves, providing relevant information and shortcuts without
overwhelming the user.

3.3.5 SECURITY AND PRIVACY ENHANCEMENTS

Security was prioritized throughout the development lifecycle of the SRMS.

Authentication was implemented using JSON Web Tokens (JWT), which ensures that user
sessions remain stateless and secure. Upon successful login, the server issues a signed token
that the client includes in the header of every request. This token is verified on each API call
to confirm authenticity and prevent unauthorized access. Additionally, JWTs contain embedded
claims like user ID and role, which help enforce role-based access controls throughout the
system.

Passwords were securely handled using bcrypt hashing. Instead of storing plain-text
passwords, each password is salted and hashed before being saved in the database. This
approach ensures that even in the event of a data breach, actual passwords remain protected
due to the irreversible nature of hashing and the computational resistance provided by bcrypt.

Sensitive user data, such as student academic records and bank details, were encrypted at rest
using AES-based encryption. Access to these datasets is regulated through role-based

34
authorization, restricting visibility and operations based on the authenticated user’s
permissions.

To visually represent the security model used in the SRMS, Figure 3.23 illustrates the
JWT-based authentication and bcrypt password hashing process, highlighting the secure flow
from login to token validation and protected resource access.

Figure 3.23: JWT Authentication and Bcrypt Hashing Process

3.4 TESTING AND VALIDATION

3.4.1 UNIT TESTING

Unit testing was rigorously applied to each core backend function using the Jest testing
framework. These tests were executed in isolation to validate the behavior of individual units
such as file upload validation, JWT token handling, and status update logic. Mock data was
used to simulate various scenarios including successful requests, failed verifications, and

35
permission-based constraints. The objective was to identify any logic inconsistencies at the
micro-level before full system integration.

Figure 3.24 displays the Thunder Client testing output for a unit test of the pending
online courses API endpoint, confirming that the correct status transition occurs and that proper
response messages are returned.

Figure 3.24: Unit testing output using Thunder Client.

3.4.2 FUNCTIONAL TESTING

Functional testing validated the system’s overall workflow from the perspective of
multiple users students, faculty, and administrators. Thunder Client was used to simulate
realistic API requests corresponding to actual user behavior. A complete submission cycle was
tested: starting with a student request, followed by faculty approval, and culminating in admin
finalization. This ensured that user privileges, data flow, and status transitions behaved as
expected under integrated conditions.

As seen in Figure 3.25, the functional test simulates a successful academic update
workflow, with Thunder Client confirming each stage via HTTP response codes and status
payloads.

36
 Figure 3.25: Functional testing output showing course update

3.4.3 PERFORMANCE TESTING

Performance testing was conducted to assess the scalability and responsiveness of the
SRMS platform under concurrent user load. Using load simulation tools, the system was
subjected to increasing traffic, starting from 50 users and scaling up to over 200 concurrent
users. Throughout this simulation, the server consistently maintained response times below 1.5
seconds for standard API calls such as login, document upload, and status updates. This
indicates the platform is capable of supporting real-time academic workflows at institutional
scale without degradation in performance.

As illustrated in Figure 3.26, the performance test results show stable throughput and
acceptable latency under concurrent load conditions, verifying the system's readiness for
deployment in a live academic environment.

37
 Figure 3.26: Performance testing output with response time metrics.

3.4.4 USER TESTING AND FEEDBACK

User testing involved students and faculty engaging with the platform in real-time
scenarios. Their feedback led to the improvement of error messages, visual flow clarity, and
the addition of tooltips and contextual help.

3.4.5 ITERATIVE IMPROVEMENTS

Based on testing results, iterative updates were made to the UI, backend logic, and
system notifications. New features such as deadline reminders, export options, and batch
actions were also introduced during this phase.

3.5 COMPARATIVE ANALYSIS AND RESULTS

A comparative evaluation was conducted between the proposed SRMS and the existing
ERP system to assess performance across key metrics. The SRMS significantly improved user
engagement by allowing students to initiate requests and track their progress in real time—
capabilities not available in the ERP. The approval process, which previously took days due to
email-based workflows, was reduced to a matter of hours due to automated routing and

38
notifications. Communication between stakeholders became seamless, thanks to the centralized
dashboards and instant status updates. Faculty members experienced a noticeable reduction in
workload, as the structured submission system reduced back-and-forth communication. From
a security standpoint, the SRMS introduced encrypted data storage, audit trails, and strict
access control, greatly enhancing privacy. Overall, the system's flexibility, modularity, and
modern interface offered a transformative improvement over the ERP system, making it
suitable for long-term institutional adoption.

CHAPTER 4

CONCLUSIONS AND FUTURE SCOPE

4.1 SUMMARY OF KEY FINDINGS

The development and implementation of the proposed Student Record Management

System (SRMS) mark a significant step forward in addressing the inefficiencies and limitations
of the existing ERP system used at NEC, where student interaction is largely restricted to a
view-only mode and all updates are handled exclusively by administrators. Through a
comprehensive forward engineering process, the new SRMS was designed to facilitate a
decentralized yet controlled data workflow, enabling students to actively participate in their
academic journey by submitting documents and requests, which are then validated and
processed through an organized hierarchy involving faculty and administrators. This structure
improves operational transparency, encourages accountability, and reduces the workload
bottlenecks often experienced in centralized systems.

One of the key findings of this project is the critical role of automation and user-centric
design in enhancing institutional efficiency. The integration of real-time notifications using
Node-mailer, alongside an intuitive and mobile-responsive frontend built on Vite React,
significantly improves communication and accessibility. The backend, developed using
Node.js and Express.js, interacts seamlessly with a MySQL database, ensuring both
performance and data reliability. The implementation of role-based access control (RBAC) has
added an essential layer of security, delineating permissions based on user roles and minimizing
unauthorized access or accidental data manipulation.

39
 The system has also demonstrated its strength in ensuring data integrity and compliance
with privacy standards through the use of audit logs, secure authentication, and structured
workflows. The modular architecture allows for scalable development and easy future
integration with learning management systems and other institutional platforms. Overall, the
SRMS provides a modern, efficient, and secure environment for student data handling, aligning
closely with the digital transformation goals of educational institutions.

4.2 FUTURE ENHANCEMENTS

Although the current version of the SRMS successfully addresses the core requirements
of student record submission, verification, communication, and tracking, there are multiple
opportunities for future enhancements to expand its functionality and impact. A priority in the
upcoming development phase is the integration with existing Learning Management Systems
(LMS), which would allow seamless synchronization of student academic data, including
grades, course materials, and attendance. This would create a more comprehensive academic
profile and support better institutional oversight.

Another key enhancement involves the development of a dedicated mobile application,

allowing users to access the platform through their smartphones. Such an app would provide
push notifications for real-time updates, offline data caching, and integration with mobile-
specific features such as biometric login for added security and ease of access. Furthermore,
incorporating AI and machine learning models into the system could lead to predictive features
such as performance analytics, early warning systems for students at risk of academic failure,
and automated assistance tools for students and staff.

To improve inclusivity, multilingual support will be considered to cater to a broader

range of users, especially in diverse educational environments. Additionally, expanding the
SRMS to integrate with national academic verification and scholarship portals would
streamline documentation processes for institutions and government bodies alike. Finally,
implementing advanced data visualization dashboards for administrative users would support
data-driven decision-making by providing real-time insights into student performance trends,
submission statistics, and system usage analytics.

40
 These enhancements aim to transform the SRMS into a holistic academic management
platform that supports the evolving needs of modern educational institutions while ensuring
accessibility, security, and efficiency.

CHAPTER 5

OUTCOME

The implementation of the new Student Record Management System (SRMS) has
resulted in measurable improvements across several critical dimensions of institutional record
handling. The outcome of this project reflects a successful departure from the limitations of the
existing ERP system in which students were only able to view records while administrators
were solely responsible for all data entries and updates. With the new SRMS, data submission
responsibilities are more democratically distributed, allowing students to actively participate
in administrative processes by uploading necessary academic documents, leave requests, and
other relevant forms directly through the system. This decentralization significantly reduces
dependency on administrative personnel, thereby lowering bottlenecks and improving
turnaround times.

In terms of user experience, the system provides a much more transparent and
interactive interface. Students are no longer left in the dark regarding the status of their
submissions. They receive real-time notifications via email at every stage of the workflow—
from submission to approval—ensuring clear communication and reducing anxiety or
confusion related to pending academic processes. For faculty and administrative staff, the
automated workflows and status tracking tools allow for faster processing, improved
accountability, and reduced chances of human error. The structured backend, developed using
Node.js and MySQL, supports data integrity while enabling smooth concurrent access for
multiple users without performance degradation.

The outcome also includes increased compliance with data privacy and security
regulations. The use of role-based access control, audit trails, and secure storage protocols
ensures that sensitive academic records are handled responsibly and ethically. Moreover, the
system’s modular architecture lays the groundwork for future scalability and integration with

41
other institutional platforms, such as learning management systems or national academic
verification databases. In summary, the outcome of this project has been the successful
development of a secure, efficient, and scalable SRMS that meets both current institutional
needs and the future direction of digital academic management.

As part of the academic contribution and validation of our work, we have submitted our
research paper based on this project to a reputed national conference. The paper highlights the
design, architecture, and impact analysis of the SRMS. Below Figure 5.1, is the official email
confirmation of our paper submission

Figure 5.1 Email Confirmation Screenshot for conference paper submission

CHAPTER 6

REFERENCES

[1] Almahdi Alshareef and Ahmed Alkilany, “Toward a Student Information System for
Sebha University, Libya,” Fifth International Conference on Innovative Computing
Technology (INTECH 2015), pp. 34–39.

42
[2] Prabhu T. Kannan and Srividya K. Bansal, “Unimate: A Student Information System,”
2013 International Conference on Advances in Computing, Communications, and Informatics
(ICACCI), pp. 1251–1256.

[3] S. R. Bharamagoudar, Geeta R. B., and S. G. Totad, “Web Service API for Student
Information and Course Management Systems,” International Journal of Advanced Research
in Computer and Communication Engineering, June 2013.

[4] Hanan A. Al-Souly, Abeer S. Al-Sheddi, and Heba A. Kurdi, “Enhanced TSFS
Algorithm for Secure Database Encryption,” Science and Information Conference, 2013, pp.
328–335.

[5] R. Manivannan and R. Sujarani, “Light Weight and Secure Database Encryption using
TSFS Algorithm.”

[6] Lejia Kong, “Blockchain-Based Student Record Management System,” IEEE Access,
2020.

[7] Bakri Awaji and Ellis Solaiman, “A Blockchain-Based Trusted Achievement Record
System,” Future Generation Computer Systems, 2021.

[8] Emanuel Adeniyi Oloniruha and Khalimat Oyiza Momohjimoh, “AI-Based Student
Record Management for Performance Prediction,” IEEE Transactions on Learning
Technologies, 2019.

[9] G. Siemens and R. Baker, “Learning Analytics and Student Performance Prediction,”
Journal of Educational Data Science, 2018.

[10] Jin Mei-shan, Qiu Chang-li, and Li Jing, “The Design of Student Information
Management System Based on B/S Architecture,” IEEE, 2012.

[11] Bill Brandon, “Mobile-Based Student Record Systems,” Journal of Educational

Technology, 2021.

[12] Tang Yu-fang and Zhang Yong-sheng, “IoT-Based Student Record Authentication
System,” IEEE Symposium on Smart Education, 2019.

[13] Oluwatosin Samuel Falebita, “Privacy-Preserving Student Information Management,”

Journal of Information Security, 2020.

[14] David Wentworth, “Machine Learning in Academic Record Analysis,” Springer, 2019.

43
[15] R. Baker, “Data Mining Techniques for Student Performance Analysis,” ACM
Transactions on Learning Technologies, 2020.

[16] Chinmoy Kumar et al., “Role-Based Access Control System for SRMS,” IEEE, 2021.

[17] S. Ramakrishnan et al., “Decentralized Student Record Management Using Smart

Contracts,” Elsevier, 2021.

[18] Amira El-Meseery et al., “Hybrid AI-Blockchain-Cloud SRMS,” IEEE, 2022.

[19] Tushar Sharma and Priti Singh, “Big Data Techniques for Student Record Processing,”
ACM, 2020.

[20] Khalid Al-Zubaidi et al., “Mobile-Based Student Information System,” IEEE, 2019.

[21] N. K. Raghunandan et al., “Voice-Enabled Student Record System,” Elsevier, 2021.

[22] James H. Vincent et al., “Comparative Study of Student Record Management

Architectures,” Springer, 2021.

[23] Yusuf Al-Shahrani et al., “Facial Recognition for Student Identity Verification,” IEEE,
2020.

[24] Emma L. Sanders and Robert D. Hughes, “Cloud-Based University Management

System,” IEEE, 2020.

[25] Victor M. Garcia et al., “Automated Academic Progress Tracker,” Springer, 2019.

[26] A. Ghomeed and A. Abdallah, “Development of a Web-Based Student Management

System,” International Journal of Computer Applications, vol. 179, no. 7, pp. 5–10, 2018.

[27] K. Budhrani, H. Ogra, and S. Sudhakar, “Student Information Management System

Using Web Technologies,” International Journal of Engineering and Technology, vol. 7, no.
3.34, pp. 480–485, 2018.

[28] A. Adekunle, F. Akinyemi, and B. Onifade, “A Complaint Management System for

Tertiary Institutions,” International Journal of Computer Applications, vol. 131, no. 3, pp. 1–6,
2015.

[29] B. Rexha, E. Ahmedi, and N. Kurti, “Lifecycle Management of Student Information at

the University of Prishtina,” IFAC-PapersOnLine, vol. 49, no. 29, pp. 91–96, 2016.

44
[30] Y. Naveh, R. Tubin, and A. Pliskin, “Student Satisfaction With Learning Management
Systems,” Internet and Higher Education, vol. 13, no. 3, pp. 127–133, 2010.

[31] M. Thambipillai, “Student Management System for Info Tech Sys Institute,”
International Journal of Scientific and Research Publications, vol. 7, no. 5, pp. 179–182, 2017.

[32] M. Abuhassna et al., “Motivation and Self-Regulated Learning in Learning

Management Systems,” Education and Information Technologies, vol. 25, pp. 5611–5629,
2020.

[33] T. Thiruthanigesan et al., “Automated Certificate Issuing and Student Management

System,” Proceedings of the International Research Conference, University of Jaffna, Sri
Lanka, 2022.

[34] M. Othman and M. Othman, “Implementation of Web-Based Student Management

Systems in Schools,” Malaysian Journal of Educational Technology, vol. 16, no. 1, pp. 1–9,
2016.

[35] T. Gürkut, M. Dilek, and E. Kaya, “A Decision-Making Satisfaction Model for Student
Information Systems,” Educational Sciences: Theory and Practice, vol. 20, no. 3, pp. 30–40,
2020.

45