DIRE DAWA INISTITUTE OF TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

TITLE:

ONLINE WATER BILLING SYSTEM FOR DIRE DAWA WATER

SUPPLY AUTHORITY

Name ID

1. ----------------------------R/0091/07

August 2019

Dire Dawa, Ethiopia

i
 DIRE DAWA INISTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

ONLINE WATER BILLING SYSTEM FOR DIRE DAWA WATER

SUPPLY AUTHORITY

PREPARED BY:

A Project submitted to Dire Dawa University in partial fulfillment of the

requirement for the Degree of Bachelor of Computer Science

ii
 August 2019

iii
ABREVATION DESCRIPTION

BCA Basic Course of Action

SWSSO shashamane water supply service office
CRC Class Responsibility Collaboration
GUI Graphical User Interface
HTML Hypertext Markup Language
HTTPS Hyper Text Transfer Protocol Security
ID Identification
MYSQL My Structured Query Language
LAN Local Area Network
PHP Hypertext Pre processor
UC Use Case
UML Unified modeling language
SDLC Software development life cycle
SQL Structured query language

Table of Contents
Chapter One...............................................................................................................................................1

1. Introduction.......................................................................................................................................1
1.1. Background of the organization................................................................................................1
1.2. Background of the project.........................................................................................................1

iv
 1.3. Statement of the problem..........................................................................................................1
1.4. Objective of the project.............................................................................................................2
1.4.1. General objective...............................................................................................................2
1.4.2. Specific objective................................................................................................................2
1.5. Scope of the project....................................................................................................................3
1.6. Limitation of the Project...........................................................................................................3
1.7. Significance of the Project.........................................................................................................4
1.8. Beneficiaries of the Project........................................................................................................4
1.9. Methodology...............................................................................................................................5
1.9.1 Data Gathering Methodology...................................................................................................5
1.9.2 System analysis and Design methodology...............................................................................5
1.9.3 Development approach.............................................................................................................6
1.9.4 Development tool.....................................................................................................................7
1.10 Testing methodology....................................................................................................................9
1.11 Feasibility Study...........................................................................................................................10
1.11.1 Technical Feasibility.............................................................................................................10
1.11.2 Operational Feasibility.........................................................................................................10
1.11.3 Economic Feasibility.............................................................................................................10
1.11.4 Schedule Feasibility..............................................................................................................11
1.12. Project Plans...............................................................................................................................11
1.12.1. Project Time Schedule.........................................................................................................11
1.12.2 Project Cost...........................................................................................................................12
1.12.3 Budget Plan...........................................................................................................................12
Chapter Two............................................................................................................................................13
Requirement Elicitation..........................................................................................................................13
2.1. Overview of the Existing System.............................................................................................13
2.2. Advantages of the existing system...........................................................................................15
2.3. Drawback of existing system...................................................................................................15
2.3.1. Performance Related problem:.......................................................................................16
2.3.2. Information related problem...........................................................................................16
2.3.3. Efficiency related problem..............................................................................................16
2.3.4. Control related problem..................................................................................................16
2.3.5. Economic related problem...............................................................................................16
2.3.6. Service related problem...................................................................................................17

v
 2.4. Proposed Solutions...................................................................................................................17
2.5. Preferred solution....................................................................................................................18
2.6. Domain Modeling With Class Responsibility Collaborator (CRC) Card............................18
2.7. Essential Use Case Diagram....................................................................................................20
2.8. Essential use case documentation.......................................................................................22
2.9. Essential User Interface Prototype.......................................................................................25
CHAPTER THREE.................................................................................................................................27
SYSTEM ANALYSIS..............................................................................................................................27
3.1. Introduction...............................................................................................................................27
3.2. Over view of the new system...................................................................................................27
3.3. System requirements...............................................................................................................27
3.3.1. Functional requirements.................................................................................................27
3.3.2. Non-functional requirements..........................................................................................28
3.4. System modeling......................................................................................................................31
3.4.1. System use case diagram.................................................................................................31
3.4.2. Use Case Documentation.................................................................................................36
3.4.3. Sequence Diagram............................................................................................................44
Figure 12 UML Sequence diagram for Delete customer....................................................................53
3.4.4. Activity diagram...............................................................................................................53
3.4.5. Class diagram...................................................................................................................62
CHAPTER FOUR...................................................................................................................................64
SYSTEM DESIGN..................................................................................................................................64
4.1. Design Goals..................................................................................................................................64
4.2. System Architecture.....................................................................................................................65
4.3. User Interface Prototype..............................................................................................................66
4.4. Sub System decomposition...........................................................................................................67
4.5. Hardware/Software Mapping......................................................................................................68
4.6. State chart diagram......................................................................................................................68
4.7. Collaboration diagram.................................................................................................................70
4.8. Component diagram.....................................................................................................................72
4.9. Deployment diagram....................................................................................................................73
4.10. Persistence Data management...................................................................................................74
4.11 User interface design...................................................................................................................78
Chapter Five............................................................................................................................................80

vi
Conclusion and Recommendation..........................................................................................................80
5.1. Conclusion.....................................................................................................................................80
5.2. Recommendation..........................................................................................................................80
Reference..................................................................................................................................................81

vii
 Chapter One

1. Introduction
As we know, today our world is under the control of technology because of this reason the
world is 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 shashamane water supply service
office (SWSSO) into web based system using today’s technology. SWSSO has many activities.
Such as, Customer registration, calculating bill based on their customer information and the
likes. Because every activity is performed in a single computer so, we 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.

1.1. Background of the organization

Shashamane water supply service office is a water supply organization which is located in
Shashamane town. The organization is established in 1986 E.C as part of the town
administration. At that time, the office had only 15 employees’ water chemist, motor operator,
meter reading expert, and two security bodies. Shashamane town water supply service follows
manual system to give service for their customer. In 1990 E.C the office had only 800 customers,
which are registered to get the service. But, in 1991 the organization builds its own office by
40,000 birr and become independent organizational office with 40 employees under the
workplace and 2000 customers. SWSSO uses a desktop application to perform any activity.
Therefore, in case of its desktop application the organization was faced with problems of
workload, so customers can not get a quick access. To solve such problems, we are going to
develop web based water billing &customer management system for (SWSSO).

1
 1.2. Background of the project
The project title is online billing system for shashamane city. This project is proposed to improve the
load of existing manual system by automation or computerization. As there are many problems face
human being throughout his/her life it is obvious to solve many of the problems using computers.
When saying this as the computer is the modern technology problem solver any one can solve his/her
problem by developing the software for the problem.

The proposal we have prepared is also the precondition for solving the main problems of online
billing system was implemented manually. Therefore, this work that manually performed needs to be
automated or computerized to reduce the problems that happened. This proposal includes the profile
of the office, the problems in the office, our objective, scope of the project and feasibility studies are
clearly specified.
Online water billing system is the billing system which uses self-service technology as a base of
website helping the user to pay monthly bill themselves. Online water billing system provides an
ease in the pay bill procedure where there should not be any error in transaction like calculation and
human error, bill generation and other things. It keeps of records of all bills also the information of
the customer. Give to ensure a reliable and successful implementation of online water billing system.
The billing system for shashamane city process of billing is disappointing many customers. For some
branch it even takes more than two months to get the printed bill from the print house and to deliver
it to customers. In some other kebele electronic bill presentation and payment is used. Therefore, it
actually minimized the time of bill delivery. However, because the charging days are limited, still
water billing offices are very crowded every end the month.

1.3. Statement of the problem

There is already a computerized system in SWSSO which is a standalone desktop application. In the
system every activity is performed on a single desktop. SWSSO has many activities. Such as: -
Registration of customer, Bill calculates, meter reading, Bill print, register materials and there is a
line transfer. But since it is desktop application there is a great workload on the organization,
customer wastes their time and money. Since the system is installed in single computer customers do
not get quick access, materials do not distribute fairly and also there may be a great fault due to
workload. Another key problem of WWSSO is if a customer had no enough balance on his hand
he/she needs to go home and get more money because there is no way of checking mechanism before
going to office to pay the water billing. Therefore, such problems are present currently from this we

1
try to change the desktop application system into web based system using today’s technology. Then
by using web-based system every activities of the existing system will provide a quick access
Shashamane water supply and sewerage authority gives water service for the shashamane city
society. And also it has an authority of collecting service charge but the way of collecting this
payment is not adequate for the customers. Shashamane water supply and sewerage authority has a
number of offices in different branches in the city that collect monthly payment for fixed line and
postpaid water billing.
And it is difficult to collect the money in one place, so it has a lot of office which give this payment
collecting service to the customers. Opening these offices in different kebele is costly and also needs
huge human capital that needs a monthly payment. Generating and delivering the bills for the
specific service is also problem of this company.
Customers are not satisfied on service delivery processes and customer complaint handling procedure
of Shashamane water supply and sewerage authority. On the current time, customers are tired of
keeping track of paying their monthly bills and running to the nearest drop box or payment center.
This kills their time (they will wait a lot of minutes in the different offices) and costs them much for
transportation. Customers are also facing late payment charge as a result of problem with notifying
due date of payment.

1.4. Objective of the project

The objective of our project can be divided in to general and specific

1.4.1. General objective

The general objective of the project is to develop online water billing system for shashamane water
supply authority

1.4.2. Specific objective

On the way of attaining the general objective, the project specifically attempts to achieve the
following.
F Analyze the existing system
F To give fast and accurate access for customers
F To design Web based Application for customers
F To Avoid Workload
F System analysis and object design
F Requirement analysis of the system
F Collecting data about the organization
2
 F Identifying the problem under the existing system
F Specify functional and nonfunctional requirements
F Test and implementation system
F Deploy the implemented system
F Giving training about the developed system.

1.5. Scope of the project

As the project title indicates water billing and customer management web application and other
related services for customers are: -

F Customer registration and retrieval

F On the registration of the maintain material.
F On the registration of meter reading.
F On the registration of the payment.
F Generate Report.
F Bill calculation and printing.
Scope out: -Online payment: - customers cannot process their payment at their home. Because the
way of processing online payment is not handle scope.

1.6. Limitation of the Project

There are many factors that limited us to minimize our scope, such as time limitation, resource,
place, and complexity of the system. In general our proposed system is limited to perform the
following tasks because of the above mentioned factors.

Even though customers can check how much they pay in each month from home they cannot process
payment from home since we do not include online payments It is also does not include HRM and
Other tasks within the organization due to limitation of: - Lack of materials: There is no enough
computer access with internet and lack of books and references used to show how projects 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. Lack of
money: AS we are students it is difficult to spend much amount of money on the project, so it will
limit the effectiveness of the project.

3
 1.7. Significance of the Project
The main Significance of this system as it is computerized web based system reduces the customers
accessing time to get service from the organization.

F It minimizes the customers losing time when they want to access service from the
organization.
F It provides timely information to their employees and also Process Customers request on
time.
F It can easily update customer’s record.
F It can generate appropriate reports automatically.
F Reduce material loss
F It increases performance of the organization
F Enhance employee morale of the organization by providing quality service.
F Improves the confidence of the system users.

1.8. 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 SWSSO. 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:

For the organization: -

F Save their time and Reduce work loads

F Reduce complexity
F Easily access customers’ information from organized database.
F Control customer’s records and reduce data redundancy for the Customer:
F It provides quick access

For the project developer team.

F The project has initiated our team to get knowledge of how to develop the required system
application.

4
 F While struggling with some difficulties, the team got a lot of experiences of solving
problems.

1.9. Methodology
1.9.1 Data Gathering Methodology
We will use the following methods to collect relevant data required to our project.

Interview: - As an interview, we have contacted the manager of that organization and then exchanged
some ideas of this system how it have been working and the structure of this organization have in its
implementation also the aim of they have to change the current or manual system to an online
system. As a general, we gathered so many data in order to prepare our project by interviewing them.
we will gather necessary information about the background of the Shashamane water supply and
sewerage authority organization, their works activities and the function of their existing system using
some structured (when did the Shashamane water supply and sewerage authority was established,
how does the existing system function, how many customers get services per day, how many
employers are there etc.) and unstructured interview questions from management and workers.

F Observation: We will also arrive to the organization in Shashamane water supply and
sewerage authority and observe how workers carrying out their work activities in a natural
setting. Observation will allows us to collect data in real time where activities are being
performed.
F Document analysis: - we will also collect certain relevant information from written
documents in the Office. Not only that but also we will tried to review other relevant
documents to develop our project.
F Brainstorming:-we will use our previous experience on the developing of other systems,
thinking and reasoning of real world problems.
1.9.2 System analysis and Design methodology
During the 1970s and 80s, the primary methodology to do these was structured programming.
However, structured programming approach has limitations:

F It is difficult to reuse work done for other projects. By starting with a particular problem and
subdividing it into pieces, the program design tends to produce a design that is unique to that
problem. Adapting a piece of programming from another project usually involves a lot of
effort and time.

5
 F The solution of some problems cannot be expressed easily in a particular sequence of
instructions. When the order in which instructions are to be executed cannot be determined
easily, a different approach is required.
Object-Oriented programming (OOP) is an approach to designing modular reusable software
systems. A module is a component of a larger system that interacts with the rest of the system in a
simple and well-defined manner. The object-oriented approach is a logical extension of structured
programming. The central concept of OOP is the object, which is a kind of module containing data
and subroutines. An object is a kind of self-sufficient entity that has an internal state (the data it
contains) and that can respond to messages (calls to its subroutines).

Object-Oriented programming (OOP) is a collection of objects, each with its own data and its own
set of responsibilities. The objects interact by sending messages to each other. Object-Oriented
programming (OOP) produces solutions that are:

F Easier to write
F These techniques have a reusability feature.
F These techniques provide greater opportunities for users to participate in the
development process.
F This increases flexibility.
F This also improved quality.
F These techniques are latest, powerful, easy and highly in use by now.
F Increase domain and design reuse.
F Easier to understand
F Contain fewer errors
F Reduction of development time
F Reduction of time and resources required to maintain existing systems
F Increase code reuse
1.9.3 Development approach
A software development approach helps us to structure, plan and control the process of
developing software. There are several software methodologies that can be used in developing
software.
1. Waterfall model
2. Prototyping model
3. Spiral model
4. Iterative model and others.
6
 By comparing the above methodologies our group selects ‘Iterative model’ because this model
are the following advantage
F Generates working software quickly and early during the software life cycle.
F This model is more flexible – less costly to change scope and requirements.
F It is easier to test and debug during a smaller iteration.
F In this model customer can respond to each built.
F Lowers initial delivery cost.
F Easier to manage risk because risky pieces are identified and handled during it’d iteration.

1.9.4 Development tool

To develop this project some hardware and software tools will needed.
1.9.4.1 Hardware
Name of hardware Use
Desktop Computer or To perform any tasks
Laptop with (RAM
According to [7] a web server that is capable of serving
4.00GB,Storage space
300GB – 500GB , more than 1000 users should have the following
Processor 2.67GHz)
specifications
Printer To print out the end report of the project
CD For backup the data.
Flash disk 16GB and Store and transfer file
Hard disk 1TB

Table 1: Hardware tools

1.9.4.2. Software
To develop our system we will use the following software tools:-

Software Use
Front end Software Programming Language: PHP, Coding purpose Why PHP?
HTML, JS, CSS
According to [8], there are
several types of web
programming language that are
used for making a site more
dynamic. But, for this project
chooses PHP scripting language
to design this database. Because
It’s fast and easy
It’s cross platform
7
 It accesses everything
It’s free
Back end Software My SQL Database Store data in an organized form
Why MySQL?
According to [9], there are
several reasons to use MySQL.
It’s quick and powerful
It’s improving all the time
It’s free
Handles large database. MySQL
with some database that contains
50,000,000 records and users
MySQL with 60,000 tables and
about 5,000,000,000 rows. All
columns have default values.
You can use insert a subset of a
table’s columns; those columns
that are not explicitly given
values are set to their default
value.
Wamp Server Package contain PHP and
MYSQL database for storing
data
Windows7, 8.1 and 10 Operating General purpose of computer
System
Microsoft Word Writing the document
Notepad For writing PHP and HTML
code
Browser (Chrome, Mozilla To running and testing our PHP
Firefox 43.0 and Internet and HTML code
Explorer)
E-draw max and Visio 2013 To draw UML
diagrams
Table 2: software tools

1.10 Testing methodology

Testing is a process of finding out the errors in a system which focused on validation and verification
before delivery to an end user. The project is tested using system testing in order to test the entire
8
software and we test the software in terms of functionality, performance, security and portability of
each system. Testing can be conduct using two approaches: functional testing (black box) and
implementation testing (white box).

White-box testing:(also known as clear box testing, glass box testing, transparent box testing, and
structural testing) is a method of testing software that tests internal structures or workings of an
application, as opposed to its functionality (i.e. black-box testing ). In white-box testing an internal
perspective of the system, as well as programming skills, are used to design test cases. The tester
chooses inputs to exercise paths through the code and determine the appropriate outputs.

This is analogous to testing nodes in a circuit. White-box testing can be applied at the unit,
integration and system levels of the software testing process. Although traditional testers tended to
think of white-box testing as being done at the unit level, it is used for integration and system testing
more frequently today. It can test paths within a unit, paths between units during integration, and
between subsystems during a system–level test. Though this method of test design can uncover many
errors or problems, it has the potential to miss unimplemented parts of the specification or missing
requirements.

Black-box testing: Test cases are built around specifications and requirements, i.e., what the
application is supposed to do. Test cases are generally derived from external descriptions of the
software, including specifications, requirements and design parameters. Although the tests used are
primarily functional in nature, non-functional tests may also be used. The test designer selects both
valid and invalid inputs and determines the correct output, often with the help of an oracle or a
previous result that is known to be good, without any knowledge of the test object's internal structure.

There for we will use both white box to test the functionality of the system and black box to test the
code one by one.

We will apply our testing methodology using blow procedures

1. Unit testing: - First we will tests each unit at each subsystem. So, if a problem is encountered
it will immediately maintain at which the problem is occurred.
2. Integration Testing: - After we test each unit of the proposed system we will perform an
integration test to check whether the system meets all the functional requirements. When a
number of components are complete; it will test to ensure that they integrate well with each
other, the operating system, and other components.

9
 3. System testing:-After all of the above testing are checked we will test our system by other
peoples and we will conduct some comments how they get our system.

1.11 Feasibility Study

The feasibility study is the preliminary study that determines whether a proposed system project is
financially, technically and operationally feasible.

1.11.1 Technical Feasibility

The system will be developed by following the object oriented system development technique, and
the team will have the ability to develop this system without any difficulty since the team have
studied the required methodologies and have tools for development, and also we will use currently
exist technology’s to perform and to develop the system. So the entire group members are expected
the system will be technically feasible.

1.11.2 Operational Feasibility

Since we will organize friendly user interface any user can easily interact with the system. Also we
will provide a help menu to give direction for users. As the users are almost educated there is no
more complexity to the users.
The system will be secured because of only authorized person can access information due to user
name and password, and also the system will be efficient because to develop this system we will use
object oriented concept due to this we reuse resources.

1.11.3 Economic Feasibility

Economically our project does costly more and also the materials to implement the system will cost
great amount of money, since this project will be computerize the current manual system. So we will
reduce the cost of materials used in manual operation such as paper, pen, human power, space needed
to record, and save data storage & time that we can be induced or bring on during in the manual
system . Here we have stated the costs related to the project and the benefits that are going to be
gained after the completion of the project by performing as a cost benefit analysis. Let’s start from
the cost by classifying them into tangible and intangible.

A) Intangible benefits our system will provide intangible benefits such as: -
• Increase accuracy
• Boost employee moral
• Fast decision making from reports
• It minimizes the work load of the employee
b) Tangible benefit: -Our system will provide tangible benefits such as
10
 • Error reduction
• Material consumption reduction
• Increase speed of activities to the system
F Our system is economical feasible because the cost that we generate in order to develop our
system is less than that of we will get from market after produce this system.
F Once the system is developed the organization will be beneficiary by reducing the amount of
money they rely on the manual system.
F Minimize the payment for the customer that work in the manual system so the organization is
economically feasible.
Finally when the organization will need additional functions it is easy to add the needed functionality
because we use incremental development method.

1.11.4 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 will be completed on time without any delay.

1.12. Project Plans

1.12.1. Project Time Schedule
Within the time duration, we will have identified the activities of the project in order to accomplish
the project objective within their schedule requirement which is on the table below
No

Time duration

2011/2019 2011/2020
Activities
Augs Septemb October Novemb Decembe April May June
e
Wee Week Week Week Week Week Week
k
1 2 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

11
1 Proposal and
Presentation
2 System Analysis
3 Presentation
4 System design
5 Implementation
and coding
6 Testing
7 Presentation
8 Post
Implementation

Table 3: Time Schedule for Our Project

1.12.2 Project Cost
Activity Cost(in birr)

Requirement analysis 550.00

Design 365.00
Coding 300.00

Testing 650.00

TOTAL 1,865.00

Table 4: Cost estimation for each phase of the software development.

1.12.3 Budget Plan
NO Item Description Quantity Price (Birr)
1 Paper 3 360
2 Internet Access --- 100
3 Mobile card --- 300
4 CD 3 75
5 Photo copy 500 500
6 Pen 6 30
7 Flash Disk (16GB) 2 500
TOTAL COST --- 1,865 ETB
12
 Table 5: Budget plan

Chapter Two
Requirement Elicitation

This chapter contains overview of existing system, business rule, drawback and advantage of the
existing system, proposed and preferred solution, domain modeling with CRC, essential use case
documentation, essential use case diagram and user interface prototype.
2.1. Overview of the 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.
Shashamane water supply service office (SWSSO) is a water supply office; it is using Desktop
application system for customer information management and bill calculation. Registration of new
customers and bill calculating using by this system. But, the system can’t generate organized report,
when we see how the new customer joins the organization. The report prepared by paper or manual.

13
Currently in online water billing system for shashamane water supply authority which is a customer
can pay water billing by going to the office physically and by finding customer information
document manually. Shashamane water supply authority currently serves 30,000 customers that
connect different parts of the city using 300 operational workers. The number of customer shows
high variability during each periods of time that requires fluctuation of number of billing payment.
This resulted in, the fact that, some customer can’t pay the billing, which subsequently result in poor
performance on resource utilization, number of customers and service quality: From the interview
conducted with the accounting and cashier personnel about billing policies, they said that the billing
procedures start with:
a.) The meter reader reads the water meter of the customer, then submits the meter reading list to the
accounting personnel,
b.) The accounting personnel posts meter readings individually then computes the cubic meter
consumed by every concessionaire and its charge in birr,
c.) After computation, the billing clerk prepares the notices of collection and a summary of bills, d.)
After billing, the Billing Clerk turns over the notices of collection to the accounting personnel,
e.) Customer pay their water bills to the Cashier, and
f.) The Billing Clerk posts the paid bills based on the Cashier’s official receipt.
Generally system exists in shashamane water billing system is manual which encounter the following
situation
F In existing system, there are various problems like keeping records of items, prices of per
water meter and fixing bill generation on each bill.
F If number of customer is increased some file is missed.
F In order to pay the billing ,they have to go to the water office station and this make customer
waste his /her time, waste budget, etc.…
F Customer need to pay cash when they pay bill and sometimes needs to queue up long time to
get the pay the bill.
F When customer go to the water office he /she may face different social problems like getting
conflict with robust
F Existing system is totally on book and those a great amount of manual work has to be done.
F The amount of manual work increases exponentially with increase in services.
2.2. Advantages of the existing system
The main advantages of the current manually water billing system gives an opportunity for customer
to have a good communication skill. In the existing system the workers only needs writing and

14
reading skill to handle manual data that does not need any knowledge of skill to register costumer
needs and information. There are activities that are considered as strength of the existing system or
practices to be preserved Employees data, Register form, Bill calculating formula, Water
preservation support agreement and Report generating form. It was easy to understand and, had clear
and precise customer identification/ code. Customer can easily view and record the different
information like card by their mobile devices by capturing a photo or writing on paper. On the other
hand, since, the system stored manually on paper, it did not depend on on/off or availability of
electric service. They also have some special functions like calling the late payer customer when they
going to finish other payment at the end of the month. In addition it is not must the availability of
network service to perform a task searching, storing, updating data.
2.3. Drawback of existing system
 The existing system performs manually and this leads to security weakness. Because of the
manual system, is time consuming and boring. This is the result of lack of computerized
system or web-based system. When the project team was analyzing the existing system, the
team has tried to study the detailed nature and procedure of the tasks and operations
performed by the system. It can only provide required information of the users after a long
period of time (takes a lot of time to perform a specific task).
F Materials registration, viewing information etc.
F Time consuming when registered as a customer of the company.
F Time consuming to prepare a bill.
F Input (Inaccurate/redundant/flexible) and Output (Inaccurate)
F Problem in getting monthly (timely) Report about customer, consumption and bill
gaining incorrect customer bill.
Security and Control Storing data is not secure, because the existing system uses access and excels
as a front end. Anyone who opens the computers, in which the system is installed and used, can
access all the contents of the database why because every activity is performed in a single computer,
activities are not secure. It causes dissatisfaction of customer.
The project team analyses the existing system problem as by using a “PIECES” framework. The
PIECES framework developed by James Wither be is used here as a means to classify problems.
PIECES stand for Performance Information Economics Control Efficiency Service.

15
 2.3.1. Performance Related problem:
Since the existing system is manual, it takes long response time. For example, when one customer
needs to pay money he/she must appear physically in the place and it takes long time that leads Poor
performance in terms of time. The work procedure is prone to error and tedious
2.3.2. Information related problem
Input: List of the customer does not contain their full information on the papers. Receive the
incorrect/redundant passenger list. They fill incorrect name and the specific time.
Output: They show the starting time, but not the ending time for the customer.
F Mishandling of information occur.
F Data is difficult to correct and maintain.
F Data is stored redundantly in multiple files.
F Data is not easily accessible.
F Data is not well organized.
F Data is not secure from damage.
2.3.3. Efficiency related problem
In manual operation, most of the activities are prone to wastage of resources like papers, man power,
time etc. to produce the corresponding outputs. This makes the current system inefficient while
utilizing resources. There should be a mechanism that reduce wastage of resources and that make the
system to be efficient. As a result, the new system will reduce wastage of resources and make it
efficient
F Since the work is performing manually, the efficiency of the working system is poor.
F Since the data is stored in redundant manner, the information generated also is redundant.
2.3.4. Control related problem
In the existing system, it is difficult to control the system because there is no privilege in data
accessing. Here the necessary reports may not generate at exact time so it may occur security
violence. The system shouldn’t provide sufficient protection for access and manipulation of records
associated with the system. So, it is not easily protected and used properly the resource.
F Control over the data is too difficult and it takes long time.
F Input data is not adequately edited.
F Redundantly stored data is inconsistent/ unreliable in different files.
F Security is another big issue concerning manual based system.
2.3.5. Economic related problem
F There is many requirement resource of paper; printer, pen and other are very cost effective.
F Manual handling of data is expansive.

16
 F Cost in terms of time is high.
2.3.6. Service related problem
The customers do not get better service and they do not satisfy with service
Business rule Identified in the Existing System
• Business rule is a rule in which the organization uses it to perform any activities or invoice.
Water meter is the property of the Authority therefore only the Authority has the right to install,
to remove, to change, transfer and to clean to inspect a water meter.
• The customer shall notify the authority as soon as he is aware that the meter is broken or has
been damaged.
• The Authority shall demand the payment of the water charge from the customer According to
its tariff and the consumption of water as show by the meter.
• Unless it is proved that the meter is not making correct reading, or is broken, the reading shall
be accepted by the Authority and the customer.
• Where the correctness of the meter is doubtful the customer may request the inspection of the
authority. The authority may also at any time inspect the meter as its own initiative.
• Where the customer fails to pay the require water charge, the Authority shall give him two
consecutive periods of months within punishment and finally the water bill removes from
customers.
2.4. Proposed Solutions
The new system is targeted to address the problem of the current system and to support additional
manipulations or features. Our proposed system will overcome the problems being faced by the
manual management system. The newly proposed system is web based system that the users can
access the web page and can get different services from this website of shashamane water supply and
authority. The system requires very low system resources and will work in almost all configurations.
It has got following features:
1. Customer can pay the bill over the Internet, 24 hours a day, 7 days a week, and the payment
information cannot be lost, stolen or left behind.
2. Ensure data accuracy.
3. Records are efficiently maintained by DBMS which provides security
4. Any person across the country, having Internet can access this service.
5. Minimum time need for the various processing.
6. Better Service.
7. Minimum time required.

17
8. This would help the corporation prepare and organize its schedules more efficiently on the basis
of traffic demand.
2.5. Preferred solution
Easy to manage and update: web based systems only need to be installed once on the company’s
server rather than separately installed on each of the end users workstations. This makes any updates
to the web based system quick and easy to roll out. The proposed system has many applications and
advantages compared to the existing system. It solves the problems of the existing system and
increase the performance of the evaluation. In our proposed system, we develop a web based
application water billing system that is capable of controlling. Water billing system is a web
application more reliable and efficient service. Any operations can have done easily with an easy
interaction with the system. Furthermore, the system especially could handle water bill payment and
might calculate the water meter reader to Ethiopian birr more easily than before the existing system.
The applications of proposed system are:
 Replace the manual to automated system.
 The proposed system enables to the water meter reader to Ethiopian birr and store bill
information in the database.
 The application composes different forms to store data to the database and retrieve required
information from the database.
 Create accounts for different users.
 It provides better and efficient service to the user.
 Reduce the workload of customer, employee, water bill reader and manager, quality assurance
and reform and staff members.
 Faster retrieval of information.
 Provides facility for proper monitoring, reduce paper-based work & provide data security.
 All details will be available in one click with the matter of second.

2.6. Domain Modeling With Class Responsibility Collaborator (CRC) Card

A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that have
been divided into three sections, class, responsibility and collaborator. 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.

CRC card
18
Class
Responsibility Collaborator
What the class knows(Name, ID, Address etc.)
What the class does(class activity).
Table 2. 1: CRC card Customer

- Customer
Responsibility Collaborator
- Name - Administrator
- Registration - Cashier
- View payment status

- Adding information

Administrator
Responsibility Collaborator
- Name - Customer
Table 2. 2: CRC
- ID - Cashier
card for cashier
- Department
- Gender
- Birth place
- View comment
- View daily report

Table 2. 3: CRC card for manager

19
 2.7. Essential Use Case Diagram
A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams model the
functionality of a system using actors and use cases. Use cases are a set of actions, services, and
functions that the system needs to perform.
Relationships: Illustrate relationships between an actor and a use case with a simple arrow line.


20
21
 2.8. Essential use case documentation
Table 1 registration essential use case

Use Case Name Registration

Use Case ID UC#1
Brief description This use case represents the procedure which the customer in
charge goes to their information to the water office. It
typically accomplished by specifying customer id.
Actor Customer
Pre-condition The customer s must be go to water office
Post Condition The customer’s information will be recorded for registration
Basic Course of Action 1. the use case starts before payment is done
(BCA) 2. The record officer adds the customer id per year
information to water office as input.
3. The record contains full customer information
provided.
4. The use case ends when all customer information gets
registered and added successfully.

Table 2 generate report essential use case

Use Case Name Generate report

Use Case ID UC2
Brief description This use case represents also which the administrator in
charge accomplishes by generating reports from registration
records
Actor Administrator
Pre-condition The customer record must be exist in the system
Post Condition The report will be generated for director
Basic Course Of Action 1. The use case starts before payment is done
(BCA) 2. The administrator can generate report to the director as
input for billing payment
3. The director keeps the reports generated for payment
4. The use case ends when director gets all the generated
inputs successfully.

22
Table 3view bill essential use case

Use Case Name View bill

Use Case ID UC3
Brief description This use case represents also which the customer in charge
and system users accomplishes by seeing and visiting bill
from.
Actor Customer
Pre-condition The payment bill must be announced to watch
Post Condition The payment bill will become viewed.
Basic Course Of Action 1. The use case starts after payment bill become created
(BCA) and added.
2. The clerk in charge, vice customer will get the
payment bill.
3. The payment bills become visible and ready for
usability.
4. The use case ends when the payment bill is posted
successfully.

Table 4 pay bill essential use case

Use Case Name Pay bill

Use Case ID UC4
Brief description This use case represents also which the customer in charge
accomplishes by paying the monthly bill.
Actor Customer
Pre-condition The customer r must go to water office
Post Condition The payment bill receipt will give to customer
Basic Course Of Action 1. The use case starts after the customer go to water office .
(BCA) 2. The administrator in charge will get the reports.
3. The payment bill becomes paid and ready for managing.
4. The use case ends when the payment bill is paid
successfully.

23
Table 5 View feedback essential use case

Use Case Name View feed back

Use Case ID UC5
Brief description This use case represents also which the administrator in
charge accomplishes by seeing and visiting payment bill
from.
Actor Administrator
Pre-condition The cashier must get reports generated
Post Condition The payment bill reports will become seen after generation
Basic Course Of Action 5. The use case starts after the payment bill View feedback
(BCA) become seen.
6. The administrator in charge will get the bill View
feedback reports.
7. The View feedbacks become visible and ready for
managing.
8. The use case ends when the View feedback report is view
successfully.

Table 6 Manage cashier essential use case

Use Case Name Manage cashier

Use Case ID UC6
Brief description This use case represents also which the administrator in
charge accomplishes by managing the cashier details
Actor Administrator
Pre-condition The cashier information must be created and added.
Post Condition The cashier will become managed to solve bill reports
generated.
Basic Course Of Action 1. The use case starts after the cashier information become
(BCA) created.
2. The administrator in charge will generate reports on
payment bill
3. The administrator manages the bill by the reports in

24
 charge.
4. The use case ends when the cashier is managed
successfully.

2.9. Essential User Interface Prototype

In the existing system, they use different forms and reports to manipulate different records associated
with the different activities bill. Among them water billing form is one of the main paper document
used in the existing system. The form is look like this:
The following are forms and other documents used in the existing system. Contract for supply of
water: date, full name, address, woreda, kebele, house no, placement no, house phone no, mobile no,
email, service type, purpose of water is to be signature, contract no, power approved, application
tariff, purpose of electricity is to be supply, deposit birr, connector birr, total, receipt, customer sign
and authority sign.

The following table shows current tariff of water consumption

Number Consumption Tariff/Birr

1 From 0 - 5 m3 2.90

2 From 5.1 - 10m3 4.40

3 From 10.1 - 25m3 6.10

4 From 25.1m3 and above 8.20

Water consumption table

25
 CHAPTER THREE

SYSTEM ANALYSIS
3.1. Introduction
System analysis is an essential activity that must be under taken in any project in order to have a
clear idea of the proposed system. This document will discuss details of the requirement analysis and
overall description and Work flow of the existing system.
The requirement of the proposed system will be explained in functional and non-functional
requirements. In doing so, use case model will be used. To produce a model of the system which is
correct, complete and consistent we need to construct the analysis model which focuses on
structuring and formalizing the requirements of the system. Analysis model contains three models:
functional, object and dynamic models. The functional model can be described by use case diagrams.
Class diagrams describe the object model. Dynamic model can also be described in terms of
sequence, state chart and activity diagrams. For the purpose of this project we have described the
analysis model in terms of the functional model
26
 3.2. Over view of the new 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 web based
water billing and customer service management system for SWSSO which allows easily register
customer, maintenance order request, search payment, and generate report and to overcome the
existing system problems.

3.3. System requirements

To distinguish the different features and aspects of the newly developed system we have tried to use
two approaches in requirement specification:
 Functional requirement
 Nonfunctional requirement
3.3.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:
Manager Aspect:
 The system should allow to the manager to Delete User accounts.
 The system should allow to the manager to Create User accounts
 The system should allow to the manager to Update User Accounts Customer Service Aspect:
 The system should allow to the Customer Service Expert to delete customers.
 The system should allow to the Customer Service Expert to register new customers.
The system should allow to the Customer Service Expert to update customer’s info.
 The system should allow to the Customer Service Expert to Delete, add &Update new
customers.
Customers Aspect:
 The system should allow to the customer to search their payment.
 The system should allow to the customer to request maintenance order.
 The system should have login accounts.
 The system should allow to the Bill Officer to record the meter reading into it.
• The proposed system should have authentication system for Manager, Bill officer,
Customer Service expert and Technical supervisor.
• The new system should hold customer’s personal information.
27
 • The proposed system should add data from different user of the system to the DB our
proposed system should update, delete and add records as needed.
• Bill calculates.
• 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 should search the customer file from the database.
3.3.2. Non-functional requirements
Nonfunctional requirement is a requirement that specifies criteria that can be used to measure the
performance of a system, rather than specific behaviors. Non-functional requirements define how a
system is supposed to be performing activity. Non-functional requirements are often called qualities
of a system. Other terms for non-functional requirements are constraints, quality attributes, Quality
goals and quality of service requirements. Qualities that are nonfunctional requirements can be
divided into two main categories: -
 System performance
System performance is characterized by the amount of useful work accomplished by a system
compared to the time and resources used.
Depending on the context, good system performance may involve one or more of the following:
• Every employee can access the system.
• Works can be performed in a short period of time.
• Customers get quick access.
 Security
In order to make the system safe from an unauthorized access and modification, the system uses a
login account to differentiate among the different users of the system on WWSSO to protect the
sensitive customer and material information. This enables the system to verify who has logged in
using the correct logging account provided and display the right form associated with that user.
 Usability
• More efficient to use—it takes less time to accomplish a particular task.
• Easier to learn—operation can be learned by observing the object.
• To give more satisfaction to use our system we prepare manual and
documentation facility.
 Backup

28
  We use aback up method regularity of the backup (per week, per month,). And also
we use from the three types of back up methods (Full, Incremental and Daily
backup) daily backup. We use some of the Medias (HD, flash, CD, DVD).
 Efficient • Searching a customer record should not take more time
• The system displays in every window.
• The system should be user friendly Integrity
• 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. But here there is misfeasors authentication.
• We will keep them from them
 Maintenance
The system should be easy to maintain and update.
3.3.2.1. Hardware Requirement
F Personal computer (PC): almost all tasks of our project are performed on
computer.
F Flash disk: required for data movement to store & transfer data from one PC
to another PC.
F Disks (CD, DVD): necessary for the movement of relevant data and for
backup and recovery mechanism.
F 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.
F Server: to store the data.
F Stationeries (pen, paper): for writing all necessary documentations associated
with the project.
F Note book: to take notes during data collection and for other document.
3.3.2.2. Software Requirement
F Windows 10 Operating system: will be used for the system since it is readily available
in laboratories.
F Browsers: -since our system is web based, it is very necessary requirement
PHP: -To design the graphical user interface and the whole application.
F MYSQL server: -for designing the database.
F Microsoft office Word 2013: -for documenting the corresponding deliverables
associated with the project
29
 F Enterprise architecture and Edraw max 6.8: -for designing Unified Modeling
Language (UML) diagrams.
F Microsoft Visio: used to draw diagrams.
F Adobe Photoshop (CS4): -for editing images and preparing user interfaces.
F Macromedia Dreamweaver 8: For writing a code or program of the system.
F Xampp Server: - To test the system by running.
3.3.2.3. Security Procedure
In order to make the system safe from an authorized access and modification, the system uses a
login account. This enables the system to verify who has logged in using the correct logging account
provided and display the right form associated with that user. The technologies that the system is
going to be built on gives a robust security handling and user authentication facilities. Access is
controlled through proper password verification facilities which the database and the server require.
The security service provided by the system will maintain the security, confidentiality and integrity
of the system. The security provided includes giving users a higher confidentiality. Security is
addressed using proper authentication. Generally, this system introduces a proper authentication and
accountability through proper authentication requirement to that aspect.
3.3.2.4. Safety Procedures
After the system is fully developed and displayed the development group members are
responsible for the installation of the system. In addition, the group handles system maintenance in
case of failure and expansion of the system.
3.4. System modeling
The use case model provides detailed information about the behaviors of the system or application
that we are developing. The use case model identifies the requirements of the system in terms of the
functionality that must exist to achieve the goals set out by the user or to solve a problem identified
by the user.
System modeling: is the conceptual model as result of the modeling describes and represent a system
State.
3.4.1. System use case diagram
A use case diagram is a sequence of actions that provide a measurable value to an actor. It describes
the systems behavior as it responds to a series of related requests from an actor. This use case
perhaps the best way to capture functional requirements of the system.
According to the description of use case, there are major use case scenarios in the Water billing
System.

30
3.4.1. 2. Scenarios
F Tells who is using the system and what they are trying to
accomplish.
F Provides a realistic, fictional account of a user's constraints: when
and where they are working, why they are using the system, and
what they need the system to do for them.
F Describes any relevant aspects of the context in which the user is
working with the system, including what information the user has
on hand when beginning to use the system.
F The following are describing scenario of how the user uses the
systems of the institution.

Scenario Name Login(successfully)

Participating: Actor Manager: Mohamed ,
Technical supervisor: Girma,
customer service expert: Aster,
Bill Officer: Alemayehu:
Customer: Abebe,
Flow of events 1. The actor displays home page of the system.

2. The actor puts his or her user name and password in to the login form.

3.The system checks the validity of the inputs of the actor

4. The actor is logged into the system.

Table 5 A Scenarios for Login (Successful)

Scenario Name Mange Account

Participating: Manager Manager: Mohamed

31
Flow of events 1. Manager Alemu displays the home page
of the system.
2. He puts his user name and Password in to
the login form.
3. The system checks the validity of the
inputs and if it is correctly much Mohamed can
logged in to his page.
4. After he logged in to his page he can
delete, create and update accounts as he wants.

Table 6 A Scenario manage account

Scenario Name Manage customer info

Participating: Customer Customer service expert: Aster
service expert
Flow of events 1. First She must display his login page.

2. She must enter his user name and password in to the system.

3. The system checks its validity and if it is correctly much input.

4. The customer service expert can log into the system and now
She can delete, update and add customers.

Table 7 A Scenario manage customer info

Scenario Name Record material

32
Participating: Technician Technician: Girma
Flow of events 1. Technician: Girma displays the home page of the system
2.He puts her user name and Password in to the login form 3.
The system checks the validity of the inputs and if it is
correctly much Girma can log in to his page.
4. Technical supervisor Girma clicks the record material link.
5. Enter the correct & all necessary information. Step5.

Initiate the system to sends to the organization.

Table 8 A Scenario for record material

Use Case represents interaction between the user and the system
The following use cases have been identified from the system specification
• View payment
• View Maintenance Assigned Date
• Request Maintenance Order
• Login
• Register new water connection
• Maintenance Request
• Payment record
• Manage Account
• Manage Customer
• Bill Calculate
• Accept Maintenance
• Generate Report
• Maintenance approve
• Record meter reading

33
The identified actors that will be participating in the system are:
• Customer
• Bill officer
• Manager
• Customer service expert
• Technical supervisor
Figure 1 use case diagram
Note: Deleting customer is not mean that totally delete customers from the database, actually

mean temporarily remove the data.

34
 3.4.2. 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 Manager; Bill officer, customer service expert, Technical supervisor.

Pre-condition The users should have registered into the system

Post-condition The user will be login in to the system and able to access the required
home page.
Basic course of Step 1. Initiated when the user wants to login into the system Step2.
action (Flow of The system Displays the User Login Page.
event): 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 page of the user.
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.
2. The system continues at step 2 to fill user name and password
again.

Table 10 Use case documentation for Login;

Use case documentation for Create account

35
Use case name Create Account

Description Used to create account for users.

Actor Manager
Pre- condition: The user should be member of the WWSSO
Basic course action of Step1.The manager wants to create account.
(Flow event): Step2.The system displays create account page.
Step3.The manager fills the required information and submits it.
Step4.The system validates the information.
Step5.The system registers the users into the system database.
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 9 Use case documentation for Create Account

Use case documentation for Delete account

Use case name Delete Account

Description It Allows Manager to delete User account
Actor Manager
Precondition To delete the User account must be registered in the database.

36
 Basic course of Step1.The Manager wants to delete account.
action (Flow of Step2.The system displays the delete account page.
event): Step3. The Manager 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 If the selected account is invalid.

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

Table 10 Use case documentation for Delete Account

Use case documentation for Apply new water connection
Use case name Register customers
Description It allows customer to register the DB, a customer requests registration to
get new water connection from WWSSO.
Actor Customer service expert
Precondition The customer should have contact with the customer service expert to get
the new water connection of WWSSO.
Post-condition The customer can join the organization and access online service from the
office.

37
Basic course of action Step1.Initiated when the Customer wants to register to the DB
(Flow of event): Step2.Customer Service expert opens the home page and click apply
register link.
Step3.The system displays the Customer register page.
Step4.Enter the correct & all necessary information’s of the customer.
Step5. Initiate the system to sends to the organization.
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 11 Use case documentation for Apply new water connection

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 events): 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.

38
 Table 12 Use case documentation for Update customer
Use case documentation for Delete customer
Use case name Delete Customer
Description It allows to remove customer from WWSSO database.
Actor Customer service expert
Precondition 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 13 Use case documentation for Delete customer

Use case documentation for request maintenance

39
Use case name Request maintenance

Description It allows customer to get order maintenance.

Actor Customer
Pre-condition The customer should register to the system or system DB.
post condition Maintenance order will be recorded to the system.
Basic course of Step1. Customer open the homepage Step2. Customer selects maintenance order
action (Flow of from the home page.
event): 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 14 Use case documentation for request maintenance

Use case documentation for Receive maintenance

Use case name Receive maintenance

Description It allows receive and approve customer maintenance request process.
Actor Technical supervisor
Precondition The customer should ask the request maintenance.
Post- condition Customer maintenance request should be transferred and service being
delivered.
Basic course of action Step1.Technical supervisor open the homepage
(Flow of event): Step2. Technical supervisor inserts the login address on the page.
Step3. System validates the address. Step4. Technical supervisor
checks and see the problem. Step5. Technical supervisor takes the
request 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.

Table 15 Use case documentation for Receive maintenance

Use case documentation for View report

40
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 (Flow of Step1. The manager opens the home page.
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 16 Use case documentation for View Report

Use case documentation for Receive payment
Use case name Receive payment
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 Step1. Bill officer Open the homepage.
action (Flow of Step2. Bill officer Enter user name and password. Step3. System validates it.
event): 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 17 Use case documentation for Receive payment

Use case documentation for maintain meter reading

41
Use case name maintain meter reading
Description The bill officer reads water meter reading.
Actor Bill officer
Precondition 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. Step2. Bill officer should collect
(Flow of event): water meter. Step3. Bill officer Enter the address of the customer.
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. 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 18 Use case documentation for Record meter reading

Use case documentation for record 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 registers the material into WWSSO database
Racecourse action Step1. Technical supervisor opens the home page.
(Flow of event): Step2. Technical supervisor enters its own username and password to login.
Step3. Technical supervisor clicks 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.

42
 3.4.3. 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. [2]

43
 Figure 4 UML Sequence diagram for Login

Figure 5 UML Sequence diagram for Customer Registration

44
Figure 6 UML Sequence diagram for Calculating Bill

45
Figure 7 UML Sequence diagram for View Report

46
Figure 8 UML Sequence diagram for Create Account

47
Figure 9 UML Sequence diagram for Delete Account

48
Figure 10 UML Sequence diagram for request maintenance

49
Figure 11 UML Sequence diagram for Update customer

50
 Figure 12 UML Sequence diagram for Delete customer
3.4.4. 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. 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. Activity diagram focuses on the flow of activities involved in a single
process. The Activity diagram shows how these sing

Figure 13 UML activity diagram for Registration of customer

51
52
Figure 14 UML activity diagram for View report

53
Figure 15 UML activity diagram for Record meter reading

54
Figure 16 UML activity diagram for Calculate cost of bill

55
Figure 17 UML activity diagram for request Order maintenance

56
Figure 18 UML activity diagram for Create account

57
Figure 19 UML activity diagram for Delete customer

58
Figure 20 UML activity diagram for update customer

59
 3.4.5. Class diagram
The conceptual class diagram of our system notifies Classes that are identified from school
management system and specify each class by adding the possible methods an attribute. These
Classes during this phase are helping in developing the source code. The class diagram is the
main building block of object oriented modeling. It is used both for general conceptual
modeling of the systematic of the application, and for detailed modeling translating the models
into programming code. The classes of the scheduling system are integrated as follows:

60
Figure 2 Class diagram

61
 CHAPTER FOUR

SYSTEM DESIGN
4.1. Design Goals
In the previous chapter we have identified the functional and non-functional requirements of the
system and produced the analysis model. The following are discussed in this chapter: design
goals, system architecture, system decomposition, deployment and database design and interface
design. Systems design is the process of defining the architecture, modules, interfaces, and data
for a system to satisfy specified requirements. Systems design could be seen as the application of
systems theory to product development. There is some overlap with the disciplines of systems
analysis, systems architecture and systems.
System design is the process and focuses on decomposed the system into manageable parts.
During requirements elicitation and analysis, we concentrated on the purpose and the
functionality of the system. During system design, we focused on the processes, data structures,
and software and hardware components necessary to implement it. The challenge of system
design is that many conflicting criteria and constraints need to be met when decomposed the
system. The analysis model describes the system completely from the actors’ point of view and
serves as the basis of communication between the client and the developers. The analysis model,
however, does not contain information about the internal structure of the system, its hardware
configuration, or, more generally, how the system should be realized.
System design results in the following products:
 List of design goals, described the qualities of the system that developers should
optimized.
Software architecture, described the subsystem decomposition in terms of subsystem
responsibilities, dependencies among subsystems, subsystem mapping to hardware, and major
policy decisions such as control flow, access control, and data storage
Design goals identify the qualities that our system should focus on.And provide a consistent set
of criteria that must be considered when making design decisions. The design goals are derived
from the non-functional requirements.
N.B: The goal of system design is to manage our system complexity by dividing the system into
smaller, manageable pieces in general.

62
4.2. System Architecture
Class type architecture (layering), software architecture, and describing the sub system
decomposition in terms of sub system responsibility and dependencies among subsystem,
subsystem mapping to hard ware, and major policy decisions such as control flow, access
control.
The proposed software has three layers of architecture. The layers are the following: -

 The application layer

 Logic/ connector layer

 Database layer

Application layer: Layer which provides graphical user interface and application specific
entry forms to the user of the system. Application layer interact with logical layer through
http protocol. Logic layer: Layer that used to implement business rules and data rules, which
keep the data structure consistent. Database layer: This actual DBMS layer. Used to assist
resource sharing and allow the client to be configured with the help of ODBC driver.

Figure 24 System architecture for SWSSO

63
4.3. User Interface Prototype

Figure 21 User Interface Prototypes

64
4.4. Sub System decomposition
During the subsystem decomposition of Online Ethiopian Postal Service, we have just divided
the general system into smaller subsystem with strong coherence. So following are subsystems of
our system

Figure 25 Decomposition of SWSSO

65
4.5. Hardware/Software Mapping
In this section the team put down the overall hardware and software organization of the system.
So deployment diagram is required to show the system hardware/software mapping.
The system interface which will interact with the database will be programmed in PHP and the
databases will be done in MYSQL and the web server will be run on Apache.

Fig 4.7 Hardware and Software mapping diagram

4.6. State chart diagram

The state chart of the online Water billing system used to model and identify the behavior with in
our system and behaviors specified to the instances of a single class. The following diagram
shows the flow of control from state to state.

66
Figure 1state diagram for create account

Figure 2state diagram for login

67
Figure 3state diagram for edit user

Figure 4state diagram for delete use

Figure 5state diagram for add user

4.7. Collaboration diagram

Collaboration diagram of our system represents a combination of information taken from class,
sequence, and use case diagrams that describes the behavior of a system. And it also shows data
flows between objects
Collaboration diagram represent a combination of information taken from class, sequence, and
use case diagrams describing both static structure and dynamic behavior of a system. And it
also shows some data flows between objects and the interaction caused between them. The
following figures show the Collaboration Modeling of the system.

68
Figure 6collaboration diagram for login

Figure 7collaboration diagram for manage account

69
4.8. Component diagram
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.

Figure 22 Component Diagram

70
4.9. Deployment diagram
In the deployment diagram of our system, it intends to show the hardware of the system, the
software that was installed in the hardware and the middle-ware or the server that connects the
disparate machines to one and another

Figure 23 Deployment Diagram

71
4.10. Persistence Data management
Also called data modeling; persistence models are used to communicate the design of database,
usually relational database, with the user and other developers. This is basically the entity
relation in database application. Persistent modeling is used to depict the design of the database.
The team is used the relational database since it is the most used data base system recently.
Every table is related to each through their primary and foreign key. Also each table has
Attribute with compatible Data Type.
Mapping relational tables
The term mapping refers to how objects are their relationships are stored in a relational database.
In order to perform this approach we have maintained the following rules:-
Rule1: Entity names will automatically tables name.
Rule2: Attributes will be columns of the respective tables.
: Single valued attributes will be mapped as columns of the table.
: Composite attributes will be decomposed to become columns of the table.
: Multi valued attributes will be mapped to a new table where the primary key of the main
table will be posted for cross referencing.
Rule3: Relationship will be mapped by using foreign key attribute.
In relational persistence model we have to relate the class by using primary key and foreign key
as shown below.

72
 Figure 3 EER Diagram

. User table
73
User_ID FName LName Kebele cellphone Office phone

Customer table
UserID FName Lname Kebele

Account table
AccountID UserID username Password Role

Report table
RID Rtype Rdescription

Meter table
M_ID UserID Mtype Msize

Meter reading table

MR ID MID Previous reading Current raeding

Bill table

Bill_ID MRID Amount Payment Status

Material table

MaterialID Type cost

Maintainance table
MaintainanceNo MaintainanceRequestDate

Table 20 Normalization for the table

Relational table

74
Bill_ID MRID Amount Payment Status

4.11 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

75
 Figure 26 user interface for SWSS Login page

Figure 27 user interface for SWSS Create Account

76
Figure 28 user interfaces for SWSS Customer registration

Figure 29 user interface for SWSS Payment record

77
 Chapter Five
Conclusion and Recommendation
5.1. Conclusion
Shashamane Water Supply Service Management System is one of the main Management
system found in the Shashamane Town. This system is a web based application to serve
customers as well as the working group of the system in different direction. Specially:
customers can know their payment online and they can send a maintenance request to get
maintenance support which overcomes extra expenditure of time and resource customers can
save their time and resource lost for requesting maintenance order and they get benefit by
viewing their payment online by their ID. Through various challenging, now the team
members are coming to the end of this project. Those different challenges made possible by the
cooperation of all the group members. In developing this project all group members
contributed their full capability with maximum interest and all group members get ways
toward developing a project.
5.2. Recommendation
While doing this system we all the team members have faced different challenges.
But by our cooperation and with the help of our main advisor now we able to reach to the final
result.
I.e. all of we the group members strongly fight these challenge and by informing to our advisor
to help us we reach the turn to the front. Moral support is the main instrument for resist
challenging problems to solve them. So now all the group members strongly recommend the
department that for the coming students, it has to provide them with better service than the
present in better hard ware, guaranteed software’s, giving orientations how to proceed, offering
guest to provide them with more experienced work, support morally, manually, forming good
relation with students, giving students description of each phases and so on. So that it will get
what it expects from its students and satisfy with them.

78
 Reference
[1] "http://ww.satisfaction.com/cool-text-maker/," [Online].

[2] "http://en.wikipedia.org/wiki/Sequence diagram," [Online].

[3] "http://www.tutorialspoint.com/uml/uml_deployment_diagram.htm,"
[Online].

[4] " http://creately.com/blog/diagrams/uml-diagram-types-examples/,"

[Online].

[5] "http://edutechwiki.unige.ch/en/User_interaction_and_user_interface_desi
gn," [Online].

[6] "http://www.tutorialspoint.com/uml/uml_statechart_diagram.htm,"
[Online].

[7] " https://www.youtube.com/watch?v=ObNDfHliVdw," [Online].

[8] W. Manager, Interviewee, Background and existing system of WWSSO.

[Interview]. 30/03/08 November 2008.

[9] "http://www.screen cast - O-matic.com," [Online].

Websites
 www.tutorialspoint.com/index.html
 www.w3schools.com/index.php
 http://www.ibm.com/developerworks/rational/library/3101.html

Books
• Essentials of System analysis and design (in analysis and design phase)
• System analysis and Design methods (in analysis and design phase)
• A modern, modular approach to standards-compliant web design Craig Grannell
Foreword by Jon Hicks, Huckstering
• Andrew Curioso, Ronald Bradford, Patrick Galbraith

79