WOLLO UNIVERSITY KIOT

COLLEGE OF INFORMATICS
DEPARTEMENT OF COMPUTERSCIENCE
WEB BASED CUSTOMER SERVICE MANAGEMENT SYSTM FOR
KOMBOLCHA WATER SUPPLY SERVIC OFFICE
PREPARED BY:

NAME ID

1. Mesfin Shifera -----------------------------------------ITR/1339/03

2. Kalkidan Misganaw -----------------------------------ITR/1515/03

3. Aliheyder Jemal----------------------------------------ITR/1306/03

4. Adamu Girma-------------------------------------------ITR/1305/03

5. Tigst Yimam-------------------------------------------- ITR/1355/03

6. Teshome w/tensey-----------------------------------ITR/051/02

Advisor: Mr. Yonas Abate

1
 Acknowledgments
We would like to thank GOD for giving us strength and health to complete this project. We
also grateful to our advisor Mr. Yonas Abate for his motivate and constructive guidance as of the
beginning of problem formulation to the completion of the project.

We would like to forward our special thanks to Kombolcha city water supply service office staff
employee.

Finally, we want to extend our thanks to our parents for their encouragement, Motivation and
support throughout our study.

2
Lists of table
1 Page

Table 1.1 project cost plan ………..…………………………………………………………

Table 1.2 Project schedule………..…………………………………………………………
Table 1.3 Task Breakdown and Deliverables……….………………………………..……..

2
Table 2.6.1 Apply register ………..……………………………………………………………
Table 2.6.2 Update customer ………..………………………………….………………………
Table 2.6.3 Delete customer……….……………………………..………..……………………
Table 2.6.4 Post vacancy………..………………………………………………………………
Table 2.6.5 Create account………..………………………………………………………………
Table 2.6.6 record meter reading………..………………………………………………………
Table 2.6.7 record maintain material………..………………………………………………….

Table 2.6.8 view report………..……………………………………………………………..…

3
Table 3.3.1 Use case documentation for Login…………………………………………………….
Table 3.3.2 Use case documentation for Create Account………………….………………………
Table 3.3.3 Use case documentation for Delete Account………………………………………….
Table 3.3.4 Use case documentation for Apply register………….…………………….…….……
Table 3.3.5 Use case documentation for Update customer……………………………….……….
Table 3.3.6 Use case documentation for Delete customer………… ……………………….…….
Table 3.3.7 Use case documentation for Order maintenance………………………………….….
Table 3.3.8 Use case documentation for Receive maintenance…………………………….…….
Table 3.3.9 Use case documentation for View Report ……………………………………......…
Table 3.3.10 Use case documentation for Calculate cost of Bill………………………………...
Table 3.3.11 Use case documentation for Record meter reading………………………………..

3
Lists of Figures
2 Page
Fig 2.1: Essential use case diagram ………………………………………………. ………..
Fig 2.1: UML use case diagram ……………………………………………………………..

3
Fig 3.5.1: UML Sequence diagram for Customer Apply Register…………………………..
Fig 3.5.2: UML Sequence diagram for Calculating Bill ………….………………………...
Fig 3.5.3: UML Sequence diagram for View Report ……………………………….……….
Fig 3.5.4: UML Sequence diagram for Update Customer ……………………………….….
Fig 3.5.5: UML Sequence diagram for Order Maintenance ………………………….……..
Fig 3.5.6: UML Sequence diagram for Delete Customer ………………………….………..
Fig 3.5.7: UML Sequence diagram for Receive maintenance ………………………….…...
Fig 3.5.8: UML Sequence diagram for Create account ………………………….……….....
Fig 3.5.9: UML Sequence diagram for Delete account ………………………….…………
Fig 3.5.10: UML Sequence diagram for login ………………………….………………….
Fig 3.5.11: UML Sequence diagram for water meter reading………………………………
Fig 3.6.1: UML activity diagram for Apply Register………………………………………
Fig 3.6.2: UML activity diagram for Login administrative staffs…………….……………
Fig 3.6.3: UML activity diagram for View Report…………………………………………
Fig 3.6.4: UML activity diagram for record meter reading………………………………..
Fig 3.6.5: UML activity diagram for Calculate cost of bill …………….………………….
Fig 3.6.6: UML activity diagram for Receive maintenance………………………………..
Fig 3.6.7: UML activity diagram for Order maintenance………………………………….
Fig 3.6.8: UML activity diagram for Create account …………….……………………….
Fig 3.6.9: UML activity diagram for Delete account……………………………….. …...
Fig 3.6.10: UML activity diagram for Delete customer…………………………………..
Fig 3.6.11: UML activity diagram for Update Customer …………….…………………..
Fig 3.6.12: UML activity diagram for post vacancy………………………………………
Fig 3.7.1: User interface prototype……….……………………………………………….

4
4

Figure 4.2.1: Class type architecture….………………….. ………………………………....

Figure 4.3.1: Class Diagram….………………………………………………………………
Fig 4.4.1: State chart diagram for login……………………………………………………….

Fig 4.4.2: State chart diagram for record payment…………………………………………..

Fig 4.4.3: State chart diagram for record meter………………………………………………

Fig 4.4.4: State chart diagram for Material register………………………………………….

Fig 4.4.5: State chart diagram for Customer register…………………………………………

Fig 4.4.6: State chart diagram for view report……………………………………………….

Fig 4.4.7: State chart diagram for post vacancy……………………………………………..

Fig 4.4.8: State chart diagram for create account……………………………………………

Fig 4.5.1: Component modeling…………………………...…………………………………

Fig 4.5.1: Deployment modeling…………………………...………………………………..

Fig 4.7.1: Home page…………………………...…………………………………………...

5
1. Introduction
As we know, today our world is under the control of technology because of this reason the
world are related each other. Our country is one part of the world but, we are too late according
to this technology as compare as others western countries.
Even if our country is not developed in this project, we try to change the desktop application
system of kombolcha water supply service office (KWSSO) into web based system using today’s
technology. KWSSO has many activities. Such as, Customer registration, Calculating bill based
on their customer information and the likes. When we see how the new customer joins the
organization, it requires physical present to the office. So, the project try to reduce this problem
and enable the office system to have very fast service to their customer by designing web based
service management system for them.

6
1.1 Background
Kombolcha water supply service office (KWSSO) is a water supply Organization which
found in Kombolcha city. The organization establishes in 1962E.C.At that time the offices have
only 5 employees (one water clearance expert (water chemist), one motor operator, one meter
reading expert and two Security bodies).Until 2003E.C KWSSO follows manual based office
system which means, they follow traditional way of giving service for their customer. At
2003E.C the office develop its own Desktop application system. This Desktop application
limited to customer register and calculate belling system. Not generate organized report; the
information can’t visible to customer, and the likes. The system only visible to employee. Until
1971E.C the office has only 300 customers which register to use the service.
Currently the office have 80 employees(29 technician staff,51 management and finance staff)
from those 20 women and 60 mens.This office done many activities like, customer registration,
Bill process calculating, and meter number registration and viewing reports for them, taking
customers maintenance order and respond it. Currently, this organization has 10128 customers
and has 80 employees which they register under this office.

1.1.1 Vision
The vision of KWSSO is to see produced enough and pure water for drinking, for industrial, and
for irrigation of city, for the population living in Kombolcha city and it’s around.

1.1.2 Mission
The mission of KWSSO is to increase income with direct proportional of balancing city’s
development and by adding extra water resource areas to give pure and enough water for the
city’s societies.

7
1.2 Description of the existing system
Kombolcha water supply service office (KWSSO) is using Desktop application system.
Registration of new customers and bill calculating using by this system. But, the system can’t
generate organized report, detail customer information can’t visible to customer, when we see
how the new customer joins the organization, it requires physical present to the office. The report
prepared by paper or manual. The organization vacancy announcement submits by paper or on
the board.

Existing system is difficult for:-

Vacancy announcement,
Getting feedbacks from the customer,
Making comments to customers,
Searching single data is time consuming,
Deleting Updating customer data is difficult,
Prepared organized report etc.

Kombolcha water supply service office (KWSSO) Desktop application system is time taking,
unqualified, costly and not satisfactory. Employee spend much time to prepare report due to all
information is transferred manually by paper-based method and difficult to register new
customer, it must physically join to the office, customers cannot see their payment on time.

1.3 Statement of the problem and justification of execution the

project
1.3.1 Statement of the Problem
KWSSO is currently uses Desktop application systems. As it is desktop application, they have
their own problem like:

Vacancy announcement,
Registration of customer,
Registration of material,
Registration of meter reading,
Getting feedbacks from the customer,
Making comment to customer,
Searching for even single data is time consuming,
Redundancy (multiple records of the same data).
Difficult in preparing an organized report etc.

8
 1.3.2 Justification for execution of the project
We are interested to overcome and solve the above mentioned problems by developing web
based system. We believed that the new proposed system will help the kombolcha water supply
service office (KWSSO) to accomplish their tasks such as customers’ registration, storing and
retrieving customers’ information as well as generating an organized report in efficient and
effective manner. Post vacancy announcement, getting feedbacks from the customers, making
comments to customers,

1.4 Objective of the project

1.4.1 General objectives
The general objective of the project is to develop web-based customer service management
system for Kombolcha water supply service office (KWSSO).

1.4.2 Specific objectives

 Studying the background of the organization,
 Stud the existing system,
 Develop a database that holds information about customer,
 Identifying the problem under the existing system,
 Identifying the problem under the existing system,
 System analysis and object design,
 Implementations of the system,
 Testing of the system,
 Requirement analysis of the system ,
 Collecting data about the organization,

1.5 Scope and limitation of the project

1.5.1 Scope of the project

Web based system of KWSSO is too huge in its scope but, the project is limited on the
following points only:-

 On the registration of the new customers.

 Give Vacancy announcement for customer and employee.

9
  On the registration of the maintain material.
 On the registration of meter reading.
 On the registration of the payment.
 Generate Report.
 Updating, deleting, searching customers by the employee of the office which are
responsible for the appropriate task.
 To making the workers of the organization more secured by creating login account for
them.
 To develop dynamic web page for future data storage requirement for the office.

1.5.2 Limitation of the project

The project does not work about employee salary or pay rolling nd detail information about
employee because of the following limitation.

Some limitations of our project are:

Lack of Materials: There is no enough computer access, books and references used to show how
Project will be done.

Shortage of time: We are student and in learning process we have shortage of time to complete
the project in one semester. This enforces our project team to minimize the project scope.

Shortage of money: As we are students it is difficult to spend much amount of money on the
project so it limits the effectiveness of the project.

1.6 Risks
During the development of the project there may be different problems that we may face. These
are:

 Unfortunate failure of system: To handle this problem the teams have some method to
resist not completely but partially by using back up mechanisms using flash disks,
CD/DVD and by storing the data in more than two computers.
 Power problem: we tried to use laptops to cover the gap happened to our project during
power failure.
 Virus attack: It is difficult to control data from virus but try to scan the data, installing
and updating antivirus software.

10
  Time management problem: we solve this problem by working cooperatively, divide our
time by schedule for each phase of the project and we try to use this schedule effectively
 One of our group members may be sick while in the process of project development: to
solve this problem the remaining group member together covers this member done.
 Therefore whatever situation happen or occurred that hinder during the
progression of the project the team try the best to do what expected and
reform it.

1.7 Methodology

1.7.1 Method of data collection

As we know there are different methods to collect information. From those the project uses the
following tools and methods respectively to collect data from the organization.
 Observation (Documentation & material): use this method to get the right
information about the organization and also understand how the existing system
works.
 Interview: interview some employee of the organization as well as the customer to
get & share enough and reliable data which is important to do the project.

1.7.2 System analysis and design methodology

The team plan to use the object oriented design methodology for the development of the system
among the different methodologies. Because it is better way to construct, manage and assemble
objects that are implemented in our system. Object oriented design methodology has two
phases:-

Object Oriented Analysis (OOA): During this phase the team will look at the
problem domain and with the aim of producing a conceptual model of the information that
exists in the area which will be analyzed. And this model the functions of the system (use
case modeling), identifying the business objects, organize the objects and also the
relationship between them and finally model the behavior of the objects.
Object Oriented Design (OOD): During this phase the model interactions and
behaviors that support the use case scenario, and finally update object model to reflect the
implementation environment. And also transforms the conceptual model produced in

11
 object-oriented analysis to take account of the constraints imposed to our system format, so
that we will use this phase to refine the use case model to reflect the implementation
environment.

1.8 Hardware and Software Tools of the system development

1.8.1 Hardware tools required are:

 Personal computer (PC): almost all tasks of our project are performed on
computer.
 Flash disk: required for data movement to store & transfer data from one PC to
another PC.
 Disks (CD, DVD): necessary for the movement of relevant data and for
backup and recovery mechanism.
 Network cable: since our system is web based, it is very necessary
requirement. It is also help us to extract relevant information about our project
from internet.
 Server: to store the data.
 Stationeries (pen, paper): for writing all necessary documentations
associated with the project.
 Note book: to take notes during data collection and for other document.

1.8.2 Software tools required are:

 MS-Access: to create and design the database which used to store the information of
the customers & the employee of the organization.
 Windows 7 Operating system: will be used for the system since it is readily
available in laboratories.
 Browsers: -since our system is web based, it is very necessary requirement.

 PHP: -To design the graphical user interface and the whole application.

 MYSQL server 2005 :-for designing the database

12
  Microsoft office Word 2010:-for documenting the corresponding deliverables
associated with the project
 Enterprise architecture and Edraw max 6.8: -for designing Unified
Modeling Language (UML) diagrams.
 Microsoft Visio: used to draw diagrams.

 Adobe Photoshop (CS4): -for editing images.

 Macromedia Dreamweaver 8: For writing a code or program of the system.

 Xampp Server: - To test the system by running.

1.9 Cost of the project

Even though it is different to provide an accurate cost estimates, the following is a rough
estimate of the costs associated with the project.
Types of costs Tool name Quantity Unit price (in Birr) Total price (in Birr)
Hardware costs Computer 1 8000 8000
Flash(4 GB) 1 180 180
CD ROM 2 6 12
DVD 2 18 36
Pen 6 3 18
Paper 1 packet 100 100
Note book 1 30 30
Printing and binding 3(copies) 100 300
Software costs Wamp server 1 Free Free
Microsoft office 2007 1 Free Free
Notepad++ 1 Free Free
Microsoft Visio 1 Free Free
Adobe Photoshop 1 Free Free
Windows 7 OS 1 Free Free
Other costs --- --- ---- 300
Total cost --- --- --- 8,976
Table 1.1: project cost plan

13
 1.10 Schedule of the project
The table below represents the main activities of the project together with their respective start
and end date.
Task name Nov201 Dec201 Jan2014 Feb2014 Mar2014 Api2014 May2014 Jun2014
3 3
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Requirement
gathering &
preparing
Proposal writing
Document
System analysis

User interface
prototyping
Coding & Testing

Table 1.2: Project schedule

1.11 Task Breakdown and Deliverables

Each part of tasks of the project will be delivered by collaborating with each of the group members. Each
group members has their own responsibility to complete the project successfully.
Student.N Id Number Name Activity
o
1 ITR/1339/03 Mesfin Shifera In all activity
2 ITR/1515/03 Kalkidan Misganaw In all activity
3 ITR/1306/03 Aliheyder Jemal In all activity
4 ITR/1305/03 Adamu Girma In all activity
5 ITR/1355/03 Tigst Yimam In all activity
6 ITR/051/02 Teshome W/tensey In all activity

Table 1.3: Task Breakdown and Deliverables

14
1.12 Communication plan
We have time frame to meet the project objective. We will meet three times in week to discuss
and reach conclusion about the project work processes. In order to complete the project we have
the common meeting time below:
1.2:00-5:00 AM Saturday
2.2:00-5:00 AM Sunday
3. 1:00 – 6:00 PM Friday.

1.13 Feasibility of the project

Feasibility study is used to investigate the proposed system in multiple dimensions. It used
to indicate whether the system feasible or not. The proposed system can be seen according to the
following literals.

1.13.1 Technical feasibility

It is the process of accessing the developed system by the organization. Technical feasibility
is the measure of practicality of the specific technical solution and the availability of technical
resources and expertise. The proposed system can be easily maintained and repaired without
requiring high Experts or technical assistants, because the system was developed by familiar
programming language (environment).The project team members have learned programming
languages that required for the successful completion of the project such as java script, CSS,
HTML, PHP, MySQL. Team members have the required skill to develop the system, So that the
project can be said technically feasible.

1.13.2 Schedule Feasibility

Schedule feasibility is making sure whether the potential time frames and Completion date can
be met or not .The project team members expected the Project to be completed on time without
any delay.

1.13.3 Operational Feasibility

This system bring better achievement for the operations performed by the office by providing
efficient registration and storage of customers information, easy updating ,deletion, modification

15
etc. This intern increases the efficiency of work in the office. So that one can say that the system
is operationally feasible.

1.13.4 Legal Feasibility

The project team members built the system without violating rules and regulations of the
governments as well as the organization. The system being built is for the sake of productivity of
the organization, so that the project is legally feasible.

1.13.5 Economic Feasibility

Economic feasibility is the process of identifying the financial benefits and costs associated
with the project being developed.

1.14 Benefits and beneficiaries of the project

1.14.1 Benefits of the project

The main benefits of this system as it is computerized web based system:
 It reduces the customers accessing time to get service from the organization.
 It minimizes the customers losing time when they want to access service from the
organization.
 The main use of this new proposed system is it introduces the employee of the
organization as well the customers with today’s world technology.
 It provides timely information to their employees and also Process Customers request on
time.
 It can easily update customer’s record.
 It can generate appropriate reports automatically.
 It reduces waste file report(file cabinets)
 It increases performance of the organization
 Enhance employee morale of the organization by providing quality service.
 Improves the confidence of the system users.

16
1.14.2 Beneficiaries of the project
The first beneficiaries of this proposed system is the customers who have knowledge on how to
access information from the internet and those of employee of KWSSO. And the other user of
this system the organization by its own, everybody can join their organization simply and can
understand how they work, and understand what things they done in them. So, within a short
time it becomes more profitable and famous office across the world.
Beneficiaries of the Project:

System users’ beneficiary

 Save their time and Reduce work loads
 Reduce complexity
 Easily access customers’ information from organized database.
 Control customers records and reduce data redundancy
Group members Beneficiary:
 The project has initiated our team to get knowledge of how to develop the
required system application.
 While struggling with some difficulties, the team got a lot of experiences of
solving problems.

17
2. Business Area Analysis
In this chapter overview of the existing system, overview of the proposed system functional and non-
functional requirement of the system will be discussed and modeled using unified modeling
language(UML) models.

2.1 Description of current/ existing system

The main purpose of studying the existing system is to develop a new system which efficiently
performs activities than current one and understanding existing problems. To solve problems
document analysis, form designs, some constraints and rules of the existing system incorporated.
Kombolcha water supply service office (KWSSO) is a water supply office .it is using
Desktop application system. Registration of new customers and bill calculating using by this
system. But, the system can’t generate organized report, detail customer information can’t visible
to customer, when we see how the new customer joins the organization, it requires physical
present to the office. The report prepared by paper or manual. The organization vacancy
announcement submits by paper or on the board. The organization information only manually
present.

2.2 Problem identified and alternative solution

2.2.1 Problem of the existing system

 Most of time uses manual ways to achieve its vision and mission.
 Customers and employee are not satisfied.
 The management is not effective.
 It takes more time and effort.
 It is very difficult to memorize the exact shelf location and amount of data.
 Difficult for vacancy announcement,
 Difficult for getting feedbacks from the customer,
 Difficult for making comments to customer,
 Difficult for prepared organized report,

18
2.2.2 Alternative solution
After the team has identified the real problem of the existing system which is in a desktop
application system, the team suggests an alternative option to overcome the problem.

These alternative options are:-

Changing the desktop application system into web based environment.
Changing the desktop application system into a web based system that works on web
based environment.
Uses computerized and automated way to achieve its vision and mission.
There will be fair service that will tend for satisfaction.
The system is lucky to easily throw exact location and exact amount of data from the
database.
Most of the task will be done by the server side machine so no need of customer and
employee to be contact.
Customers can order request by browsing at their home or office. Because, the proposed
system is web based.
An effective and centered management will be applied.
The system can generate almost all related tasks in short period of time.
Can generate and store information’s to the database.
The team has analyzed all of the alternative options based on the ability of performance,
information flow and service to the users and efficiency. This analysis has enforced to select the
web based system

2.3 Option analysis and the proposed new system

The proposed system is very easy to operate and easily handle all the data and the work done by
the existing systems. Option analysis is means of evaluating the alternative solutions in terms of
their advantages and disadvantages.

Advantage of proposed system:

 The new system can be implemented without changing the organization policy.
 Loss costly and easy to install.

19
  The new system does not require more human labor.
 Processing data with high speed and short hand form.

 Data redundancy problem will be avoided with the proposed system.

 Is to reduce human errors by providing user-friendly input and output capabilities
and record keeping.

 Performance: The performance of the proposed system does provide fast response
time because it is easy to access data from the stored document.
 Throughput: the expected number of operation that can be performed in a unit
time. That minimizes the number of tasks that labeled to the employees.
 Efficiency: the web based customer service management system by itself is short
and clear and in this system there is no duplication of data through the new
system is powerful to manage things around web based customer service
management system.
 Service: the system can be visited by anybody who is a member of the
organization. The new system gives some activities when a user logged in the
system the system displays vacancy announcement for each users and displays
new posts.
 Economy: when we apply web based customer service management system there
will be areas in which cost will be reduced. Example as a result of a new system
the payment too many employees will be reduced. Reduce cost of paper.

Disadvantage of proposed system:

 Requires technical person to handle and manage the system.

 The new system needs to have internet connection

2.4 Overview of the proposed system

As previously mentioned in statement of the problem, there are a lot of problems associated
with the current system of the organization. The main aim of the proposed system is to
implement kombolcha town water supply service office web based customer service

20
 management system which allows easily register customer, maintenance order request, follow
announcement, and overcome to those problems.

2.5 Requirement definition

The project “WEB BASED CUSTOMER SERVICE MANAGEMENT SYSTM FOR
KOMBOLCHA WATER SUPPLY SERVIC OFFICE” aims at developing website for
KOMBOLCHA WATER SUPPLY SERVIC OFFICE (KWSSO) by using the internet based
application. The system focuses on registering customer’s request, producing report, maintenance
order request, producing different reports for manager online on the internet.

The main objective of the project is to enable the organization to facilitate its day to day activity
efficiently by using the modern technology. It minimizes the task load of the organization by
allowing them to delegate some part of tasks to the system. If this project successfully completed,
it will minimize wastage of hard copy materials like paper and record book. It will illuminate some
of the physical activities of the office such customers can see their payment online without having
physical contact with the employee. Customer can maintenance order request easily by online.

21
2.6 Essential use case modeling
Essential use case modeling is a simplified abstract, generalized use case that captures the
intentions of the user in a technology and implementation independent manner. It identifiers use
case and actors of the proposed system.

Essential use case diagram

Apply register
Record meter
Customer reading
Bill officer
Update
Customer

Delete
Customer
Record maintain
material
Customer Technical supervisor
Service expert Post vaccancy

Creat account View report

Administrator Manager

Figure 2.1: Essential use case diagram

22
2.6.1 Essential use case description
Use case name Apply register
Use case number UC1
Description The customer enables to select register link and fills the form and
submit to their record request to view by customer service expert.
Actor Customer
Pre-condition The customer must have internet connection.
Basic course of action Step 1. The customer wants to register by selecting register link.
(Flow of event): Step2. The system Displays the register form Page.
Step3.The customer fill the inputs his/her required status.
Step4. The customer click submit button.
Step5.The system displays the id no and information’s of the customer.
Step6. The use case ends.
Post-condition Submit the full fill records to the KWSSO data base
Alternate course of A: the filled Register information is invalid.
action: 1:Go to step 2 to fill register form again
Table 2.6.1: Apply register

Use case name Update customer

Use case number UC2
Description The customer service expert enables to select customer update link and
Update or modify the customer data and view the updated data.
Actor Customer service expert(CSE)
Pre-condition The CSE must login to the system by its own user name and password.
Basic course of Step 1. The CSE wants to update by selecting update customer link.
action (Flow of Step2. The system Displays the customer update form Page.
event): Step3.The CSE fill the inputs his/her required updated information.
Step4. The CSE click Update record button.
Step5.The system displays the updated customer information.
Step6. The use case ends.
Post-condition The CSE must be click update record button and logout from the CSE page.

23
Table 2.6.2: Update customer

Use case name Delete customer

Use case number UC3
Description The customer service expert enables to select customer Delete link and
delete the customer.
Actor Customer service expert(CSE)
Pre-condition The CSE must login to the system by its own user name and password.
Basic course of action Step 1. The CSE wants to delete by selecting delete customer link.
(Flow of event): Step2. The system Displays the customer delete form Page.
Step3. The CSE click delete link.
Step5.The system deleted customer information.
Step6. The use case ends.
Post-condition The CSE must be click delete on required delete customer and logout
from the CSE page.

Table 2.6.3: Delete customer

Use case name Post Vacancy

Use case number UC4
Description The Administrator enables to select post vacancy link and fills the form
and submit to their record information and to view by any users.
Actor Administrator
Pre-condition The Administrator must login to the system by its own user name and
password.
Basic course of action Step 1. The Administrator wants to post vacancy by selecting post
(Flow of event): vacancy link.
Step2. The system Displays the post vacancy form Page.
Step3.The Administrator fills the form.
Step4. The Administrator click submit button.
Step5.The system displays the vacancy for any users.
Step6. The use case ends.

24
Post-condition The Administrator must be click submit button and logout from the
administrator page.
Table 2.6.4: Post vacancy

Use case name Create account

Use case number UC5
Description Used to create account for users.
Actor Administrator
Pre-condition The user should be member of the KWSSO organization.
Basic course of action Step 1. The administrator selects create account link.
(Flow of event): Step2. The system displays create account page.
Step3. The administrator fills the required information and submits it.
Step4. The system validates the information.
Step5. The system registers the users into the system.
Step6. The use case ends.
Post-condition The account is successfully created.
Alternate course of A. Invalid information entry.
action: Go to step 2 to fill again.
Table 2.6.5: Create account

Use case name Record meter reading

Use case number UC6
Description The Bill officer enables to select record meter reading link and fills the
form and submit to their record information and view.
Actor Bill officer
Pre-condition The Bill officer must login to the system by its own user name and
password.
Basic course of action Step 1. The Bill officer wants to record meter reading by selecting
(Flow of event): record meter reading link.
Step2. The system Displays the record meter reading form Page.
Step3.The Bill officer fills the form.
Step4. The Bill officer click submit button.
Step5.The system displays the meter record for appropriate users.

25
 Step6. The use case ends.
Post-condition The Bill officer must be click submit button and logout from the
administrator page.
Table 2.6.6: record meter reading

Use case name Record maintain material

Use case number UC7
Description The Technical supervisor enables to select record maintain material
link and fills the form and submit to their record information and view.
Actor Technical supervisor (TSV)
Pre-condition The TSV must login to the system by its own user name and password.
Basic course of action Step 1. The Bill officer wants to record maintain material by selecting
(Flow of event): record maintain material link.
Step2. The system Displays the record maintain material form Page.
Step3.The TSV fills the form.
Step4. The TSV click submit button.
Step5.The system displays the maintain material for appropriate users.
Step6. The use case ends.
Post-condition The TSV must be click submit button and logout from the administrator
page.
Table 2.6.7: record maintain material

Use case name View report

Use case number UC8
Description The manager used to view report.
Actor Manager
Pre-condition The data should be submitted in KWSSO database.
Basic course of action Step 1. The manager selects view report link.
(Flow of event): Step2. The system displays the View report page.
Step3. The manager press alternative view icon.
Step4. The system displays their data to manager from KWSSO

26
 database.
Step6. The use case ends.
Post-condition The report is viewed by the manager.
Table 2.6.8: view report

2.7 System Requirements of the new system

The following are Functional and Nonfunctional requirements of the proposed new system that a
group member have identified from requirement use cases associated with each actor and use
case interactions.

2.7.1 Functional requirements

The functional requirement for the system describes the functionally or services that the system
is expected to provide. It is a system requirement that describes an activity or process that the
system must perform. The users first know how to use the system. The developed system is
expected to provide the following functionalities:

The proposed system will have authentication system for any level user like administrator
employee and other user’s indifferent way.
Enables users to view vacancy announcement.
Hold customers personal information.
Allow customer to apply register.
Displays new posted vacancy.
The proposed system will add data from different user of the system to the DB
Updates record as needed.
Approve new customer’s application: support the record of the new customer to the
database if the organization adds more customers.
Modify customer data: modify the database if there is any change in the customer file.
The proposed system will search the customer file from the database.
The proposed system will announce vacancy.

27
2.7.2 Non-Functional requirements
Many non-functional requirements relate to the system as a whole rather than individual
system features. Nonfunctional requirements are behavioral properties that the system must have.
The following lists of nonfunctional requirements are expected from the system:

Scalability: The system must be compatible with any environment.

Security: should allow login to only authorized users
Reusability: Ability of an item that allows it to be used repeatedly unlike a disposable
item.
Performance: this system gives service 24 hours per day with maximum response time
so, it is easy to access data from the stored document.
Accuracy: proposed system will be better due to reduction of error. All operation can be
done correctly and it ensures that whatever information is coming from the data base is
accurate.
Reliability: The reliability of the proposed system will be better due to proper storage of
information when users access the application.
No Redundancy: In the proposed system can be avoided reputation of data anywhere in
the database.
Availability: All data in the system will be available all the time.
Efficiency: The system must ensure allocation and use of services being requested for the
users by using minimum memory storage, cost, time and human power.
User friendly Interface: Users can easily input and retrieve their profile and history.
Error handling Exception: The system must recover immediately when a user enters
incorrect (error) data.

Efficient
o Searching a customer record should not take more time
o The system displays every window.
o The system should be user friendly.
o The system should operate as efficiently as possible.
Usability

28
o Usability is a term used to denote the ease with which people can employ a
particular tool or other human-made object in order to achieve a particular goal. In
this case our system possesses the following regarding to usability:
o Easier to learn—operation can be learned by observing the object
o More satisfying to use
Integrity
o Only authorized users of the system (administrator or manager) can able to
update, modify, delete or access data. Access is denied for unauthorized and
unauthenticated users of the system.
Maintenance
o The system should be easy to maintain and update.

29
3. Object oriented system Analysis

3.1 Introduction
The project development team used an object oriented system development methodology.
Because the Object system development approach gives easier way to break down problems into
simple and small components so that it reduces the vague appearance of the big problem. The
major activities covered in this chapter are constructing a use case model, documenting the use
case course of events, constructing sequence and activity diagrams and user prototype about the
proposed system.

3.2 Objective of system analysis

The new system changes the current working system and provide suitable graphical user
interface.

The main objectives of the system analysis are:

Filter the problem from the current working system

Find a solution for those potential problems.

To clarify the design and implementation phase.

It plays a major role in avoiding time wastage while designing.

It helps to see the internal functions of the current system and the new proposed system
clearly and completely.

3.3 System Requirement Specifications (SRS)

3.3.1 Use case diagram

Use Case represents interaction between the user and the system.
The following use cases have been identified from the system specification

Use case
Login

30
 Apply register
Maintain register
Payment register
Post vacancy
Delete vacancy
Update vacancy
Create account
Delete account
Update customer
Delete customer
Maintain order
Calculate cost of bill
Receive maintain
View report
Record meter reading
Post vacancy
Delete vacancy
Update Vacancy
The identified actors that will be participating in the system are:

Actors

Customer
Customer service expert
Technical supervisor
Administrator
Bill officer
Manager

31
 View
vacancy
Apply Calculate cost
register of bill
<<includes>> Record meter
<<includes>> Bill officer
reading
Maintain
Customer order <<includes>> Record
<<includes>>
payment
Delete
customer <<includes>> <<includes>> Receive
Login
maintain
<<includes>>
Update <<includes>>
Customer Service customer <<includes>> reject
Expert <<includes>> order
<<includes>> Technical supervisor
<<includes>> record
Delete material
account
<<includes>> View report
Creat
Administrator account
<<includes>>
Manager
Post
vacancy

Delete
Vacancy

32
Fig 3.3.1: UML Use case diagram

3.4 Use case documentation

The following consecutive tables show the use case documentation for each of the use cases
that has identified in the above use case diagram. Each table contains the use case name, the
actor which initiates and interacts with the use case, description of the use case and typical
course of events that show the interaction between the actor and the use case which enable the
team to easily depict the functions of the proposed system.

Use case documentation for Login

Use case name Login

Description It allows user to login into the system
Actor/s Administrator, Bill officer, customer service expert, Technical
supervisor, manager.
Pre-condition The users should have registered into the system
Post-condition The user will login in to the system and able to access the required home
page.
Basic course of action Step 1. Initiated when the user wants to login into the system
(Flow of event): Step2. The system Displays the User Login Page.
Step3.The user fill the inputs his/her user name and password.
Step4. The system verifies the username and password.
Step5.The system displays the appropriate home page.
Step6. The use case ends.

From the above steps Step 1 and step 3 Actors action whereas Step 2
Step 4, Step 5 and Step 6 System response

Alternate course of The username/password is invalid.

action: 1. The system displays error message.

33
 2. The system continues at step 2 to fill user name and password again.

Table 3.3.1: Use case documentation for Login

Use case documentation for Create account
Use case name Create Account
Description Used to create account for users.
Actor Administrator
Pre- condition: The user should be member of the KWSSO
Basic course of action (Flow Step1.The administrator wants to create account.
of event): Step2.The system displays create account page.
Step3.The administrator fills the required information and submits
it.
Step4.The system validates the information.
Step5.The system registers the users into the system.
Step6.The system displays confirm message.
Step7.The use case ends.

Post- condition The user account successfully created.

Alternative course of action Invalid information entry.
(Flow of event): 1. The system displays error message.
2. Go to step 2 to fill again.

Table 3.3.2: Use case documentation for Create Account

Use case documentation for Delete account
Use case name Delete Account
Description It Allows Administrator to delete User account
Actor Administrator
Pre-condition To delete the User account must be registered in the database.
Basic course of action Step1.The Administrator wants to delete account.

34
(Flow of event): Step2.The system displays the delete account page.
Step3. The Administrator press on delete button.
Step4.The system validates the information.
Step5.The account is deleted from the system.
Step6.The system displays confirm message.
Step7. The use case ends.

From the above steps Step 1 and step 3 Actors action whereas Step 2
Step 4, Step 5, Step 6 and Step 7 System response

Alternative course of If the selected account is invalid.

action: 1. The system displays error message.
2. Go to step2 to select the delete account again.

Table 3.3.3: Use case documentation for Delete Account

Use case documentation for Apply register
Use case name Apply register
Description It allows customer to register the DB, A customer requests registration by
using online application for KWSSO web page.
Actor Customer
Pre-condition The customer should have internet access and get the home page of
KWSSO.
Post- condition The customer can join the organization and access online service from the
office.
Basic course of Step1.Initiated when the Customer wants to register to the DB
action (Flow of Step2.Customer opens the home page and click apply register link.
event): Step3.The system displays the Customer register page.
Step4.Enter the correct & all necessary information.
Step5. Initiate the system to sends to the organization.

35
 Step6. The use case ends.
From the above steps Step 1,Step 2, and step 4 Actors action whereas
Step 3 Step 5 and Step 6 System response

Table 3.3.4: Use case documentation for Apply register

Use case documentation for Update customer
Use case name Update customer
Description It allows updating previously recorded customer data.
Actor Customer service expert
Pre-condition The customer must be registered & customer service expert login to the
system and the data of the customer should be ready.
Post- condition The customer service expert will have updated customer data.
Basic course of action Step1. Customer service expert open the home page.
(Flow of event): Step2. Customer service expert Enter login address on the login page.
Step3. The system check is the correct address or not.
Step4. Customer service expert enter customer ID of the intended
Customer.
Step5. The system validates the customer ID.
Step6. The system searches and display customer detail.
Step7. Customer service expert enter new modification.
Step8. System updates the information and displays it.
Step9. End use case.
From the above steps Step 1,Step 2, Step 4, and Step 7 Actors action
whereas Step 3, Step 5, Step 6, Step 8, and Step 9 System response

Table 3.3.5: Use case documentation for Update customer

36
Use case documentation for Delete customer
Use case name Delete customer
Description It allows to remove customer from KWSSO database.
Actor Customer service expert
Pre-condition The customer must be registered & customer service expert login to the
system.
Post- condition The customer service expert will have deleted customer or The
customer will be discarded from the system database.
Basic course of action Step1. Customer service expert open the home page.
(Flow of event): Step2. Customer service expert Enter login address on the login page.
Step3. The system check is the correct address or not.
Step4. Customer service expert enter customer ID of the intended
Customer.
Step5. The system validates the customer ID.
Step6. The system searches and display required customer.
Step7. The system deletes the customer.
Step8. End use case
From the above steps Step 1,Step 2, Step 4, and Step 7 Actors action
whereas Step 3, Step 5, Step 6, Step 7, and Step 8 System response

Table 3.3.6: Use case documentation for Delete customer

Use case documentation for Order maintenance

Use case name Order maintenance
Description It allow customer to order maintenance.
Actor Customer
Pre-condition The customer should register to the system or system DB.

37
Post- condition Maintenance order will be recorded to the system.
Basic course of action Step1. Customer open the homepage
(Flow of event): Step2. Customer selects maintenance order form from the home page.
Step3. The customer enters their ID.
Step4. System validates the customer ID.
Step5. The customer enters maintenance detail in the form.
Step6. The system responses transferred message to the customer.
Step7. End use case

From the above steps Step 1,Step 2, Step 3, and Step 5 Actors action
whereas Step 4, Step 6, and Step 7 System response

Table 3.3.7: Use case documentation for Order maintenance

Use case documentation for Receive maintenance
Use case name Receive maintenance
Description It allows receive and approve customer maintenance order process.
Actor Technical supervisor
Pre-condition The customer should order the maintenance.
Post- condition Customer maintenance order should be transferred and service being
delivered.
Basic course of action Step1.Technical supervisor open the homepage
(Flow of event): Step2. Technical supervisor insert the login address on the page.
Step3. System validates the address.
Step4. Technical supervisor checks and see the problem.
Step5. Technical supervisor take the order from the customer.
Step6. End use case

From the above steps Step 1,Step 2, Step 4 and Step 5 Actors action
whereas Step 3, and Step 6 System response

38
Table 3.3.8: Use case documentation for Receive maintenance

Use case documentation for View report

Use case name View Report
Description It allows viewing report from the experts.
Actor Manager
Pre-condition They should have prepared data by the employee of the organization.
Post- condition The manager sees the report prepared by the office employees.
Basic course of action Step1. The manager opens the home page.
(Flow of event): Step2. The manager Enter his/her user name and password.
Step3. System validates the address.
Step4. The manager View the prepared report.
Step5. End use case.
From the above steps Step 1,Step 2 and Step 4 Actors action
whereas Step 3, and Step 5 System response

Table 3.3.9: Use case documentation for View Report

Use case documentation for Calculate cost of Bill
Use case name Calculate cost of bill
Description The system calculates the cost of bill.
Actor Bill officer
Pre-condition The Bill officer should get the current water meter reading value of the
customer.
Post- condition The customer bill will be calculated.
Basic course of action Step1. Bill officer Open the homepage.
(Flow of event): Step2. Bill officer Enter user name and password.

39
 Step3. System validates it.
Step4. Bill officer Enter current water meter reading of the customer and
other important information.
Step5. Initiate the system to calculate the cost.
Step6. End use case

From the above steps Step 1,Step 2 and Step 4 Actors action whereas
Step 3, Step 5 and Step 6 System response

Table 3.3.10: Use case documentation for Calculate cost of Bill

Use case documentation for Record meter reading

Use case name Record meter reading
Description The bill officer reads water meter reading.
Actor Bill officer
Pre-condition Bill officer should have collected reading.
Post- condition The current meter reading of the customer will recorded.
Basic course of action Step1. Bill officer Open the homepage.
(Flow of event): Step2. Bill officer should collect water meter.
Step3. Bill officer Enter the address.
Step4. System validates the address.
Step5. System retrieves the customer ID & customer detail.
Step6. Bill officer Enter the current reading to the system.
Step7. End use case.
From the above steps Step 1,Step 2, Step 3 and Step 6 Actors action
whereas Step 4, Step 5 and Step 7 System response.

Table 3.3.11: Use case documentation for Record meter reading

40
Use case documentation for Post vacancy
Use case name Post vacancy
Description Administrator used to post vacancy.
Actor Administrator
Pre-condition Administrator first login to the system.
Post- condition Posted vacancy viewed by all users of the system
Basic course of action Step1. Administrator Open the homepage.
(Flow of event): Step2.Administrator login to the system.
Step3. Administrator click on post vacancy link.
Step4. Administrator fills the post vacancy form.
Step5. Administrator click submit button.
Step6. End use case.

Table 3.3.12: Use case documentation for Post vacancy

Use case documentation for Delete Vacancy

Use case name Delete Vacancy
Description It allows removing post vacancy from KWSSO database.
Actor Administrator
Pre-condition The Vacancy must be registered into DB & Administrator login to the
system.
Post- condition The Administrator will have deleted vacancy or The posted vacancy
will be discarded from the system database.
Basic course of action Step1. Administrator opens the home page.
(Flow of event): Step2. Administrator Enter login address on the login page.
Step3. The system check is the correct address or not.
Step4. Administrator click delete vacancy link.
Step5. The system deletes the vacancy.
Step6. End use case

Table 3.3.13: Use case documentation for Delete post vacancy

41
Use case documentation for record maintain material
Use case name Record material
Description It allows material to register the database.
Actor Technical supervisor.
Pre-condition Technical supervisor first login using its own username and password
Post- condition Technical supervisor register the material into KWSSO database
Basic course of Step1. Technical supervisor open the home page.
action (Flow of Step2. Technical supervisor enter its own username and password to login.
event): Step3. Technical supervisor click the record material link.
Step4.Enter the correct & all necessary information.
Step5. Initiate the system to sends to the organization.
Step6. The use case ends.
Table 3.3.14: Use case documentation for record maintain material

3.5 Sequence diagram

A sequence diagram in a unified modeling language (UML) is a kind of interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence

42
 Apply register

Customer Customer register Customer register Customer register KWSSO

<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Wants to
register

Create
Display

Customer
enter detail
information

Validate

If invalid

If valid

successfully Validate
register

Fig 3.5.1: UML Sequence diagram for Customer Apply Register

43
 Clculating bill

Bill officer Calculate Bill Home page Bill calcu page Is valid KWSSO
Bill
<<actor>> <<controller>> <<UI>> <<UI>> :account <<DB>>

Wishis to
calculate

goto home
page

Enter address

Is valid
Valid?
Validate
If invalid

If valid

Calculate()

sucss & succes

print

Fig 3.5.2: UML Sequence diagram for Calculating Bill

44
 View report

Manager View report View report Report page KWSSO

<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Want to view
Create

Display

Fill and press

view

validate

If invalid

If valid

The report is confirmation

viwed

Fig 3.5.3: UML Sequence diagram for View Report

45
 Update customer

Customer service expert Update customer Update customer Update customer KWSSO
<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Want to
update custom

Create
Display

Modify and
update

validate

If invalid

If valid

Successfully Confirmation
updated

Fig 3.5.4: UML Sequence diagram for Update Customer

46
 Order maintenance

Customer Order maintain Order maintain Order maintain KWSSO

<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Wishis to
order maintain

Create

Display

Fill and submit

validate

If invalid

If valid

confirmation
Success

Fig 3.5.5: UML Sequence diagram for Order Maintenance

47
 Delete customer

Customer service expert Delete customer Delete customer Delete customer KWSSO
<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Wants to
delete

Creates

Display

Delete
customer

validate

If invalid

If valid

Successfully confirmation
deleted

Fig 3.5.6: UML Sequence diagram for Delete customer

48
 Receive maintain

Technical supervisor Receive maintain Receive maintain Receive maintain KWSSO

Customer Maintain
<<actor>> <<link>> <<controller>> <<UI>> <<DB>>
Wants to
receive

Create

Display

Receive
maintain

validate
If invalid

Cheack ()
Customer

If valid

Receive Confirmation
maintain
Take maintain
order

Fig 3.5.7: UML Sequence diagram for Receive Maintenance

49
 Create account

Administrator Create account Create account Create account KWSSO

<<actor>> <<link>> <<conroller>> <<UI>> <<DB>>

Wants to
create

Create
Display

Validate

If invalid

If valid

Confirmation
Success

Fig 3.5.8: UML Sequence diagram for Create account

50
 Delete account

Administrator Delete account Delete account Delete account KWSSO

<<actor>> <<link>> <<conroller>> <<UI>> <<DB>>

Wants to
delete

Create
Display

Delete accoun

Validate

If invalid

If valid

Confirmation
Success

Fig 3.5.9: UML Sequence diagram for Delete account

51
 Login

User Login Login Login KWSSO

Main page
<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Wants to
Login

Display

Display

Validate

If invalid

If valid

If not
authonticated
If
authonticated

Confirmation
Success

Fig 3.5.10: UML Sequence diagram for Login

52
 Water record

Bill officer Record water meter Record water meter Record water meter KWSSO
<<actor>> <<link>> <<controller>> <<UI>> <<DB>>

Wants to
record

create

create

Validate

If invalid

If valid

Confirmation
Success
insert record

Fig 3.5.11: UML Sequence diagram for water record

53
 3.6 Activity diagram
An Activity diagram is similar to a flowchart to represent the flow from one activity to another
activity. Activity diagrams and State chart diagrams are related. While a State chart diagram
focuses attention on an object undergoing a process (or on a process as an object), an Activity
diagram focuses on the flow of activities involved in a single process. The Activity diagram
shows how these single-process activities depend on one another.
Activity diagrams model is a high level business or processes or transitions between states of
a class. In this activity diagram tried to document the flow of logic for the major business
processes.

Apply re giste r

Custome r open home page

Click apply regis ter link

Ente r all ne ce ssary information

Click register button

Fig 3.6.1: UML activity diagram for Apply Register

54
 Login Administrative staff

Employee of the office open the home page

Employee select login alternative

Employee Enter uname and pwd

Invalid
Display error message

valid

User login to the system

Fig 3.6.2: UML activity diagram for Login administrative staffs

55
 View report

The manager open the homepage

Manager select its own login alternative

The manager enter the login address

Invalid
Display Error message

valid

View the prepared report

Fig 3.6.3: UML activity diagram for View report

56
 Record meter reading

Bill officer should collect water meter

The bill officer open the homepage

Bill officer select its own login alternative

invalid
Display Error message

Valid

System retrives the customer ID and customer detail

Bill officer see and put the curent reading

Fig 3.6.4: UML activity diagram for Record meter reading

57
 Calculating bill

Bill officer Login to the system

Bill officer select its own login alternative

Invalid
Display Error message

Valid

Enter current water meter Enter necessary information

reading of the customer

System calculates Bill

Fig 3.6.5: UML activity diagram for Calculate cost of bill

58
 Receive maintenance

Technical supervisor Enter the address on the page

Incorrect Address Errer message

Correct address

Technical supervisor Enter the customer

ID

Incorrect ID

Correct ID

System display the customer detail and their order

Technical supervisor see the problem and receive it

Fig 3.6.6: UML activity diagram for Receive maintenance

59
 Order maintenance

Customer selects maintenance order form

The Customer Enters ID

Incorrect ID

Correct ID

The Customer Enters maintenance detail in the form

System respond success message to the customer

Fig 3.6.7: UML activity diagram for Order maintenance

60
 Create account

Select create account link

Fills the information and submit

Not Valid
Display Error message

Valid

The account is created

Fig 3.6.8: UML activity diagram for Create account

61
Delete account

Select the user wants to delete

Display delete account page

Select the type wants to delete

Fills the information and press button

Not Valid
Display Error message

Valid

Display the delete account

Press delete button

The account is deleted from the DB

Fig 3.6.9: UML activity diagram for Delete account

62
 Delete customer

Customer service expert Login to the customer service page

Incorrect

Correct

Customer service expert Enters customer ID want to delete

Incorrect

Correct

Delete Customer

Fig 3.6.10: UML activity diagram for Delete customer

63
 Update customer

Customer service expert Login to the customer service page

Incorrect

Correct

Customer must be registered

Customer service expert Enter customer ID of the intended customer

Incorrect ID

Correct ID

Customer service expert Enter new modification

Fig 3.6.11: UML activity diagram for Update customer

64
 Post vacancy

Administrator open home page

Administrator login to the system select its

login alternative

Invalid

Valid

Click post vacancy link

Fills the form and submit the

vacancy

Fig 3.6.12: UML activity diagram for post vacancy

65
 3.7 User interface prototype
User interface prototyping is an iterative development technique in which users are actively
involved in the mocking-up of the UI for a system.

Home page

Login

Customer Techinical
Administrator Manager Bill officer Customer
service expert supervisor

Home Home Home Home Home Home

Create View Delete Receive

Record meter Apply
account report customer maintain
reading register

Delete Update Record

account customer Material Calculate Maintain
cost of Bill order
View
Post Vaccancy
Vacancy
view View
Payment Payment
Delete
Vacancy
View View
Update Vaccancy Vaccancy
vacancy

Fig 3.7.1: User interface prototype

66
4. System Design

4.1 Introduction
This chapter mainly concerned with the design part of customer service management system. In
order to make the implementation easy the design is very important.

In this chapter we will see the different type of class type architecture such as user interface
layer, process/control layer, business/domain layer, persistence layer and system layer and also
different types of system modeling techniques that are used for the implementation of the system
such as class modeling, state chart modeling and also some system design techniques such as
user interface design are also to be covered in this chapter.

Generally this chapter is describes how the project is designed, what tasks done under this
project.

4.2 Class Type Architecture

Class type architecture provides a strategy for layering the classes of the system to distribute
the functionality of the software among classes. Furthermore, class type architectures provide
guidance as to what other types of classes a given type of class will interact with, and how that
interaction will occur. This increases the extensibility, maintainability, and portability of the
systems.

Interface This layer wraps access to the logic of our system. This layer consists of interface

Class – user interface (UI) classes that provide people access to our system.

Domain- This layer implements the concepts pertinent to our business domain, focusing on the
data aspects of the business objects, plus behaviors specific to individual objects.

Process- The process layer implements business logic that involves collaborating with several
domain classes or even other process classes.

Persistence- Persistence layers encapsulate the capability to store, retrieve, and delete
objects/data permanently without revealing details of the underlying storage technology.

67
System- System classes provide operating-system-specific functionality for your applications,
isolating your software from the operating system (OS) by wrapping OS-specific features,
increasing the portability of your application.

Interface
(User interface,System interface)

Process
(Application,controller)

Domain System
(Infrastructure,Platform)
(Business)

Persistence
(Data)

Data source

KWSSO

Figure 4.2.1: Class type architecture

68
4.3 Class modeling
Class diagrams in the Unified Modeling Language (UML) is a type of static structure diagram
that describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among the classes. The class diagram with its
corresponding objects will be present in the following diagram.

Customer
- First_name: varchar Manager
- Last_name: varchar CSE
- Request:varchar - First_name: varchar
- Last_name: varchar - First_name: varchar
- Email: varchar
- Email: varchar 1 - Last_name: varchar
- Customer_Id :varchar
- Password :varchar - Email: varchar
- Telephone:int *
- User_name:varchar - Password :varchar
- Catagory:varchar
- User_name:varchar
+ Maintainance Order() + View report() *
+ Apply Register() + view Payment() 1 + Delete Customer()
+ View Payment() 1
+ View Vaccancy() + Update customer()
+ View Vaccancy() + Login() + View Payment()
+ Login()
* 1 1
* 1
Vaccancy
Administrator
- Qualification: varchar
1 - work Experiance: varchar 1 - First_name: varchar
- Required_no: varchar - Last_name: varchar
1
- Place of work :varchar - Pass word: varchar
1 - Departement:varchar 1 - User_name: varchar 1
- Date of application:varchar - Email: varchar
* *
+Create Account()
Bill Officer +Delete Account()
+Update Account()
- First_name: varchar *
1 +Post Vaccancy()
- Last_name: varchar +Delete Vaccancy()
- Email: varchar TSV 1
+ Login()
- Password :varchar - First_name: varchar
- User_name:varchar - Last_name: varchar
1
- Email: varchar
+ Register meter reading() - Password :varchar
+ Delete meter reading() - User_name:varchar
+ Update meter reading()
+ View meter reading() + Receive maintain()
+ Genereating Bill() + Reject order()
+ View Vaccancy() + Register material()
+ Login() + Delete material()
+ Update material()
+ View Vaccancy()
+ Login()

Fig 4.3.1: Class diagram

69
4.4 State chart modeling
The state chart diagram is shows the change of an object through time from one state to the
other state. State chart modeling is used to show the sequence of states that an object goes
through, the events that cause the transition from one state to the other and the actions that result
from a state change. The following figure shows the state of the objects.

Intermediate Transition
Initialization state
State object

Idle Login event

Fill user name
and password

Confirmation Order
Cancel
Action
Initial
object
Check the validate
of Input

Finish
Display the
required page

Fig 4.4.1: State chart diagram for login

70
 Transition

Initialization State object Intermediate state

Idle Record
Fill the form
payment

Confirmation Order
Cancel
Action
Initial
object

Check the validate

of Input

Finish
Record payment into
DB and view

Fig 4.4.2: State chart diagram for record payment

71
 Initialization Transition
State object Intermediate state

Idle Record meter

Fill the form
reading event

Confirmation Order
Cancel
Action
Initial
object
Check the validate
of Input

Finish
Register meter reading
and view the record

Fig 4.4.3: State chart diagram for record meter

reading

72
 Intermediate Transition
Initializati state
on State object

Idle Material
Fill the form
register event

Confirmation Order
Cancel
Action
Initial
object
Check the validate
of Input

Finish
Register the
material and view

Fig 4.4.4: State chart diagram for Material register

73
 Transition
Intermediate state
Initialization
State object

Idle Customer
Fill the form
register event

Confirmation Order
Cancel
Action
Initial
object
Check the validate
of Input

Finish
Register customer, View
the customer ID and
detail information

Fig 4.4.5: State chart diagram for Customer register

74
 Transition
Intermediate state
Initialization State object

Idle View report

Fill user name
and password

Confirmation Order
Cancel
Action
Initial
object
Check the validate
of Input

Finish
View the report

Fig 4.4.6: State chart diagram for view report

75
 Intermediate state Transition
Initialization State object

Idle Post vacancy

Fill the form
event

Confirmation Order
Cancel
Action
Initial
object
Check the validate
of Input

Finish
Post and view
Vacancy

Fig 4.4.7: State chart diagram for post vacancy

76
 Transition
Initialization Intermediate state
State object

Idle Create Fill the form

account
event

Action Confirmation Order

Cancel

Initial
object

Check the validate

of Input

Finish

View created
account

Fig 4.4.8: State chart diagram for create account

77
4.5 Component Modeling
Component diagrams show how the physical components of a system are organized. And also
shows which component or objects will be accessed by whom and what type of security
infrastructures it is using. The diagram is simulated below.

Register Maintain
Material

TSV
View Vaccancy

Customer
Apply register

Security
Post Vaccancy
Administrator Login

Delete customer

CSE Persistence

Update
Customer

Payment record
Bill Officer
KWSSO
<<Database>>
View Report
Manager

Fig 4.5.1: Component Modeling

78
4.6 Deployment modeling
Deployment modeling is used to show the hardware of the system, the software that is installed
in the hardware and also shows how the software and the hardware components work together.

Users Computers Web Server Application Database server

PHP MYSQL
Web
Create
browsers
Account
Xampp
KWSSO
Database

Post
Vaccancy

Mozila
Firefox

Generate
bill

Payment
record

Fig 4.6.1: deployment Modeling

79
 4.7 User Interface design
User interface design is the overall process of designing how a user will be able to interact with
a system.
The goal of user interface design is to make the user's interaction as simple and efficient as
possible, in terms of accomplishing user goals.

WelCome To Customer Service Managenment System For Kombolcha

Water Supply Service Office
Home Users Information Feedback Customer About Us Contact As Login

Copy right @20014 Customer service managenment System

Home page

80
 Login Form Select Alternative
User Name

Password

Login Reset

Create Account Form Select Alternative

First Name:

Last Name:

Email:

Password:

Re_EnterPassword:

User Name:

Save New

81
 Customer Register Form
Date:

First Name:

Last Name:

Email:

Request:

Telephone:

Category:

House No:

Kebele:

City:

Meter Size:

Save New

Delete & Update Account Form

Record_no Actio First Last Email passwor Reenter User
n name name d password name
Update Delete

82
 Search Customer Availability

Submit
Enter Customer ID

Delete & Update Customer Form

Custom Action Dat First Last Email Requ Phon Categor House Kebele Cit Meter
er ID e name name est e y No y size
Update Delete

Register Maintain Material Form

Material Name:

Material Price:

Material Size:

Material Photo:

Status:

Save Reset

83
 Delete & Update Maintain Material
Material ID Action Material Name Material Price Material Size Material Photo Status
Update Delete

Search Maintain Availability

Enter Material ID Submit

Search Payment of Customer

Enter Customer ID Submit

84
 Payment Register Form
Customer ID:

First Name:

Last Name:

Category:

Date:

Meter Size:

Previous record:

Current record:

Difference:

Payment: Birr:

Cent:

Save Reset

85
 Delete & Update Payment
Customer Action First Last Category Date Meter Previous Current Difference Payment
ID Name Name size Record Record
Update Delete

Post Vacancy Form

No:

Qualification:

Work Experience:

Required No:

Place of work:

Department:

Date of Application:

Save Reset

86
 Delete & Update Vacancy
Record Action No Qualificati Experience Required Place Departme Date of Detail
No on nt Application
Update Delete

87
88