W Supply

WEB BASED CUSTOMER MANAGEMENT SYSTEM FOR WERABE CITY WATER SUPPLY SERVICE
WERABE UNIVERSITY
INSTITUTE OF TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
TITLE: WEB BASED CUSTOMER MANAGEMENT SYSTEM
FOR WERABE CITY WATER SUPPLY SERVICE
SUBMITED TO DEPARTMENT OF INFORMATION
TECHNOLOGY IN PARTIAL FULFILLMENT OF THE
REQUIREMENT FOR DEGREE OF BACHLER OF SCIENCE
INFORMATION TECHNOLOGY
By
Name Id_No
1 Kemeru Kelifa…………………………………………………NSR/0504/12
2 Bedada Regasa……………………………….………...............NSR/0172/12
3 Bariee Megersa…………………………………………………NSR/0168/12
Under Guidance of Mr. Negash Korsebo(MSc)
WERABE, ETHIOPIA
February,2023
I|Page
Approval sheet
This is to confirm that the project report entitled web based customer management system for
werabe city water supply service submitted to Werabe University, Institute of Technology
department of information technology in partial fulfillment of the requirement for the award of
the degree of Bachelor of Science in information technology is an original work carried out by
Kemeru Kelifa, Bedada Regasa, Bariee Megersa, under my guidance. The matter embodied in
this project is reliable and is genuine work done by the student and has not been submitted
whether to this University or to any other University /Institute for the fulfilment of the
requirement of any study.
Student Team Approval Form
Name Signature
Kemeru Kelifa …………………..
Bedada Regasa …………………...
Bariee Megersa ………………….
Advisor and department head Approval Form
Advisor Name Advisor Signature
---------------------------------------------- -------------------
Department Head Name Department Head Signature
---------------------------------------------- ---------------------
Examiner Approval Form
Examiner Name Examiner Signature
---------------------------------------------- ---------------------
---------------------------------------------- ---------------------
II | P a g e
ACKNOWLEDGMENT
First of all, we would like to thanks our almighty God for giving us strength and hope to do the
project from start to end. Next to we would like to thank our advisor Mr. Negash.K for his
effective guidance, direction, opinion, and any other helps which was created doubt and
confusion by giving brief explanation and right direction to do this project. Additionally, we
would like thank to our class students for their help and sharing their knowledge for us. Finally
we have thanks and prestigious for Werabe town water supply service office for spending their
golden time for us by giving the information which we need for our project especially Msr
Mohammad who give us necessary information regarding the organization working system.
III | P a g e
Table of Contents
List of Figure......................................................................................................................................... VII

List of Table ......................................................................................................................................... VIII
Abbreviations ........................................................................................................................................... X
Abstract ................................................................................................................................................... XI
Chapter One: Introduction ............................................................................................................................ 1
1. Introduction ............................................................................................................................................... 1
1.2. Background information of the Organization .................................................................................... 1
1.3. Background of The Project ................................................................................................................ 1
1.4. Statement of the problem ................................................................................................................... 2
1.5.Objective of the project ....................................................................................................................... 3
1.5.1.General Objective ........................................................................................................................ 3
1.5.2.specific objective.......................................................................................................................... 3
1.6. Feasibility Analysis ............................................................................................................................ 3
1.6.1. Technical feasibility ........................................................................................................................ 4
1.6.2. Economic feasibility ....................................................................................................................... 4
1.6.3. Operational feasibility ................................................................................................................. 5
1.6.4 Behavioral/Political feasibility ..................................................................................................... 5
1.6.5 Schedule feasibility ...................................................................................................................... 5
1.7.Scope of the project ............................................................................................................................ 5
1.8. Significance of the project ................................................................................................................. 6
1.9 Target Beneficiaries of the system .................................................................................................. 6
1.10. Methodology for the project ............................................................................................................ 7
1.11. Systems Analysis and Design Approach ......................................................................................... 9
1.11.1.Limitation of the Project ............................................................................................................ 9
1.11.2 Risks & contingencies ................................................................................................................ 9
1.11.3 Assumptions and Constraints ..................................................................................................... 9
1.12. Team composition ............................................................................................................................ 9
1.13. Time Table ..................................................................................................................................... 10
Chapter Two: Description of the Existing System...................................................................................... 11
2.1. Introduction of existing system ............................................................................................................ 11
2.2 Organization structure (if any) .......................................................... Error! Bookmark not defined.
2.3. Users of Existing System ................................................................................................................. 11
2.4. The major functions of current system ............................................................................................ 11
2.5. Existing System Workflow Structure .............................................................................................. 12
2.6 Report generated in the existing system(if any) ................................ Error! Bookmark not defined.
IV | P a g e
2.7 Forms and other documents of the existing system(if any) .............. Error! Bookmark not defined.
2.8. Bottlenecks of the existing system (using for example PIECES frame Work). .............................. 12
2.8.1. Performance (response time) .................................................................................................... 13
2.8.2. Security and control .................................................................................................................. 13
2.8.3. Efficiency .................................................................................................................................. 14
Chapter Three: Proposed System ................................................................................................................ 15
3.1. Introduction .......................................................................................................................................... 15
3.2. Product Overview ............................................................................................................................ 15
3.3. User class and characteristics ........................................................................................................... 16
3.4. Functional Requirements ................................................................................................................. 17
3.4.1. Performance Requirements ....................................................................................................... 19
3.4.2. Process Requirement ................................................................................................................. 20
3.4.3. Input related requirements ........................................................................................................ 20
3.4.4. Output related requirements ...................................................................................................... 20
3.4.5. Storage related requirements ..................................................................................................... 20
3.5. Nonfunctional requirements ............................................................................................................. 20
Chapter Four ............................................................................................................................................... 23
4.1. System models ..................................................................................................................................... 23
4.1.1 Scenarios ........................................................................................................................................ 23
4.1.2. Use Case Model ........................................................................................................................ 25
4.1.3. Use Case Model ........................................................................................................................ 27
4.1.3. Use Case Description ................................................................................................................ 27
4.1.4. Object model ............................................................................................................................. 37
4.1.4.1. Data Dictionary ...................................................................................................................... 38
4.2.Dynamic Model ................................................................................................................................ 41
4.2.1 Sequence diagram. ..................................................................................................................... 41
4.2.2 Activity Diagram........................................................................................................................ 46
4.2.3 State Diagrams ........................................................................................................................... 57
4.3.ER Diagram ...................................................................................................................................... 60
4.3.1 Mapping ..................................................................................................................................... 60
4.3.2 Normalizatio(1st-BNCF normal forms) ...................................................................................... 60
Chapter Five: System Design .................................................................................................................. 62
5.1. System Overview ............................................................................................................................. 62
5.2. Design Considerations ..................................................................................................................... 62
5.3. Design Goals .................................................................................................................................... 62
5.4. Design Trade-offs ............................................................................................................................ 62
V|Page
5.5. Architecture of the System............................................................................................................... 63

5.6. System Decomposition .................................................................................................................... 63
5.7. Hardware/Software mapping ........................................................................................................... 64
5.8. Persistent data management ............................................................................................................. 65
5.9. user Interface Design ....................................................................................................................... 66
New User Account Format ..................................................................................................................... 69
5.10. Object Design................................................................................................................................. 69
5.10.1. Interface documentation guidelines ........................................................................................ 69
5.10.2 Class interface .......................................................................................................................... 70
References ................................................................................................................................................... 72
VI | P a g e
List of Figure
Figure2. 1: : workflow diagram ................................................................................................................... 12

Figure4. 1: User case model ........................................................................................................................ 27
Figure4. 2: Object model............................................................................................................................. 38
Figure4. 3: Analysis level Class diagram ...................................................................................................... 41
Figure4. 4: Sequence diagram for login. .................................................................................................... 42
Figure4. 5: Sequence diagram for create account. ..................................................................................... 43
Figure4. 6: Sequence diagram for customer registration ........................................................................... 44
Figure4. 7: Sequence diagram for maintenance order ............................................................................... 45
Figure4. 8: Sequence diagram for delete customer information. .............................................................. 46
Figure4. 9: Activity diagram for login form ................................................................................................. 47
Figure4. 10: Activity diagram for apply registration ................................................................................... 48
Figure4. 11: Activity diagram for create account........................................................................................ 49
Figure4. 12: Activity diagram for bill collector ............................................................................................ 50
Figure4. 13: Activity diagram for delete account........................................................................................ 51
Figure4. 14: Activity diagram for update customer information. ............................................................... 52
Figure4. 15: Activity diagram for generate report. ..................................................................................... 54
Figure4. 16: Activity diagram for maintenance order................................................................................. 55
Figure4. 17: Activity diagram for view message. ........................................................................................ 56
Figure4. 18: State chart diagram for create account. ................................................................................. 57
Figure4. 19: State chart diagram for send order. ....................................................................................... 58
Figure4. 20: State chart diagram for generate report. ............................................................................... 59
Figure4.2 2:Entity relationship diagram 60
VII | P a g e
List of Table
Table 1. 1:Team composition ...................................................................................................................... 10
Table 1. 2 Time table of the project ............................................................................................................ 10
_Toc128052996
Table 4. 2 Scenario for create new account ............................................................................................... 24
Table 4. 3 Scenario for create new account ............................................................................................... 24
Table 4. 4 User case description for login. .................................................................................................. 27
Table 4. 5 Use case description for customer registration. ........................................................................ 28
Table 4. 6 Use case description of bill collect ............................................................................................. 29
Table 4. 7 Use case description of manager ............................................................................................... 29
Table 4. 8 Use case description of employee registration .......................................................................... 30
Table 4. 9 Use case description of view message ....................................................................................... 31
Table 4. 10 Maintenance order use case description. ................................................................................ 32
Table 4. 11 Use case description receive order. ......................................................................................... 33
Table 4. 12 Use case description of update service. ................................................................................... 34
Table 4. 13 User case description of report. ............................................................................................... 35
Table 4. 14 Use case description of view report. ........................................................................................ 36
Table 4. 15 Use case description of finance................................................................................................ 37
Table 4. 16 Data Dictionary of manager table ............................................................................................ 38
Table 4. 17 Data dictionary of maintenance order ..................................................................................... 39
Table 4. 18 Data dictionary of employee registration. ............................................................................... 39
Table 4. 19 Data dictionary of customer registration ................................................................................. 40
Table 4. 20 Data dictionary for account create. ......................................................................................... 40
Table5. 1: Class interfaces........................................................................................................................... 70
VIII | P a g e
IX | P a g e
Abbreviations
CSS……………………………………………………………Cascade Style Sheet
GUI…………………………………………………………Graphical User Interface
HTML……………………………………………………….Hyper Text Markup Language
MYSQL…………………………………………………….MY Structured Query Language
NFR…………………………………………………………..Non-Functional Requirement
PHP…………………………………………………………..PHP Hypertext Preprocessor
RAM………………………………………………………….Random Access Memory
SQL…………………………………………………………..Structured Query Language
UC………………………………………………………………Use Case
UML………………………………………………………….Unified Modeling Language
USB……………………………………………………………Universal Serial Bus
WCWSS…………………………………………………….Werabe City Water Supply Service
WWW…………………………………………………………World Wide Web
XAMMP…………………………………………..Cross-platform Apache MYSQL, PHP Perl.
X|Page
Abstract
This documentation is proposed for Werabe city water supply service. The water is the most
important for human being and every person day today life process is dependable with water or
interact with water. So it very crucial to make supply services to reduce work load of suppliers,
to make the user of the service more enjoyable and access the services in short period of time by
making the organization working process by web based. This document is part of industrial
project for the fulfillment of a bachelor’s degree in Information Technology written to give detail
information about Werabe city water supply service office. It intended to describe the general
operation performed in the organization. It also focused on general approaches to be followed to
automate the existing manual system to web based system. We used different requirement
gathering methods like interview with in the workers of the organization to know how the system
currently works, existing system problem, the business rule of organization, and current working
system and process of the organization. We used object oriented methodology to develop this
project with the programming language PHP and HTML with CSS for the purpose of formatting
the system and data repository is SQL. We strongly hope that our project will make better the
way Werabe city water supply service office perform than the later
XI | P a g e
Chapter One: Introduction
1. Introduction
There are different task done in Werabe city water supply service; Such as, customer
registration, bill calculating, maintenance etc.
The system has employees like accountant, bill collector, bill officer and technical supervisor to
give service for their customers.
The office use software which is desktop application to generate the customers billing system
and also they use manual system to store back up files like file cabinets and suspension can. In
general the office uses semi-automated system. So, the project try to reduce this problem and
enable the organization system to have very fast service to their customer and to become
automated system by designing web based service management system for Werabe city water
supply service. The system will solve the problem in different ways; it saves the customers’ time
when they want to access service from the organization, it initiates and increases employee moral
to do their task properly, it attracts other customer to join and register under the system,
introduces the organization to technology and also facilitates technology throughout the coverage
area, as it is web based system, it motivates many customers to join the system, as it is easily
accessible, it makes the organization efficient and more profitable in a short period of time, as it
follows automated system and has many customers, it increases performance of the organization,
it makes smooth relation between the office and their customer.
1.2. Background information of the Organization

Today’s there are many water supply service. These organization uses semi _automatic method
to service their products.
1.3. Background of the Project
Werabe city water supply service is established in 1995 E.C as part of the city
administration. At a time the organization had few employees, customers. But as the
organization growth up itself and attracting customers different users like private person,
different organization (hotels, commercial organizations, government organization) start to
use the service. Not only has this by its plan the organization built which called grouping
people or flat (Bono) for the communities who have low income to use the service. Now a
time the organization has two branches (Duna and Alkeso ). And also the tariff payment
1|Page
divided into four categories: - Private, commercial organization, government organization,

and flat or Bono users. Werabe city water supply service office follows semi-automated
system to give service for their customer. Until 1997 E.C the office had only 170. Now days
the organization has around 250 employees in different sectors and including the branches.
1.4. Statement of the problem

Werabe city water supply service is currently uses a semi-automated system. As it is semi
automated, it has its own problems;
 Since the billing information was circulated, the data will loss, and it takes time to
manage it.
 Since customer registration is taking place in physically; it leads to wasting time.
 During requesting maintenance, the customers may spend unnecessarily expense and
waste their time.
 The customers may not get the chance to request service of the organization 24/7(twenty
four hours a day and seven days a week).
 During the backup system of the office, it was not efficient if the documents were
damaged.
 During generating monthly report, it takes time and it may not be easy to manage and
analyses the monthly work due to massive collection of data. In general the gaps that the
group members have been observed is:
 There is a number of customers who have been waiting for services.
 Office of the clerk is full of paper which hold different documents
 Tracing document shelf to get the document of the customer who is attending the
organization for request services is difficult.
 Rotating the document from one bureau to another bureau. There May be loses document
when rotating the document
2|Page
 Customers wasting their time to get services by waiting for employees until the present
to their bureau.
 Sometimes only few customers can be served because of task load done manually.
1.5. Objective of the project
1.5.1. General Objective

The general objective of the project is to develop web based customer management system for
Werabe city water supply service office.
1.5.2. Specific objective

Specific objectives are objectives that help to achieve the general objective of the system. To
achieve general objective we:
 Gather requirements to understand Werabe water supply services
office.
 Analyze the data to understand the architecture of the organization.
 Designing data base and user interface:
 Develop the web based system.
 Implement the proposed system.
 Evaluate the system.
1.6. Feasibility Analysis

When doing any project it is fair to see some conditions concerning cost, benefits, clients or
end users community and about the system developer. To be feasible our project include the
followings:
 Technical feasibility
 Economic feasibility
 Operational feasibility
3|Page
 Behavioral/Political feasibility
 Schedule feasibility
1.6.1. Technical feasibility

This assessment focuses on the technical resources available to the organization. [1] It helps to
determine whether the technical resources meet capacity and whether the technical team is
capable of converting the idea into working system. The project is technically feasible; it include
different resources and tools to develop the system:-
 E draw or UML to draw different procedure showing diagrams.
 PHP language with backend MYSQL server database.
 XAMMP server.
 Visual studio and sublime to edit text or code.
 Microsoft word to write documents
 Browsers (google chrome, Mozilla Firefox) to run the project. Our group hope
that we develop a successful project by using the above resources and academic
knowledge
1.6.2. Economic feasibility

This assessment typically involves a cost or benefits analysis of the project help to determine the
viability, cost, and benefits, time, material, human resources, and the resources the project
consumes associated with a project before financial resources are allocated. Economic feasibility
benefits in two ways.
Tangible benefits:-
The system benefits the organization in different ways; reduces expenses, increase service,
reduces the office that is full of clerks and customers, increase the amount of users. Comparing
with the existing system the new system is more economically feasible. When we analysis the
system by comparing its incurred cost and benefits; the benefit is more than its cost. Obtained
benefits from our proposed system are: Transportation free 20 ETB per customer as we know
4|Page
from any public transportation tariff fee but this may not be for all customer since there may be a
customer who can access the service without any transportation fee. Print and copy materials
request forms Identity card copy: 1ETB per customer Document copy and print: 1ETB per paper
if it is 100 paper the customer incur 100ETB. Unexpected expenditure like food or coffee when
waiting for service: 20ETB this also not common for all customers
Intangible benefits:-
Different intangible benefits are listed below.
 Increase security by only giving authorized users can access.
 Faster to use by using electronic devices.
 Faster to make decision since every information is in database
 Increase accuracy since human being may do doubt during performing tasks
1.6.3. Operational feasibility

This assessment involves undertaking a study to analyze and determine whether and how well
the organization’s needs can be met by completing the project.
It ensure that the management and should support the proposed system and its working feasible
in the current organization environment. Our system is operationally feasible: Since it is web
based the customers use easily because the system is run on web browser which they use for
different reason.
1.6.4 Behavioral/Political feasibility

This project does not do any tasks which is against the law, rule and regulation.
So that it is politically feasible.
1.6.5 Schedule feasibility
Schedule feasibility determine whether the proposed system will be completed on the given
schedule or not. Our project completed on the time that we have planned so the project is feasible
or schedulable.
1.7. Scope of the project
The scope of this project is developing web based system for Werabe city water supply service
organization. More over the project addressed:
5|Page
 Register and update the users.
 Customer maintenance order processing.
 Billing system processing.
 bill report (monthly, quarter year, year) based on organization policy.
 Report generating.
 The does not support the online payment
1.8. Significance of the project

The system will give different significance to different actors in the system generally the
system has the following significance:-
 It save the customers time when they want to access service from the organization.
 It initiates and increases employee moral to do their task properly.
 It attracts other customer to join and register under the system.
Introduces the organization to technology and also facilitates technology throughout the
coverage area, as it is web based system.
1.9 Target Beneficiaries of the system

 It motivates many customers to join the system, as it is easily accessible.
 It makes the office efficient and more profitable in a short period of time, as it follows
fully automated system and has many customers.
 It increases performance of the organization.
 Generates more secured information for each customer.
 It makes smooth relation between the office and their customer [2].
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. And the other user of this system the
organization by its own, everybody can join their organization simply and can understand how
6|Page
they work, and understand what things they done. The followings are beneficiary from the
system: -
The customers
 The system perform service within short period of time.
 It gives access to order online that increase customer satisfaction.
 The system has username and password to keep data secure.
The organization
 Increase profitability
 Reduce manpower
 The system save time and cost
 Easily manage any tasks performed by communicating each other
The employee
 Reduces work overload of employees
 Easily contact with other employees and customers
1.10. Methodology for the project

This section describes the method that we are using to gather information and tools that are used
when we done this project. These methods are listed below.
1.10.1. Data / requirement collection method
There are different methods to collect information. From those the project uses the following
tools and methods to collect data from the organization.
Observation (Documentation & material):
use this method to get the right information about the organization and also to understand how
the existing system works.
Interview: This methodology encapsulates two types of methods. These methods are closed and
open interview. So the team has selected an open interview for interviewing the manager and
7|Page
employees for recognizing the existing working procedure of the organization. So the team was
able be to gather more information about the organization and requirements.
1.10.2. Implementation tools
This includes both software and hardware tools that we are using when we implement this
project.
Software tools:
The most software tools we used are the following:
 MySQL- to create and design the database which used to store the information of
the customers & the employee of the organization.

 MS-word- to prepare the documentation part of the project
 PHP scripting language and its own XAMMP server: to implement the system
and provide the user of the system with an interface.
 We use Notepad++ to write code.
 Web browser.
 E-draw max: to draw user interface.
 Snipping tool: to take screen shoot of pictures.
 MS PowerPoint: for presentation
Hardware tools
For the new system to be efficient there is a requirement for specific hardware.
 Personal computer or PC
 Hard disk: to keep the permanent data.
 USB Flash: 4GB or above to store & transfer data from one PC to another PC.
 Printer: to have a hard copy for the data.
 Pen and pencil: to write notes and during interviews
 Smart phone and network cables.
8|Page
1.11. Systems Analysis and Design Approach

The team decides to use object oriented system analysis and design approach because of
the following reasons:
 Simplicity: Software objects model real world objects, so the complexity is reduced and
the program structure is very clear.
 Increased extensibility: -When you need to add new feature to the system you only need
to make changes in one part of the applicable class.
 Modifiability: It is easy to make minor changes in the data representation or the
procedures in an object oriented program.
 Increase consistency across analysis, design and programming.
 This method is well known by the group members and commonly used in different
course.
1.11.1. Limitation of the Project

Due to lack of some situation like resource, time, internet, and current situation as a
whole; the limitation of projects are:-
 The system does not recognize visually impaired person.
 Do not read the consumption online.
1.11.2 Risks & contingencies

This is a challenges that we get during we develop this project. So that our team is venerable for
such things: - lack of computer in lab class, there is no internet connection, there is a problem of
power and also other risks are available.
1.11.3 Assumptions and Constraints
This is the place where we write our team assumption and constraints to avoid the risk and
contingencies of the above. So we assume that all problems which are listed above have to
solved automatically in order to make a team to work very well
1.12. Team composition

The project team composed of three members. Decision on problem and approach are made by
group agreement.
9|Page
Table 1. 1:Team composition
Group members Works

Kemeru Kelifa In all works
Bedada Regasa In all works
Bariee Megersa In all works
1.13. Time Table

Our project time table is described on the following table.
Table 1. 2 Time table of the project
Work Name Time

Dec4- January2-Feb2 Feb 8-March3 March4-May7 May5-June 12
January11
Project proposal
Analysis
Design
Implementation
Testing
10 | P a g e
Chapter Two: Description of the Existing System
2.1. Introduction of existing system

The purpose of analyzing the existing system is that to determine exactly how the existing
system works, to identify what problems exist, and finally to give a solution. The desktop is
presented as the alternate solution of the existing system present in the organization. The
discussed system is semi- automatic which will be beneficial for the organization the operational
functions of the organization.
2.3. Users of Existing System

This includes the actors of the existing system. The actors of the existing system are list below.
Manager: It has the following activities.
Managing employees.
Generate report.
View feedback.
Manage permission.
Customer: The customer can send a request to the organization for any order they prefer.
Employee: It has the following tasks..
Receive job order.
Request permission.
View request.
2.4. The major functions of current system

Customer registration
Register the customers who want to the member of organization access the service given to them.
Bill calculation
The employee calculates bill monthly and tells to customer how much it count then the
customers pay their bill monthly based on their bill.
Report generation
11 | P a g e
Month and generates the report.
Maintenance reporting
Customers inform physically to their technical supervisor when service maintenance was needed.
2.5. Existing System Workflow Structure
Figure2. 1: workflow diagram
2.8. Bottlenecks of the existing system (using for example PIECES frame Work) [3].
Werabe city water service supply currently uses a semi-automated system. Since it is
automated, it has some problem. Like
 Customer registration is taking place to physically: that leads to wasting time and office
of the manager overloaded by customer who need service.
12 | P a g e
 Customers may spend unnecessarily expense and waste their time to request maintenance
order since they have to report to the office physically.
 order since they have to report to the office physically.
 The customers may not get the chance to request service of the organization 24/7(twenty
four hours day and seven a week).
 During natural disaster happen data and history of customer and any organization’s
employees may be damaged since it manual based. Data and history of customers may be
loss during circulation since there is huge amount of documented history and take time to
find.
 During generating monthly work due to massive collection of data and the generated
report may not be accurate.
2.8.1. Performance (response time)

Performance is a quality attribute that describes the responsiveness of the system to various user
interactions with it. Poor performance leads to negative user experience.
Hence our system is:-
 Works very well within short period of time, high available
 Can support many users at a time
 Execute concurrent tasks at the same time.
2.8.2. Security and control

Since everything in the office is financial, the system should be highly secured and every users
of the system should have their own privilege which in turn maximize the system security.
 The system uses encryption method to encrypt data in database
 It is secured since it validates customers and any other user by their own
username password.
13 | P a g e
 Natural disasters and any other damages cannot be disappear the file since it has
backup files.
2.8.3. Efficiency
The current system is not some efficient during transaction due to all tasks are performed semi-
automated. So that this has a few of disadvantages such as, time consuming, lack of employee
and others. This make the current system some inefficient.
14 | P a g e
Chapter Three: Proposed System
3.1. Introduction
The proposed web based customer management system for city water supply service solve the
problem of the existing systems by designing computerized system.
Web based customer management system for city water supply service is very useful for the
operators and customers. They can minimize the working stress and can keep essential
documents related to the employees and the customers as a softcopy.
The advantage of the proposed system is the reduction in the cost of the office equipment’s and
the transaction is done quickly.
The new system has several advantages such as:-
 Organized information storage
 Restricted Access to data,
 Easy access to information using search function.
 Increase Customer Service.
 Improved Billing.
 Eliminate Paperwork entirely.
3.2. Product Overview

The proposed system deals with developing web based customer management system of Werabe
city water supply service. The proposed system do them following:-
 Unlike the existing system, which operates by registering one customer at a time the
online web system can register many customers concurrently.
 The new system can also help to found any files of the customers with in a fraction of
seconds. With this new system the organization given efficient and time observance
service for this customer.
 In new system the customers not need to physically appear at the office to order
maintenance service.
15 | P a g e
 Employees, customers, and anyone can access the service online.
 Reports, new relating with organization can access online.
 Since the system works 24/7(twenty four hours a day and seven days a week).
 Reduces physically appearance at office of the organization since all services are given
online.
3.3. User class and characteristics

The following are the actors in our system. [4]
User class and characteristics
Admin
 Manage account
 Update account
 Delete account
Manager
 Manage employees
 Update, delete, edit as an admin
 Generate report
 View feedback
 Manage permission
Employee
 Receive job order
 Request permission
Customer
 Request order
 Update order
16 | P a g e
 View appointment
 Pay bill
 Send feedback or give comment
3.4. Functional Requirements

Function requirements these are statements of services the system should provide, how the
system should react to particular inputs, and how the system should behave in particular
situations. It specifies the software functionality that the developers must build into the product
to enable users to accomplish their tasks.
Functional requirements that included in our system are:-
For manager
 Managing employees: the system allows the manager to manage employee, advice,
punish, and fire depending the rule and regulation of the organization
 Generate report: the system allows a manager to manager view customers ‘and employee
‘history and generate report that is collected from different sub-department monthly,
quarterly, annually depending on the policy of the organization.
 View feedback: the manager can view feedback of users about their services.
 Manage permission: the system allows the manager to manage permission rise from
employee to get annual leave, pregnancy (if employee is female), sickness and others.
For employee
 Receive job order: any order arise from the customer is performed by employees
depend of their job.
 Receive job order: any order arise from the customer is performed by employees
depend of their job categories.
 Request permission: employee can send annual leave, medical issues, and other
requests to manager.
17 | P a g e
 View salary: the system allows the employee to view their salary.
For customers:
 Request order: the customers can send a request to the organization for any order they
prefer Update order: this is possible if and only if the order is not started.
 View appointment: the customers can view the appointment to get service for their
request.
 Send feedback: if they have any comment regarding organization`s service, they simply
leave their comment.
For bill calculator:
 Calculate the bill based on type of their customer (private, commercial, and
government Organization, and flat/bono users).
For technician:
 Receive order of maintenance: any technical error or breaking of service.
 Report maintenance request: assign technician to the area where

maintenance needed, and update maintenance report
For finance:
 The finance manage the salary of the employees.
 Manage budget: the finance allocates the budget.
For Administrator
 Managing accounts: the system allows the administrator to manage accounts in case of
updating, deleting, and creating new account.
 In general the system has been done the following properly:
18 | P a g e
 The system must have a dynamic website that provides successfully registration of
customers which are under the business rule of the office and generate report to interact
with various users.
 The system should allow staff to login to the system using their username and password.
 The system should display full information for the customer from the database to the
interface of the web page.
 The system should have well organized information storage and accessing mechanism.
 The system should allow generating report for the organization.
 The system must presents information of the customer and their monthly costs, and
request service maintenance in secured manner.
 It is expected to solve the difficulty of managing overloaded customer registration,

maintenance order bill calculating and other task successfully.
3.4.1. Performance Requirements

 To facilitate the efficient collection of performance requirement data, we have established
the Following:
 Water Performance requirement – this guidance semi-automated provides context for

each requirement to assist both the water businesses and regulatory auditors in
determining a value for each requirement.
 Water performance report data collection template – we annually provide the water
businesses
 With collection template for their completion.
 Water organization regulatory audits – we require the reported performance requirement

values to be audited Audits are undertaken in accordance with our Guideline for
Approving, Conducting & Reporting Operational Audits.
 Water Performance Report – annually we publish a report on the performance.
19 | P a g e
 Water businesses that provide water, sewerage and related services to urban customers.
3.4.2. Process Requirement

Water process requirement is the process of manager, employee and customer water process in
terms of both water quantity and quality across all water uses. It includes the organization,
customer, employee, and information system that support and guide water requirements.
3.4.3. Input related requirements

 The system allows write comment of user.
 The system allows search supply.
3.4.4. Output related requirements

 The system allows view comment.
 The system allows view supply.
 The system allows view report.
3.4.5. Storage related requirements

The system allows register or adds supply to the database.
Manage customer data record: this is the responsibility of the administrator to manage the
customer data record.
3.5. Nonfunctional requirements

Non-functional requirements (NFR) describe how a system must be have and establish
constraints of its.
They may relate to emergent system properties such as reliability, response time, and store
occupancy, scalability, availability, maintainability, environmental, and interoperability.
Non-functional requirements, security, or availability, usually specify or constrain characteristics

of the system as a whole.
3.5.1. Scalability
Scalability requirements describe how the system must grow without negative influence on its
performance. This means serving more users, processing more data, and doing more transaction.
3.5.2. Availability
20 | P a g e
Availability is evaluated by the period of time that the system’s functionality and services are
available for use with all operation.
Hence the system is available everywhere means where the internet connection reaches.
3.5.3. Reliability
Reliability defines how likely it is for the software to work without failure for a given period of
time. The system calculates the customer’s bill rent, so it should give accurate result; so should
be reliable. The system deploys on server computers and allows multiple clients to access the
server at the same time. Since our system has a backup procedure it secures data of customers,
managers, employees, and any other users.
3.5.4. Maintability
Maintainability is how easy it is for a system to be supported, changed, enhanced, and structured
over time. The system support change, updates, enhances, and restructured when I needed. If any
error occurs after system developed the system developer can easily maintain it. The interface is
user-friendly and interactive so it is essay to fix while errors occur.
3.5.5. Environmental
The system works accurately always by maintaining condition of the environment and the server
the system upload have to be placed under a safety environment.
3.5.6. Usability
Usability defines how difficult it will be for a user to learn operate the system. The system is
easy and understandable to use. The system has a guide that instructs the users through the
system. It also displays and error message if the user access in wrong way.
3.5.7. Interoperability
Interoperability is defined as how easily a system can share information and exchange data with
other system and external hardware. It is the capability of a product or system to interact and
function with others. The system must interoperable with other, available on other device other
than the devices project is done.
 The system must be hardware operable means the system need to run on different types
of devices.
21 | P a g e
 The system must be information operable means information easily move from one
system to another and it be seamless. The system share the same data format
 The system is easily readable by browsers.
3.5.8. Security
To use the system a user must first register to system and log in to the system but if unregistered
user tries to reserve without having registering the system does not allow the user to use the
system.
The authorization mechanism of the system will block the unwanted attempts to the server and
also let the system decide on which privileges may the user have.
22 | P a g e
Chapter Four
4.1. System models

System modeling is the interdisciplinary study of the use of models to conceptualize and
construct the system. A system model is a conceptual model that describes and represents a
system.
4.1.1 Scenarios
 Scenario tells us who is using the system and what they are trying to accomplish.
 Describes any relevant aspects of the context in which the is working with the system,
including what information the user has on hand when beginning to use the system.
Below are scenario of how user users the system of the organization.
Table 4. 1 Scenario for login
Scenario Name Login
Actor Manager, Employee, Customer, Technician, bill calculator
Flow of action
 The actor browse the address of the system
 The system login page display to the actor
 The actor fulfill the field and submits the login button
 The system validates the input of the user
 If the username and password is correct the system

displays the home page
 If the values entered are incorrect the system displays

error message.
23 | P a g e
Table 4. 2 Scenario for create new account
Scenario Name Create account
Actor Customer
Flow of action  The actor browse the website of the

organization
 The login page is displayed to actor
 On login page there is “create new

account”.
 The user click create account button and

the system displays the form.
 User enter the form with appropriate

information and the click on create account
button.
 The system displays to the user “account

successfully created” message.
Table 4. 3 Scenario for create new account
Scenario Name Manage account
Actor Admin
Flow of action
 Admin login and click manage account
 System displays create, update, delete and

search.
 The admin selects what he/she want and
24 | P a g e
fill it click button
 The system display successful message
Scenario Name Request and update order
Actor Customer
Flow of action  Login with username and password
 System verifies customers` address
 Click on the request order form
 System displays request order form
 Customer fills the form and submits the

forms
 If the customers click update it checks

whether or not the order start.
 If not send an update order requests
4.1.2. Use Case Model

A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. The use case
models are used to document the functional requirement of a system [5].
The following are the actors in our system.
User class and actor definition
Admin
 Manage account
25 | P a g e
Manager
 Manage employees
 Generate report
 View feedback
 Manage permission
Employee
 Receive job order
 Request permission
 View request
Customer
 Apply registration
 View appointment
 Send feedback or give comment
Bill collector
 Bill collect
 View report
Technician
 Receive order maintenance
 Assign technician
 Report maintenance request
26 | P a g e
Finance
 Manage salary
 Manage budget
4.1.3. Use Case Model

A use case is a sequence of action that provides a measurable value to an actor. In another way a
use case describes a way to which the real-world entity interacts with the system.
The use-case model includes use cases, actors, their associations, system boundary box.
Figure4. 1: User case model
4.1.3. Use Case Description

Table 4. 4 User case description for login.
Use case name Login

Use case number UC01
Description User login into the system by using username and
password
Actors Manager, customer, bill collector, technician,
employee.
27 | P a g e
Pre-condition The user must have an account to login into the

system.
Basic course of action User action System response
Step1: the user browse Step2: display the web
the system page
Step3: user click on Step4: the system
login displays login form.
Step5: the user enters Step6: the system
username and password validates the user
then click on login whether or not username
button. and password is correct .
Step7: end of use case.
Alternative course of action The system display error message “incorrect
username and password” Step4 will display and
user fill it again.
Post-condition The user enter to the system.
Table 4. 5 Use case description for customer registration.
Use case name Apply registration

Description
Customers register themselves by fulfilling into the
prepared form
Actors Customer ,Manager

Pre-condition The customer should fulfill the business rule of the
organization to apply service order
Step1: the user browse Step2: system display
the system web page website Step4: the
Step3: customers click on system display register
sign up form Step5: form. Step6: system
customer fulfill a form valid and display
and click the submit successful register
28 | P a g e
button. message.
Step7: end of use case.
Alternative course of action The system shows that the users enter invalid
information. Step4 of use case will continues again.
Post-condition The customer will joined the organization and
access the service.
Table 4. 6 Use case description of bill collect
Use case name Bill collect

Use-case number UC03
Description Bill collector accumulates the overall financial
value from the accountant and customer data from
the office
Actor Bill collector
Pre-condition Accountant must transfer payment value of
customer to bill collector and get customer data
from the office.
Step1: open the page Step2: login form
Step3; enter user name Step4: validates the
and password. address of bill collector.
Step5: open the
customer payment link
and check the payment
and transfer to the
accountant.
Step6: end use case
Alternative course of action In case there is invalid information the step2 will
continue.
Post-condition Customer pay their debit to accountant according to
calculated bill.
Table 4. 7 Use case description of manager
Use case name Manager
29 | P a g e
Use- case number UCO4
Description The manager takes the responsibility of

managing all process performed through the
organization
Actor Manager
Pre-condition The manager first get access from the admin to
control the system process

Step1: open the Step2: system display
page login form
Step3: enter user Step4: system validates the
name and password address of manager
Step5: open links Step6:system displays the
like customer
feedback, employee link
request, employee
salary payment.
Step7: fill the form
according to their
order.
Step8: end
Alternative course of action In case there is invalid information the step2 will
continue.
Post-condition Give response for all requests from all users.
Table 4. 8 Use case description of employee registration
Use case name Employee registration

Use case number UCO5
Description Employees who are member of the organization are registered
online by using Werabe city water supply service website
Actor Employee
Pre-condition First the employee must fulfill the business rule of the
organization.
30 | P a g e
Basic course of action Use action System response
Step1:open the system

Step2: login form
Step3: enter user
Step4: the system check the
name and password address of employee

Step5: click registration Step6: the system displays the
form link Step7: fulfill registration form
the form with needed Step9: display registered
information. successfully.
Step8: click register
button
Step10: end.
Alternative course of action In case there is doubt information regarding the employee
input; step2 will continue.
Post-condition The employees will join and become member of the

organization.
Table 4. 9 Use case description of view message
Use case name View manager

Description The customers of the organization can view any
messages released from the organization for their
users.
31 | P a g e
Actor Customer
Pre-condition First the customer must login or UC01
Step1:The customer
open the system. Step:2 display login
form
Step3: enter user name Step4: validates the
and password. address of customer
Step5: click information

button and see the
information released
Step7:end use case
Alternative course of action

If there is any invalid information that customers
enter ste2 will continue.
Post-condition The customer get information and values.
Table 4. 10 Maintenance order use case description.
Use case name Order maintenance

Description Allow the customer to order maintenance for the
organization
Actor Customer
Pre-condition First the customer must be registered.

displayed
Step3: enter user
Step4: validates the
name and password. address of the user
Step6: system displays
32 | P a g e
Step5: select maintenance form

maintenance order
form
Step7:customer fulfill
the form with detail
information Step8: the
system response
whether or not the
message is transferred
and sent successfully
Step9: end use case.
Alternative course of action Step2 will continue if the user enters incorrect user
name and password.
Post-condition Maintenance order will bill be stored to the system.
Table 4. 11 Use case description receive order.
Use case name Receive maintenance order

Description Receive, assign technician and approve customer
maintenance order
Actor Technician
Pre-condition UC09
Basic course of action User action

System response
Step1:the technician Step2: the system displays

browse the system login form. Step4:system
Step3:the technician validates the address
enter username and
password Step5:
check and see the
problem and identify
33 | P a g e
the customer we
send the order
Step6: receive the
order from the
customer Step7: end
of use case
Alternative course of action Step4 will continue if the user enters invalid
username and password.
Post-condition Assign the technician for the service being
transferred and give the service.
Table 4. 12 Use case description of update service.
Use case name Update maintenance order

Description Update the service order that would maintained
Actor Technician
Pre-condition UC09
Step1: the technician Step2: the system
browse the system display login form
Step3: enter username Step4: the system
and password validates the address.
Step5: check whether or
not the service is
maintained
If it was maintained:
• Record the
maintained
service.
• Calculate how
much it cost to
maintain.
34 | P a g e
• Transfer the
calculated cost
to the
accountant.
Update the
received data to
permanently
Else try to
maintain the
service.
• Step6: end use

case.
Alternative course of action The system displays that the user enter invalid
username or password Step2 will continue.
Post-condition
Update the maintained service.
Table 4. 13 User case description of report.
Use case name Generate report

Use-case number UC011
Description Generate report that was done per month in
printable form
Actors Manager
Pre-condition
First must login into the system and receive reports
from sub-departments
Step3: enter user name displayed
and password. Step4; validates the
Step4: Click report address of manager.
35 | P a g e
link Step6: write the Step5: system displays

report based on report form.
organization rule
Step7: click print
button Step8: end use
case.
Alternative course of action The system displays that the user enter invalid
username or password Step2 will continue
Post-condition Prepare report.
Table 4. 14 Use case description of view report.
Use case name View report

Description View reports that was done within a month
Actor Employees
Pre-condition First employees must be login and registered
Step1: open the Step2: display login form
page. Step3: Step4: system validates the
enter user name address
and password
Step5: Click
report link
Ste6: view
reports
generated from
the manager.
Step7: end use
case.
The system displays that the user enter invalid
username or password Step2 will continue
Post-condition View prepared report.
36 | P a g e
Table 4. 15 Use case description of finance.
Use case name Manage budget

Description Manage the budget and any finance done through the organization.
Actor Finance
Pre-condition The employees must be under the organization, the finance must know
original salary of the employees, and budget request from other
department.
Step1: open the Step2: display login form

page. Step4: system validates the
Step3: enter user address
name and password Step6: the system display
Step5: finance click the form
manage salary link Step8: the system verifies
Ste7: finance enter the entered data and
the appropriate calculates the salary.
information and click
the calculate button.
Step9: end use case.
The system displays that the user enter invalid username or password and
invalid information Step2 and step6 will continue.
Post-condition Budget and salary the organization managed
4.1.4. Object model

Object model visualizes the elements in a software application in terms of objects Object
diagram is a structural diagram. It is similar to class diagram these diagrams help to understand
object behavior and their relationships at a particular moment. An object model helps describes a
software or system in terms of object
37 | P a g e
Figure4. 2: Object model
4.1.4.1. Data Dictionary

Data dictionary also provides metadata about data elements.
The metadata included in a data dictionary can assists in defining the scope and characteristics
of data elements, as well as the rules for their usage and application
Table 4. 16 Data Dictionary of manager table
Field name Data type Description

MID Int Holds ID of the manager
First name String Holds the first name of the
manager
Last name String Holds the last name of the
manager
Age Int Holds the age of the manager
User name String Holds the unique name of
38 | P a g e
manager
Password String Holds the password of
manager
Table 4. 17 Data dictionary of maintenance order

Cust_ID Int Contains the ID of customer
First name String Contains the first name of
customer
Last name String Contains the last name of
customer
Mtype String Contains the type of
maintenance that customer
need to access
Keble String Contains the address of
customer
Phone number Int Contains the phone number
of customer
Date Int Contains the date customer

sent a request
User name String Contains the unique name of
customer
Password String Contains the password of
customer
Table 4. 18 Data dictionary of employee registration.

EID Int Contains the ID of employee
First name String Contains the first name of the
employees
employees
Age Int Contains the age of
employees
Email Email Contains the email of
39 | P a g e
employees
GPA Float Contains the GPA of
employees
Phone number Int Contains the phone number
of employees
Password String Contains the department
he/she is qualified.
Table 4. 19 Data dictionary of customer registration
Field name Datatype Description

Cust_ID Int Contains the ID of customers
First name String Contains the first name of
customers
customers
Age Int Contains the age of customers
Keble String Contains the address of
customers
Phone number Int Contains the phone number of
customers
Customer group String Contains the customers group
Table 4. 20 Data dictionary for account create.

First name String Contains the first name of users
Last name String Contains the last name of users
Age Int Contains the age of users

Phone number Int Contains the phone number of
users
Birth date Date Contains the birth date of users
Gender String Contains the gender of the users
User name String Contains the unique name of
users
Password String Contains the password of users
40 | P a g e
Figure4. 3: Analysis level Class diagram
4.2.Dynamic Model
The dynamic model is used to express and model the behavior of how operations are carried out.
It includes support for activity diagrams, state diagrams sequence diagrams and extensions
including business process modeling .
4.2.1 Sequence diagram.
41 | P a g e
Figure4. 4: Sequence diagram for login.
42 | P a g e
Figure4. 5: Sequence diagram for create account.
43 | P a g e
Figure4. 6: Sequence diagram for customer registration
44 | P a g e
Figure4. 7: Sequence diagram for maintenance order
45 | P a g e
Figure4. 8: Sequence diagram for delete customer information.
4.2.2 Activity Diagram

Activity diagrams are graphical representations of work flow of activities and actions with
support for choice, iteration and concurrency. So the team depicts activity diagrams of this
project as follows.
46 | P a g e
Figure4. 9: Activity diagram for login form
47 | P a g e
Figure4. 10: Activity diagram for apply registration
48 | P a g e
Figure4. 11: Activity diagram for create account.
49 | P a g e
Figure4. 12: Activity diagram for bill collector
50 | P a g e
Figure4. 13: Activity diagram for delete account.
51 | P a g e
Figure4. 14: Activity diagram for update customer information.
52 | P a g e
Figure 1Activity diagram for receive maintenance order:
53 | P a g e
Figure4. 15: Activity diagram for generate report.
54 | P a g e
Figure4. 16: Activity diagram for maintenance
55 | P a g e
Figure4. 17: Activity diagram for view message.
56 | P a g e
4.2.3 State Diagrams

The state diagram used to show the sequence of states that an object goes through the events that
cause the transition from one state to the other and the actions that result from a state change.
Figure4. 18: State chart diagram for create account.
57 | P a g e
Figure4. 19: State chart diagram for send order.
58 | P a g e
Figure4. 20: State chart diagram for generate report.
59 | P a g e
4.3.ER Diagram
E-R (Entity-Relationship) Diagram is used to represents the relationship between entities in a
table. ER diagrams represent the logical structure of databases. ER Diagram represents
relationship between two database tables
4.3.1 Mapping
Figure4.2 1:Entity relationship diagram
4.3.2 Normalizatio(1st-BNCF normal forms)

Normalization is a process that aims at achieving better designed relational database [6]schemas
through the user of semantic information given by Functional dependencies and Primary keys,
Normalization process takes a relational schema through a series of tests to certify whether it
satisfies conditions. The schemas that satisfy certain condition are said to be in a given
“NORMAL FORM’ and unsatisfied schema are decomposed by breaking up their attributes into
smaller relations that possess desirable properties. Normalization allows us to organize data that
it allows fast access and reduced space.
Customer
Cust_ID Name Sex House_No Tell_No Kebele
First normal form (remove multi valued attributes)
Cust_ID FirstName LastName Sex House_No Kebele
60 | P a g e
Figure2. 22:
Figure4.2 2:Entity
3: Entityrelationship
relationshipdiagram
diagram
Cust_ID House tell number Mobile Number
Employee
Emp_ID Name Sex Position Tell_No
Emp_ID First Name Last Name Position
Emp_ID Office Tell_Number Mobile Number
Manager
M _ID Name Sex Office_No Tell_No
M _ID FirstName LastName OfficeTell_Number Mobile Number
61 | P a g e
Chapter Five: System Design
5.1. System Overview

Under this chapter we concerned with a design parts of the web based customer management
system for werabe city water supply service. Design is visual representation of the system that
makes our implementation step easier and which will avoid the need for modification that will
come after design phase. In this chapter we will introduce the design consideration, design goals,
design trade-offs, architecture of the system, system decomposition, hardware/software mapping,
persistent data management, user interface design and object design of our systems.
5.2. Design Considerations

There are many aspects to consider in the design of a piece of software. The importance of each
consideration should reflect the goals and expectations that the software is being created to meet
[7]. The WCWSS is designed with better and sophisticated consider of the following set of
fundamental design aspects.
5.3. Design Goals

It deals with qualities of the system should developers optimize during design phase. Several
elements will impact and shape the design of the application. Such goals are normally derived
from the non-functional requirements of the system. These are:
Performance Criteria
Response time: The part of the system to be used for the record should have a fast response
time (real time) with maximum throughput [8].
Throughput: The system performs a number of tasks at given period of time do to efficient way
of design.
5.4. Design Trade-offs

Trade-off is inevitable in trying to achieve a particular design goal. One best case is the issue of
security versus response time. Checking User-Id and Password before a member can enter to the
WCWSS creates response time problem/overhead. The other case is the issue of response time
versus quality. There is some amount of time taken by the system to generate the functional
modules like reports and timetable. So, the user has to wait a little after telling the system to
generate the report timetable and getting the result to get a quality time table [9].
62 | P a g e
5.5. Architecture of the System

A system represents the collection of components that accomplish a specific function or set of
functions. The purpose of designing is to show the direction as to how system is developed and
to obtain clear and enough information needed to derive the actual implementation of the system.
Once the services is available based on the user request the services will be delivered with each
specific privilege to access, to receive, to view the data. We select three-layer architecture
systems. The reason we use a three-layer is that users or clients can access the system from
anywhere via the World Wide Web (WWW). Our system is more related to the database and the
database is accessible and is implemented using three-tier architectures.
5.6. System Decomposition

System decomposition is undertaken to reduce the complexity of the system and attain insight
into the identity of the constituent components. Subsystem decomposition is the process by
which a complex problem or system is broken down into parts that are easier to understand,
program, and maintain. It breaks a large system down into progressively smaller classes or
objects that are responsible for some part of the problem domain.
 Customer management subsystem: is a subsystem that used to manage the customers of
the organization which is manager can register, update, delete and view customers using
the system.
 Order management subsystem: is a subsystem that used to manage the order of the
customer in approve the order and order job to the employee.
 Employee management subsystem: is a subsystem that used to manage the employee of

the organization which is manager can register, update, delete and view employee using
the system
 Feedback management subsystem: is a subsystem that used to manage the feedback of

the customer which is customers can send feedback managers can view feedback and
return suggestions to them.
 Report management subsystem: is a subsystem that used to manage a report of each

department function.
63 | P a g e
 Appointment management subsystem: is a subsystem that used to manage the

appointment of the system which gives by customer service able to view, update and
delate appointment.
 Permission management subsystem: is a subsystem that used to manage different

permission in which the manager can approve, reject the permission of the employees.
Figure5. 1: System decomposition diagram
5.7. Hardware/Software mapping

The hardware and software mapping is the various hardware devices and software equipment
used in the system and its instruction with the software components.
64 | P a g e
Figure5. 2: Hardware/software mapping
5.8. Persistent data management

Persistent data management describes the persistent data stored by the system and data
management infrastructure required for it. Persistent data management is all about permanent
data that are stored and how they should be managed. The training material should permanently
store to be available to the user. Account detail must be compared with permanently stored
account detail to authenticate the user for operations. Those data must be stored permanently that
the system get required information when it needs.
65 | P a g e
Figure5. 3: Persistent data management.
5.9. User Interface Design

User interface design is the 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.
1. Login interface: - The login form interface is an interface where user fills Email and
password to access the system.
66 | P a g e
Figure5. 4: Login interface
67 | P a g e
Figure5. 5: register account interface
68 | P a g e
New User Account Format
Figure5. 6: register account format interface.
5.10. Object Design
5.10.1. Interface documentation guidelines

In This section we will define rules or guidelines for naming variables, class attributes, interface,
exception and methods.
Variables
Variable names should be descriptive and indicative of the variable’s use. For multiword
variables, the following notation will be used; the first letter of each word will be capitalized if
the variable contains multiple words except first word.
Classes
All classes are named with singular nouns or noun phrases, and the first letter of each word
should be capitalized.
 Methods
All methods are named with verb phrases, and the first letter of each word should becapitalized
except first word.
Exception
69 | P a g e
When error occurs, the application will display an appropriate error message to the user and then
allow the user to terminate the application or close the error message and proceed with the
application.
5.10.2 Class interface
Class interfaces the class interface describes the content of the class such as class name, methods,
attributes, parameters, data type, and visibility.
Table5. 1: Class interfaces
Class Methods and attributes

Attributes
firstName: public, string and it contains first name of the
Customer customer
lastName: public, string and it contains last name of the customer
custID:int
kebele: public, string and it contains kebele of the customer
firstName: String mType: public, string and it contains mType of the customer
lastName: String phoneNumber: public, int and it contains phone number of the
mType:string customer
kebele:string custID: private, int and it contains customer id
phoneNumber: int date: public, int and it contains date of the customer
date:int
Methods
+View message():void
+view message():public, void and enables customer to view their
+apply():viod
message
+apply():public, void and enables customer to apply their register
Attribute
eID: private, string and it contains employee id
Employee
eID:int firstName: public, string and it contains first name of the
firstName: String
employee
lastName: String
lastName: public, string and it contains last name of the
age:int
position:string employee
GPA:float age: public, int and it contains age of the employee
70 | P a g e
-phoneNumber: int -email: public ,email and it contain email of the employee
-email:email -phoneNumber: public, int and it contains phone number of the
employee
GPA:public,float and it contain GPA of the employee
+view():void
Methods
+view():public, void and enables employee to view their request
Manager
Attributes
firstName: public, string and it contains first name of the
mID:int
fristName:string manager
lastName:string
lastName: public, string and it contains last name of the manager
age:int
age: public, int and it contains age of the manager
+approve request():void mID: private, string and it contains manager id
Employee():void
See feedback():void
Methods
+ approve request ():public, void and enables manage to approve
their request
Employee():public, void and enables manage to their employee
See feedback():public, void and enables manage to employee
their See feedback
71 | P a g e
References
[1] google, [Online]. Available: https://cesh.health/wp-content/uploads/2.2-Analyse-feasibility.pdf.

[Accessed 23 2 2023].
[2] google, [Online]. Available: https://www.scribd.com/document/518597325/Industrial-Project-I-Final.
[3] google, [Online]. Available: https://www.coursehero.com/file/51363821/meron-oosaddocx.
[4] google, [Online]. Available: https://www.docsity.com/en/ethiopia-debre-berihan-university-college-
of-computing/5239245.
[5] google, [Online]. Available: https://www.techtarget.com/searchsoftwarequality/definition/use-case.
72 | P a g e

W Supply

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

W Supply

Uploaded by

Copyright:

Available Formats

WEB BASED CUSTOMER MANAGEMENT SYSTEM FOR WERABE CITY WATER SUPPLY SERVICE

Under Guidance of Mr. Negash Korsebo(MSc)

Bedada Regasa …………………...

Bariee Megersa ………………….

Advisor and department head Approval Form

Advisor Name Advisor Signature

Department Head Name Department Head Signature

Examiner Approval Form

Examiner Name Examiner Signature

List of Figure......................................................................................................................................... VII

5.5. Architecture of the System............................................................................................................... 63

Figure2. 1: : workflow diagram ................................................................................................................... 12

Table5. 1: Class interfaces........................................................................................................................... 70

Chapter One: Introduction

1.2. Background information of the Organization

1.3. Background of the Project

divided into four categories: - Private, commercial organization, government organization,

1.4. Statement of the problem

 Since customer registration is taking place in physically; it leads to wasting time.

 There is a number of customers who have been waiting for services.

 Office of the clerk is full of paper which hold different documents

1.5. Objective of the project

1.5.1. General Objective

1.5.2. Specific objective

 Analyze the data to understand the architecture of the organization.

 Designing data base and user interface:

 Develop the web based system.

 Implement the proposed system.

 Evaluate the system.

1.6. Feasibility Analysis

1.6.1. Technical feasibility

 PHP language with backend MYSQL server database.

 Visual studio and sublime to edit text or code.

 Microsoft word to write documents

1.6.2. Economic feasibility

Different intangible benefits are listed below.

 Increase security by only giving authorized users can access.

 Faster to use by using electronic devices.

 Faster to make decision since every information is in database

1.6.3. Operational feasibility

1.6.4 Behavioral/Political feasibility

 Register and update the users.

 Customer maintenance order processing.

 Billing system processing.

 bill report (monthly, quarter year, year) based on organization policy.

 The does not support the online payment

1.8. Significance of the project

 It initiates and increases employee moral to do their task properly.

 It attracts other customer to join and register under the system.

1.9 Target Beneficiaries of the system

 It increases performance of the organization.

 Generates more secured information for each customer.

 The system perform service within short period of time.

 It gives access to order online that increase customer satisfaction.

 The system has username and password to keep data secure.

 The system save time and cost

 Easily manage any tasks performed by communicating each other

 Reduces work overload of employees

 Easily contact with other employees and customers

1.10. Methodology for the project

the customers & the employee of the organization.

 We use Notepad++ to write code.