Final Documentation

SAMARA UNIVERSITY
COLLEGE OF ENGINEERING AND TECHINOLOGY

DEPARTMENTOF COMPUTER SCIENCE
TITLE:-SAMARA ONLINE POST OFFICE MANAGEMENT SYSTEM
NAME ID
1. HAMZA MUHAMMED 0044/07
2. YOHANIS YADETA 0095/07
3. HIRUT ASSEFA 0178/07
4. MUSSA GOBENA 0063/07
5. IYASU IDOSA 0049/07
6. SENAYT GIRMAY 0075/07
ADVISOR NAME: ……………….
FINAL PROJECT SUBMITED TO DEPARTMENT OF COMPUTER SCIENCE IN PARTIAL

FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF BACHELOR OF
SCIENCE IN COMPUTER SCIENCE
JUNE, 2017,
SAMARA UNIVERSITY, ETHIOPIA

SAMARA ONLINE POST OFFICE MANAGEMENT SYSTEM
Acknowledgment
We would to thanks god you arrive us the graduation year and then today we also thanks starting
from our department and faculty to give us a letter which helps to collect or gather requirements.
And we also thanks last year software instructor which help us by learnt the way of writing
documentation. And also we would to thanks our Adviser instructor WELDAY to advise us by
devoting there time.
Page I
Abstract
The mail or post is a system for physically transporting documents and other small packages; or,
the postcards, letters and parcels themselves. Usually government runs system by which letters,
packages and other material are transported and delivered to individuals and organization. This
project examines the issue related to Samara Online Postal Office Management System and its
contribution for all employees of all organization and Customers. The Main objectives for this
project is to devote to be automatic system of Samara Online Postal Office Management System
and also keep employees or Customers information in efficient, reliable or secured way, consume
and minimize time wasted to get service, get employees or customers information as quickly as
possible when an authorized or unauthorized person wants some task related to automatic employee
registration. This will enable the country to give appropriate and efficient services to its customers
and to achieve the customers need or went.
Page II
Table of contents
Acknowledgment_______________________________________________________________I
Abstract______________________________________________________________________II
List of figures_________________________________________________________________V
List of tables__________________________________________________________________VI
Abbreviation_________________________________________________________________VII
CHAPTER ONE_______________________________________________________________1
1. INTRODUCTION____________________________________________________________1
1.1 Background of the Study__________________________________________________________1
1.2 Introduction about the Project_____________________________________________________2
2. Literature Review____________________________________________________________2
3 .Statement of the Problem______________________________________________________3
4 .Objective of the Project________________________________________________________4
4.1 General Objective________________________________________________________________4
4.2 Specific Objective________________________________________________________________4
5. Significance of the project_____________________________________________________4

6. Scope and limitation__________________________________________________________5
6.1 Scope__________________________________________________________________________5
6.2 Limitation______________________________________________________________________5
7. Methodology________________________________________________________________6
7.1Data Gathering Methodology_______________________________________________________6
7.2 Development Methodology_________________________________________________________7
7.3 Development Approaches__________________________________________________________8
7.4 Development Tools_______________________________________________________________9
7.4.1 Hardware Tools_______________________________________________________________________9
7.4.2 Software Tools________________________________________________________________________9
7.5 Testing Methodology____________________________________________________________10
CHAPTER TWO______________________________________________________________11
2. REQUIREMENT ELICITATION______________________________________________11
III
2.1Overview of the Existing System___________________________________________________11

2.1.1 Problem of the existing system________________________________________________________12
2.1.2 Weakness and strength of the existing system_____________________________________________12
2.1.3 Business rules of the system__________________________________________________________13
2.2 Overview of the proposed System__________________________________________________14

2.2.1 Functional Requirement of the proposed system_____________________________________________14
2.2.2 Non Functional requirements of the proposed system_________________________________________15
2.2.3 System Requirement of the proposed system_______________________________________________16
2.3 Constraints and assumptions______________________________________________________16

2.3.1 Constraints__________________________________________________________________________16
2.3.2 Assumptions_________________________________________________________________________17
CHAPTER THREE____________________________________________________________18
3. SYSTEM MODELING_______________________________________________________18
3.1 Use Cases Identification__________________________________________________________18
3.2 Use case diagrams_______________________________________________________________20
3.2.1 Actors specification___________________________________________________________________20
3.2.2 Use Case Description__________________________________________________________________21
3.3 Sequence Diagram_______________________________________________________________59

3.4 Class Diagram___________________________________________________________________75
IV
List of figures
Figure 1 Iterative Approach.........................................................................................................................8

Figure 2 The proposed System Use Case Diagram....................................................................................58
Figure 3 Sequence Diagram For Login......................................................................................................60
Figure 4 Sequence Diagram for Create Account.......................................................................................61
Figure 5 Sequence Diagram For Paying Pension.......................................................................................62
Figure 6 Sequence Diagram For Register Material....................................................................................63
Figure 7 Sequence Diagram For Register Sent Airmail.............................................................................64
Figure 8 Sequence Diagram For Register Receive Airmail.......................................................................65
Figure 9 Sequence Diagram for Register Rent Post Box...........................................................................66
Figure 10 Sequence Diagram For Check Track.........................................................................................67
Figure 11 Sequence Diagram For Search Post Box...................................................................................68
Figure 12 Sequence Diagram for Update Post Box...................................................................................69
Figure 13 Sequence Diagram For Delete Post Box....................................................................................70
Figure 14 Sequence Diagram For View Data............................................................................................71
Figure 15 Sequence Diagram For Generate Report...................................................................................72
Figure 16 Sequence diagram For Pay Online............................................................................................73
V
List of tables
Table3. 1 Use case Identification Number.................................................................................................22
Table3. 2 Use case documentation for login..............................................................................................23
Table3. 3 Use case documentation for Create Account.............................................................................24
Table3. 4 Use case documentation for Renting Post Box..........................................................................25
Table3. 5 Use case documentation for Register sent airmail.....................................................................26
Table3. 6 Use case documentation for Register Receive airmail...............................................................27
Table3. 7 Use case documentation for Search airmail...............................................................................28
Table3. 8 Use case documentation for Update airmail..............................................................................29
Table3. 9 Use case documentation for Register material...........................................................................30
Table3. 10 Use case documentation for Search material...........................................................................31
Table3. 11 Use case documentation for Update material...........................................................................32
Table3. 12 Use case Documentation for Delete material...........................................................................33
Table3. 13 Use case documentation for Search Post Box..........................................................................34
Table3. 14 Use case documentation for Update Post Box.........................................................................35
Table3. 15 Use case Documentation for Delete Post Box..........................................................................36
Table3. 16 Use case Documentation Check track......................................................................................37
Table3. 17 Use case Documentation Paying Pension................................................................................38
Table3. 18 Use case Documentation View Feed Back..............................................................................39
Table3. 19 Use case Documentation for Delete Airmail............................................................................40
Table3. 20 Use case Documentation for Generate Report.........................................................................41
Table3. 21 Use case Documentation for Delete User................................................................................42
Table3. 22 Use case documentation for Update User................................................................................43
Table3. 23 Use case Documentation Paying Online..................................................................................44
Table3. 24 Use case documentation for Manage Post Box........................................................................45
Table3. 25 Use case documentation for Manage Post Bus ticket...............................................................46
Table3. 26 Use case Documentation for Change Password.......................................................................47
Table3. 27 Use case documentation for Post Notice..................................................................................48
Table3. 28 Use case documentation for Search User.................................................................................49
Table3. 29 Use case documentation for Assign Sent Mail Cost................................................................50
Table3. 30 Use case documentation for Manage Mail Cost.......................................................................51
Table3. 31 Use case Documentation for Deliver Airmail..........................................................................52
Table3. 32 Use case Documentation for View Delivered Material............................................................53
Table3. 33 Use case Documentation for Register Received Airmail.........................................................54
Table3. 34 Use case documentation for Manage Airmail..........................................................................55
Table3. 35 Use case documentation for Assign Post Bus..........................................................................56
Table3. 36 Use case documentation for Logout.........................................................................................57
Table3. 37 Sequence Diagram For Logout................................................................................................74
VI
Abbreviation
Acronyms Description
BPR Business Process Reengineering
SOPOMS Samara Online Postal Office Management System
EMS Express Mail Service
UPU Universal Postal Union
RAD Requirement Analysis Documentation
HTTP Hyper Text Transfer Protocol
SPO Samara Post Office
VII
CHAPTER ONE
1. INTRODUCTION
1.1 Background of the Study
Prior to the establishment of the postal service in Samara in 1894 correspondences
were conducted through messengers known as “melektegnas” or “postegnas”. These were
hardened individuals who travelled great distances often on foot over coming through terrain
weathering hostile climate. They endured the pangs of hunger and thirst and carried their letters
over their heads on cleft sticks which latter become the symbol of EPS As historical evidences
suggests the emperor of the regime emperor Minilick the second was seriously interested in
introduction of westerns culture and technology as a result in 1890’s he introduce some
communication technology in the country lick constriction of rail ways line and installation of
the first telegraph and telephone lines. Began to use telephones to learn the where about of the
items. The message tacks more than 15 days and week as to reach from one state to another in
the country. But the organization grows gradually and Ethiopia Postal service establish on
March 9, 1894 as Ethiopian postal and telecommunication. In 1908, Ethiopia became member
of the Universal Postal Union /UPU/ and the first Samara stamps were also printed and sold
around this time. The postal and telecommunication offices were separated and Samara Postal
independently established in1953.
Vision
In the year 2015, Samara Post to be known for Excellency in the country and exemplary in the
world.
Mission
To connect the citizens and Institutions among themselves and to the world by
providing quality and economical postal service.
1
1.2 Introduction about the Project

The impact of technology in modern life is immeasurable, we use technology in
different ways and sometimes the way we implement various technologies ends up
changing our lives or the society we leave in. Technology is applied to the roles
each individual fulfills during life. We use technology on a daily basis to
accomplish specific tasks or interests. It means the source of the radical changes
that are happening in all phases of life.
So our System is plays its Owen role to implement and provide technological
system to the society by developing automated Postal Service for Samara. As we
know; now a day everything is done with the help of computer so as to achieve the
Samara Postal Office Mission and vision our system plays its Owen roll.
Our automated Samara Online Postal office system used to improve the
organizations drawback and to support automated system and also to simplify
employees work load, to speed up or to do the organizations service in short time
and to achieve the customers went. So the aim of our proposed system is mainly to
avoid the drawback of the current existing system and adding some new features
that do not exist before and also changes the activity of the organization to
computerized or automated System and reduce the extravagancy of resource.
2. Literature Review
We try to see some projects that are related to our proposed system that is Ethiopian Online Post
Office system, because it helps us to develop our project effective. The project that is to be
developed will solve the problems in existing system. Such as searching specific authorization
information inserting new data, deleting or updating some authorization in formations from the
stored authorization information’s. So the project after it has been accomplished will solve these
specific problems in current manual authorization system and perform different type of tasks and
reduce the organization drawback and this system also transfer different messages, objects and
different types of letters from one place to another place without any corrupts effectively and
efficiently.(AdWWW.monstercrawler.com)
2
Input:-It is well known that human power is the main resource which is used as an input for
every organization especially for performing manual operations as result human power is one of
the basic input for EOPS.
Process:-Process is a series of activities that leads to the output. Some of the processes in Addis
Ababa general post office to provide good postal service are designing and gradually up grading
their web site, sharing information, accepting comments.
Output:-After having of all the above inputs there must be an output. The output is a tangible
form of an input after process(en.m.wikipedia.org)
3 .Statement of the Problem

In fact, postal service is one of the most crucial as well as backbone of the people
by giving postal related services as well as any other services which can be transfer
through postal system. Our project team considers Samara Online Postal Office
Management System, still the system generally does follow or perform the manual
system or paper based system and somewhat automated to provide service to its
customers. So that using manual system has a lot of problems in many cases.
Moreover, the following are problems that are present in the current system of
postal service system in general. Because of this reason the organization faced to
many problems. The problems are
• Work load of the Employers
• It needs much time due to record, to search ones specific customer file if it is
necessary
• Wastage of resources
• Loss of data, poor organized and unsecured data.
• And also currently there is no any free source for this system.
3
• Time limitation in which the system doesn’t keep track of sending and receiving
different materials deliver in the customers’ expected time and date. Example,
postponing customer expected time.
N.B: The problems that raised in the above limit the organization not to give reliable and
fast service to its customers.
4 .Objective of the Project

4.1 General Objective
The general objective of this project is to develop an Online Postal Office System for
Samara Postal Service Enterprise.
4.2 Specific Objective

To achieve or accomplish the general objectives of our proposed system, the following
specific objectives are set.
• Collect the necessary information or data and identify problems of the existing system by
using different data gathering methodology
• Analyze the system requirements by using analyzing methodology
• Design the artifacts of the proposed system for the overall view of the structure.
• Implementing the proposed system.
• Testing the system by using different tasting methodology
• Finally Deploy the proposed system
5. Significance of the project

Since our project is the Postal service and it is the most crucial service for
the people, it has a basic purpose that communicating the customers
throughout the world giving service by considering using fast, efficient
technology to improve the above mentioned problem, Through real and
4
customers expected time, Using fewer amounts of resource and human

power, providing how customers check their materials or any messages they
have sent and they do a truck where it reaches, and communicating all
branch organizations each other, customers with the organizations'
employee through online.
From our proposed system three main bodies Employees they are working
in the organization, Customers they are sends and receives messages and
also the organization are benefited but we are also benefited from this
project because as a developer we increases our knowledge. Those body are
benefit like register or record, search, add, remove customers information
and prepare or provide report on a prepared form simply in less time, see
and manage customers information and minimize employees work overload,
able to reach messages to destination in expected time, able to paying
online, the customers information to be secure and will get Satisfaction.
6. Scope and limitation

6.1 Scope
The scope of this project is that first of all this system is only concerned to the samara post office
in Ethiopia and no cover all parts of our country and also not include foreign countries. It will
perform how to make online service, track management that checks the sent messages of
customers, give to customer email notification, rent post box services, user management, mail
management, including transaction for customer, proving public transportation service and
paying pension and limited on locally or only provides a service to Samara.
Our proposed system will not include performing the tasks of Western Union Services, Forming
DV Lottery, Distributing SIM Cards, and Mobile Card. Therefore, our system is not supports
international postal system. Mostly EPO provides a service in a commission or Agency works
such as blood trace, selling different organization products are out of scope of this project.
6.2 Limitation
There are many factors that limit to perform our scope, such as:
5
1. Time limitation:-there is no enough time to perform this system.

2. Resource limitation:-there is shortage of resource to develop our system.
3. Place limitation:-there is no comfortable place to implement our system.
4. Complexity of the system:-which means that when the system is very wide
then the system is complex and difficult to understand and implemented.
5. The project does not work about holyday working times of the employee as there will
electric fluctuation Entry and Exit time attendance is not included under our project.
7. Methodology
Methodology is a method or approach or a technique that we are uses to develop
this SOPOMS system and it describes how the work to be done to achieve the
objectives using system requirements. To develop this SOPOMS system we use
data gathering, development, testing and other methodology’s used.
7.1Data Gathering Methodology

Gathering Requirements from existing system is important tasks to develop the SOPOM
System. To fulfill this requirement our project development team may obtains from:
• Primary
• Secondary source.
• Primary Source
This is a data that we collected the original data by different techniques from different source.
The techniques are we used to collect this data:

Observation: This technique is used to gather accurate information about how the
system actually operates, particularly about the processes. Observing how the tasks
are actually is the good way of understanding the existing system. By observing the
current working environment of SOPOMS our team collects data which necessary
for automating of postal service system. Our team tried to observe things
mentioned below
• The general system of providing service in the current system

6
• How the system handles and store material’s information
• Types of document format is there printed or non-printed
Interview: The reason why the team select interview is: it permits clarification of
questions, it has high response rate than written questionnaires, and the interview is
flexible and adaptable way of finding information. So to know how the postal
service system is work prepare questions concerning on postal service and
interview the counter SOPOMS. The counter is person who performs managing the
all transactions inside the post office, as well as the manager is a person who
controls and manages the overall system. He also called postmaster. So from the
manager will gain the overall description of the system.
• Secondary Source
Our team collect this type of data is by reading different references books and by analysis
of different internet address.
Document Analysis: Our team analyzes the Ethiopian Postal Service Enterprise Service
Charter book which is given by Samara Post Office.
7.2 Development Methodology

Among the available different methodologies our team plan to use the object
oriented analysis, object oriented design and object oriented implementation
methodology for the development of our system. Because it is best way to
construct, manage and assemble objects that are implemented in our system, and
the composition of objects and collaboration between objects on the system. The
team prefers to use object oriented system analysis because of the system is a
collection of integrated data and method is called object so this model focuses on
the object, provides less transition among different phases of software
development, after implementing the system is easy to maintain and modify and
also this model promotes reusability to improve consistency, reduce time and cost
for system development, easy to maintain or modify and increase reliability.
7
7.3 Development Approaches

Our team to develop this proposed SOPOMS System we choose Iterative model
Approach, Because of selecting this approach from other approaches its projects
the development process in cyclic manner repeating every step after every cycle of
software development cycle. Therefore this model is used to discover errors easily.
In this development model the software is first developed on every small scale and
all the steps are followed which are taken consideration then every next and added
to the software. And this model is easier to manage and perform the development
process. It has also the ability to back up the system. This means the developers got
comment from users, friends and from ours until the team have finished the project
Figure 1 Iterative Approach
8
7.4 Development Tools

Implementation is a realization of a technical specification or algorithm as a program,
software component through programming.
7.4.1 Hardware Tools

Hard ware tools are primary requirement to develop the new system. Although the
team of the project takes different kinds of hard ware tools, to develop this project
we take the following HW tools requirements:
Processer: this is the basic hard ware component to develop our system so in the client
side we needs 3.30MHZ and in the server side also 6MHZ is needs.
RAM Size: also another type of hard ware component to develop our system and it is a
storage device and we need 2GB and 4GB in client and server side respectively.
Internal Hard Disc Space: this is another type of hard ware component to develop
our system so in the client side we need 500GB and in the server side also 1TB is
needs.
AND other hard ware components we need to develop EOPO System such as Switch,
Network, Cable, RJ-45, etc.
7.4.2 Software Tools

The different kind of software we used for developing the project is:-
• Wamp Server 2.5(MYSQL) or xampp-win32-1.7.3: to develop database

application
• PHP, HTML, Java Script –Programing Languages ,Microsoft office word 2007
for documentation.
• Windows 7 Operating system- will be used for the system since it is readily
available in our laboratories
• Edraw Max- to design Sequence Diagram, Class Diagram, and Use case
Diagram.
• Browsers-since our system is web based, it is very necessary requirement.
9
And others like Notpad++, Micromedia Dreamweaver
7.5 Testing Methodology

There are some testing methodology to test the functionality of our propose
system are White Box testing, Black Box testing, Unit testing, Integration
testing, Alpha testing, Beta testing. Our team selects all testing
methodologies to sure the functionality of the system.
White Box Testing: in this type of testing requires programming and

implementation knowledge as a mandatory so our team gives input to the system
and checking that how the system processes the input to generate the output.
Black Box Testing: In this type of testing methodology is not mandatory to be

known about the internal pare of source code only our team testes by giving the
inputs to the system and checks whether the expected result is deployed or not.
Unit testing: this unit testing will implement during deployment time. So, if the
error will occur, it will fix immediately.
Integration testing: we will make an integration testing to check whether the system meets all
the functionality requirements or not.
Alpha testing: the system will tested by allowing or giving the correct input.
Beta testing: beta testing will be tested by the users at their own working place weather it meets
their needs or not.
10
CHAPTER TWO
2. REQUIREMENT ELICITATION
2.1Overview of the Existing System
Currently the Postal Service System mostly follows manual based system and somewhat
automated to provide service to its customers. The services provided by the system are mainly
categorized in to two which are direct and commission. The direct one is the service which
provide by EPO sending and receiving different type of Airmail and the commission services are
provided by the EPO for other governmental or non-governmental organizations for collective
benefits. The services provided by the system are sending and receiving airmail, renting post
box, giving western union service, paying pension, forming of dv lottery, selling SIM,
CDMA/WCDMA, mobile cards, income tax collection, blood tramp and tale agency license tax
collection.
Sending airmail
On the process of sending airmail if a customer want to send an airmail, first she/he contact the
counter, then he/she must select the types of airmail, the counter receives the airmail to check
whether the address of both sender and receiver are valid or not. Second, the counter measures
the weight of the airmail, attach postage stamp and record the information available on airmail
(date of sending, registration no, sender address, receiver address, weight, barcode number (for
EMS air mail), cost and price) in three copies on the form. Finally the customer pays the price
and receives the receipt. Then the counter starts to collect daily received airmails and group
together according to their destination, then packed and gives to the messenger/postman. The
messenger/postman takes the packed airmails to the bus station and distribute to different
expected sites of the customers.
Receiving airmail
Every day the messenger/postman brings the packed airmails from the bus station and gives to
the counter. The counter registers all received airmails. Then, if the airmail is ordinary or first
order airmail the counter distribute it to the post box of a customer. But type of airmail is either
registered or parcel, the counter distribute registered letter 1 st advice form (if the customer
11
received a single airmail) or collective 1st advice form (if the customer has more than one
received letter). For EMS the messenger/postman directly contact the customer and gives the
airmail.
2.1.1 Problem of the existing system

The existing system has many problems in the working procedure for the organization and
customer. These are:-
 Risk of management data due to massive data collection
 Accuracy not guaranteed.
 lack of awareness
 Not in reach of distant users.
 The customers may be resulted to unnecessary extra expense and waste their time.
 The customer may not get service of the organization twenty four hours a day and
seven days a week.
 When generating report, it takes time and it may not be easy to manage and analysis
the monthly work due to massive collection of data and the generated report may not
be accurate.
2.1.2 Weakness and strength of the existing system

Weakness of the existing system
The current system has weakness of u se more human power since the system is
not some more computerized it use more human power to give service, there is
duplication of data because of the data are not well organized and structured, there
is also disorder of data because the data are not stored sequentially and the user
information is may be accessed by unauthorized person because of the information
is stored manually there is the disadvantage for employees it is difficult to perform
any activity that performed in this organization so high work bourdons for
employees.
12
Strength of the existing system
The current system has strength to develop the new system it is used as a secondary
source to gather system requirements, the employee working overtime, punctual to the society,
honesty to the users, responsible and transparent for their action and also used for the following
action.
 The employees have their own privilege (freedom).
 The customers can buy items in a good price.
 A Distribution of work for the employee.
2.1.3 Business rules of the system

A business rule is effectively an operating principle or polices that we try to specify for both the
existing system and the new system must satisfy. The business rule is a principle or a policy in
which the proposed system operates accordingly. It deals with access control issues. It often
pertains to access control issues, operating policies and principles of the organization. The
organization has the following principles in the existing system which includes:
 The organization does not functional on Sunday.

 It does not reach books to customers to their address.
 The organization prepares reports to the higher officials monthly.
 The organization is functional only restricted time (from 2:00-6:00 morning and from
8:30-11:00 afternoon).
 The organization does not functional on holiday. Our proposed system includes the
following operating principles or rules:
 Business Rule1: the customer uses the application properly.
 Business Rule2: the customer fills the form properly.
 Business Rule3: the system gives fast responses to the customer.
 Business rule4: the system helps to arrive the books to the customer place.
 Business rule5: it provides more options to customers.
 These system allow the customer order all time
13
2.2 Overview of the proposed System

The Online Postal Service will try to eliminate the drawbacks of the existing
system by improving some feature to the proposed system time accuracy, by
reducing system complexity, improving security issue, improving activities, make
online transaction and email notification for the user and also able to pay customers
online.
2.2.1 Functional Requirement of the proposed system

Functional requirements describe the interactions between the system and its
Environment independent of its implementation. The environment includes the user
and any other external system with which the system interacts. The system should
provide how the system should react to particular inputs and how the systems
behave in particular situations. The following are the functional requirements for
our propose system:-
User management
• The system verify user account to login in to the system by Authenticating

their information
• The system handles user information
• The system enables Users/Customers to change and updates their profile.
Airmail and Material management
• The system register different types of airmails and materials information

which are send and delivered or received
• The system provides data manipulation service such as insertion, updating

and deletion
• The system enable users to search data
• Customers can check track and write comments, suggestions, questions, and
receives notifications in their email account thanks on the online service of
the system.
14
• Box rent management
• The system enables user to rent boxes
• The system enables to manage boxes
• The Renter able to Renewed contract
• Online Payment: customers can able to paying online for the services which given by
the organization and also gets pensions salary.
• Customers able to use Post Bus Ticket in Online
2.2.2 Non Functional requirements of the proposed system

Nonfunctional requirements describe user-visible aspects of the system that are not
directly related with the functional behavior of the system. Nonfunctional
requirements include quantitative constraints, such as response time (i.e., how fast
the system reacts to user commands) or accuracy (i.e., how precise are the system’s
numerical answers). The nonfunctional requirements of our proposed postal system
will list as follows:
• User interface: our system should have friendly user interface by making simpler
and interactive to user
• Robustness: our system should be robust by showing errors message or gives

notification in server and client side when errors occur during data entry.
• Security: the system should be secured and protected from unauthorized user. It
should have a user’s database and should authenticate each user on login and
should grant user specific services and we use (data encryption) algorithm to
secure a data inter to the organization data base
• Performance: System will have good performance as much as possible this will
be attained via easily loadable interface components and optimal algorithms which
make searching, updating, deleting, inserting and saving easy and fast
• Error handling mechanism: the system must have error handling mechanism. It
is not stop functioning rather it must report an error message
15
• Portability: The system can be executed in different platforms without any

restriction. The user can access the system at any place and to achieve this we
selects php programing language
• Reliability: the system is always reliable. The new system will operate for long
period of time
2.2.3 System Requirement of the proposed system

Hardware Requirement
 RAM: -400MB or Higher

 Printer
Software Requirement
 Operating system: - Window 7 Operating System.
2.3 Constraints and assumptions
2.3.1 Constraints
Constraints are something limit or impose our project. A constraint can be two types which are:-
1. Business constraint: - It depends on the state of the organization. Some of them in our
proposed system are:-
During gathering information the manager not always present on their office.
The time schedule limits our project function of working in order to submit before the given time
deadline.
2. Technical Constraints:-It depends on security and safety. Some of them in our proposed
system are:-
 We does not get lab when we want.
 Power fluctuation.
 Network connection problem.
16
2.3.2 Assumptions
It is a belief of what we assume that are expected to happen during the project's life cycle. Thus
are:-
To access the system the customer shall be in network coverage area.
 Customer must be good in computer usage.
 Customer must know English language.
 Customer must know the address of web.
 All software and hardware requirements are fulfill.
 The administrator must check if order is exist or not from the customer.
17
CHAPTER THREE
3. SYSTEM MODELING
The system model of Samara postal service system is composed of the functional
model represented by Use cases models, the sequence diagram and activity diagram
and also about conceptual class diagram.
These UML use case diagram is a map problem statement into a system
specification that we represent as a set of actors, scenarios, and use cases and their
relationship. Use-case model consists of the collection of all actors and all use case,
a use case is a scenario that describes the use of the system by an actor to
accomplish a specific goals, an actor is a user playing a role with respect to the
system. Scenario is a sequence of step that describes the interaction between an
actor and the system.
3.1 Use Cases Identification

The first step of requirements elicitation is the identification of actors. This serves
both to define the boundaries of the system and to find all the perspectives from
which they are need to consider the system. When the system is deployed into an
existing organization most actors usually exist before the system is developed. A
use case is initiated by an actor. After its initiation, a use case may interact with
other actors as well. A use case represents a complete flow of events. The
following are listing of all actors that interact or involved with the system under
development and use cases:
Use cases
• Login
• Create user account
• Assign Mail Cost
• Receive Airmail
• Register sent airmail
• Renting post box
18
• Register received airmail

• Register Material
• Deliver Material
• Deliver Airmail
• Search airmail
• Update airmail
• Delete airmail
• Search material
• Update material
• Delete material
• Search post box
• Update post box
• Delete post box
• Check track
• Post Contract Period
• Generate Notification
• Receive Notification
• Update User
• Pay Pension
• View Data
• Assign Post Bus
• Assign Mail Cost
• Manage Post Bus Ticket
• Manage Post Box
• Manage Mail Cost
• Sent Airmail Registration
• Delete User
• Search User
• Logout
19
3.2 Use case diagrams

Use case diagrams for the current and proposed system are used to represent the basic
functionalities of the Current and propose system as Use cases focus on the behavior of the
system from an external point of view. It also represents user requirements gathered during
requirement elicitation, contains use case, actors, system boundary and their relationships. Use
Case diagram of the current and propose system are shown as follows:
3.2.1 Actors specification

Actors
• Administrator
• Counter
• Postman
• Customers
• CBE(external system)
Administrator: is a person who registers user, update and delete information about the user and
approves report and pays a pension.
Counter: is a person who register and manages (update, search and delete) sent and
received airmails and rent post box information.
Postman: is a person who sends and receives airmails as well as materials from one
customer to another or from one person to organization or one organization to other
organization. Also who can register and manage update, search and delete materials in the
system and also Generate Report and Notifications.
Customers: are people or any users who can send and receive any material using the
Samara postal service system in Ethiopia.
20
CBE (Commercial Bank of Ethiopia): is an external system which interact with our
propose system for payment.
3.2.2 Use Case Description
Use case Identification Use case Name Use case description

No
UCI 01 Login Describe how users login to the system
UCI 02 Create Account Describe how admin creates account for users
UCI 03 Rent Post Box Describes how counter registers a rent box
UCI 04 Register sent Describes how counter registers sent airmail
airmail
UCI 05 Register Received Describes how counters registers Received
Airmail airmail
UCI 06 Search Airmail Describes how counters search specific airmail

UCI 07 Update Airmail Describes how the counter updates registered
airmail
UCI 08 Register Material Describes how a post man registers material

UCI 09 Search Material Describes how a post man searches specific
material
UCI 10 Update Material Describes how a post man updates the registered
material
UCI 11 Delete Material Describes how a post man removes the registered
material
UCI 12 Search Post Box Describes how a counter searches once post box
UCI 13 Update Rent Post Describes how a counter changes the renter info
Box
UCI 14 Delete Rent Post Describes how a counter removes registered Post
Box box
UCI 15 Check Track Describes how customers check there material

UCI 16 Pay Pension Describes how an admin pays pension for
customers
21
UCI 17 View Feed Back Describes how Admin View Feed Back from the
system
UCI 18 Delete Airmail Describes how a counter removes registered
airmail
UCI 19 Generate Report Describes how an Admin Generate Report
UCI 20 Delete Users Describes how an admin removes users
UCI 21 Updates Users Describes how an admin changes users profile
UCI 22 Paying Online Describes how customers paying online
UCI 23 Manage post Box Describes how Counter Manage Post Bus
UCI 24 Manage post Bus Describes how Counter Manage Post Bus ticket
ticket
UCI 25 Change Password To Describe how users change their password
UCI 26 Post Notice Describes how Counter control the post contract
period
UCI 27 Search User Describes how Admin search specific user
UCI 28 Assign Sent Mail Describes how Admin Assign the Mail Cost
Cost
UCI 29 Manage Mail Describes how Admin Manage the Mail Cost
Cost
UCI 30 Deliver Airmail Describes how Post Man Deliver Airmail
UCI 31 View Delivered Describes how Post Man View Delivered

Material Material
UCI 32 Register Describes how Post Man Register Received
Received Airmail Airmail
UCI 33 Manage Airmail Describes how Counter Manage Airmail
UCI 34 Assign Post Bus Describes how Counter Assign Post Bus
UCI 35 Log Out Describe how users Log Out to the system
Table3. 1 Use case Identification Number
22
UCI 01
UC Name Login
UC Description Login to the system by users own account in order to perform

actions
Actor Administrator, Counter and Post man

Precondition The users should have an account
Normal Flow of • The user activates the system.
event • The system display Home Page
• The User Press Login Tab Then
• Users Enters user name and password
• Users clicks on login button
• The system checks and validates the entered user name and
password.
• The system displays the user first page

• Use case ends
Post condition An authorized user entered to the system and can access the
system and performs their actions
Alternative flow A7.The system informs to the user invalid user name and
event password A8. End.
Exceptional Flow E7. Error! Can’t connect to server please try again. Message is
of Event displayed.
E8. Use case ends.
Table3. 2 Use case documentation for login
23
UCI 02
UC Name Create Account
UC Description Describes how an administrator creates account

Actor Administrator
Precondition The administrator should successfully login into the system and
know the information of users
Normal Flow of 1The Administrator click create account link

event 2The system displays create account page.
3The Administrator fills full information about users

4The Administrator clicks on submit button
5 The system validates the information interred by the Admin 6
The system registers and creates new account.
7 The use case ends

Post condition An Administrator creates Account successfully to the user
Alternative flow A6 The system displays “Fill all information correctly!” massage.
event A7 use case end
Exceptional Flow E6 The system displays “Error! Can’t connect to server please
of Event try again!” message.
E7 use case end
Table3. 3 Use case documentation for Create Account
24
UCI 03
UC Name Renting Post Box
UC Description Describes how a Counter Rents Post Box

Actor Counter
Precondition The Counter should successfully login into the system and the customer
fulfill the criteria and should be pay the cost of box in online or in cash
Normal Flow of • The Counter click Rent Post Box link

event • The system displays Rent Post Box page.
3The Counter fills full information about the Subtenant and exaction
the cost of box
• The Counter clicks on Rent button

• If it may be Rent post box in cash “Rent In cash” button
• The system validates the information interred by the Counter
• The system registers and prints the receipt
• The use case ends
Post condition A Counter Renting Post Box successfully to the Subtenant
Exceptional Flow E7 The system displays “Error! Can’t connect to server please try
of Event again!” message.
E8 use case end.
Table3. 4 Use case documentation for Renting Post Box
25
UCI 04
UC Name Register sent airmail
UC Description Describes how a Counter Register sent airmail

Actor Counter
Precondition The Counter should successfully login into the system
Normal Flow of 1The Counter click Register sent airmail link
event • The system displays Register sent airmail page.
• The Counter fills full information about the material
• The Counter clicks on Register button
• The system registers successfully
Post condition A Counter Register sent airmail successfully to the DB
E7 use case end.
Table3. 5 Use case documentation for Register sent airmail
26
UCI 05
UC Name Register Receive airmail
UC Description Describes how a Postman Register Receive airmail

Actor Postman
Precondition The Postman should successfully login into the system
Normal Flow of 1The Postman click Register Receive airmail link
event • The system displays Register Received airmail form.
• The Postman fills full information about the material
• The Counter clicks on Register button
• The system registers successfully
Post condition A Counter Register Receive airmail successfully to the DB
E7 use case end.
Table3. 6 Use case documentation for Register Receive airmail
27
UCI 06
UC Name Search airmail
UC Description Describes how a Counter Search airmail

Actor Counter
Normal Flow of 1The Counter click Search airmail link
event • The system displays Search airmail form and all Records
• The Counter Can fills Directly Airmail Id or other values
• The Counter clicks on Search button
• The system Search successfully
Post condition A Counter Register Search airmail successfully from the DB
Alternative flow A5 The system displays “Inter Valid Id!” massage.
E6 use case end.
Table3. 7 Use case documentation for Search airmail
28
UCI 07
UC Name Update airmail
UC Description Describes how a Counter Update airmail

Actor Counter
Normal Flow of 1The Counter click Update airmail link
event 2The system displays Update airmail form and also all records 3
The Counter fills the correct information for the specific updated
data item or directly press update button for specific row from
displayed records
• The system Displays the update form with previously

registered information
• The Counter files new information and clicks on Update Btn

• The system checks the entry
• The system Updates successfully
Post condition A Counter Register Search airmail successfully from the DB
E8 use case end.
Table3. 8 Use case documentation for Update airmail
29
UCI 08
UC Name Register material
UC Description Describes how a Post man Register materials

Actor Post man
Precondition The post man should successfully login into the system and
Normal Flow of 1The Post man click Register material link
event 2 The system displays Register material page.
3The Post man fills full information about the martial
• Click on register material button
• The system validates the information interred by the Post man
• The system registers materials
Post condition A Counter Renting Post Box successfully to the Subtenant
Exceptional Flow E6 The system displays “Error! Can’t connect to server please
of Event try again!” message.
E7 use case end.
Table3. 9 Use case documentation for Register material
UCI 09
30
UC Name Search material
UC Description Describes how a Post man Search material

Actor Post man
Precondition The Post man should successfully login into the system
Normal Flow of 1The Post man click Search material link
event • The system displays Search material form and all Records
• The Post man Can fills Directly material Id or other values
• The Post man clicks on Search button
Post condition A Post man Register Search material successfully from the DB
E6 use case end.
Table3. 10 Use case documentation for Search material
UCI 10
31
UC Name Update material
UC Description Describes how a Post man Update material

Actor Post man
Precondition The Post man should successfully login into the system
Normal Flow of 1The Post man click Update material link
event 2The system displays Update material form and also all records 3
The Post man fills the correct information for the specific updated
displayed records

• The Post man files new information and clicks on Update

Btn
Post condition A Post man Register Search Update material successfully from the
DB
E8 use case end.
Table3. 11 Use case documentation for Update material
UCI 11
32
UC Name Delete material
UC Description Allow postman to Delete material and To describe how a post mane
Delete material
Actor Post man
Precondition The post man should have logged in to the system successfully
Normal Flow of • The post man selects the “Delete material” link.
event • The system display Delete material form and also all records
• The post man inters the material identification or other attributes
or directly press delete button from displayed records
• The system checks and validates the entered value

• The system displays the material is successfully deleted message
• Use case ends
Alternative Flow A6. The system display “inter Valid information!” message display
Events A7. Use case ends
Exceptional E6. The system display “Error! Can’t connect to server please try again!”
Flow Events E7. Use case ends
Table3. 12 Use case Documentation for Delete material
UCI 12
33
UC Name Search Post Box
UC Description Describes how a Counter Search Post Box

Actor Counter
Normal Flow of 1The Counter click Search Post Box link
event • The system displays Search Post Box form and all Records
• The Counter Can fills Directly Post Box Id or other values
Post condition A Counter Register Search Post Box successfully from the DB
E6 use case end.
Table3. 13 Use case documentation for Search Post Box
34
UCI 13
UC Name Update Post Box
UC Description Describes how a Counter Update Post Box

Actor Counter
Normal Flow of 1The Counter click Update Post Box link
event 2The system displays Update Post Box form and also all records 3
The Counter fills the correct information for the specific updated
displayed records

• The Counter files new information and clicks on Update Btn

Post condition A Counter Register Search Post Box successfully from the DB
E8 use case end.
Table3. 14 Use case documentation for Update Post Box
UCI 14
35
UC Name Delete Post Box
UC Description Allow Counter to Delete Post Box and To describe how a Counter
Delete Post Box
Actor Counter
Precondition The Counter should have logged in to the system successfully
Normal Flow of • The Counter selects the “Delete Post Box” link.
event • The system display Delete Post Box form and also all records
• The Counter inters the Post Box identification or other attributes
or directly press delete button from displayed records

• The system displays the material is successfully deleted message
• Use case ends
Table3. 15 Use case Documentation for Delete Post Box
36
UCI 15
UC Name Check track
UC Description Allow Customers to check there track and To describe how the
customer check there track
Actor Customer
Precondition The Customer should be know there track ID number
Normal Flow of • The customer inters valid Track number in specified Search
event Track Form for the track
• The counter clicks on Search button

• The system checks and validates the entered Track Number
• The system display where the track is there
• Use case ends
Post Condition Customers know where the sent material is reach
Alternative Flow A6. The system display “inter valid Track Number!” message
Events display
A7. Use case ends

Exceptional E6. The system display “Error! Can’t connect to server please try
Flow Events again!” message E7. Use case ends
Table3. 16 Use case Documentation Check track
37
UCI 16
UC Name Paying Pension
UC Description Allow Administrator to Paying Pension and To describe how it pay

Actor Administrator, Customer and ECB System
Precondition The Customer should be have ECB Account and Administrator
should be login successfully
Normal Flow of • An Administrator clicks on Pay Pension link

event • The system displays access page for payment
• An Admin import full information for Pensioner Customers
• The System Display the unpaid customers information from the
imported data
• An Admin Clicks on the Pay Pension Button

• The system Pays(Transforms to customer Bank Account) Salary
(Pension) for all Valid customers based on each Pensioners
Customers
• The system display Successfully pay message

• Use case end
Post Condition An Admin Transfers pension to Customers Account
Alternative Flow A7. The system display “Unpaid Pensioners with Reasons!”
Events message display
A8. Use case ends

Table3. 17 Use case Documentation Paying Pension
38
UCI 17
UC Name View Feed Back
UC Description Allow Administrator to View Feed Back and To describe how it pay
Actor Administrator
Normal Flow of • An Administrator clicks on View Feed Back link

event • The system displays access page for Feed Back
• An Admin import full information about the system Feed Back
to the customers
• An Admin Clicks on the View Feed Back Button
• The system display Successfully Feed Back message
• Use case end
Post Condition An Admin Transfers Feed Back to Customers

Alternative Flow A7. The system display “Feed Back with Reasons!” message
Events display
A8. Use case ends

Table3. 18 Use case Documentation View Feed Back
UCI 18
39
UC Name Delete Airmail
UC Description Allow Counter to Delete Airmail and To describe how a Counter

Delete Airmail
Actor Counter
Precondition The Counter should have logged in to the system successfully
Normal Flow of • The Counter selects the “Delete Airmail” link.
event • The system display Delete Airmail form and also all records
• The Counter inters the Airmail identification or other attributes or
directly press delete button from displayed records

• The system displays the Airmail is successfully deleted message
• Use case ends
Table3. 19 Use case Documentation for Delete Airmail
UCI 19
40
UC Name Generate Report
UC Description Allow Admin Generate Report to Admin and describe how it

generated
Actor Admin
Precondition The Admin should have logged in to the system successfully
Normal Flow of • Admin selects “Generate Report” Tab.
event • The system Generates Total and Summarized Report for one
day, one month, … and also display the link to view the
detail reports for each type of report
• If The Admin went to see the detail report Select from each
type of report and press on links
• The system Generates for the selected type of report

• If the Admin wants to print each Type of report Press Print
Button.
• Use case ends

Post Condition Post Man successfully generates report to admin and sends request
to approve it
Alternative Flow A4. The system display “There is Report Currently!” message
Events display
A6. Use case ends

Exceptional E2,E6. The system display “Error! Can’t connect to server please
Flow Events try again!”
E7. Use case ends
Table3. 20 Use case Documentation for Generate Report
41
UCI 20
UC Name Delete User
UC Description Allow an admin removes users and To describe how Admin

Delete User
Actor Admin
Precondition The Admin should have logged in to the system successfully
Normal Flow of • The Admin selects the “Delete User” link.
event • The system display Delete user form and also all records
• The Admin inters the User identification or other attributes or
directly press delete button from displayed records

• The system displays the User is successfully deleted message
• Use case ends
Alternative Flow A6. The system display “inter Valid User!” message display
Table3. 21 Use case Documentation for Delete User
UCI 21
42
UC Name Update User
UC Description Describes how a Admin Update User

Actor Admin
Precondition The Admin should successfully login into the system
Normal Flow of 1The Admin click Update User link
event 2The system displays Update User form and also all records 3 The
Admin fills the correct information for the specific updated data
item or directly press update button for specific row from
displayed records

• The Admin files new user and clicks on Update Btn

Post condition A Admin Register Search airmail successfully from the DB
E8 use case end.
Table3. 22 Use case documentation for Update User
43
UCI 22
UC Name Paying Online
UC Description Allow how customers paying online and To describe how it pay
Actor Administrator, Customer and ECB System
Normal Flow of • An Administrator clicks on Pay Online link

event • The system displays access page for payment
• An Admin import full information for Customers
• The System Display the unpaid customers information from the
imported data
• An Admin Clicks on the Pay Online Button

• The system Pays(Transforms to customer Bank Account) Salary
(Online) for all Valid customers based on each Customers
• The system display Successfully pay message

• Use case end
Post Condition An Admin Transfers Customers Account

Alternative Flow A7. The system display “Unpaid customer with Reasons!” message
Events display
A8. Use case ends

Flow Events again!” message .
E8. Use case ends
Table3. 23 Use case Documentation Paying Online
44
UCI 23
UC Name Manage Post Box
UC Description Describes how a Counter Manage Post Box

Actor Counter
Normal Flow of 1The Counter click Manage Post Box link
event • The system displays Manage Post Box form and all Records
• The Counter Can fills Directly Post Box Id or other values
• The system Manage successfully
Post condition A Counter Register Manage Post Box successfully from the DB
E6 use case end.
Table3. 24 Use case documentation for Manage Post Box
UCI 24
45
UC Name Manage Post Bus ticket
UC Description Describes how a Counter Manage Post Bus ticket

Actor Counter
Normal Flow of 1The Counter click Manage Post Bus link
event • The system displays Manage Post Bus form and all Records
• The Counter Can fills Directly Post Bus Id or other values
Post condition A Counter Register Manage Post Bus ticket successfully from the
DB
E6 use case end.
Table3. 25 Use case documentation for Manage Post Bus ticket
UCI 25
46
UC Name Change Password
UC Description Allow Users to change their password and User Name and to show
how it is performed
Actor Admin, Counter, Post Man

Precondition The User should have its own valid previous user name and
password
Normal Flow of • The User selects “Change Password” Tab.

event • The system display Change Password Form
• The User fill previous user name and password and current
password
• The user clicks on Change Password button

• The system displays successfully change password message
• Use case ends
Post Condition Users successfully able to Manage their profile
Flow Events again!”
E6. Use case ends
Table3. 26 Use case Documentation for Change Password
UCI 26
47
UC Name Post Notice
UC Description Describes how a Counter control Post Notice

Actor Counter
Normal Flow of 1The Counter click Post Notice link
event • The system displays Post Notice form and all Records
• The Counter Can fills Directly Post Notice Id or other values
Post condition A Counter Control Post Notice successfully from the DB
E6 use case end.
Table3. 27 Use case documentation for Post Notice
UCI 27
UC Name Search User
48
UC Description Describes how a Admin Search User

Actor Admin
Normal Flow of 1The Admin click Search User link
event • The system displays Search User form and all Records
• The Admin Can fills Directly User Id or other values
• The Admin clicks on Search button
Post condition A Admin Search User successfully from the DB
E6 use case end.
Table3. 28 Use case documentation for Search User
UCI 28
49
UC Name Assign Sent Mail Cost
UC Description Describes how a Admin Assign Sent Mail Cost

Actor Admin
Normal Flow of 1The Admin click Sent Mail Cost link
event • The system displays Sent Mail Cost form and all Records
• The Admin Can fills Directly Sent Mail Cost Id or other values
Post condition A Admin Assign Sent Mail Cost successfully from the DB
E6 use case end.
Table3. 29 Use case documentation for Assign Sent Mail Cost
50
UCI 29
UC Name Manage Mail Cost
UC Description Describes how a Admin Manage Mail Cost

Actor Admin
Normal Flow of 1The Admin click Manage Mail Cost link
event • The system displays Manage Mail Cost form and all Records
• The Admin Can fills Directly Manage Mail Cost Id or other values
Post condition A Admin Manage Sent Mail Cost successfully from the DB
E6 use case end.
Table3. 30 Use case documentation for Manage Mail Cost
51
UCI 30
UC Name Deliver Airmail
UC Description Allow postman to Deliver Airmail and To describe how a post mane
Deliver Airmail
Actor Post man
Normal Flow of • The post man selects the “Deliver Airmail” link.
event • The system display Deliver Airmail form and also all records
• The post man inters the Airmail identification or other attributes
or directly press Deliver Airmail button from displayed records

• The system displays the Deliver Airmail is successfully Deliver
message
• Use case ends
Alternative Flow A6. The system display “Deliver Airmail!” message display
Table3. 31 Use case Documentation for Deliver Airmail
52
UCI 31
UC Name View Delivered Material
UC Description Allow postman to View Delivered Material and To describe how a post
man View Delivered Material
Actor Post man

Normal Flow of • The post man selects the “View Delivered Material” link.
event • The system display View Delivered Material form and also all
records
• The post man inters the View Delivered Material identification or
other attributes or directly press Deliver Airmail button from
displayed records

• The system displays the View Delivered Material is successfully
Deliver message
• Use case ends
Alternative Flow A6. The system display “ Delivered Material!” message display
Table3. 32 Use case Documentation for View Delivered Material
53
UCI 32
UC Name Register Received Airmail
UC Description Allow postman to Register Received Airmail and To describe how a post
man Register Received Airmail
Actor Post man

Normal Flow of • The post man selects the “Register Received Airmail” link.
event • The system display Register Received Airmail form and also all
records
• The post man inters the Register Received Airmail identification
or other attributes or directly press Register Received Airmail
button from displayed records

• The system displays the Register Received Airmail is successfully
Register message
• Use case ends
Alternative Flow A6. The system display “Received Airmail!” message display
Table3. 33 Use case Documentation for Register Received Airmail
54
UCI 33
UC Name Manage Airmail
UC Description Describes how a Counter Manage Airmail

Actor Counter
Normal Flow of 1The Counter click Manage Airmail link
event • The system displays Manage Airmail form and all Records
• The Counter Can fills Directly Manage Airmail Id or other values
• The system Manage Airmail successfully
Post condition A Counter Register Manage Airmail successfully from the DB
E6 use case end.
Table3. 34 Use case documentation for Manage Airmail
55
UCI 34
UC Name Assign Post Bus
UC Description Describes how a Counter Assign Post Bus

Actor Counter
Normal Flow of 1The Counter click the Assign Post Bus link
event • The system displays Assign Post Bus form and all Records
• The Counter Can fills Directly Assign Post Bus Id or other values
• The system Assign Post Bus successfully
Post condition A Counter Register Assign Post Bus successfully from the DB
E6 use case end.
Table3. 35 Use case documentation for Assign Post Bus
56
UCI 35
UC Name Logout
UC Description Logout to the system by users own account in order to leave out
from the system
Actor Administrator, Counter and Post man

Precondition The users should have an account
Normal Flow of • The user activates the system.
event • The User Press Logout Tab Then
• Users clicks on Logout button
• Use case ends
Post condition An authorized user can leave out of the system and the end of
the actions
Alternative flow A7.The system informs to logout press A4. End.

event
Exceptional Flow E7. Error! Can’t connect to server please try again. Message is
of Event displayed.
E8. Use case ends.
Table3. 36 Use case documentation for Logout
57
Figure 2 The proposed System Use Case Diagram
58
3.3 Sequence Diagram

A sequence diagram shows object interactions arranged in time sequence. Sequence
diagram is a system model that is used to depict the interaction between
participating objects in a given use case. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario. A sequence diagram shows, as
parallel vertical lines (lifelines), different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them,
in the order in which they occur. The sequence diagrams for our automated postal
service system is clearly show the participating objects in the given use case as
follows.
59
Figure 3 Sequence Diagram For Login
60
Figure 4 Sequence Diagram for Create Account
61
Figure 5 Sequence Diagram For Paying Pension
62
Figure 6 Sequence Diagram For Register Material
63
Figure 7 Sequence Diagram For Register Sent Airmail
64
Figure 8 Sequence Diagram For Register Receive Airmail
65
Figure 9 Sequence Diagram for Register Rent Post Box
66
Figure 10 Sequence Diagram For Check Track
67
Figure 11 Sequence Diagram For Search Post Box
68
Figure 12 Sequence Diagram for Update Post Box
69
Figure 13 Sequence Diagram For Delete Post Box
70
Figure 14 Sequence Diagram For View Data
71
Figure 15 Sequence Diagram For Generate Report
72
Figure 16 Sequence diagram For Pay Online
73
Table3. 37 Sequence Diagram For Logout
74
3.4 Class Diagram

Class diagram is structure that describes the structure of a system by showing
classes of a system their attributes methods and interrelationship between classes. It
is used both for general conceptual modeling of the systematics of the application.
A conceptual model is a representation of a system, made of the composition of

concepts which are used to help people know, understand, or simulate a subject the
model represents. Which focus on the perspective and language of the subject
matter experts for the domain under consideration Rather, making for any system
design choices or with other computational issue and it is the domain class diagram
models the high level concepts in the system, not the implementation details it
should be modeled without concern for the implementation language. It also
describes the system in terms of objects, classes, attributes, operations, and their
association.
In our system:-
• Administer
• Post Man
• Counter
• Customer
• Airmail
• Material
• User
• Post Box
• Notification
• Report and Bank Account are classes.
75
Figure2. 27 Conceptual/Analysis Class

Diagram
76

Final Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Documentation

Uploaded by

Copyright:

Available Formats

SAMARA UNIVERSITY

COLLEGE OF ENGINEERING AND TECHINOLOGY

TITLE:-SAMARA ONLINE POST OFFICE MANAGEMENT SYSTEM

ADVISOR NAME: ……………….

FINAL PROJECT SUBMITED TO DEPARTMENT OF COMPUTER SCIENCE IN PARTIAL

SAMARA UNIVERSITY, ETHIOPIA

5. Significance of the project_____________________________________________________4

7.5 Testing Methodology____________________________________________________________10

2.1Overview of the Existing System___________________________________________________11

2.2 Overview of the proposed System__________________________________________________14

2.3 Constraints and assumptions______________________________________________________16

3.3 Sequence Diagram_______________________________________________________________59

Figure 1 Iterative Approach.........................................................................................................................8

BPR Business Process Reengineering

SOPOMS Samara Online Postal Office Management System

EMS Express Mail Service

UPU Universal Postal Union

RAD Requirement Analysis Documentation

HTTP Hyper Text Transfer Protocol

SPO Samara Post Office

1.2 Introduction about the Project

3 .Statement of the Problem

• Work load of the Employers

• Loss of data, poor organized and unsecured data.

4 .Objective of the Project

4.2 Specific Objective

• Analyze the system requirements by using analyzing methodology

• Implementing the proposed system.

• Testing the system by using different tasting methodology

• Finally Deploy the proposed system

5. Significance of the project

customers expected time, Using fewer amounts of resource and human

6. Scope and limitation

1. Time limitation:-there is no enough time to perform this system.

7.1Data Gathering Methodology

The techniques are we used to collect this data:

• The general system of providing service in the current system

• How the system handles and store material’s information

• Types of document format is there printed or non-printed

7.2 Development Methodology

7.3 Development Approaches

Figure 1 Iterative Approach

7.4 Development Tools

7.4.1 Hardware Tools

7.4.2 Software Tools

• Wamp Server 2.5(MYSQL) or xampp-win32-1.7.3: to develop database

• Browsers-since our system is web based, it is very necessary requirement.

And others like Notpad++, Micromedia Dreamweaver

7.5 Testing Methodology

White Box Testing: in this type of testing requires programming and

Black Box Testing: In this type of testing methodology is not mandatory to be

2.1.1 Problem of the existing system

 Accuracy not guaranteed.

 Not in reach of distant users.

2.1.2 Weakness and strength of the existing system

Strength of the existing system

2.1.3 Business rules of the system

 The organization does not functional on Sunday.

2.2 Overview of the proposed System

2.2.1 Functional Requirement of the proposed system

• The system verify user account to login in to the system by Authenticating

• The system handles user information

• The system enables Users/Customers to change and updates their profile.

Airmail and Material management