WALLAGA UNIVERSITY

COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

Title: Online Cost Share Management System For Wallaga University

Shambu Campus

In Partial Fulfillment for the Award of the Degree of

Bachelor of Science in Computer Science

Final Project I

Submitted by:

1.
2.
3.
4.
5.
Advisor:

May, 2024
Shambu, Ethiopia
Table of Content
s
1. INTRODUCTION.............................................................................................................................3
1.1. Background of The Organization.............................................................................................3
1.2. Background of The Project.......................................................................................................3
1.3. Statements of The Problem.......................................................................................................4
1.4. Objective of the Project.............................................................................................................5
1.5. Scope and Limitations of the Project........................................................................................6
1.6. Feasibility Analysis....................................................................................................................6
1.10. Risk and Constraints...........................................................................................................13
2. Description of Existing System.......................................................................................................13
2.1. Function of Existing System with Clear Input, Process and Output...................................13
2.2. Business Rules..............................................................................................................................13
2.5. Problem of Existing System Using Pieces Frame Work........................................................15
2.6. Practice to Be Preserved from Existing System.....................................................................16
2.7. Alternative Option to Address the Problem of Existing System..........................................16
2.7.1. SWOT Analysis.......................................................................................................................16
3.2 Sequence Diagram...........................................................................................................................39
3.3 Activity Diagram...........................................................................................................................44
3.5 Class Responsibility Collaboration (CRC) Analysis......................................................................47
3.6 Class Diagram................................................................................................................................49
 No table of figures entries found.
Table 1: Project budget plan........................................................................................................................9
Table 2: Use Case Description for Login.....................................................................................................23
Table 3: Use case Description for Create Account.....................................................................................24
Table 4: Use case Description for Update Account....................................................................................25
Table 5: Use case Description for View Account........................................................................................26
Table 6: Use case Description for Fill Cost Sharing....................................................................................27
Table 7: Use case Description for Register Cost.........................................................................................28
Table 8: Use case Description for Update Cost..........................................................................................29
Table 9: Use case for Upload Student List.................................................................................................30
Table 10: Use case Description for Send Feedback....................................................................................31
Table 11: Use case Description for View Feedback....................................................................................31
Table 12: Use case Description for Post Notice.........................................................................................32
Table 13: Use case Description for View Notice........................................................................................33
Table 14: Use case Description for Register Payer.....................................................................................34
Table 15: Use case Description for Update Payment Expense...................................................................35
Table 16: Use case Description for View Student List................................................................................36
Table 17: Use case Description for Print Cost Share..................................................................................37
Table 18: Use case Description for View Student Cost Share....................................................................38
Table 19: Use case Description for View Payment.....................................................................................39

List of figures
Figure 1: Use Case diagram.......................................................................................................................22
Figure 2: Sequence diagram for login form...............................................................................................41
Figure 3: Sequence diagram for update cost share status.........................................................................42
Figure 4: Sequence diagram for student fill cost share..............................................................................43
Figure 5: Sequence diagram for send feedback.........................................................................................44
Figure 6: Sequence diagram for update payment expense.......................................................................45
Figure 7: Activity diagram for login............................................................................................................46
Figure 8: Activity diagram for fill cost share..............................................................................................46
Figure 9: Activity diagram for send feedback............................................................................................47
Figure 10: Activity diagram for update payment expense.........................................................................47
Figure 11: Activity diagram for create Account.........................................................................................48
Figure 12: CRC modeling for Login and Cost Sharing Officer.....................................................................48
Figure 13: CRC Modeling for Student and for Inland Revenue Officer.......................................................49
Figure 14: Class Modeling Diagra...............................................................................................................50
 CHAPTER ONE

1. INTRODUCTION

1.1. Background of The Organization

Wallaga University is one of the higher educational organizations in Ethiopia. It was established
in 1997 A. E.C, at Oromia region Nekemte town, which far 328 KM from Addis Ababa the
capital city of Ethiopia. It is situated on an area of 150 hectares. It has three campuses such as
Nekemte Campus, Shambu campus and Gimbi campus, but our project specially focuses on
Shambu campus online cost share management system. In this campus there are many
management systems and cost sharing management system is one of them.

Wallaga university Shambu Campus was opened at shambu town which is located West of Addis
Ababa and this campus was opened at Shambu town in 2010, which is located 330 km
West of Addis Ababa. The campus is located on an altitude of 1000-3300 meters above sea
level, with a minimum and maximum rainfall of 800 mm-2200 mm, respectively. The
topography is undulating with Savannah type of vegetation. The campus, though young for
its age, has made remarkable and multifarious progress in training, research, and
services provision since its establishment.

1.2.Background of The Project

Cost sharing is considered as a government loan program for higher education students to cover
partial cost of services like health care, food, education and dormitory. Any student who has
either graduated or under graduated from higher education of the public institution is required to
share the cost sharing of his/her education, training and other Services based on cost sharing
principle. Cost sharing management system is one of the activities in the higher educational
organizations. Online cost share management system is a process of paying a
cost share that present between the university and student based on the
agreement filled in the university by the students online. The current system
of cost sharing system is manual, and has many problems in finding student
data, wasting time and boring to fill the form, difficult to find and manage
student record information, data loss, data redundancy, and data
inconsistence.

Wallaga University shambu campus cost sharing management system works manually. Since the
system is manual, customers face different problems related to waste time, resource and consume
manpower. By observing the overall problems of Wallaga university shambu campus cost
sharing management system, we are going to solve this problem by developing online cost
sharing management system.

In our project developing online cost sharing management system is better than that of the
existing manual system in different ways related to the customer obtain information online, to
minimize power, wastage of time and money in addition to this online cost sharing system is
more reliable than that of the existing system. Generally, our system benefits the
university as well as students by minimizing the time and manpower,
minimize errors, reduce resource wastage, create satisfied work result and
the system will have accessed everywhere in the university in the given
time.

1.3. Statements of The Problem

In the current system documenting, writing, finding and searching of the specific information of
the student cost share is done manually. Employer cannot manage the cost share efficiently
starting from the donor registration, blood screening, processing, and storage and distribution
information. Moreover, there are manual recording systems, so that each process or workflow
cannot be traced from the database. The current system cannot show the how the cost share is
calculated, difficult for making comments about the cost share services, it becomes tedious for a
seeker to search the information.
 These types of system make the workers to document erroneous and redundancy
information.

 The current system is also consumed the time of worker for completing specific task.
  The need to improve performance and the urgency to solve the above stated problems
contribute to undertake this project into consideration.

1.4.Objective of the Project

1.4.1. General Objective

The main objective of this project is to develop online cost share management
System to facilitate the blood transfusion process.

1.4.2. Specific Objective

We can achieve the general objective which mentioned above by fulfilling the following specific
objective:

 To understand the problems in the existing system and to plan the solution for the
problems identified.
 Analyze the existing system and design better system for the organization

 To design and developed a user friendly system to handle data insertion, updating,
deletion, retrieving on the database.

 Enable students, their parent and seekers to know the detail information about the cost
share in their home.

 To improve information sharing between the organization and the users.

 To design and develop the system

1.5.Scope and Limitations of the Project

1.5.1. Scope of the Project

The scope of the project covers the development of online cost share management system in
Wallaga university Shambu campus. The proposed system is proposed only for a regular student
of Wallaga university Shambu campus. It cannot support the students of Wallaga university other
than Shambu campus and the students those who are dismissed from the university. The
proposed system performs different tasks some of are:

Upload student name

View response

Provide information to the students/generate report

1.5.2. Limitations of the Project
Some of the main limitations of the online cost share management system project are as follows:
 The system does not support languages other than English language.
 The system cannot help people with visual impairment.

 The system is only accessible when the internet is available.

 The system cannot have connected with bank

1.6.Feasibility Analysis

Feasibility study is used to investigate the proposed system in multiple dimensions. It is used to
indicate whether the system feasible or not. Feasibility study is an important phase in both
research and software development process. It enables the developer to have an assessment of
the product being developed. It refers to the feasibility study of the product in terms of outcomes
of the product, operational use and technical support required for implementing it. Feasibility
analysis is undertaken to prove if the proposed system is valuable to implement.
1.6.1. Operational Feasibility

The proposed system will provide best services for university and students and it will be highly

secure. The system will also be on behalf of origination’s goal and user satisfaction, because the

system will be possible to run and use in the organizations LAN internet. So the system will be

operationally feasible or it will be operationally acceptable to users. The system gives better user
interface registration form and storage of user information, easy updating, deletion and
modification etc.

1.6.2. Technical Feasibility

The proposed system can be easily maintained and repaired; technically, the system will be
powerful to be applied by low skilled users as much as possible. There is no need for the
developer involvement in almost all implementation of the entire system. It is easily accessible
by the people who can easily understand natural languages.

1.6.3. Economic Feasibility

As cost/benefit analysis, show the new system is developed using minimum cost and it give a lot
of benefits such as advancing the services of the system, decreasing the work load of the users.

The organization does not use any media advertises because it makes information online and
every one can get the information from the site.

Tangible benefits: are benefits derived from the creation of an information system that can be
measured in money and with consistency. The team has identified the following:-

 Increase in flexibility of the modifying cost share information system.

 Provide higher data backup by designing database for the cost share.

 Reduce resource requirements or unnecessary wastage of resource in cost share

management system like paper, pen and time.

 Increase the speed of activities during searching information.

 Increase online cost sharing management system performance

Intangible benefits: are benefits derived the creation of an information system that cannot be
easily measured in money and consistency. The intangible benefits of the new system are:
 Increase in accuracy of blood bank detail information.
 Faster decision making by searching records from database.

 Increase security by providing authorized user can access.

  Reduce workload of the organization system user’s faster decision making by searching
records from data base.

 Error reduction during filling necessary information about blood donation process.

 Increase efficiency of blood bank management system performance.

Project budget plan (Costs)
Price per unit(birr) Total price(birr)
Material Amount birr cent birr cent
use
computer 1 25,000 - 25,000 -
scanner - - - 600 -
printers - - - 1500 -
Flash 1 350 - 350 -
DVD-RW 2 70 - 140 -
Pen 2 25.00 50 51.00 -
Paper 120 2 240 -
Ruler 1 100.00 100 -
Total 27,981
Table 1: Project budget plan

1.6.4 Legal feasibility

The proposed system has no any conflict with any government directives, because it gave

services for the people effectively and efficiently so the organization is profitable and the system
is politically feasible.

1.7. Significance of The Project

Wallaga university Shambu campus online cost sharing management system provides many
advantages for the students and employees. This means, anywhere and anytime students are
authorized to use this system effectively through internet accesses. This system is expected to
bring remarkable change on cost sharing management system. Thus, it will document the student
information in an organized manner. Among this main significance some of them are listed
below:
 Minimize errors

 Eliminate paper based recording

 Reduce resource wastage
 Easy to use the system
 Minimize work load

 The system can be accessed by multiple users concurrently

1.8.Beneficiaries of The Project

The current system is not using computerized data processing system. So making the system
online will give benefits for the following four aspects.

For students

 It provides full information for the students and the students can use the system.

 The students can view the cost share with its reason and ways of calculation.

 The system can also calculate the cost share accurately and limit un wanted things which
go with manual system, the cost share is calculated based on course (course teacher, lab
teacher, class supporter), food, dorm...

 Also the system can save time and resource wastage for the students.

For Department: In manual system the department can calculate cost share, print and distribute
this calculated cost share across all the students, so it is time and energy consuming. But in this
proposed system the department can only upload the student name, to the system and the system
can calculate the cost share and provide it to the students, the students can view it and fill the
form, so this system save time, resource and energy for the students as well as for the
department. Seeker can see available Blood on the database.

University: the proposed sytem has the following advantage for Wallaga University Shambu
campus:
  The probability of error should be minimal.

 Information retrieval should be precise and effective.

 It can provide full information about the cost share for both the students and the campus,
so the campus can easily get the cost which is paid for the students.

For The Developers: While developing the system

 Developer’s team and skills will be improved knowledge how to conduct and prepare a
web based system.

 Developer’s team problem solving skill will be increase.

1.9.Methodology of The Project

The methods that facilitate us to capture information about requested system is called
Methodology. Starting from proposed system we gathered information and data through different
mechanisms.

System analysis and design methodology

It is a recommended collection of phases, procedures, rules, techniques, tools, documentations
and trainings to improve the quality of a software development effort. We use object oriented
system analysis and design (OOSAD) methodology because of its more acceptable due to its
greater advantage of polymorphism, abstraction and encapsulation.

An object oriented system analysis and design methodology suitable for this particular project
because: -

 Increased reusability
 Users usually understand the objects easily

 It highly reduces the interaction gap between the reality and models

 Object oriented system analysis and design methodology is more user friendly

 Tackle more challenging problems

Data collection methods
To develop online cost sharing management system, the primary task is collecting required data
from different sources to perform further tasks. The data will be gathered from primary and
secondary sources by using the following techniques: -

Observation: -We have observed some data physically by going to their office directly. We
select observation to know the real world environment of the organization manual working. In
the observation part we observe how the manual cost sharing management system is working.

Interview: -The other method we have used to get information about the general view of the
system is by interviewing employee of cost share office and some students. It is fact finding
technique where by the system analyst collects information from individual face to face
interaction. It gives us an opportunity to motivate the interviewee to respond freely and openly.

We have asked different questions: -

 What is the current problem of the manual system?

 How do you work currently? Or
 How to process the current system?
Document analysis: -we also collected certain relevant information from written documents in
the cost share office. Not only that but also we tried to review other relevant documents to
develop our project proposal.
Internet: -internet aids us to see the available sample on the internet and to download different
types of tutorials which help to do our project.
System development and implementation tools
We have used the following software and hard ware tools to do our project:
Software tools: -
The software requirements tools are the instructional components used to develop a system.
Some of the software requirement tools used to develop the system are as follows:
 Windows7: will be used for the system since it is readily available more compatible in
laboratories.
 MYSQLI server: - for designing the database
  Microsoft office Word and power point 2007: - for documenting the corresponding
deliverables associated with the project and for presentation
 Microsoft office Visio: -to design Unified Modeling Language (UML) diagrams.
 GUI software: - to draw user interface of the system.
 WAMP Server: -to test the system by running
 Notepad++:- to write implementation or code
 Web browser: - to run our program or code from the server side

Programing language: Programming language is important to complete the system in the best
way and to make it good, easy and interactive with the customer. It two types server side(PHP)
and client side (JavaScript, CSS, HTML). The programming languages required to develop a
system are:-
PHP: because it is

Easier to fix problems-PHP indicates easily where the problem occurred

Increased efficiency & usability - PHP provides incomparable efficiency and usability
when it is used for the development of websites.

Compatible- PHP is compatible on all operating systems including Windows and UNIX-
among other systems.

Data processing - A website that has been developed using the PHP functions has fast
features of data processing.

Easy to understand - When compared with other scripting languages, PHP can be
understood easily because it has simple techniques and features.
Html: - to display the web page.
CSS: - for the formatting of the system.
Java Script: for data validation
Hard ware tools: -
 Personal computer, printer and scanner
 Flash disk(8GB) and Hard disk(500GB)
1.10. Risk and Constraints
During developing this project, we have faced the following problems that retards back us from
doing the project.
 Lack of enough time and budget: to collect data from many user and organizing this data it
needs money and time, with our study we haven’t enough time and money to do that.
 Failure of electric power and internet connectivity- we try to solve this by taking back up to
external storage devices.
 Lack of material: for collecting data as well as doing the project it needs more computing
which most of the member does not have.

CHAPTER TWO

2. Description of Existing System

2.1.Function of Existing System with Clear Input, Process and Output

Currently Wallaga university Shambu campus cost sharing management system works manually.
Every student fill cost sharing form for his/her partial cost of education, dormitory, and meal
services once at each year until she/he graduated. The cost sharing credit charge can change from
year to year based on economic consideration.
As the system is manual there are different drawbacks among those: -
 Poor way of data handling
 Data lose
 Resource wastages like time, paper, pen, and labor
 Data Redundancy and Inconsistence Problem
2.2.Business Rules

The organization has rules and regulations that should be performed when they give a service for
the students. Those are:-
BR1: All enrolled students are eligible to enter into an agreement for cost sharing and future
repayments.
BR2: Every student should fill cost sharing for his/her partial cost of education, dormitory, and
meal services once per year.
BR3: When students transfer from one university to other university, they expected to fill cost
sharing for total year stayed even one semester fill half annual cost sharing.
BR4: When students dismissed from the university by academic, discipline, other cases; he/she
doesn’t expect to fill cost sharing at that year.
BR5: Any beneficiary student who completes his education shall be given a document stating the
amount owed in cost sharing.
BR6: Every graduate student should fill cost sharing for all years unless he/she can’t get
Temporary degree.
BR7: Every alumnus person to finish the payment he/she get the official transcript otherwise
he/she can’t get.
2.3.Report Generation in Existing System

Data Recording

The current system of Wallaga university shambu campus cost share management system is
based on manual system composed of different files and paper based data strategic physical
system. There is no always use a database recording and reporting systems. Every student
provided with the cost sharing regulation form from the department and fills the form, finally
returns to the department. Any information of the student stores on paper as a document without
any protection mechanism. When a new students come to register, another paper would be
prepared for recording purpose and continues in this fashion so as to the institution hosts the
student. When the student shifts from their first batch to the coming batch, another paper
required to register all personal information of the student on that year. So, having in mind this
ways of operation, it is not difficult to predict that the problem of current working system in
terms of time, money or poor utilization of resources with tedious working style.

Data Storage

All that student information recorded are stored on the forms of physical documents. It is not
difficult to expect the size of the document stored for all students that are hosting by the
university which makes the recording and reporting system difficult from the physically
documented materials. This large size of the document makes searching student’s data difficult,
puts the reliability of the data under quotation mark, makes difficult to prepare a report when the
report is required on time and also it is difficult to update.

Analyzing and reporting the current system

When someone wants to analyze the information and claims to have a report from those
information, it is not as such easy to see the report and difficult to analyze those huge amount of
documents in a short time interval.

Generally, it is impossible to understand how the current is operating, to know what type of
operation does the system incorporates, in what way the recorders prepare a report and search a
specific information from the large document collection.

2.4.Forms and Documents in Existing System

2.5.Problem of Existing System Using Pieces Frame Work

The current manual system, as stated on the statements of the problem, is faced to numerous
(many) problems:
Performance problems:
Unable to provide or retrieve student’s information on time
Wastage of time to organize and integrate fill
Unreliability of student’s information
Redundancy of student’s data
Information problems: The following are problems most probably related to information’s on
the current system.
Loss of student information
Difficult to manage the information due to unorganized data
Difficult to access student’s data
Difficult to update
Business problems: It incurs high cost for the materials necessary to document the data and
manpower
Efficiency problems:
Maximum use of resources
 The speed with which the system executes
Usability problems: Difficult to get easily to used due to the manual working system
2.6.Practice to Be Preserved from Existing System

In the existing system generating the overall report of the organization is done manually and
also the association accepts feedback from students only on the meeting date because of manual
working.

2.7.Alternative Option to Address the Problem of Existing System

After the team has identified the real problem of the existing system which is in a manual
system, the team suggests an alternative option to overcome the problem. The alternative option
is: -
Changing the manual system into automated system that works on online environment. The team
has analyzed the alternative option based on the ability of performance, information flow and
efficiency. This analysis has enforced to select the online system.
After the team has identified the real problem of the existing system which is in a manual
system, the team suggests an alternative option to overcome the problem.

2.7.1. SWOT Analysis

The existing student cost sharing management system has its own strength, weakness,
opportunity and threat.
A. Strength of the Current System
 The system does not depend on the power is off /on
 Not consider any internet connection.
B. Weakness of the Current System
 Time consuming, when processing cost share
 Lack of centralized data source
 Loss of vital documents
C. Opportunities of Existing System: To provide job opportunity for many employees.

D. Threats of Existing System: The manual system easily attacks by human or natural
disasters like fire, theft
2.8.System Requirement of the New System

The purpose of requirement is used to prepare requirement specification before starting the
actual design. This enables the designer to have a clear idea about the structure and content of the
information system.

2.8.1. Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or
activity that must be accomplished. A function is described as a set of inputs, processing, and
outputs. Functional requirements may be technical details, data manipulation and processing and
other specific functionality that define what a system is supposed to accomplish.
The system provides the following basic functionality: -
1. Advertisement and announcement: The system to promoting about the organization what is
there services, how they treat students and others. Like other advertising media, it frequently
involves a publisher, who integrates advertisements into its online content and users of the
system who has an account can be visited published information through internet access.
2. student signup and staff member registration: This online cost share management system
allows the students to view his/her cost share details.
3. Online appointment: The online cost share centers' administrators can then manage their
appointments.
4. Cost share form request and Cross matching: Online cost share management system allows
the students to request for cost share form and in addition, various reports for cost share form
requisition and the cross matching can be generated at run time.
5. Searching functionality: functionality in order to allow normal and privileged users to search
the details of a given user to permit or prevent access.
6. No installation: As it is a web application, it prevents users from any kind of hindrances faced
during installation or up-gradation of application. User simply needs a browser to access the
application.
7. Retrieving Report: Various comprehensive reports can be retrieved any time by the end user
to measure the performance parameters in the cost share and to analyses the user and other
aspects in cost share management system.
 2.8.2. Non-Functional Requirements
Non-functional requirements describe how the system works, while functional requirements
describe what the system should do. They specify criteria that judge the operation of system
qualities to capture the required properties of the system. Then the team is going to develop its
own nonfunctional requirements, such as: -
 Availability: The system, which is called online cost share management system for Wallaga
university, is available all the time if internet connection is reliable.
 Security: Security is major problem now a day. People’s knowledge and ability to bypass
security measures is also one constraint to build more secured systems. Besides the usual
authorization and authentication (deals with identifying a user and what a user is allowed to
do respectively) such as username and passwords. The new cost sharing management system
considers these security risks.

 Performance: The response time that the system uses to process, query and retrieve cost
sharing data and information from database is very short. That means it takes short response
time for a given piece of work. The designed system will use low utilization of system
resource in terms of space and time. Many tasks can be performed on the same time that in
turns provide time and cost effective services.

 Usability: The online cost sharing management system is simple to understand, easy to
use and user friendly because it making questioners in native language.

 Efficiency: Accommodating vast amount of information on a computer and processes cost

sharing management system in fraction of seconds.
 Modification/ maintainability
 Through time there should be changes in when the user needs another additional
functionalities and new features, when the cost share administrator identifies the system need
to be modified, while the cost share system work style is changed and depending on different
reasons. This can be easily done because the whole system development tasks divided into
several smaller work parts. Since the system was modularized not the whole system should
be maintained rather only the specific modules that need modification will be modified and
maintained. Some of the user interface and basic modification can be performed by the
collection of developers but the system developers are the right persons to update the system.
 Graphical user interface: The system we are going to develop will have a user friendly
graphical user interface (GUI) which allows users to interact with the system easily. The user
 is expected to have knowledge of using device and also navigating through this device
interfaces.

 Error handling: - When a user interacts with the system errors may occur. To control this
kind of inaccuracies system will generate different user friendly messages. To do this, most
of the system execution buttons will be controlled according to the sequence which the user
is expected to follow, or this can be done by generating different system responses to the
input of the user.
 CHAPTER THREE

3. SYSTEM MODELING

3.1.Use Case Diagram

The use case diagram is concerned with the interaction between the system and actors (objects
outside the system that interact directly with it). It presents a collection of use cases and their
corresponding external actors. A use case is a generic description of an entire transaction
involving several objects of the system. Use cases are represented as ellipses, and actors are
depicted as icons connected with solid lines to the use cases they interact with. A use case
diagram is helpful in visualizing the context of a system and the boundaries of the system’s
behavior. Each use cases in the use case diagram can also be described using a narrative form.

Use case diagram is one of the unified modeling language which represents user’s interaction
with the system and depicting the specifications of a use case. The purposes of use case diagrams
can be as follows: -

 Used to gather requirements of a system

 Used to get an outside view of a system
 Identify external and internal factors influencing the system
A Use Case represents a discrete unit of interaction between a user and the system. A use case
diagram contains four components.
1. Boundary: which defines the system of interest in relation to the world around it.
2. Actors: usually individuals involved with the system defined according to their roles.

3. Use cases: which the specific roles are played by the actors within and around the system.

4. The relationships between the actors and the use cases as depicted in the following figure.
1. Actors of the system
Actors: An actor represents anything or anyone that interacts with the system. This may include
people (not just the end user), external systems, and other organizations. Actors are always
external to the system being modeled; they are never part of the system. The actors that will
participate in the system are listed below:
The System Administrator-is the one who maintains and manage account for users and
manages the system.

Student

2. Use cases of the system

The Use case (UC) represents functionality provided by a system unit and expressed by sequence

of message exchange by the system unit and one or more actors of the system. It describes the
interaction between the user and system in a more detailed way than an essential use case. There
are four actors in the current proposed system those are:-

 Admin
 Student
 Cost sharing officer
 Registrar officer
 Inland Revenue officer
 Figure 1: Use Case diagram

3.2.Use Case Documentation

ID: Give an identification number that enables you to make the use case traceable.
Name: The name that you have used in the use case model.
Actor: who interacts with the system either internally or externally?
Pre-condition: what is the expected situation before the use case can be started.
Main scenario (Basic flow of event): which use case performs when it is started?
Alternative scenario (alternative course of action): it is optional but it is the activity done when
basic course of actions failed.
Post-condition: what is expected?
 Name Login
Use case id UC01
Brief When the user enter user name, password and select user type, it checks the
description input from database, if it is valid the user can access, if not it displays error
message.
Actors Cost sharing officer, student, Inland revenue officer, and registrar officer
Pre condition User must be authorized user who has username and password
Post condition The user is authenticated and the system displays all features available for the
role for the user is associated.
Basic flow of User action System response
events
1. The student, cost sharing officer, Inland 2. The system display login
revenue officer, and registrar officers are form
want to login to the system.
4. The system verifies that all
3. The cost sharing officer, student, inland the filled have been filled out
revenue officer and registrar officer Enter and valid.
user name ,password and select user type
then request to login 5. The system successfully
logged in.

6. Use case ends.

Alternate Flow of events

Title Description
A. the user fill invalid 1. The system display message “invalid username or password or user
data type”
2. The system prompts the user to reenter the valid information
3. Use case continues with step 2
Table 2: Use Case Description for Login
 Name Create account
Use case id UC02
Brief description the cost share officers create account for their staff workers, for
registrar officer and for inland revenue officer
Actor(s) Cost sharing officer
Pre condition they must be authorized
Post condition Create account for users
Basic flow of events User action System response
1. The Cost sharing officer request to 2. The system display
create account create account Form
3. The Cost sharing officer fill 5. The system display
information that included id, full name, message “account created
sex, phone, user name and select user successfully”
type 6. use case ends
4.the Cost sharing officer request to
create
Alternate flow of events
Title Description
A. The cost sharing officer inserts 1. The system display message “account not
invalid user account information successfully created”
2. The system prompts the user to reenter the valid
information
3. Use case continues with step 2
Table 3: Use case Description for Create Account
 Name Update account
Use case id UC03
Brief description The user update their account created before because of security
Actor(s) Student ,inland revenue officer, registrar officer , staff workers of
cost sharing
Pre condition They must be authenticated
Post condition The authenticated users able to update their account
Basic flow of events User actions System response
1.the user with the system to update 2.the system display the form
account 5. the system validate the
3.the user entered the required entered data
information that include 6. the system display
3.1 user name message ”successfully
3.2 old password updated”
3.3 new password 7.use case ends
3.4 confirm new password
4. the user request to update

Alternate flow of event

Title Description
A. Enter invalid data entry 1. The system describes which entered data was
invalid
2. Re-enter the valid data
3. Go to step 2
Table 4: Use case Description for Update Account
 Name View account
Use case id UC04
Brief description User may graduate or stop because of some problems so user account
will be disable.
Actor(s) Cost sharing officer
Pre condition The account should be created
Post condition the account is enable or disable
Basic flow of events

Include:- User action System response

Disable account 1.the Cost sharing officer want to 2.the system display the
Enable account enable or disable user account form

3.The Cost sharing officer search any 4.the system validate the
user account he/she wants using id existence of the account and

5.User request to enable or disable the display searched account

searched account 6. the system display
message
7. use case ends
Alternate flow of events
Title Description
A. the cost sharing officer enter invalid 1. system display error message
data 2. the system prompts to re-enter field

3. use case continues with step 2

Table 5: Use case Description for View Account

 Use case Fill cost Sharing
Name
Use case id UC05
Brief The students fill cost sharing form based on cost sharing principles
description
Actor(s) Student
Pre condition student wants to fill cost share agreement form
Post Store the agreement into database
condition
Basic flow of User actions System
events response
1.Students want to fill agreement of cost sharing 2. the system
displays the
3. Student fills all necessary information to the form such form
as
6. The system
3.1 date of withdrawal (date, month, year, semester) make sure all
inputs are filled
3. 2. transferred from other university (name, college,
(check the input
department)
is valid or not)
3.2.1 date of transfer (date, semester)
7. The system
3.2.2 total cost before coming saves the input
data and the
3.3.type of service you choice following
information
3.3.1.In kind(food only, boarding only, food and boarding)
7.1 year, price
3.3.2.In cash(food only, boarding only, food and boarding) for(food,
3.5 If the student is graduate class he/she fill in addition to dormitory,
the above education, total)
Into DB
3.6.1 type of payment(to provide service, to be paid my
income) 8. The system
display” fill
3.6.2 duration of year successfully”
message
4. choose photo if any
9. Use case ends
5. student press submit button after filling the form

Alternate flow of events

Title Description
A. Enter invalid data entry 1. The system display the entry data is invalid
2. Go to step 2
3. Use case ends
Table 6: Use case Description for Fill Cost Sharing
 Name Register Cost
Use case id UC06
Brief description the cost sharing officer register the cost of food, dormitory, education
base on the year and department
Actor(s) Cost sharing officer
Pre condition the cost sharing officer must login successfully
Post condition The cost data has been registered
Basic flow of events User action System response
1.The Cost sharing officer want to 2.The system displays register
register cost form
3. the Cost sharing officer fills all 5. the system validate the
necessary information to the form entered data and then display
such as:- ”successfully registered”
3.1. Select department message
3.2. Select year 6.Use case ends
Enter price for:-
3.3. Education
3.4. Food
3.5. Dormitory
4.the Cost sharing officer request to
submit
Alternate flow of event
Title Description
A. Enter invalid data 1. System display error message
2. Use case continues with step 2
Table 7: Use case Description for Register Cost
 Name Update Cost
Use case id UC07
Brief description It allows the cost sharing officer to update the cost
Actor(s) Cost sharing officer
Pre condition the cost sharing officer must login successfully
Post condition The cost of food, education, dormitory data has been updated
Basic flow of events User action System response
1.The Cost sharing officer want to 2.The system displays update
update cost form
3. the Cost sharing officer fills all 5. the system validate the
necessary information to the form entered data and then display
such as:- ”successfully updated” message
3.1. Select department 6.Use case ends
3.2. Select year
Enter price for:-
1.3. Education
1.4. Food
1.5. Dormitory
4.the user request to update
Alternate flow of event
Title Description
A. Enter invalid data 1. System display error message
2. Use case continues with step2
Table 8: Use case Description for Update Cost
 Name Upload Student List
Use case id UC08
Brief description The registrar Upload student list into database then the system create
account for each students automatically
Actor(s) Registrar
Pre condition the Registrar officer must login successfully
Post condition the student information has been recorded success fully
Basic flow of events User action System response

Include:- 1. the registrar officer want to upload 2. the system display the form
New student list student information 5. The system automatically
Graduate student list 3. A. the registrar officer upload the creates account for each
new student file from excel that include student’s that have not an
account before. using(id as a
3.1. Full name, id, sex user name& mother first name
3.2. Region, woreda, phone number as a password)
5.1 the system also updates
3.3. University name, faculty, year of his previous information if it
entrance, department, academic year is different
3.4 Mother adopters (full name, phone 6.the system save information
number) into database
7. the system display
3. B. the registrar officer upload the
“Successfully upload”
Graduate student file from excel that
message.
include( id, full name , faculty,
department, graduation year , total cost 8.use case ends
expense)

4.the registrar request to upload

Alternate flow of events

Title Description
A. The user 1 the system display invalid entry message
select invalid 2 The system prompts to re-enter the valid data
data entry 3 use case continue with step 2
Table 9: Use case for Upload Student List
 Name Send Feedback
Use case id UC09
Brief description Describing about strength and weakness of the system
Actor(s) Student
Pre condition The student successfully login
Post condition Give comment
Basic flow of events User action System response
1. the Student request to 2. The system display the form
comment 4. The system save comments
3. the student write 5. The system display “successfully
comment and then request sent” message
to submit 6. The use case ends
Alternate flow of events
Title Description
A. if the text area is empty 1. The system display “please write
comment” message
2. Go-to step 2
Table 10: Use case Description for Send Feedback

Use case Description for View Feedback

Name View Feedback

Use case id UC10
Brief description the cost sharing officer can view the feedback sent by students
Actor(s) Cost sharing officer
Pre condition The feedback requested from the student
Post condition To view the feedback
Basic flow of events User actions System
response
1.The Cost sharing officer want to view the 2.The system displays
feedback the requested feedback
3.The Cost sharing officer view feedback 4.Use case ends
and then give response
Table 11: Use case Description for View Feedback
Use case Description for Post Notice

Name Post Notice

Use case id UC11
Brief description The cost sharing officer and Inland Revenue Officer post notice
Actor(s) cost sharing officer, Inland Revenue Officer
Pre condition They are successfully login
Post condition Post notice they required
Basic flow of events User action System response
1. cost sharing officer and want to post notice 2.the system displays
3. Cost sharing office, Inland Revenue Officer r notice form
enter the required data such as:- 5.the system display
3.1. Notice number “successfully sent
message”
3.2. body
6.use case ends
3.3. Select receiver
4.the cost share officer , Inland Revenue Officer
request to post

Alternate flow of If the user entered invalid data then The system describes which entered
events data was invalid and Re-enter the valid data and go to step 2
Table 12: Use case Description for Post Notice
Use case Description for View Notice

Name View Notice

Use case ID UC12
Brief description The student and registrar officer view the notice posted by the cost sharing
officer
Actor(s) Student and registrar officer
Pre condition They must be authenticated
Post condition Able to access the required information
Basic flow of User action System response
events 1.student and registrar officer request to view notice 2.the system display
3. The registrar officer and student views the the posted notice
posted notice 4. Use case ends.
Alternate flow of If no information found the system will display the warning message
events like” no information are posted”
Table 13: Use case Description for View Notice
 Use case Description for Register Payer

Name Register Payer

Use case id UC13
Brief description The employee payment expense should be register with in inland revenue
officer when she/he begin to pay
Actor(s) Inland revenue officer
Pre condition The payer file must be upload by registrar officer
Post condition Register payer
Basic flow of User action System response
events 1.the user want to register payer 2. the system display the form
3.the inland revenue officer enter 5.the system validate the entered data and
the required data such as:- automatically perform some tasks:-
3.1. id 5.1 stores (full name, date, total,
3.2 .tin number graduation year, department, facaluty)
4. the inland revenue officer then save into DB.
request to register 6. the system displays
“successfully register “message
7.use case ends
Alternate flow of A. If the user entered invalid id number then the system describes which
events entered id number was invalid and Re-enter the valid data then go to
step 2.
B. If the entered id or tin register before the system display ”this person
register before” and then go to update payment expense form.
Table 14: Use case Description for Register Payer
 Use case Description for Update Payment Expense

Name Update Payment

Use case id UC14
Brief The student payment expense should be update with in inland revenue
description officer when she/he pays
Actor(s) Inland revenue officer
Precondition The student must be begin payment
Post condition Update student payment
Basic flow of User action System response
events 1.the user want to update 2. the system display the update payment
payment expense expense form
3.the inland revenue officer 5.the system validate the entered tin and
enter the required data such then automatically perform some tasks:-
as:- 5.1 calculate interest
3.1. tin number 5.2 store date
4. the inland revenue officer 5.3 store subtrahend
request to update 6. the system displays
“successfully updated “message
7.use case ends
Alternate flow If the user entered invalid tin number then The system describes which
of events entered tin number was invalid and Re-enter the valid data then go to step 2.
Table 15: Use case Description for Update Payment Expense
Use case Description for View Student List

Name View Student List

Use case id UC15
Brief The inland revenue officer, registrar officer and cost sharing officer view
description student list upload by registrar
Actor(s) Inland revenue officer, registrar officer, cost sharing officer
Per condition They must be login successfully
Post condition To view students
Basic flow of User action System
events 1.the users with the system to view 2.the system display the form
student list 5.the system validate the entered
3. the users select department or batch data display student information
4. the user request to view 6.use case ends
Table 16: Use case Description for View Student List
 Use case Description for Print Cost Share

Name Print cost share

Use case id UC16
Brief description It is allow cost sharing officer print cost share
Actor(s) cost sharing officer
Pre condition They must be successfully login
Post condition print the filled cost share
Basic flow of events User action System response
1.The cost sharing officer 2.The system display the form
want to print the cost share of 4.the system validate the entered data
student’s and display the selected student
3. The cost sharing officer information
enter student id and select 6. The system print the files
year then press search 7. use case ends
5. The cost sharing officer
request to print
Alternate flow of events

Title Description

A. If the cost sharing 1. the system display “the student not register ”or “the student
officer enter invalid id not fill cost share at this year” message
or year 2. the system allow to re-enter
3. go to step 2
Table 17: Use case Description for Print Cost Share
 Use case Description for View Student Cost Share

Name View cost share

Use case id UC17
Brief description The cost share must be filled by students
Actor(s) Registrar officer ,student, cost sharing officer
Pre condition The cost share must be filled by student
Post condition View student cost share
Basic flow of events User action System response
1.The user want to see student cost 2.The system display the
share form
3.The user enter the required data 5.the system validate the
include:- entered data and display the
2.1 id student cost share status
2.2 year 6.use case ends
4.the user request to search
Alternate flow of If the user entered invalid data then The system display error message
events and allow to Re-enter the valid data and then go to step 2
Table 18: Use case Description for View Student Cost Share
 Use case Description for View Payment

Name View Payment Status and print the file

Use case id UC18
Brief The inland revenue office view payment status of the payer and print receipt
description
Actor(s) Inland revenue officer
Pre The payer must be begin pay expense
condition
Post View payment status and print Receipt
condition
Basic flow User action System response
of events 1.The Inland revenue officer want to view 2.The system display the form
payment status 5.The system validate the
3.The Inland revenue officer enter TIN number entered data and display the
4. The Inland revenue officer request to search payment status
6. The Inland revenue officer request to print 7. the system print the file
8.use case ends
Alternate If the user entered invalid TIN then the system display error message and allow to
flow of Re-enter the valid data and then go to step 2
events
Table 19: Use case Description for View Payment

3.2 Sequence Diagram

A Sequence diagram is an interaction diagram that shows how objects operate with one another
and in what order. A sequence diagram shows object interactions arranged in time sequence.
Sequence diagrams are sometimes called event diagrams or event scenarios. It is also:-
Represent the details of a UML use case
Model the logic of a sophisticated procedure, function, or operation
See how tasks are moved between objects or components of a process
Plan and understand the detailed functionality of an existing or future scenario[1]
 Sequence diagram for login form

home page login login DB

<<UI>> <<controller>>
user

open

enter user name

&password

click login()
chick validity

invalid

valid

display message

Figure 2: Sequence diagram for login form

 Sequence diagram for update cost share status

update cost update cost

share share DB
<<UI>> <<controller>>

SD for update
cost share cost
sharing
officer open

fill information

update()

check validity

invalid
record data

updated

Figure 3: Sequence diagram for update cost share status

 Sequence diagram for student fill cost share

fill cost share fill cost share

homepage DB
<<UI>> <<controller>>
student

open

access form

fill information

click fill()

check validity

invalid
confirm and record
data

successfully filled

Figure 4: Sequence diagram for student fill cost share

 Sequence diagram for send feedback

send feedback send feedback

DB
<<UI>> <<controller>>
student
access text area

write comment

click send()

check validity

if it is empty

confirm and record

data

sent successfully

Figure 5: Sequence diagram for send feedback

 Sequence diagram for update payment expense

update payment update payment

expense expense DB
<<UI>> <<controller>>
inland
revenue
officer
open

fill information

update()

check validity

invalid

confirm and record

updated

Figure 6: Sequence diagram for update payment expense

3.3 Activity Diagram

Activity diagram represent work flows in a graphical way. Activity diagram is basically a flow
chart to represent the flow form one activity to another activity. Activity diagram is diagram in
UML used to describe dynamic aspects of the system. The purposes of activity diagram can be
described as:

 Demonstrate the logic of an algorithm

 Illustrate a business process or workflow between users and the system
 Simplify and improve any process by clarifying complicated use cases[1]
Activity diagram for login

login
<<UI>>

enter user name

&password
no

yes login
initiate login is valid
successfully

Figure 7: Activity diagram for login

Activity diagram for fill cost share

fill cost share

<<UI>>

fill information
no

yes
initiate send is valid store to DB

Figure 8: Activity diagram for fill cost share

Activity diagram for send feedback

 send
feedback
<<UI>>

fill information

initiate send is valid yes store to DB

Figure 9: Activity diagram for send feedback

Activity diagram for update payment expense

update payment
expense
<<UI>>

fill information
no

yes
click update is valid store to DB

Figure 10: Activity diagram for update payment expense

Activity diagram for create Account

 create
account
<<UI>

fill
information

no
yes
click create is valid store to DB

Figure 11: Activity diagram for create Account

3.5 Class Responsibility Collaboration (CRC) Analysis

Class responsibility collaboration is a collection of standard index cards that have been divided
into three sections. A class represents a collection of similar objects, a responsibility is
something that a class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities

Account
User name Student
Password Cost sharing
Login() officer
Logout() Inland revenue
Manageaccount() officer
Registrar officer

Cost sharing officer

Id Student
Full name Registrar officer
User name Account
 Password
ManageCost()
PostNotice()
ViewFeedback()
ViewCostShare(
)
PrintCostShare()
Figure 12: CRC modeling for Login and Cost Sharing Officer

Student )
Id Cost sharing officer Inland revenue officer
Full Name Registrar officer Id Student
Age Inland revenue Full name Registrar
Sex officer
User name officer
Department Account
Password Account
User name
Postnotice()
Password
ManagePayment()
FillCostShare()
ViewGraduateStudentList()
SendFeedback()
Figure 13: CRC Modeling for Student and for Inland
ViewNotice() Revenue Officer
ViewCostShare()
ViewPaymentStatus(
3.6 Class Diagram
UML class diagrams are the mainstay of object-oriented modeling. Class models show the
classes of the system, their interrelationships (including inheritance, aggregation, and
association), and the operations and attributes of the classes. Classes are depicted as boxes with
three sections: the top one indicates the name of the class, the middle one lists the attributes of
the class, and the third one lists the methods. By including, both an attribute and a method box in
the class. Another approach would be to have two sections, one for the name and one for the
responsibilities.
Class diagram provide an over view of target system by describing the object and classes inside
the system and the relationship between them.

Student Cost Share

* 1
1 Fill * Cost Sharing Officer
View
-Department:String * 1
-Batch:Year Update
-Region:String 1
+Fill() *
-Woreda:String
+View()
-Academic Year:Year Register
+Update()
-Faculty:String
+Register() 1
View *
1 * +Print()
Print
1 * 1
1 1
1 1

Post
* 1 * *
*
Person Account Notice
FeedBack *
+Id:String -Id:int -NoticeNumber:String
-Full Name:String +Email:String +Create() -Date:date
-User Name:String -Date:date +View() -Body:String
-password:String 1
+Update() * -Sender Name:String
-Sex:String +Send()
+Disable/ Enable() +Post()
-Phone:int +View()
1 +View()
*
View

1
1
1 Registrar Officer
Inland Revenue officer 1 Payment

-Id:String
1 +TIN Number:String
*
Manage -Date:date
+Register()
+Update() +UploadStudentFile()
+View()
+Print()

Figure 14: Class Modeling Diagra