AUWC Registration System

Ambo university woliso campus online Registrar system
2017
Ambo University woliso campus

Department of information technology
TITLE: ONLINE REGISTRAR SYSTEM OF AUWC

Project team members:
1. MILIYON LETA……………………………….…………………..……IT-RW/037/06
2. EDASA AGA…………….……………….…………………..…………IT-RW/016/06
3. SAMUEL ABEBE...…….……..……………………..……………….…IT-RW/046/06
4. ARAFAT KASSIM……..……………………………………….………IT-RW/007/06
5. ZAYNU MOHAMMED…………………………………………………IT-RW/054/06
Approved by examination committee
__________________________ _______________________
Chairman/ Dep’t head Chairman’s signature
__________________________ ________________________
Advisor’s name Advisor’s signature
__________________________ ________________________
Examiner’s name Examiner’s signature
AUWC, Information Technology Department Page i

2017
Declaration
This is to declare that the project work is done under the supervision of Mr. Lubak M and
having the title Online Registrar system for Ambo university woliso campus by contribution of:
1. Miliyon Leta
2. Edasa Aga
3. Samuel Abebe
4. Arafat Kassim
5. Zaynu Mohammed
No part of the project work has been reproduced illegally which can be considered as Plagiarism.
All referenced parts have been referenced properly. We will be responsible and liable for any
consequence if violation of this declaration occurs.
____________________________________________
Date
Full Name Signature

1. Miliyon Leta __________________________________
2. Edasa Aga __________________________________
3. Samuel Abebe ___________________________________
4. Arafat Kassim ___________________________________
5. Zaynu Mohammed ___________________________________
The project has been submitted for examination with my approval as University advisor.
______________________________ ____________________________
Advisor’s Name Signature
AUWC, Information Technology Department Page ii

2017
Executive Summary
The main objective of this project is to develop online registrar system for Ambo university
woliso campus. This system helps the registrar of the campus and also the campus community to
optimize and enhance the efficiency of the registrar tasks such storing, retrieving, grade
calculation ,handling add /drop cases, handling special grade cases ,final exam scheduling, grade
submission etc. This document is a technical report of the main activities performed from
inception to deployment of the project.
In chapter one the introduction and background of the organization, background of the system,
the problem statement, the objective, scope and limitation and significance of the project has
been included. Chapter two contains the requirement analysis activities such as the identification
of major functions of current system, business process of existing system and business use case
with its description, business rules analysis, scanned report formats and forms of existing system,
analysis of current system strength, weaknesses, opportunities and threats which help us to get
clear picture of the current AUWC registrar system problem. Moreover, functional and non
functional requirement of proposed system, feasibility study of the proposed system and data
flow diagrams has been dealt with. Similarly, in chapter three we described system design
activities such as current software architecture, proposed software architecture, UML of
proposed system such as use case diagram, use case description, sequence diagram, collaboration
diagram, activity diagram, deployment diagram, component diagram, class modeling, database
design and user interface screenshots.
AUWC, Information Technology Department Page iii

2017
Acknowledgement
Above the all, we would like to thank our Almighty God who through his infinite mercy and love guided
us throughout the duration of the program. Then we are deeply grateful to AUWC department of
Information technology for giving us this opportunity.
We are extremely grateful for our advisor Instructor Lubak M. for his continuous follow up, advice,
critical comment and encouragement throughout the completion of this project.
Finally, we would like to thank AUWC registrar office employees for giving us necessary information.
AUWC, Information Technology Department Page iv

2017
Acronyms
AUWC: Ambo university woliso campus
SGPA: Semester grade average point
CGPA: cumulative grade average point
ID NO: identification number
SMS: short message service
SRS: system requirement specification
CEP: continue Education program
LEH: Lecture Hour
AU: Ambo University
DFD: Data Flow Diagram
AUWC, Information Technology Department Page v

2017
Contents
Declaration .................................................................................................................................................... ii
Executive Summary ..................................................................................................................................... iii
Acknowledgement ....................................................................................................................................... iv
Acronyms ...................................................................................................................................................... v
Chapter one ................................................................................................................................................... 1
Introduction ................................................................................................................................................... 1
1.1. Overview ............................................................................................................................................ 1
1.2. Background of the organization ......................................................................................................... 1
1.3. Background of the system .................................................................................................................. 1
1.4. Statement of the problem ................................................................................................................... 2
1.5. Objectives of the project .................................................................................................................... 3
1.5.1. General objective ........................................................................................................................ 3
1.5.2. Specific objectives ...................................................................................................................... 3
1. 6. Scope and limitation of the project ................................................................................................... 4
1.6.1. Scope of the project..................................................................................................................... 4
1.6.2. Limitation of the project ............................................................................................................. 5
1.7. Risks, constraints and assumption ..................................................................................................... 5
1.7.1. Risks ............................................................................................................................................ 5
1.7.2. Constraints .................................................................................................................................. 6
1.7.3. Assumption ................................................................................................................................. 6
1.8. Significance of the project ................................................................................................................. 6
1.9. Beneficiaries of the project ................................................................................................................ 7
1.10. Team composition, budget and schedule ......................................................................................... 9
1.10.1. Team composition ..................................................................................................................... 9
1.10.2. Budget schedule ........................................................................................................................ 9
1.10.3. Time schedule ......................................................................................................................... 10
Chapter 2 ..................................................................................................................................................... 11
System requirement specification ............................................................................................................... 11
2.1. Overview of existing system ............................................................................................................ 11
2.2. Major functions of existing registrar system .................................................................................... 11
AUWC, Information Technology Department Page vi

2017
2.2.1. Business process of existing registrar system ........................................................................... 12
2.2.2. players/Actors in Existing systems ........................................................................................... 14
2.2.3. Business rules of existing system.............................................................................................. 18
2.2.4. Reports generated, forms, documents of existing system ......................................................... 21
2.2.5. SWOT analysis of existing system ........................................................................................... 22
2.3. Problems of existing system ............................................................................................................ 23
2.4. Proposed system............................................................................................................................... 24
2.5. Methodology and tools .................................................................................................................... 25
2.5.1. Data collection methods ............................................................................................................ 25
2.5.2. Hardware and software tools..................................................................................................... 26
2.5.3. Minimum hardware and software requirements ....................................................................... 27
2.6. System analysis tools and techniques employed .............................................................................. 27
2.6.1. Data flow diagrams ................................................................................................................... 27
2.7. Requirement analysis ....................................................................................................................... 30
2.7.1. Functional requirement of the project ....................................................................................... 30
2.7.2. Nonfunctional requirements ...................................................................................................... 32
2.8. Feasibility analysis ........................................................................................................................... 33
2.8.1. Technical feasibility .................................................................................................................. 33
2.8.2. Operational feasibility ............................................................................................................... 33
2.8.1. Economic feasibility ................................................................................................................. 33
2.8.2. Schedule feasibility ................................................................................................................... 33
Chapter 3 ..................................................................................................................................................... 34
System Design ............................................................................................................................................ 34
3.1. Overview of system design .............................................................................................................. 34
3.2. System Architecture ......................................................................................................................... 34
3.2.1. Current registrar system software architecture ......................................................................... 34
3.2.2. Proposed registrar system software architecture ....................................................................... 34
3.3. UML of the proposed system ........................................................................................................... 35
3.3.1. System Actors ........................................................................................................................... 35
3.3.2. Use case Model ......................................................................................................................... 36
3.3.2. Sequence diagram ..................................................................................................................... 71
AUWC, Information Technology Department Page vii

2017
3.3.3. Collaboration diagram............................................................................................................... 77
3.3.4. Activity diagram ....................................................................................................................... 81
3.3.5. Class diagram ............................................................................................................................ 87
3.3.6. Component diagram .................................................................................................................. 89
3.3.7. Deployment diagram ................................................................................................................. 91
3.4. Data persistence modeling ............................................................................................................... 91
3.4.1. Entities, attributes and schema .................................................................................................. 92
3.4.2. ER-diagram ............................................................................................................................... 93
3.4.3. Referential integrity and constraints ......................................................................................... 94
3.4. 4. Database table schema ............................................................................................................. 97
3.4.5. Normalizations ........................................................................................................................ 103
3.5. User interface of the prototype....................................................................................................... 107
Reference .................................................................................................................................................. 115
Appendix ................................................................................................................................................... 116
AUWC, Information Technology Department Page viii

2017
List of Figures
Figure 1: project plan .................................................................................................................................. 10
Figure 2: Business use case of Ambo university WOLISO campus Registrar system ............................... 15
Figure 3: first level Data flow diagram for AUWC registrar system .......................................................... 28
Figure 4: Second level data flow diagram for AUWC Registrar system .................................................... 29
Figure 5: proposed online AUWC registrar system software architecture ................................................. 35
Figure 6: Use case diagram for online registrar system (part one) ............................................................. 37
Figure 7: Use case diagram for online registrar system (part two) ............................................................. 38
Figure 8: Sequence diagram for login use case........................................................................................... 71
Figure 9: Sequence diagram for create account use case ............................................................................ 72
Figure 10: Register new student use case sequence diagram ...................................................................... 73
Figure 11: Sequence diagram for Register for course use case .................................................................. 74
Figure 12: Sequence diagram for post registration date use case ............................................................... 75
Figure 13: Collaboration diagram for login ................................................................................................ 77
Figure 14: Collaboration diagram for new student registration .................................................................. 78
Figure 15: Collaboration diagram for Drop Course .................................................................................... 79
Figure 16: Collaboration diagram for add mark use case ........................................................................... 80
Figure 17: Activity diagram for Login Use case......................................................................................... 81
Figure 18: Activity Diagram for Register for course use case .................................................................... 82
Figure 19: Activity Diagram for Add course use case ................................................................................ 83
Figure 20: Activity diagram for Drop course use case ............................................................................... 84
Figure 21: Activity diagram to generate final exam schedule use case ...................................................... 85
Figure 22: Activity diagram for post registration date use case.................................................................. 86
Figure 23: Activity diagram for add mark use case .................................................................................... 87
Figure 24: Class diagram for online registrar system ................................................................................. 88
Figure 25:- Component diagram for online registrar system ...................................................................... 90
Figure 26:- Deployment diagram for online Registrar system.................................................................... 91
Figure 27: Entity Relationship Diagram for online registrar system .......................................................... 93
AUWC, Information Technology Department Page ix

2017
List of tables
Table 1: Team composition .......................................................................................................................... 9

Table 2: Budget schedule .............................................................................................................................. 9
Table 3: Business use case description for preparing registration slip. ...................................................... 16
Table 4: Business use case description for check course prerequisite ........................................................ 17
Table 5: Business use case description for Register ................................................................................... 17
Table 6: Use case description for Login ..................................................................................................... 40
Table 7: Use case description for create account ........................................................................................ 41
Table 8: Use case description for delete account ........................................................................................ 42
Table 9: Use case description for update account ....................................................................................... 43
Table 10: Use case description for register new student ............................................................................. 44
Table 11: Use case description for Add assessment rule ............................................................................ 45
Table 12: Use case description for Register instructor ............................................................................... 46
Table 13: Use case description for Update instructor ................................................................................. 47
Table 14: Use case description for Delete instructor information .............................................................. 48
Table 15: Use case description for register course information .................................................................. 49
Table 16: Use case description for view course .......................................................................................... 50
Table 17: Use case description for Update course information .................................................................. 51
Table 18: Use case description for Delete course information ................................................................... 52
Table 19: Use case description for Register department information ......................................................... 53
Table 20: Use case description for Update department information ........................................................... 54
Table 21: Use case description for Delete department information ............................................................ 55
Table 22: Use case description for register classroom information ............................................................ 56
Table 23: Use case description for Update classroom information ............................................................ 57
Table 24: Use case description for Delete classroom information ............................................................. 58
Table 25: Use case description for Register for course............................................................................... 59
Table 26: Use case description for Add course........................................................................................... 60
Table 27: Use case description for Drop course ......................................................................................... 61
Table 28: Use case description for generate exam schedule ....................................................................... 62
Table 29: Use case description for view exam schedule............................................................................. 63
Table 30: Use case description for view Result .......................................................................................... 64
AUWC, Information Technology Department Page x

2017
Table 31: Use case description for send grade complaint ........................................................................... 65
Table 32: Use case description for view grade complaint .......................................................................... 66
Table 33: Use case description for Replay grade complaint ....................................................................... 67
Table 34: Use case description for Reject Complaint ................................................................................. 68
Table 35: Use case description for post registration date ........................................................................... 69
Table 36: Use case description for add mark .............................................................................................. 70
Table 37: Sequence diagram for add mark use case ................................................................................... 76
AUWC, Information Technology Department Page xi

2017
Chapter one
Introduction
1.1. Overview
Registrar system is huge system in which many subsystems will communicate with each other
such as grading system, status determination system, class and exam scheduling system,
registration system, etc. Running up of all these subsystems by using manual system is bulky,
tedious, error prone and require more time, high cost, and man power.
1.2. Background of the organization

Ambo University is one of the fastest growing Ethiopian Universities, currently expanding to
four campuses. In addition to the main campus, it has four functional campuses - Awaro
Technology Campus, Guder agriculture campus and Woliso Business and Economics faculty.
Among these campuses woliso is the one which was started in 2002 E.C by having Accounting
and finance, Economics, management and information technology departments. By now it is
teaching 13 departments and in the course of these developmental processes it had enrolled
students from various backgrounds.
The office of the registrar is responsible to handle exam scheduling, manage add/drop cases,
manage special case related to grade, compile and process the records of students enrolled, issue
documents for the graduates after the completion of the programs intended and so on. Besides,
the office is currently handling records of the alumni to provide appropriate information when
required.
1.3. Background of the system

By definition the registrar is an office of academic institutions such as university, college, high
school etc. AUWC registrar is one of Ambo University’s registrar offices dedicated to perform
standard registrar tasks that are naturally complex and very critical. This office is responsible for
Student registration, processes and generates transcripts, receives paperwork regarding grade
changes, drops/withdrawals, exam schedule, and graduation applications and etc. Since the
running up of current system is manual (which wastes time, resource and, consumes human
By AUWC Information Technology 4th year students Page 1

2017
power) in order to solve this problem we are going to develop Online Registrar system for
AUWC which deals with the problems of managing registrar system. Identification of the
drawbacks of the existing system leads to the designing of a computerized system that is
compatible with the existing system and more users friendly. Our system is a web based
application that allows users to get any information through online access. Therefore, it is
necessary to develop online registrar system to make a more computerized service provision by
giving priority to the functionality of data validating, storing, updating, deleting and generating
report.
1.4. Statement of the problem

The main objective of Ambo University Woliso Campus registrar is managing the academic and
related records of students in accurate, secured and efficient ways. While doing this, currently,
the existing system of AUWC was facing many problems.
Error prone:-there is great chance of error such as assigning one class room for two or more
exams at the same time, register grade wrongly, incorrect calculation of SGPA and CGPA,
incorrect student status determination and etc.
Time consuming: - registrar system of AUWC is manually operating system. It performs many
activities such as SGPA and CGPA calculation, student status determination, scheduling class
and exam, prepare registration slips and etc. Since the system is manual, to calculate SGPA and
CGPA, to determine student status of now existing student, to prepare final schedule and etc, it
will take more time. As number of students assigned to this campus increases it needs more and
more time and more man power. For this reason Student academic report such like Grade report
and transcript is not provided to the student on time. Students are wasting their time while
registering for class by waiting their sequences. When mistakes are made or changes or
corrections are needed, often all action must be completely re-done rather than just updated.
Lots of paper work: - existing system require lot of paper work. Every data is stored as hard
copy in two or more than two copies. Loss of even a single register/record led to difficult
situation. Because of all papers are need to generate student transcript or other report. In
addition to this since campus is using physical notice board, to make the notice easily viewable
AUWC, Information Technology Department Page 2

2017
by concerned body, campus is posting the same copies of notice in different place. This brings
wastage of paper.
Storage place: - existing system stores the same copy of data in different location (in registrar
and in dep’t head). Because of the data is stored in hard copy, as number of students become
increasing, it needs large storage area to store.
Not secured: - the current system have no any form of authentication mechanism and the
document of one student can be seen by other users.
Needs high cost: -existing system needs many employees to operate as well as other necessary
resource such as paper and pen
Searching of information is so hard: - existing system doesn’t have organized record keeping
and searching for specific information needs to scan for all existing record which is tedious.
Generally existing AUWC registrar system is facing above mentioned problems, which
motivates us to automate it.
1.5. Objectives of the project
1.5.1. General objective

The general objective of this project is to design and implement an automated Online Registrar
system that solves the problems of existing system.
1.5.2. Specific objectives

Specific objectives of our project are:
 To study major components and functionality of existing system such like registration
management, status determination management, Grade management, final exam
schedule management, report management, student transcript management and etc.
 To identify problems of existing system
 To propose the solution for identified problems and make the system user centric and
user friendly by designing single data base, which will make the system effective and
efficient, more secured, give reliable search facility, to record new student

2017
information, to update existing student information and avoid data redundancy and
inconsistency.
 To design and implement cost effective registrar system.
 To test system designed and implemented registrar system.
1. 6. Scope and limitation of the project

1.6.1. Scope of the project
The Registrar system scope is limited to activities performed by the Registrar office such:
1. System will register and display course detail such as course code, course title, course
credit hour, course prerequisite, course department and etc.
2. System allows students to perform online registration including new students and existing
students. The system is able to check course prerequisites while registering existing
students.
3. System informs instructors start and last grade submission(verification) date and allows
instructors to submit Grade within limited time frame being online
4. System has ability to handle special case grades (NG, Incomplete, FX, etc.) and it is
accurate to calculate SGPA and CGPA, displays the course taken by student with the
corresponding grade, SGPA and CGPA.
5. System has ability to determine student status for existing student (Dismissal, Dismissal
with Academic Re-admission (RE), In-progress) based on their academic result.
6. System is able to generate reports regarding to students such as grade report, student
status, GPA report and etc.
7. System will generate final exam schedule.
8. System has ability to generate automatic identification number (ID NO) for every student
when they are registered as new student.
9. The system will store all necessary information in a database and retrieve it by using
advanced searching mechanism
10. Enables registrar head, to post academic calendar on campus website
11. The system shall be able to deliver messages for the directed person through his/her
account.

2017
12. System accepts complaint from any users and allows admin to send feedback for users
complaint
13. System will allow admin to create account for users and it will allow access to only
authenticated users.
14. The system enables users to change password, if the users forget their password.
15. The system administration can delete, update and view user data from system.
This project can be used by other universities.
1.6.2. Limitation of the project

Some limitation in our project is:
 The user interface is only support English language i.e. another language is not
supported.
 The system doesn’t support online payment for extension student registration as well as
for any punishment.
 The system doesn’t handle registration of extension students for summer semester.
 The system not able to manage Alumni
 The system is not mobile based and cannot send SMS message
 The system doesn’t perform new student placement
1.7. Risks, constraints and assumption

1.7.1. Risks
As all human wants success, there is unavoidable obstacle which prevents human from success.
This obstacle is unexpected risks that may occur while we are doing our project. Our project will
have the unexpected risks such as:
 Power: - power may go continuously during the time of this project work.
 Schedule: - because of the system is huge and has many functionality we may not
complete the project on scheduled date and within a given time by the campus.
 Financial: - since the campus didn’t assign any budget, and group members have no any
income, it is clear that there is financial risk during this project work.

2017
 Resource: - Resources may not be enough to achieve our objective.
1.7.2. Constraints
 Time given for this project is not enough
 As beginners we are not sufficiently experienced.
 Reference and technical material may not be satisfactorily available.
1.7.3. Assumption
 We assume that everyone that uses the system has access to the intranet.
 We assume that everyone of system’s user can understand English to use it.
1.8. Significance of the project

The proposed online registrar system will give the following benefits:
Minimize the time and manpower: - our proposed system aim is to minimize time required to
perform certain actions such as student status determination, SGPA and CGPA calculation, final
exam scheduling by making it automatic.
Minimize errors:- since the system is automated, error occurring because of manual control
such as incorrect calculation of SGPA and CGPA, Assigning the same class for two or more
exam at the same time, and the like are aimed to be minimized.
Reduce resource wastage:- Resources wasted such as paper, pen, man power are aimed to be
reduced by reducing paper based work and number of employee required to operate with the
system.
Create security of data and system: - the system allows authorized person to access
information only related with his/her permission. The system identifies the user permission based
on the user type that the user entering and the system direct the user to user type home page.
The general core importance of the project is to change the current manual work system to easily
manageable web based online registrar system. The system provides easy way for storage and

2017
access or retrieval of data to and from the database. The system is used to remove the mismatch
of student grade and corresponding GPA for all courses that a student has already enrolled. The
system also used to deliver notices for the responsible person, which can accessible by
responsible body.
1.9. Beneficiaries of the project

Student:
The proposed registrar system allows students to:
 View information such as available courses detail
 See start and end date of registration for as senior and freshman student.
 Register online being online, so they can save their time and energy at the time of
registration.
 View final exam schedule
 View result every semester and print non-official grade report.
 Send his/her complaint and receive replay for his/her complaint
 See posted news and timely information about their academic learning
 Add course/courses being online.
 Drop course/courses being online.
 Edits his/ her own profile.
 Withdraw/cancel class
 Get satisfaction.
Instructor:
Our system allows instructors of AUWC to:
 View list of students registered for course assigned for him/her.
 View list of students those drop his/her course/courses
 View posted news and access timely information like start and last grade submission
date, academic calendar of the campus.
 View final exam schedule.
 Send system complaint and receive replay for his/her complaint.
 Submit grade being online and change grade if there is error.
 Receive grade complaint and replay or reject complaint.

2017
 View GPA report and top scorers from every department of the campus
 Add assessment method(Test, project, presentation, individual assignment, group
assignment, etc)
Department head:
Our system allows all department head of AUWC to:
 Verify assessment method
 Approve grade
 Receive grade complaint and replay or reject complaint
 Manage curriculum easily
 View posted notices and access timely information
Campus:
 Save time and resource such as human resource, financial resource and etc.
 Eliminate redundancy of data by storing in a single database.
Employee of Registrar:
 Helps employee of campus by reducing workload.
Campus Dean:
 Shall be able to retrieve all the necessary information with regard to the system from the
system quickly and easily.
 Enables dean to view transcript request
 The system allows the dean of the campus to verify original transcript.
 The system allows dean to give comment on final exam schedule.
 The system allows dean to view different forms of report.

2017
1.10. Team composition, budget and schedule
1.10.1. Team composition
In our project, we have five (5) members on the development of registrar system and also the
project is supervised by one of our members. The following are the types of tasks and as well
as the responsibility each of us can have.
Task Group member Name

Project manager Miliyon Leta
Propose the system All group members
SRS Miliyon Leta and Zaynu Mohammed
Design Miliyon Leta, Edasa Aga and Samuel Abebe
Coding and implementation Arafat Kassim and Miliyon Leta
Testing Miliyon Leta
Table 1: Team composition
1.10.2. Budget schedule

The budget is the backbone of our project which leads it to success. Even if there is no budget
budgeted from academic institution for this project, we are enforced to budget the cost by
ourselves to complete our project as much as possible.
Reason of payment Amount Unit price Total price in Birr

One Laptop One 12,000.00 12,000.00
Flash disk Five 120.00 600.00
Compact disk(CD-RW) Five 25.00 125.00
Unexpected risk - 1000.00 1000.00
Total - 13,120.00 13,720.00
Table 2: Budget schedule

2017
1.10.3. Time schedule
The project planning defines activities that will be performed and describe how the activities will
be accomplished. The purpose of project planning is to define each major task, estimate the time
and resources required and provide frame work to manage and control project activities.
Figure 1: project plan

2017
Chapter 2
System requirement specification

2.1. Overview of existing system
The current AUWC registrar system which performs crucial activity is being done manually. The
manual way of data handling and running up of the activities is time and human power
consuming, resource wasting and tedious one.
2.2. Major functions of existing registrar system

The main activities of the registrar system are:
 Prepare the academic calendar of the University each year.

 Create and maintain up-to-date, confidential, private, safe, and permanent records of all
students, including drop-outs, dismissals, withdrawals, and alumni.
 Create and maintain up-to-date and accurate information on student admission, placement,
registration, academic performance, and graduation based on types programs.
 Issue transcripts, degrees, diplomas and certificates.
 Prepares class and exam schedules.
 Arranges the preparation and issuance of ID cards to admitted students.
 Maintains files for admitted students in the Regular and CEP.

 Updates student records, compute grade point average and prepares student status.
 Ensures student necessary documents for admission, backgrounds, grades, clearances, etc are
maintained timely in each of student files and transferred to the main registrar for the
necessary information and documentation
 Follows up status of discontinued students for various reasons and their file along with record
keepers and admission officer
 Prepares the various lists of students for possible academic actions.
 Prepares and issues transfer, withdrawal, re-grade, etc. request forms upon request.
 Ensures student grade complaints are resolved per the rules and regulations

2017
 Continuously updates student files
 Assures the safety and security of all academic records
2.2.1. Business process of existing registrar system

AUWC’s existing Registrar system is running up the activities such as student registration, handle
add/drop course/courses, handle withdrawal, prepare schedule, calculate SGPA and CGPA, determine
student status, generate grade report, generate GPA report, generate transcript and the like.
Student registration is one of the activities of AUWC’s registrar system. To register students, registrar
announce registration date and as they has to be in the campus physically. At registration date
student goes to department head and take slip for registration. Then student fills and submits hard
copy of filled application form to the campus registrar to register for courses/class.
Add/drop course/courses are also handled by existing system. It can be performed in two ways.
The one way is voluntarily (Based on student wish) and the second one is forcedly. Forcedly
add/drop courses taken if course prerequisites not meet. It follows the process: Dep’t head
identifies student not meets course prerequisites by accessing the grade of courses having
prerequisites and finding the id number of students who score “F” on that courses and informs to
those students to drop course they are registered before fulfilling perquisites of the course and
adds another course/s which is/are under option by preparing the add/drop course form and gives
it to student. The students fill the form and submit to registrar.
Withdrawal is defined as cancellation of all classes/ courses for which student registered. Can be
based on student wish or based on academic enforcement. Voluntarily withdrawal is started by
student who request registrar for withdrawal within a given time frame. Then registrar gives
withdrawal form to student who request for withdrawal. Student fills all necessary information in
two copies. After filling all necessary information student must have to return it to registrar for
approval. Then registrar see as all filled information is valid. After checking validity of filled
information registrar put registrar seal on it to indicate as it is approved. After it is approved
gives one of its copy to the student and keeps the second for itself. If the student academic
performance is low he/she is also enforced to fill withdrawal. Registrar announces a student whose
academic performance is low to fill withdrawal. Then student fill withdrawal by following the above
procedure.

2017
AUWC’s deputy of registrar prepare schedule by taking student’s details registered to the
campus and availability and capacity of classroom by taker of class overlapping.
Calculating SGPA and CGPA, preparing grade report for the students and determining of student
status are the major function of existing system. To calculate SGPA and CGPA, registrar
receives grades having course title, course code, course credit hour, course department, course
class year, course semester approved by department head from instructors. After collecting all
grades from instructors who was teaching the courses, the registrar records all the grade details
with its equivalent grade point based on campus grading system scale in excel. After completion
of recording grade, the registrar adds all grade point achieved in a semester and divide it to total
credit hour given within a semester to get SGPA.
AUWC registrar also calculate CGPA, after the completion of SGPA calculation, by adding total
grade points earned in all previous semester and now semester and divide it by total credit hours
given in all previous semester and now semester.
AUWC registrar has a way to measure student’s academic performance, called student status
determination. AUWC registrar, determine student’s status (pass, academic dismissal with re-
admission (AD/RE) and dismissal (ADD) from their own SGPA and CGPA based on evaluating
criteria interval of the AUWC. AUWC registrar does this activity repeatedly in every semester.
Prepare grade report is the activities of AUWC registrar. In AUWC registrar grade is the method
of student’s competency evaluation on specific course. Each of the courses taken by students has
its own grade. Grade report is the report of student’s competency on all the given courses per
semester. Official grade report is given by the registrar and must carry all the names, ID numbers of
students, department and necessary information. After completion of calculating SGPA and CGPA,
AUWC registrar prepares grade report for its students from all grade earned per semester, SGPA and
CGPA.
Similarly AUWC registrar is issues the transcript for graduates students. Transcript is records of a
student's academic performance in a campus life. It is generated from the collection of student
records and must include: University name, college/school/Institute, department, student name,
degree nomenclature, date of issued and university seal.

2017
2.2.2. players/Actors in Existing systems
The main users that are involved in the registrar system are:
• Registrar office manager: - Manages the registration, result of student status this such as
academic dismissal, in progress, graduate and academic dismissal with readmission etc.
He/she is the one who manages the overall existing system of AUWC Registrar system.
• Admission officer: - responsible body to register students.
• Record officer: - responsible for recording all information related to existing system.
• Student: - Register, perform withdrawal, take grade report, add/drop course/courses, etc.
• Instructor: - get class and exam schedule, submit grade, change grade and etc.
• Registrar Secretary: - typing information related registrar system.
• Department head: - approve grade, give list of courses belongs to his/her department,
check course with prerequisites, prepare slip for add/drop course or courses and etc.

2017
Give Course
Instructor
Submit Grade
Registrar
Change Grade
Send Student list
Give Transcript
Department Head Manage Curriculum
Registrar head
Assign Instructor
Prepare Student ID
Approve Grade
Manage Registration
Prepare Registration Slip
Add Course Prepare Schedule

Check Course Prerequisites
<<extend>>
Personal Information
<<extend>> Repeat Course
Register <<extend>>
Record Officer
<<extend>>
Grade Record Student Data
Student <<extend>>
Drop Course
<<extend>>
CGPA Calculate GPA
<<extend>>
Take Grade Report
SGPA
Prepare Grade Report Admission Officer
<<extend>>
Legal Withdraw
Withdraw Class Check Student Status
<<extend>>
Forced Withdraw
Register Student
Post Notice
Registrar Secretory
Figure 2: Business use case of Ambo university WOLISO campus Registrar system

2017
Business use case description
 Use case ID: Represents identification number that enables us to make the use case
traceable.
 Use case name: Represents the name that we have used in the business use case model.
 Participating Actor: Represents who interacts with the system either internally or
externally.
 Precondition: Represents what is the expected situation before the use case can be
started.
 Event flow: represents the steps we have to follow to get output we want from system.
 Post-condition: represents what is expected output at the end of use case.
 Alternative Flow: steps we have to follow if there is another ways to get the same result.
Use case ID UC01
Use case name Prepare Registration slip
Participating actor Department head
Precondition Course detail must be existed
Event Flow
1. Department head must access course detail
2. Department head select those courses having the same class year and class semester
3. Department head leave place for student name, id and signature and date of registered.
4. Department head put all selected courses in a table format with their description such as
course code, course title, course credit hour and etc.
5. Department head leave place for his/her signature and registrar signature.
6. Department head notice students to fill the prepared slip in three copies and submit one of it to
registrar, one of it to him/her and receive the remain form himself/herself
Post condition Registration slip is prepared successfully.
Alternative Flow
-
Table 3: Business use case description for preparing registration slip.

2017
Use case ID UC02
Use case name Check Course prerequisites
Participating actor Department head
Precondition - Student Grade must existed
- Course that have prerequisite must be there
Event Flow
1. Department head must access student grade
2. Department head select those courses having prerequisites form course detail
3. Department head select grade of courses having prerequisites.
4. Department head search “F” grade in grade of courses having prerequisites.
5. Department head take students’ id no, who score “F” Grade.
6. Department head notice student, who score “F” to drop course having prerequisite and to add
another if he/she want.
Post condition A course prerequisite is checked.
Alternative Flow
-
Table 4: Business use case description for check course prerequisite
Use case ID UC03

Use case name Register
Participating actor Student
Precondition - Student must be presented in Campus
Event Flow
1. Student goes to department head and takes registration slip.
2. Student Fill all necessary information in three copies and submit it to registrar.
3. After registrar sealed on it, give one to registrar, one to department head and take one
for him/hers.
Post condition A course prerequisite is checked.
Alternative Flow
-
Table 5: Business use case description for Register

2017
2.2.3. Business rules of existing system

 Students must register before class started.
 All regular students must register for total of 30ECTs per semester.
 Adding and dropping of the courses shall be treated as per the University academic
calendar with regard to add and drop.
 Student cannot register for a course having prerequisites if he/she scores F on the
previous course.
 Students wishing to withdraw from their class must do so during the first four weeks
of the semester. (Legal withdrawal).
 Student can cancel/withdraw/ their class if they are faced problems like disease,
pregnant etc. when they need by providing sufficient evidence to registrar. (Forced
withdrawal).
 Final exam shall be conducted according to registrar schedule.
 Maximum final exam time is 3.00 hour and minimum is 1.00 hour.
 Grades shall be submitted by the instructor to the registrar and with a copy to the head of
the department on duly signed official grade submission form. This document shall be
prepared legibly with no alterations or erasures.
 Grade contains Continuous assessment in the form of test, project/midterm exam,
Assignment, presentations should form 60% and remaining 40% is for final exam.
 The grade A+ is the highest possible grade, and grades below D are considered
failing. Plus or minus (-) symbols are used to indicate grades that fall above or below
the letter grades, but grades of A+ and D- are not used. The possible grades are A+,
A, A-, B+, B, B-, C+, C, C-, D, FX, NG, I and F having the following values:
Grade Point Grade Point Grade Point Grade Point

A+ 4.00 B 3.00 C- 1.75 I -
A 4.00 B- 2.75 D 1.00 NG -
A- 3.75 C+ 2.50 FX Re-exam
B+ 3.50 C 2.00 F 0.00
Table: Grading system scale of AUWC

2017
 Courses completed with FX must be re-examined/cleared/ with makeup exam.
 If a student didn’t take re-examination having “FX” within two weeks’ time due to
unjustifiable reason, the “FX” shall be converted into “F”
 If a student scores FX again, re-examination is given for the second time. If the
student scores FX again it should be changed to F grade.
 A student who scores „F‟ grade should repeat that course by re-registering for the same
course.
 A student who has obtained an “F” must repeat the course/module up to two times.
 All “NG”s grade shall be changed to one of the following:
o To an “I” (incomplete) by the registrar based on the decision of academic
commission for a student, because of illness or extenuating or extraordinary
circumstances, fails to complete the module/course.
o To a “W” to show that course is withdrawn by student who fails to complete the
course.
o To “F” to show the failures of student to do so
 Any “I” grade not removed within a year shall be converted to an “F” grade.
 If cheating case is found on final exam once instructor is responsible guy to give F
grade.
 Instructor can change grade by filling grade change form. Grade change must be
approved by department head and registrar head.
 A student who has been reported for cheating for the second time shall be suspended for
at least one academic year.
 Any student who commits such an offence for the third time while enrolled in a program
shall be dismissed indefinitely.
 The SGPA and CGPA are calculated at the end of each Semester
SGPA ∑ ∑
Where n is total number of courses taken per semester.
CGPA ∑ ∑
Where n is total number of courses taken in all previous semester and now
semester.

2017
 Grade report is prepared for each student by registrar.
 Student’s status is determined based on their CGPA and SGPA result. There are warning,
dismissal, dismissal with academic re-admission and pass possible status.
Table: Year I semester I
Table: Year I semester II –previous warned
Table: Year I semester II- pervious pass
Table: Year II and above- previous warned
Table: Year II and above- previous pass

Where: W: warning AD/R: Academic dismissal with Re admission

2017
P: pass AD: Academic dismissal
 Student is allowed to graduate if:
o He/she scores a CGPA of 2.00 or more than 2.00.
o He/she should not have “F” grade in any course he/she has taken.
o A student, who at the end of a study program, has a CGPA of 1.95, shall be
allowed to raise the CGPA to >2.00 to graduate by repeating a maximum of four
courses (an equivalent of 18 ECTS) over two semesters.
 A student may obtain a copy of his/her academic record from the Office of the
Registrar-(official copy of degree and transcript-after payment).
2.2.4. Reports generated, forms, documents of existing system

Existing registrar system of AUWC is generating various reports such as grade report, GPA
report, student status report, and etc in different formats by using existing system’s various
documents.
2.2.4.1. Report generated formats of existing registrar system of AUWC

Grade Report Format
Final exam Schedule Format

2017
2.2.4.2. Forms of existing registrar system of AUWC

Existing registrar system of AUWC is using different forms to collect necessary information
from campus students, instructors, department head, etc.
Registration Slip Form
2.2.5. SWOT analysis of existing system

Strength of existing system
Strengths are the strong parts of existing system that can be directly controlled. Existing system
has the following strength:
 It doesn’t give grade report, temporary, official transcript and the like to the third party.

2017
Weakness of existing system
Weaknesses represent areas of existing system that can be improved by the proposed system.
After the study of existing system in detail the following weaknesses were identified:
 Has no ways to generate student id automatically.

 Less accurate to determine student status
 Less accurate to check maximum credit hour allowed per semester while adding course/
courses
 Less accurate to check minimum credit hour allowed per week while dropping
course/courses.
 Generate the same slip for students that meet course prerequisites and don’t meet. It
needs more paper. It is paper based (i.e. needs more cost). Doesn’t check prerequisites
for courses against student records
 Final exam scheduling mechanism has probability to assign a single class to conduct
two or more exam at the same time, which needs computerized solution to eliminate this
issue.
 Has a probability to assign one invigilator for two or more exam room.
 Incorrect calculation of SGPA and CGPA.
 Doesn’t have any mechanism to deliver message for concerned body secretly.
Opportunity
 AUWC registrar may get copies of student’s transcript from AU main if it is loosed.
 AUWC registrar may get copies of grade report from department head if it is loosed.
Threat
 Unethical employee of registrar system may change student grade, change student status,
print transcript for dismissed student or third party.
2.3. Problems of existing system

After studying of existing system of AUWC registrar the following problems are identified:
 Require more man power, cost and time consuming

 There is great chance of error

2017
 There is loss of critical data.
 It is difficult for modifying stored information. It needs re-doing if there is a single error.
 Searching for specific document will require scanning all documents in the registrar office.
 The delivery of information for the directed person is difficult and can be done in a printed
paper format and the directed person must read the notice from notice boards.
 Generating correct grade report and the corresponding GPA is difficult.
 Lack of automatic student’s id number generation which saves human resource and time.
 Has no way of transmitting the immediate notice to all campus community.
2.4. Proposed system

After investigating the current working system, we were able to identify the critical problems
clearly observed (that was explained in the Statement of problem).
The proposed system aims to simplify the task of the Registrar system in different directions by
removing the bulky process of manual registrar system by automating it. The Registrar system is
responsible for generating and posting information related with campus registrar on the intranet
for different activities(such as to register student online, allows students to see their SGPA and
CGPA, allows students to Add/drop courses, allows students to see academic calendar, allows
students to see final exam schedule, enables student to withdraw, etc.). The system follows the
three tier client-server architecture. There is a centralized database, saving different data that are
used to generate information related with registrar.
There are many participating groups as actors in the system. These are:-
Students: - register for the course, request for grade report, request for Add/drop course, request
for course detail, request for final exam schedule, etc.
Instructors: - add assessment method, see students registered for his/her course, request for final
exam schedule, submit grade, change grade, etc.
Department head: - approve grade, manage curriculum, view registration report, and etc.
Registrar office manager: - post notice for student and staff, approve grade, post academic
calendar, deliver message to concerned body, print original transcript and etc.

2017
Deputy of registrar: - generate exam schedule, maintain class room information and etc.
Admission officer: - handle registration of new and senior students; determine the status of
senior students, and etc.
Record officer: - maintain student data, calculate SGPA and CGPA, post top scorers, generate
grade report, and etc.
System administrator: - creating and deleting accounts, receive user’s complaint and etc.
Dean: - view different reports (like registered for course student report), GPA report, verify
transcript, comment exam schedule and etc.
By having above listed actors, the major benefit that the new proposed Online Registrar system
would provide is: -
1. To simplify the work load of the registrar’s employee.
2. To reduce loss of data.
3. Eliminate errors
4. Minimizes most paper based works.
5. To facilitate the working system of the registrar office.
6. To save time.
2.5. Methodology and tools

2.5.1. Data collection methods
We have been gathering Information in the following ways:
2.5.1.1. Observation
The group members observed how the existing system is working, to get visual understanding of
the system and to design the suggested and an interesting system.
2.5.1.2. Interview
The group members interview with campus registrar office manager to know how existing
system works and to identify the existing problem of the current system.
2.5.1.3. Collection data

We also read the collection of data with related to registrar system to get what should be
included in our proposed system.

2017
2.5.1.4. Document analysis methods
In our project the group members analyze the data collected from different data sources by using
object oriented system analysis design diagram, business use case diagram, use case description
and group members decide to use object oriented system analysis and design diagram like system
use case, sequence diagram, activity diagram, collaboration diagram, class diagram to design the
proposed system.
2.5.2. Hardware and software tools
2.5.2.1. Hardware devices

 Personal computer: is a necessary and mandatory device which is used to organize our
project documentation and implementation.
 Printer: is device used to print document of our project.
 Flash disk and Compact disk (CD): is device used to hold files of project as a backup
purpose.
2.5.2.2. Software tools

The following software tools are identified to be used by group members to organize this project.
Unified modeling language (Star UML): is a standardized modeling language, used to draw all
diagram needed while designing the proposed system.
HTML: Hypertext Markup Language, a standardized system for tagging text files to achieve font,
color, graphic, and hyperlink effects on World Wide Web pages.
PHP: PHP (Hypertext Preprocessor) is a widely-used open source general-purpose scripting

language that is especially suited for web development and can be embedded into HTML.
JAVASCRIPT: an object-oriented computer programming language commonly used to create

interactive effects within web browsers.
AJAX: Ajax is a client-side script that communicates to and from a server/database without the need
for a post back or a complete page refresh. Ajax is the method of exchanging data with a server, and
updating parts of a web page -without reloading the entire page.
XAMPP MySQL server: allows users to define the data in database and manipulate that data.
Notepad: it is an editor for the code

2017
Microsoft word: for the preparation of the documentation.
Microsoft power point: for presentation.
2.5.3. Minimum hardware and software requirements
2.5.3.1. Minimum hardware requirements

 PC (client, server)
 Processor: INTEL core i3
 RAM(random access memory) : minimum of 5GB
 Hard Disk: 600GB
 Flash:- for storage purpose
 Processing power
2.5.3.2. Minimum software requirements

 Operating System Microsoft Windows 8 or higher.
 Web Server Apache 2.2.6 or higher.
 Relational Database Management System MySQL 5.0.45 or higher
 Internet Browser UC browser 5.5.6 or higher.
 Programming languages PHP 1.7.4 or higher, JavaScript, HTML5.
2.6. System analysis tools and techniques employed

2.6.1. Data flow diagrams
Registrar system data flow diagram is used to shows how data flows in a system. It contains four
basic components. These are:
1. Entity: - An entity of registrar system is the source or destination of data. The source in a
DFD represents these entities that are outside the context of the system. Entities either
provide data to the system (referred to as a source) or receive data from it (referred to as a
sink). Entities are often represented as rectangles
2. Process: - is a place where input is given to the registrar system and output is generated
from the registrar system.
3. Data store: - is a place where a process stores data between processes for later retrieval
by that same process or another one.

2017
4. Data flow: - the movement of data between the entities in registrar system is represented
by data flow.
Based on AUWC registrar system activities, we represent the flows of data as follows:
Register 1. Registrar Registered Student

Student Registration confirmation slip system
Department
Student Evaluation
1. Student
Registered Student
Record Student Evaluation Result 2. Provide
Course
Grade Report/Transcript Academic Record
Complete
d
Figure 3: first level Data flow diagram for AUWC registrar system

2017
Register for course Registered student

1. Registrar Department
Add course
Student System
Drop Course
Withdraw
Manage
1. Student
Record
Instructor
2. Course
1.1. Student Catalogue Accessed by
Academic
Result Add Marks
3. Academic
Rule and
regulation
1.3. 1.4. 1.5.
Check Course Determine Check
prerequisite Status Availability
1.1. 1.2.
Accessed by
Check Check
minimum maximum
credit hour Credit hour
1.2. Drop 1.3. Add

course course 1.4. Registered for course student
Student student record
record record
Add assessment rule
Figure 4: Second level data flow diagram for AUWC Registrar system

2017
2.7. Requirement analysis
2.7.1. Functional requirement of the project
1. The system enables users (Administrator, student, department head, instructor, dean,
Admission officer, Record officer, Deputy of registrar and registrar head) to login by
entering correct user type, username and password.
2. The system enables system administrator to manage user (create account for the new
users, delete existing account when account holder is graduated or dismissed, block
student account for the specified time if the student status is academic dismissal with
re-admission).
3. The system shall be able to deliver messages for the directed person through his/her
account.
4. The system enables registrar to manage student information such as student first name,
last name, sex, age, department, etc. (Insert student information, delete student
information, update student information, view student information and etc.).
5. System enables student, department head and instructors to view student information.
6. The system enables department head to manage instructor information such as
instructor id, instructor first name, instructor last name, instructor sex, instructor
qualification, instructor department, etc. (Insert instructor information, delete instructor
information, update instructor information, view instructor information and etc.).
7. System enables student, department head and instructors to view instructor information.
8. The system enables department head to manage course information such as course
code, course title, course class year, course semester, course credit hour, course
department, course prerequisites and etc. (Insert course information, delete course
information, update course information, view course information and etc.).
9. System enables student, department head and instructors to view course information.
10. The system enables registrar to manage classroom information including classroom id,
classroom location and etc. (Insert classroom information, delete classroom
information, update classroom information, view classroom information and etc.).
11. System record and Trace student versus course profile(displays course allowed to be
taken by individual student based on prerequisites)

2017
12. The system enables students to register online.
13. System checks prerequisites at the time of registration.
14. System generates registration slips based on student academic status(FX,NG,F,I etc.
system will be pending)
15. System is able to send online registration confirmation report for student
16. The system enables student to add course
17. System handle adding courses(check maximum semester credit hour, availability of
course)
18. System handle drop courses(check minimum semester credit hour)
19. System will generate automatic student id no for fresh man students
20. System will able to allow registrar head to post start and end date of registration for
senior and fresh students and grade submission date.
21. System enables the instructors to view grade submission date.
22. The system enables the instructors to submit Grade being online
23. The system support hierarchical approval of Grade.(instructor, Head of department,
registrar head)
24. The system will handles grade complains such as NG, I, FX, Re-grade.
25. The system generate report on special case grades(NG,I, Fx, Re-grade)
26. The system will perform automatic SGPA and CGPA calculation.
27. System enables registrar to generate GPA report.
28. The system has ability to generate grade report automatically.
29. Determine status(such warning, Dismissal, pass etc. ) and generate status
report(semester wise)
30. The system enables students to view their result by providing PIN.
31. The system allows deputy of registrar to generate final exam schedule (the system
doesn’t allows deputy of registrar to allocate classroom for final exam if it is already
reserved for another final exam).
32. System enables students and instructors to view final exam schedule.
33. The system enables the user to send their complaint and receive feedback.
34. The system enables department head and instructor to manage student’s grade
complaint (view complaint, replay for complaint, reject complaint).

2017
35. The system enables Admin to manage user’s complaint (view complaint, replay for user
complaint, reject user complaint).
36. Post top scorer list for every department semester wise
37. The system enables the registrar to post academic calendar
38. The system enables system users to search for information with respect to registrar
system using necessary key words.
39. System will provide electronic notice board for students and staff
40. System has admin side
2.7.2. Nonfunctional requirements

1. Performance:
 Defines acceptable response times for system functionality.

 The load time for the user interface screens and processing shall take little time
 The login information shall be verified within short time
 The user queries shall get result within short time
 High throughput
2. Reliability:
 Validation for user input shall be done appropriately

 Avoiding incorrect storage of data (records) shall be considered seriously
3. Scalability:
 The system’s functionality can be extended based on campus need.
4. Security:
 System will uses encrypted password to be more secured

 Only authenticated users are allowed to use the system.
 Database content is encrypted
5. Easy to use/user friendliness:
 The system will have clear interface which will be easy for its user.
 The system should provide the necessary information when the user commits
possible errors.

2017
7. Effectiveness
 The system will have the ability to perform right thing.
2.8. Feasibility analysis

2.8.1. Technical feasibility
Generally speaking, using the different techniques, we can perform the work up to the desire of
the campus, even though fulfilling a human being’s need in all directions may be difficulty and
impossible.
2.8.2. Operational feasibility

The system being developed working is quite easy to use and learn due to its simple but
attractive interfaces. User requires no special training to operate with the system.
2.8.1. Economic feasibility

The system being developed is economic with respect to AUWC point of view. It is cost
effective in the sense that has eliminated the paper work completely.
2.8.2. Schedule feasibility

Schedule feasibility determines whether the proposed system will be completed on the given
schedule or not. Whatever the scarcity of time given for the project by the internal motivation
and potential of the group members of the project, we expect the project will be completed on
time.

2017
Chapter 3
System Design
3.1. Overview of system design
Registrar system design is the process of defining its architecture, its components, its modules,
its interfaces, and data for a system to satisfy specified requirements. It is intermediate language
between requirements and code and also it is the first step in moving from problem domain to
solution domain proceeding from abstract to more concrete representations. It is a creative
activity. It determines the major characteristics of a system. In this chapter we will use different
type of diagrams that are useful to design the proposed system.
3.2. System Architecture

3.2.1. Current registrar system software architecture
The current software architecture of registrar system represents the architecture that we are going to
solve its problem with the new system. Now the system is manual and keeps all available student
information in paper-based documents and sometimes in Microsoft excel products.
3.2.2. Proposed registrar system software architecture

To solve the problem of existing system, we are going to develop the three tier client-server
architecture for AUWC online registrar system. In three tier client-servers architecture, the
functionality of the system is organized into services, with each service delivered from server.
Clients are the users of the services and access servers to make use of them. We will use this three
tier architecture because when data in a shared database has to be accessed from a range of locations.
Data tier: the data tier maintains the application data such as user’s data, department data, courses
data, student’s data, grades data, schedule data and etc.
Middle tier: the middle tier (web / application server) implements the controller logic and
presentation logic to control the interaction between the application client and data.
Client tier: the client tier is the application user interface connecting entry forms and client side
applications. It displays data to the user. The user interacts to the application through the user

2017
interface. The client tier interacts with the web /application server to make request and to retrieve
data from the registrar database. It then displays the user data retrieved from the registrar database.
To make the system economically feasible, we designed it with a single server on which registrar
application and XAMMP (web server) are installed. Web server (apache) has built in database server
called MYSQL which can be act as data tier.
Client tier Middle tier
Send request through http select
Web server(Apache)
Client 1 Registrar Application server
. mysql
Data tier
.
.
Get response through html Registrar
database
Client n
Figure 5: proposed online AUWC registrar system software architecture
3.3. UML of the proposed system

3.3.1. System Actors
Students: - register for course, view his/her own result, Add/drop course, view course detail,
view final exam schedule, view registration date, view academic calendar and etc.

2017
Instructors: - see course assigned for him/her, manipulate grade (submit grade, change grade),
request for final exam schedule, view grade submission date, etc.
Department head: -manage curriculum like registering new course, updating existing course,
deleting old course which is already out of dated, assign instructor for course, approve grade,
receive grade complaint, respond for grade complaint or reject grade complaint, view GPA
report and the like.
Registrar head: - approve grade, generate new student ID NO, deliver message to concerned
body, post grade submission date, registration date, upload academic calendar, and the like.
Deputy of registrar: - generate final exam schedule, maintain classroom information, and etc.
Admission officer: - register new and senior student, determine student status and the like.
Record officer: -record grade, calculate GPA including SGPA and CGPA, generate GPA report
and the like.
System administrator: - manage user account including creates account and deletes use account,
and handle user complaints (reject user complaint or replay for user complaint).
Dean: -responsible body to print original transcript of learners.
3.3.2. Use case Model

A Registrar system use case is an interaction between users, others components of registrar
system. It contains the goal of the users and the responsibility the registrar system provides to its
users. It is the functionality of the system or the service provided by the system.

2017
System
Register For Course Create Account Store
Drop Course
Change Password Database
Check Status
Delete Account
Add Course
Student
Update Account
With Draw
<<extend>> Receive User Complaint

View Schedule Admin
<<extend>>
Reject User Complaint
View User Profile

Edit Profile
Replay User complaint
Add Mark
Register Classroom
Verify Grade
Change Grade Delete Classroom
Deputy Registrar
Update Classroom
View Grade Submission date
Instructor
Generate Final Exam Schedule

Add assessment rule
Generate StudentID
Update Instructor
Login
Deliver Message
Register Instructor
Approve Grade Print transcript Registrar Head
Delete Instructor
Register New Student
Dep't Head Register Course

Determine Status Admission Officer
Delete Course
Senior Student
Update Course
Record Student Data
View GPA Report
Register Department
Record Officer
Comment Exam Schedule
Delete Department
Verify Transcript
Update Department
Dean
Figure 6: Use case diagram for online registrar system (part one)

2017
System
View Result Grade Submission Date

View Top Scrores Store
Request Transcript Database
Registration Date
Post Academic Notice
Student
Send Grade Complaint
Academic Calender Registrar head

View Reoprts
View Course
View Notice Logout
Record Grade
Calculate CGPA Record officer

Recieve Message
Instructor
View Academic Calender Calculate SGPA
Generate GPA Report

<<extend>> Replay Complaint
Recieve Grade Complaint
Generate Grade Report
Department head <<extend>>

Reject Complaint
Post-Top Scorers
Deputy of Registrar
ViewEligbleGraduate
Update Exam Schedule

Dean
View Transcript Request
Delete Exam Schedule
Generate Eligble Graduate Admin
Generate Received Course Report
Admission officer
Figure 7: Use case diagram for online registrar system (part two)

2017
Use case Description
 ID: Represents identification number that enables us to make the use case traceable.
 Name: Represents the name that we have used in the use case model.
 Actor: Represents who interacts with the system either internally or externally.
 Pre-condition: Represents what is the expected situation before the use case can be
started.
 Extend: - is used when we have one use case that is similar to another use case but does a
bit more.
 Main scenario (Basic flow of Events): represents the steps we have to follow to get
output we want from system.
 Alternative scenario (alternative course of action): steps we have to follow if the main
scenario is not correctly given to the system.
 Post-condition: represents what is expected output at the end of use case.

2017
Name Login
Use case ID: UC01
Brief Description When the user enters necessary information, it checks the input from
database, if it is valid user information, the user direct to access, if not it
displays error message.
Actor(s) Administrator, student, department head, record officer, admission
officer, registrar head, instructor and dean.
Pre-Condition: User must be authorized user who has username and password.
Basic flow of Events
1. Actors selects login option from main home page
2. Login interface is opened.
3. Actors enter necessary information.
4. System validate
4. System validates input against system database.
5. System accepts user type.
6. The privileged user’s home page is opened

7. use case end
Post-Condition: The user is authenticated and the system displays all features available for the role for
the user is associated.
Alternative course of action
Title Description
A1:Actors enter invalid user type, 1. The system display message “invalid user type, username or
username and password password”.
2. The system prompts the user to reenter the valid information.
3. Use case continues with step 3.
A2: if account is not existed 1. The system display Error message wrong user name or
password!
Table 6: Use case description for Login

2017
Name Create Account
Use case ID: UC02
Brief Description Allows a user to become register and to login the system
Actor(s) Admin
Pre-Condition: Admin login to the system
1. The Actor click on Create account from drop down menu of user account
2. The system displays new Account Form.
3. The Actor fills the required user account information values.
4. The Actor select Create option
5. The system verifies values entered are valid.
6. System checks as entered information already reserved by someone else
7. The system saves the new account information to the database.
8. The system notifies new account created successfully.
9. The use case end.
Post-Condition: User account is successfully created.
Title Description
1.The system prompts invalid user account

A1:Actor Enter Invalid 2.system prompts user to reenter valid user account information
User Account Information 3.use case continues with step 3
A2:Actor enters existed 1.system prompts error message

account information 2.system display account is already existed
3.use case continues with step 3
Table 7: Use case description for create account

2017
Name Delete Account
Use case ID: UC03
Brief Description User may graduate or stop because of some problems so user
account will be deleted.
Actor(s) Admin
Pre-Condition: Admin login to the system.
1. The Actor clicks Delete account from drop down menu of User account.
2. The system display list of account
3. The Actor press delete button of the account he/she want to delete
4. System asks Actor for user account deletion operation confirmation
5. Actor confirm
6. System display account deleted successfully.
7. Use case end
Post-Condition: The selected user account is successfully deleted
Title Description
A: Actor didn’t confirm 1. system cancel operation
2. use case end
Table 8: Use case description for delete account

2017
Name Update Account
Use case ID: UC04
Brief Description Admin needs to update users account
Actor(s) Admin
Pre-Condition: Admin login to the system
1. Actor clicks on Update account from drop down menu of User account.
2. System display all existing user account with update option
3. Actor select update option of the user account he/she wanted to update
4. System display form to fill
5. Actor fill all necessary information
6. System validate entered information
7. System asks the Actor for confirmation of operation (Do you want to update user account
information?)
8. Actor confirm( press Yes option)
9. System display account is update successfully.
10. use case ends
Post-Condition: The account is already updated
Title Description
A1: Invalid entry 1. System display error message.
A2: If Actor didn’t confirm 1. System cancels the operation.
2. Use case ends.
Table 9: Use case description for update account

2017
Name Register new student
Use case ID: UC05
Brief Description -
Actor(s) Admission officer
Pre-Condition: Admission officer login to the system
1. Actor selects Add new student from admission officer home page.
2. System displays a form to the User
3. Actor enters student information such as full name, id, age, birth date, region, zone, woreda,
kebele in their appropriate place provided by select each of alternative form fields.
4. Actor select Register option
5. System validate the entered value
6. System saves the new student information into the database
7. System displays as student information is registered successfully.

8. use case end
Post-Condition: The new student information has been registered.
Title Description
A. If the form is not filled 1.System display Error: fill the form properly
properly 2. Use case continues with step 3.
Table 10: Use case description for register new student

2017
Name Add assessment rule
Use case ID: UC06
Brief Description .
Actor(s) Instructor
Pre-Condition: The instructor must login to the system.
1. Actor select Add assessment rule option
2. The system displays the forms Actor has to fill.
3. The Actor fills the form with necessary information like course code, instructor id, assessment
type, mark weight and click Register button.
4. The System validate the data
5. The system checks as total mark weight is equal to 100.
6. The system save the rule to the database and display successfully added message.
7. Use case end
Post-Condition: Assessment rule has been added.
Title Description
A1. invalid entry 1.The system display invalid entry re enter
A2. If total mark weight is 1. The system display error message total mark weight
less than or greater than 100 must be equal to 100.
Table 11: Use case description for Add assessment rule

2017
Name Register Instructor
Use case ID: UC07
Brief Description Helps department head to register new instructor information
Actor(s) Department head
Pre-Condition: Department head must login to the system
1. Actor selects the Instructor option from department head home page
2.Actorselects Register instructor option
3. System displays form
4. Actor fill forms
5. System validate inputs
6. Actor select Register option
7. System save instructor information and displays as instructor is added

8. use case end
Post-Condition: The new instructor information has been registered.
Title Description
A. If the form is not filled 1.The system display message fill the form properly
Table 12: Use case description for Register instructor

2017
Name Update Instructor
Use case ID: UC08
Brief Description Instructor information may be wrongly registered then his/her

information may be updated.
Pre-Condition: Department head login into the system

1. Actor select instructor option from department head home page
2. Actor selects update instructor option
3. System display all instructor information with update option for each instructor information
4. Actor select update option of instructor he/she want to update.
5. System display form to fill a new instructor information
6. Actor fills the new information of instructor and press update button
7. System validates the input information
8. System asks actors to confirm the instructor information updating operation.
9. Actor confirm
10. System informs actor, as instructor information is updated

11. Use case end
Post-Condition: The instructor information has been Updated.
Title Description
A1. invalid entry The system display invalid entry, go to step 6.
A2. If Actor didn’t confirm 1.the system aborts the operation

2. End use case
Table 13: Use case description for Update instructor

2017
Name Delete Instructor
Use case ID: UC09
Brief Description Instructor may be change work place then his/her information may be
deleted.
Pre-Condition: Department head login to the system
1. Actor select instructor information from department head home page
2. Actor select delete instructor information link
3. System display all instructor information with delete option
4. Actor selects delete option of instructor information he/she want to delete and press delete
option
5. System asks for delete operation confirmation
6. Actor confirm the operation
7. System informs actor, as instructor information is deleted

8. Use case ends
Post-Condition: The instructor information has been deleted.
Title Description
A. Actor didn’t confirm The system cancel the operation

Table 14: Use case description for Delete instructor information

2017
Name Register Course
Use case ID: UC10
Brief Description
1. Actor selects course option from department head home page
2. Actor selects Register course option
3. System display new course registration form
4. Actor fill the forms with required course information and select register button
5. System validate the data
6. System saves the new course information to the database and displays success message.
7. Use case end
Post-Condition: The new course information has been registered.
Title Description
Table 15: Use case description for register course information

2017
Name View Course
Use case ID: UC11
Brief Description .
Actor(s) Instructor and student
Pre-Condition: Instructor and student must be login to the system
1. Actors select View Course from their home page

2. The system display the form in which the Course to be viewed is requested
3. Actors Fills all required information (dep’t, class year, semester, etc) and sent the request.
4. The system validates
5. System checks the course against the database
6. The system display detailed of course requested
7. Use case end

Post-Condition: The Course detail has been viewed.
Title Description
A1.Invalid entry 1. System display error message please fill all field with valid value.
A2. if the searched is not 1.system displays, request error

available in the database
Table 16: Use case description for view course

2017
Name Update Course
Use case ID: UC12
Brief Description Course information may be wrongly registered or its detail is changed
then its information may be updated.
1. The Actor clicks Update Course from the drop down menu of course.
2. The system display course information available with respect to his department
3. The Actor select update option of the course he/she want to update
4. The system display form with old value
5. Actor cancel the old value and fills form with new necessary information
6. The system validates filled information.
7. The system asks actor for confirmation of the update course operation.
8. Actor confirm operation
9. System update course information
10. use case end
Post-Conditions: The course information has been Updated.
Title Description
A1. invalid entry 1. The system display invalid information entering
2. Use case continues with step 5
A2. If Actor didn’t confirm 1.system cancel operation
2. use case end
Table 17: Use case description for Update course information

2017
Name Delete Course
Use case ID: UC13
Brief Description Course may be erased from curriculum then it may be deleted.
1. Actor select delete option from drop down menu of course
2. System display all courses detail with respect to his/her department with delete option for each
course
3. Actor selects Delete option of the course he/she want to delete.
4. System asks Actor for confirmation of course detail deletion operation
5. Actor confirm the deletion of course operation
6. System delete the selected course information from database and informs actor as course
information is successfully deleted
7. use case end
Post-Conditions: The course information has been deleted.
Title Description
A. if Actor didn’t confirm 1.System cancel operation

2. End use case
Table 18: Use case description for Delete course information

2017
Name Register Department
Use case ID: UC14
Brief Description Department may be opened then its information must be registered
Actor(s) Record officer
Pre-Condition: Record officer must login to the system
1. The Actor select Register department from submenu of Department

2. The system display form
3. The Actor enters department information such as department id, department name, department
location, department head name, department office number and etc. in their appropriate place
provided for each.
4. System validates the entry information.

5. System saves in the database and displays success full message
6. use case end
Post-Condition: The new department information has been registered.
Title Description
A. If the form is not filled 1.the system display message fill the form properly
properly 2. use case continues with 3
Table 19: Use case description for Register department information

2017
Name Update Department
Use case ID: UC15
Brief Description Department information may be wrongly registered or its detail is

changed then its information may be updated.
Pre-Condition: Record officer must login to the system.
1. The Actor clicks Update Department from drop down menu of Department.
2. The system displays all department information available with update option for each.
3. The Actor select update option of the department he/she want to update
4. The system display form
5. The Actor fill form with necessary information
6. The system validates filled information.
7. The system asks Actor to confirm the operation.
8. The Actor confirm operation
9. System saves changes on department information in the database and display successful
message.
10. use case end
Post-Condition: The Department information has been Updated.

Title Description
A1. invalid entry 1.The system display invalid entry re enter

A2. Actor didn’t confirm 1.System cancel operation

2. use case end
Table 20: Use case description for Update department information

2017
Name Delete Department
Use case ID: UC16
Brief Description Department is may be closed then it may be deleted.
Pre-Condition: Record officer must login to the system
1. Actor select Delete Department option from drop down menu of Department
2. System display all department information with Delete option for each
3. Actor selects delete option of department he/she want to delete.
4. System asks actors to confirm delete department information operation
5. Actor confirms
6. System delete selected department information from the database and informs actors, as
department information is deleted
7. use case end
Post-Condition: The department information has been deleted.
Title Description
A. if Actor didn’t confirm 1. The system cancel operation

2. Use case end.
Table 21: Use case description for Delete department information

2017
Name Register Classroom
Use case ID: UC18
Brief Description
Actor(s) Deputy of Registrar
Pre-Condition: Deputy Registrar must login to the system
1. Actor selects Register option from drop down menu of classroom.

2. system display form for input classroom information
3. Actor fills classroom information such as room name, building number, room description
and capacity, etc. and select register button.
4. System validate input data
5. System saves into the database and display classroom information is registered.
6. Use case end
Post-Condition: The new class room information has been registered.
Title Description
Table 22: Use case description for register classroom information

2017
Name Update classroom
Use case ID: UC19
Brief Description Classroom information may be wrongly registered or its detail is
changed then its information may be updated.
Actor(s) Deputy of Registrar
Pre-Condition: Deputy of registrar must login to the system

1. Actor select Update Classroom from drop down menu of Classroom
2. System displays all classroom information with update option for each.
3. Actor select classroom he/she want to update and press update button of it.
4. system display form to be filled
5. Actor fill all necessary information
6. Actor selects the save changes option
7. System asks actor for confirmation of updating classroom data.
8. Actor confirms.
9. System save changes in the database and displays classroom information is updated
10. use case end
Post-Condition: The classroom information has been Updated.
Title Description
A1. invalid entry 1. The system display invalid entry re enter
A2. Actor didn’t confirm 1.system cancel operation
2. use case end
Table 23: Use case description for Update classroom information

2017
Name Delete Classroom
Use case ID: UC20
Brief Description -
Actor(s) Deputy of registrar
Pre-Condition: Deputy of registrar must login to system
1. Actor selects Delete Classroom option from drop down menu of Classroom.
2. System displays all available classroom information with delete option for each classroom.
3. Actor selects the delete option of classroom he/she want to delete
4. System asks Actor to confirm the operation
5. Actor accepts the operation
6. System saves changes into the database and informs actor, as Classroom information is
deleted
7. Use case end
Post-Condition: The classroom information has been deleted.
Title Description
A1. If Actor didn’t confirm 1. The system cancel operation

2. Use case end
Table 24: Use case description for Delete classroom information

2017
Name Register for course
Use case ID UC21
Brief Description .
Actor(s) Student
Pre-Condition: Student must login to the system

1. The Actor selects Register for Course option from drop down menu of Registration.
2. The system display registration form
3. Actor fills the required information and press Register button.
4. The system validate the entered data
5. The system check student status
6. The system check available courses based on information actor enters
7. The system check for course prerequisite meet
8. The system saves to the database.
9. The system displays registration confirmation report and allows student to print/cancel it.
10. use case end
Post-Condition: Successful registration and printed/cancelled slip
A1. invalid data entry 1.The system display the entry data is invalid
A2. Student status is 1. System display error message your status not allow you to register
Add/R, D for course.
2. Use case end
A3. If prerequisite is 1. The system display the course the actor felt to register b/c of
not meet prerequisite case and display the courses that student is registered
successfully.
2. Use case end
Table 25: Use case description for Register for course

2017
Name Add course
Use case ID UC22
Brief Description .
Actor(s) Student
Pre-Condition: Student must login to the system.

1. The Actor selects Add course option from drop down menu of Register.
2. System display add course form
3. The Actor fills the form with required information and press Next button.
4. System validates the entered information.
5. The system displays the list of courses that can be added by that student.
6. Actor select add option of course/courses he/she wants to add.
7. System check maximum credit hour allowed per semester by fetching from database.
8. System saves to the database
9. The system displays Course is added success fully and allows student to print/cancel add
course confirmation report.
10. use case end
Post-Condition: Course selected is successfully added

Title Description
A1. Invalid information 1. system asks for valid information

entry 2. Use case continues with step 3.
A2. meet above maximum 1. The system display error message maximum credit hour per week
credit hour per week is reached.
Table 26: Use case description for Add course

2017
Name Drop course
Use case ID UC23
Brief Description .
Actor(s) Student
1. Actor selects the Drop course from drop down menu of Registration
2. System display the drop course form
3. Actor fills all required information and press Next Button
4. The system validate the entered information
5. The system display list of courses that student already registered for
6. Actor select the course he/she want to drop and select drop option of it
7. Check minimum credit hour allowed per semester from database
8. System asks for confirmation
9. Actor confirm
10. The system save the changes in database
11. The system display Course is dropped success fully and allows student to print/cancel drop
course confirmation report.
12. Actor can print/cancel slip.
13. use case end
Post-Condition: Course selected is successfully dropped
Title Description
A1. If Actor enters invalid 3. system asks for valid information
information 4. Use case continues with step 3.
A2. meet above minimum 1. The system display error message minimum credit hour per
credit hour per week week is reached.
A3. If student didn’t confirm Systems cancel operation.
Table 27: Use case description for Drop course

2017
Name Generate Exam Schedule
Use case ID: UC24
Brief Description .
Actor(s) Deputy of registrar
Pre-Condition: Deputy of registrar must login success fully
1.Actor Add Schedule option from drop down menu of schedule

2. The system display form to be filled
3. The Actor fills form with required information and select Add option.
4. The system validates the entered information
5. The system checks classroom capacity
6. The system checks Invigilator is free at that time
7. The system saves the schedule in database and display successful message.
8. use case end
Post-Conditions: Exam schedule has been generated successfully.
Title Description
A1. If actor enter invalid in 1. System display error message.

formation 2. Use case continues with step 3.
A2. if the student number 1.System display Error message

exceeds classroom capacity 2. Use case continues with step 3.
A3. If invigilator is not free 1. System display error message

Table 28: Use case description for generate exam schedule

2017
Name View Final Exam Schedule
Use case ID: UC25
Brief Description .
Actor(s) Instructor, student.
Pre-Condition: Instructor and student must login success fully
1.Actor Press Schedule Option from his/her own home page

2. The system display form to be filled
3. The Actor fill form with class department, class year, class semester and select view option.
4. The system validates the entered information
5. The system displays the schedule it requested.
6. The Actor views exam schedule.
7. use case end
Post-Conditions: Final schedule has been viewed.
Title Description
A1. If actor enter invalid in 3. System display error message.

formation 4. Use case continues with step 3.
A2. if the searched is not 1.system display the viewed is not found
available in the database
Table 29: Use case description for view exam schedule

2017
Name View Result
Use case ID: UC25
Brief Description .
Actor(s) Student
Pre-Condition: Student must login to the system.
1. The Actor select Result option his/her own home page

2. The system displays forms to enter id(PIN) and department
3. The Actor enter id(PIN) and department
4. The system validate the entry data
5. The system check for existing
6. System displays Result for student and allows student to print non official of it.
7. Actor prints or cancels.
8. use case end
Post-Condition: Student result has been viewed
A. invalid entry id(PIN) or dep. 1.the system display Error message

A1. searched not found 1. System display the searched no found

Table 30: Use case description for view Result

2017
Name Send Grade Complaint
Use case ID: UC26
Brief Description -
Actor(s) Student
1. Actor select Grade complaint from menu of Complaint

2. The system display the complaint form
3. The Actor fills the form with Student id, department, comment and select Send option.
4. The system validate filled information
5. The system save comment in database and display successful message
6. The use case ends.
Post-Condition: Entered grade complaint or saved suggestion
Title Description
A1: the user entered invalid data 1. The system display error message
2. The use case continues with step 3
Table 31: Use case description for send grade complaint

2017
Name Receive Grade Complaint
Use case ID: UC27
Brief Description -
Actor(s) Department head and instructor
Pre-Condition: Department head and instructor must login to the system
1. The Actors select Complaint link

2. The Actors select view complaint option
3.The system display available list of complaints
4. The Actors Read complaint already received
Post-Condition: User complaint has been viewed.
Title Description
A1. If there is no complaint 1. System display no complaint found.

received 2. Use case end
Table 32: Use case description for view grade complaint

2017
Name Replay Complaint
Use case ID: UC28
Brief Description -
Pre-Condition: Department head and instructor must login to the system
Extends: Receive grade complaint use case
1. The Actor select Reply option of complaint

2. The system display Complaint replay form
3. The Actor Write response and select Send option
4. The system save Replay in database
Post-Condition: Grade complaint has been Answered.
Title Description
Table 33: Use case description for Replay grade complaint

2017
Name Reject Complaint
Use case ID: UC29
Brief Description -
Pre-Condition: Department head and instructor must be login to the system
Extends: Receive grade complaint use case
1. The Actors select Reject complaint option

2. The system asks Actors for confirmation of the operation.
3. The Actors Confirm
4. The system display the complaint is deleted from the system successfully!
Post-Condition: Grade complaint is successfully rejected
Title Description
A1. If the actors not confirm 1. The system cancel operation
2. Use case end
Table 34: Use case description for Reject Complaint

2017
Name Post Registration date
Use case ID: UC30
Brief Description -
Actor(s) Registrar head
Pre-Condition: Registrar head must be login to the system
1. The Actor selects Post registration date from drop down menu of Academic notice
2. The system displays the form in which actor fill necessary information about registration
date like start date and end date.
3. The Actors Fill the form with necessary information and press Post button.
4. The system validates all the filled information by actor.
5. The system saves the registration date in the database.
6. The system displays successful message.
7. Use case ends.
Post-Condition: Registration date is successfully posted.
Title Description
A1. If start registration date is 1. The system display error message start date is greater
greater than end registration date than end date. Posting registration date failure
A2. If start and end registration 1. The system display error message posting already past
date is already past registration date is occur. Failure during posting of
registration date.
Table 35: Use case description for post registration date

2017
Name Add mark
Use case ID: UC31
Brief Description -
Actor(s) Instructor
Pre-Condition: Instructor must be login to the system
1. The Actor selects Add mark option

2. The system Displays the form in which actor fill necessary to request add mark form like
course code, instructor id, assessment type.
3. The Actor fills the form with necessary information and press Next button.
4. The system validates all the filled information by actor.
5. The system display the add mark form
6. The actor fills the mark detail like student id, mark.
7. The system check as Student is registered for course first.
8. The system check as mark weight is above the specified.
9. The System saves mark to the database and display successful message.
10. Use case ends.
Post-Condition: Grade is submitted successfully.
Title Description
A1. If actor enter invalid 1. The system display error message invalid data entry is
information happened.
A2. If Actor is add mark for not 1. The system display error message adding mark for not yet
registered student registered student for this course is happened.
A3. If Actor try to add above 1. The system display error message adding above specified
specified mark weight mark weight is impossible
2. Use case continues with step3.
Table 36: Use case description for add mark

2017
3.3.2. Sequence diagram
Sequence diagram is a kind of interaction diagram that show how processes registrar system’s
operate with one another and in what order.
Login
Actor HomePage
Login Controller Database
1 : open home page()
2 : Select login option()
3 : Request login form()
4 : Open Login user interface()
5 : Fill Login information()
6 : Send information()
7 : Invalid()
8 : Ivalid login information()
9 : Re enter login information()

10 : Valid()
11 : Check()
12 : Not Existed()
13 : Error: Wrong user information()
14 : Existed User account()
15 : open privelledged home!()
Figure 8: Sequence diagram for login use case

2017
Create account
Admin
Admin page Create Account Controller Database
1 : Login to()
2 : Select()
3 : Create account form request()
4 : Display SignUp Form()
5 : Enter User Information()

7 : Invalid()
8 : Invalid user Information()
9 : Re-enter User account information()

10 : Send()
11 : Valid()
12 : Send()
13 : Existed()
14 : Error: User is already existed()
15 : Not Existed()
16 : User Account is successfully created()
Figure 9: Sequence diagram for create account use case

2017
Register new student
Actor Admin page controller Database

Add new student
1 : Login to()
2 : Select()
3 : Add new student form request()
4 : Display Form()
5 : Enter new student information()
7 : Invalid()
8 : Error: Enter information properly()
9 : Re enter new student information()
10 : Valid()
11 : Register()
12 : Successful registration()
13 : New Student information is successfully registered!()
Figure 10: Register new student use case sequence diagram

2017
Register for course
Actor StudentHomePage Register page Controller Database
1 : Login to()
2 : Select register for course option()
3 : Request for course registration form()
4 : Display Form()
5 : Fill information and press register button()
6 : Send filled information()
7 : invalid()
8 : Error message: Invalid information entry()
9 : Fill valid information and press register button()
10 : Send filled information()
11 : Request student status()
12 : Student status()
13 : ADD/R, Dismissal()
14 : Error message: Your status is not allow you to register!()

15 : pass or warning()
16 : Request for available courses()
17 : Available courses()
18 : Request for previous student grade()
19 : Previous student grade()
20 : prerequisite is not meet()
21 : Save to database()
22 : Display list of courses that student felt to register b/c of prerequisite and successfully registered courses()
23 : prerequisite meet()
24 : Save to database()
25 : Successful message: You are registered for courses()
Figure 11: Sequence diagram for Register for course use case

2017
Post Registration date
Registrar head Home page

Actor Academic Notice
Controller
Database
1 : Login to the system()

2 : Select Post Registration date()
3 : Registration date form request()
4 : Display Registration date form()
5 : Fill Registration date information and press post button()
6 : Send Filled registration information()
7 : Start date is greater than end date()
8 : Error message: Start registration date is greater than end registration date()
9 : Fill start registration date which is less than end registration date and press post button()
10 : Send Filled registration date()
11 : Already past()
12 : Error Message: Already past registration date entering, please fill correct registration date()
13 : Fill Not already past registration date()
14 : Send()
15 : Save to the database()
16 : Registration date is successfully posted()
Figure 12: Sequence diagram for post registration date use case

2017
Add mark sequence
Actor Instructor Home page Add mark Controller

Database
1 : Login to()
2 : Select()
3 : Request add mark request form()
4 : Display add mark request form()
5 : Fill form with necessary information()

6 : Send()
7 : invalid()
8 : Error message: Fill valid information()
9 : Re-fill form with valid information()
10 : Send()
11 : valid()
12 : Request assement rule()
13 : Display assement rule()
14 : Display Add mark form()
15 : Fill form with student id and mark()

16 : Send()
17 : > spacified weight()
18 : Error message: You are entering wrong mark weight()
19 : <= specified weight()
20 : Request registered for course detail()
21 : Display registered for this course student list()
22 : Student id is not found()
23 : Error message: Add mark for not registered student is impossible() 24 : Student id is found()
25 : Save mark()
26 : Successful message: Mark is successfully added()
Table 37: Sequence diagram for add mark use case

2017
3.3.3. Collaboration diagram
Collaboration diagram of registrar system shows the objects and their association with other
objects of registrar system apart from how they interact with each other. In addition to this it
shows the dynamic interaction of objects in the registrar system.
Registrar system’s collaboration diagram is easily represented by modeling objects in a system

and representing the associations between the objects as links. The interaction between the
objects is denoted by arrows. To identify the sequence of invocation of these objects, a number is
placed next to each of these arrows.
1 : Enter User information()

Login UI
User
2 : Send User Information()
Database 4 : Existed User information()

Validate
Controller
+Check for existence 3 : Send Valid User Information()
5 : Open()
UserPrivellegedHomePage
Figure 13: Collaboration diagram for login

2017
5 : Select Register option()

4 : Enter New Student Information()
1 : Select AddNewStudent()
User AddNew Student UI
3 : Display Form()
9 : Successfully Registered() 2 : Request for New student registration form()
6 : Send()
Validates
8 : Successfully registration() Controller
Database
7 : Register()
Figure 14: Collaboration diagram for new student registration

2017
5 : Press Next()
4 : Fill Form with necessary information()
Actor 1 : Select Drop course option()
DropCourse UI
2 : Request Drop course Form()
6 : Send Filled information()
3 : Display Drop Course Form() 10 : Select Course Wanted to be dropped()

9 : Display List of course student registered for() 11 : Press Select Button of the course wanted to be dropped()
14 : Successfully Dropped()
Validates
13 : Save Dropped course()
Controller
8 : Display list of courses already registered for()
+Check minimum cr.hr

Database
7 : Send Request for list of courses student already registered()
12 : Send List of dropped Courses()
Figure 15: Collaboration diagram for Drop Course

2017
10 : Fill the form with student id and the mark that student scores()
Add mark UI
5 : Fill the form with necessary information and press Next button()
1 : Select Add mark option()
4 : Get Add mark request Form()

Actor
9 : Get add mark form() 11 : Send mark()
2 : Request for add mark request Form()

15 : You add mark successfully()
3 : Display add mark request form() 6 : Check validity()
8 : Display add mark form()
14 : Display successful message()
Valid?
Controller
check mark weight

13 +Registered?
7 : Select form assement rule()
12 : Save to the database()

Database
Figure 16: Collaboration diagram for add mark use case

2017
3.3.4. Activity diagram
Registrar system’s activity diagram represents the work flows in a graphical way. In our system
we used activity diagram to describe operational work flow of any component in a system. We
can use activity diagram as the alternative of state chart diagram.
Start
Open Home page
Click on Login
Openned Login interface Fill UserName, Password and UserType
System Display Error Message

No
Valid?
Yes
No System Display Error Message

Found?
Yes
Open UserType's Home Page
End
Figure 17: Activity diagram for Login Use case

2017
Start
Login to system
Select Register For Course
System Display Form
Fill the form and press Register Button
Valid? No Error Message: Enter valid information
Yes
No
Found? Error Message: Not found information
Yes
System check Student status
No
System select requested courses System Display Your status is not allow you to register
Pass, or Warning?
Yes
Yes
Prerequisite meet? System Save to Database
No
System display courses felt to register and registered successfully System Display Successful Message
END
Figure 18: Activity Diagram for Register for course use case

2017
Start System Display Add course form Fill Add course Form
Actor Login to the system Actor Select Add Course option Error Message: Enter valid information
Press Next Button
Error Message: Not found information
Valid? No
Yes
No
Found?
Yes
Actor Selects Course Want to Add
System Check maximum credit hour Error Message: Maximum credit hour reached
is above maximum? Yes

No
System Save to database
System Display successful message
End
Figure 19: Activity Diagram for Add course use case

2017
Start
Actor Login to the system
Actor Select Register Option
Actor Select Drop Course System Display form
Actor Fill Form

Error Message: Enter valid information
Actor press Next Button
No
Valid?
Yes
System Display courses Actor already registered for
Actor Select Course want to drop

Error Message: Below Minimum Credit hour
System Checks Minimum Credit hour
No
>=Minimum?
Yes
System asks for Actor Confirmation
Confirmed?
Yes No
Save Changes in Database
System Display Successful Message System Canel Operation
End
Figure 20: Activity diagram for Drop course use case

2017
Start
Actor Login to System
Actor Select Add Schedule option
System Display Form
Actor Fill Form with necessary information
System Validates entered data
No
Valid?
Yes
System Check classroom capacity System check invigilator is free
Yes No
No Yes Free?
Below?
System Saves schedule in the database
End
Figure 21: Activity diagram to generate final exam schedule use case

2017
START
Actor Select Post registration date from drop down menu of Academic notice
System Display Form
Actor Fill Form and press post button
Error Message: Fill Valid information No

Valid?
Yes
YES
Error Message: Start date cannot be greater than end date
Start Date> End Date
NO
Error Message: Posting already past registration date YES NO

Save to the database
Already Past?
Display Successful message
END
Figure 22: Activity diagram for post registration date use case

2017
START
Actor Select add mark option
System display add mark request form
Actor Fill the form with necessary information
Error message: Enter valid information Yes

System display add mark form
Valid?
No
Actor fill form with student id and mark that student scores
System check for mark weight
Yes
Error message: Mark weight should not be above specified
Above specified?
No
System check as student is registered for this course
Error message: Add mark for not registered student is impossible Yes
system save mark to database and display successful message
Registered?
No
END
Figure 23: Activity diagram for add mark use case
3.3.5. Class diagram

The following class diagram depicts the registrar system’s object structure. It shows object classes that the
registrar system is composed of as well as the relationships between those object classes.

2017
Is a Registration
School/College
Person +ClassYear
Grade +schoolID
+Semester
+Fname +GradeID View +schoolName
+Add Course()
+Mname +Letter +Dep'tID 1
Student +Drop Course()
+Lname +Point * Course
+StudID +RegisterForCourse()
+Gender +CourseCode * -CourseCode
1..
+PhoneNumber +StudID +Dep't *
-Module
*
+EmailAddress +CalculateGPA() * +SendGradeComplaint()
-Title
+DoB +View GPA() * +ReceiveReplay()
-Cr.Hour *
+Region +ViewGrade()
Offer
+View Mark() View Request -Prereq.Cocode
+Woreda +ViewCourse() 1
+Kebele +ViewCourse()
*
+ProfilePic * * Calculate
*
1 Transcript
Manipulates
* View
+TranscriptID
Report Has
* +Uni.Name
1
Read
Is a +ReportID Belongs to +OwnerName
Belongs to
*
1..* +ReportType +DateOfIssued
View
*
+GenerateGPA Report() +RequestTranscript()
+Generate GradeReport() 1 +PrintTranscript()
Instructor +GenerateElligbleGraduateReport()
+InstID +GenerateStatusReport()
Record Officer
Generate
+Dep't +ViewReport() 1..*
* 1
-Salary +RecordOfficerID
+Teaches Course() *
Generate
+ManageDepartmentData() Department
+ManipulateGrade() 1 +ManageStudentData()
+ReceiveGradeComplaint() +PostTopScorers() +Dep'tID
+ReplayGradeComplaint() 1 +Dep'tName *
Admission Officer 1
1
+RejectGradeComplaint() View +OfficeNumber
1
+AdmID
1
*
Has +Location
-FirstName -SchoolID
Replay/Reject
*
1 Account
1 -MiddleName
+RegisterCourse()
0..* -LastName +UserName
has +AssignInstructor()
-EmailAddress Has +Password
1 +UpdateCourse()
+GenerateElligbleGraduate() +UserType 1 1 +DeleteCourse()
+GenerateReceivedCourseReport() -Security question
+ApproveGrade()
+GenerateStatusReport() -Security answer
1 +ReceiveGradeComplaint()
Print
+Login() +ReplayGradeComplaint()
Has +ChangePassword() +RejectGradeComplaint()
1 +EditProfile() +RegisterInstructor()
Read
Has +Logout() +UpdateInstructor()

1
* +DeleteInstructor()
1
1 H as
1
1
1
* Has
Manages
1..* 1..*
*
1 .
Deputy Of Registrar Registrar Head 1

.*
1..
Academic Notice
*
+DeputyID +RegistrarHeadID
H as
+Fname +NoticeID +Fname Dean
+Mname 1 +NoticeTitle +Mname 1
+Fname
+Lname +NoticeBody +Lname
Post -EmailAddress +Mname
-EmailAddress Read +PostMessage() +Lname
*
-OfficeNumber +ReadMessage() -TelephoneNumber

-SchoolID
+GenerateExamSchedule() +PostRegistrationDate() +ApproveGrade() -OfficeNumber Read
+ManageClassroomData() * +ReadRegistrationDate() 1 +GenerateStudentID() 1 -Telephone number
1
+PostGradeSubmissionDate() +PrintTranscript()
Manages
* -EmailAddress
1 Generate +ReadGradeSubmissionDate() Read +CommentFinalExamSchedule()
+PostAcademicCalender()
1..* +VerifyTranscript()
+ReadAcademicCalender() 1
Has
*
Schedule
*
+SchedID Comment
+ClassYear
+Semester Complaint
+Day +ComplaintID Replay/Reject 1 1
+TimeStart Classroom +ComplaintType
+TimeEnd +RoomID +Description
+RoomID +Name +SenderName
+InstID Admin
+Description +ReceiveGradeComplaint()
+CourseCode +Capacity +ReplayGradeComplaint() +AdminID
+GenerateSchedule() * +RegisterClassroom() +RejectGradeComplaint() +CreateUserAccount()
0..* 0..1
+ViewSchedule() +UpdateClassroom() +RecieveSystemComplaint() +DeleteUserAccount()
+CommentSchedule() +ViewClassroom() +ReplaySystemComplaint() *
1 * +RejectSystemComplaint()
+DeleteClassroom()
Figure 24: Class diagram for online registrar system

2017
3.3.6. Component diagram
Component diagram of registrar system is used to shows which component or objects of registrar
system and what type of security infrastructures it is using. Registrar system is decomposed into
the following components:
1. User account management: is the subsystem of registrar system in which registrar system
user’s security information is managed by using encryption mechanism.
2. Report management: is the subsystem of registrar system in which report generated in the
system like GPA report, Grade report, Status report and etc are managed.
3. Grade management: is the major subsystem of registrar system in which Grade of
students is processed. This component focuses on the Grade submission, Grade approval,
GPA calculation, grade access, and related activities.
4. Academic notice management: is registrar subsystem in which academic related notices
like academic calendar, registration date, grade submission date and etc are transferred to
concerned body.
5. Registration management: is a major component of registrar system in which current and
new student registration is managed. This component is also concerned with add/ drop
course/courses, register for course, withdraw class, and related activities.
6. Schedule management: is a registrar system’s component in which final exam is
generated and accessed by concerned body.
7. Transcript management: is a registrar system component in which student’s transcript
request and transcript printing activities are managed.
8. Department information management: is a registrar system component in which
department details like department location, department name, department id, department
chair man and etc is managed
9. Instructor information management: is the registrar system component in which
instructor’s information like instructor id, instructor name, instructor department, instructor
salary, and etc is maintained.
10. Student information management: registrar system component in which student details is
maintained.
11. Course information management: registrar system component in which course details is
organized and processed.

2017
Client
System client
Dean Dep't head Admin Admission officer Registrar head Deputy of registrar Record officer
Instructor Student
http
Web server
Instructor information management Academic Notice management
Registrar Application
Report management
Course information management
Grade management
Student information management
Department information management
Registration management
Transcript management
Schedule management User account mamangement

Access Control
Security
Encription
MYSQL Server
MYSQL
AUWC Registrar Database
Figure 25:- Component diagram for online registrar system

2017
3.3.7. Deployment diagram
Online registrar system used deployment diagram to represent a static view of the run-time
configuration of processing nodes and the components that run on those nodes. In other words,
deployment diagrams show the hardware for our system, the software that is installed on that
hardware, and the middleware used to connect the disparate machines to one another.
Web server/Apache Server
ApplicationServer
PC
Web browser TCP/IP HTTP Registrar System Application
Chrome Internet Explorer
MYSQL
UC browser Mozilla
MYSQL Server
Database
Figure 26:- Deployment diagram for online Registrar system
3.4. Data persistence modeling

Persistent model describes the persistent data stored by the system and the data management
infrastructure required for it. Our system will use the MySQL database engine for storing data.

2017
3.4.1. Entities, attributes and schema
Registrar system needs well designed database to maintain information about its entities. To
design well database it is necessary to identify the entities in the registrar system with their
perspective attributes and what is the relationship between them. In our system we identify the
following entities:
Entity Attributes
Person PersonID, Fname, MName, Lname, PhoneNumber, EmailAddress,
DOB(date of birth), Region, Zone, Woreda, Kebele, ProfilePic
Instructor InstID, Department, salary, PersonID, UserID
Student StudID, Dep’tID, PersonID, UserID
Department Dep’tID, Name, Location, Officenumber, chairman, UserID, SchoolID
Course CourseCode, Module, CourseCode, Cr.Hour, prerequisite
Grade GradeID, Letter, point, StudID, CourseCode
Report ReportID, ReportType
Schedule SchedID, ClassYear, Semester, Day, TimeStart, TimeEnd, CourseCode,
InstID, RoomID
Registrar Head RegistrarHeadID, Fname, Lname
AdmissionOfficer AdmID, Fname, Lname
RecordOfficer RecordofficerID, Fname, Lname
Registration StudID, ClassYear, Semester, CourseCode, RegisteredDate
Admin AdminID, UserName, Password,
Account UserID, Username, Password, UserType, securityQuestion, securityAnswer
Transcript TranscriptID, Uni.name, StudID, Dep’tID, DateOfIssued, etc
School/College SchoolID, SchoolName, Dep,tID
Dean DeanID, FirstName, MiddleName, LastName, OfficeNumber,
TelephoneNumber, SchoolID, EmailAddress
Table: Registrar system entities with its attributes
In above table attributes which is singly underlined is primary key and double underlined one is
foreign key.

2017
3.4.2. ER-diagram
Online registrar system used the following ERD to depict the relationship between the entity’s
data stored in registrar database. The primary purpose of this ERD is to represent data objects
and their relationships.
MName LName Gender
FName
schoolID PersonID
PhoneN
Kebele
COLLEGE/SCHOOL AdmID
Woreda Fname
1 PERSON Lname
Email
Region
SchoolName Be ProfilePic ADMISSIONOFFICER
SchoolID lon
gs DOB
to Section 1 1 1
InstID Salary Dep’tID
IS A
StudID
1 Register
1..M INSTRUCTOR M
1...M 1
M STUDENT
M
Dep’tID Chairman M
1
Name
Generate
InstID 1...M 1...M
Assign DEPARTMENT Belongs StudID
1
1...M RegistrationID
AssID Dep’tID
OfficeNumber Semester Registration
CourseCode Offers M
Password ReportID
M RegisteredDate REPORT
Prerequisite Class year CourseCode
M
Teaches M
M COURSE ReportType
Cr.hour
Letter
CourseCode GradeID
Course Title Module Has
CourseCode
GRADE
Dep’tID Point Generate
M M StudID
Manipulates
UserType
Username UserID
RecordofficerID 1
Password
Has Fname
RECORDOFFICER
1 1 Record Lname
ACCOUNT 1
1 1 1
M 1 Dep’tID
AdminID Has Generate
Add
1
Uni.name
UserName ADMIN
H as M
TranscriptID
1 Day CourseCode
TimeStart TRANSCRIPT
Password
DateOfIssued
InstID M
TimeEnd StudID
RoomID SCHEDULE Print
1...M ClassYear
DoRID Generate 0...M 1 Lname
Semester
1 SchedID
Fname 1 1 DEAN Fname
DEPUTYOFREGISTRAR Dean ID
Lname
Description Comment
NoticeID
Capacity Manage
RoomID M NoticeTitle
1
CLASSROOM M ACADEMICNOTICE
RoomName REGISTRAR HEAD 1 NoticeBody
1
RegistrarHeadID PostedDate
Lname Fname Post NoticeType
Figure 27: Entity Relationship Diagram for online registrar system

2017
3.4.3. Referential integrity and constraints
Referential integrity is a relational database concept in which multiple tables share a relationship
based on the data stored in the tables, and that relationship must remain consistent.
Person

2017

2017

2017
3.4. 4. Database table schema
Person: - stores personal details.

Field Name Data type Null Primary key Foreign key Reference table
PersonID Varchar(20) No Yes - -
Profilepic blob No - - -
FName Varchar(20) No - - -
MName Varchar(20) No - - -
LName Varchar(20) No - - -
Gender Char(1) No - - -
PhoneN Int(10) Yes - - -
Email Varchar(20) Yes - - -
DOB Date No - - -
Region Varchar(20) No - - -
Woreda Varchar(20) No - - -
Kebele Varchar(20) No - - -
Account:- stores system’s user security details

UserID Varchar(20) No Yes - -
UserName Varchar(20) No Unique - -
Password Varchar(20) No - - -
UserType Varchar(20) No - - -
Security Varchar(100) No - - -
question
Answer Varchar(50) No - - -

2017
Admin:- stores system’s administrator security information

AdminID Varchar(20) No Yes - -
UserID Varchar(20) No - Yes Account
Department:- stores department details

Dep’tID Varchar(20) No Yes - -
Name Varchar(20) No - - -
Chairman Varchar(20) No - - -
Location Varchar(20) No - - -
Officenumber Varchar(20) No - - -
Instructor: -stores instructor details

InstID Varchar(20) No Yes - -
UserID Varchar(20) No - Yes User
PersonID Varchar(20) No - Yes Person
Dep’tID Varchar(20) No - Yes Department
Qualification Varchar(20) No - - -
Salary Varchar(20) No - - -

2017
Student: -stores student details
StudID Varchar(20) No Yes - -
UserID Varchar(20) No - Yes User
PersonalID Varchar(20) No - Yes Person
Course:- stores course details

CourseCode Varchar(20) No Yes - -
Module Varchar(20) No - - -
CourseTitle Varchar(20) No - - -
Cr.Hour Int(2) No - - -
Prerequisite Varchar(20) Yes - - -
Room:- stores Classroom details

RoomID Varchar(20) No Yes - -
RoomName Varchar(20) No - - -
Capacity Int(2) No - - -
Description Varchar(20) No - - -

2017
Schedule:- stores final exam schedule
SchedID Varchar(20) No Yes - -
RoomID Varchar(20) No - Yes Room
CourseCode Varchar(20) No - Yes Course
InstID Varchar(20) No - Yes Instructor
ClassYear Varchar(20) No - - -
Semester Varchar(20) No - - -
Day Date() No - - -
TimeStart time No - - -
TimeEnd time No - - -
Grade:- stores students grade details

GradeID Varchar(20) No Yes - -
StudID Varchar(20) No - Yes Student
Letter Varchar(2) No -
Point Float(2,2) No - - -

2017
Add Course:- stores added courses details
Add_CourseID Int(5) No Yes - -
StudentID Varchar(20) No - Yes Student
Drop course:- stores dropped courses details

Drop_CourseID Int(5) No Yes - -
StudentID Varchar(20) No - Yes Student
Registration:- stores students details who register for courses

RegistrationID Int(5) No Yes - -
ClassYear Varchar(2) No -
Semester Float(2,2) No - - -
RegisteredDate Date() No - - -

2017
GPA:- stores SGPA and CGPA of students
GPAID Varchar(20) No Yes - -
GradeID Varchar(2) No - Yes Grade
SGPA Float(2,2) No - - -
CGPA Varchar(20) No - - -
As we try to mention on Entity relationship, Designed registrar system can generate different
reports like received course report, grade report, eligible graduates report, GPA report and etc by
selecting the necessary information from above mentioned table.
GPA Report:- stores number of students who score between a given SGPA and CGPA
interval
GPAReportID Varchar(20) No Yes - -
GPAID Varchar(20) No - Yes GPA
Min. SGPA Float(1,2) No - - -
Max. SGPA Float(1,2) No - - -
Min. CGPA Float(1,2) No - - -
Max. CGPA Float(1,2) No - - -
Student Int(5) No - - -
Number

2017
3.4.5. Normalizations
In our registrar system we use normalization mechanism to organize the data of registrar system
and to keep its consistency.
1st NF
 Any row must not have a column in which more than one value is saved.
2nd NF
 Every column in the table must fully dependent on primary key.
Person table
Profilepic
PersonID
MName
PhoneN
Woreda
LName
Gender
FName
Region
Kebele
Email
DOB
1 Mili Leta Gobu 0936 M Mi@, Le@ 11/5/1995 Oromia Woliso 02
1st NF of person table is:
Profilepic
PersonID
MName
PhoneN
Woreda
LName
Gender
FName
Region
Kebele
Email
DOB
1 Mili Leta Gobu 0936 M Mi@ 11/5/1995 Oromia Woliso 02

1 Mili Leta Gobu 0936 M Le@ 11/5/1995 Oromia Woliso 02
2nd NF of person table is:
PersonID Email
1 Mi@
1 Le@

2017
Profilepic
PersonID
MName
PhoneN
Woreda
LName
Gender
FName
Region
Kebele
DOB
1 Mili Leta Gobu 0936 M 11/5/1995 Oromia Woliso 02
Grade table
GradeID StudID CourseCode Letter Point

1 037/06 ITec2022 A 20
ITec2023 A- 18.75
ITec2024 A+ 20
1st NF of grade table is:
GradeID StudID CourseCode Letter Point

1 037/06 ITec2022 A 20
1 037/06 ITec2023 A- 18.75
1 037/06 ITec2024 A+ 20
2nd NF of Grade table is:
GradeID CourseCode Letter Point

1 ITec2022 A 20
1 ITec2023 A- 18.75
1 ITec2024 A+ 20
GradeID StudID
1 037/06

2017
Instructor table
InstID UserID PersonID Dep’tID Qualification Salary

1 1 1 1 MScs in IT, Bsc in Software engineering 14,000.00
1st NF of Instructor table is:
InstID UserID PersonID Dep’tID Qualification Salary

1 1 1 1 MScs in IT 14,000.00
1 1 1 1 Bsc in Software engineering 14,000.00
2nd Normal form of instructor table:
InstID qualification
1 MScs in IT
1 Bsc in Software engineering
InstID UserID PersonID Dep’tID Salary

1 1 1 1 14,000.00
Drop course table
Drop_CourseID CourseCode StudentID Dropped date Remarks

1 ITEC2020, ITEC2021 IT-RW/037/06 21/06/2017, Prerequisite problem
22/06/2017
1st Normal form of Drop course table:

1 ITEC2020 IT-RW/037/06 21/06/2017 Prerequisite problem
1 ITEC2021 IT-RW/037/06 22/06/2017 Prerequisite problem

2017
2nd normal form of drop course table:
Drop_CourseID CourseCode
1 ITEC2020
1 ITEC2021
StudentID Dropped date Remarks

IT-RW/037/06 21/06/2017 Prerequisite problem
IT-RW/037/06 22/06/2017 Prerequisite problem
Drop_CourseID StudentID
1 IT-RW/037/06
Add course table

1 ITEC2020, ITEC2021 IT-RW/037/06 21/06/2017, Prerequisite problem
22/06/2017
1st Normal form of Add course table:
Drop_CourseID CourseCode StudentID Added date Remarks

1 ITEC2020 IT-RW/037/06 21/06/2017 Dropped last year
1 ITEC2021 IT-RW/037/06 22/06/2017 Dropped last year
2nd normal form of Add course table:
Add_CourseID CourseCode
1 ITEC2020
1 ITEC2021
StudentID Added date Remarks

IT-RW/037/06 21/06/2017 Dropped last year
IT-RW/037/06 22/06/2017 Dropped last year
Add_CourseID StudentID
1 IT-RW/037/06

2017
3.5. User interface of the prototype
Home page

2017
Login page

2017
Admin home page

2017
Student Home page

2017
Department head home page

2017
Instructor home page

2017
Registrar head home page

2017
Record officer home page

2017
Reference
Jeffrey L. Whitten and Lonnie D. Bentley (2007), System analysis and design methods,
seventh edition
Jim Arlow and Ila Neustadt(2006), UML 2 and the unified process, Second edition
Timothy C. Lethbridge and Robert Lagniere (2005), Object-Oriented Software Engineering

Practical software development using UML, Second edition

2017
Appendix
Interview questions
While requirement collection for the development of AUWC registrar system we use interview to get
over view of existing AUWC registrar system. We interview with registrar head office by asking the
following interview questions:
1. How existing registrar system is working?

a. How to register students? What are the possible list activities to handle student
registration?
b. How to handle student record? Where and how you are storing student’s data?
c. How to generate student grade report?
d. How to prepare final exam schedule?
e. How to generate id number for students?
f. How to manage grade and special case grade?
2. What are the major problems you are facing?
3. Are you interested computerized solution for problem you are facing?

AUWC Registration System

Uploaded by

Copyright:

Available Formats

AUWC Registration System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AUWC Registration System

Uploaded by

Copyright:

Available Formats

Ambo university woliso campus online Registrar system

Ambo University woliso campus

TITLE: ONLINE REGISTRAR SYSTEM OF AUWC

Approved by examination committee

Advisor’s name Advisor’s signature

Examiner’s name Examiner’s signature

AUWC, Information Technology Department Page i

Full Name Signature

Advisor’s Name Signature

AUWC, Information Technology Department Page ii

AUWC, Information Technology Department Page iii

AUWC, Information Technology Department Page iv

SGPA: Semester grade average point

CGPA: cumulative grade average point

ID NO: identification number

SMS: short message service

SRS: system requirement specification

CEP: continue Education program

LEH: Lecture Hour

AU: Ambo University

DFD: Data Flow Diagram

AUWC, Information Technology Department Page v

AUWC, Information Technology Department Page vi

AUWC, Information Technology Department Page vii

AUWC, Information Technology Department Page viii

AUWC, Information Technology Department Page ix

Table 1: Team composition .......................................................................................................................... 9

AUWC, Information Technology Department Page x

AUWC, Information Technology Department Page xi

1.2. Background of the organization

1.3. Background of the system

By AUWC Information Technology 4th year students Page 1

1.4. Statement of the problem

AUWC, Information Technology Department Page 2

1.5. Objectives of the project

1.5.1. General objective

1.5.2. Specific objectives

AUWC, Information Technology Department Page 3

1. 6. Scope and limitation of the project

AUWC, Information Technology Department Page 4

This project can be used by other universities.

1.6.2. Limitation of the project

1.7. Risks, constraints and assumption

AUWC, Information Technology Department Page 5

1.8. Significance of the project

AUWC, Information Technology Department Page 6

1.9. Beneficiaries of the project

AUWC, Information Technology Department Page 7

AUWC, Information Technology Department Page 8

Task Group member Name

1.10.2. Budget schedule

Reason of payment Amount Unit price Total price in Birr

AUWC, Information Technology Department Page 9

Figure 1: project plan

AUWC, Information Technology Department Page 10

System requirement specification

2.2. Major functions of existing registrar system

 Prepare the academic calendar of the University each year.

 Arranges the preparation and issuance of ID cards to admitted students.

 Maintains files for admitted students in the Regular and CEP.