DESIGN AND IMPLEMENTATION OF

AN ONLINE STUDENT’S RECORDS MANAGEMENT SYSTEM

(A Case Study of BUK Staff Model Secondary School)

BY

SUFIYANU ALH SANI

CST/22/COM/01034

A PROJECT SUBMITTED TO THE DEPARTMENT OF

COMPUTER SCIENCE, FACULTY OF COMPUTING, BAYERO
UNIVERSITY KANO, IN PARTIAL FULFILLMENT OF THE
REQUIREMENT FOR THE AWARD OF BACHELOR OF SCIENCE
([Link].) DEGREE IN COMPUTER SCIENCE

FEBRUARY, 2026
i
 DECLARATION

I, Sufiyanu Alh. Sani, hereby declare that this project titled “Design and Implementation
of an Online Students Records Management System for Staff Secondary School, Bayero
University Kano” is an original work carried out by me under the supervision of Mal
Ahmad A Datti. This work has not been submitted, either wholly or partly, for the award
of any degree or diploma in this or any other institution.

Sufiyanu Alh. Sani – CST/22/COM/01034

_________________________________
Sign & Date

i
 CERTIFICATION

This is to certify that this project titled “Design and Implementation of an Online
Students Records Management System for Staff Secondary School, Bayero
University Kano” was carried out by Sufiyanu Alh. Sani and has been read and
approved as meeting the requirements for the award of Bachelor of Science ([Link].) in
Computer Science, Bayero University, Kano.

MAL AHMAD A DATTI ___________________________________

PROJECT SUPERVISOR SIGN & DATE

DR SAMINU MOHAMMED ALIYU ___________________________________

PROJECT COORDINATOR SIGN & DATE

DR HADIZA ALI UMAR ___________________________________

HEAD OF DEPARTMENT SIGN & DATE

EXTERNAL EXAMINER ___________________________________

SIGN & DATE

ii
 DEDICATION

This project is dedicated to Allah (SWT) for the continuous support and protection
throughout the course of my studies, my beloved parents Alh. Sani Mainono and Fatima
M. Ladan Maru, for their prayers, sacrifices, guidance, and unwavering support
throughout my academic journey.

iii
 ACKNOWLEDGEMENT

All praise and gratitude are due to Almighty Allah for granting me the strength, wisdom,
and perseverance to successfully complete this project.

I wish to express my sincere appreciation to my project supervisor Mal Ahmad A Datti

for his valuable guidance, constructive criticism, and continuous support throughout the
course of this research. My profound gratitude also goes to the lecturers of the
Department of Computer Science, Faculty of Computing, Bayero University Kano, for
the knowledge and skills imparted to me during my studies.

I am deeply grateful to my parents, Late Alh. Sani Mainono and Fatima M. Ladan
Maru, whose prayers, encouragement, and sacrifices laid the foundation for my
academic success, special thanks to my sister, Zaliha Sani, and the entire family of Ari
and Masallaci for their moral support and understanding.

My appreciations also go to my friend and mentor Mal Abdulhadi Ya’u, for his
encouragement, ideas, and support during the course of my studies. I equally extend my
heartfelt thanks to all my mentors like Mal Yusuf Alkali Anka, Late Mal Bashar Sani
Marafa, Hon Muhammad Yahaya Tambura, Comrade Mu’awuya Garba Ja’o and
well-wishers who contributed in one way or another to the successful completion of this
work and my studies at large.

iv
Table of Contents
DECLARATION..................................................................................................................i
CERTIFICATION...............................................................................................................ii
DEDICATION...................................................................................................................iii
ACKNOWLEDGEMENT..................................................................................................iv
LIST OF TABLES...........................................................................................................viii
LIST OF FIGURES............................................................................................................ix
ABSTRACT........................................................................................................................x
CHAPTER ONE..................................................................................................................1
INTRODUCTION...............................................................................................................1
1.1 Background of the Study...........................................................................................1
1.2 Problem Statement.....................................................................................................3
1.3 Research Questions....................................................................................................4
1.4 Aim and Objectives of the Study...............................................................................4
1.5 Significance of the Study...........................................................................................5
1.6 Scope of the Study.....................................................................................................6
1.7 Limitations of the Study............................................................................................7
1.8 Operational Definition of Terms...............................................................................7
1.9 Summary....................................................................................................................8
CHAPTER TWO.................................................................................................................9
LITERETURE REVIEW.....................................................................................................9
2.1 Introduction................................................................................................................9
2.2 Conceptual Overview (Student Record / Information Management Systems).........9
2.3 Related Works.........................................................................................................10
2.4 Summary..................................................................................................................16
CHAPTER THREE...........................................................................................................17
METHODOLOGY............................................................................................................17
3.1 Introduction..............................................................................................................17
3.2 Description and Analysis of Existing System.........................................................17
3.2.1 Description of Existing System........................................................................17
3.2.2 Challenges of the Existing System:..................................................................18

v
 3.3 Requirement Elicitation...........................................................................................19
3.3.1 Interviews and informal discussions................................................................19
3.3.2 Observation.......................................................................................................19
3.3.3 Key Findings:...................................................................................................19
3.4 Requirements Definition..........................................................................................20
3.4.1 User / Functional Requirements.......................................................................20
3.4.2 Non-Functional Requirements..........................................................................22
3.4.3 Requirement Analysis.......................................................................................23
3.5 Description of the Proposed System........................................................................30
3.5.1 System Design..................................................................................................31
3.5.2 Main Features Overview (Activity Diagram)...................................................31
3.5.3 Architecture Design..........................................................................................32
3.5.4 Architecture Design..........................................................................................33
3.6 System Development Model....................................................................................33
3.6.1 Reason for Selecting Waterfall Model:............................................................34
3.7 Summary..................................................................................................................34
CHAPTER FOUR.............................................................................................................35
SYSTEM IMPLEMENTATION AND TESTING...........................................................35
4.1 Introduction..............................................................................................................35
4.2 Development Environment......................................................................................35
4.2.1 Hardware Requirements...................................................................................35
4.2.2 Software Requirements.....................................................................................36
4.3 Development Tools:.................................................................................................36
4.3.1 Text editor / IDE...............................................................................................36
4.3.2 Web browser.....................................................................................................36
4.3.3 Languages and Technologies:...........................................................................36
4.4 System Implementation...........................................................................................37
4.4.1 Database Implementation.................................................................................37
4.4.2 Backend Implementation (PHP and MySQL)..................................................38
4.4.3 Frontend Implementation (User Interfaces).....................................................39
4.5 System Features.......................................................................................................41

vi
 4.5.1 User Authentication and Role-Based Access Control......................................41
4.5.2 Student Records Management..........................................................................42
4.5.3 Teacher and Class Management (Admin)........................................................44
4.5.4 Results Management.........................................................................................46
4.5.5 Subject Score Sheet and Broadsheet Generation..............................................48
4.5.6 ID Card Generation...........................................................................................49
4.5.7 System Configuration.......................................................................................50
4.5.8 Dashboard Analytics.........................................................................................51
4.6 System Testing.........................................................................................................52
4.6.1 Testing Strategy................................................................................................52
4.6.2 Test Cases.........................................................................................................52
4.6.3 Test Results and Discussion.............................................................................55
4.7 Challenges Encountered..........................................................................................55
4.7.1 Data Design and Migration:..............................................................................55
4.7.2 Role-Based Access Implementation:................................................................56
4.8 Summary..................................................................................................................56
CHAPTER FIVE...............................................................................................................57
SUMMARY, CONCLUSION AND RECOMMENDATION..........................................57
5.1 Summary..................................................................................................................57
5.2 Conclusion...............................................................................................................58
5.3 Limitation................................................................................................................58
5.4 Recommendation.....................................................................................................59
5.4.1 For the School Administration..........................................................................59
5.4.2 For Further Research........................................................................................59
REFERENCES..................................................................................................................61
ELICITATION EVIDENCE.............................................................................................65
CODES OF MAJOR FUNCTIONALITY........................................................................68
1. Dashboard........................................................................................................68
2. Add Teacher....................................................................................................68
3. Insert Scores....................................................................................................69
4. View Score......................................................................................................70

vii
 LIST OF TABLES

Table 2. 1 Recent software systems for student records....................................................16

Table 3. 1 Login Use Case Description………………………………………………….25

Table 3. 2 Add Student Use Case Description Table........................................................26

Table 3. 3 Input Scores Use Case Description Table........................................................28
Table 3. 4 Generate Report Sheet Use Case Description Table........................................29

viii
 LIST OF FIGURES

Figure 3. 1 Use Case Diagram...........................................................................................24

Figure 3. 2 Activity Diagram.............................................................................................31
Figure 3. 3 Class Diagram.................................................................................................32
Figure 3. 4 Entity Relationship Diagram..........................................................................33

Figure 4. 1 A Landing Page of the Proposed System.......................................................41

Figure 4.2 A unique Login Page for admin and the teachers...........................................42
Figure 4. 3 Add Student....................................................................................................43
Figure 4. 4 Search Students..............................................................................................43
Figure 4. 5 Update Students records/Delete.....................................................................44
Figure 4. 6 Manage Teachers............................................................................................45
Figure 4. 7 Manage Classes and Subjects.........................................................................45
Figure 4. 8 Students Score Sheet......................................................................................46
Figure 4. 9 Automated Report Card from the system.......................................................47
Figure 4. 10 Subject based grade sheet from the system..................................................48
Figure 4. 11 Class Broadshee...........................................................................................48
Figure 4. 12 Staff ID Card form........................................................................................49
Figure 4. 13 Sample Staff ID card ID print generated from the system............................49
Figure 4. 14 A General System settings page showing the active term and session........50
Figure 4. 15 A system dashboard for an admin................................................................51
Figure 4. 16 A class form master dashboard.....................................................................51

ix
 ABSTRACT

Student records management is a critical component of academic administration in

secondary schools. This project aims to design and implement an online student’s
records management system for Staff Secondary School, Bayero University Kano, in
order to improve the efficiency, accuracy, and security of student data handling. The
methodology adopted involves requirements elicitation, system analysis and design,
implementation using HTML, CSS, PHP, and MySQL, and testing on a local XAMPP
serve. Chapter One presents the background and objectives of the study, while Chapter
Two reviews related works in student records management systems. Chapter Three
describes the system methodology and design, and Chapter Four covers system
implementation and testing. Chapter Five concludes the study with a summary,
limitations, and recommendations. The developed system provides a centralized platform
for managing student records, reduces manual errors, enhances data security, and
supports timely access to student information particularly the examination records
overtime.

x
 CHAPTER ONE

INTRODUCTION

1.1 Background of the Study

Secondary schools are information-intensive organizations. Every academic session, they

generate large volumes of data on student bio data, admissions, subject registration,
continuous assessment, examination results, discipline, attendance, and co-curricular
participation. In many Nigerian secondary schools, these records are still kept in paper
registers, cabinets and loosely structured spreadsheets, often without a centralized
standard or clear policy framework (Odeniyi & Adeyanju, 2020).

Research in Nigeria and other African countries shows that such manual and fragmented
records practices lead to duplication of work, delays, and inconsistencies, making it
difficult to track a learner’s academic history in a reliable way (Odeniyi & Adeyanju,
2020; Atuh et al., 2023). For instance, admission registers, attendance registers and result
sheets may be kept in separate offices and are vulnerable to physical deterioration, loss,
misfiling, and unauthorized alterations, which undermines accountability and
transparency in school management (Duruin & Siddayao, 2024).

At the same time, there is increasing pressure on schools to provide up-to-date

information to ministries of education, examination bodies, parents and other
stakeholders, in line with broader trends in Education Management Information Systems
(EMIS) and digital transformation in education (Yusuf et al., 2022; Yuliandari et al.,
2023). EMIS and school management information systems aim to integrate student data
in a centralized, digital platform so that enrolment, assessment, and progression can be
monitored consistently and reported quickly (Kaviya et al., 2025; Ronquillo Jr. et al.,
2022). Evidence from Kenya and Zambia indicates that when EMIS or web-based result
systems are adopted, schools improve the tracking of student records, speed of result
dissemination, and communication with parents through SMS and online portals (Venice
& Mwale, 2025).

1
Digital student record systems and web-based platforms developed in secondary schools
and universities have been shown to enhance efficiency by automating enrolment,
grading, attendance tracking, and report generation, while reducing human error and
administrative workload (Silwamba & Matela, 2025; Walia, 2014; Patil et al., 2023). A
school records and forms online management system in the Philippines, for example, was
rated “very acceptable” on software quality criteria and significantly improved the
generation of school forms and student records (Ronquillo Jr. et al., 2022). Similar
systems using RFID or web technologies have streamlined attendance and enabled
real-time data retrieval and export to analytical formats such as Excel (Mustafa &
Mustafa, 2025).

In the Nigerian context, scholars have emphasized that secondary schools need to
reposition record-keeping practices by embracing modern, ICT-based strategies to
improve administrative effectiveness and student achievement (Agwu, 2018; Yusuf et al.,
2022). However, challenges such as inadequate ICT infrastructure, limited digital skills
among staff, and resistance to change often slow down this transformation (Yusuf et al.,
2022; Akuna & Y. P., 2025).

Staff Secondary School, Bayero University, Kano, shares many of these contextual
realities. As enrolment grows and curriculum demands become more complex, continued
reliance on manual registers and basic office tools becomes less sustainable. Tasks such
as compiling term results, updating student biodata, preparing class lists, and generating
reports for university authorities or government agencies can become time-consuming
and error-prone. In line with global and regional trends toward digital school
administration, there is a need for a tailored online students’ records management system
that will centralize student information, support secure, role-based access, and enable
timely decision-making. Such a system aligns with evidence that well-designed student
records systems can streamline operations, enhance data quality, and contribute to better
student outcomes (Silwamba & Matela, 2025; Kaviya et al., 2025; Ronquillo Jr. et al.,
2022).

2
1.2 Problem Statement

Despite the recognized importance of accurate and accessible student records, many
secondary schools in Nigeria still manage admissions, attendance, assessments and
results primarily through paper-based systems (Odeniyi & Adeyanju, 2020; Agwu, 2018).
Studies show that these manual approaches often result in incomplete records, delays in
updating information, and difficulties in retrieving historical data for individual students
or classes (Odeniyi & Adeyanju, 2020; Duruin & Siddayao, 2024). In some cases, the
lack of secure storage and backup exposes records to risks such as fire, theft, or
accidental loss, threatening the integrity of students’ academic histories.

Research in Cameroon and Kenya further reveals that when student admission files,
registers and result books are poorly managed, school leadership struggles to make
informed decisions about promotion, resource allocation, disciplinary interventions and
support for learners with special needs (Atuh et al., 2023; Journal of Education and
Practice, 2022). Inaccurate or missing records can also weaken public trust and
complicate interactions with external regulators and examination bodies.

At Staff Secondary School, Bayero University, Kano, the situation reflects many of these
broader challenges. Student information is dispersed across multiple registers and files
maintained by different offices and departments. Generating consolidated reports—such
as complete term results for a class, longitudinal performance trends, or
gender-disaggregated data—requires substantial manual collation and cross-checking,
which increases the risk of arithmetic and transcription errors. As the school population
increases, teachers and administrative staff must spend more time on repetitive clerical
tasks, leaving less time for core academic and guidance responsibilities—a problem also
reported in other schools where manual systems dominate (Silwamba & Matela, 2025;
Ronquillo Jr. et al., 2022).

While various models of EMIS and web-based student information systems exist, they
are often designed for national or higher-education contexts and may not directly fit the
operational realities of a secondary school attached to a university campus (Akuna & Y.

3
P., 2025; Kaviya et al., 2025). There is therefore a gap between the school’s current
records practices and the potential benefits of a context-specific online students’ records
management system that reflects local workflows, existing infrastructure and user
capacities.

The central problem this study addresses is the absence of an integrated, web-based
system for managing student records at Staff Secondary School, Bayero University,
Kano, which leads to inefficiencies, data inconsistencies, and limited support for timely,
evidence-based decision-making.

1.3 Research Questions

To guide the study, the following research questions are posed:

1. What are the current practices and challenges in managing student records at Staff
Secondary School, Bayero University, Kano?
2. What functional and non-functional requirements should an online students’
records management system meet to address these challenges effectively?
3. How can a web-based system be designed and implemented to support secure,
accurate and efficient management of student records in the school?
4. In what ways does the proposed system improve the speed, accuracy and
accessibility of student records compared with the existing manual methods?

1.4 Aim and Objectives of the Study

The aim of this project is to design and implement an online students’ records
management system for Staff Secondary School, Bayero University, Kano, to provide a
secure, centralized and efficient platform for managing student information and academic
records.

4
The specific objectives are to:

1. Analyze the existing records management practices at Staff Secondary School,

Bayero University, Kano, in order to identify the in-efficiencies/gaps to be
addressed by the proposed system.
2. To identify functional and non-functional requirements the proposed system
should meet in order to address these challenges effectively.
3. Design and implement role-based access control and authentication mechanisms
so that administrators and teachers access only the data and functions appropriate
to their roles, in line with confidentiality, integrity and availability principles.
4. Develop functionalities for automated result computation and the generation of
key reports such as class lists, individual result slips, transcripts, and performance
summaries by class, subject and term.

1.5 Significance of the Study

Effective management of student records has been linked to improved school

administration, planning and accountability in secondary education (Atuh et al., 2023;
Odeniyi & Adeyanju, 2020). By developing and deploying an online students’ records
management system for Staff Secondary School, Bayero University, Kano, this study
offers several practical and scholarly contributions.

For school administrators, the system will provide timely and accurate reports needed for
decision-making, such as enrolment statistics, performance trends, and attendance
summaries. Evidence from Kenya and the Philippines suggests that digital records
systems make it easier to classify students, track progress, and generate standardized
forms and reports for policy compliance.

For teachers, the system reduces the burden of manual computation and transfer of
scores, enabling them to record assessments once and automatically generate term results
and progress reports. Similar systems have been reported to streamline administrative
work and allow staff to focus more on teaching and student support (Silwamba & Matela,
2025; Duruin & Siddayao, 2024).

5
For students and parents, online access to results and academic profiles can improve
transparency, motivation and engagement. Studies show that when learners and parents
receive timely and clear academic information—often through web portals or SMS—
communication and accountability in the school community are strengthened (Venice &
Mwale, 2025).

At the institutional and policy level, the project contributes to ongoing efforts to integrate
ICT and management information systems into Nigerian secondary schools (Yusuf et al.,
2022; Agwu, 2018). It provides a case-based model, grounded in a real secondary school
attached to a university that can inform similar initiatives in other schools within Bayero
University and beyond.

From a research perspective, the study enriches the growing body of work on digital
academic records management in African educational institutions by focusing on a
secondary school context and by linking practical system development with issues of data
quality, security and user acceptance (Akuna & Y. P., 2025; Silwamba & Matela, 2025).

1.6 Scope of the Study

The study is delimited to Staff Secondary School, Bayero University, Kano, and focuses
on the design and implementation of an online students’ records management system as a
prototype for the school. The system will:

I. Manage student bio data and academic details.

II. Record and update subject registration, continuous assessment and examination
scores for each term.
III. Provide role-based access for administrators and teachers.
IV. Generate core reports such as class lists, term result slips, summary sheets and
simple performance analytics.

The platform is web-based and designed to run on standard web browsers using the
school’s existing computer and network infrastructure, similar to other PHP/MySQL or
Django-based systems reported in the literature.

6
The study does not cover integration with external national examination bodies,
comprehensive financial/fee management modules, advanced data analytics or mobile
app development. Security measures focus on authentication, authorization, and routine
data backup appropriate to a school-level system, rather than enterprise-grade security or
blockchain-based credentialing discussed for higher education.

1.7 Limitations of the Study

The project may be constrained by the availability and reliability of ICT infrastructure
within the school, such as stable internet connectivity, power supply, and adequate client
devices—challenges commonly reported in African schools implementing EMIS or
digital systems (Ronquillo, 2022). The level of digital literacy among some staff may also
influence the pace of adoption and effective use of the system.

Furthermore, the evaluation of the system’s impact will be based on user perceptions and
basic performance indicators (such as time taken to generate reports), rather than
long-term outcomes like sustained improvements in academic performance. Finally, the
case study nature of the research limits the generalizability of findings, though the design
principles and lessons learned may still be useful for similar schools.

1.8 Operational Definition of Terms

 Student Records Management System (SRMS): A software application designed

to capture, store, process and retrieve student information such as biodata,
admissions, grades and attendance in digital form (Matela, 2025).
 Education Management Information System (EMIS): An integrated system for
collecting, processing, storing and disseminating education data for planning,
management and decision-making at institutional or system level (Yusuf, 2022).
 Online / Web-based System: A software system accessed via a web browser over
a network, where application logic and data are hosted on a server (Venice &
Mwale, 2025; Patil et al., 2023).

7
  Role-based Access Control (RBAC): A security mechanism that restricts system
access based on the roles of individual users, such as administrator, teacher or
student (Venice & Mwale, 2025).

1.9 Summary

This chapter has presented an expanded overview of the context, problem, aim,
objectives, research questions, significance, scope, limitations and key concepts of the
study. It established that traditional record-keeping in secondary schools, including Staff
Secondary School, Bayero University, Kano, is increasingly inadequate for contemporary
demands of accuracy, efficiency and accountability, and that digital, web-based solutions
offer a promising response. Subsequent chapters will build on this foundation to review
relevant literature, describe the system design and implementation, and present findings
from the system evaluation.

8
 CHAPTER TWO

LITERETURE REVIEW

2.1 Introduction

This chapter reviews existing literature and software projects related to student records /
student information management systems and closely related school information systems.
It focuses on works published from 2014 to date that implemented software solutions
(mostly web-based) for managing student data such as bio data, enrolment, grades,
attendance and guidance records.

The chapter is organized into two main parts. The first part presents an overview of the
main concepts underpinning student records management systems and their
implementation as software. The second part reviews selected related works, with
emphasis on: research focus, programming languages and technologies used, software
type (web, desktop, cloud, IoT), and key functionalities. The chapter concludes with a
summary highlighting the gaps that motivate the development of an online students’
records management system for Staff Secondary School, Bayero University Kano.

2.2 Conceptual Overview (Student Record / Information Management Systems)

Student Record Management Systems (SRMS) or Student Information Systems

(SIS/SMIS) are specialized information systems that capture, store and process
student-related data, typically including registration, enrolment, grades, attendance and
personal details (Patil et al., 2023; Silwamba & Matela, 2025; Agarwal et al., 2021; Zhou
& Hou, 2023). Modern systems are commonly web-based and follow multi-tier
architectures using technologies such as PHP, Python/Django, Java/Spring, JavaScript
and MySQL to support secure, centralized access over a network (Patil et al., 2023; Barot
& Jain, 2025; Marcel, 2019; Rodríguez-Campos et al., 2024; Zhou & Hou, 2023).

Key design concerns reported in the literature include data accuracy, usability, security
(often via role-based access control and authentication), and scalability to handle large

9
student populations (Patil et al., 2023; Silwamba & Matela, 2025; Barot & Jain, 2025;
Marcel, 2019; Duruin & Siddayao, 2024; Zhou & Hou, 2023). Many recent systems also
incorporate quality frameworks such as ISO/IEC 25010 for software evaluation, or adopt
specific development methodologies such as Waterfall, SDLC, Agile or Sashimi models
(Patil et al., 2023; Paculanan et al., 2025; Sistem et al., 2025; Barot & Jain, 2025; Duruin
& Siddayao, 2024; , 2025).

The conceptual trends from these works guide the design of the proposed system in this
project, particularly the focus on web-based architecture, centralized database design, and
role-based access for administrators, teachers and students.

2.3 Related Works

The table below summarizes at least ten software-development-focused studies on

student records, student information and closely related academic record systems (2014–
2025). Papers are ordered by year (ascending).

Several works focus specifically on web-based SRMS/SIS for educational institutions.

Patil et al. developed a Django-based SRMS with integrated department website,
supporting registration, enrolment, grading, CGPA tracking, fees, and communication
between students and staff (Patil et al., 2023). Gatete designed an online SMIS
(UGSMIS) using PHP and MySQL to automate registrar processes including student
registration, grades, transcripts, and academic notifications (Marcel, 2019). Agarwal et al.
implemented a Java-based SIS with HTML/CSS/JS front-end and MySQL backend to
securely store and retrieve academic reports, curriculum and institutional data (Agarwal
et al., 2021). DK and Aanaikutti proposed a PHP/MySQL student record system
emphasizing automated data entry, storage, retrieval, data security, and attendance reports
(K & M, 2024).

At secondary-school level, Duruin and Siddayao designed a School Records Management

System for Magalalag National High School using SDLC with Sashimi model; the
system achieved very high compliance with ISO 25010 quality standards and effectively
addressed paper-based storage problems (Duruin & Siddayao, 2024). Venice and Mwale

10
(Chapter 1 reference) similarly built a web-based result management system for a
Zambian secondary school using PHP/MySQL, with role-based access and automated
report generation, demonstrating improved accuracy and speed of result processing.

Some projects extend beyond core records to specialized educational processes.

Rodríguez-Campos et al. built a PHP/MySQL platform to automate degree processes at
ITESI, with CRUD operations for students, projects and teachers, PDF report generation
and Excel export, improving monitoring of graduation activities (Rodríguez-Campos et
al., 2024). Ifeanyi Alex implemented a PHP/MySQL complaint management system with
features for complaint submission, tracking, login logging and category management,
aimed at reducing delays and inefficiencies in handling student complaints (Alex, 2023).

Other works concentrate on guidance and counseling records. Alegado et al. developed a
VB-based guidance and counseling record management system using SDLC, rated highly
on functionality, usability and security (Alegado et al., 2021). Mahendra et al. later built a
VB 6.0 + MySQL Guidance and Counseling Information System with Waterfall and
R&D methodology, supporting student data, counseling cases and reporting, with good
correctness and usability (Sistem et al., 2025). Paculanan et al. advanced this line with a
web-based Guidance Record Management System in Laravel, integrating Python-based
EDA and a Decision Tree algorithm to visualize behavior and predict academic
performance, evaluated against ISO 25010 (Paculanan et al., 2025).

Emerging trends include IoT and cloud-based SRMS. Mustafa and Mustafa implemented
an RFID-driven attendance SRMS using PHP/JS/MySQL, recording real-time arrivals
and departures and generating attendance reports (Mustafa & Mustafa, 2025). Zhou and
Hou described an intelligent campus student information system on a cloud platform to
manage enrolment, attendance and academic records, highlighting high data security,
online backups and improved accessibility (Zhou & Hou, 2023). Barot and Jain’s SMIS
used Java/Spring Boot, RBAC, and encryption, showing substantial improvements in
data accuracy and workload reduction, and proposing future AI and blockchain
enhancements (Barot & Jain, 2025). Silwamba and Matela emphasized comprehensive

11
automation of student records with attention to data accuracy, ease of use and security in
their SRS design (Silwamba & Matela, 2025).

Across these works, recurring functionalities include: student biodata management;

enrolment/subject registration; grades and CGPA computation; attendance tracking;
report generation (class lists, transcripts, statistics); secure authentication and role-based
access; and, in newer systems, analytics and integration with other services (Patil et al.,
2023; Silwamba & Matela, 2025; Paculanan et al., 2025; Mustafa & Mustafa, 2025;
Barot & Jain, 2025; Marcel, 2019; Agarwal et al., 2021; Duruin & Siddayao, 2024; K &
M, 2024; Zhou & Hou, 2023). Methodologically, most projects adopt structured software
development processes (Waterfall, SDLC, R&D, Agile variants) and evaluate software
quality using functional and non-functional criteria, sometimes guided by ISO 25010
(Patil et al., 2023; Alegado et al., 2021; Paculanan et al., 2025; Sistem et al., 2025; Barot
& Jain, 2025; Duruin & Siddayao, 2024; , 2025).

The proposed system for Staff Secondary School, Bayero University, Kano aligns closely
with these trends by implementing a web-based platform with centralized database,
role-based access, automated result/report generation and a focus on usability and basic
security. Unlike many university-level systems, however, it is tailored specifically to a
Nigerian secondary school context and to routine operations such as termly results and
class-level reporting.

12
Software-Based Student Record / Information Systems (2019–2025)

Research Focus,
Title / Software
Author(s), Year Tech Stack, Key Functionalities Citations
Type
Method

Developed UGSMIS
Online Integrated
to automate registrar Student registration, editing
Student
operations in a personal data, grades,
Management (Marcel,
Gatete (2019) university; PHP, transcripts, course/batch
Information System 2019)
HTML, jQuery, JS, details, academic
(web) (Marcel,
CSS, MySQL; online notifications
2019)
integrated SMIS

Web-based SIS to
store and maintain
Registration forms, secure
Student Information student and academic
login, storage and retrieval
System (web) records; (Agarwal et
Agarwal et al. (2021) of academic reports,
(Agarwal et al., HTML/CSS/JS al., 2021)
curriculum and institutional
2021) frontend, Advanced
details
Java (Servlets)
backend, MySQL DB

Guidance and
Add/update student profiles,
Counseling Record VB 2017 and MS SQL
print records, manage
Management Server system for (Alegado et
Alegado et al. (2021) counseling data; strong
System (desktop) guidance center; al., 2021)
ratings on functionality,
(Alegado et al., SDLC methodology
usability, security
2021)

Online Integrated
Student
Student, course, grades,
Marcel (2019, pub. Management Automation of manual
curriculum, instructor, batch (Marcel,
2019; within 10-year Information student management;
details; transcripts, semester 2019)
window) System, University PHP/MySQL based
reports, notifications
of Gitwe (web)
(Marcel, 2019)

13
 Research Focus,
Title / Software
Author(s), Year Tech Stack, Key Functionalities Citations
Type
Method

Web-based SRMS for

Student Record Registration, enrolment,
department;
Management grading, CGPA, fees, contact
Python/Django, (Patil et al.,
Patil et al. (2023) System using info, photos, remarks;
HTML/CSS/JS; 2023)
Django (web) (Patil integrated portal for students
relational DB; SRMS
et al., 2023) and staff
+ department website

Web-Based Student Automates student

Complaint submission,
Complaint complaints in tertiary
tracking, admin dashboards,
Ifeanyi Alex (2023) Management institution; PHP, JS, (Alex, 2023)
user login logs, category
System (web) HTML, CSS, MySQL;
management
(Alex, 2023) Waterfall method

Intelligent Campus
Manage enrolment,
Student Information Cloud-based student
attendance, academic
Management info management; web (Zhou &
Zhou & Hou (2023) records; online backup and
System (cloud/web) app using online Hou, 2023)
high security;
(Zhou & Hou, server and DB
anywhere/anytime access
2023)

Student Records
Management Centralized storage and
Designed SRMS using
System for retrieval of student records; (Duruin &
Duruin & Siddayao SDLC + Sashimi;
Magalalag National addresses paper storage Siddayao,
(2024) evaluated with ISO
High School (web) issues; high compliance with 2024)
25010
(Duruin & quality standards
Siddayao, 2024)

14
 Research Focus,
Title / Software
Author(s), Year Tech Stack, Key Functionalities Citations
Type
Method

Web Platform for Web platform for

Degree Process controlling graduation CRUD for students, teachers,
(Rodríguez-
Rodríguez-Campos et Administration processes; PHP, projects; PDF report
Campos et
al. (2024) (web) (Rodríguez- MySQL, JS; layered generation; export to Excel;
al., 2024)
Campos et al., frontend–backend advanced search filters
2024) approach

Student Record Web-based SRS for Student profiles, data

DK & Aanaikutti System using PHP efficient student data security features, attendance (K & M,
(2024) (web) (K & M, management; PHP, reports, automated data 2024)
2024) MySQL, HTML/CSS entry, storage and retrieval

Student Records
Management RFID-based SRMS for Real-time attendance
(Mustafa &
Mustafa & Mustafa System using IoT attendance; PHP, logging (arrival/departure),
Mustafa,
(2025) (web + RFID) HTML, CSS, JS, report generation, semester
2025)
(Mustafa & MySQL participation tracking
Mustafa, 2025)

Design and
Comprehensive SRS
Development of a Centralized records, reduced
to automate enrolment, (Silwamba
Silwamba & Matela Student Record redundancy, improved
grades, attendance; & Matela,
(2025) System (software) communication; emphasis on
system development 2025)
(Silwamba & accuracy, usability, security
approach
Matela, 2025)

Laravel (PHP), JS,

Guidance Record Student record submission,
TailwindCSS,
Management guidance records, EDA
Paculanan et al. MySQL; integrates (Paculanan
System with EDA dashboard, predictive
(2025) Python (Pandas, et al., 2025)
(web) (Paculanan et insights on academic
Matplotlib, Seaborn)
al., 2025) performance
& Decision Tree

Mahendra et al. Guidance & Desktop GCIS using Student data management, (Sistem et

15
 Research Focus,
Title / Software
Author(s), Year Tech Stack, Key Functionalities Citations
Type
Method

Counseling
VB 6.0 + MySQL; counseling case records, BK
Information System
(2025) Waterfall + R&D activity reporting; high al., 2025)
(desktop) (Sistem et
method usability, maintainability
al., 2025)

Enrolment, grades,
Student
attendance, faculty
Management Java/Spring Boot
communication; RBAC,
Information System backend, web (Barot &
Barot & Jain (2025) encryption,
(SMIS) (web) frontend, MySQL; Jain, 2025)
GDPR/FERPA-aligned
(Barot & Jain, Waterfall model
security; reports and
2025)
analytics

Table 2. 1 Recent software systems for student records and information management

2.4 Summary

This chapter outlined the conceptual basis of student record and information management
systems and reviewed recent (2014–2025) software projects implementing such systems
in schools and higher institutions. The related works demonstrate a strong shift toward
web-based, database-driven architectures using technologies like PHP/MySQL,
Python/Django, Java/Spring and VB/.NET, alongside structured development
methodologies and growing attention to software quality and security (Patil et al., 2023;
Silwamba & Matela, 2025; Alegado et al., 2021; Paculanan et al., 2025; Mustafa &
Mustafa, 2025; Barot & Jain, 2025; Marcel, 2019; Agarwal et al., 2021; Duruin &
Siddayao, 2024; Zhou & Hou, 2023).

Key functionalities across the literature—centralized storage of student bio data,

automated grading and reporting, secure role-based access, and, in some cases, analytics
and IoT-based attendance—provide a clear benchmark for the design of the proposed
system. However, there remains a need for solutions specifically adapted to
16
secondary-school environments like Staff Secondary School, Bayero University, Kano.
The next chapter will build on these insights to present the detailed methodology for
designing and implementing the online students’ records management system.

CHAPTER THREE

METHODOLOGY

3.1 Introduction

This chapter describes the methods and processes used in the design and implementation
of the “Online Students Records Management System” for Staff Secondary School,
Bayero University Kano. It explains the project workflow, the chosen system
development model, analysis of the existing manual/partial system, the requirements
gathered, and the design of the proposed web-based system built with HTML, CSS, PHP,
and MySQL and tested on a local XAMPP server.

3.2 Description and Analysis of Existing System

3.2.1 Description of Existing System

Staff Secondary School, Bayero University Kano currently uses a partially manual
system for managing student academic records and generating report sheets.

[Link] Administrative/Exam Office Staff

a. Keep student bio data records (paper forms and sometimes electronically on an
offline installed software).
b. Maintain class lists, sessions and terms.
c. At examination time, they generate and print blank grade sheets for each subject
and class.
d. After teachers fill scores manually on the paper, staff (or a data entry clerk) enters
these scores into a computer to generate class summary and individual report
sheets.

17
 e. They handle promotion lists and overall performance statistics manually or with
basic spreadsheets.

[Link] Form Masters

a. Responsible for a class (e.g., JSS 3).
b. Collect scores from subject teachers on the printed grade sheets.
c. Verify and submit compiled class results to the exam office.
d. Sometimes participate in entering or checking data in the computer system at the
exam office.
e. Have limited flexibility to update records once scores are submitted.

[Link] Subject Teachers

a. Manually record students’ Continuous Assessment (CA) and examination scores
in their personal record books.
b. During exam periods, they collect empty score sheets printed from the system, fill
in scores by hand, and return them to the exam office or form master.
c. They do not directly input scores into the existing computer system and cannot
see automatic summaries or error checks at the time of entry.

[Link] Students
a. Receive printed report sheets at the end of the term.
b. Have no online access to their academic records.
c. If an error occurs in scores, correction requires going back through the paper
sheets and manual editing in the system/spreadsheet.

3.2.2 Challenges of the Existing System:

a. High dependence on paper: Many operations still rely on physical forms and
grade sheets.
b. Error-prone data transfer: Manual transfer from paper to system leads to mistakes.
c. Time-consuming: Generating report cards and broadsheets for all classes take a
lot of time.

18
 d. Limited access and flexibility: Only exam-office computers can be used, subject
teachers cannot directly input into the system.
e. Data inconsistency: Corrections may not be updated everywhere (paper, Excel,
partial system).

These challenges motivated the development of a more integrated online student records
management system.

3.3 Requirement Elicitation

Requirement elicitation was carried out mainly through:

3.3.1 Interviews and informal discussions

An interview with the school administrator/exam officer, selected form masters, selected
subject teachers

3.3.2 Observation

a. Observing the current result processing workflow: Generation of empty sheets at

the exam office, annual recording of scores by teachers
b. Data entry into the computer for summary and report sheets

3.3.3 Key Findings:

a. Administrators need a centralized web-based system to manage students, teachers,

classes, subjects, sessions and terms, and to generate various reports (report cards,
class lists, summaries, and student IDs).
b. Form masters need the ability to manage students in their class, input or verify
scores, print report sheets, and see class performance summaries.
c. Subject teachers want to enter subject scores in a controlled manner (without the
ability to alter other sensitive data), view score sheets, and ensure that once scores
are submitted, they cannot be changed accidentally.

19
 d. There is a strong need for role-based access control so that each user only sees
and performs operations that match his/her role.
e. The school is comfortable with a web-based system accessible from desktop
computers in the exam office and staff room, not necessarily over the public
internet (can run on local network).
f. The system must support academic sessions (e.g., 2025/2026), terms (First Term,
Second Term, Third Term), and handle promotion of students from one class to
another.

3.4 Requirements Definition

Requirements are divided into user (functional) requirements and non-functional

requirements.

3.4.1 User / Functional Requirements

[Link] Administrator (Admin) Requirements:

i. The administrator shall be able to log into the system using a secure username and
password.
ii. The administrator shall be able to add, update, and delete teachers.
iii. The administrator shall be able to add, update, and delete students.
iv. The administrator shall be able to manage classes, subjects, sessions, and terms.
v. The administrator shall be able to assign form masters and subject teachers to
specific classes and subjects (via teacher_assignments).
vi. The administrator shall be able to configure the active academic session and
term using the system settings page.
vii. The administrator shall be able to generate and print: Student report cards, class
lists and student lists, overall performance summaries and broadsheets staff and
student ID cards
viii. The administrator shall be able to view class statistics (e.g., overall best
student, best class, etc.).
ix. The administrator shall be able to manage system settings and profile information.

20
[Link] Form Master Requirements:
i. The form master shall be able to log in with a unique username and password.
ii. The form master shall be able to add students to his/her class and manage their
records (update basic information).
iii. The form master shall be able to view all students in the assigned class.
iv. The form master shall be able to input or verify CA and exam scores for students
via an exams module.
v. The form master shall be able to generate and print: Individual report sheets. class
performance summaries, subject-based summaries and broadsheets for his/her
class
vi. The form master shall be able to view the overall best student in the class and
other statistics from the dashboard.

[Link] Subject Teacher Requirements:

i. The subject teacher shall be able to log into the system.
ii. The subject teacher shall be able to view classes and students for his/her assigned
subjects.
iii. The subject teacher shall be able to input scores (CA and exam) for assigned
subjects through the Exams interface.
iv. Once submitted, the subject teacher shall not be able to edit scores.
v. The subject teacher shall be able to view subject score sheets and class statistics
for their subjects but cannot access administrative settings.

[Link] General System Requirements:

i. The system shall store all data in a MySQL database.
ii. The system shall provide search functionality to search for students by name or
ID.
iii. The system shall support multiple user roles (admin, form master, subject teacher)
with different dashboards.
iv. The system shall allow logout from any role.
v. The system shall be accessible via a standard web browser over a local network or
localhost (XAMPP).

21
3.4.2 Non-Functional Requirements

[Link] Security
i. The system must provide role-based access control.
ii. Passwords should be stored securely (e.g., hashed) in the database.
iii. Only authenticated users can access the system functionalities.

[Link] Usability
i. The user interface must be simple and intuitive, using clear menus such as
“Dashboard”, “Add Student”, “Add Teacher”, “Exams”, “Report Sheets”,
“Settings”, etc.
ii. Pages should be consistent in design (same header, footer, color scheme).

[Link] Performance
i. The system should respond quickly for common operations such as searching
students, loading class lists, and generating report sheets, even when there are
many student records.

[Link] Reliability
i. The system should handle normal usage without crashing.
ii. Data should be correct and consistent when entered and retrieved from the
database.

[Link] Maintainability
i. The code should be modular (separate PHP files for database connection, header,
footer, controllers, etc.) to allow easy modification.

22
[Link] Portability
ii. The application should be able to run on any server that supports PHP and
MySQL, and has a web server like Apache (e.g., XAMPP/WAMP/LAMP).

3.4.3 Requirement Analysis

Requirement analysis was done using use case modeling.

[Link] Use Case Diagram

Actors:

 Admin
 Form Master
 Subject Teacher

Use Cases
 Login
 Add Teacher
 Add Student
 Update Students
 View Students
 Insert Scores
 Update Scores
 Print IDs
 Print Report Cards
 Print Broadsheets
 Print Subject Grade sheets

23
 Figure 3. 1 Use Case Diagram

[Link] Use Cases Description

24
Table 3. 1 Login Use Case Description

Use Case Name Login

Actor Administrator, Form Master, Subject Teacher

Priority High

Description This use case describes how a user logs into the online student
records management system.

Trigger User navigates to the login page.

Preconditions The user must have a valid username and password stored in the
database.

The database server (MySQL) and web server (Apache via XAMPP)
must be online.

Normal Course 1. The system displays the login page, requesting username and
password.

2. The user enters a valid username and password.

3. The system checks the credentials against the admins, teachers, or

related user table.

4. If credentials are correct, the system identifies the user role (admin,
form master, subject teacher).

5. The system redirects the user to the appropriate dashboard.

6. The use case ends.

25
 Alternative 3a. If the username or password is incorrect:
Course
The system displays an error message such as “Invalid username
or password”.

The user may re-enter the login details.

After a number of failed attempts (if implemented), the system may

temporarily block the user or prompt to contact administrator.

Postconditions A login record may be stored (if implemented).

The user session is created and the user is authenticated.

Table 3. 2 Add Student Use Case Description Table

Use Case Name Add Student

Actor Administrator, Form Master

Priority High

Description This use case describes how authorized users register a new
student into the school database.

Trigger User navigates to the "Manage Students" section and clicks

"Add New Student".

Preconditions User is logged in as Administrator or Form Master.

26
 The specific Class/Arm for the student must already exist in the
system.

Normal Course 1. System displays the Student Registration Form.

2. User enters student details (Surname, First Name, DOB,

Address, Class, Parent Contact).

3. User clicks the "Save" or "Submit" button.

4. System validates that all mandatory fields are filled and

formatted correctly.

5. System saves the new record to the database.

6. System displays a success message: "Student Added

Successfully".

7. Use case ends.

Alternative 4a. If validation fails (e.g., missing fields):

Course
System highlights the missing fields.

System displays error: "Please fill all required fields".

User updates the fields and resubmits.

4b. If the student already exists:

System detects a duplicate admission number.

System displays error: "Student ID already exists".

Postconditions A new student record is created in the database and is visible in

the class list.

Table 3. 3 Input Scores Use Case Description Table

27
Use Case Name Input Scores

Actor Administrator, Form Master, Subject Teacher

Priority High

Description This use case describes the process of entering academic scores
(CA and Exam) for students in a specific subject.

Trigger User selects "Input Scores" from the dashboard menu.

Preconditions Students are registered in the class.

The Subject has been assigned to the teacher (or is accessible by

Admin).

Normal Course 1. User selects the Session, Term, Class, and Subject.

2. System retrieves the list of students offering that subject.

3. System displays a grid/spreadsheet view for data entry.

4. User enters scores for Continuous Assessment (CA) and Exams.

5. User clicks "Save Scores".

6. System validates that scores are within the valid range (e.g., 0-
100).

7. System saves the data.

8. Use case ends.

Alternative 6a. If an invalid score is entered (e.g., >100):

Course

28
 System flags the specific cell in red.

System displays error: "Score cannot exceed maximum

obtainable marks".

System prevents saving until corrected.

Post conditions Student scores are updated in the database and ready for report
generation.

Table 3. 4 Generate Report Sheet Use Case Description Table

Use Case Name Generate Report Sheet

Actor Administrator, Form Master

Priority Medium

Description This use case describes how the system processes scores to
produce a printable termly report card for students.

Trigger User selects "Print Report Cards" or "Generate Results".

Preconditions Scores for all subjects must be entered.

Grading scale configuration must be set.

Normal Course 1. User selects the Class, Session, and Term.

29
 2. User selects a specific student or "All Students".

3. User clicks "Generate Report".

4. System calculates Totals, Averages, Grades, and Class

Positions.

5. System generates a PDF preview of the report sheet.

6. User sends the document to the printer.

7. Use case ends.

Alternative 4a. If data is incomplete (e.g., missing subjects):

Course
System warns: "Some subjects have no scores entered. Proceed
anyway?"

User can choose to Cancel or Proceed with incomplete reports.

Post conditions A finalized report card is generated, and position/class statistics

are stored.

3.5 Description of the Proposed System

The proposed system is a web-based application that automates the management of

student records and examination scores, with clearly defined user roles.

The system adopts a modular approach, separating the application logic from the
database management to ensure flexibility and ease of maintenance. By leveraging a
centralized database, the system eliminates data redundancy and ensures that all
stakeholders have access to real-time, accurate academic records.

30
3.5.1 System Design

This section presents the design of the proposed online student records management
system, the proposed Student Records Management System is designed as a robust, web-
based application aimed at automating the manual processes of student enrollment, score
processing, and result generation. The primary objective of the system design is to create
a secure, scalable, and user-friendly platform that ensures data integrity and streamlines
the workflow between Administrators, Form Masters, and Subject Teachers.

3.5.2 Main Features Overview (Activity Diagram)

Figure 3. 2 Activity Diagram

31
3.5.3 Architecture Design

[Link] Class Diagram Showing the System Architecture

Figure 3. 3 Class Diagram

32
3.5.4 Architecture Design

[Link] Database Design Description Using Entity relationship Diagram (ERD)

Figure 3. 4 Entity Relationship Diagram

3.6 System Development Model

For this project, the Waterfall Model (a linear sequential SDLC model) was adopted.

The phases include:

a. Requirements Analysis
b. System Design
c. Implementation (Coding)
d. Testing
e. Deployment (localhost/XAMPP and Infinityfree via their cloud)
f. Maintenance (future improvements)

33
3.6.1 Reason for Selecting Waterfall Model:

The project has clearly defined requirements (online student record management, result
processing, role-based access for admin, form master, subject teacher).

The academic project has limited time; a linear sequence makes planning and
documentation easier. Waterfall is simple to understand and well suited to small and
medium academic software projects where major requirement changes are not expected
during development.

It aligns with the departmental guideline that follows: Introduction → Analysis & Design
→ Implementation → Testing → Documentation.

In this project, each phase was completed before moving to the next, and outputs from
one phase became the input for the next phase. This ensured proper documentation and
traceability of decisions.

3.7 Summary

This chapter presented the methodology adopted in developing the Online Students
Records Management System for Staff Secondary School, Bayero University Kano. The
chapter described the project workflow from problem identification through design,
implementation with HTML/CSS/PHP/MySQL on XAMPP, and testing. The Waterfall
model was used as the system development life cycle due to its simplicity and suitability
for academic projects with clearly defined requirements.

The existing partially manual system was analyzed, highlighting challenges such as
errors, delays, and limited accessibility. User and non-functional requirements were
elicited from administrators, form masters, and subject teachers, and then analyzed using
use case modeling. The design of the proposed system was outlined with descriptions of
user roles, system architecture, class design, and database schema based on tables
like admins, teachers, studentdata, scores, classes, subjects, sessions, ter
ms, and system_settings.

34
 CHAPTER FOUR

SYSTEM IMPLEMENTATION AND TESTING

4.1 Introduction

This chapter presents the implementation and testing of the Online Students Records
Management System developed for BUK Staff Model Secondary School. It describes the
development environment, how the system was implemented using HTML, CSS, PHP
and MySQL on XAMPP, the main interfaces and modules, the user roles (admin, form
master and subject teacher), as well as the testing strategies adopted to verify that the
system meets the specified requirements. The chapter also discusses test results,
challenges encountered during implementation and testing, and how they were resolved.

4.2 Development Environment

This section describes the hardware and software tools used in the development and
deployment of the system.

4.2.1 Hardware Requirements

The system was developed and tested on a standard personal computer with the following
minimum specifications:

i. Processor: Intel Core i3 (or equivalent)

ii. RAM: 4 GB or higher
iii. Storage: 250 GB HDD/SSD (with at least 5 GB free space)
iv. Display: 15.6-inch monitor with 1366 × 768 resolution or higher
v. Peripherals: Keyboard, mouse, printer (for printing report sheets and ID cards)

On deployment, any computer in the school’s examination or administration office that

meets similar specifications can run the system in a local network or online hosting
environment.

35
4.2.2 Software Requirements

[Link] Operating System:

Windows 10 (development and testing); the system can run on any OS that
supports a web server (e.g., Linux).

[Link] Web Server Stack:

XAMPP distribution including: Apache HTTP Server, PHP (server-side
scripting), MySQL/MariaDB (database server)

4.3 Development Tools:

4.3.1 Text editor / IDE

VS Code/Notepad++.

PHP MyAdmin (for database administration).

4.3.2 Web browser

(Chrome, Firefox, Edge) for testing.

4.3.3 Languages and Technologies:

HTML and CSS: for structure and styling of user interfaces.

PHP: for server-side logic and dynamic content generation.

MySQL for relational database management.

Basic JavaScript (where needed) for client-side form validation and interactivity.

36
4.4 System Implementation

This section explains how the design in Chapter Three was translated into an operational
system. The implementation followed the layered architecture: presentation layer
(interfaces), application logic (PHP scripts) and database layer (MySQL tables).

4.4.1 Database Implementation

The database was implemented in MySQL using the schema designed in Chapter Three.
The main tables include:

admins – stores administrator login details and profile information.

teachers – stores teacher accounts including form masters and subject teachers.

classes – defines the different classes (e.g., JSS1, JSS2, JSS3, etc.).

subjects – contains the list of subjects offered at the school.

studentdata – stores student personal and academic information (name, gender,

class, admission number, etc.).

scores – stores students’ continuous assessment (CA) and exam scores for each
subject, class, term and session.

sessions – stores academic sessions (e.g., 2024/2025, 2025/2026).

terms – stores terms (First Term, Second Term, Third Term).

teacher_assignments – maps teachers to classes and subjects they handle.

system_settings – stores active session and term, school name, logo and other
configuration values.

user – stores generic user accounts where necessary.

Primary keys, foreign keys and indexes were defined to maintain referential integrity and
to speed up queries. For example, each score record links to a specific student, subject,

37
class, session and term. Role-based access was enforced using user and teacher tables to
differentiate admin, form master and subject teacher permissions.

4.4.2 Backend Implementation (PHP and MySQL)

The core application logic was implemented in PHP. Major modules include:

[Link] Authentication Module:

i. Handles login for admin, form master and subject teacher.
i. Verifies credentials against the database and sets user sessions.
ii. Enforces access control so that each role only accesses allowed pages (e.g.,
subject teacher cannot modify system settings).

[Link] Student Management Module:

i. Admin and form master can add new students, edit student records, and view lists
of students by class.
ii. Search functionality allows users to find students by name or admission number.

[Link] Teacher Management Module (Admin):

i. Admin can add new teachers, assign them as form masters or subject teachers.
ii. Admin can assign subject teachers to specific classes and subjects using the
teacher_assignments table.

[Link] Class, Subject, Session and Term Management (Settings):

i. Admin can configure classes, subjects and academic sessions.
ii. Admin can set the active session and active term in the system_settings table.
iii. These settings control which session and term are used when entering and
generating results.

[Link] Results and Scores Management (Exams Module):

i. Form master and subject teacher can enter continuous assessment and exam
scores for students in their assigned class/subject.
ii. Subject teachers can only input scores but cannot edit previously approved scores,
maintaining data integrity.

38
 iii. The system automatically computes total scores, averages and positions where
required.

[Link] Report Generation Module:

i. Generates individual student report sheets showing subject scores, total, average,
grades and comments.
ii. Generates class summary sheets, subject summaries and broadsheets for the exam
office.
iii. Provides functionality for printing student ID cards and staff ID cards.

[Link] Dashboard and Analytics Module:

i. Displays key statistics such as total active students, overall best student, and class
champions.
ii. For the admin, the dashboard summarizes the overall performance across the
school.
iii. For form masters, the dashboard focuses on their specific class performance.
iv. All interactions between the application layer and the database are performed
through parameterized SQL queries to reduce the risk of SQL injection. Server-
side validation in PHP checks for missing or invalid inputs before performing
insert or update operations.

4.4.3 Frontend Implementation (User Interfaces)

i. The user interfaces were developed using HTML and CSS and are designed to be
simple, clear

[Link] Admin Dashboard Interface:

i. The dashboard match the school logo in color and easy to use for staff members.
ii. The main interfaces show school logo, admin name and role (Administrator).
iii. Provides navigation menu: Dashboard, Search Student, Add Student, Add
Teacher, View Students, Print Staff ID, Student ID Card, Exams, Settings, Profile
and Logout.
iv. Displays information such as number of active students, overall best student and
class champions.

39
[Link] Admin Search and Student Management Pages:
i. Search page allows the admin to search for students by name.
ii. View Students page lists students with options to view details and print report
sheets.

[Link] Settings Interface (Admin):

i. Allows the admin to set the active academic session and term (e.g., 2025/2026 •
First Term).
ii. Provides options to manage classes, subjects, sessions and teacher assignments.

[Link] Form Master Dashboard and Pages:

i. After login, the form master sees a dashboard showing class statistics and best-
performing students in the assigned class.
ii. Navigation menu includes: Dashboard, Add Student, View Students, Print Report
Sheets, Exams, Results Summary, Broadsheet and Logout.
iii. The form master can register students, enter or verify scores, and generate class
report sheets.

[Link] Subject Teacher Dashboard and Pages:

i. The subject teacher interface has a simpler menu: Dashboard, View Students,
Exams, Subject Summary, and Logout.
ii. Subject teachers can select their class and subject to input students’ CA and exam
scores.
iii. They can view subject summary sheets but cannot modify global settings or edit
students’ personal data.

Each page is styled with consistent colors, fonts and school branding (logo, motto
“SUCCESS THROUGH HARDWORK”). Buttons and forms are clearly labeled to
reduce user errors.

40
4.5 System Features

The major features of the implemented system are summarized below in line with the
requirements:

4.5.1 User Authentication and Role-Based Access Control

[Link] Landing Page

This the landing page serving as the first interface a user will visit in order to navigate his
access, here teachers and administrators has to click on staff login to start, the school
contact details, location, programs offered and admission advertisement were made
available in the landing page for effective public communication.

Figure 4. 1 A Landing Page of the Proposed System

41
[Link] Login Page:

Upon clicking the login button the user will be redirected to this login page, the system
has centralized login page were each user will be validated upon his assigned role and
grant access to the right interface, e.g admin, subject teacher and form masters.

Figure 4.2 A unique Login Page for admin and the teachers

The system has a secure login for admin, form master and subject teacher. Each role sees
only the functions they are authorized to use.

4.5.2 Student Records Management

Capture and update student bio data, maintain class information and search for students
quickly by name or admission number.

42
[Link] Add Students:
Here users can add students based on the role assigned to them (e.g admin can add
students for all classes while form masters can add only to their assigned classes)

ff

Figure 4. 3 Add Student

[Link] Search Students

Search student is restricted to admins only, only admin can search and manage students
(e.g delete, update, or promote).

Figure 4. 4 Search Students

43
[Link] Update Student
After searching the student by like characters of their name admin can select and click on
an individual student to update/delete his/her records from the system, this is restricted to
admin (i.e the school administrators).

Figure 4. 5 Update Students records/Delete

4.5.3 Teacher and Class Management (Admin)

Admin can add teachers with a role assignment of form master or a subject teacher; also
he can search for a specific user to update or delete his/her records, and the classes as
well with their subject offered.

44
 Figure 4. 6 Manage Teachers

[Link] Manage Classes and Subjects

Here admin can manage the individual entities of the system (i.e admin can add classes
and the subjects offered by such classes and also he/she can delete the class, or subject).

Figure 4. 7 Manage Classes and Subjects

45
4.5.4 Results Management

[Link] Students Score sheet

The below interface is for students’ scores recording, its designed based on access
restriction such that an admin can manage scores for all the subjects and classes added to
the system, while form masters and subject teachers can only manage scores of their
assigned class, there is also edit restriction to the form masters such that only admin can
edit scores after it being recorded.

Figure 4. 8 Students Score Sheet

46
[Link] Students Report Card
The system can also generate report cards with the restriction of; only admin can generate
report cards of all classes while the form masers can generate report cards of their
assigned class.

Figure 4. 9 Automated Report Card from the system

Enter CA and exam scores for each student, subject, term and session, automatically
calculate totals and averages, restrict editing of scores based on role and status (e.g.
Subject teacher cannot modify finalized scores).

47
4.5.5 Subject Score Sheet and Broadsheet Generation

Form masters can generate subject score sheet for an individual subject(es) offered by
his/her class, and also he/she can generate the class summary (broadsheets) at the end of a
particular term.

Figure 4. 10 Subject based grade sheet from the system

Figure 4. 11 Class Broadsheet

48
4.5.6 ID Card Generation

To ease another cause the system also made available the generation of staff identity
cards, which is manage by the school administrator.

Figure 4. 12 Staff ID Card form

Figure 4. 13 Sample Staff ID card ID print generated from the system

49
4.5.7 System Configuration

Set active academic session and term, manage classes, subjects, and general system
parameters.

Figure 4. 14 A General System settings page showing the active term and session

50
4.5.8 Dashboard Analytics

Display overall best student, class champions, and basic performance statistics, with the
system menu in the hamburger.

Figure 4. 15 A system dashboard for an admin

Figure 4. 16 A class form master dashboard

51
4.6 System Testing

System testing was carried out to ensure that the implemented system meets both
functional and non-functional requirements identified in Chapter Three.

4.6.1 Testing Strategy

The following testing approaches were adopted:

[Link] Unit Testing:

Individual PHP functions and modules such as login validation, student registration and
score insertion were tested independently to verify that they behave correctly with valid
and invalid inputs.

[Link] Integration Testing:

Related modules (e.g., student registration, score entry and report generation) were tested
together to ensure that data flows correctly from one module to another without errors.

[Link] System Testing:

The complete application was tested in local environment (XAMPP) using different user
roles to confirm that it satisfies the overall system requirements.

[Link] User Acceptance Testing (UAT):

Selected staff (representing admin, form masters and subject teachers) were asked to use
the system to perform their normal tasks such as adding students, entering scores and
printing report sheets. Their feedback was used to refine the interfaces and fix minor
issues.

4.6.2 Test Cases

Representative test cases used during testing are outlined below (you can later put them
in a table in your report):

52
[Link] Login Test
Input: Correct username and password for admin.

Expected Result: User is redirected to admin dashboard and granted admin privileges.

Actual Result: As expected – PASS.

Input: Incorrect password.

Expected Result: System displays “Invalid username or password” and denies access.

Actual Result: As expected – PASS.

[Link] Add Student Test (Admin/Form Master)

Input: Complete and valid student details (name, gender, class, admission number).

Expected Result: Student is saved to studentdata table and appears in View Students list.

Actual Result: As expected – PASS.

Input: Missing required field (e.g., no class selected).

Expected Result: System prompts user to complete required fields and does not save the
record.

Actual Result: As expected – PASS.

[Link] Score Entry Test (Exams Module)

Input: Valid CA and exam scores within allowed range.

Expected Result: Score is saved in scores table; total and average are calculated
correctly.

Actual Result: As expected – PASS.

Input: Invalid score (e.g., score > 100 or negative value).

Expected Result: System rejects input and displays validation error message.

Actual Result: As expected – PASS.

53
[Link] Report Sheet Generation Test
Input: Select a student with existing scores for a given term and session.

Expected Result: Report sheet displays correct subject scores, totals, average and
remarks; layout is formatted for printing.

Actual Result: As expected – PASS.

[Link] Role-Based Access Test

Scenario: Subject teacher attempts to access Settings page or delete a student.

Expected Result: Access is denied or page is hidden, depending on implementation.

Actual Result: As expected – PASS.

Scenario: Form master attempts to modify system-wide session settings.

Expected Result: Access denied – only admin can modify.

Actual Result: As expected – PASS.

[Link] Session and Term Configuration Test

Input: Admin sets active session to 2025/2026 and term to First Term.

Expected Result: All new scores are associated with 2025/2026 First Term, and this
state is displayed in dashboards.

Actual Result: As expected – PASS.

[Link] Search Functionality Test

Input: Partial student name in Search Student page.

Expected Result: System returns matching students; clicking on student opens their
details.

Actual Result: As expected – PASS.

All critical test cases passed after iterative debugging and refinement.

54
4.6.3 Test Results and Discussion

The testing process confirmed that the system fulfills the main functional requirements:

1. Admin can manage teachers, classes, subjects, sessions and system settings.
2. Form masters can add students, manage their class records and generate report
sheets and broadsheets.
3. Subject teachers can only enter and view scores for their assigned subjects and
classes, without modifying other data.
4. Reports and summaries are generated automatically, significantly reducing
manual computations.
5. Non-functional requirements such as ease of use, performance and basic security
were also reasonably met:
6. The interfaces are simple and consistent, making it easy for non-technical users to
operate the system.
7. Operations such as searching for students and generating report sheets execute
quickly within the local environment.
8. Password-based authentication and role-based access help protect sensitive
student records.
9. Some minor issues such as formatting of printed report sheets and error message
wording were discovered during user acceptance testing and were corrected
before finalization.

4.7 Challenges Encountered

During system implementation and testing, several challenges were faced:

4.7.1 Data Design and Migration:

Designing a database structure that could accommodate different sessions, terms, classes
and subjects without redundancy required careful planning. Migrating existing manual
records into the database also required data cleaning to handle incomplete or inconsistent
information.

55
4.7.2 Role-Based Access Implementation:
Ensuring that each user role (admin, form master, subject teacher) had correct and
restricted privileges required additional checks in PHP scripts and careful menu design.

4.7.3 Report Formatting:

Adjusting the layout of printed report sheets, ID cards and broadsheets to match the
school’s expectations involved multiple iterations of HTML/CSS styling and print
preview tests.

4.7.4 User Familiarity:

Since staff were accustomed to partially manual processes (using paper grade sheets and
then transferring scores), some initial orientation was needed to show how to use the
system effectively.

These challenges were addressed through redesign of database tables, additional access
control logic, interface refinements and feedback sessions with intended users.

4.8 Summary

This chapter described the implementation and testing of the Online Students Records
Management System for BUK Staff Model Secondary School. The development
environment, database and application modules were outlined, and the main system
features were explained, including user management, student records management, score
entry, report generation, and system configuration. System testing using unit, integration,
system and user acceptance testing demonstrated that the system meets its functional and
non-functional requirements. Finally, the chapter discussed challenges experienced
during implementation and how they were resolved. The next chapter presents the
summary, conclusion and recommendations of the study.

56
 CHAPTER FIVE

SUMMARY, CONCLUSION AND RECOMMENDATION

5.1 Summary

The primary objective of this research project was to design and implement an Online
Students’ Records Management System for Staff Secondary School, Bayero University,
Kano, to replace the existing manual and partially computerized processes that were
prone to errors, delays, and data redundancy.

The study began with a detailed investigation into the school’s current record-keeping
practices. It was established that the reliance on paper registers and isolated spreadsheet
files made result compilation, report generation, and information retrieval inefficient.
Based on these findings, the Waterfall development model was adopted to guide the
software development life cycle.

The system was designed using a three-tier architecture and implemented using HTML,
CSS, and JavaScript for the frontend, with PHP handling the server-side logic and
MySQL serving as the relational database management system. Key functionalities
developed include:

1. Role-Based Access Control: Distinct dashboards were created for Administrators, Form
Masters, and Subject Teachers to ensure data security and appropriate access privileges.

2. Academic Records Management: Modules for registering students, managing classes

and subjects, and defining academic sessions and terms.

3. Result Processing: Automated computation of Continuous Assessment (CA) and

Examination scores, totaling, and grading, which eliminates manual calculation errors.

4. Report Generation: The system successfully generates automated Student Report

Sheets, Class Broadsheets, Result Summaries, and printable Staff and Student ID Cards.

57
 The system was tested in a local environment (XAMPP) using unit, integration, and user
acceptance testing strategies. The results confirmed that the application is robust, user-
friendly, and capable of solving the identified problems of the manual system.

5.2 Conclusion

The successful development of the Online Students’ Records Management System for
Staff Secondary School, BUK, marks a significant improvement over traditional record-
keeping methods. This project has demonstrated that web-based technologies can be
effectively utilized to streamline administrative workflows in secondary education.

By centralizing the database, the system ensures data integrity and consistency. The
automation of result processing has drastically reduced the time required for teachers to
compile grades and for the examination office to produce termly reports. Furthermore,
the implementation of role-based security measures ensures that sensitive student data is
protected against unauthorized alteration—a major deficiency in the previous manual
setup.

In conclusion, the system meets the research objectives set out in Chapter One. It
provides a scalable, efficient, and secure platform that empowers the school
administration to make timely, data-driven decisions while allowing teachers to focus
more on academic instruction rather than clerical duties.

5.3 Limitation

While the developed system successfully addresses the core problems of record
management, the following limitations were observed during the study:

1. Infrastructure Dependence: The effective deployment of the system relies heavily on a

stable power supply and consistent network infrastructure. In the context of the study
environment, power outages may disrupt access to the server if not backed up by
alternative power sources.

58
2. Scope of Modules: The current system focuses strictly on academic records (bio data and
results). It does not include a Bursary/Finance module for school fee management, nor
does it include a library management system.

3. Digital Literacy: During the testing phase, it was observed that some staff members with
limited computer proficiency required significant guidance to navigate the system,
suggesting a potential learning curve during full implementation.

4. Local Hosting: The system was tested and demonstrated in a local host environment.
While it is cloud-ready, issues related to live web hosting costs and domain management
were not covered in the implementation phase.

5.4 Recommendation

Based on the findings and the limitations identified above, the following
recommendations are made:

5.4.1 For the School Administration

1. Staff Training: It is recommended that Staff Secondary School, BUK, organizes

workshop training sessions for teachers and administrative staff to improve their digital
literacy and ensure they can utilize the system effectively.

2. Infrastructure Investment: The school should ensure there is a dedicated server or host
computer with a reliable backup power supply (UPS/Inverter) to prevent data loss or
downtime during operations.

3. Data Backup Policy: A routine data backup policy should be established to export the
database at the end of every term to an external drive or cloud storage to safeguard
against hardware failure.

5.4.2 For Further Research

59
 Future researchers and developers looking to enhance this system should consider the
following areas:

1. Integration of SMS/Email Notification: The system can be upgraded to automatically

send term results and attendance reports to parents via SMS or Email immediately after
approval by the admin.

2. Bursary Module Integration: Future versions should include a fee management module
that tracks school fee payments and automatically withholds access to report cards for
defaulting students.

3. CBT Integration: A Computer Based Test (CBT) module could be added to allow
students to take continuous assessment tests directly within the platform.

4. Mobile Application: Developing a mobile app version for Android and iOS would
improve accessibility for parents and teachers who may prefer accessing the system via
smartphones.

60
REFERENCES

Agarwal, P., Joshi, A., & Naib, B. (2021). Research Paper on Student Information
System. International Journal of Engineering, 10, 158-161.
[Link]
Alex, A. (2023). An Automated and Robust Tertiary Institution Web-Based Student
Complaint Management System. International Research Journal of Innovations
in Engineering and Technology. [Link]
(2025). Digital Archives: School and Academic records for Preservation and
Accessibility. International Journal of Science and Applied Information
Technology. [Link]
Agwu, L. O. (2018). Repositioning record keeping practices in Nigeria secondary
schools.
Akuna, E., & Y. P. (2025). Academic records management practices in Africa higher
education institutions: Empirical review. British Journal of Contemporary
Education, 1(1).
Atuh, A. J., Besong, B. J., & Nfon, N. F. (2023). Student records and the effective
management of public secondary schools in the South West and Littoral regions
of Cameroon. The American Journal of Social Science and Education
Innovations, 5(10).
Alegado, R., Alegado, A., & Alcantara, G. (2021). Guidance and Counseling Record
Management System. International Journal of Advanced Trends in Computer
Science and Engineering. [Link]
Barot, N., & Jain, V. (2025). Design and Implementation of a Student Management
Information System (SMIS). International Scientific Journal of Engineering and
Management. [Link]
Duruin, R. A., & Siddayao, G. P. (2024). Development of student records management

61
 system of Magalalag National High School. AIDE Interdisciplinary Research
Journal.
Duruin, R., & Siddayao, G. (2024). Development of Student Records Management
System of Magalalag National High School. AIDE Interdisciplinary Research
Journal. [Link]
Journal of Education and Practice. (2022). Education Management Information System
and tracking of students’ records in selected public secondary schools in Turbo
Sub-County, Kenya, 13(17).
Kaviya, C., Kalpana, R., Kanimozhi, P., Dhinesh Kumar, S., & Viji, D. (2025).
Web-based academic platform for optimizing student database management and
communication. International Research Journal on Advanced Science Hub.
K, D., & M, A. (2024). STUDENT RECORD SYSTEM USING PHP. INTERANTIONAL
JOURNAL OF SCIENTIFIC RESEARCH IN ENGINEERING AND
MANAGEMENT. [Link]
Mustafa, R., & Mustafa, K. (2025). Student Records Management System SRMS using
IoT. International Journal of Computational and Experimental Science and
Engineering. [Link]
Marcel, G. (2019). DEVELOPMENT OF AN ONLINE INTEGRATED STUDENT
MANAGEMENT INFORMATION SYSTEM: CASE STUDY “UNIVERSITY
OF GITWE. International Journal of Advanced Research in Computer Science.
[Link]
Mustafa, R. M., & Mustafa, K. (2025). Student records management system (SRMS)
using IoT. International Journal of Computational and Experimental Science and
Engineering, 11(1).
Odeniyi, O., & Adeyanju, A. (2020). Assessment of school record management in
secondary schools in Federal Capital Territory. Open Journal of Educational
Development, 1(1).
Patil, V., Patil, D., Satpute, H., & Tayade, S. (2023). Student Record Management
System using Django. International Journal for Research in Applied Science and
Engineering Technology. [Link]
Paculanan, R., Lacdao, J., De Guzman, M., Bautista, J., Paano, A., & Lumabi, J. (2025).

62
 Development of Guidance Record Management System with Exploratory Data
Algorithm for Predicting Academic Performance. International Journal of Latest
Technology in Engineering Management & Applied Science.
[Link]
Patil, V., Patil, D. S., Satpute, H. B., & Tayade, S. N. (2023). Student record management
system using Django. International Journal for Research in Applied Science and
Engineering Technology, 11(5).
Ronquillo Jr., Z. T., Tagasa, R. B., Batino, M. R., & Aquino, M. S. (2022). School
records and forms-online management system (SRF-OMaS). International Journal
in Information Technology in Governance, Education and Business, 2(2).
Rodríguez-Campos, J., Rico-Chagollán, M., Del Carmen Chacón-Olivares, M., &
Guzmán-Hernández, M. (2024). Frontend and Backend: The new approach to the
development of a Web platform for automating the control and administration of
degree processes at ITESI. Revista de Tecnologías Computacionales.
[Link]
Silwamba, F. K., & Matela, M. (2025). Design and development of a student record
system. Scientific Journal of Engineering and Technology, 4(1).
Silwamba, F., & Matela, M. (2025). Design and Development of a Student Record
System. Scientific Journal of Engineering, and Technology.
[Link]
Sistem, P., Bimbingan, I., Menggunakan, K., Smkn, D., Mahendra, P., Febriyanti, F.,
Taman, S., & Bima, S. (2025). Development of Guidance and Counseling
Information System Using Vb. 6.0 at SMKN 1 Palibelo. JURNAL PENDIDIKAN
IPS. [Link]
Venice, D. A., & Mwale, M. (2025). Design and implementation of a web-based result
management system: A case study of Emusa Day Secondary School, Chasefu
District, Zambia. ASET Journal of Management Science, 4(1).
Walia, S. (2014). A framework for web-based student record management system using
PHP.
Yuliandari, T. M., Putri, A., & Rosmansyah, Y. (2023). Digital transformation in
secondary schools: A systematic literature review. IEEE Access, 11.

63
Yusuf, S., Ayoku, O. B., & Funmilayo, I. B. (2022). Management information system in
Nigerian secondary schools: Challenges and way forward. International Journal of
Educational Innovation and Research, 3(2).
Zhou, Y., & Hou, L. (2023). Intelligent Campus Student Information Management
System Based on Cloud Platform. 2023 2nd International Conference for
Innovation in Technology (INOCON), 1-6.
[Link]

64
ELICITATION EVIDENCE

Empty Score sheet for manual filling from the existing system

65
Class Broadsheet Generated from the existing system

66
Student Report Card Generated from the Existing System

67
CODES OF MAJOR FUNCTIONALITY

1. Dashboard

2. Add Teacher

68
3. Insert Scores

69
4. View Score

70