Chapter One: Introduction

1.1 Background

The primary school environment relies on various manual and semi-automated

processes to manage student records, attendance, grades, and communications with
parents. Traditional paper-based filing and disparate spreadsheets lead to
inefficiencies, data duplication, and challenges in ensuring data accuracy. A
centralized Student Information System (SIS) will streamline these tasks, improve
data reliability, and support better decision-making.
The school in focus operates from grades 1 through 8, comprising administrative staff,
teaching faculty, and over 600 enrolled students. Each grade is split into multiple
sections, and teachers are assigned to specific subjects per grade level. Administrative
functions include enrollment, attendance tracking, grading, student transfers, and
communication with parents or guardians. Presently, much of this is managed through
fragmented and inconsistent processes, highlighting the urgent need for an integrated
system.

1.2 Statement of the Problem

The current student management system relies heavily on manual record-keeping and
spreadsheets. This results in data redundancy, difficulty in tracking student progress
across terms, delayed communication with parents, and time-consuming
administrative processes. Teachers and staff often struggle with retrieving up-to-date
information, leading to inefficiencies that affect both academic and operational
outcomes. A more robust, digital solution is required to address these issues.

1.3 Objective

General Objective: To develop a centralized, digital Student Information System

(SIS) for the primary school to improve the efficiency, accuracy, and accessibility of
student data management.

Specific Objectives:

To enable efficient student registration and record maintenance.




To automate attendance tracking and reporting.




To provide a centralized grading and performance tracking system.




To facilitate timely communication between the school and parents.




To implement secure role-based access for different user types (admin,

teacher, parent).


1.4 Methodology

Requirement Gathering Methods: User requirements will be gathered through

interviews with administrative staff, classroom observation, and review of existing
paper and digital records.

Requirement Modeling: An object-oriented approach will be used to model the

system, as it aligns well with the modular, entity-based structure of school operations.
Object-oriented models support better scalability, code reusability, and alignment
with real-world processes.

Tools Used:

UML Modeling Tool: StarUML




Programming Language: Java




Database: MySQL




Development Environment: Visual Studio Code




Version Control: Git




Documentation: Microsoft Word and Draw.io for diagramming


Chapter One: Introduction

1.1 Background

The primary school environment relies on various manual and semi-automated

processes to manage student records, attendance, grades, and communications with
parents. Traditional paper-based filing and disparate spreadsheets lead to
inefficiencies, data duplication, and challenges in ensuring data accuracy. A
centralized Student Information System (SIS) will streamline these tasks, improve
data reliability, and support better decision-making.

Ifa Bula Primary School operates from grades 1 through 8, comprising administrative
staff, teaching faculty, and over 600 enrolled students. Each grade is split into
multiple sections, and teachers are assigned to specific subjects per grade level.
Administrative functions include enrollment, attendance tracking, grading, student
transfers, and communication with parents or guardians. Presently, much of this is
managed through fragmented and inconsistent processes, highlighting the urgent need
for an integrated system.

1.2 Statement of the Problem

The current student management system relies heavily on manual record-keeping and
spreadsheets. This results in data redundancy, difficulty in tracking student progress
across terms, delayed communication with parents, and time-consuming
administrative processes. Teachers and staff often struggle with retrieving up-to-date
information, leading to inefficiencies that affect both academic and operational
outcomes. A more robust, digital solution is required to address these issues.

1.3 Objective

General Objective: To develop a centralized, digital Student Information System

(SIS) for Ifa Bula Primary School to improve the efficiency, accuracy, and
accessibility of student data management.

Specific Objectives:

 To enable efficient student registration and record maintenance.

 To automate attendance tracking and reporting.
 To provide a centralized grading and performance tracking system.
 To facilitate timely communication between the school and parents.
 To implement secure role-based access for different user types (admin, teacher,
parent).
1.4 Methodology

1.4.1 Requirement Gathering Methods

The following requirement gathering methods will be employed to collect accurate

and comprehensive system requirements for the Student Information System (SIS):

✅ Interviews
Conduct structured interviews with key stakeholders including administrative staff,
teachers, and IT personnel to understand their needs, pain points, and expectations for
the system.

✅ Classroom Observation
Observe daily classroom and administrative routines to gain insights into current
workflows, data handling practices, and areas of inefficiency.

✅ Document Review
Analyze existing paper-based and digital records such as enrollment forms, grade
sheets, and attendance logs to identify the type and structure of data that needs to be
digitized.

✅ Use Cases and Scenarios

Develop practical use case scenarios that reflect day-to-day operations (e.g., student
registration, attendance entry) to ensure that system features align with user needs.

✅ Prototyping
Create low-fidelity prototypes to visualize the system’s user interface. Present these to
stakeholders for early feedback and refinement of system requirements.

1.4.2 Process Model

An Object-Oriented Development approach will be followed for designing and

implementing the system, supported by Agile principles to allow flexibility and
iterative feedback.

✅ Object-Oriented Approach
This model suits the SIS due to its modular and entity-based design. Core components
like students, teachers, grades, and classes can be easily represented as objects,
enabling scalability and maintainability.

✅ Agile Development Process

The project will be developed in multiple sprints, each involving planning, coding,
testing, and stakeholder review. Agile's iterative model enables continuous
improvement and rapid response to evolving user requirements.

1.4.3 Tools Used

The following tools will be utilized throughout the development lifecycle of the
Student Information System:

▶ Modeling Tool: StarUML

Used to create UML diagrams such as use case, class, sequence, and activity diagrams
to visualize system architecture and behavior.

▶ Programming Language: Java

Chosen for its robustness, portability, and extensive library support suitable for
enterprise-grade applications.

▶ Database: MySQL
A widely used open-source relational database to store student records, attendance,
grades, and user credentials.

▶ Development Environment: Visual Studio Code

A lightweight and customizable IDE that supports Java development and integrates
well with extensions for version control and debugging.

▶ Version Control: Git

Used to manage source code revisions, track changes, and facilitate team
collaboration through platforms like GitHub.

▶ Documentation & Diagramming: Microsoft Word and Draw.io

Word will be used for system documentation, while Draw.io will assist in drawing
additional diagrams and wireframes.

By applying these methods, process models, and tools, the project team will ensure
that the system meets real user needs, is well-documented, and can be developed,
tested, and deployed efficiently within the allocated timeframe.

1.5 Feasibility

Economic Feasibility: The system will be developed using open-source tools and
existing hardware infrastructure within the school. This minimizes cost and ensures
that the economic investment is limited primarily to staff training and deployment.

Technical Feasibility: The system can be implemented with currently available

technologies and within the technical capacity of the project team. The chosen
technologies (Java, MySQL) are widely used, well-supported, and compatible with
the school's existing infrastructure.

Time Feasibility: The project is planned to be developed and deployed within a five-
month timeframe. This includes requirement gathering, system modeling,
development, testing, and training phases.

1.6 Project Scope and Limitation

1.6.1 Project Scope

The Student Information System (SIS) for Ifa Bula Primary School is designed to
streamline and centralize key student management operations within the school. The
scope of the system includes:

1.Student Registration and Record Management – Digitizing the enrollment

process, storing student profiles, and enabling easy updates to student information.

2.Attendance Tracking – Automating daily attendance recording, generating reports,

and identifying attendance patterns.

3.Grading and Academic Performance Monitoring – Allowing teachers to input

grades, generate report cards, and track student progress across terms.

4.Parent Communication – Facilitating timely updates and notifications to parents

regarding attendance, grades, and other school matters.

5.Role-Based Access Control – Assigning specific system access levels for

administrators, teachers, and parents to maintain security and confidentiality.

6.Centralized Data Storage – Maintaining a single, unified database to ensure

consistency, data integrity, and ease of reporting.

1.6.2 Limitations

While the SIS offers significant improvements over the existing manual processes, it
does have some limitations:

1. No Mobile Application Support – The initial system release will be web-based

only, with no dedicated mobile app.
2. 2.Limited Analytics – Advanced reporting and predictive analytics (e.g., student
performance forecasting) are not included in the first version.
3. 3.No Integration with External Platforms – The system does not currently
support integration with external educational platforms or government databases.
4. 4.User Adoption Dependency – The success of the system is highly reliant on
consistent and correct usage by staff and faculty.
5. 5.Initial Training Required – Teachers and administrative staff will require
training to effectively use the new system.
6. 6.Hardware Constraints – The system will depend on the school’s existing
infrastructure, which may limit performance or accessibility in some cases.

1.7 Significance of the Project

A Student Information System (SIS) holds immense importance for educational

institutions, particularly at the primary level. Its significance lies in its ability to
enhance administrative operations, improve academic management, and foster better
communication between schools and families. Below are key reasons why such a
system is crucial for Ifa Bula Primary School:

✅ Administrative Efficiency

The SIS automates routine administrative tasks such as

enrollment, attendance tracking, and grade management.

It reduces manual effort, minimizes human errors, and

enables staff to focus on more strategic responsibilities.

✅ Enhanced Communication

Parents receive timely updates on their child’s academic performance, attendance, and
school events.

This strengthens the partnership between home and school, fostering a supportive
learning environment.

✅ Academic Tracking and Decision-Making

Teachers and administrators can monitor student progress in real-time.

The system provides a centralized view of grades, attendance patterns, and behavioral
records, aiding data-driven decision-making.

✅ Data Accuracy and Integrity

Centralized storage ensures data consistency and reduces redundancy often found in
paper-based or spreadsheet systems.

Accurate and up-to-date records improve the quality of reporting and school planning.

✅ Accessibility and Transparency

Authorized users (teachers, admin staff, and parents) can securely access relevant
student information based on their roles.

This promotes transparency while maintaining privacy and data protection standards.

✅ Scalability

The system is designed to accommodate growing student numbers, additional staff,

and future feature expansions such as analytics or mobile integration.

✅ Environmental and Cost Benefits

Reducing reliance on paper contributes to environmental sustainability.

Leveraging open-source tools and existing infrastructure ensures economic feasibility
with minimal ongoing costs.

✅ Model for Broader Adoption

If successful, the SIS developed for Ifa Bula Primary School

can serve as a replicable solution for other schools facing
similar challenges in student data management.

In conclusion, the Student Information System will transform how Ifa Bula Primary
School handles its core operations. Through automation, accuracy, and improved
communication, the system will create a more effective and responsive educational
environment. However, its long-term success will also depend on consistent usage,
proper training, and user-friendly design.

1.8 Organization of the Project

The project document is organized into three main chapters:

Chapter One covers the introduction, objectives, and methodology.

Chapter Two addresses system analysis, including existing and proposed

systems, functional requirements, and UML diagrams.

Chapter Three focuses on the design of the system, including architecture,

components, deployment, and security considerations.

Chapter Two: Analysis

2.1 Existing System
Existing System Description

The current system for managing student information at Ifa Bula Primary School is
largely manual, with limited use of basic digital tools. It includes traditional methods
such as handwritten records, spreadsheets, and face-to-face communication. The
system is characterized by the following issues:

✅ Manual Record Keeping: Student data, grades, and attendance are mostly stored
in paper-based registers. This leads to difficulty in retrieval, frequent misplacements,
and inconsistency in data.

✅ Basic Digital Tools: Some tasks are performed using Microsoft Excel or Word, but
there is no centralized, integrated system for handling all student-related information.

✅ Limited Communication: Parent-teacher communication is usually conducted via

notes sent home with students or through infrequent meetings, often resulting in poor
information flow.

✅ Inconsistent Reporting: Generating reports (e.g., academic progress, attendance

summaries) requires significant manual effort, causing delays and inaccuracies.

✅ Administrative Overload: Staff spend a large portion of time on repetitive tasks

such as entering grades, compiling attendance, and maintaining personal records
manually.

Drawbacks of the Existing System

Inefficiency and Time-Consumption: Manual processes are slow and prone to error.
Data Inaccuracy and Loss: No backup or recovery mechanisms for lost or damaged
records.

Poor Communication: Delays in informing parents about student performance.

Limited Access and Transparency: Students and parents cannot access academic
data independently.

Scalability Issues: The system cannot handle growing numbers of students or

expanded administrative needs.

2.2 Business Rules

The school currently operates under the following rules and policies:

✅ Enrollment Policy: Students must register at the beginning of each academic year.
Required documents include birth certificate, previous school reports (if applicable),
and identification for the guardian.

✅ Attendance and Grading: Teachers record attendance daily, and grades are
entered at the end of each term manually. A minimum attendance of 75% is required
for promotion.
✅ Parental Access: Parents can request academic reports and attend scheduled
meetings to discuss performance. No digital platform exists for on-demand access.

✅ Discipline and Record-Keeping: Student behavioral incidents are recorded

manually and reviewed by administrative staff during parent conferences.

✅ Fee Management: Payments for school fees are handled through cash or bank
deposits with no system for tracking due dates or generating receipts automatically.

These business rules form the backbone of the existing system. However, due to
operational inefficiencies, an integrated Student Information System is needed to
automate and enhance these procedures.

2.2 New System

2.2.1 Non-functional Requirements and Constraints

The new Student Information System must meet the following non-functional
requirements:

Security:User authentication and role-based access control for teachers, admins, and
parents.Data encryption and compliance with school data protection policies.

Performance:The system should provide fast response times during data entry,
retrieval, and report generation.

Scalability:Capable of handling increased student records and staff as the school

grows.

Reliability:Ensure 24/7 system availability with minimal downtime and offline

access when necessary.

Usability:Simple and intuitive interfaces designed for non-technical staff, teachers,

and parents.

Data Backup and Recovery:Regular automated backups and recovery protocols to

avoid data loss.

2.3 Functional Requirements

The system will support the following core functions:

User Registration and Authentication:

Admin, teachers, and parents can register and securely log in to the system.

Student Enrollment:
New students can be registered with personal details, guardian information, and
academic history.
Attendance Management:
Teachers can record daily attendance and generate summary reports.

Grade Recording and Reporting:

Teachers can enter grades for assignments and exams. Parents and students can view
progress reports.

Parent Portal:
Parents can access academic records, attendance reports, and receive notifications.

Fee Management:
Tracks student payments, generates receipts, and sends reminders for upcoming dues.

Notification System:
Sends SMS or email alerts to parents regarding attendance issues, announcements,
and events.

2.3.1 Use Case Diagram

Participating Actors:

Admin

Teacher

Parent

Student

Use Cases:

Login to system

Register new student

Record attendance

Enter grades

View academic reports

Pay fees

Generate receipts

Notify parents

View attendance and grade history

 Update student profile

📌 Use Case: Student Enrollment

Actors: Admin

Flow of Events:

Admin logs into the system.

Opens the enrollment module

Inputs student and guardian data

Submits the form.

System saves and confirms enrollment.

Entry Condition: Admin authenticated

Exit Condition: Student successfully registered in the system

📌 Use Case: Record Attendance

Participating Actor: Teacher

Flow of Events:

 Teacher logs in to the system using their credentials.

 The system authenticates the teacher and loads the dashboard
 The teacher selects the “Attendance” module from the main menu.
 The system displays a list of classes assigned to the teacher.
 The teacher selects a specific class and date for which attendance is to be
 recorded.
 The system displays the list of students enrolled in the selected class.
 The teacher marks each student as Present, Absent, or Late.
 The teacher reviews the entries and clicks “Submit Attendance”.
 The system validates the data (e.g., no student left unmarked).
 Upon successful submission, the system saves the attendance record in the
database.
 A confirmation message is displayed: “Attendance recorded successfully”.
 Optionally, a notification is sent to parents (if configured).
 The teacher logs out or returns to the dashboard.

Entry Condition:Teacher is authenticated and logged

into the system.

Exit Condition:Attendance is successfully recorded

and stored in the system database.

2.5 Activity Diagram

Activity diagrams describe the flow of operations in a system. For the Student
Information System, these diagrams show how various activities are carried out
dynamically by different actors such as Admin, Teacher, Parent, and Student. They
reflect the sequence and decision logic used in the following processes.

Figure 1: Student Registration Activity Diagram

Start

Admin logs in

Opens Registration form

Enters student and guardian information

Checks for completeness

Validates against existing records

Adds to database

Sends confirmation to parent

End

Figure 2: Attendance Recording Activity Diagram

Start

Teacher logs in
 Selects class and date

Opens attendance module

Marks students present or absent

Saves attendance

Notification sent to parent (optional)

End

Figure 3: Grade Entry and Report Generation Activity

Diagram

Start

Teacher logs in

Selects subject and student

Enters grades

Saves and submits grades

Admin reviews (if applicable)

System generates report card

Report available to parent and student

End

Figure 4: Fee Payment Activity Diagram

Start

Parent logs in

Views outstanding fees

Makes payment (cash or bank transfer)

 System verifies payment

Generates and sends receipt

Updates student fee status

End

2.6 Conceptual Modeling: Class Diagram

A class diagram provides a static view of the system, showing key objects (classes),
their attributes, methods, and relationships. The following is a high-level UML
class diagram for the Student Information System of Ifa Bula Primary School.

Figure 5: Student Information System – Class Diagram

Class: Student

Attributes: studentID, fullName, dateOfBirth, gender, gradeLevel, address,

guardianInfo

Methods: register(), updateProfile(), viewReport(), viewAttendance()

Class: Teacher

Attributes: teacherID, fullName, subject, contactInfo

Methods: recordAttendance(), enterGrades(), viewClassList()

Class: Admin

Attributes: adminID, fullName, role

Methods: approveRegistration(), manageUsers(), generateReports()

Class: Parent

Attributes: parentID, fullName, contactInfo, studentID

Methods: login(), viewGrades(), viewAttendance(), payFees()

Class: Attendance

Attributes: attendanceID, studentID, date, status

Methods: markAttendance(), viewSummary()

Class: Grade
 Attributes: gradeID, studentID, subject, term, score

Methods: inputGrade(), calculateAverage()

Class: FeePayment

Attributes: paymentID, studentID, amount, date, method, status

Methods: makePayment(), verifyPayment(), issueReceipt()

Class: Notification

Attributes: notificationID, recipientID, message, dateSent

Methods: sendNotification(), markAsRead()

Relationships:

Student ↔ Parent (1:1 or 1:many)

Student ↔ Attendance (1:many)

Student ↔ Grade (1:many)

Student ↔ FeePayment (1:many)

Admin ↔ All classes (has control or access)

Teacher ↔ Grade, Attendance (1:many)

Teacher logs in.

Navigates to attendance module.

Selects class and date.

 Marks students as present or absent.

Saves and submits data.

Entry Condition: Teacher authenticated

Exit Condition: Attendance saved and visible to admin/parents

📌 Use Case: View Grades

Actors: Parent, Student

Flow of Events:

Parent/Student logs in.

Opens academic records section.

 Views term-wise and subject-wise grades.

Entry Condition: Parent/Student authenticated

Exit Condition: Academic report viewed/downloaded

2.4 Sequence Diagrams

Sequence diagrams illustrate how system components interact over time to perform
tasks:

Figure 1: Sequence Diagram – Student Registration

Actors: Admin, System

Flow: Admin enters data → System validates → Student ID created →

Confirmation sent

Figure 2: Sequence Diagram – Attendance Recording

Actors: Teacher, System

Flow: Login → Select class/date → Mark attendance → Submit →

Confirmation
Figure 3: Sequence Diagram – Grade Entry

Actors: Teacher, System

Flow: Login → Select student → Enter grades → Save → Generate report

Figure 4: Sequence Diagram – Parent Notification

Actors: System, Parent

Flow: Event trigger → Notification generated → Message sent via SMS/Email

2.5 State Chart Diagram

The following state diagrams show how key objects change state during their
lifecycle:

Figure 5: State Diagram – Student

States: Registered → Active → Promoted → Graduated/Withdrawn

Figure 6: State Diagram – Fee Payment

States: Not Paid → Partial Payment → Fully Paid → Receipt Issued

Figure 7: State Diagram – Report Card

States: Not Generated → Draft → Finalized → Viewed/Downloaded

Figure 8: State Diagram – Parent Notification

States: Not Sent → Scheduled → Sent → Acknowledged

Here's the Use Case Documentation for a Student Information System based on
the structure and style you provided:

📌 USE CASE NAME: Student Registration

PARTICIPATING ACTORS
Student, Admin

FLOW OF EVENTS

The student opens the homepage.

 Clicks on the "Register" button.

The system displays a registration form.

The student fills in all required details (name, DOB, grade, guardian info,
etc.).

The system checks for completeness and duplication in the database.

If valid, the request is sent to the admin for approval.

Admin verifies the form and creates a student account.

The system sends login credentials via email or SMS.

ENTRY CONDITION
The student accesses the registration page.

EXIT CONDITION
Student account is created and credentials are issued.
📌 USE CASE NAME: Class Attendance Recording

PARTICIPATING ACTORS
Teacher, Student, Admin

FLOW OF EVENTS

The teacher logs into the system.

Navigates to the "Attendance" section.

Selects the class and date.

Marks each student as Present or Absent.

Submits the attendance data.

The system stores the attendance and makes it viewable by Admin and
Parents.

ENTRY CONDITION
Teacher logs into their dashboard.

EXIT CONDITION
Attendance data is saved and visible to authorized users.
📌 USE CASE NAME: Grade Entry

PARTICIPATING ACTORS
Teacher, Student, Parent, Admin

FLOW OF EVENTS

Teacher logs in to the system.

Navigates to the “Grades” module.

Selects class, subject, and term.

Inputs student scores and saves.

The system calculates average scores and stores them.

Students and parents can view results.

ENTRY CONDITION
Teacher accesses their dashboard.

EXIT CONDITION
Grades are submitted, stored, and available for viewing.
📌 USE CASE NAME: Fee Payment

PARTICIPATING ACTORS
Parent, Bank, Admin, Student

FLOW OF EVENTS

Parent logs into the portal.

Opens the “Payments” section.

System shows pending fees.

Parent makes payment using available options.

Bank verifies transaction and confirms success.

System updates student payment status.

Admin reviews and finalizes receipt generation.

 Receipt is issued and saved in the database.

ENTRY CONDITION
Parent is authenticated.

EXIT CONDITION
Payment is processed and receipt is issued.

📌 USE CASE NAME: Academic Report Viewing

PARTICIPATING ACTORS
Student, Parent

FLOW OF EVENTS

Student or Parent logs into the system.

Navigates to “Academic Records.”

Selects subject/term/year.

System displays report card/grade sheet.

User downloads or prints report.

ENTRY CONDITION
Actor logged into the system.
EXIT CONDITION
Report card viewed or downloaded.

📌 USE CASE NAME: Notification Management

PARTICIPATING ACTORS
Admin, Teacher, Parent, Student

FLOW OF EVENTS

Admin or teacher logs in and opens the “Notifications” section.

Creates or schedules a new message (e.g., announcements, fee reminders).

Selects recipients (individuals or groups).

Message is sent via system inbox/email/SMS.

Recipients are notified and can mark as read.

ENTRY CONDITION
Admin/teacher is authenticated.

EXIT CONDITION
Notification sent and acknowledged by recipient.

Would you like this in a formatted Word or PDF file for submission?