All in One

ADDIS ABABA UNIVERSITY
ADDIS ABABA UNIVERSITY INSTITUTE OF

TECHNOLOGY
CENTER OF INFORMATION TECHNOLOGY AND
SCIENTIFIC COMPUTING
DEPARTMENT OF SOFTWARE ENGINEERING
Web based Health Consulting and Disease Diagnosing
Assistance System
Team Members: -
Abebe Gietaneh
Abraham Dereje
Asefa Tasew
Challelign Tilahun
Advisors:
Ins. Endrais Haile
Date Feb. 27, 2017

Web based Health Consulting and Disease Diagnosing 2016
Assistance System
Addis Ababa Institute of Technology

Information Technology and Scientific Computing
Web based Health Consulting and Disease Diagnosing
Assistance System
This Project documentation submitted in partial fulfillment of the requirements for the
Degree of Bachelor of Science in Software Engineering.
Project Advised by:
Ins. Endrais Haile
Name and signature of Members of the examining board:
Name Title Signature Date
1. __________________ Advisor _____________ ______________
2. __________________ Chairperson _____________ ______________
3. __________________ Examiner _____________ ______________
4. __________________ Examiner _____________ ______________
5. __________________ Examiner _____________ ______________
February 2017
ii
Assistance System
Declaration of Originality
We declare that this project is our original work and has not been presented for a degree
in any other university.
Name Signature Date
1. Abebe Gietaneh __________________ __________________
2. Abraham Dereje __________________ __________________
3. Asefa Tasew __________________ __________________
4. Challelign Tilahun __________________ __________________
This project documentation has been submitted for examination with my approval as
university advisor:
Advisor Name: Ins. Endrais Haile Signature: _________________________
February 2017
iii
Assistance System
Acknowledgement
First of all, the team would like to give our gratitude to AAIT. Then, the team wants to
acknowledge center of Information Technology and Scientific Computing (ITSC). The
team would also like to thank the Final Project Committee for giving us the opportunity
to do our final project. This project won’t be possible without the contribution of few
individuals. Finally, the team gratefully acknowledge our respected advisor Mr.Endrias
Haile, Lecturer at Addis Ababa Institute of Technology, Department of Information
Technology and Scientific Computing, for his generous help and suggestion in this
project proposal.
iv
Assistance System
Abstract
Among all the things, Health is the one which needs special care. The system, a Web
based Health Consulting and Disease Diagnosis Assistance System, takes the power of
internet to give a chance for the people to consult and know about their health and other
health related issues anytime anywhere. On our day to day activities, we, as human
beings come up with different questions related to our health. When we feel or see
something strange in our body or somebody else’s body (kids, friends, or other family
members), we want to know what is happening.
But unfortunately we do not go to experts or physicians to get answers for our questions
(consult) as soon as these questions come up to our mind or to know what is happening
to our body by the time we feel strange and by the time we see these signs in our body.
Because to consult a physician, one should go to a clinic, hospital or health care providing
center in person and more worst may need to get an appointment first. And people do
not have a passion to do this for every little strange feelings or questions they have. But,
most of the time this little symptom becomes a serious cause for diseases and being
unhealthy. Even if everyone wants to be healthy, they are not brave enough to go to
health centers or consult physicians by the time they should be. Most of the time people
go to clinics or hospitals after they severely got damaged. Of course, there are many
reasons that discourage people to go and consult a physician, like the availability of a
nearby health center, time, money and many other reasons.
But, these factors don’t affect us anymore. No more need to go to health institutions to
get healthy. We can do it from home with Web based Health Consulting and Disease
Diagnosis Assistance System. The system gives people the opportunity to contact the top
physicians to consult anywhere from home, to talk to the right physicians, doctors that
are specialized in the required medical field and more generally, the system helps people
to act in favor of their health.
There are around 10,000 diseases plus symptoms for each disease. Physicians, as human
beings, are limited to remember all these diseases and symptoms in a specified time.
Physicians don’t have to remember all the diseases and their symptoms. What they have
to do is, just use the Disease Diagnosis Assistance feature of the system.
In conclusion, this project, by closely examining the current problems, will shed new light
on rarely acknowledged health related issue of the people.
v
Assistance System
Table of Contents
Declaration of Originality ...........................................................................................................iii
Acknowledgement .......................................................................................................................iv
Abstract...........................................................................................................................................v
Table of Contents .........................................................................................................................vi
List of Tables ..................................................................................................................................x
List of figures ............................................................................................................................... xii
Definitions, Acronyms, Abbreviations ................................................................................... xiv
Chapter 1: Introduction ............................................................................................................... 1
1.1 Background ......................................................................................................................... 1
1.2 The Existing System ........................................................................................................... 1
1.3 Statement of the Problem .................................................................................................. 2
1.4 Objective of the Project ...................................................................................................... 2
1.4.1 General Objective......................................................................................................... 2
1.4.2 Specific Objective ......................................................................................................... 2
1.5 Proposed System ................................................................................................................ 3
1.6 Feasibility Study ................................................................................................................. 5
1.6.1. Economic Feasibility................................................................................................... 5
1.6.2. Technical Feasibility ................................................................................................... 5
1.6.3. Schedule Feasibility .................................................................................................... 6
1.7 Scope .................................................................................................................................... 6
1.8 Methodology ....................................................................................................................... 6
1.8.1. Requirements............................................................................................................... 6
1.8.2. Design ........................................................................................................................... 7
1.8.3. Implementation ........................................................................................................... 7
1.8.4. Testing .......................................................................................................................... 7
1.9 Project Management plan.................................................................................................. 7
1.9.1. Time Management plan ............................................................................................. 7
1.9.2. Quality Management Plan......................................................................................... 8
1.9.3. Communication Management Plan ......................................................................... 9
vi
Assistance System
Chapter 2: Requirement Analysis ............................................................................................ 10

2.1. Introduction ..................................................................................................................... 10
2.2. Scope ................................................................................................................................. 10
2.3. Overview .......................................................................................................................... 10
2.4. General Description ........................................................................................................ 11
2.4.1. Product Perspective .................................................................................................. 11
2.4.2. Product Functions ..................................................................................................... 11
2.4.3. User Characteristics .................................................................................................. 12
2.4.4. General Constraints .................................................................................................. 13
2.4.5. Assumptions and Dependencies ............................................................................ 13
2.5. External Interface Requirements ................................................................................... 13
2.5.1. User Interfaces ........................................................................................................... 13
2.5.2. Hardware Interfaces ................................................................................................. 15
2.5.3. Software Interfaces ................................................................................................... 15
2.5.4. Communications Interfaces..................................................................................... 16
2.6. Functional Requirements ............................................................................................... 16
2.6.1. FR: 01 – Text Messaging........................................................................................... 16
2.6.2. FR: 02 – Audio Messaging ....................................................................................... 17
2.6.3. FR: 03 – Recent Chats ............................................................................................... 18
2.6.4. FR: 04 – Chat History ............................................................................................... 18
2.6.5. FR: 05 – Rating and feedback on consultation ...................................................... 19
2.6.6. FR: 06 – Presenting nearby experts ........................................................................ 19
2.6.7. FR: 07 – Posting Articles .......................................................................................... 20
2.6.8. FR: 08 – Commenting Articles ................................................................................ 21
2.6.9. FR: 09 – Accepting Symptom inputs ...................................................................... 21
2.6.10. FR: 10 – Predicting Disease ................................................................................... 22
2.6.11. FR: 11 – Adding new Disease and Symptoms .................................................... 22
2.6.12. FR: 12 – Updating Disease ..................................................................................... 23
2.6.13. FR: 13 – Searching for Experts .............................................................................. 24
2.6.14. FR: 14 – Searching for Disease .............................................................................. 24
vii
Assistance System
2.7. Use Cases .......................................................................................................................... 25

2.7.1. Actors.......................................................................................................................... 25
2.7.2. Use Cases ................................................................................................................... 25
2.7.3. Use Case Diagram .................................................................................................... 27
2.7.4. Use Case Description ............................................................................................... 28
2.8. Non-Functional Requirements ...................................................................................... 34
2.8.1. Performance ............................................................................................................... 34
2.8.2. Reliability ................................................................................................................... 35
2.8.3. Availability ................................................................................................................ 35
2.8.4. Security ....................................................................................................................... 35
2.8.5. Maintainability .......................................................................................................... 35
2.8.6. Portability .................................................................................................................. 36
2.9. Inverse Requirements ..................................................................................................... 36
2.10. Design Constraints ........................................................................................................ 36
2.11. Logical Database Requirement .................................................................................... 36
2.11.1. File Format ............................................................................................................... 36
2.11.2. Accessibility and Security...................................................................................... 39
2.12. Other Requirements ...................................................................................................... 39
2.12.1. Training-related Requirements ............................................................................. 39
2.12.2. Packaging Requirements ....................................................................................... 39
2.12.3. Legal Requirements ................................................................................................ 39
2.13. Change Management Process ...................................................................................... 40
Chapter 3: System Design ......................................................................................................... 41
3.1. Purpose ............................................................................................................................. 41
3.2. General Overview ........................................................................................................... 41
3.3. Development Methods and Contingencies ................................................................. 42
3.4. System Architecture ........................................................................................................ 43
3.4.1. Subsystem Decomposition ...................................................................................... 43
3.4.2. Hardware/Software Mapping................................................................................ 45
3.5. Object Model .................................................................................................................... 46
viii
Assistance System
3.5.1. Class Diagram ........................................................................................................... 46

3.5.2. Sequence Diagram .................................................................................................... 47
3.6. Detailed Design ............................................................................................................... 56
3.7. User Interface Design...................................................................................................... 69
BIBLIOGRAPHY ........................................................................................................................ 74
APPENDIX ................................................................................................................................... 75
A.1 Risk Categories ................................................................................................................ 75
A.2 Flow Charts ...................................................................................................................... 76
User Registration ................................................................................................................ 76
Edit profile ........................................................................................................................... 77
Post Article........................................................................................................................... 78
Insert Symptoms ................................................................................................................. 79
Providing Feedback ............................................................................................................ 80
ix
Assistance System
List of Tables
Table 1: Definitions, Acronyms, Abbreviations.................................................................... xiv
Table 2: Time Table ...................................................................................................................... 8
Table 3: Internal Communication Management Plan ............................................................. 9
Table 4: FR: 01-Text Messaging ................................................................................................ 17
Table 5: FR: 02-Audio Messaging ............................................................................................ 17
Table 6: FR: 03-Recent Chats .................................................................................................... 18
Table 7: FR: 04-Chat History..................................................................................................... 19
Table 8: FR: 05-Rating and feedback on consultation ........................................................... 19
Table 9: FR: 06-Presenting nearby experts.............................................................................. 20
Table 10: FR: 07 – Posting Articles ........................................................................................... 20
Table 11: FR: 08-Commenting Articles ................................................................................... 21
Table 12: FR: 09-Accepting Symptom inputs ......................................................................... 22
Table 13: FR: 10-Predicting Disease ......................................................................................... 22
Table 14: FR: 11-Adding new Disease and Symptoms ......................................................... 23
Table 15: FR: 12-Updating Disease .......................................................................................... 24
Table 16: FR: 13-Searching for experts .................................................................................... 24
Table 17: FR: 14-Searching for Disease.................................................................................... 25
Table 18: Logical Database........................................................................................................ 38
Table 20: User class .................................................................................................................... 56
Table 21: Attributes description for User class ...................................................................... 56
Table 22: Operation description for User class ...................................................................... 57
Table 23: PersonalInfo class ...................................................................................................... 57
Table 24: Attributes description for PersonalInfo class ........................................................ 57
Table 25: Address class.............................................................................................................. 58
Table 26: Attributes description for Address class ............................................................... 58
Table 27: Physician class ........................................................................................................... 58
Table 28: Attributes description for Physician class ............................................................. 59
Table 29: Operation description for Physician class ............................................................. 59
Table 30: Patient class ................................................................................................................ 59
Table 31: Attributes description for Patient class .................................................................. 60
Table 32: Operation description for Patient class .................................................................. 60
Table 33: Organization class ..................................................................................................... 60
Table 34: Attributes description for Organization class ....................................................... 61
Table 35: Operation description for Organization class ....................................................... 61
Table 36: Admin class ................................................................................................................ 61
Table 37: Attributes description for Admin class .................................................................. 61
Table 38: Operation description for Admin class .................................................................. 61
x
Assistance System
Table 39: Payment class ............................................................................................................. 62

Table 40: Attributes description for Payment class ............................................................... 62
Table 41: Operation description for Payment class ............................................................... 62
Table 42: Chat class .................................................................................................................... 63
Table 43: Attributes description for Chat class ...................................................................... 63
Table 44: Operation description for Chat class ...................................................................... 63
Table 45: TextMessage class ..................................................................................................... 63
Table 46: Attributes description for TextMessage class ....................................................... 64
Table 47: Operation description for TextMessage class ....................................................... 64
Table 48: AudioMessage class .................................................................................................. 64
Table 49: Attributes description for AudioMessage class .................................................... 64
Table 50: Operation description for AudioMessage class .................................................... 64
Table 51: Articles class ............................................................................................................... 65
Table 52: Attributes description for Articles class ................................................................. 65
Table 53: Operation description for Articles class ................................................................. 65
Table 54: Feedback class ............................................................................................................ 66
Table 55: Attributes description for Feedback class .............................................................. 66
Table 56: Operation description for Feedback class .............................................................. 66
Table 57: Comments class ......................................................................................................... 66
Table 58: Attributes description for Comments class ........................................................... 67
Table 59: Operation description for Comments class ........................................................... 67
Table 60: Ratings class ............................................................................................................... 67
Table 61: Attributes description for Ratings class ................................................................. 67
Table 62: Operation description for Ratings class ................................................................. 68
xi
Assistance System
List of figures
Figure 1: System Architecture .................................................................................................... 4
Figure 2: Gantt chart of Schedule .............................................................................................. 8
Figure 3: Home Page ................................................................................................................ 14
Figure 4: Chatting Page ............................................................................................................ 15
Figure 5: Use case Diagram ..................................................................................................... 27
Figure 6: Entity Relation Diagram .......................................................................................... 38
Figure 7: The High Level Architectural Design of Web based Health Consulting and
Diseases Diagnosing Assistance System ................................................................................ 42
Figure 8: The UML Component Diagram for Diseases Diagnosing Subsystem ............... 43
Figure 9: The UML Component Diagram of Web based Health Consulting and Diseases
Diagnosing Assistance System ................................................................................................. 44
Figure 10: The UML Deployment Diagram of Web based Health Consulting and
Diseases Diagnosing Assistance System ................................................................................ 45
Figure 11: The UML Class Diagram of Web based Health Consulting and Diseases
Diagnosing Assistance System ................................................................................................. 46
Figure 12: User Registration Sequence diagram .................................................................... 47
Figure 13: User Authentication Sequence diagram............................................................... 48
Figure 14: Providing Feedback Sequence diagram ............................................................... 49
Figure 15: Search Experts Sequence diagram ........................................................................ 50
Figure 16: Using Consultation Service Sequence diagram .................................................. 50
Figure 17: Providing Consultation Service Sequence diagram ........................................... 51
Figure 18: Insert Symptoms Sequence diagram .................................................................... 51
Figure 19: Diagnosing Diseases Sequence diagram .............................................................. 52
Figure 20: Add Diseases Sequence diagram .......................................................................... 53
Figure 21: Article Posting Sequence diagram ........................................................................ 54
Figure 22: Article Reading Sequence diagram ....................................................................... 54
Figure 23: Verifying Documents Sequence diagram ............................................................ 55
Figure 24: Home Page Interface ............................................................................................... 69
Figure 25: Registration Page interface .................................................................................... 70
Figure 26: Login Interface ......................................................................................................... 70
Figure 27: Feedback Giving Page............................................................................................. 71
Figure 28: Consulting Service Page ......................................................................................... 72
Figure 29: User Consulting the Doctor ................................................................................... 73
Figure 30: Doctor giving the consulting service .................................................................... 73
Figure 31: Flow Diagram - User Registration ....................................................................... 76
Figure 32: Flow Diagram – Edit Profile ................................................................................. 77
Figure 33: Flow Diagram – Article Posting ........................................................................... 78
xii
Assistance System
Figure 34: Flow Diagram – Insert Symptoms ....................................................................... 79

Figure 35: Flow Diagram – Providing Feedback .................................................................. 80
xiii
Assistance System
Definitions, Acronyms, Abbreviations

Terms Definition
SDS (Software Design Specification) A design specification of a software system to be
developed
Healthcare Provider Institutions or individuals providing healthcare
services.
WAN (Wide Area Network) A computer network that covers a large
geographical area.
UI (User Interface) The part of a software application that a user sees
and interacts with
AngularJS A complete JavaScript-based open-source front-
end web application development framework.
Bootstrap A free and open-source front-end web framework
for designing websites and web applications.
JQuery A cross-platform JavaScript library designed to
simplify the client-side scripting of HTML.
Spring Framework An application framework and inversion of
control container for the Java platform.
Hibernate Framework An object-relational mapping framework for the
Java language
Tomcat Server A servlet and JSP server
Ubuntu Server Operating System A Debian-based Linux operating system for
personal computers, tablets and smartphones.
MySQL DBMS An open-source relational database management
system (RDBMS).
JDK (Java Development Kit) A software development environment used for
developing Java applications and applets.
Table 1: Definitions, Acronyms, Abbreviations
xiv
Assistance System
Chapter 1: Introduction
1.1 Background
Ethiopia has a poor health status in relation to other low-income countries, even within
Sub-Saharan Africa. Infectious and communicable diseases account for about 60-80% of
the health problems in the country. Poor access to health services have contributed to the
high burden of ill-health in the country [6].
The major health problems of the country remain largely preventable communicable
diseases. Despite major progresses made to improve the health status of the population
in the last one and half decades, Ethiopians still face a high rate of morbidity and
mortality and the health status remains relatively poor [1].
The project, Web based Health Consulting and Disease Diagnosis Assistance System,
aims at building a powerful health consulting and diagnosis system with a goal of making
life easier by giving a chance to everyone to know about his/her health and take care of
it. It enables people to consult the right physicians plus empower physicians with disease
analysis prediction.
1.2 The Existing System

Currently, in Ethiopia, one has to go to clinics or hospitals or other health centers in
person to get health services. If he/she needs to consult a physician about something
regarding with his/her health, he/she must go to a clinic or other health centers. Most of
the time, he/she may need to get an appointment first or wait for some large queue to
finish. Most Activities are taking place manually in a traditional way.
There are some institutions that try to tackle this issue by providing services like
answering questions related to health. But, most of these systems are centralized. Only
one expert is going to consult or answer the questions. It is like a call center but with one
expert. Somebody call for a help (may be need consultation or need to ask a question),
the expert assigned there pick up the phone, ask what to help, the customer tell his/her
problems, the expert tries to address his problems or questions. No other
customer/patient is going to be handled until the expert is done with the first
patient/customer. One expert cannot be specialized in every area of medicine. But, in
these systems questions about heart and questions about teeth or about eye will be
addressed/answered by the same expert. This makes the customers to be discouraged
to call. The one who must consult about heart must be heart specialist. And the one who
must consult about teeth must be a tooth doctor.
Currently, nobody is going to health centers to ask what will do to his/her health if
he/she eats or drinks something or if he/she takes some processed foods like protein
1
Assistance System
shakes. But, this is the basic thing that everyone has to know to be healthy. Most of us
don’t go to health centers for any little strange feelings. Instead, we mostly hope that we
will be fine.
1.3 Statement of the Problem

The first problem in our country is the accessibility of health centers and health services.
There are no enough and nearby health centers so that the villagers can go and check
their health at any time they want. This increases the chance of danger. The distance of
the health center discourages people to go.
The second problem is, the people are not passionate to go to health centers by the time
they should be. In our society, going to clinics or hospitals for silly things is considered
as time wastage. This attitude and culture of the people leads to other problems, like the
spread of disease will increase, the chance of contamination will increase, and the chance
to be fine/cured will decrease.
The third problem is the time to wait to get a service, like appointments or long queues.
Appointments are big problems. Somebody doesn’t have to wait for a week or a month
to consult about his/her skin. It has to be done by the time he/she wants (in a short period
of time).
The fourth problem is, the limitation of physicians to remember all the diseases and their
symptoms to analyze and make decisions.
The fifth problem is that there are no enough systems that assist physicians in the process
of decision making.
1.4 Objective of the Project

1.4.1 General Objective
The general objective of the project is to develop a Web based Health Consulting and
Disease Diagnosis Assistance System.
1.4.2 Specific Objective
In order to achieve the aforementioned general objective, the project has also the
following specific objectives:
 Identify the problems of the current system on the health sector
 Propose a new system that enables to solve the problems identified
 Identify the requirements for the new system to be developed
 Analyze and structure the requirements of the new system
 Design the new system
2
Assistance System
 Develop the new system (a Web based Health Consulting and Disease Diagnosis
Assistance System) to enable people to consult physicians and to assist physicians
in analyzing symptoms and making decisions
1.5 Proposed System

This system, Web based Health Consulting and Disease Diagnosis Assistance System, is
a big system with multiple powerful features that enable people to act in favor of their
health and to be more aware of other health related issues plus used as an assistance for
physicians in analyzing diseases and drawing conclusions.
The Main features and sub systems of the system includes;
- Blogging Sub system, the system can be used as a means of addressing issues
or knowledge to the public by posting useful articles
- Consultancy Service Sub system, used as a means of communication between
users and physicians
- Disease Diagnosis Assistance Sub system, used as an assistance for physicians
in analysis of diseases and draw conclusions
This system can be considered as a playing field in which two groups can play in it, the
physician group and the public or customer group. It creates the opportunity for the
public and the physician to play on this field. The system is used as a means of
communication between customers and experts. Communication is possible via text or
audio messaging. Customers use this means to contact experts and get consultancy
services.
Physicians can be benefited from the Disease Diagnosis Assistance Sub system in the
process of analyzing disease and drawing conclusions. The system asks physicians
multiple kinds of questions. Based on the knowledge stored in the system, it analyzes
the answers or the data provided by the physician and draw a conclusion with a brief
description.
The system is used as a source of knowledge or a means of addressing issues to the public.
Experts can post useful articles to the system so that the public can read these articles and
gain knowledge. There is also a situation that physicians want to address some urgent or
non-urgent issues to the people. In this case, this system will play a significant role.
Physicians post articles regarding any issues so that the whole people can be aware of.
In this system, interested doctors/physicians abroad will have an account to log into this
system. Then, the physician can post general health related things that will be useful to
the public in the front page. But, this is optional (i.e. the physician is not forced to post).
The following figure shows high level system architecture and how it functions.
3
Assistance System
EXPERTS THE SYSTEM

CUSTOMERS
As a source of knowledge Gain knowledge by
Post useful articles to the
and a means of addressing reading articles posted by
public to give them
the whole public about an physicians
knowledge or to address an
issue issue
A means of communication
via text or audio messaging Ask for consultation
Consult customers who want services
consultation
Get consultation
Ask Questions
Answer Questions
Disease Diagnosis
Assistance (stored
knowledge)
Make a decision about the Analyze the data and

patient with the help of the draw conclusion with
information provided brief description and
display it for the
physician
Figure 1: System Architecture

Registration and Accounts:
Both the physicians and customers will be registered into the system and get accounts to provide
and get services. Only registered users will get services from the system. But, useful articles
posted by experts will be accessible to the whole public (registered and unregistered).
Searching for Experts:

Customers can search for an expert based on location and specialty.
a. Location based search:
4
Assistance System
When customers use location based search, to search physicians, they enter a
place/location, then the system filters out available experts within that
area/location. In first place, the system presents experts to the customer by
filtering out based on the customer’s place/location so that the customer can view
nearby experts.
b. Specialty based search:
When a customer wants to get an expert in a specific area, the customer can use
this type of search. The customer chooses specialization areas (heart, nerve, skin,
eye, mind, etc….) as a search parameter, then the system filters out experts and
present the customer available experts in that area.
Payment Issues:
Customers will pay when they are registering to get services from experts like
consultancy. Experts will be paid based on the services they provide to the customer.
Payment methods may include hello cash, m-birr, and banks or from the users mobile.
The team don’t make a clear decision on this. One thing to be sure is, the team will provide
a means of payment.
1.6 Feasibility Study

1.6.1. Economic Feasibility
1.6.1.1. Developmental cost
While developing this project the team is going to use a free software and use our own
and lab computers. And the team is going to develop this system by ourselves along with
the help of our advisors. So, there is no need for additional man power. But, the project
costs a lot of time. It will cost a time of around seven months. There are also costs to be
remembered like costs of transportation when gathering requirements, internet costs and
etc…
1.6.1.2. Operational Cost
For this system to be up and running, it needs a server to be hosted and a domain name.
So, it needs a cost of a server or a cost to rent a server for hosting. The operational cost is
two kind. One, if the system is going to be hosted on its own server, it costs the cost of
the server. Two, if the system is going to be hosted on a rented server, its cost will be the
rent of the server. So, the system is operationally feasible in this country.
1.6.2. Technical Feasibility
Most of the people that are expected/intended to use this system has a good
understanding on how to use computers and browse websites. And the
doctors/physicians are also skilled on using the computer and browsing sites. There will
5
Assistance System
not be any problem on using the system. So, this system is technically feasible in this
country.
1.6.3. Schedule Feasibility
The development process of this project is dynamic, but the project will be completed by
the time frame allocated in the project management plan in section [1.9.1]. The project is
feasible according to the time frame shown in the Time management plan provided in
section [1.9.1].
1.7 Scope
The system is going to be developed for the public plus for the physicians. Any interested
user, registered or unregistered user, can use this system. It is only applicable if there is
internet. The final product of this system;
 Enables people to talk with experts of their choice via text and audio message to
get consultancy
 Enables people to get access to read useful health related articles from physicians
 Enables people to get advice from experts on what to do on some situations, like
during emergency
 Enables people to find nearby experts
 Enables early prevention of diseases
 Enables doctors to follow up their patients
 Enables early detection of spreadable diseases
 Empower physicians in analysis and decision making process
1.8 Methodology
The methodology that is going to be used to develop the proposed system is Modified
Water Fall method. Because, the Modified Water Fall provides and orderly sequence of
development steps with some flexible iterative stages to facilitate the adequacy of
documentation and design reviews to ensure the quality, reliability, and maintainability
of the developed system. This enables to back loop in the development life cycle of the
system so that it allows the phases to overlap when it is necessary. Since it allows the
overlapping of phases, the MWF methodology is the preferred method of choice for this
system.
1.8.1. Requirements
Requirements will be gathered from different people and will be analyzed until the team
gets a clear picture of the problem. Doctors/physicians and other people will be
asked/interviewed to gather these requirements as much as possible.
6
Assistance System
In the coming 4 weeks the team is going to have a clearly defined functional and non-
functional requirements by following this methodology. And these requirements will be
documented into a Software Requirement Specification, SRS.
1.8.2. Design
After finishing the SRS, the constraints of the system will be defined. The constraints will
be easy to use. In this section, the system’s overall design will be defined using different
sequence diagrams and class diagrams. There are different powerful tools used to design
diagrams/UML diagrams out there. One of these tools will be used to design this project.
These constraints and designs (diagrams) will be documented into a document called
SDS, Software Design Specification.
1.8.3. Implementation
Different popular tools and technologies will be used to implement the system. The
system will be implemented using Java Technology.
1.8.4. Testing
Unit Testing, Integration Testing and System Testing will be conducted throughout the
development process of the system. Unit testing has to be performed to isolate each part
of the program and show that individuals are correct in terms of requirements and
functionality. Integration testing has to be performed to determine if the combined parts
of the application function correctly. System testing is needed to test that once all the
components are integrated, the system as a whole meets the specified quality standards
and requirements.
The functionality of the system will be tested locally (in local host). But, if the system
needs to be tested in a real world it needs a server to be hosted to operate. This project
can be said successful, if it is accomplished by the right time. But, the real success of the
system will be measured by its service to the public when it becomes operational.
Everything will be tested before it starts functioning and start to provide service to the
public.
1.9 Project Management plan

1.9.1. Time Management plan
The project will be carried on according to time plan provided in the table and Gantt chart
below.
ID Task Name Start Date Finish Date Duration Completion

1 Title Approval Oct. 27/ 2016 Nov.1/2016 6 days 100%
2 Proposal Nov.1/2016 Nov. 13/2016 1 week, 6 100%
days
7
Assistance System
3 SRS Nov.20/2016 Dec.20/2016 4 weeks 100%

4 SDS Dec.21/2016 Jan.21/2017 4 weeks 100%
5 Implementation Jan.22/2017 May.12/2017 3 months, 20 100%
days
6 Testing May 13/2017 May 23/2017 1 week, 4 100%
days
7 Finalizing May 24/2017 June10/ 2017 2 weeks 100%
remaining
things
Table 2: Time Table
Figure 2: Gantt chart of Schedule
1.9.2. Quality Management Plan
During the various stages of developing this software, different quality measurement
process will be carried out. This includes consultations with advisors to ensure that the
pre-defined standards of the documentation are met. The final testing stage of the project
life cycle is expected to meet to relentlessly measure the usability, reliability, efficiency
and understandability of the system to the highest degree to match the requirements
specified.
All the team members will participate in risk management. There will not be a single risk
manager. Every member of the group is responsible to identify (as scope, schedule,
8
Assistance System
operational or resource risks), quantify (as low, medium, high and critical), response
(avoid, pass on the risk, and take corrective measures to reduce the impact of the risk, or
acknowledge the risk), monitor and control every risks that will arise throughout the
development process of the system. Most importantly, a big effort will be made to
identify risks proactively. Possible risks that might be occur during the development of
the project are pointed out in Appendix-A
The role of our advisor is significant in ensuring the document standards of the project.
The team will continuously advice and discuss with our advisor so that the document
meets standards of documentation.
The team will follow standard conventions of coding to ensure coding standards. The
team members will write the code in a way that other team members can understand.
1.9.3. Communication Management Plan
This team is formed based on the strengths of each individual in a way that would
guarantee the maximum output of the system that will meet the requirements. The team
will have meetings and group discussions. Since we (the group) live together in one
campus and are friends, we can’t spent our day without seeing each other. And we have
the opportunity to talk about the project always. The team will also communicate with
the advisor in a consistence manner to ensure that the project is going on as expected.
Type of Method / Tool Frequency/ Information Participants
Communication Schedule
Project Meetings In person Weekly Project status, problems, Team Members
and on risks, changed
event requirements
Weekly report Via Email Weekly Review of the status of Team members,
the project. Advisor
Team-Advisor In person As needed Discuss what is done, Team members,
meetings what to be done and how Advisor
to do.
Table 3: Internal Communication Management Plan
9
Assistance System
Chapter 2: Requirement Analysis

2.1. Introduction
The purpose of this document is to provide a basis for developing the software design for
the "Web based Health Consulting and Diseases Diagnosing Assistance System" project.
This SRS document will illustrate the complete declaration for the development of the
system. It will give a detailed description of the requirements. It will also explain the
features of the system, the interfaces, product functions, and the system's interactions
with other external applications. This document is intended for both the stakeholders and
the developers of the system and will be proposed to the project advisors for its approval.
2.2. Scope
The Web based Health Consulting and Diseases Diagnosing Assistance System is a health
information technology system that is designed to provide physicians and other health
professionals with clinical decision support, that is, assistance with clinical decision-
making tasks and a way for providing consultancy services.
The proposed system targets people who have basic computer interaction skills and
access to internet. Some of the benefits the system provides are:-
- Enables people get consultancy from physicians via text and audio messaging
- Enables people grab knowledge from articles created by physicians
- Enables physicians make accurate diagnosis by providing possible diseases
suggestions based on patient data.
- Enables users provide feedback on services they use and functionalities of the
system.
2.3. Overview
The rest of this document includes three sections. The second section provides the general
description of the system which describes the general factors that affect the product and
its requirements. The third section presents specific requirements which contains all the
software requirements at a specific level of detail. The fourth section gives information
about change management process which is all about identifying and describing the
process that will be used to update the SRS, as needed, when project scope or
requirements change.
10
Assistance System
2.4. General Description
2.4.1. Product Perspective
professionals with clinical decision support, that is, assistance with clinical decision-
making tasks and a way for providing consultancy services. The systems link health
observations with health knowledge to influence health choices by clinicians for
improved health care.
The system is a first of its type for Ethiopia and a technology that is not highly driven into
worldwide. There are a lot of research works in the area. However, there are only some
novice systems implementing the idea. And most of them are designed for the public,
who usually don’t have the knowledge of how to interpret medical diagnosis results,
which makes them unpopular due to current regulations and high probability of missed
serious diagnoses.
The main purpose of the proposed system is to assist clinicians at the point of care. This
means that clinicians interact with the system to help to analyze, and reach a diagnosis
based on, patient data. This doesn’t mean the clinician would input the information and
wait for the system to output the "right" choice and the clinician would simply act on that
output. However, the usage of the system to assist means that the clinicians interacts with
the system, utilizing both their own knowledge and the system, to make a better analysis
of the patient's data than either human or system could make on their own. Typically, the
system makes suggestions for the clinician to look through, and the clinician is expected
to pick out useful information from the presented results and discount erroneous system
suggestions.
2.4.2. Product Functions

Upon completion the proposed system is expected to provide:
a) A platform that allows physicians use a diseases diagnosing assistance tool that
helps them analyze, and reach a diagnosis based on, patient data.
b) A feature that enables physicians modify the diseases diagnosing assistance tool.
c) A feature that enables physicians give feedback, comment and rating, on
modifications to diseases diagnosing assistance tool.
d) A platform that allows physicians address a large community through writing
articles.
e) A platform that allows people get consultancy services and physicians provide
consultancy services via text or audio messaging.
f) A feature that enables both people and physicians browse through messaging
history.
11
Assistance System
g) A feature that enables people filter nearby or any specific physicians.

h) A feature that enables people give feedback, comment and rating, on services they
use.
2.4.3. User Characteristics
The Web based Health Consulting and Diseases Diagnosing Assistance System has four
different types of users.
2.4.3.1. Ordinary user
Frequency of use: As needed
Subset of product function used: These users use the system to read articles written on
different health related issues by physicians. They may give comments on those articles and request
for account in the system.
Minimum technical expertise: Basic computer interaction skills.
Privilege Level: These users can get detail information on articles.
Minimum Education Level: Elementary Level
2.4.3.2. Registered user
Subset of product function used: These users have all the privileges of ordinary users. In
addition, these users can get consultancy services.
Privilege Level: These users can get detail information on physicians, and can give feedback on
their services too.
Minimum Education Level: Elementary Level
2.4.3.3. Physicians
Subset of product function used: These users are the most influential of all other users. They
can provide consultancy services, write articles, use the diseases diagnosing assistance tool, modify
the diseases diagnosing assistance tool, and review modifications on the diseases diagnosing
assistance tool.
Privilege Level: These user can access profiles of their clients (Registered Users) in addition to
all the things they can do mentioned above.
Minimum Education Level: High Level Education on Medical Fields
2.4.3.4. Administrators
Subset of product function used: These users verifies license document of physicians.
Privilege Level: These user can access profiles of their clients in addition to all the things they
can do mentioned above.
Minimum Education Level: High Level of Education on Medical Fields
12
Assistance System
2.4.4. General Constraints
The major constraints or issues that will limit the options available to develop the
proposed system are:-
a) Regulatory policies:- The usage of computer aided diseases diagnostic tools have some
legal issues
b) Infrastructure: - The system is mainly developed for Ethiopia and internet payment in
Ethiopia is under developed.
c) Reliability Requirement: - The system must be available 24 hours a day 7 days a week
365 days a year.
d) Criticality of the application- The system is important to the people for the availability
of professional counseling service and diseases diagnosing tool.
e) Security- The user and system data will be kept on a server and necessary precautions
ought to be taken by developers for the data not to be compromised.
2.4.5. Assumptions and Dependencies
To run the Web based Health Consulting and Diseases Diagnosing Assistance System an
internet browser application is needed. And it is assumed that the user is familiar with
an internet browser and has access to decent internet connection.
2.5. External Interface Requirements
2.5.1. User Interfaces

The user interface is a key to application usability. The application should include content
presentation, application navigation, and user assistance. In the Web based Health
Consulting and Diseases Diagnosis Assistance System project the following user interface
requirements shall be considered:
 All screens shall be operable via a keyboard or mouse.
 All buttons and text boxes shall be disabled unless intended action is permissible.
 The navigation between pages shall be easily managed.
 If selectable list boxes, text boxes, or pictures contain more information than is
permissible in the allocated panel space, scroll bars shall be activated.
 All operation errors shall be acknowledged with an error message.
 A selected panel shall be displayed as topmost on the windows desktop.
 User interface shall be expressed using English language.
13
Assistance System
Figure 3: Home Page
14
Assistance System
Figure 4: Chatting Page
2.5.2. Hardware Interfaces

Since the Web based Health Consulting and Diseases Diagnosis Assistance System is a
web based application which will run over WAN; all the hardware shall require to
connect to networks, will be hardware interface for the system. The Hardware interfaces
of the system are handled by the Ubuntu Server Operating System. Then, the server is
directly connected to the client systems. Also the client has the access to the database for
accessing the account details and get services.
2.5.3. Software Interfaces

2.5.3.1. Operating System
The software is being designed to run on Ubuntu Server Operating System which
includes the latest version of Tomcat Server, version 9.0.
2.5.3.2. Web Server
The software is being designed to run on Tomcat Server, version 9.0.
2.5.3.3. Database
The software will access the MySQL database for the following features.
– Import/Export Update Requests
15
Assistance System
– Adding new Information

– Updating previous Information
– Viewing the Report
– Sending New/Update Request etc...
2.5.3.4. Libraries
The application’s implementation will incorporate the following libraries:
– Spring implementation libraries,
– Hibernate implementation libraries,
– Most of the libraries in the JDK 8.0,
– Etc.…..
2.5.3.5. Page Layout Tools
Based on our requirements, AngularJS mainly and other JavaScript frameworks such as
JQuery, Bootstrap will be used for the UI implementation.
2.5.4. Communications Interfaces
2.5.4.1. Web Interface
The application will be accessed over the network. All features will be accessible through
the web site.
2.5.4.2. HTTP protocol
The Web based Health Consulting and Diseases Diagnosis Assistance System shall use
the HTTP protocol for communication over the network. More over this allows easy
interaction between the various clients and server.
2.5.4.3. Data Communication

The Hibernate framework will be used to link data layer to the database.
2.6. Functional Requirements
2.6.1. FR: 01 – Text Messaging
ID FR: 01
Name Text Messaging
Introduction The system shall allow users to be able to send

text messages. At the time of consultation, clients
(patients or customers) and experts can use this
means of communication. They can communicate
by sending text messages.
16
Assistance System
Inputs User writes a text into the provided text area for
messaging.
Processing The user requests the system to send the text into
another user. The system accepts the text input
and process the text, then send the text into the
receiver through the network (internet).
Outputs Text messaging service (the text message sent).
Error Handling Can’t send your message, Please enter an
appropriate text.
Table 4: FR: 01-Text Messaging
2.6.2. FR: 02 – Audio Messaging
ID FR: 02
Name Audio Messaging
Introduction Sometimes voice expresses feelings more than
texts. There may be a situation that the user
wants to express what he/she want vocally. In
situations when users want to express their
feelings vocally using voice rather than texts, the
system shall provide the user the ability to send
audio messages. Clients and experts can
communicate using audio messaging through the
audio recorder provided by the system.
Inputs An audio recorded by the recorder provided by
the system.
Processing The user requests the system to record his/her
voice and send it to another user (from client to
expert or from expert to client). The system
accepts recorded audio and process it, then send
the audio to the intended receiver using the
network (internet).
Outputs Audio messaging service (the audio message
sent).
Error Handling Your message is not send, try again.
Table 5: FR: 02-Audio Messaging
17
Assistance System
2.6.3. FR: 03 – Recent Chats
ID FR: 03
Name Recent Chats
Introduction The system shall display chats that are done
recently. When a user browse the chatting
system, he/she will
see the chats that he/she made recently. The
system shall display recent chats in the order of
time they have
been done. The last chat the user has made will
be at the top of his/her recent chats.
Inputs Previous chats that the user has made with other
users.
Processing The system scans the chats that has been made
earlier and order them according to the time and
display the
chats starting from the top most recent chat.
Outputs Recent chats are displayed (chats are displayed in
the order of being recent).
Error Handling There are no possible errors here.
Table 6: FR: 03-Recent Chats
2.6.4. FR: 04 – Chat History
ID FR: 04
Name Chat History
Introduction The system shall display the chat history of a user
with a specific user. When a user clicks on a
specific user from the list of recent chats, the
system shall display previous text and audio
messages with that user.
Inputs Messages sent and received previously.
Processing The system reads sent and received text as well
as audio messages from the database and display
it in order
based on the time they has been sent or received.
18
Assistance System
Outputs Previously sent and received messages are

displayed.
Error Handling Can’t load your messages, check your internet
connection.
Table 7: FR: 04-Chat History
2.6.5. FR: 05 – Rating and feedback on consultation
ID FR: 05
Name Rating and feedback on consultation
Introduction The system shall allow clients to rate and give
feedback for the experts who provide
consultation service for that client. This is the
way that clients express their satisfaction on
consultation service.
Inputs Rating and feedbacks inputs
Processing The user wants to rate the expert who provide
him/her consultation. The user rates and writes
texts as a feedback. The system accepts these
inputs and process them. Then, the system rates
the expert.
Outputs The expert is rated and received feedback.
Error Handling Please enter appropriate texts for feedback.
Table 8: FR: 05-Rating and feedback on consultation
2.6.6. FR: 06 – Presenting nearby experts
ID FR: 06
Name Presenting nearby experts
Introduction When a client seeks consultation, he/she looks
for an expert so that he/she can get consultation
service from
that expert. At that time, the system shall present
possible nearby experts based on client’s location
if
available. But, if there are no registered experts
within the client’s location, the system will
19
Assistance System
present other
experts with no consideration of location.
Inputs The location of the users.

Processing The system looks the location of the client and
search an expert within that location. Then, the
system
displays available experts in that location to that
client.
Outputs Nearby experts displayed.
Table 9: FR: 06-Presenting nearby experts
2.6.7. FR: 07 – Posting Articles
ID FR: 07
Name Posting Articles
Introduction Interested experts (physicians) can post useful
articles into the front page of the system so that
anyone can
grab knowledge or anyone can be addressed
about an issue. The system shall allow this
capability of experts
and provide a means to do this.
Inputs Articles prepared by experts (physicians).
Processing Experts or physicians prepare and provide useful
articles to the system. The system accepts these
articles
and process it. Then, display it on its home page.
Outputs Useful articles displayed on the front page.
Table 10: FR: 07 – Posting Articles
20
Assistance System
2.6.8. FR: 08 – Commenting Articles
ID FR: 08
Name Commenting Articles
Introduction Articles posted by experts for the public will be
commented by any interested user. Users can
express their
feeling about that comment. The system shall
give users the ability to comment on the posted
articles.
Inputs Text input to the provided comment area below
the article.
Processing The system takes text inputs from the comment
area and process and analyze the text. Then,
make that text
a comment for the posted article.
Outputs The article is commented.
Error Handling You cannot comment this article. You have to
register to give comments.
Table 11: FR: 08-Commenting Articles
2.6.9. FR: 09 – Accepting Symptom inputs
ID FR: 09
Name Accepting Symptom inputs
Introduction The system can be used as an assistance tool for
the physicians to diagnose disease. To use this
tool, the
physician enters symptom inputs so that the
system (this tool) predicts the possible disease.
The system
shall accept these symptom inputs.
Inputs Text on provided fields for symptoms.
Processing The user requests the system to accept the text

inputs. The user enters the inputs to the provided
text field/
area. Then, the system accepts these text inputs
and process them as symptoms of disease.
21
Assistance System
Outputs The system accepts the text inputs as disease

symptoms.
Error Handling There is no such kind of symptom registered in
the database.
Table 12: FR: 09-Accepting Symptom inputs
2.6.10. FR: 10 – Predicting Disease
ID FR: 10
Name Predicting Disease
Introduction The main purpose of the disease diagnosis
assistance tool is to help the physician by
predicting a possible
disease based on the symptom inputs entered
from the physician. The system shall accept
symptom inputs
from the physician and be able to predict the
possible diseases based on the symptoms.
Inputs Symptom inputs.
Processing The user requests the system to predict the

disease. The system accepts inputs (symptom
inputs) from the
user (physician) and process the input. Then,
display the possible disease(s) by analyzing the
inputs.
Outputs Possible disease(s) displayed.
Error Handling No such symptom is known by the system.
Table 13: FR: 10-Predicting Disease
2.6.11. FR: 11 – Adding new Disease and Symptoms
ID FR: 11
Name Adding new Disease and Symptoms
Introduction All the diseases and their symptoms may not be
known by the system. The system shall give the
experts
the ability to add unregistered diseases and
22
Assistance System
symptoms to the system to make itself more

powerful and useful.
When one expert tries to add a new disease(s)
and symptom(s), his/her action will be visible
and reviewed
by other registered experts.
Inputs New disease and symptom(s), and reviews of
other experts.
Processing An expert request the system to add new disease
and symptom(s). The system accepts disease and
symptom
input and checks expert reviews of the action.
The system processes inputs and reviews. Then,
the new
disease and symptoms will be added to the
system.
Outputs New disease and symptoms added to the system.
Error Handling The disease is already available. Can’t add it
twice.
Table 14: FR: 11-Adding new Disease and Symptoms
2.6.12. FR: 12 – Updating Disease
ID FR: 12
Name Updating Disease
Introduction The system may not be always reliable.
Sometimes for some diseases and symptoms it
may need revision
and update. The system shall allow experts to
update disease(s) and symptoms as necessary to
make itself
as reliable as possible. The updating process also
require reviews of other experts like adding new
disease(s) and symptoms.
Inputs An update for a disease or a symptom and
reviews of experts on the specified action.
Processing The system accepts update inputs of a disease or
symptom or both and expert reviews for the
action. Then,
the system processes and analyzes the update
23
Assistance System
inputs and reviews and update the required

disease or
symptom.
Outputs A specific disease or symptom updated.
Error Handling No enough reviews, can’t update.
Table 15: FR: 12-Updating Disease
2.6.13. FR: 13 – Searching for Experts
ID FR: 13
Name Searching for Experts
Introduction A client can search an expert based on location or
specialty area. The system shall allow the client
to
search for an expert of what he/she want based
on two criteria ( location and specialty area) to get
consultation service.
Inputs Location or specialty are of medicine like heart
specialist or nerve specialist.
Processing The user enters inputs to the search bar (by
location search bar or by specialty area search
bar). The
system accepts these inputs either location input,
specialty are input or both inputs and process
them.
Then, the system displays the search result to the
client.
Outputs Experts displayed based on location, specialty
area or both as a search result.
Error Handling No expert is found around this location.
Table 16: FR: 13-Searching for experts
2.6.14. FR: 14 – Searching for Disease
ID FR: 14
Name Searching for Disease
24
Assistance System
Introduction Experts don’t know whether a specific disease is

already registered in the system or not, unless
they search
for it. So, the system shall allow experts to search
for the disease by its name to know whether it is
already
in the system or not. This helps to add it into the
system it is not yet registered.
Inputs Name of the disease
Processing An expert enters the name of the disease and

press the search button to search for that specific
disease. The
system accepts the input from the search bar and
process the input. Then, the system display a
search result
with information containing the disease or
information that shows that the disease is not
already in the
system.
Outputs Search result that shows whether the required
disease is in the system or not.
Table 17: FR: 14-Searching for Disease
2.7. Use Cases
2.7.1. Actors
The following are the known actors, parties outside the system that interact with the
system, of the proposed system:-
– Healthcare Provider: - institutions or individuals providing healthcare services.

– User: - teenagers, young-adults, or adults who actively participate in the system.
– Administrator: - employees who are specifically employed to for the system.
2.7.2. Use Cases

Use cases defines a goal-oriented set of interactions between external actors and the
system. The following are the identified use cases of the proposed system:-
1. Registration
2. Authentication
25
Assistance System
3. Providing Feedback
4. Searching for Experts
5. Using Consultation Service
6. Subscribing Service
7. Providing Consultation Service
8. Insert Symptoms
9. Diagnosing Diseases
10. Update and Add Diseases
11. Review Modifications
12. Article Posting
13. Article Reading
14. Verifying Documents
26
Assistance System
2.7.3. Use Case Diagram
Figure 5: Use case Diagram
27
Assistance System
2.7.4. Use Case Description

2.7.4.1. Use Case 01: Registration
Use Case Name: Registration
Primary Actor: User, Healthcare Provider, Administrator
Description: Enables the actor to create an account in the system.
Pre-conditions: User actors need to have a bank account from partner banks and Healthcare
provider need to have scan copies of documents that verify their licenses.
Post-conditions: The actor have an account in the system.
Failures: The system fails to create the account.
Triggers: The actor wants to be involved in the system.
Main Success Scenario
1. The actor wants to be involved in the system.
2. The actor clicks the sign up button.
3. The system displays the registration form.
4. The actor enters the required information and clicks the submit button.
5. The system checks the provided information is correct and the specified username is not
used.
6. The system adds the actor into the database and displays a confirmation message.
Extensions
5.a The system find the given information is incorrect or username is used.
5.a.1 The system displays a warning message with the proper description about the
cause.
Variations
3.a The actor choose type of registration i.e. user or health provider registration.
2.7.4.2. Use Case 02: Authentication
Use Case Name: Authentication
Description: Enables the actor verify itself to the system.
Pre-conditions: The actor must be registered.
Post-conditions: The actor is authenticated.
Failures: The system fails to authenticate the user.
Triggers: The actor wants to login or authenticated.
1. The actor wants to login or authenticated.
2. The actor clicks the authentication button.
3. The system displays the credentials form.
5. The system checks the provided information is correct.
6. The system displays a confirmation message.
28
Assistance System
Extensions
5.a The system find the given information is incorrect.
cause.
2.7.4.3. Use Case 03: Providing Feedback
Use Case Name: Providing Feedback
Description: Enables the actor give a rating or comment on a given event.
Pre-conditions: The actor is registered and authenticated.
Post-conditions: The actor gives feedback on a given event.
Failures: The system fails to allow the actor give feedback.
Triggers: The actor wants to give a feedback on an event.
1. The actor wants to give feedback on an event.
2. The actor clicks the feedback button.
3. The system displays the feedback form.
6. The system displays a confirmation message.
Extensions
5.a The system find the given information is incorrect.
cause.
Variations
3.a The actor choose type of feedback i.e. rating or comment.
2.7.4.4. Use Case 04: Searching for Expert
Use Case Name: Searching for Expert
Primary Actor: User
Description: Enables the actor find the expert he/she needs.
Post-conditions: The actor gets a result for his search query.
Failures: The system fails to get a result.
Triggers: The actor wants to search for a specific or group of experts.
1. The actor wants to search for a specific or group of experts.
2. The actor navigates to the search box.
3. The actor enters his/her query string and clicks the search button.
5. The system displays a result.
29
Assistance System
2.7.4.5. Use Case 05: Using Consultation Service

Use Case Name: Using Consultation Service
Primary Actor: User
Description: Enables the actor use a consultation service.
Post-conditions: The actor uses the consultation services.
Failures: The system fails to allow the user to use the consultation service.
Triggers: The actor wants to use a consultation service.
1. The actor wants to use a consultation service.
2. The actor clicks the start consultation button.
3. The system displays the available healthcare providers.
4. The actor selects a healthcare provider and get consultation via messaging.
Extensions
3.a The system finds no available healthcare providers.
3.a.1 The system provides a way for the actor to leave message for the healthcare
provider.
2.7.4.6. Use Case 06: Subscribing Service
Use case name: Subscribing Service
Primary Actors: Healthcare provider
Description: Enables the actor provide consultation service and/or use the diseases diagnosing
assistance tool.
Preconditions: The actor is registered, authenticated and have a bank account from partner
banks.
Post-conditions: The actor provides consultation services and/or use the diseases diagnosing
assistance tool.
Failure: The system fails to allow the subscription to the actor.
Trigger: The actor wants to provide consultation service or use the diseases diagnosing
assistance tool.
1. The actor wants to provide consultation service or use the diseases diagnosing assistance
tool.
2. The actor clicks the subscribe button.
3. The system displays the account registration form.
6. The system updates the actor’s information in the database and displays a confirmation
message.
Extension:
30
Assistance System
3.a. The system finds the actor have registered bank account
3.a.1 The system updates the actor’s information in the database and displays a
confirmation message.
5.a The system finds the given information is incorrect.
cause.
Variations
3.a The actor choose type of subscription i.e. tool or service.
2.7.4.7. Use Case 07: Providing Consultation Service
Use Case Name: Providing Consultation Service
Primary Actor: Healthcare Provider
Description: Enables the actor to give consultation service
Pre-conditions: The actor is registered, authenticated, and have subscribe the service.
Post-conditions: The actor gives consultation service.
Failures: The system fails to allow the actor provide consultation service.
Triggers: The actor wants to provide consultation service.
1. The actor wants to provide consultation service.
2. The actor clicks the consult button.
3. The system displays the available customers.
4. The actor selects a customer and start consulting via messaging.
Extensions
3.a The system finds no available customers.
3.a.1 The system displays an information message that explains the
situation
2.7.4.8. Use Case 08: Insert Symptoms
Use case name: Insert Symptoms
Description: Enables the actor enter symptoms of a diseases to the system.
Preconditions: The actor is registered, authenticated and have subscribe the diseases
diagnosing tool.
Post-conditions: The actor inserts symptoms of a diseases.
Failure: The system fails to allow the actor insert symptoms.
Trigger: The actor wants to insert symptom of a diseases.
1. The actor wants to insert symptom of a diseases.
2. The actor clicks the insert symptom button.
3. The system displays the diseases symptom registration form.
31
Assistance System

6. The system process the input and provide result based on the intended purpose.
Extension:
5.a The system finds the given information is incorrect.
cause.
Variations
3.a The actor choose purpose of the action i.e. adding new diseases, update existing diseases
or diagnosing a diseases.
3.a.1 The system displays different forms based on the actors intent.
2.7.4.9. Use Case 09: Diagnosing Diseases
Use case name: Diagnosing Diseases
Description: Enables the actor diagnose a diseases.
Preconditions: The actor is registered, authenticated, have subscribe the diseases diagnosing
tool and have insert the diseases symptoms.
Post-conditions: The actor diagnoses a diseases.
Failure: The system fails to allow the actor diagnose a diseases.
Trigger: The actor wants to diagnose a diseases.
1. The actor wants to diagnose a diseases.
2. The actor clicks the diagnose button.
3. The system process the input and provide a result.
2.7.4.10. Use Case 10: Update and Add Diseases

Use case name: Update and Add Diseases
Description: Enables the actor to Update and Add Diseases to the database
Preconditions: The actor is registered, authenticated, have subscribe the diseases diagnosing
Post-conditions: The actor update and add disease to the database.
Failure: The system fails to update and add disease to the database.
Trigger: The actor wants to update and add disease.
1. The actor wants to update and add disease.
2. The actor clicks the update or add button.
3. The system display update form or add form.
4. The actor update or add the information
5. The system revise the information
Extension:
5.a The actor enters an ambiguous Input
5.a.1 The system displays a warning message with the proper description about the cause
32
Assistance System
5.b The Requested information exist in the database

5.b.1 The system notifies the information already exist.
2.7.4.11. Use Case 11: Review Modifications

Use Case Name: Review Modifications
Primary Actor: Healthcare Provider
Description: Enables the actor to review modification of update and add diseases
Pre-conditions: The actor is registered, authenticated.
Post-conditions: The actor gives feedback and review for modifications.
Failures: The system fails to review modifications.
Triggers: The actor wants to review modifications.
1. The actor wants to review modifications.
2. The actor clicks review button.
3. The system displays the available review modifications.
4. The system show message dialog, review successfully.
Extensions
3.a The system finds no available review modifications.
3.a.1 The system displays an information message that explains the situation
2.7.4.12. Use Case 12: Article Posting

Use case name: Article Posting
Description: Enables the actor to post an article
Preconditions: The actor is registered, authenticated.
Post-conditions: The actor posts an article.
Failure: The system fails to post an article.
Trigger: The actor wants to post an article.
1. The actor wants to post an article.
2. The actor clicks post article button.
3. The system displays article posting form.
4. The actor enters the required information and clicks the article post button.
5. The system shows message dialog, article post successfully.
Extension:
4.a The actor enters an ambiguous article.
4.a.1 The system displays a warning message with the proper description about the cause.
2.7.4.13. Use Case 13: Article Reading

Use case name: Article Reading
Primary Actors: user and Health provider
Description: Enables the actor to read an article.
Post-conditions: The actor read an article.
Failure: The system fails to read an article.
33
Assistance System
Trigger: The actor wants to read an article.

1. The actor wants to read an article.
2. The actor clicks read article button.
3. The system displays different article.
Extension:
2.a There is no available article.
2.a.1 The system displays message, articles not found.
2.7.4.14. Use Case 14: Verifying Documents

Use case name: Verifying documents
Primary Actors: Administrator
Description: Enables the actor to verify documents
Post-conditions: The actor is verifying documents.
Failure: The system fails to verify documents.
Trigger: The actor wants to verify documents.
1. The actor wants to verify documents.
2. The actor clicks verify document button.
3. The system display all documents to be verified.
4. The actor select each document
5. The actor checks the document
6. The actor click document verified button.
7. The system displays a message, the document is successfully verified.
Extension:
3.a The system does not found documents to verified
3.a.1 The system displays a message with the proper description about the cause.
6.a The document is invalid or forged.
6.a.1 The actor reject the document.
2.8. Non-Functional Requirements
2.8.1. Performance
For our Web based Health Consulting and Diseases Diagnosis Assistance System project,
we will be using a better standard client personal computer, so our system should have
high performance and the response time will be faster when tested from a local computer.
Its response time for searching, inserting, deletion, updating should averagely be around
4 seconds. Selecting an element from the list, opening new windows, clicking links and
dismissing pop-up messages should take less than 1 second. Our system will accurately
execute requests from multiple users simultaneously and give response in 8 second.
34
Assistance System
2.8.2. Reliability
The Web based Health Consulting and Diseases Diagnosis Assistance System will be
developed to perform the expected user needs with higher precision. There are some
issues like registration of diseases with their corresponding symptoms and registration
of user, especially when taking information of doctors which needs to be reliable and this
attribute is very essential.
2.8.3. Availability
The system must operate twenty-four hours a day, seven days a week. The database has
rollback segments, and a centralized backup can be performed to act upon a system
recovery form failure.
2.8.4. Security
The Web based Health Consulting and Diseases Diagnosis Assistance System should be
secured and it should be used by the accurately authorized personnel.
 Every user must have their own privilege, which means they should be identified
by their own secured account and perform their functions.
 To secure our system from security treat we will use layered approach of
application development.
 If a user forgot the password, he/she can change the password by email or by
answering some questions and he can login to his account.
 The system provide about two privileged level
Level 1 – normal users are users which have no account can access the
system such as reading article.
Level 2 – registered users are users who own account.
2.8.5. Maintainability
The system should be flexible enough for changes and be capable of any
modifications that would be applied to it. The business logic must be clearly separate
from the User Interface to allow different user interfaces to be developed in the future.
So, the identified requirements will be maintained during operation. Maintenance of the
Web based Health Consulting and Diseases Diagnosis Assistance System is handled at
the transition stage and as scheduled under project brief document.
To ensure the maintainability of the system we are going to include a short manual to
help the client understand the system well, comments will be addressed to the codes to
assist future readability and understanding of the code and we will are also going
to program the codes in a structured way which will further assist the maintainability.
35
Assistance System
2.8.6. Portability
The system is expected to be compatible with all web browsers and devices of
various specifications. It should be easily portable from one operating system to another,
since the system will be used by different users found in different locations.
2.9. Inverse Requirements
One of the functionalities the proposed system does not include is allowing the
integration of medical devices to receive and provide real time data which is an important
feature that enables the physician better understand client’s conditions during
consultancy programs and better clarify the patient’s condition for the diseases
diagnosing tool.
The other functionality the proposed system doesn’t provide is recommending tablets.
The system seems to work in a way the clinician would input the information and wait
for the system to output the "right" choice and the clinician would simply act on that
output. However, the system makes suggestions for the clinician to look through, and the
clinician is expected to pick out useful information from the presented results and
discount erroneous system suggestions and then make tablet recommendations.
2.10. Design Constraints
Design constraints are limitations that occur because of unavailability of another system
or a certain body not providing resources that are required to complete a specific
section. One possible constraint is online payment, yes this is a valuable asset to any
system that has an intention of simplifying life. Due to the unavailability of online
payment service the proposed system uses some work arounds using banks cooperation
to make online payments.
2.11. Logical Database Requirement
2.11.1. File Format

In the Web based Health Consulting and Diseases Diagnosis Assistance System database
will be used to store disease with their corresponding symptoms, user information,
different message format and article posted to the system. This database will keep data
of mostly text format. The data stored will be accessed at almost every possible interaction
between the user and the system.
The system database need large storage capabilities minimum about 2 GB, since data
volume increase from time to time.
The system will allow a doctors to submit symptoms. Depending on the symptom, the
system suggest the disease for doctor in return. The disease stored in a database will be
accessed if the doctors searches for adding some new disease to the system.
36
Assistance System
In addition the system allow doctors and patient to view their communication history
using stored messages in the database.
Database Table Attribute Description
User User Id This data holds detail
Address ID information of different
First Name users in the system. Using
Last Name it the system identify users
User Name using their email and
Email password when they login
Phone Number and also it gives users
Password different privilege. On the
User Type other hand it uses to know
in what field the doctors
specialize.
Address Address Id This data used to identify
Kebele location of users depending
Woreda on the data the system can
Subcity suggest nearby doctors for
City patients if they wants to
Country communicate with doctors.
Message Message Id Here the database store
User Id messages that the patient
Comment Id and doctor share and the
Rating Id system provide means of
Text message viewing history.
Audio
Image
Symptom Symptom Id This data is used to store
Symptom description different symptoms for
different disease
depending on the
symptom the doctors
provide the system give
back match result for
doctors.
Disease Disease name This data is used to provide
Symptom id search result for diseases
Comment Id registered in the system.
Rating Id
Article Article Id On these section the
User id database store some article
37
Assistance System
Title posted by the doctors and

Description this article is view any user
Comment ID of the system
Rating Id
Comment Comment Id Using this section of
Comment body database the user can
comment for the service
they get from doctors and
doctor can comment if
others doctor wants to
update some disease
Rating Rating Id Rating table store rating
Positive Ratings values and it functions is
Negative Ratings same comment but it is
more invaluable than
comment table.
Table 18: Logical Database
Figure 6: Entity Relation Diagram
38
Assistance System
2.11.2. Accessibility and Security

All users will be able to view data about article. But every user have no privilege to
modify it. And also only doctor which own the privilege can access Disease Diagnosis
Assistant tool and if a doctor wants to modify some disease or add new one, the
modifications has to be reviewed and accepted by some other doctors before it is added
to the database.
2.12. Other Requirements
2.12.1. Training-related Requirements

For Web based Health Consulting and Diseases Diagnosis Assistance System to function
as planned it needs to be used in a proper way by users. So in order to make that happen
there is a link called help which provide a short video and some documentation for
anyone who wants to familiarize himself/herself more with the system.
2.12.2. Packaging Requirements

The system is a web-based application and it contain different file formats, which come
with the web discipline. To specify a few of these, “.jar”, “.war”, ”.JS” and “Read me” text
file which are going to be packaged.
2.12.3. Legal Requirements

Customer shall not copy: in whole or in part, software or documentation; modify the
software; reverse compile of reverse assemble all or any portion of the software; or rent,
lease, distribute, sell or create derivative works of the software.
The License is effective until terminated. Customer may terminate this License at any
time by disabling the Web based Health Consulting and Diseases Diagnosis Assistance
System and destroying all copies of Software, if any, including any documentation. The
License shall be governed by and construed in accordance with the laws of country, as if
performed wholly within the state and without giving effect to the principles of conflict
of law. If any portion hereof is found to be void or unenforceable, the remaining
provisions of this License shall remain in full force and effect. This License constitutes the
entire License between the parties with respect to the use of the Software.
39
Assistance System
2.13. Change Management Process
Since change is something that you cannot avoid through the development of software it
should be handled with diligence. Most of the time change on SRS come from client side
to handle such a change the first measure taken is to discuss about pros and cons that this
change bring with clients. Then we are going to have a group discussion regarding the
first action taken with the client and if it is decided that the change is critical or if the
impact on the development progress is affordable, we will accept the change and inform
the client and plan to implement it. Pros and cons of any change that should be made is
discussed among teammates and then applied.
On the other hand if change comes from team members during implementation, the team
will assess the feasibility of the proposed changes considering the time constraints and
structural constraints of the implemented modules and develop an implementation
strategy. A change plan will be created for the implementation of the change. The team
will then continue implementing the new requirements.
40
Assistance System
Chapter 3: System Design

3.1. Purpose
This Software Design Specification (SDS) document is prepared in order to give the
software development team overall guidance to the architecture of the Web based Health
Consulting and Diseases Diagnosing Assistance System project. The document discusses
the software architecture and design of the Web based Health Consulting and Diseases
Diagnosing Assistance System in detail. Moreover the document facilitates
communication and understanding of the system by providing several views of the
system design.
3.2. General Overview
professionals with clinical decision support, that is, assistance with clinical decision
making tasks and a way for providing consultancy services. The system is composed of
multiple independent subsystems and heterogeneous clients which includes web clients
(browsers), desktop and mobile application clients (both out of scope of this project) and
other systems.
Given the composted nature, composed of many sub systems, and heterogeneous clients
of the Web based Health Consulting and Diseases Diagnosing Assistance System the
RESTful (Representation State Transfer) architectural style, will be used for its
development.
The RESTful architectural style is an architecture style for designing networked
applications and is characterized by the following three main features:-
1. Client-server - The client handles the front end the server handles the backend
and can both be replaced independently of each other.
2. Stateless - No client data is stored on the server between requests and session state
is stored on the client.
3. Cacheable - Clients can cache response (just like browsers caching static elements
of a web page) to improve performance.
Complying with these constraints, and thus conforming to the REST architectural style
enables the proposed system to have desirable emergent properties, such as performance,
scalability, simplicity, modifiability, visibility, portability, and reliability. The high level
architectural design of the system is provided below in Figure 1.
41
Assistance System
Figure 7: The High Level Architectural Design of Web based Health Consulting and Diseases
Diagnosing Assistance System
3.3. Development Methods and Contingencies
The proposed system will be developed using the Java programming language, a general-
purpose computer programming language that is class-based, and object-oriented. As a
result, the system will be developed using the object oriented approach which provides
realistic representation of real word situations, greater reusability, and maintainability.
The development of the system requires the use of different libraries such as Hibernate,
spring, AngularJS, Bootstrap and Drools. Drools is used in the development of the
diseases diagnosing assistance subsystem which is based on artificial intelligence. It is
specifically used to capture diagnosing process knowledge or rules. During
implementation phase the system may require to change and use other inference engine
implementation libraries in order to increase the accuracy and consistency.
42
Assistance System
3.4. System Architecture
3.4.1. Subsystem Decomposition
For brevity reasons the details of the Diseases Diagnosing subsystem component
diagram has been taken out of the overall component diagram of the system and is
shown separately.
Figure 8: The UML Component Diagram for Diseases Diagnosing Subsystem
43
Assistance System
Figure 9: The UML Component Diagram of Web based Health Consulting and Diseases
44
Assistance System
3.4.2. Hardware/Software Mapping
Figure 10: The UML Deployment Diagram of Web based Health Consulting and Diseases
45
Assistance System
3.5. Object Model
3.5.1. Class Diagram
Figure 11: The UML Class Diagram of Web based Health Consulting and Diseases Diagnosing
Assistance System
46
Assistance System
3.5.2. Sequence Diagram
Figure 12: User Registration Sequence diagram
47
Assistance System
Figure 13: User Authentication Sequence diagram
48
Assistance System
Figure 14: Providing Feedback Sequence diagram
49
Assistance System
Figure 15: Search Experts Sequence diagram
Figure 16: Using Consultation Service Sequence diagram
50
Assistance System
Figure 17: Providing Consultation Service Sequence diagram
Figure 18: Insert Symptoms Sequence diagram
51
Assistance System
Figure 19: Diagnosing Diseases Sequence diagram
52
Assistance System
Figure 20: Add Diseases Sequence diagram
53
Assistance System
Figure 21: Article Posting Sequence diagram
Figure 22: Article Reading Sequence diagram
54
Assistance System
Figure 23: Verifying Documents Sequence diagram
55
Assistance System
3.6. Detailed Design
The classes represented here are the ones identified on our class diagram and sequence
diagram with additional extra information
Table 19: User class
User
+UserID:Integer
-UserName:String
-Password:String
+ PhoneNumber:Integer
+Address:Address
-Email:String
+Register ()
+Login ()
+Logout ()
Table 20: Attributes description for User class
Attribute Type Visibility Invariant

UserID Integer Public UserID<>Null and must contain numbers
UserName String Private Name <> NULL and must contain at least 2 characters
Password String Private Password<> NULL and must be between 4 to 12

characters
PhoneNumber Integer Public PhoneNumber <> NULL must be 10 digits and must
start by +251/09
Address Address Public Address <>NULL and it must contain a full address
information
Email String Private Email <> NULL
 Must contain @
 Must contain. (dot)
 Position of @ >1
 Position of (dot)>position of @ + 2
 Position of (dot)+3<= total length of email address
and the total character of the Email is at least 5
characters
56
Assistance System
Table 21: Operation description for User class
Operation Visibility Return Argument Pre-Condition Post Condition

type
Register Public void . The user’s The clients
personal personal
information information
shouldn’t exist should exist
Login Public void . The user shouldn’t The user should
signed in logged in
Logout Public void - Both the client’s Both the client’s

and Beggar’s and Beggar’s
Table 22: PersonalInfo class
PersonalInfo
+FirstName:String
+MiddleName:String
+LastName:String
+Age:Integer
Table 23: Attributes description for PersonalInfo class

FirstName String Public FirstName <> NULL and must be between 2 to 20
characters
LastName String Public LastName<> NULL and must be between 2 to 20
characters
MiddleName String Public MiddleName<>NULL and must be between 2 to 20
characters
Age Integer Public Age <> NULL and must contain a number
57
Assistance System
Table 24: Address class
Address
+Country:String
+Region/State:String
+City:String
+Subcity:String
+Woreda:String
+Kebele:String
+HouseNumber:String
+SpecificLocation:String
Table 25: Attributes description for Address class

Country String Public Country <> NULL and must contain characters and must
be set the proper name of a known country
Region/State String Public Region/State<> NULL and must contain characters and
must contain proper name of a known region/state
City String Public must contain characters and must be set the proper name
of a city
Subcity String Public must contain characters and must be set the
proper/known name of a city
Woreda String Public Woreda<>NULL and must contain either numbers or
characters
Kebele String Public Kebele<>NULL and must contain either numbers or
charatcters
HouseNumber String Public Must contain either characters or numbers
SpecificLocation String Public SpecificLocation<>NULL and must contain characters

and proper name of a place
Table 26: Physician class
Physician
58
Assistance System
+PersonalInfo:PersonalInfo
-AccountNumber:Integer
-Specialization:String
+diseaseSearch()
+Register ()
Table 27: Attributes description for Physician class

PersonalInfo PersonalInfo Public PersonalInfo<>NULL and must be a number and
must contain a reference(object) of at least one
PersonalInfo object
AccountNumber Integer Private AccountNumber<> NULL and must contain
numbers given by any legal bank
Specialization String Public Specialization <> NULL must contain characters
Table 28: Operation description for Physician class
Operation Visibility Return type Argument Pre-Condition Post Condition
diseaseSearch() Public ActionResult The disease The disease

should available should
already in the displayed to
server the users
screen
Register() Public void The physicians The physicians
personal personal
Table 29: Patient class
Patient
59
Assistance System
+Register ()
+expertSearch()
Table 30: Attributes description for Patient class

PersonalInfo object
AccountNumber Integer Private AccountNumber<> NULL and must contain
numbers and the numbers must be given by the legal
bank
Table 31: Operation description for Patient class
Operation Visibility Return type Argument Pre-Condition Post Condition
Register() Public void The patient’s The patient’s

personal personal
expertSearch() Public ActionResult Information of Information of
experts should experts should
be exist in the be displayed
server for the user
who search on
the screen
Table 32: Organization class
Organization
+OrganizationName:String
+Register ()
60
Assistance System
Table 33: Attributes description for Organization class

OrganizationName String Public OrganizationName <> NULL and must contain at least
2 characters
AccountNumber Integer Private AccountNumber<> NULL and must contain numbers
and the numbers must be given by a legal bank
Table 34: Operation description for Organization class

type
Register() Public void . The organizations The
information organizations
shouldn’t exist information
should exist
Table 35: Admin class
Admin
+Register ()
+VerifyUser()
+DeleteUser()
Table 36: Attributes description for Admin class

PersonalInfo object
Table 37: Operation description for Admin class

type
61
Assistance System
Register Public void The admins The admins

personal personal
VerifyUser Public void The user should The user should
register and verified
shouldn’t verified
DeleteUser Public void The user’s The user’s
personal personal
should exist shouldn’t exist
Table 38: Payment class
Payment
+PayerAccount:Integer
+RecieverAccount:Integer
+PerformTransaction ()
Table 39: Attributes description for Payment class

PayerAccount Integer Private PayerAccount <> NULL and must contain digits
(numbers) and the numbers must be given by a legal
bank
RecieverAccount Integer Private RecieverAccount<>NULL and must contain numbers
and the numbers must be given by a legal bank
Table 40: Operation description for Payment class

type
PerformTransaction Public void Transaction of Accomplished
money is transaction of
62
Assistance System
shouldn’t money should

performed exist
Table 41: Chat class
Chat
+Sender
+Recipient
+ShowChatHistory()
+DeleteMessage()
Table 42: Attributes description for Chat class

Sender Integer Public Sender <>NULL and must contain a number that refer to
the User class
Recipient Integer Public Recipient <> NULL and must contain a number that refer
to the User class
Table 43: Operation description for Chat class

type
ShowChatHistory Public void History of History of chats
chats(chats takes should be
place before) presented
should exist
DeleteMessage Public void Messages should Message should
exist be deleted and
shouldn’t exist
Table 44: TextMessage class
TextMessage
+TextContent
+SendText ()
63
Assistance System
Table 45: Attributes description for TextMessage class

TextContent String Public TextContent <> NULL and must contain characters
Table 46: Operation description for TextMessage class

type
SendText Public void The text message The text
shouldn’t sent message should
already be sent
Table 47: AudioMessage class
AudioMessage
+AudioContent
+SendAudio ()
Table 48: Attributes description for AudioMessage class

AudioContent Binary Public AudioContent <> NULL and must be a .wav file type
Table 49: Operation description for AudioMessage class

type
SendAudio Public void The should be The audio
available and should be
shouldn’t sent already sent
64
Assistance System
Table 50: Articles class
Articles
+ArticleId:Integer
+ArticleName:String
+ArticleTitle:String
+ArticleBody:String
+PostArticle ()
+RemoveArticle()
+ModifyArticle()
Table 51: Attributes description for Articles class

ArticleId Integer Public ArticleID <> NULL and must contain a number
ArticleName String Public ArticleName <> NULL and must contain at least one
character
ArticleTitle String Public ArticleTitle <> NULL and must contain at least one two
characters
ArticleBody String Public ArticleBody <> NULL and must contain characters
Table 52: Operation description for Articles class

type
PostArticle Public void The article The article
shouldn’t posted should posted
RemoveArticle Public void The article should The article

exist should removed
65
Assistance System
ModifyArticle Public void The article should The content of

exist the article
should edited or
modified
Table 53: Feedback class
Feedback
+Date:Date
+FeedbackFor
+ViewFeedback ()
Table 54: Attributes description for Feedback class

Date Date Public Date <> NULL and must contain a date
FeedbackFor String Public FeedbackFor <> NULL
Table 55: Operation description for Feedback class

type
ViewFeedback Public void Feedbacks should The user could
exist view a feedback
Table 56: Comments class
Comments
+CommentID:Integer
+CommentBody:
66
Assistance System
+Postcomment ()
+RemoveComment()
+ModifyComment()
Table 57: Attributes description for Comments class

CommentID Integer Public CommentID <> NULL and must contain a number
CommentBody String Public CommentBody <> NULL and must contain a text
Table 58: Operation description for Comments class

type
PostComment Public void The comment The comment
shouldn’t posted should be
posted
RemoveComment Public void The comment The comment
should exist shouldn’t exist
ModifyComment Public void The comment The comments

should exist and should edited or
shouldn’t modified
modified
Table 59: Ratings class
Ratings
+Value:Integer
+Rate ()
Table 60: Attributes description for Ratings class
67
Assistance System
Value Integer Public Value <> NULL and must contain a number between 0
and 5
Table 61: Operation description for Ratings class

type
Rate Public void The rate shouldn’t The rate should
given given
68
Assistance System
3.7. User Interface Design
Figure 24: Home Page Interface
69
Assistance System
Figure 25: Registration Page interface
Figure 26: Login Interface
70
Assistance System
Figure 27: Feedback Giving Page
71
Assistance System
Figure 28: Consulting Service Page
72
Assistance System
Figure 29: User Consulting the Doctor
Figure 30: Doctor giving the consulting service
73
Assistance System
BIBLIOGRAPHY
[1] Health Status in Ethiopia, written in the background section of this document:
available on https://en.wikipedia.org/wiki/Health_in_Ethiopia [Accessed: on
November 9, 2016]
[2] How to write a good proposal; available on http://www.wikihow.com/Write-a-

Proposal [Accessed: On November 3, 2016]
[3] How to write a project proposal: available on

http://www.slideshare.net/Makewa/8-project-proposal [Accessed: On November 3,
2016]
[4] How to write an abstract for a proposal; available on

https://projectgraduateschool.wordpress.com/2011/07/15/how-to-write-a-proposal-
abstract/ [Accessed: on November 11, 2016]
[5] How to write a project abstract; available on

http://www.sciencebuddies.org/science-fair-projects/project_abstracts.html [Accessed
on: November 11, 2016]
[6] Overview of Health Sector in Ethiopia, written in the background section: available
on http://www.moh.gov.et/overviewsector [Accessed: On November 9, 2016]
The IEEE Guide to SRS,

http://www.csc.villanova.edu/~tway/courses/csc4181/s2010/srs_template-1.doc
http://www.ibm.com/developerworks/rational/library/3101.html [accessed on Jan.

10, 2017]
https://creately.com/diagram-examples [accessed on Jan. 10, 2017]
74
Assistance System
APPENDIX
A.1 Risk Categories
Risk Description
Scope Risk Defining what is required is not always easy.
Possible causes of Scope risks:
- Scope creep
- Insufficiently defined scope
- Unexpected changes in the legal
framework
Schedule Risk Keeping to timelines and agreed critical paths is

one of the most difficult situation.
Possible causes of Schedule risks:
- Estimation errors
- Hardware delays
- Putting off decision making
- Health problems
Operational Risk Risks of loss due to improper process

implementation, failed system or some external
events risks.
Possible causes of Operational risks:
 Failure to address priority conflicts
 Failure to resolve the responsibilities
 Insufficient resources
 No communication in team
Technical Risk Technical risks generally leads to failure of

functionality and performance.
Possible causes of technical risks are:
- Continuous changing requirements
- Product is complex to implement
- Difficult project modules integration
- difficulty of identifying best addressing
mechanisms
75
Assistance System
A.2 Flow Charts
User Registration
Figure 31: Flow Diagram - User Registration
76
Assistance System
Edit profile
Figure 32: Flow Diagram – Edit Profile
77
Assistance System
Post Article
Figure 33: Flow Diagram – Article Posting
78
Assistance System
Insert Symptoms
Figure 34: Flow Diagram – Insert Symptoms
79
Assistance System
Providing Feedback
Figure 35: Flow Diagram – Providing Feedback
80

All in One

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

All in One

Uploaded by

Copyright:

Available Formats

ADDIS ABABA UNIVERSITY

ADDIS ABABA UNIVERSITY INSTITUTE OF

Date Feb. 27, 2017

Addis Ababa Institute of Technology

Project Advised by:

Ins. Endrais Haile

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ ______________

2. __________________ Chairperson _____________ ______________

3. __________________ Examiner _____________ ______________

4. __________________ Examiner _____________ ______________

5. __________________ Examiner _____________ ______________

Name Signature Date

1. Abebe Gietaneh __________________ __________________

2. Abraham Dereje __________________ __________________

3. Asefa Tasew __________________ __________________

4. Challelign Tilahun __________________ __________________

Advisor Name: Ins. Endrais Haile Signature: _________________________

Chapter 2: Requirement Analysis ............................................................................................ 10

2.7. Use Cases .......................................................................................................................... 25

3.5.1. Class Diagram ........................................................................................................... 46

Table 39: Payment class ............................................................................................................. 62

Figure 34: Flow Diagram – Insert Symptoms ....................................................................... 79

Definitions, Acronyms, Abbreviations

Table 1: Definitions, Acronyms, Abbreviations

1.2 The Existing System

1.3 Statement of the Problem

1.4 Objective of the Project

1.5 Proposed System

EXPERTS THE SYSTEM

Make a decision about the Analyze the data and

Figure 1: System Architecture

Searching for Experts:

1.6 Feasibility Study

1.6.1.1. Developmental cost

1.9 Project Management plan

ID Task Name Start Date Finish Date Duration Completion

3 SRS Nov.20/2016 Dec.20/2016 4 weeks 100%

Table 2: Time Table

Figure 2: Gantt chart of Schedule

1.9.2. Quality Management Plan

Table 3: Internal Communication Management Plan

Chapter 2: Requirement Analysis

2.4. General Description

2.4.1. Product Perspective

2.4.2. Product Functions

g) A feature that enables people filter nearby or any specific physicians.

2.4.4. General Constraints

2.5. External Interface Requirements

2.5.1. User Interfaces

Figure 3: Home Page

Figure 4: Chatting Page

2.5.2. Hardware Interfaces

2.5.3. Software Interfaces

– Adding new Information

2.5.4.3. Data Communication

2.6. Functional Requirements

2.6.1. FR: 01 – Text Messaging

Introduction The system shall allow users to be able to send

Table 4: FR: 01-Text Messaging

2.6.2. FR: 02 – Audio Messaging

Table 5: FR: 02-Audio Messaging

1. ____________ Advisor _ ________

2. ____________ Chairperson _ ________

3. ____________ Examiner _ ________

4. ____________ Examiner _ ________

5. ____________ Examiner _ ________

1. Abebe Gietaneh

2. Abraham Dereje

3. Asefa Tasew

4. Challelign Tilahun