Adama Science and Technology University School of Electrical Engineering and Computing Computer Science and Engineering Department

Mobile Billing and Employee Management system for WSSA
Adama science and Technology University
School of Electrical Engineering and
Computing
Computer science and engineering department
FSE project for 3rd year 1ST semester
MOBILE BILL PAYMENT AND EMPLOYEE

MANAGEMENT SYSTEM FOR WSSA
BY:
1. Mama Mohammed ………………………..A/ur4867/09

2. Muhidin Misbah…………………………...A/4541/09
3. Mubarek Ismael……………………………A/4536/09
4. Seid Shemsu…………………………………A/4905/09
5. Shemsedin Seifedin………………………….A/4554/09
Submitted to: Inst. Anteneh Alemu

Date: 2/April/2019
I
Acknowledgements
We are grateful to extend our deep and genuine appreciation to our advisor Inst.
Anteneh Alemu, for his guidance and constant supervision as well as his kind co-
operationand encouragement, whichhelpedusin completion of this project, whichis
a Software Requirement Specification (SRS) document.
Our heartfelt thanks also goes to Mr. GichileBongase and Zerihun for the
informationthey provide and their contribution in the development of project.
Our thanks and an appreciation goesto all of those who have willingly supported
and helped usout with their abilities
II
Acronym
WSSA……………………Adama city administration water supply and

swage service enterprise
DB…………………………Database
HTML……………………Hyper Text Markup Language
CSS………………………Cascading Style Sheet
SQL……………………. Structural Query Language
PHP……………………. Hypertext Processor
UML…..........................Unified Modeling Language
III
Table of Contents
Acknowledgements.....................................................................................................................................II
Acronym.....................................................................................................................................................III
Table of Contents.......................................................................................................................................IV
FIGURES......................................................................................................................................................VI
TABLES......................................................................................................................................................VIII
CHAPTER ONE..........................................................................................................................................1
1.1 Introduction.......................................................................................................................................1
1.2 Background.......................................................................................................................................1
1.3 Statement of the project.....................................................................................................................1
1.4 Team Composition............................................................................................................................2
1.5 Objectives of the project...................................................................................................................3
1.5.1 General Objective.......................................................................................................................3
1.5.2 Specific Objective........................................................................................................................3
1.6 Feasibility..........................................................................................................................................3
1.6.1 Operational Feasibility................................................................................................................3
1.6.1 Economic Feasibility...................................................................................................................3
1.7 Scope and Limitations.......................................................................................................................4
1.7.1 Scope of the Project....................................................................................................................4
1.7.2 Limitations of the Project............................................................................................................4
1.8 Methodology.....................................................................................................................................4
1.8.2 Development method.................................................................................................................5
1.9 Significance of the system.................................................................................................................5
1.10 Development Tools..........................................................................................................................6
1.10.1 Software Tool............................................................................................................................6
1.11 Overview of the Project Phase.........................................................................................................6
1.12 Project Plan......................................................................................................................................7
1.12.1 Task and Schedules...................................................................................................................7
Chapter 2.....................................................................................................................................................8
2.1 Description of the existing system.....................................................................................................8
2.2 Major Function of the system............................................................................................................8
IV
2.2.1 Users of the Current System.......................................................................................................8

2.2.2 Drawback of the Current System................................................................................................8
2.3 Business rule Identified in the Existing System.................................................................................8
2.3.1 Forms and other Documents of the Existing System......................................................................9
2.3.2 Tables for Current Tariff of Water Consumption........................................................................9
2.4 Expected Outcomes of the Project...................................................................................................10
CHAPTER THREE...................................................................................................................................11
3. Proposed system................................................................................................................................11
3.1 overview:.........................................................................................................................................11
3.1.1 Functional Requirements:.........................................................................................................11
3.1.2. Non-Functional Requirements.................................................................................................12
3.2 System Model..................................................................................................................................14
Scenarios...........................................................................................................................................14
3.3 Actor Identification..........................................................................................................................22
3.3.1 Use Case Identification:............................................................................................................23
3.4 Use Case Diagram...........................................................................................................................24
3.5 Use Case Description.......................................................................................................................25
3.6 Object Model...................................................................................................................................34
3.6.1 Data Dictionary.........................................................................................................................34
3.7 Dynamic Model...............................................................................................................................35
3.7.1 Sequence Diagrams..................................................................................................................35
3.8 Class Diagram..................................................................................................................................50
3.9Activity Diagram..............................................................................................................................51
3.10 State Diagram................................................................................................................................55
Chapter 4...................................................................................................................................................58
4. System design....................................................................................................................................58
4.1 Introduction.................................................................................................................................58
4.2 Overview of System design..........................................................................................................58
4.2.1 Purpose of the system design...................................................................................................58
4.2.2 Design Goal...............................................................................................................................58
4.3 Proposed System architecture.........................................................................................................59
V
4.3.1 System process.........................................................................................................................60

4.3.2 Subsystem Decomposition........................................................................................................63
4.3.3 Subsystem decomposition description.....................................................................................64
4.3.4 Hardware/Software mapping...................................................................................................65
4.3.5 Persistent data management....................................................................................................65
4.3.6 Component diagram.................................................................................................................70
4.3.7 Database Design.......................................................................................................................71
4.3.8 Deployment diagram................................................................................................................71
4.3.9 Access control...........................................................................................................................73
Reference..................................................................................................................................................74
FIGURES
Figure 1. Actor Identification.....................................................................................................................21
Figure 2. Use Case Diagram.......................................................................................................................23
Figure 3.Sequence diagram for login.........................................................................................................35
Figure 4.Sequence diagram for register customer.....................................................................................36
Figure 5.Sequence diagram for update customer.....................................................................................37
Figure 6.Sequence diagram for delete customer.......................................................................................38
Figure 7.Sequence diagram for make payment.........................................................................................39
Figure 8.Sequence diagram for send request............................................................................................40
Figure 9.Sequence diagram for view history.............................................................................................41
Figure 11.Sequence diagram for meter reading........................................................................................42
Figure 12.Sequence diagram for approve maintenance............................................................................43
Figure 13.Sequence diagram for create employee account......................................................................44
Figure 14.Sequence diagram for update employee account.....................................................................45
Figure 15.Sequence diagram for delete employee account......................................................................46
Figure 16.Sequence diagram for view report............................................................................................47
Figure 17.Class diagram.............................................................................................................................48
Figure 18.Activity Diagram for customers.................................................................................................49
Figure 19.Activity Diagram for customer service expert............................................................................50
Figure 20.Activity Diagram for technician..................................................................................................51
Figure 21.Activity Diagram for manager....................................................................................................52
Figure 22.State diagram for pay bill...........................................................................................................53
Figure 23.state diagram for view history...................................................................................................54
VI
Figure 24.state diagram for create employee account..............................................................................55

Figure 25. proposed system architecture..................................................................................................57
Figure 26. System process.........................................................................................................................58
Figure 27.overall system of the service.....................................................................................................59
Figure 28.overall system activity diagram for manager.............................................................................59
Figure 29.overall system activity diagram for technician..........................................................................60
Figure 30.overall system activity diagram for customer service expert.....................................................60
Figure 31.overall system activity diagram for customer............................................................................61
Figure 32.Subsystem decomposition.........................................................................................................61
Figure 33. hardware and software mapping..............................................................................................63
Figure 34.object bill mapping....................................................................................................................63
Figure 35.object customer mapping..........................................................................................................64
Figure 36.object service expert mapping...................................................................................................64
Figure 37.object history mapping..............................................................................................................65
Figure 38object maintenance mapping.....................................................................................................65
Figure 39.object manager mapping...........................................................................................................65
Figure 40.object meter mapping...............................................................................................................66
Figure 41. object report mapping..............................................................................................................66
Figure 42. object request mapping............................................................................................................67
Figure 43.object technician mapping........................................................................................................67
Figure 44.deployment diagram.................................................................................................................70
VII
TABLES
Table 1.TeamComposition..........................................................................................................................2
Table 2 Task and Schedules........................................................................................................................7
Table 3. Private customer tariff...................................................................................................................9
Table 4 Commercial Sectors tariff.............................................................................................................10
Table 5 Private government and NGO sectors tariff..................................................................................10
Table 6. Community sectors tariff.............................................................................................................10
Table 7. Hydrant tariff...............................................................................................................................10
Table 8. Use case description for register customer..................................................................................25
Table 9.Use case description for update customer...................................................................................26
Table 10.Use case description for delete customer...................................................................................27
Table 11.Use case description for assign technician..................................................................................28
Table 12.Use case description for record meter reading...........................................................................28
Table 13.Use case description for approve maintenance..........................................................................29
Table 14. Use case description for approve maintenance.........................................................................30
Table 15.Use case description for account update....................................................................................30
Table 16.Use case description for Delete Account....................................................................................31
Table 17.Use case description for View report..........................................................................................32
Table 18.Use case description for make payment.....................................................................................33
Table 19. Use case description for View history........................................................................................33
Table 20.Use case description for Send Report.........................................................................................34
Table 21.Data Dictionary...........................................................................................................................35
Table 22.Subsystem decomposition description.......................................................................................64
Table 23.Access control matrix table for login, manage account, assign technician, record, record meter
reading, manage customers, approve maintenance.................................................................................67
Table 24.Access control matrix table for register meter, view report, make payment, send request.......67
VIII
CHAPTER ONE
1.1 Introduction
Now days, clean water is one of human’s necessity to stay alive and many companies across the
world proved this necessity to their customers. And customers pay monthly bill for their
consumption. Paying a utility bill in Ethiopia and most developing nations is time consuming. It
takes more than a quarter a day or more, to pay a utility bill in most of these nations with queues
usually several meters long in any of water supply service office. On most days, the water supply
offices are ﬁlled with long queues of hundreds of individuals waiting to pay a range of these bills
in cash. A lot of unproductive hours are spent queuing up to pay and also to make simple
inquiries or receive responses. These reasons actually dominate the customers’ reasons for the
branch visits, making the whole payment process needlessly complicated. On the other hand,
the utility company is also tasked to a greater extent with receiving, reviewing, tracking and
manually clearing each bill, which is and continues to be a laborious time intensive undertaking.
1.2 Background
The water supply history of the Adama Town begins in early 1940’s EC and transferred to the
newly established WSSA, under the Military Government, in 1975 EC thereafter, the supply
system was in action by WSSA until it was run again by the new Federal Democratic
Government taking power from Guinbot 1983 EC.
Now WSSA provides water to about 67,392 customers where about 66,092 are active customers
and 1,300 who are not active. WSSA has now 6 branches in Adama.
1. Head office (Mebrat)
2. College (in front of ASTU main gate)
3. Amede
4. Genb
5. Dukete
6. Aba Geda
1.3 Statement of the project

There is already a computerized system in WSSA which is a server-based desktop application. In
the system every employee does his job as the system provides. key problem of WSSA’s is the
bill payment system customers have to go to WSSA’s branches directly and spent queuing up to
pay .customers waste a lot of unproductive time, Therefore in this project customers are able to
pay their bill from anywhere just using their mobile phone so that it can save the time wasted to
pay their bills and also this system enables an error free billing system.
1|Page
1.4 Team Composition
Title Water utility mobile billing system
Name Email Roll
Mama Mohammed [email protected] Coordinate and lead the

Members, Design,
Architecture,
Documentation
Team
composition
Mubarek Ismael Requirement Analysis,
Design, Architecture,
implementation and
Documentation
Muhidin Misbah Requirement Analysis,

implementation and
Documentation
Seid Shemsu Requirement Analysis,

implementation and
Documentation
Shemsedin Seifedin Requirement Analysis,

implementation and
Documentation
Advisor Ins: Anteneh A.

Table 1.Team Composition
2|Page
1.5 Objectives of the project

1.5.1 General Objective
The main objective this project is to develop a mobile billing and full customer system for
WSSA.
1.5.2 Specific Objective
Analyze the existing system

Develop well organized data base system to store the customer’s information or data and
also to add new customers and to update the customer’s information or data.
To give fast and accurate access for customers
To design Web based Application for customers
To design a mobile application for online bill payment for customers.
Collecting data about the organization
1.6 Feasibility
1.6.1 Operational Feasibility
This system brings better achievement for the operations performed in serving its customers. So
that one can say that the system is operationally feasible.
This project does not violate rules and regulations of the governments as well as the
organization (WSSA). The system being built is for the sake of productivity of the organization,
so that the project is legally feasible.
1.6.1 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.
Increase accuracy
It minimizes the work load of the employee
Error reduction
3|Page
Reduction of time for bill payment

Increase speed of activities to the system
Because of these benefits this project is economic feasibility.
1.7 Scope and Limitations

1.7.1 Scope of the Project
This project includes water billing and customer management web application and mobile billing
system and other related services for customers are: -
Online payment through mobile phone.
Customer registration and retrieval
On the registration of the maintain material.
On the registration of meter reading.
On the registration of the payment.
Bill calculation and printing.
1.7.2 Limitations of the Project
The system is dependent on internet connection.

It is completely dependent on computers and smart phones.
The system needs IT professional, but in our country, there are shortage of computer and
computer teacher.
The system cannot be accessed offline.
1.8 Methodology
1.8.1 Data Collection Methodology
There are different methodologies available for collecting information (data gathering methods)
from the users and administrators of WSSA. During requirement collection methods we have
used some techniques among them:
1) Observation: we observed the existing systems (water billing systems) how it operate and
how customers communicate with the organization (WSSA).
2) Interview: In addition to observation we interview both the customers and the WSSA’s
administrators. We interview that the customers about the problems of the existing
systems and also, we interview the service administrators how they manage and store the
customers information and data. Based on the gathered data from the interview made in
4|Page
the water supply service that has been organize and process, the existing problem has
been identified.
3) Document analysis: Internet and some researches will be used as source to collect
information related to this project.
1.8.2 Development method

Agile modeling method is suitable for this project because of
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable system.
The system mainly depends on code rather than design.
Even if a change is needed in the middle of the development it is possible to make the
change.
Mainly focus on the simplicity of the system.
Lastly this model helps for making a better decision.
1.9 Significance of the system
The main Significance of this system is reduces the customers accessing time to get service from
the organization.
It minimizes the customers losing time when they want to access service from the
organization.
It provides timely information and also Process Customers request on time.
It can easily update customer’s record.
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.
5|Page
1.10 Development Tools

1.10.1 Software Tool
No Tools Used for
1 Android studio Android application development
2 Html 5 web-designing
3 MySQL Database
3 CSS layout design, content decoration in user interface

design
4 PHP Web-designing
4 Java script validating client-side inputs and forms
5 Microsoft word Writing documentation
6 Enterprise architect 12 Diagram
1.11 Overview of the Project Phase
This mobile application project includes the following phases:
Requirements Analysis: This phase begins with analyzing what exactly the system
has to do.
Functional Specification: At this phase, determining what exactly the target system
must do and the premises for its implementation. All requirements should be
thoroughly defined and documented.
Software Architecture and Test Plan: In this phase, it is necessary to determine the
system components covering your requirements and the way these components will
work together.
Implementation (Coding) and Testing: In this phase, developing the mobile
application and making sure it is error free takes place.
6|Page
Release: after the development and testing process is completed the software will be
released.
Maintenance: The task of this phase is the proper functioning of the software. To
improve a product or system, it should be continuously maintained. Software
maintenance involves detecting and correcting errors, as well as extending and
improving the software itself.
1.12 Project Plan

1.12.1 Task and Schedules
Roll phases Required time Tasks
no
1 Requirements One week Combine elements of
planning system planning and
phase system analysis phases.
Members discuss and

agree on project scope,
constraints and system
requirements.
2 User design One week Develop system model
phase and prototypes.
3 Construction Two weeks Focus on program and
phase application development
task.
4 Cutover phase Two weeks Resemble the final task
include testing.
Table 2 Task and Schedules
7|Page
Chapter 2
2.1 Description of the existing system
Currently WSSA uses a computerized system for giving service to its customers. And this
existing system currently performs different activities including registration of new customer,
bill generation, report generation. But the payment of the customers is not in timely manner and
hence the whole system is not properly organized. Even if the customers want to pay there is not
facility to payment method which can be achieved quickly. Paying utility bills for such basic
services like water still takes more than a quarter a day in Ethiopia and many other nations in
Africa. Customers to these utility companies have to spend very unproductive hours queuing to
pay bills in form of cash at the water supply service.
2.2Major Function of the system

The current system performs the following tasks: -
Registration new customers – new customers are registered by the system.
Employment- staffs like payroll payment for the employee is made this system
Bill generating- every progress of a student is recorded and stored
Finance- financial income and budget data of the company are stored
2.2.1 Users of the Current System
The current system has the following users
Administrators
Customers
Employees
IT men
And other workers
2.2.2Drawback of the Current System

Currently, the system of bill payment is totally manual.
The manual system is slow then the computerized system.
It is very time consuming.
It is required more man power to serve all customers.
2.3Business rule Identified in the Existing System
Business rule is a rule in which the organization uses it to perform any activities or
invoice. Water meter is the property of the Authority therefore only the Authority has
the right to install, to remove, to change, transfer and to clean to inspect a water meter.
8|Page
The customer shall notify the authority as soon as he is aware that the meter is broken or
has been damaged.
The Authority shall demand the payment of the water charge from the customer
According to its tariff and the consumption of water as show by the meter.
Unless it is proved that the meter is not making correct reading, or is broken, the reading
shall be accepted by the Authority and the customer.
Where the correctness of the meter is doubtful the customer may request the inspection
of the authority. The authority may also at any time inspect the meter as its own
initiative.
Where the customer fails to pay the require water charge, the Authority shall give him
two consecutive periods of months within punishment and finally the water bill removes
from customers.
2.3.1Forms and other Documents of the Existing System

The following are forms and other documents used in the existing system. Contract for supply
of water: date, full name, address, woreda, kebele, house no, placement no, house phone no,
mobile no, email, service type, purpose of water is to be signature, contract no, power approved,
application tariff, purpose of electricity is to be supply, deposit birr, connector birr, total, receipt,
customer sign and authority sign.
2.3.2 Tables for Current Tariff of Water Consumption
The following table shows current tariff of water consumption for private customers
(households)
Number Consumption Tariff/Birr
1 From 0 - 5 m3 5.25
2 From 6 - 10m3 6.30
3 From 11 - 30m3 7.90
4 From 30m3 and above 8.95
Table 3. Private customer tariff
The following table shows current tariff of water consumption for commercial sectors
Numbe Consumption Tariff/Birr
r
1 From 0 - 5 m3 6.25
9|Page
2 From 6 - 10m3 8.30

3 From 11 - 30m3 9.35
3
4 From 30m and above 10.30
Table 4 Commercial Sectors tariff
The following table shows current tariff of water consumption for private
government and NGO sectors
r
1 From 0 - 5 m3 5.25
2 From 6 - 10m3 6.30
3
3 From 11 - 30m 7.90
3
4 From 30m and above 8.95
Table 5Privategovernment and NGO sectors tariff
The following table shows current tariff of water consumption for community
r
1 From 0 m3 and above 4.25
Table 6. Community sectors tariff
The following table shows current tariff of water consumption for hydrant
Number Consumption Tariff/Birr
1 From 0 m3 and above 9.10
Table 7. Hydrant tariff
2.4Expected Outcomes of the Project
Finally, we expect from our project it saves time, money and energy for customers and
employees. Customers can get quick and fair access of WSSA water supply. Our system can
give satisfaction for employees and Customers because the system avoids fault activities.
10 | P a g e
CHAPTER THREE
3. Proposed system
3.1 overview:
The proposed system solves the problem of the existing system. The main aim of the proposed
system is to implement web-based water billing and customer service management system for
WSSA which allows easily register customer, maintenance order request, search payment, and
generate report. So, the proposed system benefits both customers and the water supply service.
3.1.1 Functional Requirements:
WSSA mobile bill payment and employee management system is an android and web-
based system for Adama city administration water supply and swage service enterprise.
The WSSA mobile bill payment application provides the amount of bill that a customer
expected to pay receiving the data from the WSSA server through the internet.
The WSSA mobile bill payment provides application the customer to make a
maintenance request to the enterprise through the internet from anywhere.
The WSSA mobile bill payment provides the customer with the history of the bill that the
customer paid.
The system calculates the consumption of water utility of the customer based on the type
of the customer and generate bill for every customer including the penalty.
The system provides access to the manager to register, update or remove employees from
the system. And also, the system enables the Customer service expert to register, update
or remove customers from the system.
3.1.2. Non-Functional Requirements
1) Reliability:
The system shall be available 24 hours a day, 7 days a week
11 | P a g e
The system shall always provide real time information about bill availability
information.
The system shall be robust enough to have a high degree of fault tolerance. For
example, if the customer enters an invalid customer Id, the system should not
crash and shall identify the invalid input and produce a suitable error message.
The system shall be able to recover from hardware failures, power failures and
other natural catastrophes and rollback the databases to their most recent valid
state.
2) Usability:
The system shall provide an easy-to-use graphical interface similar to other
existing billing system so that the customers do not have to learn a new style of
interaction.
The web interface should be intuitive and easily navigable Users should be able to
understand the menu and options provided by the system.
Any notification or error messages generated by ARS shall be clear, polite.
3) Authentication Requirement:
The system support user name and password to authentic.
Users need to be authenticated before having access to any personal data.
The system should be secure and must use encryption to protect the databases.
4) Error handling requirement:

The system has error handling mechanisms that is, as errors occur it will not stop
functioning rather provide error manages and back to the previous page to give
chance to reenter data and process the task by beyond the error.
5) Scalability:
The system should handle about 70,000 of customers record and any increase in
the number of users shall not degrade system availability to an extent noticeable
by any users.
6) Performance requirement:
Response time of the WSSA System should be less than 2 second most of the
time. Response time refers to the waiting time while the system accesses, queries
and retrieves the information from the databases.
The WSSA system shall be able to handle at least 1000 transactions/inquiries per
second.
12 | P a g e
3.2 System Model

Scenarios
Scenario: 1
Name of scenario: Register customer
Participating actors: Customer service expert
Entry condition:
Internet connection should be available.
They have to navigate to organization’s URL
The user should have valid username and password and must login
Flow of events:
1. The customer service expert logs into his/her page
2. Chooses register new customer tab from the category
3. The customer service expert enters all the necessary information
4. The customer service expert fills the table and click ADD button
5. The system displays a success message to the customer service expert
Exceptional flow:
if the customer service enters wrong information or did not entered required information the
system will display wrong input message
Scenario: 2
Name of scenario: update customer
Participating actors: customer service expert
Entry condition:

They have to navigate to organization’s URL.
The user should have valid username and password
Flow of events:
1. The user opens the system

2. Chooses manage customer tab
3. The system displays category to choose target
4. The user chooses target group and choose specific user
5. Looks into users’ profile and edits if needed
6. Clicks UPDATE button
13 | P a g e
Scenario: 3
Name of scenario: Delete Customer
participating actors: Customer Service expert
Entry condition:

They have to navigate to organization’s URL
Flow of events:

2. Chooses manage customer tab
3. The system displays category to choose target
4. The user chooses target group and choose specific user
5. Clicks DELETE button to remove the customer for active customer list.
Exceptional flow:
if the customer service delete wrong customer he/she can undo the deleted customer.
Scenario: 4
Name of scenario: assign technician
Participating actors: Customer Service expert
Entry condition:
Flow of events:

2. Chooses request maintenance tab
3. The system provides the user with a form to be filled
4. The user clicks REQUEST MAINTENANCE button to assign the maintenance
Scenario:5
14 | P a g e
Name of scenario: Record meter reading

Participating actors: Technician
Entry condition:
The user should have valid username and password and must login
Flow of events:
1. The technician logs into his page.
2. Chooses meter reading tab from the category.
3. The system displays query table to choose target.
4. The user chooses customers name.
5. The technician enters all the necessary information.
6. The system displays customer’s database for that specific target.
7. The system displays table of meter reading for that customer.
8. The technician fills the table and click SAVE button
Exceptional flow:
if the technician records incorrect meter reading, he/she can correct it by clicking EDIT button
Scenario: 6
Name of scenario: Approve maintenance
Entry condition:
The maintenance must be requested
Flow of events:
1. The technician logs into his page
2. Chooses approve maintenance tab from the category
3. The system displays the requested problem and customer information to the technician
4. The technician checks the problem and customers information
5. Technical takes the request from the customer.
6. The technician fills the information and click APPROVE button
15 | P a g e
Scenario: 7
Name of scenario: Register meter
Entry condition:
Flow of events:
1. The technician logs into his page

2. Chooses register meter tab from the category
3. The system displays the requested meter and customer information to the technician
4. The technician checks the meter and customers information
5. The technician fills the information and click SAVE button
Scenario: 8
Name of scenario: Login
Participant actors: all users
Entry condition:

If they are WASSA employees they have to navigate to WASSA URL.
If they are customers, they have to open their installed WASSA app.
They should submit a valid username and password.
Flow of event:
1. The use opens the login page.
2. Enters username and password.
3. Clicks login button.
4. The user gets appropriate page.
5. If the user forgets his/her username/password, then click forgot password
6. Username link.
7. Password recovery page will be displayed.
Exceptional flow:
If the user enters invalid username and password, the system notifies to enter the correct one.
Scenario:9
Name of scenario: create account.
16 | P a g e
Participant actors: Manager

Entry condition:
If they are WASSA employees they have to navigate to WASSA URL.
She/he should submit a valid username and password.
Flow of event:
1. Login page is presented.
2. Manager fills the required fields.
3. Click on the create tab.
4. Fills the required spaces.
5. Click create button.
6. Verification for success will display.
Exceptional condition:
If the manager did not fill all required fields or filled incorrect it will load the create tab with
error message.
Scenario: 10
Name of scenario: update account.
Entry condition:

They have to navigate to WASSA URL.
Flow of condition:
3. Click on the create tab.
4. Fills the required spaces.
5. Click update button.
Exceptional condition:
If the manager did not fill all required fields or filled incorrect it will load the update
tab with error message.
Scenario: 11
Name of scenario: delete account.
Entry condition:
17 | P a g e

Flow of condition:
3. Click on the delete tab.
4. Select from employees.
5. Click delete button.
Scenario: 12
Name of scenario: view report.
Entry condition:

Flow of condition:
3. Click on the view report tab.
4. Report will be displayed.
Scenario: 13
Name of scenario: make payment
Participating actors: customer
Entry condition:

The user should have the application.
Flow of events:
1. The user opens the application

2. Enter customer_id and password
3. Click view payment button
4. The system displays current payment value of customer.
18 | P a g e
5. Click pay button
Exceptional flow:
 If the user enters invalid customer_id or password the application will toast incorrect
customer_id or password message.
 If the user does not have sufficient balance the application will toast insufficient balance
message.
Scenario: 14
Name of scenario: view history
Entry condition:

The user should have valid customer_id and password.
Flow of events:
1. The user opens the application.
3. Click history button
4. The application will display payment history of the customer.
Exceptional flow:
 If the user enters invalid customer_id or password the application will toast incorrect
customer_id or password message.
Scenario: 15
Name of scenario: send request
Entry condition:
The user should have valid customer_id and password.
Flow of event:
1. The user opens the application.
3. Click send request button
4. Write description of the problem
19 | P a g e
5. Click submit
Exceptional flow:
If the user enters invalid customer_id or password the application will toast incorrect
customer_id or password message.3.2.2 Use case models
3.3 Actor Identification
Figure 1. Actor Identification
20 | P a g e
3.3.1 Use Case Identification:

Our system includes the following use cases: -
View payment
View Maintenance Assigned Date
Request Maintenance Order
Login
Maintenance Request
Payment record
Bill Calculate
Accept Maintenance
Generate Report
Maintenance approves
Record meter reading
View history
Assign technician
Delete Customer
Update customer
Register customer
Register meter
Create Account
Account update
Delete Account
View report
Bill payment
21 | P a g e
3.4 Use Case Diagram
Figure 2. Use Case Diagram
22 | P a g e
3.5 Use Case Description
Use case description for register customer
Use case name Register customer

Description It registers a new customer and fills the data to the database.
Actor Customer Service expert
Pre-condition Customer service expert first login using its own username and password
post condition Data of new customer saved into database
Racecourse action 1. Customer service expert opens the home page.
(Flow of event): 2. Customer service expert enters its own username and password to login.
3. Customer service expert clicks the register new customer button
4.Enter the correct & all necessary information.
5. Initiate the system to sends to the organization.
6. The use case ends.
Exceptional flow If the user enters invalid username or password the application will toast
incorrect username or password message.
-if the expert enters invalid information the system will display invalid input
message.
Table 8. Use case description for register customer
Use case description for update customer
23 | P a g e
Use case name Update customer

Description It allows to update the data of the customers.
Actor Customer service expert
Precondition The user must login to Customer service expert page
Post- condition The information of the customer will be updated and saved to the
database.
Basic course of action 1. Customer service expert open the Customer service page
(Flow of event): 2. Customer service expert inserts the login address on the page.
3. the Customer service expert finds the customer using the find button
4. the Customer service expert updates and saves the update
5.End use case
Exceptional flow - If the user enters invalid username or password the application will
toast incorrect username or password message.
-if the customer does not exist display no match found message and
return to step 3.
Table 9.Use case description for update customer
Use case description for delete customer
Use case name Delete Customer

Description It removes customer from the service.
Precondition The Customer service expert must login to customer service page
Post- condition The customer would be removed from the active customer list
24 | P a g e
3. the Customer service expert finds the customer using the find button
4. the Customer service expert removes the customer
5.End use case
-if the customer does not exist display no match found message and
return to step 3.
Table 10.Use case description for delete customer
Use case description for assign technician for maintenance
Use case name Assign technician

Description It requests for maintenance to the technician
Precondition The Customer service expert must login to customer service page
Post- condition Request would be sent to the Technician page
4. Customer service expert clicks Request maintenance button
5. Enter the correct & all necessary information
5. clicks request button.
6.End use case
25 | P a g e
-if there is no request maintenance display no request message return
to step 3
Table 11.Use case description for assign technician
Use case description for record meter
Use case name Record meter reading

Description It allows meter reading to register to the database.
Actor Technician
Pre-condition Technician first login using its own username and password
post condition Technician registers the meter reading into database
Racecourse action 1. Technician opens the home page.
(Flow of event): 2. Technician enters its own username and password to login.
3. Technician clicks the record meter reading link.
4.Ente the correct & all necessary information.
5. Initiate the system to sends to the organization.
6. The use case ends.
Exceptional flow -if the technician records incorrect meter reading display invalid input
message and return to step 4.
Table 12.Use case description for record meter reading
26 | P a g e
Use case description for Approve maintenance
Use case name Approve maintenance

Description It allows receive and approve customer maintenance request process.
Actor Technician
Precondition 1.The customer should ask the request maintenance
2.The user must login to technicians’ page
Post- condition Customer maintenance request should be transferred and service being
delivered.
Basic course of action 1.Technician open the technician page

(Flow of event): 2. Technician inserts the login address on the page.
3. System validates the address.
4. Technician checks and see the problem.
5. Technician Approves the request.
6.End use case
-if the customer did not send any maintenance request the system
displays no request is detected message and return to step 1.
Table 13.Use case description for approve maintenance
Use case description for Approve maintenance
27 | P a g e
Use case name Register meter

Description It allows the customer maintenance request process.
Actor Technician
Precondition The Technician must login to technicians’ page
Post- condition The new meter registered in the database of the organization
Basic course of action 1.Technician open the technician page

(Flow of event): 2. Technician inserts the login address on the page.
3. System validates the address.
4. Technician enters the required information.
5. Finally the technician clicks save button.
6. End use case
Table 14. Use case description for approve maintenance
Use case description for updating account
Use case name Account update.

Description It allows the manager to update employee account.
Actor Manager.
Precondition The account must be presented in the System data base.
Basic course of action Step1.The manager wants to update account.
(Flow of event):
Step2.The system displays update account page.
Step3.The manager fills the required information and submits
it.
Step4.The system validates the information.
Step5.The system update the employee into the system
database.
Step6.The system displays confirm message.
Step7.The use case ends.
Post-condition The user account successfully updated.
Table 15.Use case description for account update
Use case description for delete account.
28 | P a g e
Use case name Delete Account
Description It Allows Manager to delete employees account
Actor Manager
Precondition To delete the employees account must be registered in the

database.
Basic course of action (Flow Step1.The Manager wants to delete account.
of event): Step2.The system displays the delete account page.
Step3. The Manager press on delete button.
Step4.The system validates the information.
Step5.The account is deleted from the system.
Step6.The system displays confirm message.
Step7. The use case ends.
From the above steps Step 1 and step 3 Actors action whereas
Step 2 Step 4, Step 5, Step 6 and Step 7 System response.
Post- condition The user account successfully deleted.

Exceptional flow If the selected account is invalid.
1. The system displays error message.
2. Go to step2 to select the delete account again.
Table 16.Use case description for Delete Account
Use casedescriptionfor view report.
Use case name View report
29 | P a g e
Description It allows viewing report from the experts.

Actor Manager
Pre-condition They should have prepared data by the employee of the
organization.
Post-condition The manager sees the report prepared by the office employees.
Basic course of action Step1. The manager opens the home page.
(Flow of event): Step2. The manager Enter his/her user name and password.
Step3. System validates the address.
Step4. The manager View the prepared report.
Step5. End use case.
From the above steps Step 1, Step 2 and Step 4 Actors action
whereas Step 3, and Step 5 System response
Exceptional flow - If the user enters invalid username or password the application
will toast incorrect username or password message.
Table 17.Use case description for View report
Use Case description for make payment
Use case name Make payment
30 | P a g e
Use case description To pay monthly payment of the bill

Actor Customer
Pre-condition User must be registered on database of service provider
Post-condition Display history of payment
Main flow 1. The user opens the application
3. Click view payment button
4. The system displays current payment value of customer.
5. Click pay button
Exceptional flow  If the user enters invalid customer_id or password the
application will toast incorrect customer_id or password
message.
Include Login
Business rule -
Frequency of use When needed
Table 18.Use case description for make payment
Use Case description for View history
Use case name View history

Use case description To see history of payments of each month
Actor Customer
Pre-condition User must be registered on database of service provider, login
Post-condition Display all history of payment
Main flow 1. The user opens the application.
3. Click history button
4. The application will display payment history of the
customer.

application will toast incorrect customer_id or password
message.
Include -
Business rule -
Table 19. Use case description for View history
Use Case description for Send Request
Use case name Send request

Use case description To make report for maintenance
Actor Customer
31 | P a g e
Pre-condition User must be registered on database of service provider

Post-condition The system will send report to customer service expert
Main flow 1. The user opens the application.
3. Click send request button
4. Write description of the problem
5. Click submit

application will toast incorrect username or password message.
Include login
Business rule -
Table 20.Use case description for Send Report
3.6 Object Model

3.6.1 Data Dictionary
Class Attributes Operations Description

Customer Name, password, makeRequest(), To make request,
address, id, account, payBill(), viewHistory() payment and view
phone history
History amount, getAmount(),getDate(); To show payment
Date ,Cid getCid() history
Request customerID, getId(),getDate(),getCId( To send request
Date, id ) for assistance
Technician Name, address, email, approveMaintenance(), To approve
password, username, readMeter(), maintenance, to
salary` registerMeter() read and register
meter
Bill Amount, date, id getAmount(),getDate(), To generate and
getId(), pay bill,
Report Date, id,text getText(),getDate(), To read and write

getId() report
Maintenance Approval, date,id getId(),getDate(); To approve
maintenance
32 | P a g e
Meter Id, type, usage getId(),getDate(), To register and

getUsage(), register meter
Manager Name,id,salary,address, create(),update(),delete(), To manage
Email, username, viewReport() employees and
password, view report
ServiceExpert Name,id,salary,address, assignTechnician(), To generate report,
Email, username, generateBill(), bill, view
password viewRequest(), customer requests,
generateReport() and assign
technician
Table 21.Data Dictionary
3.7Dynamic Model
3.7.1 Sequence Diagrams
Sequence diagrams in the UML are primarily used to model the interactions
between the actors and the objects in a system and the interactions between the
objects themselves. As the name implies, a sequence diagram shows the sequence
of interactions that take place during a particular use case or use case instance. The
objects and actors involved are listed along the top of the diagram, with a dotted
line drawn vertically from these. Interactions between objects are indicated by
annotated arrows. The rectangle on the dotted lines indicates the lifeline of the
object concerned. The annotations on the arrows indicate the calls to the objects,
their parameters, and the return values.
Sequence diagram for login
33 | P a g e
Figure 3.Sequence diagram for login
34 | P a g e
Sequence diagram for register customer
Figure 4.Sequence diagram for register customer
35 | P a g e
Sequence diagram for update customer
Figure 5.Sequence diagram for update customer
36 | P a g e
Sequence diagram for delete customer
Figure 6.Sequence diagram for delete customer
37 | P a g e
Sequence diagram for make payment
Figure 7.Sequence diagram for make payment
38 | P a g e
Sequence diagram for send request
Figure 8.Sequence diagram for send request
39 | P a g e
Sequence diagram for view history
Figure 9.Sequence diagram for view history
40 | P a g e
Sequence diagram for meter reading
Figure 10.Sequence diagram for meter reading
41 | P a g e
Sequence diagram for approve maintenance
Figure 11.Sequence diagram for approve maintenance
42 | P a g e
Sequence diagram for create employee account
Figure 12.Sequence diagram for create employee account
43 | P a g e
Sequence diagram for update employee account
Figure 13.Sequence diagram for update employee account
Sequence diagram for delete employee account
44 | P a g e
Figure 14.Sequence diagram for delete employee account
45 | P a g e
Sequence diagram for view report
Figure 15.Sequence diagram for view report
3.8 Class Diagram
The Class diagram captures the logical structure of the system; the classes and things that make
up the model. It is a static model, describing what exists and what attributes and behavior it has,
rather than how something is done. Class diagrams are most useful to illustrate relationships
between classes and interfaces.
46 | P a g e
Figure 16.Class diagram
3.9Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. And show the overall flow of control.
Activity diagrams are constructed from a limited number of shapes, connected with arrows. The
most important shape types:
 rounded rectangles represent actions;
 diamonds represent decisions;
 a black circle represents the start (initial node) of the workflow;
 an encircled black circle represents the end (final node).
 arrows run
47 | P a g e
Activity diagram for customers
Figure 17.Activity Diagram for customers
48 | P a g e
Activity diagram for customer service expert.
49 | P a g e
Figure 18.Activity Diagram for customer service expert
Activity diagram for technician
50 | P a g e
Figure 19.Activity Diagram for technician
Activity diagram for manager
Figure 20.Activity Diagram for manager
51 | P a g e
3.10 State Diagram
State diagram for pay bill
Figure 21.State diagram for pay bill
52 | P a g e
State diagram for view history
Figure 22.state diagram for view history
53 | P a g e
State diagram for create employee account
Figure 23.state diagram for create employee account
54 | P a g e
Chapter 4
4. System design
4.1 Introduction
This System Design Document has been created to outline the proposed system design for new
WSSA. The WSSA is intended to create a user-friendly and powerful tool for customers and
employee of WSSA Corp. By designing, testing, and deploying the WSSA, WSSA Corp. will
improve its capabilities in maintenance management, tracking, and reporting efficiency in
serving customers. This document and the technical specifications listed herein comply with all
WSSA Corp. technical standards and infrastructure.
4.2 Overview of System design

This document describes the design issues of the overall system, such as design goal, subsystem
decomposition, hardware/software mapping, and persistent data management. It provides the
complete architecturaloverview of the proposed system. It is intended to capture and express the
significant architectural decisions, which have been made, on the system
4.2.1 Purpose of the system design
The purpose of this System Design Document is to provide a description for how the new WSSA
will be constructed. The Systems Design Document was created to ensure that the WSSA design
meets the requirements specified in the WSSA project requirements documentation. The System
Design Document provides a description of the system architecture, software, hardware, database
design, and security.
4.2.2 Design Goal
The new WSSA tool will provide the following capabilities:
Integration of all maintenance data which allows for real-time report generation and
simplifies management of all maintenance activities.
Enhanced and additional user interfaces which provide users with much simpler data
entry, updates, queries, and other capabilities.
It will be integrated with latest security methods.
55 | P a g e
We will make it as easy as possible by removing all unnecessary things, and it will be
straight forward.
Since the application is built directly for the aimed person it will be very flexible.
Crashes can happen, but it will be recovering fast.
4.3 Proposed System architecture
Figure 24. proposed system architecture
4.3.1 System process
56 | P a g e
Having identified and described the components of WSSA, it may be necessary to show the
overall
Processes for the system
Figure 25. System process
57 | P a g e
Figure 26.overall system of the service
Figure 27.overall system activity diagram for manager
58 | P a g e
Figure 28.overall system activity diagram for technician
Figure 29.overall system activity diagram for customer service expert
59 | P a g e
Figure 30.overall system activity diagram for customer
4.3.2 Subsystem Decomposition
Figure 31.Subsystem decomposition
60 | P a g e
4.3.3 Subsystem decomposition description
Subsystem Purpose Class

Manager  Manage employee  Manager
 Login  Expert
 View report  Technician
 Logout  Report
Customer  Pay bill  Customer

 View history  Bill
 Request maintenance  Meter
 Login  History
 logout  Request
Technician  Read meter  Technician

 Log in  Meter
 Register meter  Maintenance
 Approve maintenance
 Log out
Expert  Manage customer  Expert

 Assign technician  Request
 View request  Report
 login  Bill
 Bill generates  Customer
 Make report
 logout
Table 22.Subsystem decomposition description
4.3.4Hardware/Software mapping
61 | P a g e
Figure 32. hardware and software mapping
4.3.5 Persistent data management
Figure 33.object bill mapping
62 | P a g e
Figure 34.object customer mapping
Figure 35.object service expert mapping
63 | P a g e
Figure 36.object history mapping
Figure 37object maintenance mapping
Figure 38.object manager mapping
64 | P a g e
Figure 39.object meter mapping
Figure 40. object report mapping
Figure 41. object request mapping
65 | P a g e
Figure 42.object technician mapping
4.3.6 Component diagram
Component diagrams show how the physical components of a system are organized. And also
shows which component or objects will be accessed by whom and what type of security
infrastructures it is using. Again
It’s used to:
 Visualize the components of a system.

 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.
The diagram is simulated below.
66 | P a g e
4.3.7 Database Design
4.3.8 Deployment diagram

Deployment modeling is used to show the hardware of the system, the software that is installed
in the hardware and also shows how the software and the hardware components work together.
Deployment diagrams are used to visualize the topology of the physical components of a system,
where the software components are deployed. And used to describe the static deployment view
of a system.
The purpose of deployment diagrams can be described as:
Visualize the hardware topology of a system.
Describe the hardware components used to deploy software components.
Describe the runtime processing nodes.
Figure 43.deployment diagram
67 | P a g e
4.3.9 Access control
Actors log in Manage Assign Record Manage Approve

account technician meter customers maintenance
reading
Manager log_in () create_user()
update_user ()
delete_user()
Customer log_in ()
Customer log_in () get_request () create_customer
service send_request () ()
expert update_customer
()
delete customer
()
Technician log_in () record approve ()
meter ()
Table 23.Access control matrix table for login, manage account, assign technician, record, record meter reading, manage
customers, approve maintenance.
Actors Register View report Make View history Send request

meter payment
Manager view_report ()
search ()
get_consumption ()
customer_list ()
employee-list ()
budget ()
history ()
Customer check () view_history () check ()
pay () check () send ()
is_pay ()
Customer
service expert
Technician register ()
Table 24.Access control matrix table for register meter, view report, make payment, send request.
68 | P a g e
Reference
 Prentice Object Oriented Software Engineering Using UML Patterns and Java 3rd 2012
 www.google.com
 www.bing.com
 www.draw.io
 www.youtube.com
 Last year documentations
69 | P a g e

Adama Science and Technology University School of Electrical Engineering and Computing Computer Science and Engineering Department

Uploaded by

Copyright:

Available Formats

Adama Science and Technology University School of Electrical Engineering and Computing Computer Science and Engineering Department

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

Adama Science and Technology University School of Electrical Engineering and Computing Computer Science and Engineering Department

Uploaded by

Copyright:

Available Formats

Mobile Billing and Employee Management system for WSSA

Adama science and Technology University

School of Electrical Engineering and

Computer science and engineering department

FSE project for 3rd year 1ST semester

MOBILE BILL PAYMENT AND EMPLOYEE

1. Mama Mohammed ………………………..A/ur4867/09

Submitted to: Inst. Anteneh Alemu

WSSA……………………Adama city administration water supply and

HTML……………………Hyper Text Markup Language

CSS………………………Cascading Style Sheet

SQL……………………. Structural Query Language

PHP……………………. Hypertext Processor

UML…..........................Unified Modeling Language

2.2.1 Users of the Current System.......................................................................................................8

4.3.1 System process.........................................................................................................................60

Figure 24.state diagram for create employee account..............................................................................55

1.3 Statement of the project

1.4 Team Composition

Title Water utility mobile billing system

Name Email Roll

Mama Mohammed [email protected] Coordinate and lead the

Muhidin Misbah Requirement Analysis,

Seid Shemsu Requirement Analysis,

Shemsedin Seifedin Requirement Analysis,

Advisor Ins: Anteneh A.

1.5 Objectives of the project

1.5.2 Specific Objective

Analyze the existing system

1.6.1 Operational Feasibility

1.6.1 Economic Feasibility

Reduction of time for bill payment

Because of these benefits this project is economic feasibility.

1.7 Scope and Limitations

1.7.2 Limitations of the Project

The system is dependent on internet connection.

1.8.2 Development method

1.9 Significance of the system

1.10 Development Tools

1 Android studio Android application development

3 CSS layout design, content decoration in user interface

4 Java script validating client-side inputs and forms

5 Microsoft word Writing documentation

6 Enterprise architect 12 Diagram

1.11 Overview of the Project Phase

This mobile application project includes the following phases:

1.12 Project Plan

Members discuss and

2.2Major Function of the system

2.2.2Drawback of the Current System

2.3Business rule Identified in the Existing System

2.3.1Forms and other Documents of the Existing System

2.3.2 Tables for Current Tariff of Water Consumption

2 From 6 - 10m3 8.30

2.4Expected Outcomes of the Project

3.1.1 Functional Requirements:

3.1.2. Non-Functional Requirements

4) Error handling requirement:

3.2 System Model