PROJECT PROPOSAL
PROJECT NAME:
Offline E-Registration system for school
CLIENT:
The Quaid e Azam Public School Zaida (Swabi)
CLIENT INTRODUCTION:
Peshawar Model School is one of the most well established English medium schools of
Peshawar. It was established in 1971. It is also one of the most known and famous school in the
city currently and it has wide spread branches all along the city as well as in the close district
areas like Mardan and Charsadda. It aims to provide high level education to the children of
Peshawar.
Organization Structure:
PRINCIPLE
VICE PRINCIPLE
ADMINSIT
RATI
ON
STAF
F
SCIENCE
DEPART
MENTS
MATHS
STUDENTS
ENGLISH
ISLAMIAT
URDU
TIME TABLE
PAK
STUDIES
OBJECTIVES:
The following list of objectives is set:
 To develop an offline registration system.
 To facilitate attendance record keeping of students as well as teachers.
 To facilitate various report generation.
 To allow teachers, parents, school community and education bureau officials to view
reports of students.
 To produce a time table.
Scope:
The major scope of the project which emphasizes our project is as follows.
 Keep track of all students and teachers registered in School.
 Keep track of all students in different sections.
 Keep track of various activities that are performed in class on a daily basis. (Assignme nt
checking, Homework Checking, Quiz, Behavior checking)
 Keep track of daily class performances.
 Keep track of student record
PROCESS MODEL
The process model that will be used for the development of this system will be “prototyping”.
The reason for the use of prototyping is that it will make it easy for the developer to understand
the needs of the client once the client runs the prototype.
SYSTEM ANALYSIS
In this section the functional and non-functional requirements of the system are described.
FUNCTIONAL REQUIREMENTS:
The functional requirements are:
 Register a student or teacher.
 Record the attendance of students and teachers.
 Generate various reports.
 Generate timetable.
NON-FUNCTIONAL REQUIREMENTS:
Security requirements are important factors in this system as classified data will be stored in the
database. User validation will be done during login to ensure that the user is valid and the user
only has access to his or her permission data. General users will only have access through the
user interface. The system will have consistent interface formats and buttons sets for all data
entry and viewing formats, and will generate reports that should look like the existing manual
report formats for user friendliness. The system will be easily maintained by the developers or
authorized train person and it shall respond as fast as possible in generating reports and
producing the timetable. Regarding of all this the principal should have access to the software so
that he can view all the record of the students and teachers.
SYSTEM DESIGN:
System designs are grouped into five categories
 Performance
 Dependability
 Maintenance
 End User Criteria
DRAWBACKS AND LIMITATIONS:
DRAWBACKS:
 Too many registrations can be hard to use maintained in the system.
 Duplicating the current work can be a lot of burden.
 The use of the large number of bulky registers for tracing a particular record of a student
is not only a waste of time but also causes inconsistency in data.
LIMITATIONS:
 The current application is limited for only a particular institute according to institute
requirement changes in module.
USE CASE DIAGRAM
Student/teache
r enrolment
Teacher
attendance
Evaluate
teacher
performance
Login
Keep student
attendance
Keep
academic
record
Evaluate
student
performance
Generate
reports
View teacher/
student
performance
SWIMLANE DIAGRAM:
Login
Invalid
Authori
zation
Valid
Register
student/
teacher
Manage
attendance
record
Generate
reports
Generate
time table
Log
out