Software Engineering Final Year Project Report

i

MAKERERE UNIVERSITY

Web Based Diagnosis System

By
BSE 19-15
WEB SYSTEM
DEPARTMENT OF NETWORKS
SCHOOL OF COMPUTING AND INFORMATICS TECHNOLOGY

A Project Report Submitted to the School of Computing and Informatics Technology
for the Study Leading to a Project in Partial Fulfillment of the
Requirements for the Award of the Degree of Bachelor of
Science in Software Engineering of Makerere University.

Department of Networks
School of Computing and Informatics Technology, Makerere University

June,2019

i

Declaration
We, group BSE 19-15, hereby declare that the work presented is original and has never been
submitted for an award to any university or institution of higher learning.

# NAMES REGISTRATION NUMBER
STUDENT
NUMBER
1 NANSUBUGA JOYCE EUZEBIA 15/U/10807/EVE 215014151
2 ODOCH ROBERT 14/U/1033 214000256
3 BWAYO JUDE 15/U/4718/EVE 215004397
4 NABIKOLO SHIBA 15/U/8925/PS 215012434

ii

Approval
This project report titled Web Based Diagnosis System has been submitted for examination with
my approval as the supervisor of group BSE19-15.
Dr. Joab Ezra Agaba
Department of Networks
School of Computing and Informatics Technology;
College of Computing and Information Sciences,
Makerere University
Signature: ................................................... Date: ............................
Supervisor

iii

Dedication
We, group BSE19-15, hereby dedicate this final year project to the College of Computing and
informatics Technology that has brought us this far, as far as our academic knowledge is concerned,
our project supervisor who has been there to guide us on rightful decisions to take while developing
the project, our families that have been so helpful in making sure that we attain the skills beyond
basics in education and lastly to our colleagues with whom we have shared knowledge during the
entire period of our course.

iv

Acknowledgements
We convey great thanks to the almighty God and his begotten son Jesus Christ the Lord our savior
for the love, favor, wisdom, guidance and protection whose power enabled us to reach this far with
the Final year project.

We would like to express our gratitude to the College of Computing and Informatics Technology
for availing us with a conducive environment for doing our project as a partial fulfillment of our
degree of Bachelor of Science in Software Engineering.
We are so grateful to our Final year project coordinator Ms. Mary Nsabagwa for clearly laying out
important guidelines that we followed during the course of the project.
We extend heartfelt thanks to our project supervisor Dr. Joab Ezra Agaba for his time he sacrificed
for our supervision and continuous guidance about the project.

Our sincere thanks go to the respective organizations that we visited during the data collection
process of the project such as Hospitals (University hospital, Norvik hospital, Mulago hospital),
pharmacies e.g. First pharmacy Wandegeya branch and private clinics for entrusting us with their
medical data to support the project.

We deeply thank our families for their continuous love, moral and financial support towards us
throughout the course. For they have showed us real love, may the Almighty God richly bless
them.
We further extend our sincere thanks to all friends who supported us generously by advising us on
various areas that needed improvement so that the project achieves its intended purpose of
implementation.

v

Abstract
The purpose of this project is to develop a web-based system that will enable patients to obtain
preliminary diagnosis, make medical consultation from qualified medical personnel.
The project provides a platform that enables patients to send a categorized detail of signs and
symptoms about body illnesses to medical practitioners for preliminary diagnosis. The system
also allows medical specialists to receive patient’ enquiries about various body illnesses, once
received, they perform thorough analysis onto it there by deducing the most likely illness that
requesting patient may be suffering from and possible.
The project further provides an advanced medical enquiry service from medical practitioners in
form of paid medical consultancy, here patients first pay a given amount of consultation fee to a
specific medical practitioner of their preference and then they are able to consult him/her directly.
With paid medical consultancy, it is very efficient as a patient gets a response to his/her inquiry
immediately unlike in general medical consultancy where patients address their enquiries to a pool
of doctors and is provided by a specialist who may find interest in responding to a particular
medical enquiry. Each pool consists of doctor with a specific specialty.
From the patient’s records gathered, the system generates analytics in the form of graphs and charts
from which system users are able to deduce the common illnesses that patients suffer from, the
number of doctors available to attend to patients’ enquiries in each specialty, regions from which
most patient enquiries are received.
Medical personnel have always been in need of a platform where they can share knowledge and
successfully proven approaches on how to prevent or cure certain illnesses; the project provides a
platform which makes this possible.

vi

BSE 19-15
WEB BASED DIAGNOSIS SYSTEM
SOFTWARE DESIGN DOCUMENT
TEAM MEMBERS
1. BWAYO JUDE
2. NANSUBUGA JOYCE EUZEBIA
3. ODOCH ROBERT
4. NABIKOLO SHIBA
31/05/2019

Blog url: https://bse1915.wordpress.com/

vii

Table of Contents
Declaration ....................................................................................................................................... i
Approval ......................................................................................................................................... ii
Dedication ...................................................................................................................................... iii
Acknowledgements ........................................................................................................................ iv
Abstract ........................................................................................................................................... v
Table of Contents .......................................................................................................................... vii
List of Figures ................................................................................................................................ ix
List of Tables .................................................................................................................................. x
1. Introduction ................................................................................................................................. 1
1.1 Purpose .................................................................................................................................. 1
1.2 Scope ..................................................................................................................................... 1
1.2.1 Goal of the project .......................................................................................................... 1
1.2.2 Objectives of the project ................................................................................................. 1
1.2.3 Benefits of the project..................................................................................................... 2
1.3 Overview ............................................................................................................................... 3
1.4 Reference material................................................................................................................. 4
1.5 Definitions and Acronyms .................................................................................................... 4
2. System Overview ........................................................................................................................ 6
3.System architecture ...................................................................................................................... 7
3.1 Architecture design ............................................................................................................... 7
3.2 Decomposition Description ................................................................................................... 9
3.2.1 class diagram for WBDS: ............................................................................................... 9
3.2.2 Use case diagram for Web Based Diagnosis System ................................................... 11
3.3 Design rationale................................................................................................................... 21
4.Data Design ................................................................................................................................ 22
4.1 Data Description .................................................................................................................. 22
4.1.1 Conceptual model ....................................................................................................... 23
4.1.2 Logical model ............................................................................................................. 24
4.1.3 Physical design ............................................................................................................. 25
5.Component design ..................................................................................................................... 29
6. Human Interface Design ........................................................................................................... 36
6.1 Overview of user interface .................................................................................................. 36

viii

6.2 Screen Images ..................................................................................................................... 37
7.Requirements Matrix ................................................................................................................. 40

ix

List of Figures
Figure 1:Modular architecture of the WBDS system ..................................................................... 7
Figure 2:Class diagram of the WBDS system ................................................................................ 9
Figure 3:Use case diagram for the WBDS system ........................................................................ 11
Figure 4:Sequence Diagram-Register user ................................................................................... 13
Figure 5:Sequence Diagram-Login user ....................................................................................... 14
Figure 6:Sequence diagram – Submit Medical Enquiry ............................................................... 15
Figure 7:Sequence diagram - View Medical Response ................................................................ 16
Figure 8:Sequence diagram - View Medical Enquiry ................................................................... 17
Figure 9:Sequence diagram - Medical Enquiry ............................................................................ 18
Figure 10:Sequence diagram - Approve Practitioner’s Registration detail .................................. 19
Figure 11:Sequence diagram - Manage Specialty ........................................................................ 20
Figure 12:Sequence diagram - Logout .......................................................................................... 21
Figure 13:ERD for WBDS system ................................................................................................ 24
Figure 14:Patient home page ........................................................................................................ 37
Figure 15:Medical practitioner's home page ................................................................................. 38
Figure 16:Administrator Panel ...................................................................................................... 39

x

List of Tables
Table 1:Overview of the design document ..................................................................................... 3
Table 2:Acronyms Listing .............................................................................................................. 4
Table 3:Class diagram description for the WBDS system.............................................................. 9
Table 4:Register Use case Narrative ............................................................................................. 12
Table 5:Login use case narrative .................................................................................................. 13
Table 6:Submit Medical Enquiry use case narrative .................................................................... 14
Table 7:View Medical Response use case narrative ..................................................................... 15
Table 8:View Medical Enquiry use case narrative ....................................................................... 16
Table 9:Respond to Medical Enquiry use case narrative .............................................................. 17
Table 10:Approve Practitioner’s Registration details use case narrative ..................................... 18
Table 11:Manage Specialty use case narrative ............................................................................. 19
Table 12:Logout use case narrative .............................................................................................. 20
Table 13:Component design ........................................................................................................ 29
Table 14:Requirements traceability matrix ................................................................................... 40

1

1. Introduction
1.1 Purpose
The purpose of this software design document (SDD) is to provide description of the design and
architecture of the Web Based Diagnosis system that is required to fulfill requirements specified
in the Software Requirements Specification document (SRS) fully enough to allow the system
development to proceed with a legal understanding of what is to be built.
This document is addressed mainly to the development team of WBDS and shall be used as a
reference during implementation of the system.
1.2 Scope
The system shall be used by users i.e. patients and medical practitioners within and around
Kampala. The system shall accept input from patients in form of medical enquiries (signs and
symptoms), then it shall automatically send the provided input to each of the medical practitioners
that fall in the specialty in which the enquiry is made. Thereafter it shall provide feedback to the
patient that will include the suggested treatment for the possible disease that will have been
diagnosed by the medical practitioners using the signs and symptoms provided by the patient as a
result, patients shall be able to obtain treatment without necessarily accessing a doctor physically.
1.2.1 Goal of the project
The goals of the WBDS are to:
1. Provide medical treatment to patients without necessarily accessing the doctor physically.
2. Provide a platform for sharing knowledge amongst medical practitioners.
3. Assign a patient a rightful medical practitioner to handle his/her illness.
4. Provide analytics of a particular area where medical cases have been most reported.
5. Make people in the community aware of health events that are currently going on or are
upcoming.
1.2.2 Objectives of the project
1. Allow patients to submit their medical inquiries to respective medical practitioners.
2. Allow medical practitioners to create groups called health units where patients can post
their queries and also be notified of upcoming events.

2

3. Enable vetting (upvote or downvote) of a response from a medical practitioner by other
practitioners of the same specialty.
4. Acquire information about areas from which most medical enquiries have been made.
1.2.3 Benefits of the project
1. Patients shall receive preliminary medical information remotely from medical
practitioners.
2. Doctors shall be able to earn extra money outside their official jobs.
3. Patients shall be able to get help from doctors who might be far away from their current
location.
4. Stakeholders like the ministry of health and NGOs, shall use the analytics from the system
to see which specialties or regions need more medical practitioners.
5. Health units shall be able to create a group that can be shared with patients so that they can
post their queries.
6. Health units shall be able to create an event that can be used to provide a particular health
service or to educate communities.
7. Medical practitioners shall be able to share ideas and knowledge among themselves.

3

1.3 Overview
The system design document is divided into eight sections with various subsections. The
sections are organized as follows;
Table 1:Overview of the design document
Section Purpose
Section 1: Introduction This section comprises of the purpose, intended
audience, scope of the project, the benefits that shall
be obtained from the project, and definition of
acronyms that have been used in the document.
Section 2: System Overview It gives a general description of the functionality,
context and design of the project.
Section 3: System Architecture It presents the architecture of the Web Based
Diagnosis System.
Section 4: Data Design It explains how information domain of the system is
transformed into data structures.
Section 5: Component Design Provides systematic and detailed information of the
individual system components.
Section 6: Human Interface Design Explains user system interaction i.e. how users shall
interact with the system.
Section 7: Requirements Matrix Provides a cross-reference that traces components
and data structures to the requirements presented in
the SRS document.

4

1.4 Reference material
[1] “What is medical practitioner? definition and meaning - BusinessDictionary.com.”
[Online]. Available: http://www.businessdictionary.com/definition/medical-
practitioner.html. [Accessed: 04-Apr-2019].
[2] “Ugandans Warned Against Self Medication.” [Online]. Available:
https://www.newvision.co.ug/new_vision/news/1473473/ugandans-warned-self-
medication. [Accessed: 04-Apr-2019].
[3] “Advantages And Disadvantages of Client application server.” [Online]. Available:
https://www.esds.co.in/blog/advantages-and-disadvantages-of-client-application-
server/#sthash.MnGoxLXh.dpbs. [Accessed: 04-Apr-2019].
1.5 Definitions and Acronyms
Table 2:Acronyms Listing
No Term Definition
1. GPS Global Positioning System- is a space-based
navigation system that provides location and time
information in all weather conditions anywhere.
2. SDD Software Design Document
3. SRS Software Requirements Specification
4. WBDS Web Based Diagnosis System
5. App Application
6. Medical practitioner Is an individual accredited, licensed, and/or
registered as a health professional upon meeting
the specified requirements[1].
7. Patient Is a person under healthcare. The person may be
waiting for this care or may be receiving it or may
have already received it.
8. Admin Administrator
9. UC Use case
10. ERD Entity Relationship Diagram

5

11. PK Primary key
12. FK Foreign key
13. PC Personal Computer

6

2. System Overview
Due to a high cost involved in consulting medical specialists about various illnesses, many
Ugandans have resorted to self-medication, something that could put their lives in danger.
According to Dr. Ivan Kabuye a general practitioner at the International Hospital Kampala, he says
many Ugandans are self-medicating especially on anti-malarial, pain killers and skin lightening
creams for women. He further explains that when one experiences body pains, it is a
communication that something is wrong and doing self-medication could mean over or under
treating self, treating something that one is not certain of and delay in seeking right treatment
increases the burden of the disease and increases chances of death for illnesses like cancer[2].
According to the research conducted in one of the hospitals in Kampala, Mulago referral hospital
where 50 questionnaires were distributed and 45 received from the respondents (patients and
medical practitioners). For the 35 questionnaires received from patients, the information collected
showed that a few individuals who manage to make it to hospitals find long queues of other patients
waiting to be attended to. As a result, a patient must wait until it’s their turn to be worked on by
the doctor in charge and this is a wastage of time. While others explained that they get frustrated
over the missed appointments they had scheduled with medical specialists due to their
unavailability at their designated places of work.
Due to the problem stated above, Group BSE 19-15 proposed a web based diagnosis system which
is a web based platform. The system shall prompt a patient to enter his or her signs and symptoms,
select a tag that shall be attached to his/her enquiry before submission. From this tag attached to
the enquiry, the system shall be able to automatically assign the enquiry to all medical practitioners
that match the tag attached.
The corresponding medical practitioners shall read through the patient’s enquiry and provide their
medical knowledge in form of a response as a solution to the patient’s medical enquiry.
A medical response once provided by a medical practitioner shall pass through a vetting process
where fellow practitioners shall decide to either up vote or down vote it to show the patient the
most relevant answer.

7

3.System architecture
This section outlines the system and hardware architecture design of the system.
3.1 Architecture design
This section outlines the system architecture design of the system.
The implementation of WBDS is based on a client/server architecture. Client/server architecture
generally refers to systems that divide processing between one or more networked clients and a
central server. In this architecture, the client handles the entire user interface including patient
enquiries, medical practitioner response(s) to patient enquiries. The server stores the patient
enquiries. For a medical practitioner to provide response to an enquiry, he accesses these enquiries
from the database and as well the responses provided are stored in the database thereafter, they are
displayed to the patient.

Figure 1:Modular architecture of the WBDS system
The Web Based Diagnosis system consists of the following modules:
1. The Authentication and Authorization module: any user can read content on the application
but only logged in users can perform write operations like submitting in signs/symptoms of their
problematic health conditions. The authentication module handles the registration of new users
and the logging in of existing users of the system. Once logged into the system, users can
perform both read and write operations. Some content however is limited for viewing only to
users with a privilege. For example, a normal user can only view his/her own queries and actions Registration Login Medical enquiry Medical inquiry
allocation
manager Filtered medical
enquiries My Responses All Responses Notification
Manager Rewards
Processor Database Medical inquiry
analytics Patient Medical
Practitioner Authentication module Medical enquiry
allocation manager Medical response
manager Queries module

8

performed on it whereas doctors can view queries posted by any user of the application. This
filtering of content basing on the type of user is called authorization.
2. The Queries module: This module enables a patient to submit his/her medical enquiries to
specialists in order to obtain feedback.
3. The Notifications manager: Users are immediately notified when their enquiry has been
responded to by a medical practitioner.
4. Medical enquiry allocation manager: Once a patient submits his/her medical enquiry, the
system gets the submitted enquiry and assigns it to all medical practitioners that have expertise
in that specialty in which the enquiry has been made.
5. Medical response manager: When a medical practitioner contributes towards an enquiry made
by a patient, his/her contribution goes through a vetting process where fellow practitioners
decide to either upvote or down vote a fellow’s contribution. A response that is true and helpful
to a patient is upvoted while the one that is not is downvoted. Only a contribution whose upvotes
exceed the down votes is submitted as a response to the patient.
6. Medical enquiry analyzer: This module provides analytics about which medical cases are
reported most, in which places they occurred and the number of medical practitioners attending
to patients’ enquiries in various specialties in which the enquiries were made.
7. Consultancy: Here, the system provides a mechanism that a patient can use to get in touch with
the medical practitioner on monetary terms.
8. Rewards processor: This module is responsible for processing of the medical practitioner’s
commission basing on the total points acquired through the upvotes and downvote counts on
responses to patient’s enquiries.

9

3.2 Decomposition Description
3.2.1 class diagram for WBDS:

Figure 2:Class diagram of the WBDS system
Table 3:Class diagram description for the WBDS system
Class Diagram Description:
Class Name Documentation
1. Medical
Practitioner
1) Responsible for replying to the sent enquiry using respondToEnquiry()
method.
2) Also responsible for vetting (upvote or downvote) the medical response to
patient’s enquiry made by fellow practitioners in the same specialty using
vetResponse() method. User -firstName:String
-lastName:String
-email:String
-dateOfBirth:Date
-telephone:String
-gender:String
-addedOn:timestamp +login():String
+logout():String
+viewAnalytics():String WBDS Class Diagram MedicalPractitioner -id:Integer
-speciality:Integer
-totalPoints:Integer +viewMedicalEnquiry():String
+respondToEnquiry():String
+viewProfile():String
+register():String Patient -id:Integer +makeEnquiry():String
+viewResponse():String
+register():String Administrator -adminId:Integer +approveNewMedicalPractitioner():String
+addDistrict():String
+editMedicalPractitionerInfo():String Query -queryId:Integer
-question:String
-speciality:Integer +upvote():Integer
+downvote():Integer Specialty -id:Integer
-name:String +addSpeciality():String
+editSpeciality():String
+registerTag():String records respondsTo submits 1 0--* 1 0--* 1 1--* District -id:Integer
-name:String
-latitude:String
-longitude: +addName():String
+addCordinates():String
+addRegion():String 1--* 1 adds

10

3) It interacts with the query class using viewMedicalEnquiry() method to
enable a medical practitioner to read and respond to a patient’s enquiry.
2. Patient

1) It is responsible for making a medical enquiry using
makeEnquiry() method.
2) It interacts with the query class using makeEnquiry() method to
submit an enquiry.
3) Also responsible for viewing the Medical response using
viewResponse() method.
3.Administrator

1) It is responsible for managing the system by adding new district,editing
medical practitioner’s information and approving new medical practitioner
using addHealthCenter(), deleteMedicalPatitioner(),
editMedicalPratitionerInfo() and approveNewMedicalPractitioner()
methods respectively.
2) It interacts with specialty class using approveNewMedicalPractitioner ()
method to record the specialty of a given medical practitioner.
3) It also interacts with health center class using addHealthCenter() method to
register a particular health center.
4. User

1) Responsible for managing the registration, logging in and logging out of
users in the system using register() and login() methods.
2) Responsible for displaying system’s analytics.
5. Specialty 1) It is responsible for managing the specialty information by adding a
specialty, editing specialty information, and deleting specialty using
addSpecialty(), editSpecialty(), and deleteSpecialty() methods respectively.
6. Health unit 1) It is responsible for creating a localized group where doctors can quickly
respond to user queries.
6. Query 1) Responsible for managing the submitted enquiries from patients.

11

2) Handles responses from medical practitioners for various medical enquiries.

3.2.2 Use case diagram for Web Based Diagnosis System

Figure 3:Use case diagram for the WBDS system
Use cases
UC -1 Register (Patient, Medical Practitioner)
UC -2 Login (Patient, Medical Practitioner, Administrator)
UC -3 Submit Medical Enquiry (Patient)
UC -4 View Medical Response (Patient)
UC -6 View Medical Enquiry (Medical Practitioner)
UC -7 Respond to Medical enquiry (Medical Practitioner) Web Based Diagnosis System Register Login Submit Medical
Enquiry Patient View Medical
Response Medical
Practitioner View Medical
Enquiry Respond to
Medical enquiry Approve Practitioner
Registration details Manage Speciality Logout Administrator < < i n c l u d e > > view medical
analytics Add health unit

12

UC -8 Vet Medical Practitioner’s contribution (Medical Practitioner)
UC -9 Approve Practitioner’s Registration details (Administrator)
UC -10 Add Health Unit (Medical Practitioner)
UC -11 Manage Specialty (Administrator)
UC -12 Logout (Patient, Administrator, Medical Practitioner)
UC- 13 View Medical analytics
Table 4:Register Use case Narrative
Use Case 1 Register
ID UC-1
Primary actor(s) Patient, Medical Practitioner
Pre-condition 1. An individual desire to use this system and is not registered
(does not have an account).
Main scenario 1. To register with the system, a user provides his/her biodata
e.g. first name, last name, date of birth etc.
2. The system validates the provided registration details and
checks if no match exists that contains same information as
provided.
3. If no similar information is found, the user is registered
successfully.

Post-condition User is successfully registered, and user account created.

13

Figure 4:Sequence Diagram-Register user
Table 5:Login use case narrative
Use Case 2 Login
ID UC-2
Primary actor(s) Patient, Medical Practitioner, Administrator
Pre-condition 1. The user must be registered and possesses a username and
password as the login credentials.
Main scenario 1. User fills the login form with his/her username and password.
2. The system verifies the provided login details.
3. If the provided login credentials are valid, a session between
the remote user and the system is created.

Alternate scenario 1. The user receives error messages on the login screen showing
the provided login details are invalid.
2. A login form is re-displayed such that he/she can provide
valid login details once again.
Post-condition The user is successfully logged into the system. alt User :Registration
module 1:requestRegistrationScreen() 1.1:displayForm() 1.2:enterBioDataInfo() 2:checkIfInputSyntaxIsValid() :UserOperations
Controller :Data store 3:verifyIfNoMatchExists() 3.1:checkIfDetailsExist 3.1.2:no record found 5:captureRegistrationDetails() 3.1.1:details Exist 3.1.1.1:match found 3.1.2:1:match not found 4:redirect to registration
screen [user is already registered] 5.3:Registration details stored 5.4:user account created successfully 5.2:user account
created User Account 5.1:storeRegistrationInfo()

14

Figure 5:Sequence Diagram-Login user
Table 6:Submit Medical Enquiry use case narrative
Use Case 3 Submit Medical Enquiry
ID UC-3
Primary actor(s) Patient
Pre-condition 1. The patient has signs and symptoms of the illness he/she
wants to seek treatment for.
Main scenario 1. The patient requests for a medical enquiry form from the
system.
2. The system displays the ‘Medical enquiry form’ to the patient.
3. A patient fills a form for making a medical enquiry.
4. He/she provides a brief description of the sign and symptoms
associated with the illness he/she is suffering from.
5. If the patient has an attachment e.g. an image of an infected
area (for skin diseases), he/she uploads it and it is attached to
the enquiry.

15

6. The patient submits the enquiry to the system and waits for a
response.
Post-condition The patient has successfully submitted an enquiry to the system.

Table 7:View Medical Response use case narrative
Use Case 4 View Medical Response
ID UC-4
Primary actor(s) Patient
Pre-condition The patient must have submitted a medical enquiry to the system.
Main scenario 1. The patient accesses the system via a remote device such as
computer or android smart phone.
2. The patient clicks on the notification tab to view the
response(s) made to his/her enquiry.
3. The system displays the medical response.
4. Patient reads and puts into action the medical response
provided to him/her.
Alternate scenario If no response received, the patient is notified with a message
indicating that no responses were received. Patient :userOperationsController 1:requestEnquiryForm() 1.1:displayForm() 1.2:enterEnquiryInfo() :Data store 3.1:enquiry has been
submitted 2:insertEnquiry() 3:enquiry inserted
Figure 6:Sequence diagram – Submit Medical Enquiry

16

Post-condition Patient has received feedback from medical practitioner(s) and is now
aware of his/her medical condition.

Figure 7:Sequence diagram - View Medical Response
Table 8:View Medical Enquiry use case narrative
Use Case 6 View Medical Enquiry
ID UC-6
Primary actor (s) Medical Practitioner
Pre-condition Patient has already submitted his/her medical enquiry.
Main scenario 1. This use case begins when the medical practitioner accesses
the system via a remote device such as android smart phone
or personal computer.
2. The system displays a notification about new medical
enquiry(s) from patients.
3. He/she clicks on the notification to view the medical enquiry.
4. He/she views the medical enquiries.
Post-condition Medical practitioner has viewed medical enquiries from patients. alt Patient :userOperationsController 1:clickToViewResponse() 1.1:displayForm() :Data store 2:retrieveMedicalResponse() 2.1:Response exists 2.2:No response found 2.2.1:No feedback 2.1.1:Response displayed

17

Figure 8:Sequence diagram - View Medical Enquiry
Table 9:Respond to Medical Enquiry use case narrative
Use Case 7 Respond to Medical Enquiry
ID UC-7
Primary actor(s) Medical Practitioner
Pre-condition Medical practitioner has already viewed the submitted medical
enquiry.
Main scenario 1. This use case begins when the system displays the sent
enquiry from a patient.
2. The medical practitioner responds to the sent enquiry.

Post-condition He/she has successfully responded to a patient’s enquiry.

18

Figure 9:Sequence diagram - Medical Enquiry
Table 10:Approve Practitioner’s Registration details use case narrative
Use Case9 Approve Practitioner’s Registration details
ID UC-9
Primary actor(s) Administrator
Pre-condition A medical practitioner has submitted in his/her registration details to
the system.
Main scenario 1. This use case begins when the administrator accesses the
system via a remote device such as an android smart phone or
personal computer.
2. He/she approves the validity of the registration details
provided by the new medical practitioner. :userOperations
Controller 1: Click the respond to medical enquiry button :dataStore 1.2:displayMedicalEnquiryPage() medicalPractitioner 2:fetchMedicalEnquiry() 2.2:saveResponse(reponse) 1.3:enterMedicalEnquiryResponse() 2.3:publishResponseForVetting()

19

Post-condition New medical practitioner registration details have been approved and
is now fully registered.

Figure 10:Sequence diagram - Approve Practitioner’s Registration detail
Table 11:Manage Specialty use case narrative
Use Case 11 Manage Specialty
ID UC-11
Primary actor(s) Administrator
Pre-condition The administrator has logged into the system.
Main scenario 1. He/she clicks the ‘specialty management’ tab.
2. The system displays the Specialty page.
3. The administrator selects among options (add,edit) to be
performed on a specialty type.
Post-condition The specialty information is successfully managed.
alt :userOperations
Controller 1: Receive registration request for new
medical practitioner :dataStore Admin:System
Administrator 1.2: Analyze medical practitioner's bio data Valid Bio-data 1.3: Approve Medical Practitioner's
Registration Request 2.2: saveApprovedMedicalPractitioner 2:savePractitionerRegistrationRequest() invalid Bio-data 1.4: Disapprove Medical Practitioner's
Registration Request 2.3: disableDispprovedMedicalPractitioner

20

Figure 11:Sequence diagram - Manage Specialty
Table 12:Logout use case narrative
Use Case 12 Logout
ID UC-12
Primary actor(s) Patient, Medical Practitioner, Administrator
Pre-condition The user is currently logged into the system.
Main scenario This use case terminates the session on user’s request.
Post-condition Session terminated.

:userOperationsController 1: clickSpecialtyTab() :Data store 3:updateSpecialtyInfo() 3.2:notify operation successful 2:perform operations Administrator 1.1:displaySpecialtyPage() 3.1:information update successfully

21

Figure 12:Sequence diagram - Logout
3.3 Design rationale
Reasons for selecting this type of architecture
1. Centralization of control: Access, resources and integrity of the data are controlled by
the dedicated server so that a program or unauthorized client cannot damage the system.
This centralization also facilitates task of updating data or other resources (better than the
networks like Peer to Peer)[3].
2. Scalability: Increasing the capacity of clients and servers can be done separately. Any
element can be increased (or enhanced) at any time, or new nodes can be added to the
network. The server can always have spare capacity to handle larger number of clients
3. Easy maintenance: Distribution of roles and responsibilities to several standalone
computers is easy. Servers can be replaced, repaired, upgraded and even moved without users
being affected by the changes. This independence of the changes is also known as
encapsulation.
Tradeoffs for selecting this type of architecture
1. Traffic congestion. When many simultaneous clients send requests to the same server, it
might cause many problems to the server and the performance eventually slows down.

22

4.Data Design
4.1 Data Description
Data captured in the system helps to realize and come up with the conceptual and logical model of
how the system is expected to perform. The data is captured in two phases;
 At subscription of a patient
The data captured under subscription is the patient’s personal information at a point of
subscribing for the system service.
The data includes; first name, last name, telephone number, email, residence, etc.
The data about residence includes district and its specific region/town in which that particular
patient resides. The data includes; name, latitude, longitude and region name.
 During registration as a medical practitioner
As a medical practitioner registers to join a team of doctors registered with the system,
his/her bio data is captured. This includes; first name, last name,
place of work and other qualification details.

23

4.1.1 Conceptual model

Id(PK)
districtId(FK) Patient MedicalPractitioner Id(PK)
specialtyId(FK)
administratorId(FK) Administrator Id(PK) User firstName
lastName
email
telephoneNo
gender
dateOfBirth
password MedicalQuery queryId(PK)
patientId(FK)
description
tagId(FK)
starId(FK) Tag tagId(PK)
name
specialtyId(FK) specialty id(PK)
Name
adminId(FK) star id(PK)
award district id(PK)
name
longitude
latitude region id(PK)
name
districtId(FK) MedicalResponse responseId(PK)
medicalPractitionerId(FK)
queryId(FK)
response
responseDate vote voteId(PK)
medicalPractitionerId(FK)
responseId(FK)
name
dateVoted Unit unitId(PK)
medicalPractitionerId(FK)
name
dateCreated Event eventId(PK)
unitId(FK)
name Follower followerId(PK)
name
unitId(FK) Comment commentId(PK)
medicalPractitionerId(FK)
description
dateCommented wallet walletId(PK)
transactionType
amount
patientId(FK) provides 1--* 1--1 residesIn isDividedInto isHeldBy makes isAwarded
To isAttachedTo belongsTo subscribesTo avails isAppendedTo canHave contributesTo adds 1--1 1--* 1--* 1--1 1--* 1--1 0--* 1--1 1--* 1--1 1--1 1--* 0--* 1--1 1--* 1--1 1--* 1--1 1--* 1--* 0--1 1--1 1--1 1--* requires 1--* 1--1 a p p r o v e s 1--* 1--1

24

4.1.2 Logical model

Figure 13:ERD for WBDS system

Id(PK)
districtId(FK) Patient MedicalPractitioner Id(PK)
specialtyId(FK)
administratorId(FK) Administrator Id(PK) User firstName
lastName
email
telephoneNo
gender
dateOfBirth
password MedicalQuery queryId(PK)
patientId(FK)
description
tagId(FK)
starId(FK) Tag tagId(PK)
name
specialtyId(FK) specialty id(PK)
Name
adminId(FK) star id(PK)
award district id(PK)
name
longitude
latitude region id(PK)
name
districtId(FK) MedicalResponse responseId(PK)
medicalPractitionerId(FK)
queryId(FK)
response
responseDate vote voteId(PK)
medicalPractitionerId(FK)
responseId(FK)
name
dateVoted Unit unitId(PK)
medicalPractitionerId(FK)
name
dateCreated Event eventId(PK)
unitId(FK)
name Follower followerId(PK)
name
unitId(FK) Comment commentId(PK)
medicalPractitionerId(FK)
description
dateCommented wallet walletId(PK)
name
transactionType
patientId(FK) provides 1--* 1--1 residesIn isDividedInto isHeldBy makes isAwarded
To belongsTo subscribesTo avails isAppendedTo canHave contributesTo adds 1--1 1--* 1--* 1--1 1--* 1--1 0--* 1--1 1--* 1--1 1--1 0--* 0--* 1--1 1--* 1--1 1--* 1--1 0--1 1--1 1--1 1--* requires 1--* 1--1 1--* 1--1 queryTag id(PK)
queryId(FK)
tagId(FK) 1--* 1--1 isPinned 1--1 1--1 isFrom a p p r o v e s 1--* 1--1

25

4.1.3 Physical design
The physical design of the database is the transformation of the fully normalized basic
database tables into tables in MySQL database engine. The design is implemented to ensure
the performance of the system is as noted in the SRS and SDD by use of foreign keys and
alternate keys that ease referencing data between tables in relationship and also easy access
of data by use of primary key column to search from the tables in the database.
Administrator (Idd INT 5 NOT NULL,
firstName VARCHAR 30 NOT NULL,
lastName VARCHAR 30 NOT NULL,
email VARCHAR 30 NOT NULL UNIQUE,
telephoneNo VARCHAR 30 NOT NULL UNIQUE,
gender CHAR 2 NOT NULL,
password VARCHAR 255 NOT NULL,
dateOfBirth DATE NOT NULL,
createdAt DATE CURRENT_DATE)
Primary Key id

District (id INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
latitude VARCHAR 30 NOT NULL,
longitude VARCHAR 30 NOT NULL)
Primary Key id

Region (id INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
districtId INT 5 NOT NULL)
Primary Key id
Foreign Key(districtId) References district(id)

Patient (id INT 5 NOT NULL,
firstName VARCHAR 30 NOT NULL,
lastName VARCHAR 30 NOT NULL,

26

email VARCHAR 30 NOT NULL UNIQUE,
telephoneNo VARCHAR 30 NOT NULL UNIQUE,
gender CHAR 2 NOT NULL,
password VARCHAR 255 NOT NULL,
dateOfBirth DATE NOT NULL,
districtId INT 5 NOT NULL,
createdAt DATE CURRENT_DATE)
Primary Key id
Foreign Key districtId References district (id)

Specialty (id INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
administratorId INT 5 NOT NULL)
Primary Key id
Foreign Key administratorId References administrator (Id)

MedicalPractitioner (id INT 5 NOT NULL,
firstName VARCHAR 30 NOT NULL,
lastName VARCHAR 30 NOT NULL,
email VARCHAR 30 NOT NULL UNIQUE,
telephoneNo VARCHAR 30 NOT NULL UNIQUE,
gender CHAR 2 NOT NULL,
password VARCHAR 255 NOT NULL,
specialtyId INT 5 NOT NULL,
administratorId INT 5 NOT NULL,
dateOfBirth DATE NOT NULL,
createdAt DATE CURRENT_DATE )
Primary Key id
Foreign Key specialtyId References Specialty (id)
Foreign Key administratorId References Administrator (Id)
Tag (tagId INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,

27

specialtyId INT 5 NOT NULL)
Primary Key tagId
Foreign Key specialtyId References Specialty(id)
Star (id INT 5 NOT NULL,
Award INT 5 NOT NULL)
Primary Key id

MedicalQuery (queryId INT 5 NOT NULL,
patientId INT 5 NOT NULL,
description TEXT NOT NULL,
tagId INT 5 NOT NULL,
starId INT 5 NOT NULL)
Primary Key queryId
Foreign Key(tagId) References Tag(tagId)
Foreign Key(starId) References Star (Id)
Foreign Key(patientId) References Patient(id)

MedicalResponse (responseId INT 5 NOT NULL,
medicalPractitionerId INT 5 NOT NULL,
queryId INT 5 NOT NULL,
response TEXT NOT NULL,
responseDate DATE CURRENT_DATE)
Primary Key responseId
Foreign Key(medicalPractitionerId) References MedicalPractitioner(id)
Foreign Key(queryId) References MedicalQuery(queryId)

Comment (commentId INT 5 NOT NULL,
description TEXT NOT NULL,
medicalPractitionerId INT 5 NOT NULL,
dateCommented DATE CURRENT_DATE)
Primary Key commentId
Foreign Key(medicalPractitionerId) References MedicalPractitioner(id)

28

Vote (voteId INT 5 NOT NULL,
Vote_name VARCHAR 4 NOT NULL,
medicalPractitionerId INT 5 NOT NULL,
responseId INT 5 NOT NULL,
date_created DATE CURRENT_DATE)
Primary Key voteId
Foreign Key medicalPractitionerId References MedicalPractitioner(id)
Foreign Key responseId 5 References MedicalResponse(responseId)

Wallet (walletId INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
transactionType VARCHAR 10 NOT NULL,
patientId INT 5 NOT NULL)
Primary Key walletId
Foreign Key(patientId) References Patient(id)

Unit (unitId INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
medicalPractitionerId INT 5 NOT NULL,
dateCreated DATE CURRENT_DATE)
Primary Key unitId
Foreign Key medicalPractitionerId References MedicalPractitioner(id)

Event (eventId INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
unitId INT 5 NOT NULL)
Primary Key eventId
Foreign Key unitId References Unit(unitId)
Follower (followerId INT 5 NOT NULL,
name VARCHAR 30 NOT NULL,
unitId INT 5 NOT NULL)
Primary Key followerId

29

Foreign Key unitId References Unit(unitId)
5.Component design
Table 13:Component design
Class Name: User
register():using PC Method Description
The method is used to allow new patients and medical
practitioners to register with the system using a personal
computer.
Pseudocode
User connects their computer to the internet
User loads the system url into the web browser
System displays the registration interface
If (user is medical practitioner) {
System loads the medical practitioners’ registration
page
}
Else if (user is a patient) {
Load patients’ registration page
}
Class Name: User
login():using PC Method Description
The method is used to authenticate the clients before they
can access the system features by requesting for their
username and password details for the purpose of
validation.
Pseudocode
User connects their computer to the internet
User loads the system url into the web browser
User selects the login option
System loads the Login page
If (user is medical practitioner) {

30

Medical practitioner enters their username and
password
If valid Username and password
System displays the medical practitioner’s home
page
Else
Error message “wrong username or password”
}
Else if (user is a patient) {
Patient enters their username and password
If valid Username and password
System displays the medical practitioner’s home
page
Else
Error message “wrong username or password
}

Class Name: Patient
submitMedicalEquiry() Method Description
The method is used to enable patients to submit their
medical enquiries to medical practitioners for treatment
suggestions.
Pseudocode
Patient logs into the system
System displays the patients home page
Patient clicks the user queries tab
System displays the medical enquiry submission panel
Patient enters their medical enquiry
He selects a tag to attach to his/her enquiry
Patient clicks submit enquiry
System saves the enquiry

31

If (enquiry saving is successful) {
System displays a pop-pup “Your enquiry has been
successfully submitted, please wait for your feedback
shortly”
}
Else
System displays a pop-pup “Medical enquiry failed,
please try again”

Class Name: Medical Practitioner
viewMedicalEquiry() Method Description
The method is used to enable medical practitioners to
receive medical enquiries sent by a patient(s)
Pseudocode
If (medical practitioner’s session is active) {
System displays the medical practitioner’s dashboard
Medical practitioner clicks the enquiries tab
Medical practitioner views the pending enquiries from
patients
}
Class Name: Medical Practitioner
respondToMedicalEquiry() Method Description
The method is used to enable medical practitioners to
provide a detailed report as a response to the patient’s
medical enquiry
Pseudocode
If (medical practitioner’s session is active) {
Medical practitioner clicks the view medical enquiries
tab
System displays the medical enquiries page
Medical practitioner clicks the respond to enquiry tab

32

System displays the respond to enquiry page
Medical practitioner selects the medical enquiry to
respond to patients’ enquiries.
System displays the widget for inputting the response.
Medical practitioner enters the medical response
Medical practitioner clicks submit
System saves the medical practitioner’s response to an
enquiry
Session is ended
}

Class Name: Medical Practitioner
vetMedicalPractitionerResponse() Method Description
The method is used to enable authorized medical
practitioner’s to thoroughly examine their fellow medical
practitioner’s response for its suitability to the patients’
medical query.
Pseudocode
If (medical practitioner’s session is active) {
System sends a notification to the medical practitioner to
vet for a submitted response towards a patient’s enquiry
Medical practitioner receives a notification pop up to vet
for a particular response from a medical practitioner
Medical practitioner selects either to upvote or downvote
a response
If (medical practitioner selected an upvote) {
System increments the medical practitioner’s
(contributor to a response) reward value
}
Else if (medical practitioner selected a downvote) {
System decrements the medical practitioner’s
(contributor to a response) reward value

33

}
Class Name: Patient
viewMedicalResponse() Method Description
The method is used to enable a patient to view the medical
response that has passed the vetting process and allow a
him/her to take the best action as provided in the received
medical practitioner’s response.
Pseudocode
Patient logs into the system
System notifies the patient with a notification pop-up of a
successful response from a medical practitioner.
Patients clicks the view response button
System displays the panel containing the response to the
patient’s enquiry
Class Name: Admin
manageSpecialty() Method Description
The method is used to enable the administrator to add or
edit a medical specialty in the system.
Pseudocode
Administrator logs into the system
System displays the administrators’ home page
The administrator selects to either add specialty, edit
existing or delete an existing specialty
If (administrator selected add specialty) {
System displays the add specialty page
Admin enters the information about the medical specialty
Admin clicks the register button
System saves the new specialty and pops-up
“Successfully added a new specialty”
}
If (administrator selected edit specialty) {

34

System displays a page containing a list of saved
specialties
Admin selects a specialty to edit
Admin edits the specialty
System displays pop-up “confirm edit specialty”
Admin clicks submit
System saves the edited specialty info and pops-up
“Successfully edited X specialty”
}

Class Name: Admin
approveMedicalPractitionerRequest() Method Description
The method is used to enable the system admin to analyze a
medical practitioner’s registration request ahead of
approval/decline
Pseudocode
Administrator logs into the system
System pop-ups a notification of a new medical
practitioner request
Admin receives the medical practitioner’s request
Admin assesses the medical practitioner’s registration
request
If (the request is valid) {
Admin approves the registration request
}
Else {
Admin declines the registration request
}
Class Name: User
logout() Method Description
The method is used to allow a user to log out of the system
by terminating their session

35

Pseudocode
If (Valid session already established) {
User clicks the logout button
System terminates the users’ session
}

36

6. Human Interface Design
6.1 Overview of user interface
The graphical user interface of the Web Based Diagnosis System shall have 3 panels i.e. patient’s
panel, medical practitioner’s panel and the system administrator panel.
All panels shall have a light weight web layout where all functionalities shall be grouped logically
according to the types of entities, they are associated with i.e. User Queries, Paid consultancy,
Analytics links are the main menu for patients’ side while User Queries, Doctors’ Forum, Health
Units, Paid consultancy and Analytics are the main menu for Medical Practitioners’ side.
Lastly, staff management, specialties management and district Info links are the main menus for
the administrator side.
Some of these menus have submenus that link to different functionalities of the system for example
specialties management has add specialty, list of all specialties and add a tag.
Each of the menu links is manifested as a separate web page for the user. On click of a link, the user
shall be directed to a web page containing detailed information about the link clicked.
When validation errors occur, they shall be displayed in colored text such that the user can
understand that there has been violation of system rules for example in cases of input error, an error
message shall be displayed below that particular input field such that the user can easily recognize
it.
The interfaces foresee the development of the web application using VueJs Framework for building
impressive graphical user interfaces and an html template built using HTML, bootstrap and jQuery.

37

6.2 Screen Images

Figure 14:Patient home page
The interface above is accessed by the patient after logging in order to proceed with various system
functions. The User Queries link on the interface above leads the patient to the page where he/she
can post their medical inquiries. The Paid consultancy link enables the patient to consult a medical

38

practitioner privately after making the payment, Analytics link provides a quick and clear
understanding of system information in form of data visualizations.

Figure 15:Medical practitioner's home page
The interface shall be accessed by the medical practitioners on their successful login. The user
queries link enables a medical practitioner to view and respond to medical inquiries sent by patients.
The doctor’s forum shall be used by the medical practitioner to share important information with
fellow doctors on the platform.
Paid consultancy is where the medical practitioner accesses the medical inquiries sent with an aim
of privately attending to them. The Analytics link provides a quick and clear understanding of
system information in form of data visualizations.

39

Figure 16:Administrator Panel
This interface is used by the system administrator to manage the entire system information such as
approving medical practitioner requests, adding new specialties to the system ,etc.HOME STAFF MANAGEMENT Doctors' Info SPECIALTIES MANAGEMENT specialties Greetings GENERAL INFO Pending Requests Total Users Denied Requests Registered Doctors Content display

40

7.Requirements Matrix
Table 14:Requirements traceability matrix
REQUIREMENTS TRACEABILITY MATRIX
Business
Requirement Id
Business Requirement
use case
Functional
Requirement
Id
Functional
Requirement/Use
case
Priority
BR001 Register FR001 Register Medical
practitioner
High
FR002 Register Patient High
FR003 Register health center High
BR002 Send medical enquiry FR004 Deliver a medical
enquiry from a patient
to a medical
practitioner
High
BR003 Assign medical enquiry FR005 Assign medical
enquiry to a medical
practitioner
High

BR004

Respond to medical
enquiry
FR006 Deliver a response
about a medical
enquiry to the patient
High
BR006 Add specialty FR008 Addition of a medical
category or
department
Low
BR008 Analyze FR0010 Analyze the system
information and
provide meaningful
feedback/conclusion
High

41

System implementation, testing and validation report for Mobile Based
Diagnosis System

Document No: 1
Prepared by: BSE19-15
Date: 5/30/2019
Version: 1.0

42

Document Approval

Name Role Date Signature
NANSUBUGA JOYCE
EUZEBIA
Software developer,
Database designer, Systems
Analyst
Wednesday, May 29,
2019

ODOCH ROBERT
Software developer,
Database designer, Systems
Tester
Wednesday, May 29,
2019

BWAYO JUDE
Systems tester, Architectural
designer, Systems Analyst
Wednesday, May 29,
2019

NABIKOLO SHIBA
Systems tester, Architectural
designer, Systems Analyst
Wednesday, May 29,
2019

43

Table of Contents
List of tables .................................................................................................................................. 45
List of Figures ............................................................................................................................... 46
Chapter one: Introduction ............................................................................................................. 47
1.1Background and Scope of the Project .................................................................................. 47
1.2 Overview of the System ...................................................................................................... 48
1.3 Overview of the document .................................................................................................. 48
Chapter two: System Specifications ............................................................................................. 50
2.1 Version of requirements and version control ...................................................................... 50
2.2 Input .................................................................................................................................... 51
2.3 Output .................................................................................................................................. 52
2.4 Functionality........................................................................................................................ 53
2.5 Limitations and safety ......................................................................................................... 54
2.6 Default settings .................................................................................................................... 54
2.7 Special requirements ........................................................................................................... 54
2.8 Errors and Alarms ............................................................................................................... 55
Chapter three: Design output ........................................................................................................ 56
3.1 Implementation.................................................................................................................... 56
3.1.1 Development tools ........................................................................................................ 56
3.2 Design Inputs and Outputs .................................................................................................. 56
3.4 Documentation .................................................................................................................... 57
3.4.1 Design output checklist ................................................................................................ 57
3.5 Design changes .................................................................................................................... 58
3.6 Design change evaluation.................................................................................................... 58
Chapter 4: Inspection and testing .................................................................................................. 59
4.1 Introduction ......................................................................................................................... 59
4.2 Test plan and Performance .................................................................................................. 62
4.2.1 Test Objectives ............................................................................................................. 62

44

4.2.2 Scope and Relevance of the tests .................................................................................. 63
4.2.3 Levels of the tests. ........................................................................................................ 63
4.2.4 Types of tests ................................................................................................................ 64
4.2.5 Sequence of tests .......................................................................................................... 64
4.2.6 Configuration Test ........................................................................................................ 72
4.3 Precautions .......................................................................................................................... 72
4.3.1Anormalous Conditions ................................................................................................. 72
4.3.2 Precautions to Anomalous conditions .......................................................................... 72
Chapter five: Installation and System acceptance test .................................................................. 73
5.1 Input files............................................................................................................................. 73
5.2 Supplementary files ............................................................................................................. 73
5.3 Installation Qualification ..................................................................................................... 73
Chapter six: Performance, servicing, maintenance and phase-out ............................................... 76
6.1 Service and Maintenance .................................................................................................... 76
6.2 Performance and Maintenance ............................................................................................ 76
Chapter Seven: Conclusion and Recommendation ....................................................................... 78
Appendix A: Patient User Manual ................................................................................................ 79
Appendix B: Medical Practitioner User Manual .......................................................................... 86
Appendix C: Admin User Manual ................................................................................................ 92

45

List of tables
Table 14:Version of requirements and version control................................................................. 50
Table 15:Design output checklist.................................................................................................. 57
Table 16:Inspection plan and performance ................................................................................... 59
Table 17:Test Case1 ...................................................................................................................... 64
Table 18:Test Procedure1 ............................................................................................................. 64
Table 19:Test Case2 ...................................................................................................................... 65
Table 20:Test Procedure2 ............................................................................................................. 65
Table 21:Test Case3 ...................................................................................................................... 66
Table 22:Test Procedure3 ............................................................................................................. 66
Table 23:Test Case4 ...................................................................................................................... 66
Table 24:Test Procedure4 ............................................................................................................. 66
Table 25:Test Case5 ...................................................................................................................... 67
Table 26:Test Procedure5 ............................................................................................................. 67
Table 27:Test Case7 ...................................................................................................................... 68
Table 28:Test Procedure7 ............................................................................................................. 68
Table 29:Test Case8 ...................................................................................................................... 69
Table 30:Test Procedure8 ............................................................................................................. 69
Table 31:Test Case9 ...................................................................................................................... 70
Table 32:Test Procedure9 ............................................................................................................. 70
Table 33:Test Case10 .................................................................................................................... 70
Table 34:Test Procedure10 ........................................................................................................... 71
Table 35:Test Case11 .................................................................................................................... 71
Table 36:Test Procedure11 ........................................................................................................... 71
Table 37:Checklist of the Installation and system acceptance test ............................................... 74
Table 38:Installation Procedure Check ......................................................................................... 74
Table 39:Performance and maintenance details checklist ............................................................ 76
Table 40:Final Approval ............................................................................................................... 99

46

List of Figures
Figure 1:Step 1 of user registration ............................................................................................... 79
Figure 2:Step 2 of user registration ............................................................................................... 80
Figure 3:User sign In .................................................................................................................... 80
Figure 4:Medical inquiry .............................................................................................................. 81
Figure 5:Enter medical inquiry ..................................................................................................... 82
Figure 6:Paid Consultancy ............................................................................................................ 83
Figure 7:Pay Consultation Fee ...................................................................................................... 83
Figure 8:Successful payment for consultancy .............................................................................. 84
Figure 9:Consult doctor ................................................................................................................ 84
Figure 10:View Medical response ................................................................................................ 85
Figure 11:View patient's queries ................................................................................................... 86
Figure 12:Respond to patient's queries ......................................................................................... 87
Figure 13:Create health event ....................................................................................................... 87
Figure 14:Save medical event ....................................................................................................... 88
Figure 15:Add Doctor to Medical event ....................................................................................... 88
Figure 16:Add doctor details ........................................................................................................ 89
Figure 17:Discussion forum .......................................................................................................... 90
Figure 18:System analytics View ................................................................................................. 91
Figure 19:Admin Login ................................................................................................................ 92
Figure 20:Overview of the admin interface .................................................................................. 93
Figure 21:Approve new Medical Practitioner ............................................................................... 94
Figure 22:Add Specialty tag ......................................................................................................... 95
Figure 23:List of all specialties ..................................................................................................... 96
Figure 24:General System Info ..................................................................................................... 96
Figure 25:View registered health units ......................................................................................... 97
Figure 26:Record new district ....................................................................................................... 98
Figure 27:Register District ............................................................................................................ 98

47

Chapter one: Introduction
1.1Background and Scope of the Project
Due to a high cost involved in consulting a medical doctor, many Ugandans have resorted to self-
medication, something that could put their lives in danger. According to Dr. Ivan Kabuye a general
practitioner at the International Hospital Kampala, he says many Ugandans are self-medicating
especially on anti-malarial, pain killers and skin lightening creams for women. He further explains
that when one experiences body pains, it is a communication that something is wrong and doing
self-medication could mean over or under treating self, treating something that one is not certain
of and delay in seeking right treatment increases the burden of the disease and increases chances
of death for illnesses like cancer. According to the research conducted in one of the hospitals in
Kampala, Mulago General hospital where 50 questionnaires were distributed and 45 received from
the respondents (patients and medical practitioners). For the 35 questionnaires received from
patients, the information collected showed that a few individuals who manage to make it to
hospitals find long queues of other patients waiting to be attended to. As a result, a patient must
wait until it’s their turn to be worked on by the doctor in charge and this is a wastage of time.
While others explained that they get frustrated over the missed appointments they had scheduled
with medical specialists due to their unavailability at their designated places of work.
Due to the problem stated above, Group BSE 19-15 proposed a web-based diagnosis system which
is a web-based platform. The system shall prompt a patient to enter his or her signs and symptoms,
select a tag that shall be attached to his/her enquiry before submission. From this tag attached to
the enquiry, the system shall be able to automatically assign the enquiry to all medical practitioners
that match the tag attached.
The corresponding medical practitioners shall read through the patient’s enquiry and provide their
medical knowledge in form of a response as a solution to the patient’s medical enquiry.
A medical response once provided by a medical practitioner shall pass through a vetting process
where fellow practitioners shall decide to either up vote or down vote it to show the patient the
most relevant answer.

48

1.2 Overview of the System
The system is developed for use by patients and medical practitioners within and around Kampala.
The system accepts input from patients in form of signs and symptoms, then it automatically sends
the provided input to each of the medical practitioners that fall in the specialty in which the enquiry
is made, it provides feedback to the patient which includes the suggested treatment for the possible
illness that has been diagnosed and agreed upon by the medical practitioners using the signs and
symptoms provided by the patient as a result.
1.3 Overview of the document
The document describes the implementation, testing and validation findings for the Web Based
Diagnosis System. The document is further divided into the following major sections:
Section 1: Background and Scope of the Project
The section describes the background and the scope of the system in detail while specifying its
functions. This section also gives an overview of the document.
Section 2: System Specifications
This section describes the features and behavior of the system as a basis for the validation process.
It entails the following sub sections; version of requirements and version control, System inputs,
System outputs, System functionalities, System limitations and safety, System default settings,
Special requirements, errors and alarm sections.
Section 3: Design Output
The section provides a full description of the design and implementation process of the system by
clearly highlighting the platforms used and the devices used during the system implementation.
The result from this section is an approved and accepted program for the inspection and testing
phase.
Section 4: Inspection and Testing
This section provides inspection and test plan for the system and documentation of the test plan. It
also contains the requirements compliance with the testing, the acceptance test specification, the
approach, complexity, risks, and the intended and expected use of the computer system.

49

Section5: Installation and System acceptance test
The section entails the validation of the installation process to ensure that system components are
properly installed on a host system such that the user achieves a safe and complete installation of
the system
Section 6: Performance, Servicing, maintenance and phase out
This section contains descriptions of Performance, servicing, maintenance, and phase out stages.
In this phase the computer system is in use and subject to the requirements for service,
maintenance, performance, and support. This phase is where all activities during performance
reside and where decisions about changes, upgrades, revalidation, and phase out are made.
Section 7: Conclusion and Recommendations
This section provides a summary of the project and also contains remarks and recommendations
to make the system more functional and better.

50

Chapter two: System Specifications
The requirements describe and specify the system requirements as a basis for the development and
validation process. The acceptance test specification specifies the tests to be conducted to verify
that the system is working correctly. It provides a plan describing, what to test and how to test, the
details for each test scenario, the test data to be used and the expected results.
2.1 Version of requirements and version control
The requirements of the Web Based Diagnosis System underwent through a series of validations,
verification checks and approvals to guide the team in achieving a proper implementation strategy.
The changes in the versions of the requirements were done through checks in various requirements
of the Software Requirements Specification Document for remarks and recommendations. These
entailed the following:
Table 15:Version of requirements and version control
Version Requirement Id Description
changes
Author/proposed Date
Version 1.0 First draft of the
Requirements
Specification
Document

Initial SRS
document
BSE19-15 19/10/2018
Version 2.0 System Functions Inclusion of newer
requirements in the
SRS
BSE19-15/Supervisor 26/10/2019
Version 2.1 Product Perspective Detailing of the
product
perspective and
drawing of the data
analysis model
BSE19-15/Supervisor 9/11/2019
Version 2.2 Assumptions and
Dependences
Addition of
business rules and
appendices
BSE19-15/Supervisor 11/11/2019

51

Version 3.0 System Name Change of system
name to reflect the
product
perspective
BSE19-15/Supervisor 12/11/2019

2.2 Input
The system requires several sets of inputs to render its operations and functionality, of which the
most important ones are provided during the subscription for the Web Based Diagnosis System,
these inputs include:
Username and Password
These are needed for the system user to access a full set of the system functionalities. The Admin
panel, patient’s panel and Medical practitioner’s panel all require a login by entering of the
corresponding username and password which are recorded during the registration process prior to
access the features of the system.
In case of a wrong password, the system user is notified to try again or change the password if
necessary.
Signs and Symptoms
This is an input that is entered by patient as a description of their feeling about a particular illness.
It is sent by the patient to the medical practitioner who analyses it and provides preliminary
diagnosis as feedback to the patient.
Tag
This input is selected by a patient and attached to the signs and symptoms provided in the
description. Tags basically imply various parts of the body where the illness occurred. From this
tag attached on an enquiry, the system is able to determine which medical specialists the enquiry
is to be addressed to. For example if the tag is teeth, the system easily determines that the enquiry
is to be sent to dentists registered with the system.
District
This points to the district where a system user (patient, medical practitioner) is currently located
to aid in the analysis process of patient medical enquiries to infer more meaningful and helpful

52

information to the health sector and other Non-Government organisations that may need to make
use of the collected data.
Age
This input is specified by patients to determine their age brackets during the preliminary diagnosis
process. The age is also used as a determinative criterion during the analysis process of patient’s
medical diagnosis info.
Gender
This input is entered by the patient to generally help in the preliminary diagnosis to select the most
likely illness a patient may be suffering from.
Phone number
It is an input specified by both the patients and medical practitioners as a contact reference during
the preliminary medical diagnosis and other proceedings that follow.
Health Center
It is registered by the system administrator as medical unit to which patients can be referred after
the preliminary diagnosis process is complete.
2.3 Output
Registration forms
This is a form on which patients and medical personnel can register in order to access the system
functions. On the patient registration panel, an account is created for the patient instantly while on
the medical practitioner’s panel, the registration details of the medical practitioner are sent as a
request to system administrator for verification /approval.
Preliminary Medical diagnosis response
This represents the diagnosis information sent by system to the patient as a response from the
medical practitioners to the medical enquiry. This response contains preliminary diagnosis findings
and helpful procedures to follow in tackling a particular illness.
Data analytics
This is the output that shows different perspectives of the medical diagnosis information to
discover hidden meaningful patterns. It also shows the general performance of the medical
practitioners.

53

Medical practitioner approval
This is an interface where the systems administrator views a list of new medical practitioner
registration requests and decides whether to approve or disapprove depending on the registration
details provided.
Add health unit form
This is an output that displays an interface to an administrator to add a new health unit to the
system.
2.4 Functionality
1) Send Medical inquiry
It enables patients to send medical inquiries to medical practitioners who can reply to them with a
preliminary diagnosis feedback free of charge.
2) Paid Medical Consultancy
It is an advanced version of the Send Medical inquiry functionality except that the interaction is
held between only two parties i.e. the patient and the Medical practitioner, the patient is liable to
pay a consultation fee of 10000 before they can start interacting with the medical practitioner.
3) Doctors’ Forum
It provides an interactive platform for Medical practitioners to open up important medical research
discussions with fellow medical practitioners to expand their knowledge on how to best approach
certain medical situations.
4) Health Units
It allows the system admin to create health units within which medical practitioners can
manage their patient medical inquiries and also create medical based health events.
5) Analytics
It shows a more understandable summary of the system activities that can be used to discover
meaningful patterns with the system data and categorizes them into more meaningful
information. The functionality helps system users to draw conclusions easily in regards to
system’s daily processes.
6) Medical wallet
It enables users to deposit money to their medical accounts that they can later use to make
Medical consultations.

54

2.5 Limitations and safety
The system shall be accessed remotely via a stable internet connection, therefore lack of internet
shall limit the user from accessing the system’s services.
The system is tested using specified versions of php (5.4.16) and below, MySQL 5.6.12, apache
2.4.4, google chrome, safari and Firefox, therefore higher versions of the development tools may
cause unexpected behaviors which can be a limitation to the system.
There exist different types of roles a system user shall take on which shall determine the
functionalities they can perform on the system. For example, the systems administrator has higher
privileges to certain functionalities such as approve new medical practitioner, add new health unit,
add specialty among others.
The system shall require users to have the basic computer literacy knowledge in order to interact
with the functions provided by the system efficiently.
The system’s major functionalities shall strictly be available to logged in users basing on the type
of roles that they have been allocated.
2.6 Default settings
After power-up of a computer connected to the internet, assuming that there’s an installed
supported web browser as stated in the SDD, the following proceedings are supported;
1) The web browser is launched and then the system is loaded using the system’s http server
domain address.
2) A user is required to register with the system and login to access its functionalities.
2.7 Special requirements
The system is committed to keeping the security, confidentiality and security of the user’s
authentication details through the use of two-way authentication with the help of hash functions.
The system has been developed with exceptional handlers that provide users with notifications to
do away with any errors encountered.
There are limitations on to system data access by use of access control roles that prescribe what
data a particular system user should access.
The system has been designed with the interface logic totally separated from the backend logic
which decouples the system view from the backend and therefore rendering it more reusable.

55

2.8 Errors and Alarms
As far as software development is concerned, no software system can be hundred percent error
free but the percentage of errors can be reduced to a minimal level that can be tolerated by the
users.
The possible errors of the system include:
Invalid login credentials
This error may be caused by entering of invalid login credentials by the system users during the
login process into the system or when the user is registering the system. The error can be handled
by requesting the system user to re-enter the login details again.
Absolute limit error
This error may arise as a result of the user entering more information than required i.e. if the patient
enters text-information into a form field describing his/her medical illness with values exceeding
the acceptable maximum limit.
Do you want to approve the medical practitioner?
The alarm is popped up on the administrator’s panel when an administrator clicks the approve
button upon accepting a request for a new medical practitioner.
Are you aware that paid consultancy is paid for?
The alarm is presented to the patients upon their attempt to access the paid medical consultancy
service of the system.

56

Chapter three: Design output
3.1 Implementation
3.1.1 Development tools
The software was majorly developed using the following tools:
Back end
Xampp 3.2.2 that contains php version 7.2.7, apache server 2.4.3 and MySQL 5.0.12. To quicken
the development process, the Laravel MVC framework was used which separated the system
components into the model, view and controller which decoupled the implementation components
of the system and thus made development more dynamic.
The object-oriented development paradigm was applied to design and implement this software
since object-oriented php was used to implement the software and object-oriented features such as
inheritance, abstraction, and encapsulation were used in the design.
Front End
A vueJs front end framework was used for developing the views (interfaces) of the system along
with vuetify as the styling script. The front end framework was used to ease the designing of
interfaces and to make them more attractive.
Development environment
Visual Studio Code was used as the main development environment along with node Js and npm
packages which were installed on a computer that had 4gb of RAM, 500GB hard disk storage and
2.7ghz processor.
Hardware and Software Operating environment
The system can be deployed for use on any computer with minimum requirements of 1GB of
RAM, 5GB hard disk and a processing speed of 2ghz for it to run conveniently. The system can
further run on a smart phone possessing a web browser a running internet connection.
3.2 Design Inputs and Outputs
The system inputs are captured majorly using form inputs when using the software. The forms are
designed with patterns and placeholders in such a way that the system users can easily infer their
intent.

57

3.4 Documentation
3.4.1 Design output checklist
Table 16:Design output checklist
Topics Design output
Good programming
practice
Source code is... Modulized
Encapsulated
Functionally divided
Strictly compiled
Fail-safe (handling errors)

Source code contains... Revision notes
Comments
Meaningfull names
Readable source code
Printable source code

Windows programming
Interface implemented using standard Windows elements
Interface implemented using self-developed Windows elements
Application manages single/multiple running instances

Comments:
Dynamic testing
All statements have been executed at least once
All functions have been executed at least once
All case segments have been executed at least once
All loops have been executed to their boundaries
Some parts were not subject to dynamic test

Comments:

58

3.5 Design changes
The Mobile App version of the application is not implemented due to a time constraint but
has been considered as a priority future prospect ahead of a running web version of the
system.
3.6 Design change evaluation
There are no functional impacts of the changes since the android version of the application
would deliver the same functionality as the web based end, but for the purpose of user
convenience, the Android version of the system will be greatly helpful in the future.

59

Chapter 4: Inspection and testing
4.1 Introduction
The purpose of inspecting and testing software system is to evaluate the functionalities of the
developed software with an intent to find whether it met the specified requirements or not and to
identify the defects to ensure that the product is defect free in order to produce a quality software
product.
Table 17:Inspection plan and performance
Topics Inspection plan and performance Date / Initials
Design output
Program coding structure and source code
Evidence of good programming practice
Design verification and documented reviews
Change-control reviews and reports

Comments:
The outputs of the design were inspected for
consistency with the design requirements,
error detection and recovery, thus rendering
them ready for testing. Testing was done
starting from earlier processes of design and
implementation to ease the unit testing
processes and integration testing.
4/04/2019
The Software product modules were
inspected using walk troughs to ensure
that they obey the SOLID design
principles.
Members
Bwayo Jude
Odoch Robert

4/04/2019
The system implementation was
reviewed to check its consistency with
the design.
Members
Nansubuga Joyce Euzebia
Bwayo Jude
Odoch Robert

60

Topics Inspection plan and performance Date / Initials
4/09/2019
The Adequacy of the system
requirements, the change of
requirements was revised and
commiserated by the BSE19-15
together with its supervisor.

5/27/2019
The SDD and the report were
reviewed and approved by the
supervisor before submission.
By: Dr. Joab Ezra Agaba

Documentation System documentation, flow charts, etc.
Test results
User manuals, On-line help, Notes, etc.
Contents of user manuals approved

Comments:
The system documentations were inspected
thoroughly to ensure that they sequentially
relate to each other and follow the IEEE
documentation standards.
28/05/2019
The System documentation ranging
from the project concept paper to the
report were reviewed repeatedly to
ensure that they follow the IEEE
software documentation standards.
Members
Bwayo Jude
Nansubuga Joyce Euzebia
Odoch Robert
Nabikolo Shiba

61

Topics Inspection plan and performance Date / Initials
28/05/2019
The test results from the system were
compared with test case results to
ensure consistency in system
modifications.
Members
Bwayo Jude
Nansubuga Joyce Euzebia
Odoch Robert
Nabikolo Shiba

Software
development
environment
Data integrity
File storage
Access rights
Code protection
Installation kit, replication and distribution

Comments: The system development process
were inspected to ensure use of the data
orientation principles such as encapsulation,
abstraction, inheritance and polymorphism.
28/05/2019
The system design and
implementation were checked to
ensure that they satisfy all the data
integrity requirements expected out of
the product.
Members
Bwayo Jude
Nansubuga Joyce Euzebia
Odoch Robert
Nabikolo Shiba

62

Topics Inspection plan and performance Date / Initials
29/05/2019
Inspection for use of Role based
access controls was done to review
how access rights were distributed
amongst the system users.
Members
Bwayo Jude
Nansubuga Joyce Euzebia
Odoch Robert
Nabikolo Shiba
Result of inspection
Inspection approved

Comments:
30/05/2019
The system inspection plan was
submitted for approval to the
supervisor for review.
By: Dr. Joab Ezra Agaba

4.2 Test plan and Performance
4.2.1 Test Objectives
The system consists of different modules which perform different functions when called. The
major intent of testing these system modules was to find out the defects which would arise from
the system requirements, design or implementation phases of the software development and fix
them before the software would be deployed into production for use.
The software compatibility was carried out to confirm the operating systems on which it would
run, the hardware types it would support and the types of browsers suitable to run it.
Performance testing and load testing were carried out to make sure that the system is reliable and
does not crash in case of any data limit violations but instead provide helpful guidelines on how to
handle the processing issue.

63

Boundary value testing was carried out onto the system’s numerical inputs to check the flexibility
of the system to maximum and minimum data violations by user value inputs.
4.2.2 Scope and Relevance of the tests
The software testing was applied onto all modules of the system in-line with their functionalities.
This followed creating suitable test cases that were relevant for evaluating them. The tests were
performed while prioritizing functional features which are often used by the system stakeholders
and required functioning by law, thereafter the test results were communicated to the system users
with a guarantee that the system was functional. Any insecure aspects during the testing were
resolved accordingly.
4.2.3 Levels of the tests.
The system testing was carried out in phases starting with the unit /modular testing phase,
integration testing phase, system testing phase, user acceptance testing phase.
1. Unit testing phase
This involved testing each part of the software by checking to ensure that each component
fulfilled its functionality. The modules that were tested included; Login and Registration,
Medical Queries, Medical Consultancy, Data analysis and System administration module.
This was help to easy the identification of defects and fix them at lower levels of
development.

2. Integration testing.
The different independent modules were combined and tested as a whole to ensure efficient
data flow from one module to another, this prepared the system for System testing. The
major aim was to ensure that the subsystems (system components) constituting the software
product work as expected and work together in a streamlined manner.
3. System testing
System testing was performed on a complete, integrated system to check for the system’s
compliance with the requirements and check for the overall interaction of the integrated
components. Its where the load, performance and security testing were performed.
4. System acceptance testing

64

The system as a whole was tested to check if the requirements of the system design were
met by the implementation. This was intended to ensure that the software product works
for the user.
4.2.4 Types of tests
1. Functional tests
The testing was done to evaluate the system against the target business requirements as
specified in the design document. This involved preparing test data according to system’s
business requirement of the system and then tested for specification of functions.
2. Boundary value testing
It involved testing the system input fields with extreme ends or boundaries between
partitions of the system input values. For example, paying a consultancy payment amount
of a value below the acceptable minimum value and above the acceptable maximum value
to check the system’s response to the anomalies.
3. Performance Load testing
The testing was carried out to check the behavior of the system under normal conditions
and at peak conditions. The software was tested by allowing 10 people to access the system
at the same time to check whether it continues to perform satisfactorily.
4.2.5 Sequence of tests
Table 18:Test Case1
Project: WBDS
Test Case1: Login Participant: Patient/Medical Practitioner
Module: Registration and Login
Description Verify Login with valid phone number and password

Table 19:Test Procedure1
Step Test Steps Test data Expected Result
1 Navigate to Login page User is able to Login

65

2 Provide valid phone number Phone
number=0758045678
Credential can be
entered
3 Provide valid password Password=1234 Credential can be
entered
4 Click on Login Button User Logged in
successfully

Table 20:Test Case2
Project: WBDS
Test Case2: Register Participant: Patient/Medical
Practitioner
Module: Registration and Login
Description Receive user registration credentials

Table 21:Test Procedure2
Step Test Steps Test data Expected Result
1 Navigate to Register page Display the Registration
page
2 Provide valid user credentials User
credentials=phone
number, email,
password, age,
location.
Credential can be
entered
4 Click on Register Button User registered
successfully

66

Table 22:Test Case3
Project: WBDS
Test Case3: Send Medical enquiry Participant: Patient
Module: Queries
Description Test the Send Medical enquiry function for the patient
Table 23:Test Procedure3
Step Test Steps Test data Expected Result
1 Navigate to Make medical inquiry page Medical inquiry page is
displayed
2 Enter the details of the Medical inquiry Medical inquiry=”
Signs & symptoms of
a particular illness”.
Medical inquiry details
can be entered
3 Attach tag to medical inquiry Tag attached to the signs
and symptoms
4 Click on the submit Button Medical enquiry
submitted successfully

Table 24:Test Case4
Project: WBDS
Test Case4: Respond to Medical
enquiry
Participant: Medical Practitioner
Module: Queries
Description Test the Respond to Medical enquiry function for the Medical
Practitioner

Table 25:Test Procedure4
Step Test Steps Test data Expected Result

67

1 Click on the queries link to view the
pending medical enquiries
The queries page is
displayed
2 Select one of the pending queries to
respond to.
Display the details of
the selected pending
inquiry
4 Type to enter the details of the
medical response
Medical
response=”important
preliminary medical
diagnosis feedback”
Medical response ready
to be submitted to the
patient.
5 Click the Submit button Medical response
successfully sent to the
patient

Table 26:Test Case5
Project: WBDS
Test Case5: Make medical
consultancy
Participant: Patient
Module: Queries
Description Test the Medical consultancy function for the Patient

Table 27:Test Procedure5
Step Test Steps Test data Expected Result
1 Click on the Paid Consultancy link on
the home page
The Medical consultancy
page opens
2 Select a medical practitioner from the
list of medical consultants displayed
Medical practitioner to
consult can be selected

68

3 Pay the Consultation fee Consultation fee is
successfully deducted
from the patient’s wallet.
4 Type to enter the details of the medical
consultancy
Medical consultancy
=”details related to the
medical consultancy
information”
Medical consultancy
information can be
entered
5 Click the Submit button Medical consultancy
successfully sent to the
medical practitioner

Table 28:Test Case7
Project: WBDS
Test Case7: Approve Medical
Practitioner registration
Participant: Systems Admin
Module: Administration Management module
Description Test the Approve medical practitioner registration functionality

Table 29:Test Procedure7
Step Test Steps Test data Expected Result
1. Navigate to the admin Login page Display admin login
page

69

2. Login into the System as an
administrator with valid email and
password
Valid email and
password
Successfully Logged in
as an Admin
3. Click on the medical practitioner
approvals to view which medical
practitioner requests to
approve/decline
A list of pending
medical practitioner
registrations is
displayed.
4. Select to review the medical
practitioner registrations one after
the other
Medical practitioner
approval qualification
constraints.
Medical practitioner
registration details are
displayed.

5. Click approve/Decline to confirm the
Medical practitioner’s registration
Medical practitioner
registration Accepted or
declined.

Table 30:Test Case8
Project: WBDS
Test Case8: Add Health Center Participant: Systems Admin
Module: Administrator
Description Test the Add health center functionality

Table 31:Test Procedure8
Step Test Steps Test data Expected Result
1. Navigate to the add
health center page
Display of the add
health center page
2. Type to enter the
details of the new
Valid health center
name, location,
Allow the entering of
the Health center details

70

health Health center
to the system
latitude and longitude
details
3. Click on the register
Button
A new health center
added successfully

Table 32:Test Case9
Project: WBDS
Test Case9: Add Medical
Specialty
Participant: Systems Admin
Module: Administrator
Description Test the Add specialty functionality

Table 33:Test Procedure9
Step Test Steps Test data Expected Result
1) Navigate to the add
Specialty page
Display of the add
Specialty page
2) Type to enter the
details of the new
Medical Specialty to
the system
Valid Medical
Specialty name,
Description of the
Medical Specialty.
Allow the entering of
the new Medical
Specialty details
3) Click on the register
Button
A new Medical
Specialty successfully
added

Table 34:Test Case10
Project: WBDS
Test Case10: Add specialty Tag Participant: Systems Admin
Module: Administrator

71

Description Test the Add specialty Tag functionality

Table 35:Test Procedure10
Step Test Steps Test data Expected Result
1. Navigate to the add specialty Tag Display of the add
specialty page
2. Select the specialty to which the
Tag is attributed
List of registered
Specialties
Allow selection of
Specialty
3. Enter the details attributed to the
new Specialty
Valid Tag name,
Description of the Tag
Allow entering of the
Tag details
4. Click the register button Tag successfully added

Table 36:Test Case11
Project: WBDS
Test Case11: Register Health Event Participant: Systems Admin
Module: Administrator
Description Test the Register health Event functionality

Table 37:Test Procedure11
Step Test Steps Test data Expected Result
1. Navigate to the Register Health
Event page
Display of the Register
Health Event Page
2. Type to enter the health Event
details
Valid Health Event
Name
Allow the addition of
the Health Event details
3. Select the Health Unit to allocate
the Event
List of Registered
Health units
Allow selection of a
health unit for the Event
4. Click the register Health Event
Button
Health Event
Successfully registered

72

4.2.6 Configuration Test
The system was tested to confirm that it operates on any operating system and is compatible with
multiple browsers such as google chrome, Microsoft Edge and Fire Fox to ensure that the system
delivers the intended functionality.
4.3 Precautions
4.3.1Anormalous Conditions
When the system is being run on the local server, some system interface icons may not load due
to lack of stable internet connection. This occurs because some components of the vuejs interface
framework are fetched from the vuejs server during system loading.
4.3.2 Precautions to Anomalous conditions
The failure to load system interface icons is solved easily by ensuring a stable internet connection
on the local device onto which the system is installed.

73

Chapter five: Installation and System acceptance test
5.1 Input files
When installing the system, the user should create a database and edit the following file
and provide the right configuration values for the different entries.
env.php file
It contains configurations that the framework uses to perform actions like connecting to the
database, sending emails among others.
5.2 Supplementary files
The system should have the following additional files before it can be installed for use by
the target users. The supplementary files include;
1. README (md file)
2. Patient and Medical Practitioner User Manual (pdf file)
3. Admin User Manual (pdf file)
5.3 Installation Qualification
Installation Steps
Provided no files in the system directory have not been tampered with, the following procedure is
followed to install the system;
1. Open the project directory
2. Navigate to the env.php file and change its default parameters to the specific host
parameters in order to meet the standard set by the hosting provider. These parameters
include:
$host=”localhost”
$user=”root”
$password=” ”
$database=”fyp_api”
3. Ensure the presence of the .htaccess file in the project directory

74

Table 38:Checklist of the Installation and system acceptance test
Topics Installation summary
Installation method
Automatic - installation kit located on the installation media
Manual - Copy & Paste from the installation media

Comments:
Installation media
Diskette(s)
CD-ROM
Source disk folder (PC or network)
Download from the Internet

Comments:
Installed files

Php files
Css files
Javascript files
Vue files

Table 39:Installation Procedure Check
Topics Installation procedure Date / Initials
Authorization
.
Person responsible: BSE19-15 27/05/2019

75

Topics Installation procedure Date / Initials
Installation test
Tested and approved in a test environment
Tested and approved in actual environment
Completely tested according to test plan
Partly tested (known extent of update)

Comments:
27/05/2019

76

Chapter six: Performance, servicing, maintenance and phase-out
6.1 Service and Maintenance
The system shall be maintained by making updates onto its currently running functions and also
adding more new functions to it to meet the targeted user’s changing needs. The system users shall
often be notified of the updates that will be carried out on the product in the future. Services that
may have not been met during the implementation phase of the system shall be accomplished as
updates.
6.2 Performance and Maintenance
The system servicing (maintenance and repair) shall be applicable in case the existing functional
implementation fails to provide maximum performance as expected or if there may be need for
functional improvements.
Table 40:Performance and maintenance details checklist
Topics Performance and maintenance
Problem / solution

Problem: There might be some information that the user may
want to access but he/she is not sure where to access it from.
Solution: Use the search fields provided to search for such
information for example specialties and their corresponding
descriptions.
Problem: User may not be sure how to execute certain
functionalities
Solution: Navigate to the Help link, for find necessary help on
how to use the system

77

Topics Performance and maintenance
Functional maintenance

Since the system will use google maps in the near future, the
Google API keys shall require periodic repurchase when their
expiry date reach.
In case of successful implementations of new functions, users
shall always need to be familiarized with them easily to help
them cope with how they work.
Functional expansion and
performance improvement

The following is the list of the suggestions and requests that can
improve the performance of the system. This list can be
expanded further in the newer versions of the system.
1. Implementation of full android based version of the
system to enable flexible user system access.
2. Incorporating alternative forms of paid consultancy
platforms such as mobile money and by use of Bank
accounts.
3. Implementation of a fully learning system that can make
conclusions basing on the previous patient responses.
4. Adopting of other hardware devices that can be
combined with the mobile based systems to do a
complete patient disease diagnosis.
5. Inclusion of a nutrition module to keep track of the
different types of food patients eat and recommend the
correct combinations

78

Chapter Seven: Conclusion and Recommendation
The experience ranging from requirements elicitation, data collection, system design and
implementation grasped during the project’s implementation was just paramount to add more than
just basic to our day to day understanding of software development and analysis.
As BSE19-15 we recommend that student’s final year projects be given maximum time by both
the student’s and their respective supervisors without any difficulty.

79

Appendix A: Patient User Manual
For: Web Based Diagnosis System Software (version.1)
The system is intended for use by mainly Patients and medical practitioners to help patients to
acquire preliminary medical diagnosis ahead of further confirmatory hospital diagnosis. The
software is simple to use as detailed in this manual and the basic knowledge (ability to interact
with a computer freely, taking note of the feedbacks and responses it provides) is needed for one
to maximize its service.
When the system is loaded, patients are required to login using the phone number and password
which were part of the account details provided by them during the registration process.
After the Login, the patient shall access a system home page which consists of a number of
functionalities that the patient can execute as a system user. Amongst the patient functionalities
include:
Register
The functionality enables the patient to register with the system. The following steps are
followed to register with the system.
1) Fill in the personal details in the form shown below.

Figure 17:Step 1 of user registration

80

2) Click next to go to the next step.
3) Fill in the form below and click Register to complete the registration process.

Figure 18:Step 2 of user registration
Sign into the system
This involves the user logging into the system by providing their phone and password in the form
below.

Figure 19:User sign In

81

1) Ask question
This allows the patient to send a medical inquiry query to a team of medical practitioners that
can respond to with important preliminary diagnosis feedback.

Figure 20:Medical inquiry
Steps
1) Click on the ask question button to enter the medical query description. An input form appears
to enter a detailed description of the illness a patient is feeling. The interface below sis
displayed.

82

Figure 21:Enter medical inquiry
2) Add tags to enable the system to easily identify which specialty to submit the medical inquiry
to.
3) Send the compilation of the input to the system by clicking on the submit button.
4) A notification about the successful submission of the medical inquiry after which a patient
waits for the preliminary medical diagnosis report from the medical practitioners through the
system.
Paid Consultancy
The functionality is used to allow a patient to have a more private medical inquiry interaction with
the medical practitioner of which it’s paid for. The functionality is proceeded by the following
steps:
Medical inquiry
title
Medical inquiry
description

83

Figure 22:Paid Consultancy
1) Click on the Paid Consultancy icon on the home page
2) Click on “PAY CONSULTATION FEES” button to the pay consultation fees.

Figure 23:Pay Consultation Fee
3) The message below is displayed on successful payment

84

Figure 24:Successful payment for consultancy
4) The procedure continues normally as in medical inquiries with the user entering the medical
inquiry in the form displayed below.

Figure 25:Consult doctor
View Response
The patient then views the medical response to the medical inquiry he/she posted to the system as
shown m below and then takes the expected action as directed by the medical practitioner.

85

Figure 26:View Medical response
Patient’s medical
inquiry
Medical practitioner
response

86

Appendix B: Medical Practitioner User Manual
The medical practitioner can perform a vast number of functions with the system not limited to
responding to the patient’s medical scenarios. Below are the functionalities that the medical
practitioner can perform:
Respond to medical enquiry
This involves a medical practitioner responding to the patient’s medical inquiry through the
following steps:
1) Click on the queries link on the home page
2) A list of patient’s queries is displayed as shown below

Figure 27:View patient's queries
3) Select the query to address from the list of patient queries as shown above.
The medical practitioner then selects one of the medical queries and responds to them by providing
important feedback to the patient as a basis for preliminary modification. The page below is
displayed.

87

Figure 28:Respond to patient's queries
4) Enter the medical advice as a starting diagnosis phase suitable to address the situation
5) Click the submit button to deliver the feedback to patient.
Create a Health Event
This involves a medical practitioner creating a health event that can be used to provide a
particular health service. A health event can be created using the following procedure:
1) Click on the health units link on the home page.
2) The page below is displayed

Figure 29:Create health event
Form where medical
practitioner enters the
medical response.

88

3) Click on “EVENTS”.
4) The page below is displayed.

Figure 30:Save medical event
5) Enter the event name.
6) Select the health center to allocate the event.
7) Add medical practitioners to the event.
8) Click on submit to create the event.
9) On successful creation of the event, the interface below is displayed

Figure 31:Add Doctor to Medical event
Add a doctor to
Medical event

89

10) Click Add Doctor to add doctors to an event
11) The interface below is displayed

Figure 32:Add doctor details
Click submit to Add the doctor
Discussion forum
The discussion forum is necessary to enable doctors to share important health information and
proven approaches to certain health problems with their colleagues. The discussion forum is used
by medical practitioners in the following ways.
Click on the discussion forum link on the home page

90

Figure 33:Discussion forum
Publish health related information for reference or for use by other medical practitioners
Review published health information.
View Analytics
This functionality is aimed at providing the medical practitioner with a detailed analysis of all the
system data.

91

The following steps are performed by the medical practitioner I view of the system analysis

Figure 34:System analytics View
The system analytics above display a summary of a number of Medical practitioners that attend to
patient’s medical inquiry.

92

Appendix C: Admin User Manual
For: Web Based Diagnosis Software (version 1.0)
Introduction
Web Based Diagnosis System is a software intended to be used by the general public(community)
to access preliminary diagnosis of disease infections that is provided by registered medical experts
from various hospitals. The software is simple to use as detailed in this manual and a basic
knowledge of computer (ability to interact with a computer freely, taking note of the feedbacks
and notifications it provides) is needed for one to maximize its service.
To use the admin panel, you will be required to login before accessing any system functionalities.
Enter the credentials (Email: [email protected] and password = 0758720304).
As an administrator, you will have access to all functions specified in the sections below.
Login Screen

Figure 35:Admin Login
After successful login, you will have access to the admin panel that comprises a number of
functionalities that an admin can execute.

93

Figure 36:Overview of the admin interface
The admin interface consists of 3 main sections i.e. staff management, specialties management,
General Info with each comprising of sub-sections.
Staff Management
This is the section where self-enrolled medical practitioners on the system are either approved to
join or declined from joining a team of registered medical practitioners that respond to patients’
enquiries in the system.
Once a registration request by medical practitioner has been approved, this only occurs on
condition that the practitioner provided correct information during registration, he/she is
automatically joined to a team of medical experts registered with the system and can now respond
to patients’ enquiries.

94

Medical practitioners whose registration requests were denied are notified that their requests where
declined and therefore can’t be allowed to join the team of medical experts registered with the
system.

Figure 37:Approve new Medical Practitioner
To either approve or decline a request, the administrator clicks on the action button (1), and is
presented with a list of options i.e. Approve request or Decline request.
Click on icon labelled (2) to view detailed information about a medical practitioner’s request.
Registration requests are approved when the administrator performs a background check and
confirms that the provided details provided by the administrator upon registration are valid
otherwise the request(s) are declined and they are not enrolled in the system.
Specialties Management
Allows an administrator to manage information about specialties to which various medical
practitioners belong. It involves adding, editing and displaying a list of specialties that various

95

medical practitioners have expertise in. Foreach specialty to be recorded, the administrator has to
provide a detailed description of that particular specialty.
It is also concerned with attaching of tags to a given specialty, these tags are used by patients by
attaching them to the signs and symptoms that they are possessing while making an enquiry on
the system.
Register new specialty
To add a new specialty, the form below is displayed on clicking the Register new specialty tab
as shown below;

Figure 38:Add Specialty tag
To add a new tag for a given specialty, the administrator first selects the specialty on which
he/she wants to attach that particular tag. Forex ample for the dermatology specialty, tags that
can be attached to it include; skin, hair and nails such that when a patient makes an enquiry and
attaches any of the tags mentioned above, the system automatically sends this particular patient’s
enquiry to all medical practitioners that possess expertise in this speciality.

96

Figure 39:List of all specialties
Displays a list of specialties that various medical practitioners registered with the system, belong
to.

Figure 40:General System Info
This section manages information about various health centers that the medical practitioners may
recommend to patients, registering a district. This includes;

97

Register health unit
It records the name of the health center, the location (GPS coordinates i.e. latitude and longitude)
and the district in which it is situated.

Figure 41:View registered health units
Displays a list of health units that are registered with the system. It further provides an option of
editing the provided information.

98

Figure 42:Record new district
Records new district where health centers as well as patients are situated.

Figure 43:Register District

99

Table 41:Final Approval
Final approval for use
Identification:
Responsible for validation:
Remarks:

Date: Signature:

Software Engineering Final Year Project Report

About This Presentation

Slide Content

Tags

Categories

Download

Quick Actions

Statistics

Related Slideshows

Software Engineering Final Year Project Report

About This Presentation

Slide Content

Slide 1

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10

Slide 11

Slide 12

Slide 13

Slide 14

Slide 15

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

Slide 34

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40

Slide 41

Slide 42

Slide 43

Slide 44

Slide 45

Slide 46

Slide 47

Slide 48

Slide 49

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Slide 56

Slide 57

Slide 58

Slide 59

Slide 60

Slide 61

Slide 62

Slide 63

Slide 64

Slide 65

Slide 66

Slide 67

Slide 68

Slide 69

Slide 70

Slide 71

Slide 72

Slide 73

Slide 74

Slide 75

Slide 76

Slide 77