Final Project Documentation

COLLAGE OF CONFUTING AND INFORMATIC
DEPARTMENT OF INFORMATION SCIENCE

PROJECT TITLE: HARAMAYA UNIVERSITY ONLINE CLERANCE SYSTEM
GROUP MUMBER ID
1. BEREKET PAULOS 0599/13
2. BETSELOTE TADESSE 3135/12
3. EYOSIYAS BEFIRDU 1042/13
4. FRDOS HASEN 1173/13
SUMITTE TO: INFORMATION SCICENCE DEPARTMENT
SUBMISSION DATE: JANUARY 10, 2024.

HARAMAYA UNIVERSITY STUDENT’S ONLINE CLEARANCE SYSTEM
APPROVAL PAGE
Advisor Name: - ____________________________________________________
Comments
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Date ________________________ signature

____________________
1|Page
Acknowledgment
2|Page
Abstract
Online The online clearance processing system is a project work that will help to build an
effective information management for the Haramaya University. It is aimed at developing a
system for making clearance for the students. The designed software will serve as a more
reliable and effective means of understanding student’s clearance remove all to delay and
stress as well as enable the user of the system to understand the procedures involved and how
to do their clearance online. This project will be done by collecting the data from the
University. The project is aimedaims to achieve an effective and efficient clearance process
system for the students of Haramaya University. Moreover, the design and implementation
will be carried out using HTML, CSS, PHP, JAVASCRIPT, APACHE Server, and MYSQL
for data base.
3|Page
Table of Contents
APPROVAL PAGE..................................................................................................................................
Acknowledgment......................................................................................................................................
Abstract.....................................................................................................................................................
LIST OF FIGURE AND TABLE.............................................................................................................
LIST OF ACRONYMS AND ABBREVIATION....................................................................................
Chapter One.............................................................................................................................................
INTRODUCTION...................................................................................................................................
1.1 Introduction clearance...................................................................................................................
1.2 Background of the project.............................................................................................................
1.3 Background of the organization....................................................................................................
1.3.1 Vision..........................................................................................................................................
1.3.2 Mission.......................................................................................................................................
1.3.3 Goal............................................................................................................................................
1.4 Statement of the problem...............................................................................................................
1.5 Objective of the project.................................................................................................................
1.5.1 General Objective.......................................................................................................................
1.5.2 Specific Object...........................................................................................................................
1.6 Methodology for the project..........................................................................................................
1.6.1 Data source.................................................................................................................................
1.6.2 Fact Finding Techniques............................................................................................................
1.7 Scope of the project.......................................................................................................................
1.8 Significance of the project.............................................................................................................
1.9 Feasibility Analysis.......................................................................................................................
1.9.1 Operational Feasibility...............................................................................................................
1.9.2 Technical Feasibility...................................................................................................................
1.9.3 Economic Feasibility..................................................................................................................
1.9.4 Behavioural/Political Feasibility................................................................................................
1.9.5 Schedule Feasibility....................................................................................................................
1.10 System Analysis and Design.......................................................................................................
1.11 Development Tools......................................................................................................................
1.12 Implementation............................................................................................................................
1.13 Testing Procedures......................................................................................................................
4|Page
1.14 Target beneficiaries of the system...............................................................................................

1.15 Team compositions......................................................................................................................
Chapter Two............................................................................................................................................
Description of the Existing System.........................................................................................................
2.1 Introduction...................................................................................................................................
2.2 System Requirement Specification (SRS).....................................................................................
2.2.1 use case diagram.........................................................................................................................
2.2.2 Use case descriptions..................................................................................................................
2.2.3 Analysis Level Class Diagram...................................................................................................
2.3 Supplementary specification..........................................................................................................
2.4 Introduction of the Existing System..............................................................................................
2.4 Players in the Existing System......................................................................................................
2.5 Major functions/activities in the existing system..........................................................................
2.5.1 Input Analysis.............................................................................................................................
2.5.2 Process Analysis.........................................................................................................................
2.5.3 Output Analysis..........................................................................................................................
2.6 Business Rules...............................................................................................................................
2.7 Report generated in the existing system........................................................................................
2.8 Forms and Other Documents of the Existing System....................................................................
2.9 Bottlenecks of the Existing System...............................................................................................
2.9.1 Performance (Response time).....................................................................................................
2.9.2 Input (Inaccurate/redundant/flexible) and Output......................................................................
2.9.3 Security and Controls.................................................................................................................
2.9.4 Efficiency....................................................................................................................................
2.10 Practices to the Preserved............................................................................................................
2.11 Proposed Solution for the new System that address problems of the Existing System...............
2.12 Requirements of the Proposed System........................................................................................
2.12.1 Functional requirements...........................................................................................................
2.12.2 Non-functional requirements....................................................................................................
2.13 Limitation of the project..............................................................................................................
1.14 Risks and Contingencies..............................................................................................................
1.15 Assumptions and Constraints......................................................................................................
5|Page
Chapter Three..........................................................................................................................................
System Analysis......................................................................................................................................
3.1 Introduction...................................................................................................................................
3.2 Sequence Diagram.........................................................................................................................
3.3 Collaboration Modelling................................................................................................................
3.1 Component Modelling...................................................................................................................
3.2 Activity Diagram...........................................................................................................................
3.3 State chart modelling.....................................................................................................................
3.4 Persistence modelling....................................................................................................................
3.5 Deployment modelling..................................................................................................................
3.6 Normalized Physical Database Model..............................................................................................
CHAPTER FOUR...................................................................................................................................
4.1 Implementing strategies....................................................................................................................
4.2 Testing...............................................................................................................................................
4.3 Unit Testing.......................................................................................................................................
4.4 Integration Testing............................................................................................................................
4.5 System testing...................................................................................................................................
CHAPTER FIVE.....................................................................................................................................
5.1 Conclusions.......................................................................................................................................
6|Page
LIST OF FIGURE AND TABLE
Fig 1.1 Gantt chart...................................................................................................................................
Table 1.1 Hardware Requirement Cost...................................................................................................
Table 1.2 Development Tools..................................................................................................................
Fig 1.2 Team composition.......................................................................................................................
Table 1.3 Work break down structure.....................................................................................................
Figure 2.1 Use case diagram....................................................................................................................
Table 2.1 Use case description for Create Account.................................................................................
Table 2.3 Use case description for Registration......................................................................................
Table 2.4 Use case description for Delete...............................................................................................
Table 2.5 Use case description for Update..............................................................................................
Table 2.6 Use case description for view profile......................................................................................
Table 2.7 Use case description for Search...............................................................................................
Table 2.8 Use case description for Approve............................................................................................
Table 2.9 Use case description for Generate Report...............................................................................
Table 2.10 Use case description for Request...........................................................................................
Fig 2.2 Analysis Level Class Diagram....................................................................................................
Fig 2.3 Students Clearance form.............................................................................................................
Fig 3.1 Sequence diagram for Create Account by Admin and Offices...................................................
Fig 3.2 Sequence diagram for registration...............................................................................................
7|Page
Fig 3.3 Sequence diagram for login.........................................................................................................
Fig 3.6 Sequence diagram for Search......................................................................................................
Fig 3.7 Sequence diagram for Delete......................................................................................................
Fig 3.9 Sequence diagram for Generate Report.......................................................................................
Fig 3.10 Sequence diagram for Request..................................................................................................
Figure 3.11 Component modelling diagram............................................................................................
Fig 3.12 Activity diagram for Registration..............................................................................................
Fig 3.13 Activity diagram for Create Account........................................................................................
Fig 3.14 Activity diagram for Login........................................................................................................
Fig 3.15 Activity diagram for Delete.......................................................................................................
Fig 3.17 Activity diagram for View........................................................................................................
Fig 3.19 Activity diagram for Approve...................................................................................................
Fig 3.20 Activity diagram for Generate Report.......................................................................................
Fig 3.21 Activity diagram for Request....................................................................................................
Fig 3.22 State chart Diagram of Actors login..........................................................................................
8|Page
LIST OF ACRONYMS AND ABBREVIATION
UC: Use case
UCID: Use case ID
DB: Data Base
CD-ROM: Compact Disk Read only Memory
PHP: Pre-processor Hypertext Protocol
MYSQL: My Structured Query Language
CSS: Cascading Style Sheet
HTML: Hypertext Mark-up Language
UI: User Interface
UML: Unified Modelling Language
OOD: Object Oriented Design
OOA: Object Object-Oriented Analysis
OOSAD: Object Object-Oriented System Analysis and Design
E.C: Ethiopian Calendar
SRS: System Requirement Specifications
AU Haramaya University
UAT user acceptance testing
9|Page
Chapter One
INTRODUCTION
1.1 Introduction clearance
Clearance is a status granted to individuals typically students allowing them access to

information (SOURCE ??). The term clearance is also sometimes used in private
organizations that have a formal process to check the employee’s information. A clearance by
itself is normally not sufficient to gain access the organization must determine the cleared
individual has needs to know the information.
Clearance is the process of determining and negotiating any permission that are is needed
to use of someone else’s intellectual property creative project. Part of that process includes: -
 Determining the owner(s) of the intellectual property.
 Contacting the owners and negotiating on an agreement.
 Administering written contracts.
 Handling other issues related to the use and licensing of intellectual property.
No one is supposed to be granted access to classified information solely because of rank

or position, but once a clearance is obtained access to certain information or gain of freedom
will be granted.
The proposed system over comes one problem done by manual system. To reduce
misuse of manpower, avoiding errors, to save time, to provide comfort a comfortable
clearance process for the students, and to provide insurance for the organization, especially
for workers who play roles in the clearance processing system.
This system works for students of Haramaya University. The online clearance
processing system allows the students to register for the membership to access the service of
the system.
10 | P a g e
1.2 Background of the project
Haramaya University student’s clearance processing system is one of the processes that will
be done to be clearedclear the students from the campus.
The system gives its function to many users of the University. The numbers of students grow
from year to year in many numbers. Now a dayadays, there are many users of the clearance
processing system. But the project gives a service only to the students. The students get one
copies copy of the clearance sheet from the department and get signatures and stamps from
around eight offices.
These are Advisor, Bookstore, Library, Health and physical Physical Education, Student’s
Proctor, Student Service, and College/Institute Registrar. After they finished all necessary
requirements, finally the students take copies of the sheet that has all signatures and stamps
from all offices. This processing makes the students bulky because they go to about eight
offices.
1.3 Background of the organization
Haramaya University (HU) is one of the oldest higher learning institutions in Ethiopia which
has its establishment established as an Imperial Ethiopian College of Agricultural and
Mechanical of Arts (IECAMA) in the early 1950s. the governments of Ethiopia and the
United States of America signed an Agreement under the Point Four Program on May 15,
1952. Subsequently, with the recommendation of His Imperial Majesty, Emperor Haile
Sellasie I, the envisioned IECAMA was established at its present location, Haramaya, near
the historic Lake Haramaya. The area covers a total of 440 hectares of land. The
establishment involved the construction of a physical plant and enormous facilities in the
1950s.
Haramaya which is situated in East Hararghe Zone, close to Haramaya town, at about
510km East of Addis Ababa between Dire Dawa and Harar cities. HU offers a total of 211
Regular academic programs, of which 74 are undergraduate programs, 132 postgraduate
programs (104 second degree and 28 third third-degree program) and 4 are specialty
certificates in Medicine and 6 are special certificates of Postgraduate Diploma. In these
academic units, the University has now a total of 30,462 enrolled students; including 24,157
are undergraduate students, 4,686 are postgraduate students, and 1,619 postgraduate diploma
students. Besides, the University has 2,115 academic and 5,739 administrative staff members.
11 | P a g e
were opened which include Faculty of Law, Faculty of Business and Economics (September,
2002) Faculty of Veterinary Medicine (2003), Faculty of Technology (2004). In February
2006, Alemaya University was named as Haramaya University (HU). In 2008/09 academic
years, Faculty of Applied Sciences and Faculty of Computing and Informatics were further
added. the University then started to function in three campus premises (main campus, Harar
and Chiro). Subsequently HU reorganized the previous faculties in to 10 Colleges, one
Institute, and one Academy, namely: College of Agriculture and Environmental Science
(CAES),College of Business and Economics(CBE) , College of Computing and Informatics
(CCI), College of Medical and Health Sciences(CMHS), College of Social Sciences and
Humanities(CSSH), College of Law (COL), College of Veterinary Medicine(CVM), College
of Natural and Computational Sciences (CNCS), College of Education and Behavioral
Sciences(CEBS) , Directorate of Continuing and Distance Education (CCDE) and Haramaya
Institute of Technology (HIT) and Academy of Sport Sciences. Currently, HU functions in
four campus premises: main campus, veterinary campus, health campus and technology
campus.
1.3.1 Vision
Haramaya University strives to be one of the leading African Universities with international
reputation by 2025.
1.3.2 Mission
The Mission of Haramaya University is to produce competent graduates in diverse fields of

study, undertake rigorous, problem solving and cutting edge researches,disseminate
knowledge and technologies, and provide demand-driven and transformative community
services.
1.3.3 Goal
HU's goal is to evolve as an autonomous and independent (academic and research institute)
graduate and research university with competitive national and international quality and
relevance standards in its academic, research, and community engagement endeavors.
1.4 Statement of the problem
The process of clearing students of a named institution Haramaya University after the
end of the academic year requires that the students must be cleared in their various
12 | P a g e
departments. This clearance processing system service currently uses a manual system which
creates the following major problems.
 Data The data recording system is not centralized or not in the modern system which
is difficult to search.
 It creates wastages of material & time.
 Data redundancy & loss of data.
 Consumes more resources to complete the process which is of high cost such as:- 
Stationary material.
 Printers and computers etc.
 Need more manpower to process the clearance in the respective offices.
 Error is happened happens during process of the clearance System.
 The process is very offensive for students when there is a harsh atmosphere like rain.
 To process the clearance is a lot of queue because of the number of users.
 Employees involved in the clearance process are not available 24 hours of the a day.
Hence, it became imperative for computer software software-based online clearance

systems to eliminate the shortcomings of the manual system in place as above above-listed
problem.
1.5 Objective of the project
1.5.1 General Objective
The main objective of this project is to change the manual clearance processing system
to web web-based system and solve the above above-stated problems.
1.5.2 Specific Object
The specific objectives of this project includes: -
 Able to register students.
 Check students from the data base.
 Fast data processing.
13 | P a g e
 To avoid the problems and stress of travelling and queuing up of students during
clearance
 Efficient use of time.
 Designing a friendly user interface.
 To develop a reliable clearance system.
 To provide borderless access.
 To ensure prompt clearance.
 To develop a transparent clearance system.
 To develop an effective and efficient clearance system.
 To avoid redundancy, and inconsistency.
 To overcome the problem of wastage of resources like pen, paper, and human power.
1.6 Methodology for the project
1.6.1 Data source
Is the way or mechanism in which we gather information to develop the system. We

have used the following methods: -
 By seeing the forms that the existing system uses how students clear and take out
their property from the campus.
 Interviewing the heads of the office and the clerk (asking open and closed questions)
  Observing different files and reporting documents.
 Collecting information from different references, projects, and web sites
  By discussing and analysing analyzing the problems with the project team.
SW development methodology should be written here …
14 | P a g e
1.6.2 Fact Fact-Finding Techniques
Practical Observation: - we observed physically the currently existing system which is done
by manually. We referred different forms and documents in to the department, registrar, and
some other offices.
Document Analysis: - For more information about the existing system we refer to relevant
documents, others reading materials, and some forms in different offices.
Interview: - To get the basic information and background information about the existing
system structure, we ask different questions from different persons who provide clearance
systems.
1.7 Scope of the project
This project is limited only for to Haramaya University students. Currently, the
university performs a clearance system manually or a paper-based processing system.
Generally, the scope of this project includes: -
 Our The system is used for HU students only.
 The System contains all the recorded information that can be handled by
the registrar and other offices.
 Registration for a membership.
 Administrators control the system.
 Users can view their profiles.
 The proposed system is accessed by the English language.
1.8 Significance of the project
The project work will help in a good way to ease the queuing system in the university as
the online clearance system will help students to achieve whatever they want without coming
to the various offices for clearance personally such as dormitory, bookstore, registrar, sport,
library, and student service.
Online The online student clearance system allows the users to check their clearance
status as to whether they are in any way obligated to the university, fill and submit their
15 | P a g e
clearance form, and obtain their clearance letter. There are many other advantages of student’s
online clearance system. Some of them are listed below:-
 It saves a time.
 It is very convenient to use it right from the dormitories, office, or anywhere in the
campus or in the world.
 Information processing is very fast and delays can be minimized.
 Help the University in reducing costs such as labour and stationary stationery.
 Process clearance effectively and efficiently.
 Provides a reliable and transparent clearance processing system.
 It provides borderless access.
 It provides a reliable and transparent system devoid of personal interest and

inclination.
 The system removes the problems of stress, travelling to different offices, and queuing
up of students during processing of the clearance.
1.9 Feasibility Analysis
Feasibility analysis enables the system to determine whether or not the project can be
developed, and evaluates and identifies the newly developed system. Therefore, the feasibility
analysis of the proposed system involves the following feasibility:
1.9.1 Operational Feasibility
The proposed system will solve the business and time problems for the organization.
Therefore, the campus administration and other users providing provide an effective
processing system, which satisfies their needs.
 The proposed system offers a greater level of user-friendliness.
 The proposed system produces the best results and gives high performance.
 The proposed system can be implemented easily.
 The proposed system can be solved solve the existing system problem and challenge.
16 | P a g e
1.9.2 Technical Feasibility
The system developers understand the scope, and objectives including specific
objectives and limitations of the proposed system well and the users have the technical
capability to use this system. As a result, they develop the system for Haramaya University
successfully within the proposed resources (budget, time, etc.). This also deals with the
hardware as well as software requirements. We have to find out whether the necessary
technology and the proposed equipment have the capacity to hold the data used in the project.
The technical feasibility issues usually raised during the stage of fact fact-finding includes the
following: -
 This software is running in windows Windows and Linux operating systems.
 The system can be expanded in on any system platforms.
1.9.3 Economic Feasibility
When the team can be analyses analyze the system by comparing the cost with the
benefits (the enterprise can get by using the proposed system), surely the benefits out
weightweigh the cost. The cost of developing a full system, including software and hardware
costs for the class of application being considered should be evaluated. So, the benefits that
obtained by using the proposed system can be categorized as tangible and in tangible.
Tangible benefits are:
 Using less man power than the existing system.
 Increase the speed of activities and competence.
 Reduce cost.
Intangible benefits are:
 Knowledge required by the project developer.
 Facilitating information processing.
 Updating information.
 Increasing the competitiveness of the individual.
 Improved productivity.
17 | P a g e
 Improving the morale of our team.
 Facilitating information processing of our team
Therefore, the team decided the proposed project is was economically feasible.
1.9.4 Behavioural/Political Feasibility
Behavioural feasibility is the measure that how users use the system effectively. The
proposed system should be easy to operate, convenient in to maintenance, and effective in its
working. Thus behavioural feasibility is a very important factor to be considered for effective
working of the system. Behavioural feasibility is dependent on human resources available for
the project and involves projecting whether the system will operate and be used when it is
functionally operateoperating. The system is behaviourally feasible because of the following:-
 The proposed system is easy to operate.
 Retrieval of information is easy, accurate, and fast.
Since developing this new system will be solve the clearance system problems, the users
will undoubtedly have a positive attitude towards the system and the system is politically
feasible and free from any legal claims.
1.9.5 Schedule Feasibility
Schedule feasibility is concerned with analyszing and analyzing the expected

completion date of the project and the constraints that may bring change to this date. We have
so many fixed schedules to work together on the project with all groups within each day and
for the simplicity and fast developing purpose.
18 | P a g e
Fig 1.1 Gantt chart.
1) Cost of the project
A. Hardware Requirements cost

No Materials Required Amount Price Per Unit Total Cost
1 HP Computer 2 24000 48000
2 Pen 25 4 100
3 A4 Size Paper 1 Destin 110 110
4 Print 100 3 300
5 Flash Disk 1(16G) 500 500
Total 24384
Table 1.1 Hardware Requirement Cost
B. Software Requirements Cost

No Materials Required Price Per Unit
1 Microsoft Word 2013 Free
2 Visual cod Free
3 Microsoft Office Visio 2007 Free
4 MYSQL Server free
19 | P a g e
5 Mozilla Firefox Free

Total empety
Table 1.3 Software Requirement Cost
2) Cost break down
A. One-time costs: - these are costs incurred at the time of developing our project.
[B.] Recurring costs: -these are costs those incurred to maintain our project once developed.
1.10 System Analysis and Design
In this project, the team used Object Oriented System Analysis and Development
methodology (OOSAD). This has two phases.
Object Oriented Analysis (OOA):- During this phase, the team used to model the functions
of the system (use case modelling), find and identify the business objects, organize the objects
and identify the relationship between them and finally model the behaviour of the object.
Object Oriented Design (OOD):- During this phase, the team used to refine the use case
model to reflect the implementation environment, modeled object interactions and behaviours
that support the use case scenario, and finally updated the object model.
1.11 Development Tools
Software: - This project uses the following system development tools for different activities.
Tools Activities
Java script For editing code
CSS For attractive layout
PHP Back end (Server side coding)
HTML Client Client-side coding
MYSQL Back end(data base)
Apache Server As server
Mozilla Firefox, IE, Google Chrome, Opera Browsers
Ms office word Word 2013 For Documentation
Ms office PowerPoint 2013 For Presentation
20 | P a g e
Ms office Visio 2007 To draw UML Diagram and for designs

Figma To design back ground images
Table 1.2 Development Tools
Hardware
 Hard Disk
 Flash Disk 16GB
 Printer
1.12 Implementation
The current student clearance processing system is still worksworking. Since we cannot
change it directly or partially we choose to develop the proposed system parallel to the
existing system. We are going to change the manual clearance Processing system after the
user is familiar with the proposed system, until that the users and the university uses parallel
with the manual clearance processing system.
1.13 Testing Procedures
We use the above above-listed software development tools to design or implement the
proposed system, because the tools are compatible to develop the proposed system. We will
also perform different testing for checkingto check functionality of our proposed system.
1. Unit testing: - First we will test each unit at each system. So, if a problem is
encountered it will immediately maintain at which the problem is occurred.
[2.] Integration Testing: - After we test each unit of the proposed system we will
perform an integration test to check whether the system meets all the functional
requirements. When a number ofsome components are complete, it will test be tested
to ensure that they integrate well with each other like the operating system, and other
components.
[3.] System Testing: - After all of the above testing are is checked we will test our
system by with other peoples and we will conduct some comments how they get our
system.
21 | P a g e
1.14 Target beneficiaries of the system
This project provides many benefits for: -
[1.] Students: - by providing fast access to the clearance system by reducing time like
waiting in the queue and going to different offices. The students access the system
anywhere and anytime when they need the clearance. It improves the tiredness of
students by avoiding to going to different offices to get the clearance system.
1.[2.] University: - in the manual system there is a loss of materials like time, paper, pen
which is cost and more manpower, the system reduces the loss of costly materials and
manpower.
2.[3.] Developers of the project: - it increases our knowledge and we get moral
satisfaction and additional skills from the project we will develop.
1.15 Team compositions
We have organized our selfselves (team members) in a decentralized way that every team
member communicates to each other and diagrammatically.
22 | P a g e
Fig 1.2 Team composition
Work breakdown structure for the project
Haramaya University Student’s Online Clearance System

W S Tasks Duration Predecessor Respo sible
O N n
R 1 Project initiation Initiation and 1 weak All
K Planning  Gathering
B information
R 2 Description of the project 2 weak 1 All
E Introduction:
A  Back ground information 
K Statement of the problem
 Objective The objective of the
D problem
O  Scope and limitation of the project
W  Methodology
N  Feasibility study
3 Current system 1 weak 1,2 All
S  Description of the current system
T  Players in the existing system
R  Business Rules
U  Bottlenecks of the existing system
C 4 Proposed System 3 weak 1,2,3 All
T  Functional Requirement
U  Non-Functional Requirements
R  User interface
E  Hardware or software requirements
S  Security and safety procedure
5 System Modelling 1 weak 4 A
 Use case diagram and their ll
description
23 | P a g e
 Object Model
 Dynamic Model
6 Implementation 12 weak 3,4 All
 Design
 Coding
 Testing
 Documentation
Advisor MR. irandufa indebu
Submission Date Jan 10/2024
Table 1.3 Work break down structure
Chapter Two
Description of the Existing System
2.1 Introduction
This chapter deals with analyszing analyzing the proposed system by using different
UML analysis modelling techniques such as use case diagrams, the use case descriptions
(scenarios), sequence diagrams, activity diagrams, analysis class diagrams, and user interface
prototype
After identifying the actors and use cases, the use cases are developed and textual
descriptions (scenarios) are stated. The Sequence diagram id is depicted based on the use
cases which that are developed for the proposed system. Activities will be represented by the
activity diagrams
24 | P a g e
2.2 System Haramaya University

Requirement Specification Student’s
(SRS) Online
Registrar Admin
-Library -dep.t head Delet

Regis
-Bookstore -collage dean
< inclu>
Update
-Cafeteria -sport
< inclu>
-Dormitory -college
< inclu>> Log
register office CreateAcc < inclu>
< inclu>
-Women & child < inclu> Requ Stud
Appro < inclu>
< inclu>
Sear
Offices View
ReporteGen
2.2.1 use case diagram
Registrar Admin Haramaya University Student’s Online

-Library -dep.t head Delet
Regist
-Bookstore -collage dean
< includ
>
-Cafeteria -sport Update
< includ
>
-Dormitory -college
register office < includ
>> Logi
CreateAcco < includ
>
-Women & child < includ
>
< includ
> Reque Stude
Appro < includ
>
< includ
>
Searc
Offices View
ReporteGener
25 | P a g e
Figure 2.1 Use case diagram
Actors Description
The actors that interact with the system are the Proctors; Registrar, student service, sports
science, bookstore, library, and students who are users of the system. They are described here
in brief: -
Name: Proctor
Description: A Proctor is a person who is responsible for Approveapproving, Updateupdating,

deletedeleting, and searching the student’s information.
Name: Bookstore
Description: A Bookstore is a person who is responsible for Approveapproving,

UpdateUpdating, deletedeleting, and searching the student’s information.
Name: Sport science
Description: A Sports science scientist is a person who is responsible for Approveapproving,

Updateupdating, deletedeleting, and searching the student’s information.
Name: Library
Description: A Library is a person who is responsible for Approveapproving, Updateupdating,

delete, and searching the student’s information.
Name: Student service
Description: A Student service is a person who is responsible for Approveapproving, Update,

deletedeleting, and search the student’s information.
Name: Registrar Admin
Description: Registrar Admin is a person who is responsible for Approve approving and
Generate Report.
Name: Student
26 | P a g e
Description: Student A student is a person who is responsible for Update profile, Request, and
view their own information.
Key terms of Offices refer to
Proctor
Student service
Bookstore
Library
Sport science
Student loan
Women, children & youth Affairs
College/academy/HIT
Cafeteria
From the above use case diagram.
2.2.2 Use case descriptions
1. Use case description for Create Account.
UCID Use case name Create Account

-01 Actor(s) Admin, Offices
Pre-condition The Actors is not create account.
Post-condition The Actors should be create account.
Description When the Actors enter user name and password, it
stores the input information in to the database.
Typical course Actor Action System Response
of action:
Step1: This use case is Step2: The
initiated when the system displays
actors clicks on the the create
create account option account page.
Step3: The actor enter Step4: The
the required systems checks
27 | P a g e
information. the information is

correct or not.
Alternative Step5: If the actor does not fill the required
course of information then the system display error message
action: and return to step 2.
Table 2.1 Use case description for Create Account.
2. Use case description for login.
UCID Use case name Login

-02 Actor Student
Pre-condition The Actor is not login the system
Post-condition The Actor should be login in to the system
Description When the students enter id and password, it checks
the inputs from the database. If it is valid, it allows
the user to access and if not it display authorization
message.
of action:
Step1: This use case is Step2: The system
initiated when the displays log in
actors clicks on the form
login option Step4: The
Step3: The actor enter systems checks
the id and password authorization. If
she/he is
authorized system
displays the main
page if not
display
unauthorized
message.
Alternative Step5: If the actor does not fill the id and password
28 | P a g e
course of then the system display error message and return to

action: step 2.
Table 2.2 Use case description for Login.
3. Use case description for Registration.
UCID Use case name Registration

-03 Actors Students
Pre-condition The Actors are not to register
Post-condition The users registers to the system
Description This use case allows users to register in to the system
of action:
Step 1: The user Step2: The system
wants to register in displays the
to the system. registration page
Step 3: The user Step4: The system
enters the necessary validates whether
information in to the the information
form in the submitted is correct
registration page. or not. Step5:
The system register
and displays
registration
confirmation page
and leads to home
page.
Step6: The use case
ends
Alternative Step5: If the actor does not fill the id and password
course of then the system display error message and return to
action: step 2.
Alternative If the input information invalid or empty
29 | P a g e
course of Step4.1: The system indicates the user information

action invalid.
Step4.2: The use case continues Step2 of the basic
course of action.
Table 2.3 Use case description for Registration.
4. Use case description for Delete.
UCID Use case name Delete

-04 Actor(s) Administrator, Offices
Pre-condition The Actors are not authorized and login in to the
system
Post-condition The administrator delete the record from the
database.
Description The use case allows the administrator to delete
record of students from database.
of action:
Step1: This use case Step2: The system
is initiated when the displays the delete
actor on delete option form page.
Step3: The actors Step4: The system
enter the id for delete verifies whether
data from the data the existence of the
base. data base.
Step5: The system
displays
confirmation
message.

action invalid.
30 | P a g e

course of action.
Table 2.4 Use case description for Delete.
5. Use case description for Update.
UCID Use case name Update profile

-05 Actor(s) Students Admin, and Offices
Pre-condition The Actors cannot be Update profile
Post-condition The Actors will have update their account
information
Description This use case allows users to update the user account.
Typical course Actor Action System
of action: Response
Step1: The actors can Step2: The

request to update his/her system displays
information. The system user account
will display the current update page.
customer information to Step4: The
the users. system
Step3: The user enters the validates
necessary information to information is
update. correct or not.
Step5: The
system displays
confirmation
page and save
the update
information of
user.
31 | P a g e
course of Step4.1: The system indicates the Actors information

action invalid.
course of action.
Table 2.5 Use case description for Update.
6. Use case description for View Profile
UCID Use case name View Profile

-06 Actor(s) Students
Pre-condition The Actors not seen profile.
Post-condition The Actors has been viewed his/her profile.
Description This use case allows users request to view his/her
profile.
of action:
Step2: The system
Step1: The actors
displays view option
wants to View
page.
his/her profile.
Step4: The system
Step3: The actor
process selection.
selects the view
Step5: The system
profile option.
displays the actor
profile.
Step6: The use case
ends.

course of action Step4.1: The system indicates the user information
invalid.
Step4.2: The use case continues Step2.
32 | P a g e
Table 2.6 Use case description for view profile
7. Use case description for Search.
UCID Use case name Search

-07 Actor(s) Administrator, and Offices
Pre-condition The actors cannot search.
Post-condition The Actors has been searched the selected record.
Description This actors requests to search someone’s
information.
of action:
Step2: The system
Step1: The
displays user view option.
actors wants
Step4: The system
to search
process the selection.
some record.
Step5: The system
Step3: The
displays the selected
user enters the
record.
information to
Step6: The use case ends.
search from
database
option.

course of action Step4.1: The system indicates the user information
invalid.
course of action.
Table 2.7 Use case description for Search
8. Use case description for Approve.
UCID- Use case Approve
33 | P a g e
08 name
Actor(s) Offices and Admin
Pre- The actors cannot Approve.
condition
Post- The actors should be approved the information.
condition
Description The actor to be approve if they get request some
information from different corners.
Typical Actor Action System Response
course of
action: Step2: The system
Step1: The actor
displays the approve
wants to submit.
option.
Step3: The user
Step4: The system
selects the approve
process the selections.
option.
Step5: The system
displays confirmation
message to the user.
Step6: The use case
ends.

action invalid.
course of action.
Table 2.8 Use case description for Approve
9. Use case description for Generate Report.
UCID Use case Generate Report

-09 name
Actor(s) Admin
Pre- The actor cannot be Generate Report.
34 | P a g e
condition
Post- The Actors should be generate the report.
condition
Description The actor wants to report how many students are
clear from the university.
course of
action: Step1: The actor Step2: The system
wants to generate displays the generate
report. report option.
Step3: The user Step4: The system
selects the generate process the selections.
report option. Step5: The system
display the all
information’s of the
students.
Step6: The use case
ends.

action invalid.
course of action.
Table 2.9 Use case description for Generate Report.
10. Use case description for Request.
UCID Use case Request

-10 name
Actor(s) Student
35 | P a g e
Pre- The actor cannot Request the information.

condition
Post- The Actors will be Request.
condition
Description The actor wants to request what they want.
course of
action: Step1: The actor Step2: The system
wants to request. displays the request
Step3: The user option.
selects the request Step4: The system
option. process the selections
action.
Step5: The system
send information’s to
the other page.
Step6: The use case
ends.

action invalid.
Step4.2 The use case continues Step2 of the basic
course of action.
Table 2.10 Use case description for Request.
2.2.3 Analysis Level Class Diagram
 It represents the properties of entities, their operations and relationships. Also it drives use case
diagrams from use case.
 The class diagram is the main building block in our project modelling.
 It is used both for general conceptual modelling of the systematic of the application and for
detailed modelling translating the models into programming code.
36 | P a g e
 The classes in a class diagram represent both the main objects and or interactions in the
application and the objects to be programmed.
 Generally the project is including the following class in the class diagram the over view of the
class diagram is:-
Fig 2.2 Analysis Level Class Diagram
CRC (Class-Responsibility-Collaboration) is a technique used in object-oriented analysis and

design to identify and define the classes in a system, their responsibilities, and how they
collaborate with each other. This technique helps in understanding the interactions and
relationships between different components of a system. Let's apply CRC to an online
clearance system:
2.3 Supplementary specification
Business rules for an online clearance system can vary depending on the specific requirements
and context of the system. However, here are some general business rules that could apply:
37 | P a g e
1. Eligibility Verification:
The system should verify the eligibility of individuals requesting clearance based on
predefined criteria.
The system should validate the information provided by the individual against relevant
databases or records.
2. Application Submission:
The system should allow users to submit clearance applications online.
The system should validate the completeness and accuracy of the application before
processing.
3. Document Submission:
The system should provide a mechanism for users to upload supporting documents required
for clearance.
The system should validate the format, size, and authenticity of the submitted documents.
4. Workflow Management:
The system should support the defined workflow for clearance processing, including approval
stages and decision-making.
The system should route clearance applications to the appropriate individuals or departments
for review and decision.
5. Timelines and Deadlines:
The system should enforce predefined timelines for various stages of the clearance process.
The system should send reminders and notifications to users and approvers regarding pending
tasks and upcoming deadlines.
6. Data Privacy and Security:
The system should ensure the confidentiality and security of user data and documents.
The system should comply with relevant data protection regulations and guidelines.
7. Audit Trail and Reporting:
The system should maintain an audit trail of all activities and actions performed within the
clearance system.
38 | P a g e
The system should provide reporting capabilities to generate relevant metrics and statistics
related to clearance processing.
8. User Roles and Permissions:
The system should enforce appropriate user roles and permissions to control access and
actions within the system.
The system should differentiate between applicants, approvers, administrators, and other
relevant roles.
9. Communication and Notifications:
The system should facilitate communication between users, approvers, and administrators
within the clearance process.
The system should send notifications regarding the status of clearance applications and any
additional requirements.
10. System Performance and Reliability:
The system should be designed to handle the expected user load and provide a reliable
service.
The system should have appropriate backup and disaster recovery mechanisms in place.
2.4 Introduction of the Existing System
The current clearance processing system is the a manual system that needs intensive human
labour, and resources, consumes time, and less security. Here, the student to visit all the
clearance offices with a form for them to fill out and get signed by the respected respective
offices. Once these forms are signed, it proves that the users have been cleared. This process
takes some days to be completedcomplete and possess poses a lot of stress to all the users and
workers who provide the clearance system.
In the manual system, the clearance forms are documented in a file cabinet. Each time the
clearance form is needed, a search operation is conducted on the file cabinets to locate a
particular user’s clearance form.
2.4 Players in the Existing System
The main players in the existing system includes the following: -
39 | P a g e
 Students: - Students will go to department to get the clearance form and fill the form then go to
different offices to get a sign.
 Registrar: - They sign in the form and give the form to the students.
 Proctors: - They check the dorm materials like bed, window, door, and the door key if all are
not the damage they sign in the student's clearance form.
 Library: - They check either the borrowed books were returned or not.
 Sport Science: - This office check sport materials whether the student take from the office or
not.
 Student Service: - Any student debit are defined in this office.
 Book Store: - They check if the students have borrowed a book and return the book or not, if
they have not borrowed the students are cleared and they put sign in to the clearance form.
 Departments: - Distribute clearance paper form for the students in respected department.
 Security Guard: - They check the student properties are matched with their clearance paper.
2.5 Major functions/activities in the existing system
2.5.1 Input Analysis
Input to the system is the form which is fulfilled by the proper users. These forms are filled
by student and submitted to the various offices for issuing of receipts.
2.5.2 Process Analysis
The form is filling by the students then collected and signed by the respected offices to certify
that the student has completed all the necessary things. Hence a certificate issued to show that
the student have completed all the clearance processing.
2.5.3 Output Analysis
The output from the system is the certificate or one form of clearance issued to the student
stating that the student fulfilled all university obligation and is now free to pass out from the
university.
2.6 Business Rules
 Can only access authorized user.

 Unauthorized user cannot access the system for the reason of system security.
40 | P a g e
 Users must be registered to access the system to be authorized user by filling the necessary
information in the registration form.
 Users must have username and password to login to the system.
2.7 Report generated in the existing system
The forms generated in the existing system are in the forms of form and files.
Forms: - Forms are the reports generated in the existing system that contains all information
filled by the university student.
Files: -Files are the collection of information about the students who involve in the clearance
processing system. These all reports kept in the offices of the university to store information
about the university student.
41 | P a g e
2.8 Forms and Other Documents of the Existing System
42 | P a g e
Fig 2.3 Students Clearance form
2.9 Bottlenecks of the Existing System
Due to the manual means being used by the university, in keeping information about
student’s clearance, a lot of problems are encountered which includes: -
2.9.1 Performance (Response time)
 Wait in the queue while processing the clearance form.

 Unavailability of some key staff while processing the clearance form.
 Takes a lot of time to get back a particular clearance from the respected offices.
2.9.2 Input (Inaccurate/redundant/flexible) and Output
During filling of the form the user may fill inaccurate or incorrect information and may
miss necessary information, this show the system is inaccurate and the system is not flexible
because if user wants to erase the form he/she must only change another form.
2.9.3 Security and Controls
 Loose of vital documents as the filing system is manual.

 Damage of document due to fire or rain incident.
 Take a lot of time to retrieve a particular clearance form.
 Delay in processing clearance form.
 Illegal removal of forms by falsified staff leading leads to insecurity.
2.9.4 Efficiency
Due to the manual operation most of the activities are easy to wastage of resources like
stationary materials, manpower, time etc. to produce the corresponding outputs. This makes
the current system inefficient while utilizing resources.
2.10 Practices to the Preserved
Even if the existing system has a lot of problems, there are a number of activities that need to
be preserved. The system uses files and forms to define operations and to perform business
rules in the clearance system. Our team members preserve the following practices form the
existing system.
43 | P a g e
 System procedures.
 The rule and regulation of the university.
 Formalities of the users of the system, offices concerned staffs and students.
2.11 Proposed Solution for the new System that address problems of the Existing
System
The new system is designed to solve problems affecting the manual system in use. It is design
to be used online thereby relieving both the students and the offices workers from much stress
as experienced in the manual system.
This system will do the analysing and storing of information either automatically or
interactively. It will make use of online access to Internet. The proposed system will also have
some other features like:-
 Login system must be present and secured by password and logout after cover.
 Accuracy in the handling of data.
 Fast rate of operation and excellent response time.
 The system is flexible i.e. it can be accessed at any time.
 Easy way of back up or duplicating data in diskettes in case of data loss.
 Better storage and faster retrieval system.
 Accessibility from anywhere.
2.12 Requirements of the Proposed System
2.12.1 Functional requirements
Functional requirement defines a function of a system and its components. A function is

described as a set of inputs, behaviour, outputs, data manipulation and processing and other
specific functionality that define what the system is supposed to accomplish.
Performance requirements: - The system performance is one of the functional requirement

in which they regularly and producing quality output. It is all time ready to perform all the
functions, faster response time and uses minimal space usage.
Process requirements: - The system performs the services for all inputs by functional
components of the system based on the given inputs.
44 | P a g e
Input Input-related requirements: - After the system is implemented, to perform a process

it needs inputs like student username, student ID No, and other information which are is
necessary to in processing clearance are entered in the clearing process.
Output Output-related requirements: - The system takes in an input to perform or to

process some function in order to produce an output based on the given input.
Storage Storage-related requirements: - The system was developed by using MySQL

database server which is used to store all the student's information like cleared students and
the current available student's information to be cleared.
2.12.2 Non-functional requirements
Performance: -
 The system is very fast since it is automated.

 The software shall support the use of multiple users at a time.
 It works very well with short response time, high throughput, and high availability.
 Reduce costs and time waste by providing access to a system in an available place and time
where an Internet connection is available
User Interface: - The developed system provides web application user interfaces that are
compatible with browsers like Internet Explorer, Mozilla Firefox, Google chromeChrome,
etc.
Security and Access Permissions: - The system provides or contains the user name and
password for each users based on their privilege. This performs the following activity: -
 Authenticated users with predefined access rights will only enter to the information related to
the database.
 Every users should use strong passwords, especially admin.
 User The user must enter a valid user name and password to login into the system. Without this,
access to the system is denied.
 Data is encrypted for security.
 System The system allows only registered users to access the clearance system and also allows
the users’ to view their own profile, not the other users’ profile.
45 | P a g e
Backup and Recovery: - When team members standard to develop a system they must have
to put use a backup mechanism by using removable flash disks, or CDs.
Usability: - The system shall be very easy to learn, needs a basic computer knowledge to
use, and have has a help menu to guide the user.
Availability: - There is no delay in the availability of any information, whatever is needed,

can be captured very quickly and easily. The server should be always on to be available.
2.13 Limitation of the project
Defines what the proposed system is not going to perform or what is not including included
in the proposed system. This project covers some of the aspects of computer software
software-based online clearance processing systems using Haramaya University as a case
study. However the following are the constraints: -
Time constraints: - Due to time constrain the web page covers only clearance for various
departments by the students.
Financial constraints: - Due to financial constraints people cannot afford this kind of process
online, especially towards the cost of accessing the internet. Therefore, it would cost a lot to
develop a full web web-based clearance processing system. Generally, the limitations of this
project includes: -
 This project was done only for Haramaya University students.

 The system couldn’t give service to academic staff and administrative staff i.e. limited only for
to students.
 If the students lost/damaged the university property, he/she couldn’t gain clearance, until the
students pay paid the cash personally to finance.
 The proposed system cannot accessed with their local language.
1.14 Risks and Contingencies
Some risks and contingencies that may happen during the development of the system are
includesinclude the absence of electrical power, and the absence of team members during
working because of different problems are happenedhappening.
46 | P a g e
1.15 Assumptions and Constraints
Assumptions: - The group members assume to finish the system according to the given
time.
Constraint: - The major constraints of the system are the internet and electric power.
Chapter Three
System Analysis
3.1 Introduction
This chapter deals with analyszing analyzing the proposed system by using different UML
analysis modelling techniques such as use case diagrams, the use case descriptions
(scenarios), sequence diagrams, activity diagrams, analysis class diagrams, and user interface
prototype
After identifying the actors and use cases, the use cases are developed and textual
descriptions (scenarios) are stated. The Sequence diagram idID is depicted based on the use
cases which that are developed for the proposed system (SOURCE). Activities will be
represented by the activity diagrams.
3.2 Sequence Diagram
Sequence diagrams show the interaction between participating objects in a given use case.
They are helpful to identify identifying the missing objects that are not identified in the
analysis object model (SOURCE).
1) Sequence Diagram for Create Account by Admin and Offices
47 | P a g e
Fig 3.1 Sequence diagram for Create Account by Admin and Offices
2) Sequence diagram for Registration.
48 | P a g e
Fig 3.2 Sequence diagram for registration
49 | P a g e
3) S
e
q
u
e
n
c
e
diagram for Login.
Fig 3.3 Sequence diagram for login.
4) Sequence diagram for Update.
50 | P a g e
Fig 3.4 Sequence diagram for Update
5) Sequence diagram for View.
51 | P a g e
Fig 3.5 Sequence diagram for View
52 | P a g e
6) S
e
q
u
e
n
c
e
diagram for Search.
Fig 3.6 Sequence diagram for Search
7) Sequence diagram for Delete.
53 | P a g e
Fig 3.7 Sequence diagram for Delete
8) Sequence diagram for Approve.
54 | P a g e
Fig 3.8 Sequence diagram for Approve
9) Sequence diagram for Generate Report.
55 | P a g e
Fig 3.9 Sequence diagram for Generate Report
56 | P a g e
10) Sequence diagram for Request.
Fig 3.10 Sequence diagram for Request.
3.3 Collaboration Modelling
A collaboration diagram describes interactions among objects of our system in terms of

sequenced messages. Collaboration diagrams represent a combination of information
57 | P a g e
taken from class, sequence, and use case diagrams describing both the static structure and
dynamic behaviour of a system.
3.1 Component Modelling
In this modelling, the diagram describes the organization of the physical components in a
system.
Figure 3.11 Component modelling diagram
3.2 Activity Diagram
An activity diagram is used to emphasize the flow of control from activity to activity or
to model the flow of an object as it moves from state at different points in the flow of control.
58 | P a g e
1. Activity Diagram for Registration
Fig 3.12 Activity diagram for Registration
59 | P a g e
2 Activity Diagram for Create Account
Fig 3.13 Activity diagram for Create Account.
3 Activity Diagram for Login.
60 | P a g e
Fig 3.14 Activity diagram for Login
4 Activity Diagram for Delete
61 | P a g e
Fig 3.15 Activity diagram for Delete
2 Activity Diagram for Update Profile
62 | P a g e
Fig 3.16 Activity diagram for Update profile.
5 Activity Diagram for View Profile
63 | P a g e
Fig 3.17 Activity diagram for View
6 Activity Diagram for Search
64 | P a g e
Fi
g 3.18 Activity diagram for Search
7 Activity Diagram for Approve
65 | P a g e
Fig 3.19 Activity diagram for Approve
8 Activity Diagram for generate report
66 | P a g e
Fig 3.20 Activity diagram for Generate Report
9 Activity Diagram for Request.
67 | P a g e
68 | P a g e
Fig 3.21 Activity diagram for Request.
3.3 State chart modelling
A state chart diagram shows the behavior of classes in response to external stimuli
(SOURCE). This diagram models the dynamic flow of control from state to state within a
system.
Fig 3.22 State chart Diagram of Actors' login
3.4 Persistence modelling
The rRelational database are is often used as a mechanism to make your objects
persistence because relational databases do not support completely object object-oriented
concepts persistence models are also called data models or entity relationship models
are used to communicate the design of the database to both our user and other developers
(SOURCE).
69 | P a g e
3.5 Deployment modelling
UML deployment diagram shows a physical view of the system, taking software into the real world by
showing how software gets assigned to hardware and how communicateates (SOURCE ??). The
deployment diagram shows how the software components, processes, and objects are deployed into the
physical architecture of the system. It shows the configuration of the hardware units (e.g. Computers,
communication devices, etc.) and how the software components are distributed across the units. [2]
Haramaya University's Online clearance Clearance System is a server server-client structure

architecture, where clients access services offered by the server. The deployment diagram is shown as
follows.
Figure 3.23 deployment Deployment modelling diagram
70 | P a g e
3.6 Normalized Physical Database Model
Based on the provided attributes, here's an example of a normalized physical database model
for an online clearance system in an educational institution:
Entities and their attributes in the normalized physical database model for an online
clearance system:
1. Student:
 Student ID (Primary Key)

 First Name
 Last Name
 Student Number
 Department ID (Foreign Key referencing Department table)
 Other student-related attributes (e.g., address, email, phone number)
2. Proctor:
 Proctor ID (Primary Key)

 FirstName
 Last Name
 Other proctor-related attributes (e.g., email, phone number)
3. Student Service:
 Service ID (Primary Key)

 Service Name
4. Bookstore:
 Bookstore ID (Primary Key)

 Bookstore Name
5. Library:
 Library ID (Primary Key)

 Library Name
6. Sport Science:
71 | P a g e
 Sport Science ID (Primary Key)

 Sport Science Name
7. Student Loan:
 Loan ID (Primary Key)

 Student ID (Foreign Key referencing Student table)
 Amount
 Loan Date
8. Women Children Youth Affairs:
 Affairs ID (Primary Key)

 Affairs Name
9. College Academy HIT:
 College ID (Primary Key)

 College Name
10. Cafeteria:
 Cafeteria ID (Primary Key)

 Cafeteria Name
11. Department:
 Department ID (Primary Key)

 Department Name
12. Clearance Application:
 Application ID (Primary Key)

 Student ID (Foreign Key referencing Student table)
 Status (e.g., submitted, approved, rejected)
 Submission Date
 Approval Date (nullable)
 Other application-related attributes (e.g., purpose, comments)
13. Document:
 Document ID (Primary Key)
72 | P a g e
 Application ID (Foreign Key referencing Clearance Application table)

 Document Name
 Document Type
 File Location
14. Clearance Officer:
 Officer ID (Primary Key)

 Proctor ID (Foreign Key referencing Proctor table)
 Other officer-related attributes
15. Approval Task:
 Task ID (Primary Key)

 Application ID (Foreign Key referencing Clearance Application table)
 Officer ID (Foreign Key referencing Clearance Officer table)
 Task Status (e.g., pending, completed)
 Due Date
 Completion Date (nullable)
73 | P a g e
74 | P a g e
CHAPTER FOUR
4.1 Implementing strategies
Implementing an online clearance system requires careful planning and execution. Here's a
suggested implementation strategy
1. Define Requirements: Clearly define the requirements of the online clearance system,
considering factors such as user roles, clearance types, workflow, document management, and
integration with existing systems.
2. Select a Technology Platform: Choose a technology platform that aligns with your
organization's needs and capabilities. Consider factors such as scalability, security, user
experience, and integration capabilities.
3. Develop a Project Plan: Create a detailed project plan outlining the tasks, timelines,
resources, and dependencies required for the implementation. Identify key milestones and
allocate responsibilities to team members.
4. Design User Interface and Experience: Design an intuitive and user-friendly interface
for the online clearance system. Consider the needs of different user roles and ensure a
seamless and efficient user experience.
5. Develop the System: Begin the development process based on the defined requirements
and project plan. Implement the necessary functionalities such as user registration, application
submission, document management, workflow management, and reporting.
6. Integrate with Existing Systems: If required, integrate the online clearance system with
existing systems such as databases, identity management systems, or payment gateways.
Ensure data consistency and smooth information flow between systems.
7. Test and Quality Assurance: Conduct thorough testing of the system to identify and
resolve any bugs, errors, or usability issues. Perform functional testing, performance testing,
security testing, and user acceptance testing to ensure the system meets the defined
requirements.
8. Training and User Adoption: Provide comprehensive training to users, including

applicants, approvers, and administrators, on how to use the online clearance system
effectively. Encourage user adoption by highlighting the benefits and advantages of the new
system.
75 | P a g e
9. Deployment and Go-Live: Prepare for the deployment of the online clearance system by
setting up the necessary infrastructure and configurations. Gradually transition users from the
old clearance process to the new system. Monitor the system closely during the initial go-live
phase to address any issues that may arise.
10. Ongoing Support and Maintenance: Establish a support mechanism to address user
queries, provide assistance, and address any system issues that may arise. Plan for regular
maintenance and updates to ensure the system remains secure, reliable, and up to date.
11. Continuous Improvement: Gather feedback from users and stakeholders to identify
areas for improvement. Continuously enhance the system based on user needs, technological
advancements, and changing business requirements.
4.2 Testing
When testing an online clearance system, you would typically perform various types of
testing to ensure its functionality, performance, security, and usability. Here are some
important testing types to consider for an online clearance system:
1. Functional Testing: Verify that the online clearance system meets the functional
requirements. Test the system's features, such as user registration, application submission,
approval workflow, document upload, status tracking, and reporting.
2. Usability Testing: Evaluate the user interface and user experience of the online clearance
system. Test how easily users can navigate through the system, complete tasks, and
understand instructions. Gather feedback from users to identify any usability issues and make
necessary improvements.
3. Performance Testing: Assess the performance and scalability of the online clearance
system. Test its response time, throughput, and resource utilization under different load
conditions. Ensure that it can handle the expected number of users and process clearance
applications efficiently.
4. Security Testing: Validate the security measures implemented in the online clearance
system. Test for vulnerabilities such as unauthorized access, data breaches, injection attacks,
and cross-site scripting (XSS). Verify that sensitive information, including personal data and
documents, is properly protected.
76 | P a g e
5. Integration Testing: Test the integration points between the online clearance system and
any external systems it interacts with, such as databases, identity management systems, or
payment gateways. Verify that data is exchanged correctly and there are no issues with data
consistency, synchronization, or communication.
6. User Acceptance Testing (UAT): Engage actual users or representatives from the target
user group to perform UAT. Users will execute real-life scenarios, including submitting
applications, reviewing documents, and approving or rejecting clearance requests. Collect
feedback and address any usability issues or functional gaps identified during UAT.
7. Regression Testing: Conduct regression testing after making changes or updates to the
system to ensure that existing functionality has not been affected. Re-test previously tested
features to ensure they continue to work as expected.
8. Accessibility Testing: Ensure that the online clearance system is accessible to users with
disabilities. Test for compliance with accessibility standards, such as WCAG (Web Content
Accessibility Guidelines), to provide an inclusive experience for all users.
9. Disaster Recovery Testing: Test the system's ability to recover from failures or disasters.
Simulate scenarios such as server crashes, data loss, or system downtime to evaluate the
effectiveness of backup and recovery mechanisms.
10. Cross-Browser and Cross-Device Testing: Verify that the online clearance system
functions correctly across different web browsers (e.g., Chrome, Firefox, Safari, and Edge)
and on various devices (desktops, laptops, tablets, and mobile devices).
4.3 Unit Testing
When performing unit testing for an online clearance system, you would typically focus on
testing the individual units or components that make up the system. Here are some examples
of units that you might consider testing:
1.User Registration Unit: Test the functionality related to user registration, including
validating user input, creating user accounts, and ensuring proper storage of user data.
2.Application Submission Unit: Test the unit responsible for handling the submission of
clearance applications. Verify that the application data is correctly captured, validated, and
stored in the system.
77 | P a g e
3. Workflow Management Unit: Test the unit responsible for managing the workflow of
clearance applications. This includes verifying that applications move through the correct
stages, tasks are assigned to the appropriate individuals, and notifications are sent as required.
4. Document Upload Unit: Test the unit that handles the uploading and storage of supporting
documents for clearance applications. Ensure that documents are properly received, stored
securely, and associated with the correct application.
5. Approval Process Unit: Test the unit responsible for managing the approval process for
clearance applications. Verify that approvals are correctly processed, rejections are handled
properly, and notifications are sent to the relevant parties.
6. Reporting Unit: Test the unit responsible for generating reports and analytics related to
clearance processing. Validate that the reports are accurate, contain the expected data, and are
generated in the desired format.
7.Integration Units: If the online clearance system interacts with other systems or APIs, you
would also test the units responsible for integrating with those external components. This
could include verifying data exchange, authentication mechanisms, and error handling.
4.4 Integration Testing
After we test each unit of the proposed system we will perform an integration test to check
whether the system meets all the functional requirements. When a number of components are
complete; it will test to ensure that they integrate well with each other, the operating system,
and other components.
4.5 System testing
After all of the above testing are checked we will test our system by other peoples and we will
conduct some comments how they get our system.
78 | P a g e
CHAPTER FIVE
5.1 Conclusions
Reference ???
79 | P a g e

Final Project Documentation

Uploaded by

Copyright:

Available Formats

You might also like

Final Project Documentation

Uploaded by

Document Information

Original Description:

Original Title

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

Final Project Documentation

Uploaded by

Copyright:

Available Formats

COLLAGE OF CONFUTING AND INFORMATIC

DEPARTMENT OF INFORMATION SCIENCE

1. BEREKET PAULOS 0599/13

2. BETSELOTE TADESSE 3135/12

3. EYOSIYAS BEFIRDU 1042/13

4. FRDOS HASEN 1173/13

SUMITTE TO: INFORMATION SCICENCE DEPARTMENT

SUBMISSION DATE: JANUARY 10, 2024.

Advisor Name: - ____________________________________________________

Date ________________________ signature

1.14 Target beneficiaries of the system...............................................................................................

LIST OF FIGURE AND TABLE

Fig 1.1 Gantt chart...................................................................................................................................

Table 1.1 Hardware Requirement Cost...................................................................................................

Table 1.2 Development Tools..................................................................................................................

Fig 1.2 Team composition.......................................................................................................................

Table 1.3 Work break down structure.....................................................................................................

Figure 2.1 Use case diagram....................................................................................................................

Table 2.1 Use case description for Create Account.................................................................................

Table 2.3 Use case description for Registration......................................................................................

Table 2.4 Use case description for Delete...............................................................................................

Table 2.5 Use case description for Update..............................................................................................

Table 2.6 Use case description for view profile......................................................................................

Table 2.7 Use case description for Search...............................................................................................

Table 2.8 Use case description for Approve............................................................................................

Table 2.9 Use case description for Generate Report...............................................................................

Table 2.10 Use case description for Request...........................................................................................

Fig 2.2 Analysis Level Class Diagram....................................................................................................

Fig 2.3 Students Clearance form.............................................................................................................

Fig 3.2 Sequence diagram for registration...............................................................................................

Fig 3.3 Sequence diagram for login.........................................................................................................

Fig 3.6 Sequence diagram for Search......................................................................................................

Fig 3.7 Sequence diagram for Delete......................................................................................................

Fig 3.9 Sequence diagram for Generate Report.......................................................................................

Fig 3.10 Sequence diagram for Request..................................................................................................

Figure 3.11 Component modelling diagram............................................................................................

Fig 3.12 Activity diagram for Registration..............................................................................................

Fig 3.13 Activity diagram for Create Account........................................................................................

Fig 3.14 Activity diagram for Login........................................................................................................

Fig 3.15 Activity diagram for Delete.......................................................................................................

Fig 3.17 Activity diagram for View........................................................................................................

Fig 3.19 Activity diagram for Approve...................................................................................................

Fig 3.20 Activity diagram for Generate Report.......................................................................................

Fig 3.21 Activity diagram for Request....................................................................................................

Fig 3.22 State chart Diagram of Actors login..........................................................................................

LIST OF ACRONYMS AND ABBREVIATION

UC: Use case

UCID: Use case ID

DB: Data Base

CD-ROM: Compact Disk Read only Memory

PHP: Pre-processor Hypertext Protocol

MYSQL: My Structured Query Language

CSS: Cascading Style Sheet

HTML: Hypertext Mark-up Language

UI: User Interface

UML: Unified Modelling Language

OOD: Object Oriented Design