Final Project Group

JIGJIGA UNIVERSITY
INSTITUTE OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
PROJECT TITLE: CUSTOMER BILLING MANAGEMENT SYSTEM FOR

JIGJIGA CITY WATER SERVICE
Group Members
NO F.NAME L.NAME IDNO
1 Tadilo Muhabaw R/1610/09
2 Kemerya Abdulmenan R/2136 /09
3 Desalew Haymanot R/2016/09
4 Belete Alemu R/1964/09
5 Yohannes Belete R/ 2381/09
6 Netsanet Yigzaw R/2236/09
Advisor: Chaltu Fita

Submission date: 22/01/2021
Jigjiga, Ethiopia
Customer Billing Management System For Jigjiga City Water Service
APPROVAL SHEET
This Group Project Proposal titled customer billing management system for Jigjiga city water service
has been read and approved as meeting the preliminary final project requirements of the Department
of computer science in partial fulfillment for the award of the degree of Bachelor in computer
science, Jigjiga University, Jigjiga, Ethiopia.
This Senior Group Project has been approved with the signature of advisor and department of
computer science and Examiners.
Name Signature Date

Advisor …………… ………………. ………………….
Department Head ……… ……… ………… ……..………….....
Examiners:
1. Examiner 1 ……….. ……… ………… ……..…………...
2. Examiner 2 ……….. ……… ………… ……..…………...
3. Examiner 3 ……….. ……… ………… ……..…………...
4. Examiner 4 ……….. ……… ………… ……..…………...
5. Examiner 5 ……….. ……… ………… ……..…………...
i
Contents
APPROVAL SHEET..........................................................................................................................................i
List of Figures...................................................................................................................................................iv
List of Tables......................................................................................................................................................v
Acknowledgements..........................................................................................................................................vii
Abstract...........................................................................................................................................................viii
CHAPTER 1.......................................................................................................................................................1
1. INTRODUCTION......................................................................................................................................1
1.1 Background Study of the Organization.....................................................................................................1
1.2 Statement of the Problem..........................................................................................................................1
1.3 Objectives of the Project...........................................................................................................................2
1.3.1 General Objective..............................................................................................................................2
1.3.2 Specific Objectives............................................................................................................................2
1.4 Scope of the Project..................................................................................................................................2
1.5 Limitation of the project...........................................................................................................................3
1.6 Methodology of the Project......................................................................................................................3
1.6.1Data Collection Methodology.............................................................................................................3
1.6.2Analysis of the System and Design Methodology..............................................................................4
1.6.3 Development Environment Tools......................................................................................................4
1.7 Significance of the project........................................................................................................................5
1.8 Risk Assessment and Management...........................................................................................................5
1.9 Operating environment.............................................................................................................................5
1.9.1Hardware environment.......................................................................................................................6
1.9.2 Software environment........................................................................................................................6
1.10 Feasibility study......................................................................................................................................6
1.10.1Technical Feasibility.........................................................................................................................7
1.10.2Schedule Feasibility..........................................................................................................................7
1.10.3 Operational Feasibility.....................................................................................................................8
1.10.4 Legal Feasibility..............................................................................................................................9
1.10.5 Economic Feasibility.......................................................................................................................9
1.11 Document Organization........................................................................................................................10
CHAPTER TWO..............................................................................................................................................11
2. DESCRIPTION OF THE EXISTING SYSTEM......................................................................................11
2.1 Introduction............................................................................................................................................11
2.2 Main activities........................................................................................................................................11
2.3 Function of the Existing System.............................................................................................................12
2.4 Players of the existing system.................................................................................................................12
ii
2.5 Report Generating in the existing system...............................................................................................12

2.6 Documents used in the existing system..................................................................................................13
2.7 Weakness of the Existing System...........................................................................................................14
2.8 Strength of the Existing System..............................................................................................................14
2.9 Alternative Solution................................................................................................................................14
CHAPTER THREE......................................................................................................................................15
3. Requirements Specification and Analysis.................................................................................................15
3.1 INTRODUCTION......................................................................................................................................15
3.1.1 Purpose............................................................................................................................................15
3.1.2 Intended audience and reading suggestions.....................................................................................15
3.1.3 Document convention......................................................................................................................16
3.2Objective.................................................................................................................................................16
3.3 Functional Requirements........................................................................................................................17
3.4 Product perspective.................................................................................................................................17
3.5 Product Functions...................................................................................................................................18
3.6 Principal Actors..................................................................................................................................18
3.7 User characteristics.............................................................................................................................18
3.8 General constraints.................................................................................................................................18
3.9 Assumptions and dependencies..........................................................................................................19
3.10 Nonfunctional Requirement..............................................................................................................19
3.11 System Models.....................................................................................................................................21
3.11.1 Use case models.............................................................................................................................21
3.11.2 Use case description for the proposed system................................................................................23
3.11.3 Sequence diagram..............................................................................................................................34
3.2 Class diagram.........................................................................................................................................45
3.4 Activity Diagram....................................................................................................................................45
CHAPTER FOUR............................................................................................................................................54
4. System design...........................................................................................................................................54
4.1 Introduction............................................................................................................................................54
4.2 Design Goals..........................................................................................................................................54
4.2.1Performance Criteria.........................................................................................................................54
4.2.2Maintenance Criteria.........................................................................................................................54
4.2.3End User Criteria..............................................................................................................................55
4.3 System Architecture...............................................................................................................................55
4.4 Subsystem Decomposition.....................................................................................................................56
4.5 Components Diagrams............................................................................................................................56
4.6 Deployment Diagrams (hardware and software mapping)......................................................................57
4.7 Persistent data management....................................................................................................................58
iii
4.8 Access control and security....................................................................................................................59

4.8.1 Boundary condition.........................................................................................................................61
4.8.2 Exception handling..........................................................................................................................61
4.9 User Interface Design.............................................................................................................................61
CHAPTER FIVE..............................................................................................................................................66
5. System Implementation and Testing.............................................................................................................66
5.1 Implementation.......................................................................................................................................66
5.2 Sample code and their screen image.......................................................................................................66
5.2.1 Home Page.......................................................................................................................................66
5.3 Test Approach........................................................................................................................................69
5.3.1 Integration Testing...........................................................................................................................69
5.3.2 Unity Testing...................................................................................................................................69
CHAPTER SIX..................................................................................................................................................2
6. Conclusion......................................................................................................................................................2
6.2 Recommendation......................................................................................................................................2
Reference............................................................................................................................................................3
List of Figures
Figure 2. 1: Form of receipt the existing system.............................................................................................14
YFigure 3. 1: use case diagram.......................................................................................................................21
Figure 3. 2: Sequence Diagram for Login......................................................................................................33
Figure 3. 3: Sequence Diagram for Change Password...................................................................................34
Figure 3. 4: Sequence Diagram for Prepare Bill............................................................................................35
Figure 3. 5: Sequence Diagram for Set Penalty..............................................................................................36
Figure 3. 6: Sequence Diagram for Generate Report.....................................................................................37
Figure 3. 7: Sequence Diagram for View usage Bill.......................................................................................38
Figure 3. 8: Sequence diagram for Give Feedback.........................................................................................39
Figure 3. 9: Sequence diagram for request bill maintenance.........................................................................40
Figure 3. 10: Sequence diagram for View Bill maintenance requests............................................................41
Figure 3. 11: sequence diagram for pay bill use case.....................................................................................42
iv
Figure 3. 12: Sequence diagram for signup use case......................................................................................43
Figure 3. 13: Class Diagram for the proposed system....................................................................................44
Figure 3. 14: Login Activity Diagram.............................................................................................................45
Figure 3. 15: Activity diagram for Prepare Bill..............................................................................................46
Figure 3. 16: Activity diagram for set penalty.................................................................................................47
Figure 3. 17: Activity diagram for Generate Report.......................................................................................48
Figure 3. 18: Activity diagram for View Usage bill........................................................................................49
Figure 3. 19: Activity diagram for Give Feedback..........................................................................................50
Figure 3. 20: Activity Diagram for Request Bill Maintenance........................................................................51
Figure 3. 21: Activity diagram for customer signup.......................................................................................52
Figure 4. 1: Proposed system Architecture Design.........................................................................................54
YFigure 4. 2: Decomposition of JWSO...........................................................................................................55
Figure 4. 3: Component Diagram...................................................................................................................56
Figure 4. 4: Deployment diagram...................................................................................................................57
Figure 4. 5: persistence diagram.....................................................................................................................58
Figure 4. 6: Access Control and Security........................................................................................................59
Figure 4. 7: user interface for Login page......................................................................................................61
Figure 4. 8: user interface for admin page......................................................................................................62
Figure 4. 9: user interface for CreateAccount................................................................................................63
Figure 4. 10: user interface for Payment record.............................................................................................64
List of Tables
Table 1. 1: Gant chart of project schedule........................................................................................................8
v
Table 1. 2: cost break down.............................................................................................................................10
YTable 2. 1:Water consumption table.............................................................................................................13
Table 3. 1: Login use case description............................................................................................................22
Table 3. 2: Change password use case description.........................................................................................23
Table 3. 3: Prepare bill use case description..................................................................................................24
Table 3. 4: Prepare bill use case description..................................................................................................25
Table 3. 5: View usage bill use case description.............................................................................................26
Table 3. 6: Give feedback use case description...............................................................................................27
Table 3. 7: Request Bill Maintenance Use case description...........................................................................28
Table 3. 8: View Bill Maintenance Request Use case description..................................................................29
Table 3. 9: Pay Bill use case description.........................................................................................................30
Table 3. 10: use case description for customer signup.................................................................................31Y
Table 3. 11: Logout use case description........................................................................................................32
YTable 4. 1: Access Control and Security.......................................................................................................59
Acknowledgements
We would like to thank GOD for giving us strength and health to start this project proposal. We are
vi
also grateful to our Advisor Ms. Chaltu Fita for her constructive guidance from the beginning of the
project up to now, and then we would like to thanks our institute of technology for giving as this
chance to do this final project. Finally, we want to extend our thanks to our parents for their
encouragement, Motivation and support throughout our study. And also we would like to thanks all
members of Jigjiga city water billing management system office workers who give any information
when we asked them.
vii
Abstract
Now a day, using computers to simplify deadly manual work is significance. Because using computer
gives many benefits like speed, accuracy, storage capacity, flexibility, cost reduction and minimizing
tedious manual work. Customer billing management system for Jigjiga city water service is limited
on desktop work. This has a limitation for customer’s used up large amount of time in front of the
office to register and to get Service of resources. To overcome this problem, we are proposing the
new system for Jigjiga City Water Service Office. Customers can check their payment online so that
no need of wasting time and before they are going to the office to pay the payment without knowing
the real amount by the proposed system they can check their real payment.
viii
CHAPTER 1
1. INTRODUCTION
As we know, today our world is under the control of technology because of this reason the world
is related to 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 Jigjiga water billing service office
into web based system using today’s technology.
Jigjiga water billing service office has many activities. Such as, Customer registration, meter
reading, bill calculating, bill payment based on their customer information and the likes. The
proposed system enables the officer to have very fast services to their customer by designing
web based service management system for them.
1.1 Background Study of the Organization

Jigjiga water billing service office is a water billing organization which is located in Jigjiga city.
The organization is established in 1968 E.C as part of the city administration. At that time, the
office had only 12employees’ water chemist, motor operator, meter reading expert, and two
security bodies. Jigjiga city water billing service follows both paper based and desktop system to
give service for their customer. Today there are 200 employees and 15734 customers. Customers
registered first on a paper then to desktop. [2]
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 customer billing management system for Jigjiga city water service office.
1.2 Statement of the Problem

There is a paper and desktop application system in Jigjiga water billing service office which is a
standalone desktop application. In the system every activity is performed on a single desktop.
Jigjiga water billing service office has many activities. Such as: Registration of customer, meter
reading, bill calculates, bill payments, bill print and bill maintenance. Because of its paper based
and desktop application there is a great workload on the organization, customer’s waste their
COMPUTER SCIENCE 4th YEAR 2020 GC | 1
time and money. Since customers do not get quick access, and also there may be a great fault due
to workload. Another key problem of Jigjiga water billing service office 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 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.
1.3 Objectives of the Project

1.3.1 General Objective
The general objective of the project is to develop web-based customer billing management
system for Jigjiga city water service.
1.3.2 Specific Objectives
 Study the existing system and find out the problem.

 Find the solution for the problem found in the existing system.
 Requirement analysis of the system.
 Design and build a particular model of this proposed system.
 Develop a system and implement the new billing management system for Jigjiga city.
 Test the developed prototype and test if it fits to the needs of the organization.
1.4 Scope of the Project

The scope of this project is developing web based customer billing management system for
Jigjiga city water service from adding customer to the system to collecting monthly payment and
particularly focuses as follows:
 Customer registration and retrieval.
 Customer detail update.
 Bill calculation and Pay bill.
 Generating reports of bill.
 Check payment of customers.
 Set penalty.
 Bill maintenance.
1.5 Limitation of the project
Since the system need some media to conduct transaction in this project every transaction will be
passed via internet. The other limitation of the project is:
 Our system doesn’t support other payment system which is only included CBE.
 There is no android based.
 Support only English language. Because of the following reason:
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.
1.6 Methodology of the Project

1.6.1Data Collection Methodology
As we know there are different methods to collect information. From those we use the following
tools and methods respectively to collect data from the organization.
Literative Review: Document exploration is the process of going through a number of literature
works that have been conducted by other authors and organizations or researchers to review their
thoughts, ideas, and opinions towards a particular subject. In general, what they have achieved
with their previous work. During the analysis of documents, we give a special consideration to
those documents which can bring more features to the project.
Observation: Observation is the other instrument that we used to collect data which was
necessary for our web based system project for the organization. In this process we tried to
investigate the information by making our selves participates in the process. And observations
will also help us to relate the information obtained from the interview by looking to the reality of
the system. We observe the present paper based and desktop system has a lot of limitations such
as: time, manpower, readiness of customer details etc.
Document analysis: Manually collected files will be analysis for collecting information. Internet

and some researches we used as sources to collect information related to this project.
Interview: We interview some employees of the organization as well as the customer about their
existing system functionality, their problems and background.
 To develop a deeper understanding of the data resources used by the system.
 To know what the current level of system usage by the office.
Questionnaires: The questionnaires contain predefined questions that help us to gather
important information and give us some perspective from different angle. It will be spread to
customers, stakeholders and bill staff members and managers. This helps us to know more
information about how much they want the system and in which way did they want the system to
be designed.
1.6.2Analysis of the System and Design Methodology
Here there is two phases to design and analyze the system. These are: Object Oriented Analysis
(OOA) and Object Oriented Design (OOD):
We select these methods because of the following important features:
 Reduced software maintenance cost.
 Increased reusability.
 Increased consistency.
 Improved quality.
 Financial benefit.
 Increased extensibility.
1.6.3 Development Environment Tools
In our project, the following programming system will be using:

 WAMP Server: manage our servers setting.
 HTML: The html language has designed to an effective way of achieving this
transferring of data and has designed to be evolving as new media format was created.
We use html to develop our statically parts of our code. We use because of html is
compact and effective language.
 MySQL server/Apache/PhpMyAdmin: for designing the database.
 PHP and HTML: To Design web interface of buttons, links and other web controls
(interface controls).
 JavaScript: JavaScript is very interesting language used to validate data and develop
different messages. We use it to validate our data that we use in html code.
 CSS: for formatting of the web site.
 HTTP
1.7 Significance of the project

The main Significance of this project as it is computerized web based system; it minimizes the
customers losing time when they want to access service from the organization. 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.
 Reduce material loss.
 It increases performance of the organization.
 Enhance employee morale of the organization by providing quality service.
 Improves the confidence of the system users.
1.8 Risk Assessment and Management

 Shortage of Time. We managed it by using additional time from our rest time.
 Virus can attack our project. We use antivirus to manage this problem.
 Damaging the computers that we work on. We try to manage by using backup by using
external hard disk.
 Unavailability of internet also another problem here as a solution we will use other
reference material.
 Power fluctuation problem. By using laptop that has high power packups are used.
1.9 Operating environment

To develop the proposed system, the following tools will use during the various stage of the
project life cycle.
1.9.1Hardware environment
 Desktop computer: for overall operation.

 Laptop computer: as alternative use.
 RAM: 2 GB and above.
 Hard disk: 500 GB and above.
 Monitor: CRT or LCD monitor.
 Keyboard: Normal or Multimedia.
 Mouse: Compatible mouse.
 CD or flash disk.
 Printer.
1.9.2 Software environment
 PHP Script: as a Front end application.

 MySQL Database: as a Back end application.
 Microsoft office 2013: for the documentation part of the project.
 Sniping tools: as print screen.
 Dreamweaver: for designing user interface and writing the codes.
 Edraw UML Diagram (Visual Paradigm): For designing UML diagrams
associated with the project.
 Adobe Photoshop: for editing photos.
 Notepad++/Notepad/PHP editor: for designing web interfaces.
 Browser: Any latest browser.
 WAMP (Windows, Apache, MySQL and PHP server).
1.10 Feasibility study

It investigates 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.10.1Technical 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, and MySQL. Team members have the required skill to develop the system, so that
the project can be said technically feasible.
1.10.2Schedule Feasibility
The project system can be efficient after it has been developed. Our system can perform any
activity in the efficient way. In the existing system take a lot of time to perform one activity.
Project Schedule
Time Schedule of the project 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.
Gant chart of project schedule

No Feb2
Dec22- Jan11- 3- Dec- Jan-
Task Novem Decemb Jan10 Feb22 Mar 2020 2021
er 30
ber

1
Title selection
2
Proposal
submit
3 Requirement
analysis
4 Object design
document
5 System design
document
6 Implementation
7 Testing and
maintenance
Table 1. 1: Gant chart of project schedule
1.10.3 Operational Feasibility
This system brings better achievement for the operations performed by the office by Providing
efficient registration and storage of customer’s information, easy updating, deletion,
modification etc. This intern increases the efficiency of work in the office. So that one can say
that the system is operationally feasible.
1.10.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.10.5 Economic Feasibility

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.
 Intangible benefits: Our system will provide intangible benefits such as:
 Increase accuracy.
 Boost employee morale.
 Fast decision making from reports.
 It minimizes the work load of the employee.

 Tangible benefit: Our system will provide tangible benefits such as:
 Error reduction.
 Material consumption reduction.
 Increase speed of activities to the system.
Cost break down
The whole budget of manipulating system will be required the following items with their
corresponding price to use. This much amount of money would require for finishing the project.

Tools Item Quantity Estimated Unit Estimated
cost in birr Total Cost in
Birr
Hardware Paper 3 packet 120 360
Tools Pen 6 10 60
Flash 1 360 360
Personal computer 1 20,000 20,000
Printing 3 150 450
Total cost 21095
Table 1. 2: cost break down
1.11 Document Organization

In our project proposal we cover four chapters. In first chapter we have studied the background
of Jigjiga city water billing service office and its problems or limitations that are faced to the
users. We distinguish objectives of our project as general and specific objective. Depending of
the objectives of the project we put scopes of our proposed system. Here we use methodologies
such as data collection methods, analysis of the system and design, significance of the project,
risk assessment and management, operating environment as hardware and software environment,
document organization and we analyses feasibilities. In chapter two we studied about the current
system of description of the current system, main activities, function of the existing system,
players of the existing system, and report generating in the existing system, documents used in
the existing system, strength of the existing system, weakness of the existing system and
alternative solution. In chapter three we study about the requirements specification and analysis,
objective, product perspective, product functions, principal actors, user characteristics, general
constraints, assumption and dependencies, functional and nonfunctional requirements and system
models. In chapter four we study about system design, design goals, system architecture,
subsystem decomposition, components diagrams, deployment diagrams, persistent data
management, access control and security, and user interface design.
CHAPTER TWO
2. DESCRIPTION OF THE EXISTING SYSTEM

2.1 Introduction
This chapter deals with analyzing the general work flow of the existing system, players in the
existing system. It produces a broad outline of the proposed system that identifies the function to
be performed and the technical aspect that the system must fulfill and briefly describes the
existing system functionality, problem of the existing system, document in the existing system,
report generated in the existing system, alternative solutions suggested to overcome existing
system, the strength and weakness 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.
2.2 Main activities

 Customer registration manually.
 Meter reading.
 Bill calculation manually.
 Bill payment manually.
 Customer penalty manually.
2.3 Function of the Existing System

The functions of Jigjiga city water billing service office are the following:
 New customer registration manually.
 Reading meter manually.
 Collecting money from the customers is performed every month and customers they
attend every month at the organization.

2.4 Players of the existing system
The existing system has the following actors like:
 Customers: are the users of water service.
 Cashier: is a person who collects money from customers.
 Meter reader: is a person who reads the amount of water service.
 Bill officer: is a person who calculates the amount of water service which read by meter
reader.
 Administrator: is a person who controls over all activities of the organization.
 Record officer: is a person who manages the customer files manually.
2.5 Report Generating in the existing system

In order to control and manage over all activities of the organization, report must be generated.
To achieve its objective reports are generated weekly, monthly and annually. These reports
indicate performance of the services and are used to change how the organization works to
improve its performance time to time. These reports can be generated by the employee for
submission to the manager. The following data are used to generate the reports.
 Number of new customers applied for service weekly.
 New imported meter for new customers monthly.
 Imported cash from bill monthly.
 Annual task performance of organization.
2.6 Documents used in the existing system

There are a number of forms and documents which are used by the existing system. Contract for
billing 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, application
tariff, purpose of water is to be bill, deposit birr, connector birr, total, receipt, customer sign and
authority sign. The uses of these forms are to assure the correctness of their activity and to
generate reports. In addition to this, these forms are used to increase the relationship with
customers in such a way that customers can believe the paid amount of each month for water
service.
The following table shows current tariff of water consumption
Number Consumption Tariff/Birr
1 From 0- 5 m3 2_2.75
2 From 5.1 - 10m3 3.75
3 From 10.1 -21m3 6.10
4 From 21.1 m3 and above 9.63
Table 2. 1:Water consumption table
Figure 2. 1: Form of receipt the existing system
2.7 Weakness of the Existing 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).
 Materials registration, viewing information etc.
 Time consuming when registered as a customer of the company.
 Time consuming to prepare a bill.
 Input (Inaccurate/redundant/inflexible) and Output(Inaccurate)
 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.
2.8 Strength of the Existing System

There are activities that are considered as strength of the existing system; does not required
computerized skill, the manual documents does not damaged by virus.
2.9 Alternative Solution

 The important thing is to make works easy.
 Customer billing management system for water service is the system must fulfill the
requirement of giving effective services in terms of speed, accuracy, response time,
efficiency; reduce man power and time, etc.
 The proposed system stores all the information about billing at one center place for all
on the database other than store separately.
CHAPTER THREE
3. Requirements Specification and Analysis

3.1 INTRODUCTION
Requirement is a major base for better solution or for solving problem, which exists in the
current system by gathering requirement. Requirement gathering is a way of collecting
information to improve or change the existing system by the new system.
The new system is based on the interest and understanding of the customers. The sequence of

activities, which has performed in the existing system, also affects the development of new
system.
3.1.1 Purpose
Analyzing the current system and making requirement determination helps to develop a system,
which is necessary information about water billing management system.
The purpose of the software requirements specification (SRS) document is to maintain functions
in intranet based Jigjiga city water billing management system.
3.1.2 Intended audience and reading suggestions
Since we are developing web based customer billing management system for water service ,
more concern has given for the users that are customers of the Jigjiga city. So that we have
prepared and presented the existing system workflow and the optional analysis of our proposed
system and we get the following suggestions from the customers:
The proposed system is:

 Decrease the wastage of time.
 Introduce to the new technology.
 It is sophisticated.
Beside customers, we have also talked about our proposed system with the organization
administrator, manager and some employees. They have given the following suggestions,
the proposed system is:
 Easy to bill and work with.
 Efficient because the proposed system reduce redundancy and inaccuracy.
 It is easy to manage customer and officer.
3.1.3 Document convention
ADMIN…………………………………...Administrator
CBMSFJCWS……………………………..customer billing management system for
Jigjiga city water service
JCWSO………………………………....Jigjiga city water service office
DB ………………………………………Database

HTML……………………………………Hyper Text Markup language
HTTP…………………………………….Hyper Text Transport protocol
OOA……………………………………...Object oriented analysis
OOD……………………………………...object oriented design
OOSD…………………………………….object oriented system development
PHP ………………………………………Hypertext Preprocessor
SQL………………………………………Structured Query Language
SRS………………………………………Software Requirement Specifications
UC ………………………………………Use Case
UI ……………………………………….User Interface
UML ……………………………………Unified Modeling Language
CBE……………………………………..Commercial bank of Ethiopia
3.2Objective
The requirement specification is the phase that leads to the designing and implementation, that
the correct and accurate designing has a great role to the system implementation. Based on this
designing, our target providing the automated system to the web based water billing management
System can be attained with the rapidly developing technologies. These leads to a correct
designing method.
3.3 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 should search the customer file from the database.
 The system should perform customer registration online.
 The system should calculate the amount cost for service accordingly with recorded data
by meter reader.

 The system should accept the amount of water consumption data that enter by meter
reader.
 The system must allow the customers to transfer the cost payment from customer bank
account to organization account.
 The system should update the database of each customer after payment.
 The system should display confirmation message whether actors do their task
successfully or not.
 The system should have well organized information storage and accessing mechanism.
 The system should allow to the administrator to create, update and delete user accounts.
 The proposed system should have authentication system for Administrator, Bill officer
and Customer.
3.4 Product perspective

The product of the system indicates the final output of the proposed system that is Jigjiga city
customer water billing management system, which aimed to give different access to the users of
the system; these are manager of the organization, employees, administrator, and customers. The
network administrator will be responsible to create and maintain the accounts of the customers.
By using the created account, users can obtain information about the billing. Furthermore, the
water billing management system can perform update, delete, and insert customers account as
needed and our database is safe and secure.
3.5 Product Functions

Our system can help the users to maintain the integrity of the generation of water bill.
The proposed system will expect to have the following functionalities.
 Create account for bill officer by using employee id number.
 Create account for customers by using their id number.
 Search any information from database to update the customer’s record from database.
3.6 Principal Actors

An actor represents anything or anyone that interfaces with your system. This may include
people, external systems, and other organizations. Actors are always external to the system is
being modeled. The actors of our proposed system are:
 Administrator
 Customers
 Bill officer
3.7 User characteristics

User characteristics are about people who are going to use the system. Users of the system are
customers, employees, administrator and the manger.
3.8 General constraints

The constraints that raises for the proposed system are:
 All operations are in English. So, user must have basic knowledge of English.
 Customers cannot delete or update any records from the database.
 The user must give and assign each user a unique user ID and password
 Normally Jigjiga city use manual billing activities. Automating this all with short period
seems to be difficult. Therefore, it takes more time to be automating.
 The other risk is the price of materials may arise and fall. Therefore, budget may modify
in negotiation. In addition after implementation, if the software fails to run how to fix is
negotiable.
The main risk during the development of the project, is securing the project from unauthorized
access. To overcome such risks we are going to develop a password protection method that gives
access to authorized persons only. The other is data loss, which has caused by virus infection. To
prevent this problem, virus and worms infection, we will install a current updated antivirus. In
addition to installing the updated antivirus, we will take back up of our documents.
3.9 Assumptions and dependencies

 The users have some minimal knowledge of English language.
 The customers, employees and manager must have valid user name and password.
 Administrator has full privilege on the system.
 To use the product, the internet connection needed.

3.10 Nonfunctional Requirement
The non-functional requirement of the system deals with how will the system provides service to
the user.
Nonfunctional requirement is a requirement that specifies criteria that can be used to measure the
performance of a system, rather than specific behaviors. Nonfunctional requirements define how
a system is supposed to be performing activity. Nonfunctional requirements are often called
qualities of a system. Other terms for nonfunctional requirements are constraints, quality
attributes, Quality goals and quality of service requirements. Qualities that are nonfunctional
requirements can be main categories:
System performance
 Performance:
 Easy to use: unlike manual the web based is easy to use because it is
just pressing a simple and single keys or symbols.
 Fast and reliable: - since the data is stored and accessed electronically,
like that of manual it cannot be failed always and Serve users efficiently.
 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 customer billing
management system for Jigjiga city water service 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.
 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.
 Speed: it will let the employers to access the needed information quickly
 Cost: it minimizes the cost i.e. reduces wastage of man power, wastage of money during
advertising and reduces consumption of resource to maintain
 Error handling: the system must handle the error and should display error message if
the user inputted the characters that are mismatched to corresponding data types.
 Security: Provide authentic and authorized features to the proposed system where private
and confidential data can only be viewed by authorized user
 Maintainability: To ensure that the system continues to work properly by checking it

regularly and making repairs and adjustments if required.
3.11 System Models

3.11.1 Use case models
Use case model describes the interactions between the users and the system, and the required
behavior of the system in satisfying these goals. A use case model consists of a number of model
elements. The most important model elements are: use cases, actors and the connector between
them.
The actors of our proposed system are:
 Customers: are users of the system that has been registered and those that are
consuming of water utility.
 Bill officer: is a person who is responsible for things that are related to the bills. He/she
prepares bills, calculates penalty and manage the bills and generate bill reports.

 System admin: is the administrator for the systems and its main function is to manage
the database and manage accounts of users.
The following are the use cases that will include in web based customer billing management
system for Jigjiga city water service.
 Login
 Manage account
 prepare usage bill
 set penalty
 Generate report
 Manage bill
 View usage bill
 Request bill maintenance
 View bill maintenance request
 Give feed back
 View feed back
 Pay bill
 Log out
 Signup

Figure 3. 1: use case diagram
3.11.2 Use case description for the proposed system

Table 3. 1: Login use case description
Use case ID UC1
Use case name Login
Participating actors Customers, administrator, bill officer.
Description This is a use case to let authenticated users to
access the system functionality.
Pre-condition The user must be already registered or the
user must have user name, password (user
account)
Basic course of action 1. The user selects the login menu.
2. The system display the login page.
3. The user enters his/her user name and
password.
4. The user click on login button.
5. The system cheeks the username or ID and
password entered.
6. The system forwards the user to his/her
page.
7. End of use case
Alternative actions Step 5.1, If the identification is not correct

the system display incorrect user type, user
name and password try again message and
the system display the login page. The
system give chance to try again.
Post condition The user is authorized to perform an action.
Or logged in to the system.
Table 3. 2: Change password use case description

Use case ID UC2
Use case name Change Password
Participating actor All system users
description This use case helps the user when it is necessary to change
login password.
Entry condition user login to the system
Flow of event 1. User selects change password menu.
2. The system display change password form.
3. User fills all the required information and hit the change
button.
4. The system change the password and save the new password
5. The system acknowledges that password is changed
successfully
6. end of use case
Alternative Flow of event Step 3.1 If user enters wrong the system display message in
order to correct wrong information.
Post condition New password is saved
Table 3. 3: Prepare bill use case description

Use case ID UC3
Use case name Prepare usage bill
Participating actor Bill officer
description This is a use case for calculating the usage bill in order to let
customers pay their monthly utility usage bill.
pre-condition The bill officer should login to the system And should retrieve
the utilization value inserted.
Basic course of action 1. Bill Officer chooses the prepare bill menu.
2. Selects the bill he is going to prepare.

3. Bill Officer search for customer and usage month.
4. The system display information of the customer and monthly
usage record.
5. Bill Officer fills other required additional information for the
bill.
6. click the calculate button
7. System calculates the monthly usage bill of the identified
customer.
8. The system displays a message “monthly usage bill for
customer is ready ”
9.End use case
Alternative course of Step 4.1 If the customer whom the bill is preparing for is not
action available in the database the system displays “customer account
not found” information.
Post condition Customer usage bill is prepared
Table 3. 4: Prepare bill use case description

Use case ID UC4
Use case name Set customer bill penalty
Participating actor Bill officer
description This is a use case for calculating the customer penalty because
of delay of customer bill payment.
pre-condition If customer does not pay for his/her monthly usage bill within
the specified payment day intervals. In order to calculate the
penalty, bill officer must be logged in to the system.
Basic course of action 1. User selects the set penalty menu.
2. User selects the bill button.
3. Extract for the bill that has not been paid.
4. The system displays information of the monthly usage bill
that has expired or not been paid.

5. System displays the monthly usage bill of the identified
customer and its additional calculated penalty.
6. The system displays a message “penalty has been set”
7. End use case
Alternative course of Step 3.1 if there is no unpaid bill system displays “such file
action does not exit”
Post condition Penalty is set to the customer usage bill
Table 3. 5: View usage bill use case description

Use case ID UC5
Use case name View usage bill
Participating actor Customer
description This is a use case for customers to view or see their monthly
utility usage bill.
pre-condition Customer should log in to the system.
Basic course of action 1. User selects monthly utility usage bill from the menu bar.
2. User selects the view usage bill button.
3. User clicks view my monthly usage bill button.
5. The system displays the customer usage bill.
6. End of use case.
Alternative course of Step 5.1 If there is no bill prepared with that customer
action information. The system displays a message “no bill for this
customer”
Post condition Customer utility usage bill is displayed.

Table 3. 6: Give feedback use case description
Use case ID UC6
Use case name Give feed back
description This is a use case for customers to give feedback about the
overall system.
pre-condition Customer login to the system
Basic course of action 1. User selects the feedback menu.
2. The system display customer feedback form.
3. The user fills the feedback form.
4. User clicks the submit button.
5. The system saves and displays an acknowledgement
successfully submitting comment.
6.End use case
Alternative course of Step 5.1 .if the information filled on step 3 is not valid system
action displays a massage” comment not successfully submitted”
Post condition Customer comment is submitted.

Table 3. 7: Request Bill Maintenance Use case description
Use case ID UC7

Use case name Request Bill maintenance
description This is a use case for customers to request Bill maintenance
whenever there is uncertainty and the customers have more or
less meter reader values from his/her usage on bill.
pre-condition Customer login to the system.
Basic course of action 1. User selects the request maintenance menu.
2. The system display maintenance request form.
3. The user fills the form.
4. User clicks the submit button.
5. The system saves the maintenance requests.
6. System displays a successful message.
7. End use case.
Alternative course of Step 6.1 If the information filled on step3 is not valid system
action displays a massage” Maintenance request not successfully sent”
Post condition The bill maintenance request is sent.

Table 3. 8: View Bill Maintenance Request Use case description
Use case ID UC8
Use case name View Bill maintenance Request.
Participating actor Bill Officer
description This is a use case for bill officer to view Bill maintenance
requests that has been sent by customers.
pre-condition Bill Officer login to the system.
Basic course of action 1. User selects the bill menu.
2. User selects the view maintenance request button.
3. The system displays the requests from the database.
4. The user views the requests.
5.End use case
Alternative course of Step 3.1 If there is no request the system displays a massage
action “there is no Maintenance request”
Post condition Bill officer sends the bill maintenance request.

Table 3. 9: Pay Bill use case description
Use case ID UC9
Use case name Pay Bill
Participating actor Bill Officer
description This use case gives information about paying money for
customer usage.
pre-condition Customer must have account and also there must have enough
balance on his/her account to do payment.
Basic course of action 1. The customer select pay bill menu.
2. The system displays the user to bank account page.
3. The customer will fill required information.
4. The system checks whether the information filled are
correct or not.
5. System displays the payment form that filled with
the required information’s.
6. Customer selects pay button.
7. System takes payment and reduces that much
amount from account.
8. The message “pay successfully” is also displayed.
9. End use case.
Alternative course of Step5.1 If information is invalid System displays bank page.
action
Post condition Customer pays money.
Table 3. 10: use case description for customer signup

Use case ID UC10

Use case name Signup
description This use case leads customer to register their own information
in order to get either three services.
pre-condition Customer must have either of three services to do register.
Basic course of action 1. The customer opens the system.
2. Customer select signup button.
3. The system displays the registration form to the
customer.
4. The customer fills required information on the form.
5. Customer hit the register button.
6. Customer information stored on database.
7. The message “register successfully” is also
displayed.
8. End use case.
Alternative course of -
action
Post condition Customer make register
Table 3. 11: Logout use case description

Use case ID UC11
Use case name Logout
Participating actor All system users.
description After finishing their task each user must be logout of the
system.
pre-condition User login to the system.
Basic course of action 1. User wants to logout.
2. User click logout button.
3. System logout the user.
4. End use case.
Alternative course of -
action
Post condition User Logged out.

3.11.3 Sequence diagram
Sequence diagrams show the interaction between participating objects in a given use case.
In this diagram the project team has shown the interactions between objects in the sequential
order and defined event sequences that result in some desired outcome.
Figure 3. 2: Sequence Diagram for Login

All the system users open the system and the system display the login page. Then the system user
fill the login form fields and the system validate the users input, the user click the login button,
the login form creates the login form controller which allow to execute the users input from the
database, the systems database validate the users Identification and return the result to the login
controller. Login controller validates the result and displays their page to the user. Then the
system user work on their own page whatever they want to do.

Figure 3. 3: Sequence Diagram for Change Password

Figure 3. 4: Sequence Diagram for Prepare Bill
This sequence diagram shows the steps how the bill officers follow to prepare customers
monthly utility usage bill. To prepare bill the bill officers must login. The bill officer open the
system and fill the login form field , click login button, then the system display bill officers home
page. When the officer wants to prepare bill, the bill preparation page is activated and bill officer
fills the required information on their bill preparation form and click the submit button. The bill
officer lets the system to save the bill. Finally bill for customers will be successfully prepared.

Figure 3. 5: Sequence Diagram for Set Penalty

Figure 3. 6: Sequence Diagram for Generate Report

Figure 3. 7: Sequence Diagram for View usage Bill

Figure 3. 8: Sequence diagram for Give Feedback

Figure 3. 9: Sequence diagram for request bill maintenance

Figure 3. 10: Sequence diagram for View Bill maintenance requests

Figure 3. 11: sequence diagram for pay bill use case

Figure 3. 12: Sequence diagram for signup use case
3.2 Class diagram

The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. It represents the properties of entities, their operations and relationships.
Generally the project is including the following class in the class diagram the over view of the
class diagram is:
Figure 3. 13: Class Diagram for the proposed system
3.4 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow from one activity to
another activity. The team member has tried to describe operations of the system using the
following Activity Diagrams.

1. Activity diagram for Users(System admin, Bill Officer, Customer )
Figure 3. 14: Login Activity Diagram

2. Activity diagram for Bill Officer prepare bill

Figure 3. 15: Activity diagram for Prepare Bill
3. Activity diagram for Bill officer to Set penalty

Figure 3. 16: Activity diagram for set penalty
4. Activity diagram for Bill officer to Generate report

Figure 3. 17: Activity diagram for Generate Report
5. Activity diagram for Customer to View usage bill

Figure 3. 18: Activity diagram for View Usage bill

6. Activity diagram for Customer to Give feedback
Figure 3. 19: Activity diagram for Give Feedback

7. Activity diagram for Customer to Request bill maintenance
Figure 3. 20: Activity Diagram for Request Bill Maintenance

8. Activity diagram for Customer to Signup
Figure 3. 21: Activity diagram for customer signup

CHAPTER FOUR
4. System design
4.1 Introduction
System design is the process of defining and developing a system to satisfy specified
requirements of the user. Designers in all disciplines draw on fundamental design concepts and
principles. This document describes the requirements for developing of Customer Billing
Management System for Jigjiga City Water Service.
4.2 Design Goals

The goal of this project is to develop Customer Billing Management System for Jigjiga City
Water Service, based on the meter reader input water consumption to view the bill officer.
Design goals describe the qualities of the system that developers should optimize. The following
are the qualities that our system should focus on.
 Performance criteria
 Maintenance criteria
 End user criteria
4.2.1Performance Criteria
The web based customer billing management system for Jigjiga city water service should
respond fast with high throughout, i.e. it should perform the tasks of system quickly. i.e.
 Response time, the speed imposed on the system. The system should responsive
maximum number of tasks with minimum times.
 Number of tasks accomplished in a fixed period of times.
 Memory space available for speed optimizations should be used efficiently.
4.2.2Maintenance Criteria
Web based Customer Billing Management System for Jigjiga City Water Service design is easy
to maintain, and this reduces the system’s maintenance costs, which usually represent a high
proportion of the total lifetime cost of the system. Since flexibility is about change, then if the
system flexible it is also maintainable.
When we say the system is maintainable, we mean it can be maintained easily when changes
arise from the user and designer/developers. We prepare full maintenance document and attach
with the web content then the end user can maintain the fall of the system easily by using the
maintenance manual or document.
4.2.3 End User Criteria
This is to mean that users of the system after the completion of the system, how the system is
used in friendly manner for both the experienced and inexperienced users using the user
interface.
4.3 System Architecture

The proposed system will be implemented in Client/Server architecture. The proposed system
will have three tier client-server software architectures.
Figure 4. 1: Proposed system Architecture Design

4.4 Subsystem Decomposition
Subsystem decomposition is needed to make the system clear and understandable by dividing the
whole system in to subsystems and components. In the subsystem decomposition we try to show
the relationship between each component.
Figure 4. 2: Decomposition of JWSO
4.5 Components Diagrams

In this part the project team members try to identify components of the system and design the
association between the specified components.

Figure 4. 3: Component Diagram
4.6 Deployment Diagrams (hardware and software mapping)

This diagram represents the deployment view of a system. So, the system component diagrams
and physical hardware’s used to deploy the application represented on this diagram.

Figure 4. 4: Deployment diagram
4.7 Persistent data management

Persistence models also called data model or Entity relationship (ER) models, are used to
communicate the design of a database, usually a relational database, to both users and other
developers. Persistence are used the schema of database. The strength of persistence models is
that data entities are conceptually the same as the table of relation database and that attributes are
the same as table columns.

Figure 4. 5: persistence diagram
4.8 Access control and security

The access control shows who can access which class in the system and we describe it by using
access control matrix.
Table 4. 1: Access Control and Security
Class System Bill Officer Customer
admin
Login Login() Login() Login()
Create Create User - Create New
Account Account() User Account
Update Update - -
Account Account()
Delete Delete - -
Account Account()
Change Change Change Change
Password Password() Password() Password()
Feed value - Feed value -
View feedback View - -
Functionality
feedback()
Prepare Bill - Prepare Bill() -
Set penalty - Set Penalty() -
View Bill - View Bill -
Maintenance maintenance
request request()
Add newsfeed Add - -
newsfeed()
Pay bill - - Pay bill()
View Usage - - View Usage
bill Bill()
Request Bill - - Request Bill
Maintenance Maintenance()
Give Feedback - - Give
Feedback()
Signup - - Signup()
4.8.1 Boundary condition
The users should have a valid phone number, address and email for a member of the Jigjiga
water service office organization. The water service is allowed to only a person or any
organization that takes an agreement between the JWSO and them. So, every user has his/her
own user-type, user name and password and they have their own responsibility.
 System administrator can perform such activity create, update, delete and search user
account.

rgiveout
custome
admin
system
sign
setpenality
pay
reset
prepare
officer
bill
account
generate
request
maintenance
view
password
change
manage
check
log
login
d
clu
in
<
<<include>>
bill
feedback
up
usage
reports
feedbacks
password
payment
bill
bill
user
bill
report
bill
 Bill officer can do record meter reading, calculate bill, prepare bill, manage bill, view
payment, view maintenance request, set penalty.
 Customer can request bill maintenance, view usage bill, bill pay, give feedback.
4.8.2 Exception handling
 The system will display messages if it is accessed using wrong/invalid account by

checking using from the account table.
 The system can display error message when user inserts invalid data.
 If unauthorized users try to access the system, the system can control from accessing.
 Users only visit the authorized responsibility.
 Users can insert system support insertion otherwise their activity is invalid.
4.9 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.
Figure 4. 6: user interface for Login page

Figure 4. 7: user interface for admin page
Figure 4. 8: user interface for Create Account

Figure 4. 9: user interface for Payment record
CHAPTER FIVE
5. System Implementation and Testing
5.1 Implementation
Implementation refers to the Coding of the all documents gathered starting from requirement
analysis to Design phase. So now the team is in a position of converting all documents gathered
and designed into the code so that the system will be implemented for the user to be used for the
purpose it developed. To implement it the user must have a server on which the system will be
hosted because this system can run on intranet site with connection available or on internet
connection.
5.2 Sample code and their screen image

5.2.1 Home Page
Home page:-This pace is found on the main of Jigjiga billing system it contains some links
about us, contact us, signup and login page. The user view the page and he/she get login page
and can select it from the menu.
Figure 1: user interface for CBMSWS
Steps to follow to use the interface:

1. Type Home Page URL in address bar of web browser
2. The page will be displayed because it is default page.
Code for home

<! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/2020/xhtml" xml: lang="en">
<head>
<title>water billing system</title>
<meta name="description" content=" utility water billing system" />
<meta name="keywords" content="why we be inline when we can be online” />
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<div id="logo"style="width: 900px; height: 115px;">
<img height="115" src="images/billpay.png" width="100"/>
<img height="115" src="images/h22.PNG" width="790"/>
<div id="navigation">

<div align="left"><a href="index.php">HOME</a></div>
<div align="left"><a href="aboutus.php">ABOUT US</a></div>
<div align="left"><a href="contactus.php">CONTACT US</a></div>
<div align="left"><a href="signup.php">SIGNUP</a></div>
<div align="left"><a href="index1.php">LOGIN</a></div>
</div>
<div class="ws_images"style="width:890px;height:550px;"><ul>
<div class="show">
<li><img width="880" height="400" src="images/all.PNG" /></li>
</div>
<div id="footer">Copyright © 2020 | www.CBMSWS.com</div>
</body>
</html>
Login Page
This page found on the link of home page. The user must have user account or username and password to
login to the system.
Steps to follow to use the interface of login:

1. Click login page
2. Enter username and password.
3. Select the type of services provided by billing system.
4. Click login button to login to the system.
Signup Page
This page found on the link of home page. The user must click on link and user have going to register
his/her detail required information to login to the system after successful registration.
Steps to follow for use the interface signup new users:
1. The customer select signup link.
2. Fill appropriate information of customer.
3. Click on the register user button.
5.3 Test Approach

The team members develop testing plan to describe how the water utility billing system will be tested to
check whether this project satisfies the intended functionality without any bugs or errors by using both
black box and white box testing method. The Jigjiga water billing system will be tested manually by the
developers and users.
5.3.1 Integration Testing

In this level of testing we have examined how the different procedures work together to achieve the goal
of the sub system. The type of integration testing that we have followed is bottom up. Since utility water
billing system is a web based application each and every access is depend on hypertext transfer protocol
(HTTP). So we integrate each component from single functionality (individual interface) to the main
function incrementally step by step through link tag by using test driver.
 Patterned the interaction between separate functionality which performs the exact tasks.
 Estimate the functionality of subsystem after combination all separate functionality.
 Identify the independency of each subsystem with other subsystem.
5.3.2 Unity Testing

Verification (A set of operations that the software correctly implemented a particular function) on the
smallest element of the program i.e. the modules are tested alone in order to discover any error in the
code.
Test case
Here we have designed a test case for some of our interfaces.
Test case for login

Table 1: test case for login
Test Case #:1.1
Test case Name: Login
System: Login
Designed by: all members
Executed by: All user
Short Description: Test the login Accessibility or check Authorized person
Pre-conditions
The user has a valid User Name and Password. The user has accessed the page by entering the correct
User Name and Password.
Post condition
The user can access the main page.

Test Case for change password
Table 2: test case for change password
Test Case #:1.2

Test case Name: Change Password
System: Password
Designed: all members
Executed by: Admin, Employee
Short Description: Test the change current password
Pre-conditions
The user has a valid User Name and Password before.
The system displays the main page.
Post-conditions
The New password is store in database.
COMPUTER SCIENCE 4TH YEAR 2020 G.C
71
CHAPTER SIX
6. Conclusion
The system that we have developed has three phases; the first phase deals with the analysis phase
of the life cycle with the organization, and the next phase addresses the design phase and third
phase deals about the implementation. As the end of the first phase, we need to review what we
have planned at the beginning. We began our work by identifying the significance of the new
system for Jigjiga city and customers. This concerned defining the system development
methodology, identifying process and resource, and setting the deliverable and scheduled for the
project. The flow of analysis helps the team to understand the major functional areas and
processes of the proposed system. Through this flow, we identified the weakness and strength of
the existing system by developing the proposed system. After that, we discovered system
requirements. Through this phase, we identify functional and non-functional requirements of the
new system. Then we have undertaken a major phase in system development process: object
oriented Analysis. Here, we tried to model the new system we proposed using UML diagrams:
Use case, sequence, and activity and class diagrams. Also, we designed the new system user
interface prototype. As a result, the project team proposed the new system to solve the problem
of existing system such as time management, security and good customer services. And also the
project team developed their capacity during working this new system so that the existing system
is enhanced by technology.
6.2 Recommendation
The system that the project team has develop is limited on only single category of customers Therefore,
we recommend the following features need to be included in any further revision and extension attempt.
- Online queue management.
- For those visually impaired customers, voice recognizing features.
72
Reference
[1] 1.5. (n.d.). Retrieved 03, 20, 2020, from www.tutorialspoints.com
[2] administrator, w. (2020, 6 09). Jigjiga University, 1.4. (Jigjiga university) Retrieved 03 20,
2020, from Jigjiga University web site: wcu.edu.et
[3] Pree, W. (n.d.). Object oriented development.
[4] pressman, R. (n.d.). Software engneering (Vol. v).
[5] Web Finance, Inc.( Retrieved November 16, 2020). Feasibility study.[online].Available:
http://www.businessdictionary.com/definition/feasibility-study.html.
[6] http://cybarlab.com/ooad .Advantage of ooad[Online Available],[December 20, 2020].
[7]ActivityDiagram.
[Online].Available:https://www.tutorialspoint.com/uml/pdf/uml_activity_diagram.pdf.
[8] Yaybe ICT solutions PLC ,”Consultancy Service For computerized Information systems development
,water billing and customers management system for Jigjiga water Supply and Sewerage Services”.,
9/1/2020.
73

Final Project Group

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Project Group

Uploaded by

Copyright:

Available Formats

JIGJIGA UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE: CUSTOMER BILLING MANAGEMENT SYSTEM FOR

Advisor: Chaltu Fita

Name Signature Date

1. Examiner 1 ……….. ……… ………… ……..…………...

2. Examiner 2 ……….. ……… ………… ……..…………...

3. Examiner 3 ……….. ……… ………… ……..…………...

4. Examiner 4 ……….. ……… ………… ……..…………...

5. Examiner 5 ……….. ……… ………… ……..…………...

2.5 Report Generating in the existing system...............................................................................................12

4.8 Access control and security....................................................................................................................59

YFigure 3. 1: use case diagram.......................................................................................................................21

Figure 3. 2: Sequence Diagram for Login......................................................................................................33

Figure 3. 3: Sequence Diagram for Change Password...................................................................................34

Figure 3. 4: Sequence Diagram for Prepare Bill............................................................................................35

Figure 3. 5: Sequence Diagram for Set Penalty..............................................................................................36

Figure 3. 6: Sequence Diagram for Generate Report.....................................................................................37

Figure 3. 7: Sequence Diagram for View usage Bill.......................................................................................38

Figure 3. 8: Sequence diagram for Give Feedback.........................................................................................39

Figure 3. 9: Sequence diagram for request bill maintenance.........................................................................40

Figure 3. 10: Sequence diagram for View Bill maintenance requests............................................................41

Figure 3. 11: sequence diagram for pay bill use case.....................................................................................42

Figure 3. 12: Sequence diagram for signup use case......................................................................................43

Figure 3. 13: Class Diagram for the proposed system....................................................................................44

Figure 3. 14: Login Activity Diagram.............................................................................................................45

Figure 3. 15: Activity diagram for Prepare Bill..............................................................................................46

Figure 3. 16: Activity diagram for set penalty.................................................................................................47

Figure 3. 17: Activity diagram for Generate Report.......................................................................................48

Figure 3. 18: Activity diagram for View Usage bill........................................................................................49

Figure 3. 19: Activity diagram for Give Feedback..........................................................................................50

Figure 3. 20: Activity Diagram for Request Bill Maintenance........................................................................51

Figure 3. 21: Activity diagram for customer signup.......................................................................................52

Figure 4. 1: Proposed system Architecture Design.........................................................................................54

YFigure 4. 2: Decomposition of JWSO...........................................................................................................55

Figure 4. 3: Component Diagram...................................................................................................................56

Figure 4. 4: Deployment diagram...................................................................................................................57

Figure 4. 5: persistence diagram.....................................................................................................................58

Figure 4. 6: Access Control and Security........................................................................................................59

Figure 4. 7: user interface for Login page......................................................................................................61

Figure 4. 8: user interface for admin page......................................................................................................62

Figure 4. 9: user interface for CreateAccount................................................................................................63

Figure 4. 10: user interface for Payment record.............................................................................................64

Table 1. 2: cost break down.............................................................................................................................10

YTable 2. 1:Water consumption table.............................................................................................................13

Table 3. 1: Login use case description............................................................................................................22

Table 3. 2: Change password use case description.........................................................................................23

Table 3. 3: Prepare bill use case description..................................................................................................24

Table 3. 4: Prepare bill use case description..................................................................................................25

Table 3. 5: View usage bill use case description.............................................................................................26

Table 3. 6: Give feedback use case description...............................................................................................27

Table 3. 7: Request Bill Maintenance Use case description...........................................................................28

Table 3. 8: View Bill Maintenance Request Use case description..................................................................29

Table 3. 9: Pay Bill use case description.........................................................................................................30

Table 3. 10: use case description for customer signup.................................................................................31Y

Table 3. 11: Logout use case description........................................................................................................32

YTable 4. 1: Access Control and Security.......................................................................................................59

1.1 Background Study of the Organization

1.2 Statement of the Problem

1.3 Objectives of the Project

1.3.2 Specific Objectives

 Study the existing system and find out the problem.

1.4 Scope of the Project