Door To Door Help Delivery System (Industrial Project)

ADDIS ABABA UNIVERSITY COLLEGE OF NATURAL
SCIENCE DEPARTMENT OF INFORMATION

SCIENCE
Industrial Project I
Door to Door Help Delivery System
0
In Partial Fulfillment of Requirements of B.SC Degree in
Information Systems (Industrial Project-I)
Group Members
No. Name ID
1. Abel Gebremedhn Belay NSR/3136/09
2. Abdulaziz Abdulbasit Tahir NSR/0530/09
3. Abnet Tadesse Belayneh NSR/7673/09
4. Christian Million Teshome NSR/1054/09
5. Dawit Shimelis Tadesse NSR/9450/09
6. Getachew Amogne Mengesha NSR/6963/09
i
Examination Board
——————— ——————— ————

Advisor Name Signature Date
——————— ——————— ————

Examiner Name Signature Date
——————— ——————— ————

Examiner Name Signature Date
ii
Acknowledgement
Primarily, we would like to thank God for giving us the necessary guidance, energy, support and drive to
complete the first half semester process of the project.
We would like to express our special gratitude to our advisor Ms. Lemlem Hagos, who have invested her
full effort in guiding the team in achieving the goal. We have a deepest appreciation for his unfailing
patience, incessant support, unreserved and valuable advises during the course of writing this whole
paper. She gave us support for all the difficulties encountered starting from writing the research proposal
to the finalization of this portion of the project, filled with sharp intelligence and understanding.
We would like to thank the industrial committee for announcing the submission date of each phase of the
project periodically, which helped us to strictly follow the time line of providing deliverables.
iii
Acronyms
HTML ………………………………………… Hyper Text Markup Language
CSS ……………………………………………Cascading Style Sheets
AJaX …………………………………………Asynchronous Javascript And
XML …………………………………………..Extensible Markup Language
PHP……………………………………………. Hypertext Pre-processor
XAMPP……………………………………Cross Platform Apache Mariadb(Mysql), Php, Perl
UML…………………………………………Unified Modeling Language
SDLC…………………………………………. System Development Life Cycle
WBS …………………………………………..Work Breakdown Structure
IT…………………………………………………Information Technology
SEM………………………………………….. Search Engine Marketing
SEO…………………………………………… Search Engine Optimization
iv
Contents
Acknowledgement .................................................................................................................................. iii
Acronyms ............................................................................................................................................... iv
List of Tables ........................................................................................................................................ vii
List of Figures .......................................................................................................................................viii
1. Introduction ..................................................................................................................................... 1
1.1. Background of the organization ................................................................................................ 1
1.2. Statement of the problem.......................................................................................................... 2
1.3. Objective of the project ............................................................................................................ 3
1.3.1. General Objective ............................................................................................................. 3
1.3.2. Specific Objective ............................................................................................................ 3
1.4. Feasibility study ....................................................................................................................... 4
1.4.1. Operational feasibility ...................................................................................................... 4
1.4.2. Economic feasibility ......................................................................................................... 4
1.4.3. Technical feasibility ......................................................................................................... 5
1.4.4. Social feasibility ............................................................................................................... 6
1.4.5. Political feasibility ............................................................................................................ 6
1.5. Significance of the system ........................................................................................................ 6
1.6. Beneficiaries of the project ....................................................................................................... 6
1.7. Methodology ............................................................................................................................ 6
1.7.1. Data collection methodology ............................................................................................ 7
1.7.2. System development methodology .................................................................................... 8
1.8. Development tools and technologies ......................................................................................... 9
1.8.1. Front end technologies ...................................................................................................... 9
1.8.2. Back end technologies .................................................................................................... 10
1.8.3. Documentation and modeling tools ................................................................................. 11
1.9. Scope ..................................................................................................................................... 11
1.10. Risks, assumptions and constraints ..................................................................................... 11
1.11. Phases and deliverables of the project ................................................................................. 12
1.12. Work break down structure................................................................................................. 14
1.13. Project schedule ................................................................................................................. 15
2. Business Area Analysis and Requirement Analysis ........................................................................ 17
v
2.1. Introduction ........................................................................................................................... 17
2.2. Business Area Analysis ............................................................................................................... 17
2.2.1. Activities/Functions of the organization................................................................................ 18
2.2.2. Problems of the current system ............................................................................................. 18
2.2.3. Forms and Reports of the Current System ............................................................................. 18
2.2.4. Players of the Existing System ............................................................................................. 19
2.3. Requirements Definition ............................................................................................................. 19
2.3.1. Functional Requirements ...................................................................................................... 19
2.3.2. Non-Functional Requirements .............................................................................................. 39
2.4. Collaborative Modeling............................................................................................................. 40
3. Object Oriented Analysis ............................................................................................................... 43
3.1. Introduction ........................................................................................................................... 43
3.2. System Use Case .................................................................................................................... 43
3.2.1. UI identification ................................................................................................................... 43
3.2.2. Business Rules Identification................................................................................................ 43
3.2.3. Actor Identification .............................................................................................................. 44
3.2.4. Designing the Use Case Diagram ......................................................................................... 45
3.2.5. Use Case Description ........................................................................................................... 46
3.3. Conceptual Modeling ............................................................................................................. 57
3.3.1. Class Diagram ...................................................................................................................... 57
3.3.2. Class Description ................................................................................................................. 59
3.4. Sequence Diagramming ......................................................................................................... 67
3.5. User interface Prototyping ...................................................................................................... 73
4. Conclusion .................................................................................................................................... 86
References............................................................................................................................................. 87
Appendix A ........................................................................................................................................... 88
vi
List of Tables
Table 1-1. budget requirement ................................................................................................................. 5
Table 1-2. Project Tasks and Deliverables .............................................................................................. 13
Table 1-3. Project Work Break down structure....................................................................................... 14
Table 2-1 functional requirements ......................................................................................................... 19
Table 2-2. use case description for Registration ..................................................................................... 22
Table 2-3. use case description for view service ..................................................................................... 22
Table 2-4. use case description for send request ..................................................................................... 23
Table 2-5. use case description for cancel request .................................................................................. 24
Table 2-6. use case description for view request ..................................................................................... 24
Table 2-7. use case description for checkout .......................................................................................... 25
Table 2-8. use case description for rate .................................................................................................. 25
Table 2-9. use case description for view activity .................................................................................... 26
Table 2-10. Use Case Description For Replay to Request ....................................................................... 26
Table 2-11. use case description for search ............................................................................................ 27
Table 2-12. use case description for view Notification ........................................................................... 27
Table 2-13. use case description for update Profile................................................................................. 28
Table 2-14. use case description for Track service ................................................................................. 28
Table 2-15. use case description for Manage service .............................................................................. 29
Table 2-16. use case description for Manage User .................................................................................. 29
Table 2-17. collaboration model for customer class ................................................................................ 40
Table 2-18. collaboration model for expert class .................................................................................... 40
Table 2-19. collaboration model for admin class .................................................................................... 41
Table 2-20. collaboration model for account class .................................................................................. 41
Table 2-21. collaboration model for service class ................................................................................... 41
Table 2-22. collaboration model for complain class ............................................................................... 42
Table 2-23. collaboration model for notification class ............................................................................ 42
Table 2-24. collaboration model for cart class ........................................................................................ 42
Table 2-25. collaboration model for activity class .................................................................................. 42
Table 3-1. List of user interfaces ............................................................................................................ 43
Table 3-2. List of rules .......................................................................................................................... 44
Table 3-3. use case description for system use case registration.............................................................. 46
Table 3-4. use case description for system use case login ....................................................................... 47
Table 3-5. use case description for system use case view service ............................................................ 47
Table 3-6. Use case description for system use case send request ........................................................... 48
Table 3-7. Use case description for system use case view request status ................................................. 49
Table 3-8. Use case description for system use cancel request ................................................................ 49
Table 3-9. Use case description for system use case see notification....................................................... 49
Table 3-10. Use case description for system use case search .................................................................. 50
Table 3-11. Use case description for system use case update profile ....................................................... 50
Table 3-12. Use case description for system use case view activities ...................................................... 51
vii
Table 3-13. Use case description for system use case replay to request ................................................... 51
Table 3-14. Use case description for system use case change status ........................................................ 52
Table 3-15. Use case description for system use case rate ...................................................................... 52
Table 3-16. Use case description for system use case check out ............................................................. 53
Table 3-17. Use case description for system use case track service ......................................................... 53
Table 3-18. Use case description for system use case complain .............................................................. 54
Table 3-19. Use case description for system use case approve registration ............................................. 54
Table 3-20. Use case description for system use case Activate user account ........................................... 55
Table 3-21. Use case description for system use case Add service .......................................................... 56
Table 3-22. Use case description for system use case Change service status ........................................... 57
Table 3-23. Account CLASS DESCRIPTION ....................................................................................... 59
Table 3-24. Expert CLASS DESCRIPTION .......................................................................................... 60
Table 3-25. Admin CLASS DESCRIPTION .......................................................................................... 61
Table 3-26. customer CLASS DESCRIPTION ...................................................................................... 62
Table 3-27. notification CLASS DESCRIPTION ................................................................................... 63
Table 3-28. file expert CLASS DESCRIPTION ..................................................................................... 63
Table 3-29. complain CLASS DESCRIPTION ...................................................................................... 64
Table 3-30. rate CLASS DESCRIPTION ............................................................................................... 64
Table 3-31. service CLASS DESCRIPTION.......................................................................................... 65
Table 3-32. request CLASS DESCRIPTION ......................................................................................... 65
Table 3-33. activity CLASS DESCRIPTION ......................................................................................... 66
Table 3-34. onduty-Expert CLASS DESCRIPTION .............................................................................. 67
List of Figures
Figure 1-1. System Development Life Cycle for Door to Door Help delivery System ............................... 8
Figure 1-2. PROJECT GANTT CHART....................................................................................................... 16
Figure 2-1. essential use case diagram ................................................................................................... 21
Figure 2-2. landing page ........................................................................................................................ 30
Figure 2-3. registration page .................................................................................................................. 31
Figure 2-4. user type-registration page ................................................................................................... 31
Figure 2-5. Terms and conditions-registration page ................................................................................ 32
Figure 2-6. service page......................................................................................................................... 32
Figure 2-7. activity list-activities page to customer and expert................................................................ 33
Figure 2-8. customer list-admin page ..................................................................................................... 33
Figure 2-9. expert list-admin page ......................................................................................................... 34
Figure 2-10. Send request page .............................................................................................................. 34
Figure 2-11. customer cart page ............................................................................................................. 35
Figure 2-12. Expert cart page ................................................................................................................. 35
Figure 2-13. Search page for Expert and Customer page ........................................................................ 36
Figure 2-14. Customer Personal page..................................................................................................... 36
viii
Figure 2-15. admin Personal page .......................................................................................................... 37
Figure 2-16. Expert Personal page ......................................................................................................... 37
Figure 2-17. tracking service page ......................................................................................................... 38
Figure 2-18. notification page ................................................................................................................ 38
Figure 3-1. system use case diagram ...................................................................................................... 45
Figure 3-2. class diagram ....................................................................................................................... 58
Figure 3-3. Sequence diagram for registration ........................................................................................ 68
Figure 3-4. Sequence diagram for login ................................................................................................. 69
Figure 3-5. Sequence diagram for view service ...................................................................................... 70
Figure 3-6. Sequence Diagram for Use Case Cancel request .................................................................. 71
Figure 3-7. sequence diagram for view notification ................................................................................ 72
Figure 3-8. Landing page ....................................................................................................................... 73
Figure 3-9. Registration page ................................................................................................................. 74
Figure 3-10. USER TYPE- REGISTRATION PAGE ............................................................................ 74
Figure 3-11. Terms and conditions- registration page ............................................................................. 75
Figure 3-12. login page .......................................................................................................................... 75
Figure 3-13. Activities page-customer and expert .................................................................................. 76
Figure 3-14. TACK SERVICE PAGE-FOR ADMIN ............................................................................. 76
Figure 3-15. Customer list for admin ..................................................................................................... 77
Figure 3-16. expert List for admin ......................................................................................................... 77
Figure 3-17. Admin Profile Page ........................................................................................................... 78
Figure 3-18. Customer Profile Page ....................................................................................................... 78
Figure 3-19. Expert Profile Page ............................................................................................................ 79
Figure 3-20. Expert and Customer Notification Page ............................................................................. 80
Figure 3-21. Admin Notification Page ................................................................................................... 80
Figure 3-22. Customer Cart ................................................................................................................... 81
Figure 3-23. Expert Cart Page................................................................................................................ 81
Figure 3-24. Customer Request .............................................................................................................. 82
Figure 3-25. Search Expert and Customer page ...................................................................................... 82
Figure 3-26. rate page ............................................................................................................................ 83
Figure 3-27. service page ....................................................................................................................... 83
Figure 3-28. add complain customer and expert page ............................................................................. 84
Figure 3-29. view complain for system page .......................................................................................... 84
Figure 3-30. view complain for user page .............................................................................................. 85
Figure 0-1. Contact form for warka group .............................................................................................. 88
Figure 0-2. a page used for registration (Ethiopian yellow pages) ........................................................... 89
Figure 0-3. a page used to contact friends (Ethiopian yellow pages) ....................................................... 89
ix
1. Introduction
1.1. Background of the organization
There are many maintenance organizations in Addis Ababa. Take for example, snap computers, dell
computers and lenjo mitad. However, we are not interested to make our project organization specific.
Instead, we want to bridge the information gap between the customers and experts or small maintenance
business organizations. Hence, our focus area is Addis Ababa city; we will reveal some truth about Addis
Ababa in the background section of our project.
Addis Ababa is the capital city of Ethiopia. It is the largest city in Ethiopia by population, with a total
population of nearly 4 million according to population census of 2017. It holds 527 square kilometers of
Ethiopia, with population density of nearly, 5,165 individuals per square kilometer available. Adult literacy
in the capital city is the highest among all of the cities in the countries cities, at over 93 percent for males
and almost 80 percent for females. Population in the near future is expected to grow to exceed 6.5 million
residents. The annual growth rate of the city has been estimated in recent years to be 3.8 percent. In prior
years, growth has been as much as 8 percent. The city is a thriving urban area in Ethiopia, and the jobs
available in Addis Ababa, the availability of clean drinking water and plumbing, and the many shops and
businesses ensure that growth will continue to be steady in this capital city well into the future [1].
Time concept in Addis Ababa
The majority of people in Addis Ababa do not over work themselves. Much value is given to social life and
have time at their disposal. Therefore, much value is not given to time. A person might arrive to an
appointment an hour late. The one who arrived on time will not be seriously offended for waiting, as this
became a culture. Even a term called " an Ethiopian appointment” was coined to refer to delays.
This has nothing to do with disrespect but a culture of not giving too much emphasis to the concept of
time. This is gradually changing these days because life in here is becoming a lot complicated. Now a
day’s people cannot support themselves and their families unless they are giving value to their time.
These means for the sake of survival people in Addis Ababa could not have a time to waste and could
have a lot of work to do. These is not really a problem for IT person like us, rather it is an opportunity.
Opportunities
When we were asked to bring title for our industrial project, we started to conduct some survey on the
current problems of our country. Our survey result reveals that there are difficulties of finding the right
expert at the right time when people encounter some problems on their devices. Bearing this in mind,
we proposed a web based help delivery system called Door-to-Door Help Delivery System.
Delivery system is any type of system that is used to bring services and products to where they are in
demand. There are different types of delivery systems. Some are product delivery systems and others are
service delivery systems. Our concern is on Door-to-Door Help Delivery System. Help delivery system is
not a common practice in Addis Ababa. However, there are other delivery systems like food delivery
system, and other ecommerce business. These types of systems are now increasing in its acceptance and
getting a wide coverage. These trends can proof that people in Addis has lower resistance to such kinds of
technological advancements and we have a great chance of success.
1
Now people get such kind of services using different ways. For example, people find search by friends, use
grafties or notice boards. People also started to reach out experts and organizations using web pages. Yellow
pages, ezega jobs and warka group are the main pages in which customers can reach out experts on the web.
The aim of our project is to develop a system that simplifies the way customers can get their problems
solved. Our project is supposed to work beyond problems that are not solved by the above ways of reach
out mechanisms.
Our system requires the registration of users and store users information so that it can easily find the nearest
expert with required skill per users need. We believe projects like ours is necessary to relive such kinds of
problems
1.2. Statement of the problem

Currently customers get in touch with experts using conventional methods like phone calls, graffiti’s,
flayers, ads on poles and even static web pages. We can talk about many problems that puts these systems
in question. For ease of understandability, we will try assess the problems of the current system using the
PIECES framework. PIECES is a simple framework used to identify the problem of systems from
perspectives of performance, information, economy, control, efficiency, and service.
Performances
 Poor time management, it takes a lot of time because an expert location is unknown
 The respond time is slow; the user cannot fix their problem in the time they need it.
 It is difficult to find expert at the time of need.
 In most expert shop or organization when a user want thing they have to wait a time for
there to be fix.
 There is a waste of time and energy
Information
 There is no information about the expert

 No back ground information
Economics
 The cost is higher, because

 Customer waste unnecessary cost, time and energy in making phone calls, transporting
devices etc.
 Hence quality of service is low: devices may not be fixed in the right way which makes
costing resources for nothing.
 Experts also find it difficult to open maintenance shop in Addis Ababa because of the cost of
renting house is very high which is beyond the capacity of start-ups.
Control (and security): too little security

 When they user left there things to be fixed they may lost their property this makes the
current system insecure.
 Difficulty in keeping track of material to be fixed and cost.
2
Efficiency
 The customer may wait for weeks up until things get fixed
 It may not be fixed properly, because getting the right expert is sometimes difficult
 The expert may miss thing to fix too
Services
 Difficulty of a communication mechanism between the expert and the customer.

 The existing system produce inaccurate result.
 The quality of the services
 Do user satisfied with the services?
1.3. Objective of the project
1.3.1. General Objective

The main objective of doing this project is to develop a web-based application that enables customers to
search for and deal with an expert of fixing home utility devices, home electronic devices, and home
furniture devices and other infrastructures.
1.3.2. Specific Objective

In order to achieve the above general objective, we need to perform the specific tasks including studying
similar systems, defining the problems of the current system, defining the requirements of the new system,
designing, developing and testing the new system.
1. Studying similar existing systems: Similar systems will be studied and analyzed deeply, to get a
better understanding of the problem and to understand the requirements of the new system we are
trying to build.
2. Defining problems of current similar systems: After understanding existing systems, we will
discuss the different problems that exist in the systems like warka.Group, Ethiopian yellow page
and Traditional advertising.
3. Defining the requirements for the new system: Because of the lack of online door-to-door help
delivery systems in Ethiopia and the fact that current similar systems have different problems, the
next step will be to identify the different requirements needed to build our new system.
4. Designing the new system: After requirements of the new system is clear and all possible
requirements are identified, we will be designing the system by planning different part of the
technology like the back-end, front-end and the DBMS.
5. Developing the new system: After designing the different parts of the system, the actual
coding of the plans and designs of the system will happen.
3
6. Implementation and testing of the new system: After coding the system, it will be deployed to
the designed environment and tested by different programmers as well as chosen users.
1.4. Feasibility study

The feasibility study is an evaluations and analysis of the potential of the project. Feasibility assessment
unveils the economic, technical and operational area. Risk that are involved in implementing of the project
it is a required activity for all information system project and could potentially be a large undertaking. The
following are major feasibly concerns that a business must be in clear light about. These are operational
feasibility, economic feasibility, economic feasibility, and technical feasibility.
1.4.1. Operational feasibility

Operational feasibility is measured by how well the solution will work in the organization. The system will
solve every problem stated in proposal.
We believe the new system is operationally feasible because we are going to:-
 Design it in an easy to use way after an initial training on how to use

 Develop it per user needs or requirements
 Design it with capability to provide the end users and managers with timely, accurate, reliable,
flexible and usefully formatted information.
 Develop with ability to provide adequate through put and response time.
 Develop with adequate control to protect against fraud and embezzlement (misuse) to guarantee
the accuracy and security of the data and information.
1.4.2. Economic feasibility

Economic feasibility is also referred to as cost/benefit analysis. The project is economically feasible since
we are getting sufficient free software required for the project from websites and others materials are
covered by the group members. We can apply the system with a limited amount of budget. After developing,
the project plays a great role in reducing time and budget consumption. Estimated cost for the project is
listed in the table below.
Cost
Cost refers to tangible and intangible cost that is incurred to develop the system.
Tangible cost
Is the cost that is directly measured in birr.
4
TABLE 1-1. BUDGET REQUIREMENT
No Items Expected cost
1 Transport 200
2 Telephone 100
3 Printing 400
4 Computer 16,000
5 Salary of workers 24,000
6 Total 40,700
Intangible cost
Lose of time and energy
Benefits
Benefits are paybacks from a business venture. This system will have tangible and intangible benefits.
Tangible benefits
Tangible benefit is an asset that produce income consistent with its fair market value, which is listed by
the wed developer or organization in a quantifiable form. A benefit that we get from using this web-based
application can easily measure in the following manner.
 Cost reduction and avoidance.

 Reduce the response time of activities.
Intangible benefits
Intangible benefit also called soft benefits, are the gains attributable of the improvement project that are
not reportable formal accounting purposes. In this case, we can see the benefits of using this web based
application that is not easy to measure in terms of money.
 Increase information accuracy.

 Enhance our knowledge about system analysis and design
 It may be used as a baseline to develop similar systems
Hence, the benefit outweighs the cost incurred in the long run we believe the developing this system is
economically feasible. In general, the economic feasibility helps us to manage the cost benefit to insure the
most profitable project is undertaken. Also, help us to determine whether revisions to a project that at first
seems unfeasible will make it feasible.
1.4.3. Technical feasibility

We have taken full system analysis and design courses, worked on different mini projects, understood
system analysis, design and implementation and now we are capable of writing software programs using
different programming languages. Having such a team, we believe developing the system is technically
feasible.
5
1.4.4. Social feasibility
The impact of this project is not limited to economical, technical and operational but instead social impact.
Experts can get to work on our web application either fulltime or part time. Customers can also ask for or
order help at any time. This keeps users overloaded with work whenever they want. It increase economic
freedom of the society. We believe an increase in economic freedom results in social feasibility.
1.4.5. Political feasibility

The aim of this project is may seem to shift the power balance from larger maintenance organizations to
small maintenance shops. However, the fact is different. Rather it is aimed to create an easy to enter market
place for experts in which they can sell their expertise to customers effectively and efficiently. It empowers
small business organizations by providing an easy to enter market place but it does not take over the power
of larger organizations. It creates a competitive environment between them and increases expert
reachability. This in turn results in quality of service and customer satisfaction. Therefore, we believe our
project is politically feasible.
1.5. Significance of the system

The main purpose of this project is to develop web application, which enables users to get expert in an easy,
cost effective and timely manner.
 Simplifies the way customers get experts to fix their devices.

 It empowers small local businesses.
 It saves time, energy and other resources.
 It reduces cost for the businesses as well as users
 24/7 availability send requests at any time any where
 Provide the customer base with an adequate choice and information about the expert they
work with.
1.6. Beneficiaries of the project

The system will primarily benefit customer that provides them all the time access to experts that are capable
of fixing things, it also help experts (individuals and organizations) who can fix home electronics devices,
home furniture workers, and home utility device experts. Those experts should be well experienced in their
related fields and fully registered and they will get services, promotions, and virtual market spaces from us.
People living in Addis Ababa and dealing with such staff will be other beneficiaries of the system.
The beneficiaries of the system are experts, customers, and system developers.
1. Customers are the primary beneficiaries of the system because the system provides them all time
access to experts that are capable of fixing devices.
2. Experts are can be benefited from the system, as the system opens opportunities to their service at
their disposal.
3. The development team is another beneficiary of the system as it gains system development
knowledge and experience. The team receives a degree for successfully developing the system. It
can also be used as a base line for other developers to develop related systems.
1.7. Methodology
Software development has different stages or phases and each phase has its own methodology trying to
achieve a problem.
6
1.7.1. Data collection methodology
Systems analysis is the part of the systems development life cycle in which you determine how a current
information system in an organization functions. Then you assess what users would like to see in a new
system. The two parts to analysis are determining requirements and structuring [1]. System analysts use
different requirement elicitation techniques such as interviews, questionnaires’, user observation,
workshops, brainstorming, introspection etc. After tuning it to our particular requirements, we decided to
use at least two or all in combination for identifying the requirements of the new system from the following
requirements elicitation mechanisms. These are interviewing, onsite observation, introspection, and
document analysis.
 Onsite observation
 Introspection
 Document analysis
Onsite observation
People, however, are not always reliable, even when they try to be and say what they think is the truth. As
odd as it may sound, people often do not have a completely accurate appreciation of what they do or how
they do it, especially when infrequent events, issues from the past, or issues for which people have
considerable passion are involved. Because people cannot always be trusted to interpret and report their
own actions reliably, you can supplement what people tell you by watching what they do in work situations
[1].
Observations helps
 To identify and guide relationships with informants.
 to learn how people in the setting interact and how things are organized and prioritized in that
setting,
 to learn what is important to the people in the social setting under study,
 to become known to participants, and
 to learn what constitutes appropriate questions,
 How to ask them, and which questions may best help you to answer the research questions.
Introspection
Introspection is the first and the most obvious method for trying to understand what properties a system
should have in order to succeed. In introspection technique, requirement analyst “imagines” what kind of
system is required for doing the required job or by using available equipment etc. Introspection is observing
one’s own thoughts and inner self. Despite this is employed by most of analysts to some extent, this
technique is mainly used mainly as a starting point for other requirement elicitation efforts. When users are
not available, don’t want to answer your questions or lack of feedback or input then Requirement Engineers
can use these technique to imagine the things which he assumes that the user would require [2].
This method can be very useful, but the problem is that users and experts being from different fields and
the introspection of one does not reflect the understanding of the other. It does not allow discussion with
stakeholders and other experts. Therefore, it is not encouraged if not used with in combination with other
techniques. Within its limitations, we believe introspection can be our main requirements elicitation
technique in combination with other techniques listed in this document.
Reasons to use introspection
7
 Introspection is an easier technique to apply.
 There are no costs for implementing this technique
 It can act as a good initial step to start requirements elicitation
Document analysis: We will analyze different documents if we think it is necessary and can teach us how
we should develop our system.
1.7.2. System development methodology

System development methodologies are a standard set of steps used to develop and support information
systems in organizations.
We need a methodology for analyzing a problem to be solved, planning for the design of the solution and
a construction method that minimizes the risk of error. We selected object oriented approach (OO) because
it produces easy solutions with better quality, reusability and extensibility easily within short period of time.
There are different object oriented different object oriented system development methodologies. We will
use waterfall system development methodology.
FIGURE 1-1. SYSTEM DEVELOPMENT LIFE CYCLE FOR DOOR TO DOOR HELP DELIVERY SYSTEM
8
1.8. Development tools and technologies
1.8.1. Front end technologies

These are technologies to be used to build web pages and user interfaces for web applications.
HTML
Html (HyperText Markup Language) is the most basic building block of the Web. It defines the meaning
and structure of web content.
Advantages of using html
It is easy to use and to learn, simple to edit, light weight, user friendly, and free. In addition to these, all
browsers support it.
CSS
CSS (Cascading Style Sheets) is a declarative language that controls how webpages look in the browser.
Advantages of using CSS
It saves time, help to make spontaneous change and consistent change, improve page loading speed, device
compatible, and makes search engine better crawl web pages.
JavaScript
Java script is a programming language used most often for dynamic client-side scripts on webpages and
allows you to implement complex things on web pages.
It is easy to learn, debug and test, fast no need of compilation, platform independent, and has programming
language capabilities.
Bootstrap
Bootstrap is a free, open source HTML, CSS, and JavaScript framework for quickly building responsive
websites.
It saves time, encourages consistency, provides an excellent grid system, creates responsive website.
JQuery
JQuery is a JavaScript Library that focuses on simplifying DOM(Document Object Model) manipulation.
It is open source, makes table sortable and dynamic, display easily charts, popup overs, modals, tabs,
integrated or compatible with bootstrap, highly extensible, cross-browser compatible.
AJEX
AJEX (Asynchronous JavaScript and XML ) allows to update parts of the DOM of a HTML webpage
instead of having to reload the entire page. It is the integration of JQuery and PHP.
It is easy to learn and use, allows changing content without refresh or reload webpage, makes website faster.
Response time is faster so increases performance and speed.
9
1.8.2. Back end technologies
These technologies used to deal with server, application and database.
PHP
PHP is a server side scripting language. That is used to develop Static websites or Dynamic websites or
Web applications. PHP stands for Hypertext Pre-processor, that earlier stood for Personal Home Pages.
It is open source. PHP is manly supported by all the operating systems like windows, unix, and linux. It can
be integrated with other programming language and database easily and there is no requirement of re-
development. Which means it saves a lot of effort and cost. It is simple and easy to learn and to code. It is
one of the fastest languages.
MySQL
MySQL is a free to use, open source database that facilitates effective management of database by
connecting them to the software.
Advantages of using MySQL
It is more secure and reliable, provides on demand scalability, and open source so reduces cost.
Apache
Apache is an open-source and free web server software that powers around 46% of websites around the
world. The official name is Apache HTTP Server, and it's maintained and developed by
the Apache Software Foundation.
Advantages of using Apache
It is open source, reliable and stable software. It is also easy to configure and has easily available support
in case of any problem.
XAMPP
XAMPP stands for Cross Platform Apache MariaDB(MYSQL), PHP, Perl
XAMPP is a free open source cross-platform web server solution stack package developed by Apache
Friends, consisting mainly of the Apache HTTP server, MariaDB database, and interpreters for scripts
written in the PHP and Perl programming languages.
Advantages of using XAMPP
It is easy to learn and install when compared with other web servers like WAMP. It consists of Apache, and
MYSQL, so there is no need of installing them separately. It is also possible to start and stop the web server
and database stack with one command.
10
1.8.3. Documentation and modeling tools
At the end of the project we will deliver system documentation and user documentation. Our system
documentation would be the description of detail information about user requirements; systems design
specifications, its internal workings and its functionalities. And our user documentation will be in the form
of online help with a web connection. It will contain information about the system; how it works and how
to use it.
We will use the following tools for our projects documentation.
Microsoft Visio pro. 2013 to draw UML diagrams and project schedule using Gantt chart
Balsamiq Mock up as prototyping tool
Microsoft Word 2016 as word editor.
1.9. Scope
Scope refers to all the work involved in creating the products of the project and the processes used to create
them. Project scope management includes the processes involved in defining and controlling what work is
or is not included in a project. It ensures that the project team and stakeholders have the same understanding
of what products the project will produce and what processes the project team will use to produce them [1].
It is very important to articulate what will be included and what will be excluded in this project. In fact we
will add additional functionality if we found it very necessary to the success of the project. We may also
discard functionality if we found it is not really important and affordable.
 It can register new users.

 It accepts queries from users.
 It can store user information.
 It can ping to the nearest experts whenever help request comes from the customer.
 It can provide a way of can evaluation of users.
Exclusions
There is no any system without any limitations. However, we believe understanding these limitations is of
great importance. Over time we will fill these gaps to suit the users. We have no any intention to include
the following functionality into our system.
There will be no payment system integrated into our system, because there is no full-fledged payment
system in Ethiopia.
1.10. Risks, assumptions and constraints

Assumptions
 We have enough time to complete the project.
 The cost we are going to invest is enough to get the project done.
 We will have improved internet connection or at least it continues like this.
 The cooperation of team members will be continued and better coordinated or the team is
dedicated.
11
Constraints
 Not all of our group members may participate responsibly.
 The time and therefore cost constraints may not go as estimated.
Risks
 Requirements may change at the end of the day.
 The level of awareness peoples have to technology may not be as expected, as a result people may
not adopt the new system easily.
1.11. Phases and deliverables of the project

By definition phase is the logical division of a project. Like many processes, the development of information
systems often follows a life cycle. A project may be single phase or a multiphase project accordingly. Most
organizations use system the standard system development life cycle (SDLC). System experts divided
SDLC into four major development phases. These phases includes System Planning and Selection, System
Analysis, System Design and Implementation and operation [1].
The entire Door-to-Door Help Delivery System will have seven logical phases. These are introduction,
business area analysis and requirements definition, object oriented analysis, conclusion of the first three
phases, object oriented design, object oriented implementation and conclusion of the entire project phases.
This report includes up to the conclusion of the first three phases.
Each phase of the project will have its own tasks and respective deliverables. The term deliverable describes
a product created as part of a project. Deliverables can be product related, such as a piece of hardware or
software, or process-related, such as a planning document or meeting minutes [1]. Our project deliverables
could be the set of software’s and documentations. The table below shows tasks and its corresponding
deliverables.
12
TABLE 1-2. PROJECT TASKS AND DELIVERABLES
Title Deliverables
System Planning and Selection  Convincing proposal document
Business Area analysis and Requirements  Existing systems documentation

 Requirements documentation
Definition
Object Oriented System Analysis  List of User Interfaces

 List of Business Rules
 System Use Case Diagram and Use Case
Description
 Class Diagram and Class Description
 Sequence Diagram
 User Interface Prototype
Conclusion  Revision of the previous phases of the project

and Concluding statement
Object Oriented System Design  Class Type Architecture

 Class Diagram and Description of Classes
 State chart diagram
 Component diagram
 Collaboration diagram
 Deployment diagram
 Relational model
 Database diagram
 User Interface Flow Diagram
 User Interface Design
Object Oriented Implementation  Working System Program integrated to database

initialized with data
Conclusion  Revision of the entire project and Concluding

paragraph
13
1.12. Work break down structure
A work breakdown structure (WBS) is a deliverable oriented grouping of the work involved in a project
that defines its total scope. Because most projects involve many people and many different deliverables, it
is important to organize and divide the work into logical parts based on how the work will be performed.
The WBS is a foundation document in project management because it provides the basis for planning and
managing project schedules, costs, resources, and changes. Because the WBS defines the total scope of the
project, some project management experts believe that work should not be done on a project if it is not
included in the WBS. Therefore, it is crucial to develop a good WBS [3]. The table bellow indicates the
work breakdown structure of our project.
TABLE 1-3. PROJECT WORK BREAK DOWN STRUCTURE

Phases Tasks Responsible person
1. System 1.1. Studying Background of the organization Abnet Tadesse
planning and 1.2. Stating Problem statement Dawit Shimelis
selection 1.3. Stating Objective of the project Getachew Amogne
1.4. Conducting Feasibility study
1.5. Analyzing Significance of the system
1.6. Determining Beneficiaries of the project
1.7. Selecting Development methodology
1.8. Development tools and technologies specification
1.9. Scoping of the project
1.10. Determining Risks assumptions and constraints
1.11.Determining Phases and deliverables of the project
Business area 2.1. Business area analysis Abnet Tadesse
Analysis and 2.1.1. Identifying Activities and functions of the Christian Million
requirements organization Abdulaziz Abdulbasit
dominion 2.1.2. Studying Problems of the current system
2.1.3. Identifying Players of the current system
2.2. Requirements definition Getachew Amogne
2.2.1. Specifying Functional requirements Abel Gebremedhn
2.2.2. Designing Essential use case modeling
2.2.3. Essential user interface prototyping
2.2.4. Non-functional requirements identification
Object Oriented 3.1. Design System use case All members of the
Analysis 3.1.1. UI identification group
3.1.2. Business rules identification
3.1.3. Actor identification
3.1.4. Designing the use case diagram
3.1.5. Use case description
3.2. Conceptual modeling
3.2.1. Class diagram
3.2.2. Class description
3.2.3. Sequence diagramming
3.2.4. Activity diagramming(optional)
3.2.5. User interface prototyping
14
1.13. Project schedule
Schedule s tool used to show a timely sequence of actions for a given project. Project time management,
simply defined, involves the processes required to ensure timely completion of a project. Gantt charts
provide a standard format for displaying project schedule information by listing project activities and their
corresponding start and finish dates in calendar form. Gantt charts are sometimes referred to as bar charts
because the activities’ start and end dates are shown as horizontal bars. Bellow is the Gantt chart used to
display our project schedule [1]. The table below represents our project schedule using Gantt chart.
15
FIGURE 1-2. PROJECT GANTT CHART
16
2. Business Area Analysis and Requirement Analysis
2.1. Introduction
So far in the proposal section we discussed about business requirements. However, business requirement is
not the only thing we need to define to build a system. User requirements is another important thing we
need to know. We will deal with user requirements latter in the next chapter. Know system requirement is
our concern.
And this chapter discusses the functionalities, problems, forms and reports used in the current system. In
addition to this, defining the functional and non-functional requirements of the proposed system will be our
major concern.
This chapter depicts the actors of the system, essential use case diagram with description; essential user
interface prototyping and finally the collaboration among different classes along with their responsibilities.
In defining the requirements, object-oriented approach will be used since it focuses on identifying the real-
world objects associated with the problem. Models will be built to represent the real-world objects. It also
mentions and describes different alternative options proposed to address problems of the existing system
and select out the best solution.
2.2. Business Area Analysis

In Addis Ababa people get help in different ways. The most common way of doing these is by using
traditional methods. People use for example, phone calls, advertisements on boards, pools, banners, and
even grafties. Some people also try to use internet to find their useful information. Web applications and
other technologies are now trying to replace the traditional ways of enquiring information. Ethiopia yellow
pages and warka group are some of web applications people use to get their relevant information. For our
study, we selected some of the methods from the traditional and web based methods people used to get their
information.
Warka group is a professional digital advertising and marketing agency company in Addis Ababa, Ethiopia
that provides web designing, web development, corporate identity and branding, graphic designing, search
engine marketing (SEM), search engine optimization (SEO), intelligent content marketing, video
marketing, Google analytics implementation, social media marketing, display advertising(banners, video
ads and Google Gadget ads) and much more.
At warka group, they believe in a consultative approach to provide strategic and integrated digital
advertising and marketing solution that use the right mix of mediums to CONNECT, ENGAGE, and
INSPIRE your prospects. This process incorporates industry research, market analysis, understanding
current trends, what future growth opportunities exist, what your business doing right and what it can do
better in the future. Furthermore, warka group is a leading managed IT services provide to companies for
any size in Ethiopia. They offer a fully integrated managed IT services across desktop, applications, IT
infrastructure, security products, data recovery, outsources IT help desk support, security, networking,
hosting and cloud solutions. They complete IT services allows their clients to boost their organizational
performance whilst reducing cost.
Ethiopian Yellow Pages is another website that used to share information to Ethiopian business community
with nearly similar functions with warka.group. It is a business directory for Ethiopian community. It stores
the phone numbers of local business organizations so that customers can easily find them.
17
2.2.1. Activities/Functions of the organization
In this section, we are going to identify activities and functions performed by existing systems that deliver
help to customers in traditional as well as modern mechanisms. These includes:-
Functionalities of receiving and sending information using board/wall/poles
 Making phone calls to experts to set appointments,

 Ask broker for experts
 Travel to expert’s location and negotiate service fees
 Transport devices to experts
 Experts fix the devices
Here are the functionalities of warka group web application
 Register customers and business organizations

 Allows customers to share webpage to other users
 Store user and business information
 Allow users to send messages
 In addition to these warka group provides other services like design, development, marketing, IT
support, IT security, Hosting, Cloud and consulting services.
2.2.2. Problems of the current system
 Time consumption: since where experts are located is not easily found.
 Costly, since customers transport their devices to the location of experts.
 Difficult to compare to compare the proficiency of experts, since customers contact only those with
known address such as telephone.
 Difficult to compare prices as there is no generic pool of resources.
 Most systems provide information about organizations but not about individuals.
2.2.3. Forms and Reports of the Current System

We asked the owner of warka group to give information about their system, but they were unwilling to
conduct an interview. Instead, they allowed us to get the necessary information from their website
warka.group. The website includes necessary information about the functions of the organization. Warka
groups has contact form, which enables customers to contact their organization. Warka groups contact form
allow customers to fill their name, address, and send messages to the organization. Once they submitted to
them the manager of warka group replays as soon as possible. See appendix A for more information.
Ethiopian yellow pages has a registration form in its website. User can register and can be customer of the
site by filling necessary information to the registration page. A form used for new customer registration for
Ethiopian yellow pages. The form used to register new users is appended in appendix A
Ethiopian yellow pages also has form that allows users to share the web page to other customers. To share
the website to friends user needs to find tell friend form and fill his, and his friends name and address
information and shares to them using their email. See the form used to share the web to friends in appendix
A.
18
2.2.4. Players of the Existing System
The current system comprises of different players (actors) to carry out their job. Among those here are the
most common ones:- experts, customers, clerks. An expert is one with special skill or knowledge. We call
experts those who are skilled in fixing and maintaining devices such as computers, mobile phones,
television etc. A customer is the one who gets these services whenever he needs. Admin receive and view
messages, replay to customers.
2.3. Requirements Definition

A requirement is simply a high-level, abstract statement of a service that a system should provide or a
constraint on a system. These requirements reflect the needs of customers for a system that serves a certain
purpose such as controlling a device, placing an order, or finding information. The process of finding out,
analyzing, documenting and checking these services and constraints is called requirements engineering [4].
Software system requirements are often classified as functional requirements or nonfunctional
requirements.
1. Functional requirements: These are statements of services the system should provide. How the system
should react to particular inputs, and how the system should behave in particular situations.
2. Non-functional requirements: These are constraints on the services or functions offered by the system.
2.3.1. Functional Requirements

The functional requirements for a system describe what the system should do. These are statements of
services the system should provide, how the system should react to particular inputs, and how the system
should behave in particular situations. When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by system users. However, more specific
functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in
detail. Functional system requirements vary from general requirements covering what the system should
do to very specific requirements reflecting local ways of working or an organization’s existing systems [4].
TABLE 2-1 FUNCTIONAL REQUIREMENTS

FR01 Landing page
FR02 Register new user
FR03 Manage service
FR04 Store users and service information
FR05 Retrieve information
FR06 Allow feedback and complain mechanism
FR07 Book customer requests
FR08 The system should enable experts to show up themselves.
FR09 Find and ping to the nearest expert
FR10 Allow administrators to track customer location
FR11 Search
FR12 Send notifications
FR13 Accept customers service request
FR14 Manage user
19
2.3.1.1. Essential Use Case Modeling
An essential use case sometimes called a business use case is a simplified, abstract, generalized use case
that captures the intentions of a user in a technology and implementation independent manner. A fully
documented essential use case is a structured narrative, expressed in the language of the application domain
and of users, comprising a simplified, abstract, technology-free and implementation-independent
description of one task or interaction, and also an essential use case is one that describes only the minimum
essential issues necessary to understand the required functionality [5].
Use case modeling, issues related to user activities in the business area have to be modeled and described
well enough to make things clear to provide the user with the newly proposed system. Use case modeling
has two parts: -
 Use case diagram: consists of use cases and actors

 Use case description: description of the diagram
List of Use Case
Informally speaking, a use case is a scenario that is performed on a system. Technically, a use case describes
the sequence of events of some types of users, called Actors, using some part of the system functionality to
complete a process. List of the use cases identified are: -
 Register
 View service
 Send request
 Cancel request
 View request
 Check out
 Rate
 View activities
 Replay to request
 Search
 View notification
 Update profile
 Track request
 Manage service
 Manage user
List of Actors
An actor represents a coherent set of roles that are entities, which are external to the system, can play in the
system. An actor represents a type of users of the system or external systems that the system interact with.
List of actors we have identified for the essential use case modeling are:
 Guest
 Customer
 Expert
 Admin
20
2.3.1.1.1. Essential Use Case Diagram
A use case is a list of steps, typically defining interactions between a role (known in UML as an "actor")
and a system, to achieve a goal. The actor can be a human or an external system. Use case diagram depicts
functionalities of the system a given user can perform to accomplish a task and meet his/her goal. In other
words, the diagram shows the interaction between the system and the user of the system.
The Following Diagram Shows the Essential Use Case Diagram for door to door help delivery system
FIGURE 2-1. ESSENTIAL USE CASE DIAGRAM
21
2.3.1.1.2. Use Case Description
TABLE 2-2. USE CASE DESCRIPTION FOR REGISTRATION
Use Case Name Register

Use Case ID UC001
Actor Guest
Use Case The use case enables guest create new account
Description
Trigger Guest wants to get access website
Precondition None
Main Flow 1. The use case start when guest click signup button
2. System display sign up form
3. Guest fill all personal information
4. System validates guest input
5. System checks that guest input are valid
6. System display success message
7. The use case ends
Alternative Flow A4 System validates guest input

A4.1 System checks that guest input are not valid
A4.2 system display error message
A4.3 the use case continue at step 2
TABLE 2-3. USE CASE DESCRIPTION FOR VIEW SERVICE

Use Case Name View Service
Use Case ID UC002
Actor Guest
Use Case The use case enables guest or random visitor to view available services
Description provided by the system
Trigger Guest wants to know if services are available

Precondition None
Main Flow 1. The use case start when guest access the website and get the landing
page
2. The system displays available services
3. Customer views available services
Alternative Flow None
22
TABLE 2-4. USE CASE DESCRIPTION FOR SEND REQUEST
Use Case Name Send Request

Use Case ID UC003
Actor Customer
Use Case This use case enables customers to send requests to the help provider in order
Description to get help
Trigger Customer wants to get access to one or more services provided by the system
Precondition None
Main Flow 1. The use case starts when customer selects send request option
2. The system displays request processing page
3. Customer fills service and address information
4. System validates customer input
5. System checks that customer input are valid
6. System checks customer system ping status
7. Users system ping status is switched on
8. System finds the nearest expert
9. The system add the request to cart
10. The system displays success message
Alternative Flow A4 System validates customer input

A4.1 System checks that customer input are not valid
A4.2 System displays error message
A4.3 The use case continue at step 2
B6 System checks customers system ping status
B6.1 Customers system ping switched off
B6.2 System displays the list of experts with required skill
B6.3 Customer selects expert he/she wants
B6.4 The use case continues at step 9
23
TABLE 2-5. USE CASE DESCRIPTION FOR CANCEL REQUEST
Use Case Name Cancel Request

Use Case ID UC004
Actor Customer
Use Case This use case enables a customer to cancel ordered requests
Description
Trigger The customer no longer need help
Precondition None
Main Flow 1. The use case starts when customer select cart option
2. The system displays customers list of his recent request
3. Customer select requested service went to cancel
4. Customer breaks the operation
5. Customer confirms and saves his/her recent request
TABLE 2-6. USE CASE DESCRIPTION FOR VIEW REQUEST
Use Case Name View Request

Use Case ID UC005
Actor Customer, Expert
Use Case This use case helps customer or expert to view the status of his/her previously
Description sent request
Trigger Customer or expert wants to know if the system is processing his/her request
Precondition None
Main Flow 1. The use case starts when the customer selects cart option
2. System displays customer or expert recent orders on the carts page
3. Customer or expert views the status of his/her request
24
TABLE 2-7. USE CASE DESCRIPTION FOR CHECKOUT
Use Case Name Check Out

Use Case ID UC006
Actor Customer, and Expert
Use Case The use case allows customer or expert to tell task is done
Description
Trigger Customer or expert wants to notify the system that a particular task is
completed successfully
Precondition None
Main Flow 1. The use case starts when the customer or expert select activity option
2. The system displays list of activities
3. Customer or expert check out completed tasks
4. System changes status of the task
TABLE 2-8. USE CASE DESCRIPTION FOR RATE
Use Case Name Rate

Use Case ID UC007
Use Case The use case allows customer or expert to rate another customer or expert
Description
Trigger Customer or expert wants to rate another customer or expert
Precondition None
Main Flow 1. The use case starts when the customer or expert access search page
2. The system displays list of customer or expert
3. Customer or expert rate another customer or expert
4. System changes status of rate selected customer or expert
25
TABLE 2-9. USE CASE DESCRIPTION FOR VIEW ACTIVITY
Use Case Name View Activity

Use Case ID UC008
Use Case This use case helps customer or expert to view all his/her previously activities
Description
Trigger Customer or expert wants to know all his/her previous activities
Precondition None
Main Flow 1. The use case starts when the customer selects activity option
2. System displays customer or expert recent working activity
3. Customer or expert views his/her activity
TABLE 2-10. USE CASE DESCRIPTION FOR REPLAY TO REQUEST

Use Case Name Replay to Request
Use Case ID UC009
Actor Expert
Use Case It enables an expert to tell his willingness to do a job
Description
Trigger Expert wants to do job
Precondition None
Main Flow 1. The use case starts when an expert access cart page
2. Expert select request
3. Expert hits accept selected request
4. System remove request from expert and customer cart
5. System add request to expert and customer activity
Alternative Flow A3. Expert hits deny button

A3.1. System removes from expert and customer cart
A3.2. The use case continues at step 6
26
TABLE 2-11. USE CASE DESCRIPTION FOR SEARCH
Use Case Name Search

Use Case ID UC010
Actor Customer, Expert, Admin
Use Case The use case allows customer, expert or admin to search for customer or
Description expert using name
Trigger Customer, expert or admin wants to search customer or expert directly
Precondition None
Main Flow 1. The use case starts when a customer, expert or admin enters the name
of customer or expert and click search button
2. System displays customer or expert information
TABLE 2-12. USE CASE DESCRIPTION FOR VIEW NOTIFICATION

Use Case Name Notification
Use Case ID UC011

Use Case The use case allows customer, expert or admin to view notification
Description
Trigger Customer, expert or admin wants to view notification
Precondition None
Main Flow 1. The use case starts when a customer, expert or admin selects
notification option
2. System display list of notification
3. Customer, expert or admin view notification
27
TABLE 2-13. USE CASE DESCRIPTION FOR UPDATE PROFILE
Use Case Name Update Profile

Use Case ID UC012
Use Case The use case allows customer, expert or admin to update profile
Description
Trigger Customer, expert or admin wants to view notification
Precondition None
Main Flow 1. The use case starts when a customer, expert or admin selects profile
option
2. System display his/her personal information
3. Customer, expert or admin update profile
TABLE 2-14. USE CASE DESCRIPTION FOR TRACK SERVICE
Use Case Name Track Service

Use Case ID UC013
Actor Admin
Use Case The use case allows admin to track services
Description
Trigger Admin wants to know where, when, and with who the service being working
Precondition None
Main Flow 1. The use case starts when admin selects track service option
2. System display request and activities services
3. Admin view request and activity services
28
TABLE 2-15. USE CASE DESCRIPTION FOR MANAGE SERVICE
Use Case Name Manage service

Use Case ID UC014
Actor Admin
Use Case The use case allows admin to manage services
Description
Trigger Admin wants to manage services
Precondition None
Main Flow 1. The use case starts when admin selects services option
2. System display services
3. Admin create, update or delete services
TABLE 2-16. USE CASE DESCRIPTION FOR MANAGE USER
Use Case Name Manage user

Use Case ID UC015
Actor Admin
Use Case The use case allows admin to manage users
Description
Trigger Admin wants to manage users
Precondition None
Main Flow 1. The use case starts when admin selects users option
2. System display users list
3. Admin grant or deny access, approve users
29
2.3.1.2. Essential User Interface Prototyping
An essential UI prototype is a low fidelity model or prototype of the UI for the actual system. It represents
the general ideas of behind the UI and not the exact detail. The purpose of this prototyping is mainly used
to understand the needs of the user and gather information related to user requirements.
Landing page
FIGURE 2-2. LANDING PAGE
30
Registration page
FIGURE 2-3. REGISTRATION PAGE

User type
FIGURE 2-4. USER TYPE-REGISTRATION PAGE
31
Terms and conditions
FIGURE 2-5. TERMS AND CONDITIONS-REGISTRATION PAGE

Service page
FIGURE 2-6. SERVICE PAGE
32
Activities page
FIGURE 2-7. ACTIVITY LIST-ACTIVITIES PAGE TO CUSTOMER AND EXPERT

User list page
FIGURE 2-8. CUSTOMER LIST-ADMIN PAGE
33
FIGURE 2-9. EXPERT LIST-ADMIN PAGE
Send request
FIGURE 2-10. SEND REQUEST PAGE
34
Cart page
FIGURE 2-11. CUSTOMER CART PAGE
FIGURE 2-12. EXPERT CART PAGE
35
Search page
FIGURE 2-13. SEARCH PAGE FOR EXPERT AND CUSTOMER PAGE

Profile page
FIGURE 2-14. CUSTOMER PERSONAL PAGE
36
FIGURE 2-15. ADMIN PERSONAL PAGE
FIGURE 2-16. EXPERT PERSONAL PAGE
37
Tracking service page
FIGURE 2-17. TRACKING SERVICE PAGE

Notification page
FIGURE 2-18. NOTIFICATION PAGE
38
2.3.2. Non-Functional Requirements
Non-functional requirements are requirements that are not specifically concerned with the functions
conveyed by the system. These are constraints on the services or functions offered by the system. They
include timing constraints, constraints on the development process, and constraints imposed by standards.
Non-functional requirements often apply to the system as a whole, rather than individual system features
or services [4].
Non-Functional Requirements for the proposed system include:
Performance
One of the benefits of our project is to deliver services quickly and efficiently. To achieve we believe it is
necessary to set performance requirement to our system. Any search result should not exceed a maximum
of 30 seconds. The system should send notification instantly whenever it is necessary.
Security
Information is an important asset. The more information you have at your command, the better you can
adapt to the world around you. In business, information is often one of the most important assets a company
possesses. Information differentiates companies and provides leverage that helps one company become
more successful than another [6]. We value our business and users information too.
Our system is a web application which have 24/7 connection to the internet. Unless we use different security
mechanisms, we could lose our information. This will endanger our system. Therefore, we will use different
security mechanisms. like:- authentication, authorization, and access control mechanisms
Scalability
We shall design the system by considering scalability. We can make it possible, because first the
methodology we are using was selected considering the future scalability of the system. The selected
methodology, i.e. object oriented system development methodology supports scalability. Second, the
system well be designed considering scalability. After, the system is designed and implemented the system
will allow to be used beyond maintenance services. System administrator will add services in their
respective categories and even add new categories.
Availability
Availability is the probability that a repairable system or system element is operational at a given point in
time under a given set of environmental conditions [7]. Availability is another concern of our system.
Our system will be with high availability when the system will be launched for the first time and will be in
continuous available when users need it.
The system should operate a minimum of 16 hours a day and 7 days a week. We decided our system to be
available from 4 a.m. to 4 p.m. This specification is based on our assumption that users will use the system
more off in the daytime. However, this is not the end. Availability requirements of the system will be
changed based on users need in the future. When the number of users is getting larger and users need higher
availability of the system we will make the system available 24/7.
39
Reliability
Reliability is defined as the probability of a system or system element performing its intended function
under stated conditions without failure for a given period. Reliability depends on availability and
maintainability[7].
Even if everything is going the in the right way if users do not perform their task honestly it will be a great
loose to our system. Therefore, we should consider reliability while designing our system. We will take the
following measures to make our system reliable.
2.4. Collaborative Modeling

Class responsibility collaborator model is a collection of standard index cards that have been divided into
three sections, as depicted in the following figures. Class represents a collection of similar objects, a
responsibility is something that a class knows or does, and a collaborator is another class that a class
interacts with to fulfill its responsibilities.
Collaboration modeling for customer class
Customer <domain>
ID Registration page<UI>
Address Profile page<UI>
Search page<UI>
register Feedback page<UI>
viewProfile Request page<UI>
rateExpert Notification page<UI>
complain Rate<domain>
sendrequest Complain<domain>
viewnotification Request<domain>
checkout Activity<domain>
updateProfile Customercontroller<controller>
TABLE 2-17. COLLABORATION MODEL FOR CUSTOMER CLASS

Collaboration modeling for expert class
Expert <domain>
ID Registration page(UI)
Address Profile page(UI)
Search page<UI>
register Feedback page<UI>
viewProfile Request page<UI>
rateCustomer Notification page<UI>
complain Rate<domain>
replayrequest Complain<domain>
viewnotification Activity<domain>
checkout Expertcontroller<controller>
updateProfile
TABLE 2-18. COLLABORATION MODEL FOR EXPERT CLASS
40
Collaboration modeling for admin class
Admin <domain>
ID Registration page(UI)
Address Profile page(UI)
Feedback page<UI>
register Request tracking page<UI>
viewProfile Notification page<UI>
viewcomplain Complain<domain>
trackrequest Activity<domain>
viewnotification Admincontroller<controller>
updateprofile
TABLE 2-19. COLLABORATION MODEL FOR ADMIN CLASS

Collaboration modeling for account class
Account<domain>
userName Customer<domain>
password Expert<domain>
Admin<domain>
Create account Registration page<UI>
Deactivate account Login page<UI>
Update account Profile page<UI>
Forget password Forget password page<UI>
login Change password page<UI>
Change status Verification page<UI>
Accountcontroller<controller>
TABLE 2-20. COLLABORATION MODEL FOR ACCOUNT CLASS
Collaboration modeling for service class
Service<domain>
serviceId Service page<UI>
serviceName Admin<domain>
serviceDescription Servicecontroller<controller>
serviceImage
serviceStatus
createService
updateService
displayService
deleteService
TABLE 2-21. COLLABORATION MODEL FOR SERVICE CLASS
41
Collaboration modeling for complain
Complain<domain>
complainID Search page<UI>
complainSubject feedback page<UI>
complianDetail Account<domain>
complainDate Complaincontroller<controller>
sendReport
displayReport
TABLE 2-22. COLLABORATION MODEL FOR COMPLAIN CLASS

Collaboration modeling for notification
Notification<domain>
notificationID Notification page<UI>
notificationType Account<domain>
notificationStatus Notificationcontroller<controller>
Shownotification
updatenotification
Disablenotification
TABLE 2-23. COLLABORATION MODEL FOR NOTIFICATION CLASS

Collaboration modeling for cart
Cart<domain>
cartId
sendDate Cart page<UI>
address Service<domain>
status Account<domain>
Requestcontroller<controller>
showCart
cancelRequest
viewMap
acceptRequest
TABLE 2-24. COLLABORATION MODEL FOR CART CLASS
Collaboration modeling for activity
Activity<domain>
activityID Activity page<UI>
sendDate Service<domain>
recievedDate Account<domain>
Activitycontroller<controller>
showActivities
checkOut
TABLE 2-25. COLLABORATION MODEL FOR ACTIVITY CLASS
42
3. Object Oriented Analysis
3.1. Introduction
In the previous chapter, we have clearly identified the problems of existing and we proposed an
alternative solution. And, also we pointed out functional and nonfunctional requirements of the new
system. We will focus on the modeling, and implementation of the new system.
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed without considering
any implementation details. In this chapter, we model the system using use case diagrams, class
diagrams, sequence diagrams and system prototypes. Identification of business rules is also another
concern of this chapter.
3.2. System Use Case
3.2.1. UI identification
User interface is the front end application view to which user interacts in order to use the software. User
can manipulate and control the software as well as the hardware by means of user interface. Today user
interface is found at almost every place where digital technology exists, right from computers, mobile
phones, cars, music players, airplanes, ships and etc. User interface provides a fundamental platform for
human-computer interaction.
TABLE 3-1. LIST OF USER INTERFACES

UI001 Landing page The first page user access whenever he wants to access the
website
UI002 Registration page A page that contains registration form
UI003 User Type page A page used to select user types
UI004 Terms and conditions page A page used to enter additional user information and agree with
terms and conditions
UI005 Login page A page in which a user can fill his login credentials
UI006 Activity page A page used to display activities to users
UI007 Track service page A page used to track how all requests are going
UI008 Service page A page used to manage service
UI009 Rating page A page used to display activities to users
UI010 complain page A page used to manage complain
UI011 User list A page used to display and users
UI012 Profile page A page used to display users profile
UI013 Notification page A page used to display notifications
UI014 Cart page A page used to display requests
UI015 Request sending page A page used to send requests
UI016 Search page A page used to search
3.2.2. Business Rules Identification

A business rule defines or constrains one aspect of your business that is intended to assert business structure
or influence the behavior of your business. Business rules often supplement usage or user interface
requirements.
Saying it in another way business rules are statements that governs business decision making day in and
day out in our business. Documenting business rules clearly and making sure they don’t conflict is a
43
valuable activity. Because when carefully managed, rules can be used to help the organization to better
achieve their goals, remove obstacles, to market growth, reduce costly mistakes, improve communication,
comply with legal requirements, and increase customer loyalty.
TABLE 3-2. LIST OF RULES

Rule Description
BR01 To access services of the system user should be registered
BR02 Up on registration a guest should agree on terms and conditions of our system to be a
registered user of the system.
BR03 For effective monitoring and controlling, only the system administrator should approve
expert’s registration.
BR04 System administrator should approve experts registration based on the documents owned
by the expert.
BR05 A task is said to be completed if and only if both the customer and an expert confirms its
completion.
3.2.3. Actor Identification

An actor is a person, organization, or external system that plays a role in one or more interactions with your
system. Actors are drawn as stick figures.
List of actor
 Guest
 Customer
 Expert
 Admin
Use cases
 Register
 View services
 Login
 Send request
 Cancel request
 Rate
 View request
 View activity
 Checkout
 Replay to request
 Change status
 Search
 See notification
 Update profile
 Approve
 Activate user account
 Add service
 Change service status
44
 View complain
 Track service
3.2.4. Designing the Use Case Diagram
FIGURE 3-1. SYSTEM USE CASE DIAGRAM
45
3.2.5. Use Case Description
Use case description for system use case register
Use Case Name Register

Use Case ID SUC001
Actor Guest
Use Case The use case allows users to register into the system
Description
Trigger User wants to register to the system
Precondition None
Main Flow 1. Use case starts when user clicks a button for registration on the
landing page-UI001.
2. User selects appropriate button for registration on the landing page
3. System displays the registration page-UI002
4. User fills basic information on registration page
5. System validates user information
6. User information is valid
7. System displays user type page-UI003
8. User selects user type he wants to be and proceeds
9. System displays terms and conditions page-UI004
10. User accepts or rejects terms and conditions of the business according
to the business rule-BR002
11. User accepts terms and conditions and proceeds
12. System sends verification number to users email using verification
page-UI005
13. System asks user for email verification using verification page-UI005
14. User enters his verification number
15. System adds user information to user table and account table
16. System returns registration successful message to the user
17. Use case registration ends
Alternative Flow A5 System validates user information
A5.1 System validates that user information is incorrect
A5.2 System tells the user that the information provided is incorrect and
prompts to enter another input on registration page-UI002
A5.3 Use case continues at step 3
TABLE 3-3. USE CASE DESCRIPTION FOR SYSTEM USE CASE REGISTRATION
46
Use case description for system use case login
Use Case Name Login

Use Case ID SUC002
Use Case The use case allows a user to login to the system
Description
Trigger User wants to login to the system
Precondition None
Main Flow 1. Use case starts when user clicks login button to log in to the system
on the landing page-UI001
2. System displays the login page-UI006
3. User fills the credentials correctly and proceeds
4. System validates user credentials
5. System checks that user credentials are valid
6. System returns login successful message to the user
7. System redirects the user to his home page
Alternative Flow A4. System validates user credentials
A4.1. System checks that user credentials are invalid
A4.2. System displays login unsuccessful try again message
A4.3. The use case continues at step 2
TABLE 3-4. USE CASE DESCRIPTION FOR SYSTEM USE CASE LOGIN
Use case description for system use case view service
Use Case Name View Service

Use Case ID SUC003
Use Case The use case enables customer or expert to view available services provided
Description by the system
Trigger User wants to know if services are available
Precondition None
Main Flow 1. The use case starts when user selects home from the vertical
navigation bar page
2. The system displays available services
3. User views available services
TABLE 3-5. USE CASE DESCRIPTION FOR SYSTEM USE CASE VIEW SERVICE
47
Use case description for system use case send request
Use Case Name Send request

Use Case ID SUC004
Actor Customer
Use Case The use case allows a customer to send request to get services
Description
Trigger User wants to get service
Precondition SUC002
Main Flow 1. The use case starts when the customer selects add to cart option
2. System display input form
3. Customer fills service and address information
4. System validates user input
5. System checks that user input are valid
6. System checks the system ping option from users setting
7. System checks that the system ping option is switched on
8. System finds the nearest on duty experts with the required skill
9. System asks for customer confirmation
10. User confirms his request to continue
11. System adds the request to the carts page
12. System displays success message
Alternative Flow A4. System validates user input
A4.1 System checks that user input are not valid
A4.2 System display error message
A4.3 the use case continues at step 2
B6. System checks the system ping option from users setting
B6.1. System checks that the system ping option is switched off
B6.2. System displays list of available experts
B6.3. User gives order to the expert he wants
B4.4. The use case continues at step 9
C9. System asks for customer confirmation
C9.1. User confirms request to cancel
C9.2. The use case returns one step back
TABLE 3-6. USE CASE DESCRIPTION FOR SYSTEM USE CASE SEND REQUEST
Use case description for system use case view request status
Use Case Name View Request

Use Case ID SUC005
Use Case The use case enables customer and expert to view how requests sent are going
Description
Trigger Customer and expert wants to know request service status
Precondition SUC002
Main Flow 1. The use case starts when the user access carts page
2. System displays carts page
3. User views request
48
TABLE 3-7. USE CASE DESCRIPTION FOR SYSTEM USE CASE VIEW REQUEST STATUS
Use case description for system use cancel request
Use Case Name Cancel Request

Use Case ID SUC006
Actor Customer
Use Case The use case enables a customer to cancel requests sent
Description
Trigger Customer wants to cancel request
Precondition SUC002, SUC005
Main Flow 1. The use case starts when the user access carts page
2. System displays carts page
3. Customer selects the request he wants to cancel
4. System displays options available to be manipulated on that particular
request
5. Customer selects cancel request option
6. System asks the user for confirmation
7. User confirms yes
8. System changes the request status to canceled
Alternative Flow A6 System asks the user for confirmation
A6.1 User confirms no
TABLE 3-8. USE CASE DESCRIPTION FOR SYSTEM USE CANCEL REQUEST
Use case description for system use case view notification
Use Case Name See Notification

Use Case ID SUC007
Use Case The use case allows user to see his/her notifications
Description
Trigger User wants to view notifications
Precondition SUC002
Main Flow 1. The use case starts when the user selects notifications option
2. System displays list of notifications
3. User selects the notification he wants to view
4. System displays notification detail
5. User view notification
6. System updates notification status
TABLE 3-9. USE CASE DESCRIPTION FOR SYSTEM USE CASE SEE NOTIFICATION
49
Use case description for system use case search
Use Case Name Search

Use Case ID SUC008
Use Case The use case allows user to find users
Description
Trigger User wants to find users
Precondition SUC002
Main Flow 1. The use case starts when the user fill inputs to search box and click.
2. System display users list that matches user input
3. User view displayed user list
TABLE 3-10. USE CASE DESCRIPTION FOR SYSTEM USE CASE SEARCH
Use case description for system use case update profile
Use Case Name Update Profile

Use Case ID SUC009
Use Case The use case allows user to update his/her profiles
Description
Trigger User wants to update his/her profiles
Precondition SUC002
Main Flow 1. The use case starts when the user access profile page
2. System displays profile page
3. User fills his personal information
4. System validates user input
5. System checks that user input are valid
6. System saves information
Alternative Flow A4 System validates user input
A4.1 System checks that user input are not valid
A4.2 System display error massage
TABLE 3-11. USE CASE DESCRIPTION FOR SYSTEM USE CASE UPDATE PROFILE
50
Use case description for system use case view activities
Use Case Name View Activities

Use Case ID SUC010
Use Case The use case allows user to view his/her activities
Description
Trigger User wants to view activities
Precondition SUC002
Main Flow 1. The use case starts when the user access activities page
2. System displays activity page
3. Customer views activities
TABLE 3-12. USE CASE DESCRIPTION FOR SYSTEM USE CASE VIEW ACTIVITIES
Use case description for system use case replay to request
Use Case Name Replay to Request

Use Case ID SUC011
Actor Expert
Use Case The use case allows expert to replay to request
Description
Trigger Expert wants to replay to requests
Main Flow 1. The use case starts when the expert selects a particular request from
the carts page
2. Expert selects request
3. System displays possible manipulation on the selected request
4. Expert accept or deny request
5. System checks expert selection
6. Expert accepts request
7. System removes request from carts list
8. System adds request to activities list
9. System display message success to expert
Alternative Flow A5. System checks expert selection
A5.1. Expert deny request
A5.2. System removes request from carts list
A5.3. System display cart page
A5.4. The use case ends
TABLE 3-13. USE CASE DESCRIPTION FOR SYSTEM USE CASE REPLAY TO REQUEST
51
Use case description for system use case change status
Use Case Name Change status

Use Case ID SUC012
Actor Expert
Use Case The use case allows an expert to change his/her status
Description
Trigger User wants to change his/her status
Main Flow 1. The use case starts when the experts access profile page
2. Expert selects the profiles option
3. System displays experts profile
4. Expert selects status
5. System displays on or off status option
6. Expert selects one of the two options
7. System check status selected
8. Expert switches his/her status on
9. System update expert status to on from onduty
10. System displays status changed information to the expert
11. Expert sees status has changed information
Alternative Flow A7 System check status selected
A7.1 system update expert status to off from onduty
A7.2 The use case continues at step 10
TABLE 3-14. USE CASE DESCRIPTION FOR SYSTEM USE CASE CHANGE STATUS
Use case description for system use case rate
Use Case Name Rate

Use Case ID SUC013
Use Case The use case allows an customer and expert to rate another customer or expert
Description
Trigger customer or expert wants to change his status
Main Flow 1. The use case starts when the user clicks rate user option
2. System displays message box
3. User fills rate reason for a given rate level
4. System changes status of rated user
TABLE 3-15. USE CASE DESCRIPTION FOR SYSTEM USE CASE RATE
52
Use case description for system use case check out
Use Case Name Check Out

Use Case ID SUC014
Use Case The use case allows customer or expert to tell task is done
Description
Trigger Customer or expert wants to notify the system that a particular task is
completed
Precondition SUC002
Main Flow 1. The use case starts when the user select activity option
2. The system displays list of activities
3. User select a particular activity
4. System display possible manipulations to be performed on the
selected task
5. User check out selected activity
6. System changes status of the task and displays successful massage

TABLE 3-16. USE CASE DESCRIPTION FOR SYSTEM USE CASE CHECK OUT
Use case description for system use case track service
Use Case Name Track Service

Use Case ID SUC015
Actor Admin
Use Case The use case allows admin to track services
Description
Trigger Admin wants to know all detail about working service
Precondition SUC002
Main Flow 1. The use case starts when admin selects track service option
2. System display request and activities services
3. Admin view request and activity services
TABLE 3-17. USE CASE DESCRIPTION FOR SYSTEM USE CASE TRACK SERVICE
53
Use case description for system use case view complain
Use Case Name View complain

Use Case ID SUC016
Actor Admin
Use Case The use case allows admin to view complain
Description
Trigger Admin wants to know what the users are feeling of using the service
Precondition SUC002
Main Flow 1. The use case starts when admin selects complain option
2. System display list of complain
3. Admin view complain
TABLE 3-18. USE CASE DESCRIPTION FOR SYSTEM USE CASE COMPLAIN
Use case description for system use case approve registration
Use Case Name Approve Registration

Use Case ID SUC017
Actor Admin
Use Case This use case allows admin to approve expert
Description
Trigger Admin wants to approve experts
Precondition SUC002
Main Flow 1. The use case starts when admin access users page and expert tab
2. System display list expert
3. Admin select a particular expert
4. Admin click approve
5. System asks the admin for confirmation
6. Admin confirm yes
7. System change approve status of expert
8. Admin view changed status

A5.1 Admin confirm no use case continue at step 2
TABLE 3-19. USE CASE DESCRIPTION FOR SYSTEM USE CASE APPROVE REGISTRATION
54
Use case description for system use case activate user account
Use Case Name Activate user account

Use Case ID SUC018
Actor Admin
Use Case This use case allows admin to grant and revoke user from using the application
Description
Trigger Admin wants grant or revoke users from accessing the website
Precondition SUC002
Main Flow 1. The use case starts when admin access users page
2. System display user list
3. Admin select a particular user
4. System displays possible manipulations to be performed
5. Admin clicks grant
6. System asks for confirmation
7. Admin confirm yes
8. System change access status of user and displays success message
9. Admin view changed status

A5.1 Admin confirm no use case continue at step 2
TABLE 3-20. USE CASE DESCRIPTION FOR SYSTEM USE CASE ACTIVATE USER ACCOUNT
55
Use case description for system use case add service
Use Case Name Add service

Use Case ID SUC019
Actor Admin
Use Case This use case allows admin to add new service
Description
Trigger Admin wants to add new service
Precondition SUC002
Main Flow 1. The use case starts when admin access service page
2. System display list of service
3. Admin select add service
4. System display input form
5. Admin fill all inputs
6. System validate user inputs
7. System found user input valid
8. System add new service
9. System display successful message
Alternative Flow A6 System validate user inputs

A6.1 System found user input invalid

TABLE 3-21. USE CASE DESCRIPTION FOR SYSTEM USE CASE ADD SERVICE
56
Use case description for system use case change service status
Use Case Name Change service status

Use Case ID SUC020
Actor Admin
Use Case This use case allows admin to update existing service
Description
Trigger Admin wants to update existing service
Precondition SUC002
Main Flow 1. The use case starts when admin clicks update service option
2. System display input form with current value
3. Admin enters new value
4. System validate inputs
5. System found input valid
6. System saves service information
Alternative Flow A4 System validate user inputs

A4.1 System found user input invalid
TABLE 3-22. USE CASE DESCRIPTION FOR SYSTEM USE CASE CHANGE SERVICE STATUS
3.3. Conceptual Modeling
Conceptual model is a representation of a system, make of the composition of concepts which
are used to help people know, understand, or simulate a subject the model represents. It is also a
set of concepts.
3.3.1. Class Diagram

Class models show the classes of the system, their interrelationships (including inheritance, aggregation,
and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety
of purposes, including both conceptual/domain modeling and detailed structural design modeling.
57
FIGURE 3-2. CLASS DIAGRAM
58
3.3.2. Class Description
Account
This class used to contain information about user accounts
Attributes
Attribute Name Attribute Description
userTag stores the user tag of users/ identifies the user gives by system
userName stores user name of user, use to access the system
password stores password of user
accessStatus Store users accessibility the website
deactiveAccount Store users the willingness of to use the system
userType Store user type
Methods
Method Name Method Description
createAccount() used to register new accounts or user name and password
updateAccount() change account info
login() authenticates the user to access his account information and do

manipulations on
TABLE 3-23. ACCOUNT CLASS DESCRIPTION
59
Expert
refers to user who wants to get job using our system
Attributes
expertID Identifies unique table content
fullName allows to store full name of experts
Gender allows to store experts gender
Age stores experts Age
Email stores experts email
Phone stores experts telephone number
Address stores experts address
About stores experts About Summery
Date Stores experts entry date

imageAddress Stores experts profile image the actual store url
workedOn stores experts working services
educlevel stores experts educational level
Appoved stores approval status
Methods
addExpert() registers new expert
showExpert() Allows the user to show all his/her personal information

updateProfile() allows the user to update all his/her personal information
deleteExpert() Remove expert
TABLE 3-24. EXPERT CLASS DESCRIPTION
60
Admin
refers to user who have the privilege to control the system
Attributes
adminID Identifies unique table content
fullName allows to store full name of admin
Gender allows to store admin gender
Age stores admin age
Email stores admin email
Phone stores admin telephone number
Address stores admin address
About stores admin About Summery
Date Stores admin entry date

imageAddress Store admin profile image the actual store url
Methods
addAdmin() registers admin
showAdmin() Allows the user to view his/her personal information

deleteAdmin() Remove admin info
TABLE 3-25. ADMIN CLASS DESCRIPTION
61
Customer
refers to user who wants to get services using our system
Attributes
customerID Identifies unique table content
fullName allows to store full name of customers
Gender allows to store customers gender
Age stores customers age
Email stores customers email
Phone stores customers telephone number
Address stores customers address
About stores customers about Summery
Date Stores customers entry date

imageAddress Store customers profile image the actual store url
Methods
addCustomer() registers new customer
showCustomer() Show customer

deleteCustomer() Delete customer
TABLE 3-26. CUSTOMER CLASS DESCRIPTION
62
Notification
Attributes
notificationID identifies notification uniquely
notificationType stores notification type
notificationSubject stores subject of notification
notificationDetail contains the detail or body of notification
sendDate stores date of notification
Seen stores seen by user or not
Methods
showNotification() makes notification visible to user whenever necessary
send Notification() sends notification from user/system to another user
updateNotification() used to update notification status
TABLE 3-27. NOTIFICATION CLASS DESCRIPTION

File-Expert
Attributes
fileID identifies file uniquely
fileName stores name of file
fileCategories stores categories of file
fileAddress stores actual address of file
Methods
showFile() View file

addFile() Store file in database
deleteFile() Remove file
TABLE 3-28. FILE EXPERT CLASS DESCRIPTION
63
Complain
Attributes
complainID identifies complain uniquely
complainType stores complain type
complainSubject stores subject of complain
complainDetail contains the detail or body of complain
complainDate stores date of complain
Methods
showComplain() makes complain visible to admin whenever necessary
sendComplain() sends complain from user to admin
TABLE 3-29. COMPLAIN CLASS DESCRIPTION

Rate
Attributes
RateID identifies rate uniquely
rateNumber stores the number of rate
rateReason
Methods
showRate() show rate

addRate() Store rate scale in database
updateRate() updated rate scale
TABLE 3-30. RATE CLASS DESCRIPTION
64
Service
Attributes
serviceID identifies service uniquely
serviceName stores the name of services
serviceDescription stores description of service
serviceImage contains the image of service
serviceStatus Tells the service is on or off
Methods
showService() makes service visible to admin whenever necessary
createService() store Service in database
updateService() Update status of service
TABLE 3-31. SERVICE CLASS DESCRIPTION

Request
Attributes
requestID identifies request uniquely
sendDate stores the date of the service request
Address stores address where the task to be done
Methods
showRequest() makes request visible to user whenever necessary
createRequest() store requested service in database
deleteRequest() remove requested service
TABLE 3-32. REQUEST CLASS DESCRIPTION
65
Activity
Attributes
activityID identifies activity uniquely
sendDate used to store date send by the customer
receiveDate used to store date received by the expert
Address stores address where can be task done
Status Tells the activity completed or not
checkoutExpert Store expert checkout
checkout Store user checkout
Methods
showActivity() used to display activity
addActivity() store accepted service in database
updateActivity() update service status
TABLE 3-33. ACTIVITY CLASS DESCRIPTION
66
Onduty-Expert
Attributes
ondutyID identifies onduty-expert uniquely
currAddress stores Current address of expert
onlineStatus Stores expert online status

Status stores status of expert
Methods
addOnduty() Store file in database
updateOnduty() Update status of expert
showOnduty() Show onduty experts
TABLE 3-34. ONDUTY-EXPERT CLASS DESCRIPTION

3.4. Sequence Diagramming
Definition: A sequence diagram, in the context of UML, represents object collaboration and is used to
define event sequences between objects for a certain outcome. A sequence diagram is an essential
component used in processes related to analysis, design and documentation.
67
Sequence diagram for user registration
FIGURE 3-3. SEQUENCE DIAGRAM FOR REGISTRATION
68
Sequence diagram for login
FIGURE 3-4. SEQUENCE DIAGRAM FOR LOGIN
69
Sequence diagram for view service
FIGURE 3-5. SEQUENCE DIAGRAM FOR VIEW SERVICE
70
Sequence diagram for cancel request
FIGURE 3-6. SEQUENCE DIAGRAM FOR USE CASE CANCEL REQUEST
71
Sequence diagram for view notification
FIGURE 3-7. SEQUENCE DIAGRAM FOR VIEW NOTIFICATION
72
3.5. User interface Prototyping
A prototype is an early sample, model, or release of a product built to test a concept or process. Prototype is
an early sample of design used to get feedback and rapid experiments with new ideas.
Landing page
FIGURE 3-8. LANDING PAGE
73
Registration page
FIGURE 3-9. REGISTRATION PAGE

User type
FIGURE 3-10. USER TYPE- REGISTRATION PAGE
74
Terms and conditions.
FIGURE 3-11. TERMS AND CONDITIONS- REGISTRATION PAGE

Login page
FIGURE 3-12. LOGIN PAGE
75
Activity page
FIGURE 3-13. ACTIVITIES PAGE-CUSTOMER AND EXPERT

Tack service page
FIGURE 3-14. TACK SERVICE PAGE-FOR ADMIN
76
User list
FIGURE 3-15. CUSTOMER LIST FOR ADMIN
FIGURE 3-16. EXPERT LIST FOR ADMIN
77
Admin Profile page
FIGURE 3-17. ADMIN PROFILE PAGE

Customer profile page
FIGURE 3-18. CUSTOMER PROFILE PAGE
78
Expert profile page
FIGURE 3-19. EXPERT PROFILE PAGE
79
Expert and Customer notification page
FIGURE 3-20. EXPERT AND CUSTOMER NOTIFICATION PAGE

Admin notification Page
FIGURE 3-21. ADMIN NOTIFICATION PAGE
80
Cart Pages
FIGURE 3-22. CUSTOMER CART
FIGURE 3-23. EXPERT CART PAGE
81
Service request page
FIGURE 3-24. CUSTOMER REQUEST

Search page
FIGURE 3-25. SEARCH EXPERT AND CUSTOMER PAGE
82
Rate page
FIGURE 3-26. RATE PAGE

Service page
FIGURE 3-27. SERVICE PAGE
83
Complain page
FIGURE 3-28. ADD COMPLAIN CUSTOMER AND EXPERT PAGE
FIGURE 3-29. VIEW COMPLAIN FOR SYSTEM PAGE
84
FIGURE 3-30. VIEW COMPLAIN FOR USER PAGE
85
4. Conclusion
We have worked so much in the previous portion chapters of the document. Just to remember in the
proposal section of the document we discussed a little about the background of the target area, Addis
Ababa, the way customers reach experts, the problems of these methods. We proposed a system that can
overcome these problems per our knowledge of problem solving. We believe, the proposed system I.e.
Door to Door Help Delivery System can alleviates the problems of both experts and customers. We also
noted that the benefits of this system is not limited to overcoming the problems of customers and experts,
instead it is advantageous to students and system developers in related area.
In the second chapter, we performed business area analysis. We selected three currently working systems
and analyzed from different perspectives. We studied how they worked; what problems do they have;
who the participants are. Studying clearly the current system clearly helped us to identify the problems of
the current system and propose alternative solutions. From what we have learned from the existing system
and our understanding, we determined our system to fulfill certain requirements. We classified the
requirements in to two categories i.e. Functional and nonfunctional requirements.
86
References
[1 "World poplution review," 12 05 2019. [Online]. Available:

] http://worldpopulationreview.com/world-cities/addis-ababa/. [Accessed 03 10 2019].
[2 V. S. Joseph, G. F. Joey and H. A. Jeffery , Essentials of System Analysis and Design, Unknown:
] Pearson, September 18, 2014.
[3 F. Fahad, "slideshare.net," Linkedin Learning, 28 January 2018. [Online]. Available:

] https://www.slideshare.net/FahadFarooq21/introspection-software-requirement-elicitation-
technique. . [Accessed 29 November 2019].
[4 K. Schwalble, Informatiom Technology Project Management, Boston: Cangage India, 2004.

]
[5 S. Ian, Softwarre Engineering, unknoun: pearson, March 13, 2010.

]
[6 D. Alan, W. H. Barbara and T. David, System Analysis and Design Using UML 4th Edition, unknown:
] Wiley, Hardcover, 2012.
[7 R.-O. Mark, Information Security, The Complete Reference(Second Edition), Unknown: McGraw-Hill
] Osborne, 2013.
[8 S. Authors, "Reliability, Availability, and Maintainability," San Diego, CA: International, 2 June 2019.
] [Online]. Available:
https://www.sebokwiki.org/w/index.php?title=Reliability,_Availability,_and_Maintainability&oldid=
57237. [Accessed 3 January 2020].
87
Appendix A
FIGURE 0-1. CONTACT FORM FOR WARKA GROUP
Registration form for Ethiopian yellow pages
88
FIGURE 0-2. A PAGE USED FOR REGISTRATION (ETHIOPIAN YELLOW PAGES)
A page used to reach out and share the web page with friends for Ethiopian yellow pages
FIGURE 0-3. A PAGE USED TO CONTACT FRIENDS (ETHIOPIAN YELLOW PAGES)
89

Door To Door Help Delivery System (Industrial Project)

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

Door To Door Help Delivery System (Industrial Project)

Uploaded by

Copyright:

Available Formats

ADDIS ABABA UNIVERSITY COLLEGE OF NATURAL

SCIENCE DEPARTMENT OF INFORMATION

Door to Door Help Delivery System

——————— ——————— ————

——————— ——————— ————

——————— ——————— ————

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

CSS ……………………………………………Cascading Style Sheets

AJaX …………………………………………Asynchronous Javascript And

XML …………………………………………..Extensible Markup Language

PHP……………………………………………. Hypertext Pre-processor

XAMPP……………………………………Cross Platform Apache Mariadb(Mysql), Php, Perl

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

SDLC…………………………………………. System Development Life Cycle

WBS …………………………………………..Work Breakdown Structure

SEM………………………………………….. Search Engine Marketing

SEO…………………………………………… Search Engine Optimization

Time concept in Addis Ababa

1.2. Statement of the problem

 There is no information about the expert

 The cost is higher, because

Control (and security): too little security

 Difficulty of a communication mechanism between the expert and the customer.

1.3. Objective of the project

1.3.1. General Objective

1.3.2. Specific Objective

1.4. Feasibility study

1.4.1. Operational feasibility

 Design it in an easy to use way after an initial training on how to use

1.4.2. Economic feasibility

 Cost reduction and avoidance.

 Increase information accuracy.

1.4.3. Technical feasibility

1.4.5. Political feasibility

1.5. Significance of the system

 Simplifies the way customers get experts to fix their devices.

1.6. Beneficiaries of the project

Reasons to use introspection

1.7.2. System development methodology

1.8.1. Front end technologies

Advantages of using html

Advantages of using CSS

Advantages of using MySQL

Advantages of using Apache

XAMPP stands for Cross Platform Apache MariaDB(MYSQL), PHP, Perl

Advantages of using XAMPP

We will use the following tools for our projects documentation.

Balsamiq Mock up as prototyping tool

Microsoft Word 2016 as word editor.

 It can register new users.

1.10. Risks, assumptions and constraints

1.11. Phases and deliverables of the project

System Planning and Selection  Convincing proposal document

Business Area analysis and Requirements  Existing systems documentation

Object Oriented System Analysis  List of User Interfaces

Conclusion  Revision of the previous phases of the project

Object Oriented System Design  Class Type Architecture

Object Oriented Implementation  Working System Program integrated to database

Conclusion  Revision of the entire project and Concluding

TABLE 1-3. PROJECT WORK BREAK DOWN STRUCTURE

2.2. Business Area Analysis

Functionalities of receiving and sending information using board/wall/poles

 Making phone calls to experts to set appointments,