Professional Documents
Culture Documents
Student Information Menagement System
Student Information Menagement System
Student Information Menagement System
By
NAME ID
Advisor
Instructor Hailu
Date: 08/23/2022
i
Submitted by
Signature Date
Signature Date
Signature Date
Signature Date
Signature Date
Approved by
Department
ii
DEDICATION
We dedicate this project to our dear parents for their moral and financial support: brothers,
sisters, friends, course mates, lecturers, and our supervisor. Inst. Hailu and Moti for their helpful
guidance, suggestions and comments which helped to accomplish this task And to our Almighty
Father in Heaven, glory be unto You forever and ever.
iii
ACKNOWLEDGMENT
First and foremost our most profound gratitude goes to the Almighty God, who enables me to
finalize the project successfully.
Next, our appreciation goes to our Advisor Instructor Hailu for their constructive advice, helpful
guidance, and wise suggestions and comments from the beginning to the completion of the
project.
iv
ABSTRACT
The Student Information Management System (SIMS) provides a simple interface for the
maintenance of student information. It can be used by educational institutes or schools to
maintain the records of students easily. The creation and management of accurate, up-to-date
information regarding a student's academic career are critically important in the school as well as
in colleges. Student information system deals with all kinds of student details, student-related
reports, school details, subject details, curriculum, school session details, placement details, and
other resource-related details too. It tracks all the details of a student from day one to the end of
the course which can be used for all reporting purposes, tracking of attendance, progress in the
course, completed semesters, years, coming semester year curriculum details, exam details,
project or any other assignment details, online interface embedded in the school website. It will
also have faculty details, batch execution details, students’ details in all aspects, and the various
academic notifications to the parent and students updated by the school administration. It also
facilitates us to explore all the activities happening in the college, Different reports and Queries
can be generated based on vast options related to students, batch, course, faculty, exams,
semesters, certification, and even for the entire school.
v
ABBREVIATIONS
JS JavaScript
vi
Table of Contents
Dedicated ......................................................................................................................................III
Acknowledgment .......................................................................................................................... Iv
Abstract ............................................................................................................................................v
Chapter One .....................................................................................................................................1
1. Introduction ................................................................................................................................1
1.1.Background .................................................................................................................2
1.2.Statement Of The Problem ..........................................................................................2
1.3.Objectives ....................................................................................................................3
1.4.1. General Objectives ......................................................................................3
1.4.2. Specific Objectives ....................................................................................3
1.4.Methodology ...............................................................................................................4
1.4.1. Data Collection Method ................................................................................4
1.4.2. Software Development Methodology ...........................................................4
1.5. System Development Tools ........................................................................................5
1.5.1. Front End development tools ..........................................................................5
1.5.2. Back End development tools ..........................................................................6
1.6. Scope ..........................................................................................................................8
1.7. Limitation ...................................................................................................................8
1.8.Significance Of The Project ........................................................................................9
1.9.Feasibility Study ...........................................................................................................9
1.9.1. Technical Feasibility ....................................................................................10
1.9.2. Operational Feasibility .................................................................................10
1.9.3. Economical Study .........................................................................................10
Chapter Two...................................................................................................................................11
2. Literature review ......................................................................................................................11
2.1. Observed Products .....................................................................................................11
Chapter Three.................................................................................................................................13
3. Existing System ......................................................................................................................13
3.1.Description Of The Existing System .........................................................................13
3.2.Major Function Of The Current System ....................................................................13
vii
3.3.Drawback Of The Current System ...........................................................................13
3.4. Business rule of the current system .........................................................................14
Chapter Four ..................................................................................................................................15
4. Proposed System .....................................................................................................................15
4.1. Functional Requirement ...........................................................................................15
4.2.Non-Functional Requirement ....................................................................................16
4.2.1. User Interface ..............................................................................................16
4.2.2. Privacy ..........................................................................................................16
4.2.3. Usability .......................................................................................................16
4.2.4. Workability ..................................................................................................17
4.2.5. Efficiency .....................................................................................................17
4.2.6. Accessibility ................................................................................................17
4.2.7. Portability ....................................................................................................17
4.2.8. Concurrency ...............................................................................................17
4.2.9. Maintainability ...........................................................................................17
4.2.10. Error Handling ..........................................................................................18
4.2.11. Documentation ..........................................................................................18
4.2.12. User friendly ................................................................................................18
4.2.13. Security .....................................................................................................18
4.2.14. Availability ...............................................................................................18
4.2.15. Reliability......................................................................................................19
4.2.16. Correctness ................................................................................................19
4.2.17. Modification ..............................................................................................19
4.2.18. Backup .......................................................................................................19
4.2.19. Hardware Consideration ..............................................................................19
4.2.20. Software Consideration .................................................................................20
4.2.21. Performance consideration ...........................................................................20
4.3.System model .............................................................................................................20
4.3.1. Use case model ............................................................................................20
4.3.2. actor description ..........................................................................................22
4.3.3. Use case description .....................................................................................23
viii
4.4.Object Model .............................................................................................................31
4.4.1. Data dictionary .............................................................................................31
4.4.2. Sequence diagram ........................................................................................35
4.4.3. Activity diagram ..........................................................................................45
4.4.4. State diagram ...............................................................................................50
4.4.5. Data Class diagram .......................................................................................52
4.4.6. Deployment diagram ....................................................................................53
Chapter five ....................................................................................................................................54
5. System design .........................................................................................................................54
5.1.DFD ............................................................................................................................54
5.2.Purpose .......................................................................................................................54
5.3..Design goal ................................................................................................................55
5.3.1. performance ..................................................................................................55
5.3.2. Maintenance ..................................................................................................55
5.3.3. End user ........................................................................................................55
5.3.4. Priorities of Design goal ...............................................................................55
Chapter Six.....................................................................................................................................57
6. Implementation ......................................................................................................................57
6.1.High level design .......................................................................................................58
6.2.Process view ..............................................................................................................58
6.3.Development view .....................................................................................................59
6.3.1. Subsystem Decomposition ............................................................................59
6.3.2. Subsystem description ..................................................................................59
6.4.Testing ........................................................................................................................60
6.4.1. Unit testing ....................................................................................................60
6.4.2. Integration testing .........................................................................................60
6.5.physical view ..............................................................................................................60
6.6.Persistent data management .......................................................................................61
6.6.1. Data schema view ........................................................................................61
6.6.2. Mapping class to table ..................................................................................70
6.6.3. Relationship mapping ..................................................................................70
6.7.Access control ............................................................................................................71
ix
6.7.1. User interface mode ......................................................................................72
Chapter Seven ................................................................................................................................82
7. Conclusion and Recommendation ........................................................................................82
7.1.conclusion ..................................................................................................................82
7.2. Recommendation ....................................................................................................82
References ......................................................................................................................................83
annex I ...........................................................................................................................................84
Some algorithm ..............................................................................................................................84
annex II .........................................................................................................................................84
Questioner .....................................................................................................................................84
annex III ........................................................................................................................................85
User Interface Usability Testing Checklist ....................................................................................85
x
List of Table
Table 4.1 use case for create account ............................................................................................23
Table 4.2 use case description for class assigns ............................................................................24
Table 4.3 use case description for assign unit leader ....................................................................25
Table 4.4 use case description for generate score report ..............................................................26
Table 4.5 use case description for record student .........................................................................27
Table 4.6 use case description for generate student result report card ..........................................28
Table 4.7 use case description for record attendance ....................................................................29
Table 4.8 use case description for view report ..............................................................................30
Table 4.9 data dictionary for parent table ......................................................................................31
Table 4.10 data dictionary for subject table ..................................................................................31
Table 4.11 data dictionary for section table ...................................................................................31
Table 4.12 data dictionary for student table ..................................................................................32
Table 4.13 data dictionary for teacher table ..................................................................................33
Table 4.14 data dictionary for attendance table .............................................................................34
Table 4.15 data dictionary for unite leader table ..........................................................................34
Table 4.16 data dictionary for user table .......................................................................................34
Table 6.1 data schema view for attendance ..................................................................................62
Table 6.2 data schema view for event ..........................................................................................62
Table 6.3 data schema view for parent .........................................................................................63
Table 6.4 data schema view for score...........................................................................................63
Table 6.5 data schema view for section ........................................................................................65
Table 6.6 data schema view for student .......................................................................................65
Table 6.7 data schema view for subject .......................................................................................67
Table 6.8 data schema view for teacher........................................................................................67
Table 6.9 data schema view for unit-leader .................................................................................67
Table 6.10 data schema view for users ........................................................................................67
Table 6.11 access control ...............................................................................................................71
xi
List of Figure
Figure 4.1. uscase Moadal for student infotmation management system .....................................21
Figure 4.6 sequence diagram for manage student and teacher ......................................................39
xii
Figure 5.1 DFD .............................................................................................................................54
xiii
CHAPTER ONE
INTRODUCTION
1.1. Introduction
Management of students and class information is very important because it is the foundation of a
good education process. If this process is provided manually, there are big issues to handle a big
number of students, teachers, and classes. To update the class information or to make changes in
the schedule you should make a lot of work.
This proposal automates the school information management system. The system is Web-based
(thin client).
Moving on, this SIMS project in PHP focuses mainly on dealing with students and teachers
regarding their pieces of information, attendance, course, and other information. Also, the system
displays all the available data such as total students, teachers, attendance, etc. The project is
divided into five categories: Admin, Student, Teacher, Record office, and Parents Login. In an
overview of this web app, the admin has full control of the system, and he/she has full access to
the system. An admin can manage students, teachers, and parents' accounts.
All the reports, as well as the attendance sheet, can also be seen by the admin and users'
accounts. After entering for attendance of a particular teacher, the system displays his/her
records under the attendance section with a date. The admin of the system can create an update,
and delete, teachers' and student information. Besides, the system also provides a feature to
register parents' accounts of each and every student. Under all these records, the user has to
provide a photo of the identity of the students as well as teachers.
The web application takes most of the activities such as online student registering, transcript and
report card generation, attendance recording by the homeroom teachers and reporting for school,
parents interacting with the school, and producing the schedule.
1
1.2. Background
Abdi Boru primary and secondary School was built in 1999 and started teaching in September
2000 with 35 children in 17 of the 1st grade and a total of 52 students. When the school started, it
employed 9 teachers and 5 administrative staff for a total of 14 staff.
This school is currently teaching 690 students in 2014. In order for the teaching and learning
process to be carried out properly, the school has 17 kindergarten teachers and 20 regular
education teachers from 1st to 11th grade. It has completed the preparation to continue with 12th
grade in the next year 2015.
According to the vision set by the school, in 2023, the school has designed a plan to be one of the
equivalent schools in Adama city. In the same year, there is a plan to raise the level from 2nd
level to college.
To help promote students' achievement and success, schools must have access to complete,
accurate, and timely information about students. One of the benefits of automated SIMS is that
the student record systems simplify the retrieval of the required information and is a great
instrument for school improvement by taking measures from the information acquired.
• Scheduling classes and subjects which wastes manpower and much time
unnecessarily.
2
• Retrieving records of students' information difficult task and the manual
system
• Wastage of material
• Data redundancy
1.4. Objective
The study's main objective is to develop a web-based system for Student Information
Management System to provide a more efficient and productive.
To attain the general objective, the following list of specific objectives is see
3
1.5. Methodology
1.5.1. Data Collection Method
Observation
An observation since it involves an analyst getting involved in some of the activities of the
interview will be carried out on the operation of the current system and formulate questions and
conclusions based on the observation. The observation carried out during operation hours.
Questionnaires
Questionnaires will also be used and the responses got from them were that very few employees
were computer literate and they were at ease with the new system since it was going to make
work easier for the very busy departments.
We chose questionnaires because we can get different ideas about the project from different
people at the same time. Generally, this method is used for saving time.
4
On the other side, it takes very strict management to complete such products and there is a risk of
running the spiral in an indefinite loop. So, the discipline of change and the extent of taking
change requests is very important to develop and deploy the product successfully Figure spiral
methodologies.
The front-end manages everything that users virtually see first in their browser or application.
Front-end developers are responsible for the look and feel of a site, several front-end designing
tools are available such as HTML, CSS and JavaScript will be discussed here in detail as the
preferred ones.
HTML:- is an acronym for Hypertext Mark-up Language, which is the predominant mark-up
language for web pages. HTML is the basic building - block of a webpage. HTML elements
form the building blocks of all websites. HTML allows images and objects to be embedded and
can be used to create interactive forms. It provides a means to create structured documents by
denoting structural semantics for text such as headings, paragraphs, lists, links, quotes, and other
items. It can embed scripts in a language such as PHP which affects the behavior of HTML
Webpages (Somerset pub, 2008).
It is predominant mark-up language for web pages
It supports more scripting language
It is easy to understand
CSS: is an acronym for Cascading Style Sheets, a language that accompanies HTML, and
defines the style of a website’s content, such as layout, colors, fonts, etc.
5
Bootstrap: is a free, open source front-end development framework for the creation of websites
and web apps. Designed to enable responsive development of mobile-first websites, Bootstrap
provides a collection of syntax for template designs.
JavaScript: This is a programming language used for more interactive elements like drop-down
menus, modal windows, and contact forms.
jQuery; is a fast, small, and feature-rich JavaScript library. It makes things like HTML
document traversal and manipulation, event handling, animation, and Ajax much simpler with an
easy-to-use API that works across a multitude of browsers. With a combination of versatility and
extensibility, jQuery has changed the way that millions of people write JavaScript.
Font Awesome: is the world's most popular icon set and toolkit.
The back-end development refers to the server side of an application and everything that
communicates between the database and the browser. Although lots of database programming
languages exist such as PHP, MySQL, SQLite, MSSQL, and so forth, MYSQL is selected to be
used as a database development tool for the new system.
6
The script runs, and when it's finished it usually sends an HTML page to the Web
browser, which the visitor then sees on their screen.
PHP was developed so it could be inserted directly into HTML documents
MySQL: is a database constructed to enable PHP and Apache to work together to access and
display data in a readable format to a browser. It is a structured query language (SQL) server
designed for processing complex queries. As a relational database system, MySQL allows many
different tables from a particular database to be joined together for maximum speed and
efficiency.
• Handles large database. MySQL with some database that contains 50,000,000 records and
users MySQL with 60,000 tables and about 5,000,000,000 rows.
The Web Server: As the system will be web-based, research must be conducted into the various
available web servers. The web server will host the system and database and will be directly
connected to the projector and network, allowing clients to login and manage its content. Several
web servers exist such as Apache HTTP Server, Microsoft's Internet Information Services (IIS),
Lighted, Sun Java System Web Server, etc. But the main two web servers are Apache and
Microsoft's web server implementation IIS. The use of Apache had been suggested as it is a free
or open source software that can be installed on many different OS platforms such as Windows,
Unix, Mac OS, and more, and of course, offered superior security and is the most popular web
server.
7
1.7. Scope of the project
This system is designed to be fully user-friendly and efficient for a wide range of different tasks.
These tasks may include things like:
View data about certain students and teachers can edit it by adding or removing
a student
The parent communicates with the SIMS to see the attendance, academic
planning, and track student behavior.
The system organization does not have any interaction with other organization
system.
The system does not have any physical control mechanism.
8
1.9. Significance of the project
The Significance of any new technology is to make people's life easier. This project is a database
used to manage the student and allows the administrators to register the daily required
information of Students and Teachers.
Administrators and users' information are making effective decisions. The decisions are more
accurate, relevant and timely the information stored or processed is more effective.
9
1.10.1. Technical feasibility
The study was to measure the predictability of the technical solution and whether the
organization possesses the necessary technology to solve the problem as projected. It also
measured whether there is enough technical expertise in the organization to develop the
suggested solution. The possibility that the organization has or can procure the necessary
resources will also be checked. It is found out that the existing manual system would not be used
hence new hardware and relevant software is to be acquired. Manpower was lacking in the
organization which was also to be acquired.
This will be conducted to find how cost effective the system to be implemented will be. The
following questions are expected to be addressed under Economic feasibility study.
a) What benefits will the candidate system provide compared to the current system?
b) How much will the candidate system cost
The feasibility is carried out to measure how well the new system will work in the organization
and the willingness and desire of the users and how they feel about the system. I expect the
stakeholders to be interested in a system that is easy to operate, makes few or no errors, desired
information, and falls within the objectives of the organization.
10
CHAPTER TWO
LITERATURE REVIEW
Automated SMS plays a great role in simplifying the job of employees at the school and
satisfying the need of customers and stakeholders of the school. Even though no documentation
is found in Ethiopia to be reviewed, products have been observed at some schools to help
understand the problem of managing schools and handling school data. This chapter reviews
these products.
Another product that is in use is the transcript generator system. The transcript generator system
at Menelik II Preparatory School generates the official transcript of students. To generate a
student result report card, the recording officer enters the student information along with the
grade marks for the grades completed per year and per semester. Then the system generates the
required official transcript. Currently, the school is using the system to generate official
transcripts even though the data entry format has unnecessarily many fields which are not
applicable for the record office but can be used for continuous assessment by the course teacher.
All the record of students’ information, staff, subjects, and Mark list students’ roster is
11
maintained manually in paperback which is an overhead for the management staff. It is a very
time-consuming system that is not efficient for searching, updating, and maintaining
manuscripts. The main objective of the project is to make it easy for the school administrator to
retrieve and store all information related to students and staff, which is to reduce the
consumption of time maintaining the records of the school. Data collection methods by using
interviews and observation gather beneficial information for the developed system. There is no
software development methodology. System development tools back end design tool Microsoft
access software database system will be used in developing and managing the database at the
backend and for database access manipulation, and storage records. Front end design tool used
visual studio 6.0 is very com for the table to create a nice form interface for the end users.
Use for System module use case diagram. For Dynamic model sequence diagram, Activate
diagram, class diagram, state chart diagram, and component diagram. In the architecture of the
proposed System, the most popular client-server architecture is the two-tier and three-tier
architecture. Access Control and Security is password protection and simply proceeded to
prevent unauthorized access provided to the users. The system allows the user to enter the system
only through the proper user name and password also eliminating database injection by limiting
of characters on the user name and password as well as the number of times a user can enter
his/her password wrongly. The conclusion is proposed enlistment system will be a big
improvement over the existing manual system such that it provides the students with faster
service during the registration period. The system will be a substantial improvement over the
current system for students and staff. The recommendation of the system is to improve the
seating management facility then it well is more efficient in a real-time system, adding
certificates, add mark entry, and exam scheduling facility then it will be more efficient and
generation of results and rank list faculty then it will be more efficient.
12
CHAPTER THREE
EXISTING SYSTEM
In school, records are being kept manually on papers for both the students and the teacher which
are highly unsecured and can be destroyed or altered easily. Furthermore, all the processes of
those records are also highly time-consuming. Likewise, the result computation and compilation
are very tedious and cumbersome task that is associated with a lot of human errors.
All the records of the student, teacher, subject, exam, and the result are maintained manually in
books which are overhead for the management record office. It is very time-consuming so the
existing system is not so efficient for searching, Updating, and maintaining the record.
Registrations are one activity of the enrolment process which enables to list of the subjects with
the corresponding unit and schedule. Student registration is an enrolment tool offering an
extensive range of subjects and schedules.
The primary reason for the development of the registration process is to develop the enrolment
process.
• Do not sufficiently produce the required reports to allow parents to view the status of
their children and reports for officials of school to help them participate in decision
making,
13
• Genrate timetable manuly
This project work tries to fill the gap by automating the various activities at schools. It tries to
satisfy user needs and simplify the works of administrators, record officers, and teachers. With
automated SIMS parents can easily interact with the school community to follow up on their
children's achievements and play their role in the school development processes.
#Rule 2. Add new student compliance without full document can’t register a system
#Rule 4. Attendance recode only one time per day for one section
14
CHAPTER FOUR
PROPOSED SYSTEM
In this chapter the functional and non-functional requirements of the system are described and
modeled using UML models.
A UML diagram is a diagram based on the UML (Unified Modeling Language) with the purpose
of visually representing a system along with its main actors, roles, actions, artifacts or classes,
in order to better understand, alter, maintain, or document information about the system.
Student information management system aims to improve the efficiency of student information
management, and the main function is managing and maintaining information. The administrator
and students are two major functional requirements in the system. The functional requirements of
the system are:
15
4.2. Non-functional requirement
In this system, the authentication of the user is an important factor. In this system, user
authentication will be done by login by user name and password and classified by user type.
Users will get access to the system as permissions are classified for that type of user.
The system should provide an easy-to-use graphical interface so users can easily learn how they
use the system. So, little knowledge of how Web pages can be accessed is required for the user to
use.
The SIMS must have a simple user interface that makes it user-friendly and understandable.
16
4.2.4. WORKABILITY
Our system is suitable for a variety of customers or users such as reporters, officers, and the
society of the organization. It should be accurate in performing its functions and secured enough
from intruders and attacks by external users. Moreover, it must support interoperability with
other subsystems and components, and it should be complete i.e. it should be fully functional in
terms of providing all the functions expected to perform.
4.2.5. EFFICIENCY
This system will be efficient and the response time should be fast and minimally reduced since it
is capable of running on minimum hardware requirements and with the accustomed operating
systems.
4.2.6. ACCESSIBILITY
The system should be accessible. Since the system will be a Web-based application that can be
installed and work on any computer.
4.2.7. PORTABILITY
This system is portable in running on different platforms, adaptable with other systems,
installable on different machines architectures, and replaceable if the need arises.
4.2.8. CONCURRENCY
Our system supports multiple accesses of users such as teachers, students and administrators, and
so on. It should give service to multiple users concurrently.
4.2.9. MAINTAINABILITY
The system should be maintainable. Because the interaction between subsystems will be loosely
coupled and the interaction between classes and operations will be highly cohered, changes made
to our systems such as adding other subjects and functionality shouldn't affect the existing
functionality of the system.
17
4.2.10. ERROR HANDLING
Each error that may occur in the system will be handled accordingly to reduce the amount of
failure. When the error (for example invalid input) can be made by the users, the system should
answer these errors accord wrong input If the electricity goes on the main server then the system
should be out. For this we should use a Power supply to avoid this problem if the internet
connection goes on the main server, the problem must be solved fast.
4.2.11. DOCUMENTATION
The user manual should be developed to let users use the system easily.
After the project, every activity of the entire development, design, and another process will
be documented for future reference.
There will also be a documentation of implementation for maintenance during web
application failure.
4.2.12. USER FRIENDLY
the system is very interactive
4.2.13. SECURITY
To prevent unauthorized access to the web site Administrative page, a role-based security
method that allows the authorized users to have their username and password should be
developed.
Only the authorized users with the correct login and password should be allowed to
access and manipulate the data kept in the database.
To send a request the user must have registered in the system. But, without registering,
the system does not allow to users for requesting.
Let's say if login teacher and change the URL to admin URL admin page protect redirects
to the teacher
4.2.14. AVAILABILITY
The system is available whenever the internet connection is available.
The probability of the system being unavailable to the customer should be in times
when there is system maintenance and this task should be conducted.
Also, the systems work in multiple web browsers like (Chrome, Mozilla, Opera, and
Microsoft edge).
18
4.2.15. RELIABILITY
The system should be reliable; the system should perform all its services and function accurately
and on time.
4.2.16. CORRECTNESS
This system should be operating correctly for the user to retrieve the desired outputs.
To ensure this system quality, numerous testing and trial-and-error are carried out.
4.2.17. MODIFICATION
This system should be easily modifiable to meet change requirements, rectify a deficiency or
correct error, change the organization structure and adapt to the change in technology and
environment.
4.2.18. BACKUP
We will take a backup in our system database. To enable the administrator and the user to access
the data from our system.
The system should provide a backup and restore mechanism for solving accidental
failure
If the information in the database is changed, the system should be back up. Back up
will be saved in the backup server. The system administrator should be responsible for
backup, system installation, and system maintenance.
19
4.2.20. Software consideration
Web browser
Operating system
Database server (xampp)
PHP 7.3 and above
The system should respond fast with high throughput, i.e. it should perform the task quickly
possible as possible such as generating reports and receiving, taking attendance, creating
sections, and also view school information in real-time action on the system
To produce a model of the system which is correct, complete, and consistent we need to
construct an analysis model which focuses on structuring and formalizing the requirements of the
system. The analysis model contains three models: functional, object, and dynamic models. The
functional model can be described by using case diagrams. Class diagrams describe the object
model. A dynamic model can also be described in terms of sequence, state chart, and activity
diagrams. For this project, we have described the analysis model in terms of the functional model
and dynamic models using use case and sequence diagrams.
Use cases of the system are identified to be “Create account”, “Assign unit leader”, “and Create
section”, “View and update record”, and “User management” by admin. Use case of teacher
“Enter assessment scores”, “Update student score”, “Upload Martial” and “Record student
Attendance”. Use case of student and parent “Download Martial”, “View Attendance”, “View
Exam schedule”, “View score”, and “View and update”. Use case of Recorder Office “Generate
score report card”, “Generate transcript”, and “Record student and teacher” The diagram
depicted in Figure 3.1 shows the use case diagram of the system.
20
uc Use Case Model
student
Genrate Exam
Schedule
«include»
Admin «include»
«include»
«include» View Score
Parent
Create User Account
«include»
«include»
«include»
«include»
«include»
«include»
«include»
Teacher
View Report
Upload Material
View Exam Schedule
Genrate transcript
21
4.3.2. Actor Description
Description: A Record Officer is a person who registers a student, input, update student data and
produce a transcript and student result report card.
Name: Teacher
Description: A Teacher is a teacher assigned by the admin on the system to each class of students
to follow the students closely. He/she has the responsibility of recording the attendance of
students and score submission.
Name: Parent
Description: A Parent is a person who is registered as parent of the student and responsible to
follow the student in close contact with the school. He/she can view the status of the student such
as attendance and result/performance of the student online.
Name: Student
Description: A Student is a person recorded by the recording officer who views his attendance
report, and score, enters homework, and views section timely schedule
Name: Admin
Description: Admin is a person who is responsible to produce the schedule for each teacher,
assigning a unit leader for each section, and the classroom by providing the necessary
parameters.
22
4.3.3. Use case description
Flow of Event:
(1) Admin wants to create account
(2) Admin logs in
(3) when student or teacher register embed
create account by user type
(4) then display the user ID, give the id for the
user
(5) use case end
23
Name: Class Assign
Actors: Admin
Description: create a section for an assigned student in this
section
Precondition: There should be teachers and students for
creating section
Flow of Event:
(1) Admin wants to Class assign
(2) Admin logs in
(3) Admin Class assign for each section
assigned by letter or number filling a form and
then submitting it
(4) then display section with a letter
(5) use case end
Alternative Flow of Events
Alternative flow A: if not assign a letter
A4. The system can display only section
A5. Use case end
Alternative Flow of Events
Alternative flow A: if section exist
A4. Display section already existes
A5. Use case end
Table 4.2 use case description for class assigns
24
Name: Assign unit leader
Actors: Admin
Description: To assign unit leader for classe/section
Postcondition Registerd techer and ctreated section
Precondition: There should be subject teachers and classes
for which the unit leader is to be assign
25
Name: Generate Score Report
Actors: Record Officer
Description: To produce a report card for students per
semester
Precondition: A student must have complete grade marks in
all subjects of the semester
Flow of Events:
(1) The record officer logs in and selects the
class/section to which the student belongs
(2) The record officer searches the student
from the class/section based on the search
criteria
defined
(3) The system processes the report card
(4) System displays and print the result
5) Use case ends
Alternative flow B:
The student is incomplete at least in one
subject
B3. The system can not generate the report
card.
B4. Use case ends
26
Name: Register Student
Actors: Record Officer
Description : To register someone as a student of the
school
Precondition: A student has to be eligible (has to be from
the pre-specified junior schools that the
school will accept)
Flow of Event:
(1) student wants to be registered as a student
of the school
(2) Record officer verifies that the student is
eligible
(3) Registration form will be given to the
student
(4) The student completes the registration
form that contains student’s full name,
address,
parent name, emergency person names and
addresses and other detail information.
(5) RecordOfficer of the school checks
whether the contents of the registration form
is
properly completed
(6) RecordOfficer fills and submits the form
to the system
(7) System registers
(8) Use case ends
27
Name: Generate student result report card
Actors: Record Officer
Description: To produce transcript based on the request of
a student
Precondition: A student must have completed at least a
semester to have grade report
Flow of Event:
(1) A student wants to get transcript
(2) The record officer logs in and searches
the students record from the database based
on the
search criteria
(3) The system processes the transcript
(4) System displays and print the result
(5) Use case ends
Table 4.6 use case description for generate student result report card
28
Name: Record Attendance
Actors: Home Room Teacher
Description: To record attendance of students in each
school day
Precondition: A home room teacher must login as the home
room teacher of the class to record attendance
Flow of Event: (1) A home room teacher wants to record
absentees from the class
(2) The home room teacher fills in the
attendance slip in the class room
(3) Having the attendance slip the home room
teacher logs in to record
(4) HomeRoomTeacher records absentees and
submits
(5) System acknowledges
(6) Use case ends
29
Name: View Report
Actors: Parent
Description: To view the status of a student
Precondition: A parent must be recorded in the system as
parent of the student
Flow of Event:
(1) A parent wants to view status of his/her
student
(2) Parent logs in to the system supplying
user name and password
(3) System displays a form for search criteria
for a student
(4) Parent fills in the form and submit
(5) Parent selects to view the required report
(6) System displays the appropriate report
(7) Use case ends
30
4.4. Object Model
In UML models, objects are model elements that represent instances of a class or of classes. You
can add objects to your model to represent concrete and prototypical instances. A concrete
instance represents an actual person or thing in the real world.
31
No Name Description Data type Size
1 Std_id User’s unique identifier Varchar 255
2 P_id Parent unique identifier Varchar 50
3 Fname Student first name Varchar 255
4 Mname Student father name Varchar 255
5 Lanme Student grand-father name Varchar 255
6 Full_name Varchar 50
7 Sex Student gender Varchar 255
8 phone Student education level Varchar 255
9 Bdate Student date of birth Date time 255
10 bplace Student birth place Date time 255
11 Age Student age Varchar 255
12 Image Student image Varchar 1000
13 e_call Student emergency call Varchar 255
14 e_phone Student emergency phone number Varchar 255
15 Grade Student grade level Varchar 255
16 Mother name Student mother name Varchar 255
17 Region Student address Varchar 255
18 Zone Student address Varchar 255
19 Wereda Student address Varchar 255
20 kebele Student address Varchar 255
21 Nationality varchar 255
22 Date student registered date on system Date time 0000-00-00
Table 4.12 data dictionary for student table
32
No Name Description Data type Size
1 U_id User’s unique identifier Varchar 50
2 Fname Teacher first name Varchar 50
3 Mname Teacher father name Varchar 50
4 Lanme Teacher grand-father name Varchar 50
5 Full_name Teacher full name Varchar 50
6 Bdate Teacher date of birth Date time 50
7 bplace Teacher birth place Date time 50
8 e_lavel Teacher education level Varchar 50
9 Sex Teacher gender Varchar 50
10 Email Teacher email address Varchar 50
11 Unit_leader Assigned section Varchar 50
12 Gc_year Teacher graduate year Varchar 50
13 Gc_university Teacher graduate university Varchar 50
14 phone Teacher phone number Varchar 50
15 Region Teacher address Varchar 50
16 Zone Teacher address Varchar 50
17 Wereda Teacher address Varchar 50
18 kebele Teacher address Varchar 50
19 Nationality var 50
20 Doc Teacher tempo copy document file Varchar 50
21 Sub_mater Teacher field Varchar 50
22 Rig_date Teacher registered date on system Time date 50
23 Teach_id Teacher id Varchar 50
Table 4.13 data dictionary for teacher table
33
No Name Description Data type Size
1 std_id Varchar 50
2 Full name Varchar 50
3 status Varchar 50
4 Section Varchar 50
5 Sex Varchar 50
6 Age Varchar 50
7 Date Time date 50
Table 4.14 data dictionary for attendance table
34
4.4.2. Sequence diagram
Sequence diagrams show the interaction between participating objects in a given use case. They
are helpful to identify the missing objects that are not identified in the analysis object model. To
see the interaction between objects, the following describe the sequence diagram of each
identified use cases.
In Figure 4.2 below, once the user has activated the registration module by interacting with the
boundary object “Registration Button” button, the control object named “Registration Control”
manages the activities involved in “register Student” use case. First the “Registration Control”
creates registration form which will be filled by the secretary and submitted. The registration
control sends the record to a persistent storage.
35
Figure 4.3 sequence diagram for enter assement score
36
sd Update Score
Login Controller Update Scores Updatet Scores Updatet Scores Database Server
Form Controller
Home Room Teache
Invalide()
Valide()
Create()
:Select Student
:Select Student
:Acknowledgment
Update Success()
37
sd create leader
Login Controller Assign Unit Leader Assign Unit Leader Assign Unit Leader Database Server
Form Controller
Admin
Invalde()
Valide()
Click Assign Unit Leader Button()
Submit()
Success()
:Success Message
:Acknowldgment
38
sd Manage Student and Teacher
Login Controller View Record Info Record info Form Score Report Database server
Button Controller
Record office
Invalide()
Valide()
Get Student or
Teacher()
:Student or Teacher info
39
sd Create Account
Login Controller Create Account Create Account Create Account Database Server
Button Form Controller
Admin
Invalide()
Valide()
Submit()
:Display User ID
Create Account()
40
sd recode Student and Teacher
Login Controller Record Student Record Student Record Student Database Server
Button Form Controller
Record Office
Requiest Login()
Invalide()
Invalide()
Submit()
Validate()
Create Success()
:Acknowledgment
41
sd Genrate transcript
Login Controller Genrate Transcript Genrate Transcript Genrate Transcript Database Server
Button Form Controller
Record Office
Requiest Login()
Invalide()
Valide()
Submit()
Invalide()
Validte()
:Genrate Transcript
42
Figure 4.10 sequence diagram: greate score report
43
Figure 4.11 sequence diagram: view student status
sd v iew score
Login Controller Generate Score Score Report Form Score Report Database server
Report Button Controller
Student
Requiest Login()
Valide()
Create Form()
:Student Score
44
4.4.3. Activity diagram
Describe dynamic aspects of the system. It is basically a flow chart to represent the flow form
one activity to another activity. The activity can be described as an operation of the system. So
the control flow is drawn from one operation to another.
act Activ e
Start
Invalide
Valide
Valide Valide
Logout
Stop
45
act teacher
Valide Invalide
Record student
Attendance Submit scores
Upload Matrial Update scores
Invalide
Attendance controller
Valide
Logout
Stop
46
act record off
Invalide
Valide
Create User
View and update
Account Invalide
record Invalide
Check
Check Form Score
Fill
Valide
Logout
Stop
47
act student
Inval i de
Val i de
Logout
Stop
48
act Parent
Start
Inval i de
Val i de
View Studebt
View Score View and update Report
Personal Profile
Logout
Stop
49
4.4.4. State diagram
stm login
Start
Login
[Inval i de]
Check
[Val i de]
Dashboard
Final
Login
Start
Dashboard
Assign unit
Leader
fill form
[Inval i de]
Check
[Val i de]
Apply
Final
Login
Start
Dashboard
Record Student
Attendance
[Inval i d]
Check
[Val i de]
Apply
Final
51
4.4.5. Class Diagram
To illustrate the relationships and source code dependencies among classes, class diagram was
developed. In this context, the class defines the methods and variables in an object, which is a
specific entity in a program or the unit of code representing that entity.
Student
Section
Teacher - adress: int
- sec_id: int
- age: int
- section: int
- address: int - birth place: int
- status: int
- birth place: int - dateof birth: int
- subject: int
- date of birth: int - emergency call: int
- edu level: int + SectionDetail() - emergency phone: int
- email: int - fname: int
- fname: int - full_name: int
- gc unversity: int schedule - image: int
- image: int - day: varchar - lname: int
- lname: int Subj ect - mname: int
- section: varchar
- mname: int - nationality: int
- Subject: int - subject: varchar
- phone: int - tech_id: varchar - P_id: int
- subject: int + StoreSubject(): int - time slot: varchar - parent_name: int
- tech_id: int - registed date: int
- unit leader: int + Section schdule() - section: int
- sex: int
+ TeacherDetail() + std_id: varchar
+ StudentDetail(): int
Attedance Parent
Score
- by who: int # email: varchar
- by who: int
- date: int # full_name: varchar
- date: int
- section: int + p_id: varchar
- point: int
- status: int # password: varchar
- section: int
- std_id: int # std_id: varchar
- std_id: int
+ student attendance(): int - subject: int + ParentDetail()
- update by who: int
- update date: int
52
4.4.6. Deployment Diagram
T cp/Ip
Databse Server
Database
53
CHAPTER FIVE
SYSTEM DESIGN
5. System design
5.1. Data Flow Diagram (DFD)
The Data Flow Diagram (DFD) is a graphical representation of the "flow" of the student
information management system. The data flow diagram can also be used for the visualization
of Data Processing. DFD shows the interaction between the system and outside entities. This
context-level DFD is then "exploded" to show more detail of the system being modeled. A
DFD represents the flow of data Movement of data through the different transformations or
processes in the system is shown in the Data Flow Diagram.
Administrator Teacher
Student Information
Managment System
Parent
54
5.2. Purpose
Teacher Level
Student Level
• The Software includes:-
Maintaining Teacher & Student details.
Providing Teacher General Information.
Providing Student General Information & Student’s all
Exam Result.
5.3. Design Goals
Design goals describe the qualities of the system that developers should optimize. Such goals are
normally derived from the non-functional requirements of the system.
• Performance
• Dependability
• Maintenance
5.3.1. Performance
The part of the system to be used for the record office should have a fast response time (real
time) with maximum throughput. Furthermore, the system should not be taking up too much
space in memory. The record officer has chosen fast response time over throughput and hence
the system should try to be more interactive. In the case of the timetabling subsystem, the system
should be more reliable in order to satisfy the constraints than fast response time.
55
5.3.2. Dependability
The school needs the system to be highly dependable as it is expected to be used by non-IT
professionals. The system should be robust and fault tolerant. Furthermore, as the system is
handling sensitive data of the school, high emphasis should be given with regards to security, as
there are subsystems to be accessed through web.
5.3.3. Maintenance
The system should be easily extensible to add new functionalities at a later stage. It should also
be easily modifiable to make changes to the features and functionalities.
Usability is the extent to which a product can be used by specified users to achieve specified
goals with effectiveness, efficiency and satisfaction in a specified context of use. From the end
users’ perspective, the system should be designed in such a way that it is easy to learn and use,
efficient and having few errors if any.
The trade-off is inevitable in trying to achieve a particular design goal. One best case is the issue
of security versus response time. Checking User-Id or username and Password before a member
can enter the SIMS creates a response time problem overhead. The other case is the issue of
response time versus quality. There is some amount of time taken by the system to generate the
roster. So, the user has to wait for a little after telling the system to generate the roster and get the
result to get a quality roster.
56
CHAPTER SIX
IMPLEMENTATION
6. Architecture
The proposed system is expected to replace the existing manual system by an automated system
in all facets. It is mainly based on the system Analysis document (chapter 5). The architecture
used for the system is a 3 tier Client/Server Architecture where a client can use Internet browsers
to access the online report provided by the system within the local area network of the school or
anywhere using the Internet. Figure 6.1 shows the architecture of the proposed system. The data
tier maintains the applications data such as student data, teacher data, timetable data etc. It stores
these data in a relational database management system (RDBMS).
The middle tier (web/application server) implements the business logic, controller logic and
presentation logic to control the interaction between the application’s clients and data. The
controller logic processes client requests such as requests to view student’s result, to record
attendance or to retrieve data from the database. Business rules enforced by the business logic
dictate how clients can and cannot access application data and how applications process data.
A web server is a program that runs on a network server (computer) to respond to HTTP
requests. The most commonly used web servers are Internet Information Server (IIS) and
Apache. The web server used in this system is IIS. HTTP is used to transfer data across an
Intranet or the Internet. It is the standard protocol for moving data across the internet. The client
tier is the applications user interface containing data entry forms and client-side applications. It
displays data to the user. Users interact directly with the application through user interface. The
client tier interacts with the web/application server to make requests and to retrieve data from the
database. It then displays to the user the data retrieved from the server.
57
Figure 6.1 three tier architecture
Process view of work is defined as the understanding that work can be viewed as a "process" that
has inputs, steps, and output(s) and that interfaces with other processes within an organization
58
6.3. Development view
6.3.1. Subsystem Decomposition
Record student attendance
student score
student report card
Class assign
Personal profile
Assign unit leader
User management
6.3.2. Subsystem description
Attendance
Personal profile
User Address
User Authentication/Change Password
User profile
Student score
submit student score
view score whit subject
update score
Registration
59
Student result report card
View past score earned from each subject taken up to the last completed
semester.
View and Print non-official records of score
6.4. Testing
Testing is the process of executing a program or system with the intent of finding errors”. Simply
testing involves the processes of verifying and validating the program or application. This is
performed at the start of the system by the test team. It’s called black box testing. The system is
tested in a controlled environment. The purpose of system testing is to validate an application’s
accuracy and completeness in performing the function as designed. The system is tested through
the following testing approaches.
One of the major tasks in system design deals with hardware/software mapping which deals with
which components would be part in which hardware and so on. The SIMS is a broad system that
performs many functions as described in chapter 3. It consists of web-based system used by
homeroom teachers to record attendance. The web-based system also assists parents and officials
60
to get or view status and report on students’ achievement and progress. The system assists the
record officer to generate student result report card. So, the web-based part is expected to run on
a networked environment on different Operating System platforms. The client/server architecture
of the system enables different clients to connect to the server remotely through Internet
connection.
Persistent data management deals with how the persistent data (file, database, etc) are stored and
managed and it outlives a single execution of the system. Information related to student basic
information, student’s attendance and student score, the section timely schedule produced and
other related information are persistent data and hence stored on a database management system.
This allows all the programs that operate on the SIMS data to do consistently. Moreover, storing
data in a database enables the system to perform complex queries on a large data set. The schools
register students every year in thousands per grade level. For complex queries over attributes and
large dataset Microsoft SQL Server is implemented, which is a Relational Database Management
System.
A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are associated.
It formulates all the constraints that are to be applied on the data.
61
Column Type Attributes Null Default Extra Links to Comment
s
std_id varchar(255) No
full_name varchar(50) No
status varchar(50) No
section varchar(50) No section.secti
on ON
UPDATE
CASCAD
E
ON
DELE
TE
CASC
ADE
date varchar(50) No
62
Column Type Attribut Nu Default Extra Links Comme
es ll to nts
p_id varchar(255) No
std_id varchar(255) No
status varchar(50) Yes NULL
user_name varchar(50) Yes NULL
email varchar(50) Yes NULL
password varchar(255) No
date varchar(50) Yes NULL
63
section varchar(255 No ->
) unitleader.sec
tion ON
UPDATE
NO_ACTIO
N
ON
DELETE
NO_ACTIO
N
by_who varchar(255) No
u_who varchar(255) Yes NULL
u_date varchar(255) Yes NULL
date datetime No
exam_20 varchar(255) Yes NULL
exam2_15 varchar(255) Yes NULL
home_20 varchar(255) Yes NULL
class_10 varchar(255) Yes NULL
project_10 varchar(255) Yes NULL
assign_10 varchar(255) No
64
Column Type Attributes Null Default Extra Links
to
sec_id varchar(50) No
section varchar(50) No
status tinyint(1) No
date timestamp No current_ on update c
tmestam urrent_ti
p() mestam p()
65
fname varchar(255) Yes NULL
mname varchar(255) No
lname varchar(255) No
phone varchar(255) No
bdate varchar(255) No
bplace varchar(255) No
age varchar(255) No
image varchar(255) No
e_call varchar(255) No
e_phone varchar(255) No
mother_nam varchar(255) No
e
regin varchar(255) No
zone varchar(255) No
kebele varchar(255) No
nationality varchar(255) No
66
Column Type Attributes Null Defau Extra Links
lt to
subject varchar(255) No
status int(1) No
grade varchar(50) Yes NULL
date timestamp No current on update c
_t urrent_ti mestam
imesta p()
m p()
67
gc_niversity varchar(50) No
phone int(50) No
img varchar(100 Yes NULL
0)
region varchar(50) No
keble varchar(50) No
zone varchar(50) No
nation varchar(50) No ETHI
OPI A
doc varchar(250 No
)
sub_mater varchar(50) No
regi_date varchar(50) No
tech_id varchar(50) No
update_date varchar(50) Yes NULL
update_by varchar(50) Yes NULL
68
Column Type Attributes Null Default Extra Links
to
section varchar(50)
section.sec
tion ON
UPDATE
CASCAD
E
ON
DEL
ETE
CAS
CAD
E
unit_leader varchar(50) No
sub_matter varchar(50) No
Table 6.9 data schema view for unit-leader
69
6.6.2. Mapping
In order to store information persistently, we map objects into tables and the attributes into fields
to the specific table based on the objects found in the system. Therefore, we identified the
significant tables implemented on the selected DBMS.
This part is to describe and show the necessary relationships among the tables, which are
selected to store the data persistently in the system. Generally, there are three types of
relationships in a relational database system. These are one-to-one, one-to-many, and many-to-
many relationships. The system under consideration has one-to-many and many-to-many
relationships. Student and parent table one-to-one relationships. Section and unit Leader one-to-
one and section and attendance one-to-many relationship. score and subject one-to-one
relationship. Student and Subject tables have one-to-many relationships. One of the aims of a
database system is to reduce redundancy and for that purpose many-to-many relationship has to
be reduced to a one-to-one relationship. The Student and score and the Subject have a one-to-
many relationship by using the score table as the associate table. The relationship between the
remaining tables and the ones described here is descriptively shown in Fig. 6.2.
70
Figure 6.2 relationship mapping
Security is essential as all users have protectors so not all users can access another user's account.
71
6.8. User interface model
When a user starts the application, a login screen is displayed as shown in Figure 6.3 to
authenticate the user. If the user has typed the correct user id and password to the login screen,
the system displays and then a window containing the main menus of the system as shown in
Figure 6.4. The main window displays menus and sub menus based on the role of the user that
has logged in.
72
Figure 6.5 Admin dashboard
73
Figure 6.7 teacher Info
74
Figure 6.9 user management
75
Figure 6.11 record attendance
76
Figure 6.13 upload martial
77
Figure 6.15 class activity tracks
78
Figure 6.17 view student score
79
Figure 6.19 register student
80
Figure 6.21 student score report
81
CHAPTER SEVEN
7.1. Conclusion
This paper assists in automating the existing manual system. This is paperless work. It can be
monitored and controlled remotely. It reduces the manpower required. It provides accurate
information always. Malpractice can be reduced. All years together gathered information can be
saved and accessed at any time. The stored data in the repository helps in making intelligent
decisions by the management. So it is better to have a Web-Based Information Management
system. All the stakeholders, faculty, and management can get the required information without
delay. This system is essential in schools and universities.
7.2. Recommendation
There is future scope for this facility with many more features like online lectures and video
lessons that can be added by teachers; student to take online tests, question bank for each subject
and school fee payment management, and group discussion is a feature. Students can discuss
various topics and issues. This project was created for Abdi Boru School but can be installed and
used by any school.
82
References
[1]. E. Burke and W. Erben. Practice and Theory of Automated Timetabling, Third International
Conference, Germany, Springer Private Limited, August 2000
[2]. J. G. Hedberg et. al.(1992). Educational information systems: Problems of the small
educational organization. Australian Journal of Educational Technology, 8(2), 132-160.
[3] T. Willis and B. Newsome. Beginning Visual Basic 2005, Wiley Publishing, Inc., 2006.
[4] M. Jensen, J. Schwenk, N. Gruschka, & L. LO. Iacono (2009). On technical security issues
in cloud computing. CLOUD 2009 - 2009 IEEE International Conference on Cloud Computing,
109–116.
[5] S. Subashini,V. Kavitha (2011). A survey on security issues in service delivery models of
cloud computing. Journal of Network and Computer Applications, 34(1), 1–11.
[6] M. B. M. Kamel, L. E. George (2016). Secure Model for SMS Exchange over GSM.
International Journal of Computer Network and Information Security, 8(1), pp. 1-8.
83
Annex 1
Some algorithms
1. Embed security
<?php
require_once "../config/config.php";
$userID = $_SESSION['userId'];
$stm = $conn_db->prepare("SELECT * FROM user WHERE u_id=:id");
$stm->bindValue(":id", $userID);
$stm->execute();
$user = $stm->fetch(PDO::FETCH_ASSOC);
if (!isset($_SESSION['userId']) == true) {
header("location:../");
} else {
$userType = $user['u_type'];
if ($userType != "admin") {
?>
<script>
location.href = "<?php echo "../$userType/" ?>"
</script>
<?php }
}
2. Login identifier
<?php
session_start();
require '../config/config.php';
84
Annex 2
Questioner
Question 1:
How do you grade your current manual student’s enrollment system?
(PUT A MARK IN THE APROPRIATE BOX )
VERY GOOD
GOOD
AVERAGE
POOR
Question 2:
Do you think it should be computerized?
YES(Give two reasons)
1.…………………………………………………………………………………………………………………………………………
…………………………………………
2…………………………………………………………………………………………………………………………………………
……………………………………………
NO(Give two reasons)
1………………………………………………………………………………………………………………………………………………
……………………………
2………………………………………………………………………………………………………………………………………………
……………………………………………
Question 3.
Does the current system have any advantage over the proposed one?
YES
NO
If YES state them:
…………………………………………………………………………………………………………………………………………………
………………………..
……………………………………………………………………………………………
Question 4
What would you like included in the new system?
1……………………………………………………………………..
2…………………………………………………………………….
3……………………………………………………………………
Any other details regarding the new system
………………………………………………………………………………………………
Please fill the form with the right details and hand it in
85
Annex 3
1. 2.
Yes No
1. 2.
Yes No
1. 2.
Yes No
1. 2.
Yes No
1. 2.
Yes No
1. 2.
Yes No
86