BACHELOR OF SCIENCE IN INFORMATION SECURTY AND

FORENSCS (BISF).

SECURITY AND FORENSICS PROJECT: BISF 3500

ASHAKI CARE HOSPITAL APPOINTMENT MANAGEMENT

APPLICATION.

BY; IRUNGU EVERLYNE NELIUS NJERI.

REG NO: 19/05463.

PROJECT SRS DOCUMENT SUBMITTED IN PARTIAL

FULFILMENT FOR THE REQUIREMENTS FOR THE AWARD
OF A DEGREE IN INFORMATION SECURITY AND
FORENSICS.
PRESENTED TO DR. HARON TINEGA.
DECLARATION
I Irungu Everlyne Nelius Njeri, Hereby Declare That This Proposal Is Entirely my own work and
nobody else’s. This project has neither been carried out nor presented before any institution.
Where there’s contribution from other sources or individuals has been clearly acknowledged.

STUDENT

Name: Irungu Everlyne Nelius Njeri Signature …………I.E.N.N.……………

Date ………………………………………..

SUPERVISOR

Name: Dr. Haron Tinega Signature …………………………………

Date………………………………………...
Table of Contents

DECLARATION.............................................................................................................................2
1.0
INTRODUCTION............................................................................................................................
4
1.1
Purpose..........................................................................................................................................4
1.2 Intended audience and reading
suggestions......................................................................................4
1.3 THE
SCOPE...........................................................................................................................................5
1.4
References......................................................................................................................................5
2.0 GENERAL
DESCRIPTION...........................................................................................................................6
2.1 Product
Perspective............................................................................................................................6
2.2 Product
Features.................................................................................................................................6
3.0 User Classes and
Characteristics.............................................................................................................7
4.0 Operating
Environment..........................................................................................................................7
5.0 Design and Implementation
Constraints................................................................................................8
5.1 User
Documentation...........................................................................................................................8
5.2 Assumptions and
Dependencies.........................................................................................................9
6.0 SYSTEM
FEATURES................................................................................................................................10
6.1 Log
In.................................................................................................................................................10
6.2 Patient
Management........................................................................................................................11
6.3 Appointment
Booking.......................................................................................................................11
6.4 External Interface
Requirements......................................................................................................12
6.5 Hardware
Interfaces .........................................................................................................................12
6.6 Software
Interfaces...........................................................................................................................13
6.7 Software Quality
Attributes..............................................................................................................14

1.0 INTRODUCTION
The Software Requirements Specification (SRS) consists of an overview of the purpose, scope,
definition, the overall description and the design of the proposed system which is the Hospital
Appointments Management System. It also contains the in-depth overview of the system by
defining the problem statement and the user requirements the system is set to address in general.

1.1 Purpose
The purpose of the SRS is to acquire and analyze all ideas that define the system as well
as its requirements with respect to the clients. It’s also to predict how the product of the
system will be used in order to gain a better understanding of the system, outline concepts
that may be developed later, and document ideas that are being considered.
The SRS also contains a detailed information of our system, its parameters and goals. This
document describes the system’s target audience and its user interface, hardware and
software requirements. It defines how the users see the product and its functionality. It
helps the designer and developer to assist in software delivery lifecycle (SDLC) processes.

1.2 Intended audience and reading suggestions

The document is intended for the following audience:
 Doctors
Since the doctors are our main target for this application we intend to have them
equipped with suitable knowledge of how the system functions.
 Programmers and Developers
The Hospital Management System developers require the document in order to develop
the User Interface and be conversant with the features to be included in the system.
 The marketing staff
Our marketing team will require the document in order to come up with a work plan on
how to market the product based on the requirements stated.
  Testers and Maintenance teams
The system testers require the document in order to prepare for the testing of the system.
The maintenance team will require the document to plan for future and current
maintenance plans.
 Trainers
The document is necessary for them to organize materials required for training end users.

1.3 THE SCOPE

The scope focuses on the system that has been created to help the hospital administration
and the public as a whole. The automated system will help to manage the doctor’s
appointment and also to provide a mobile hospital platform where you can consult with
doctors. This system will also enhance the quality of services in terms of medical attention
given enabling doctors and management to keep in touch with their patients and track of
their progress as well.
It also aims at specifying requirements of the system to be developed and can be used to create
system requirements specifications directly or can be used as a model for defining a
system specification standard.

1.4 References
Arthur Hylton III and Suresh Sankaran arayanan “Application of Intelligent Agents in
Hospital Appointment Scheduling System”, International Journal of Computer Theory
and Engineering, Vol. 4, August 2012, pp. 625-630.
Prof. S. B. Choudhari, ChaitanyaKusurkar, RuchaSonje, ParagMahajan, Joanna Vaz
“Android Application for Doctor‟s Appointment”, International Journal of Innovative
Research in Computer and Communication Engineering, January 2014.
RashmiA.Nimbalkar and R.A. Fadnavis “Domain Specific Search of Nearest Hospital
and Healthcare Management System”, Recent Advances in Engineering and
Computational Sciences (RAECS), 2014, pp.1-5.
2.0 GENERAL DESCRIPTION
This document will provide general details of Ashaki Hospital Appointment’s Management
Application.

2.1 Product Perspective

With the main goal of the system being building a good platform for a doctor and patient
communication, this application helps you to book appointments with the doctor or
hospital you would like.
The application tracks your appointments in real time and keeps you updated on the
expected time of appointment along with how long you have to wait for your turn so that
you can plan accordingly.
It also keeps you updated on the status of your lab reports and allowing you to access
your lab reports whenever you need them.
The app helps one to manage their medicine timetable as well as allowing you to upload
prescription or access the prescribed medicines.

2.2 Product Features

System Interface;
The interface includes:
 Home Page.
 Login Interface
 Admin Interface
 Doctor/Specialist Interface
 Patient Interface

2.2.1 Interfaces
a) Home Page
The system displays accounts for the target users in the application and the user is
prompted to click their account in order to login.

b) Login Interface
Here the user is asked to fill in their credentials in order to access the system and if they
are correct he/she proceeds.

c) Admin Interface
Upon validation of the Admin’s credentials he/she is allowed access into the system
where they get to access this interface.
In this interface the admin is provided with a menu of tasks that he/she chooses to
perform.

d) Doctor/Specialist Interface
The system allows the doctor or specialist into the system where they are provided with a
list of tasks like administering professional advice to a patient and the doctor/Specialist
will choose the task to perform based on the activity in hand.

e) Patient’s Interface
The patient is allowed into the system upon keying valid credentials while logging.
The patient is provided with a list of options that are available for them and they are
expected to select the one that they would like.

2.2.2 Data Capturing

Data will be obtained from patient’s records and the doctor’s or specialist’s records as
well and will be securely stored in the system’s database.

2.2.3 Data processing

The system being a mobile-based application it will rely on whatever information that the
user feeds into it and process the data for smooth operations in the system.

2.2.4 Data Validation and Integrity

The system will have measures laid down that ensure data captured is valid and adheres
to the regulations provided.

3.0 User Classes and Characteristics

User Class Characteristic based on Importance
user privileges
Admin Ensures that only Qualified Very Important in the
doctors and specialists are System.
admitted into the system and
can add or remove them.
Doctor/Specialist Main Functionality is to give Fair Rank in Importance.
professional treatment on
health issues to patients and
book them for appointments
according to their schedule.
Patients Searches for the nearest Fair Rank in Importance.
doctor/specialist in their area
and consults with them.

4.0 Operating Environment

In order for the system to operate smoothly it requires the following specifications.
4.1.0 Hardware
A mobile phone that runs on Android Operating System with a minimum version of 7.0.

4.1.1 Software
The system requires the following minimum software specifications in order to run
smoothly.
Android Operating System.
MySQL software for the database.
XAMPP server.
5.0 Design and Implementation Constraints
Time constraint: The time stated to develop the system might affect the end product if the
project is large and the allocated time is minimal the end product might not be as
expected.
The Version of XAMPP software used to develop the system might affect the application if
it was to be run on a different version.
The design style used in the User Interface may not meet some of the end users desires.

5.1 User Documentation

For the system to be user-friendly and meet its aim it has to document all the various
stages involved from the design to the development in order to:
 Ensure easy navigation through various Interfaces.
 Boost user’s knowledge on the Hospital Appointment Management Application.
 Ensure that the User Interface is easier to understand.
Some of the documents to be used will be:
The user’s manual.
A command prompt document that informs the user how to tackle some errors in case
they pop up.
A knowledge based document that is very suitable for a quick reference.

5.2 Assumptions and Dependencies

The system targets users with an android operating system.
The users are assumed to be computer literate and thus are able to at least start and end
an application.
The system should not exceed the stated budget and since this may lead to omission of
some key requirements.
It is assumed that the test data provided is reliable.
XAMPP software will continue to be an open source software
6.0 SYSTEM FEATURES
The system has various sets of data, there is the patient’s records data, captured after the
patient keys in their details in the system.
Another form of data is the specialist’s or doctor’s data about their qualifications and
their geographical location which helps the patient to choose the suitable person to
consult.
Below are some of the use cases to depict the Environment that the system operates in.

Adds a new doctor/specialist

Logs into the Adds a hospital to the system
system in charge of the hospital’s
doctors.

Admin
Removes a

Logs into the Administers professional

system advice.
Checks on patients progress
sets appointments for
Doctor/Specialist patients .

Scans for a nearby

Logs into the
doctor/specialist.
system Checks Doctor’s details.
Pays consultation fee confirms
appointment dates
Patient updates ..progress of a certain

6.1 Log In
This is a system feature that controls if the users can have access to the system where the
users are prompted to enter their passwords and pins.
  6.1.1 Description and priority
In order for any users to access the system they have to key in valid and correct
credentials into the system, their username and pins.
The feature is of high priority since users cannot access the system without this feature.

 6.1.2 Stimulus/Response
On the homepage once the user selects their respective account this feature will pop up in
the next page where the user is prompted to enter their username as well as password, the
system the compares these to those saved in the database and if they match the user is
granted access into the system, else they are denied access.
 6.1.3 Functional Requirements
In order for this feature to be implemented the database should be accessible for the
system to compare the inputs and if invalid inputs are keyed a warning message pops up
telling the user to key in valid details for their access to be granted.

The requirements for logging into the rental management system are:
REQ1: When the username and password are both correct the user is allowed access to the
system.
REQ2: For the doctor/specialist he/she should be certified by an admin in order to log in
into the system.

6.2 Patient Management

 6.2.1 Description and Priority
This feature is of high priority since most of the data stored by the system is obtained
from the patient and with the help of the software one can store the patient’s data.
 6.2.2 Stimulus/Response
After the patient registers into the system the first time their data is recorded and also
while seeking treatment this data is captured as well and is used by the doctor’s or
specialists to have an overview of the patients record of treatment.
 6.2.3 Functional Requirements
In order for this feature to be executed certain requirements need to be in place.
REQ1: The patient should be above 18 years to access the system since no child id
allowed to consult a medical expert on their own.
REQ2: The patient should fill correct information when prompted to or when asked by a
specialist.

6.3 Appointment Booking

 6.3.1 Description and Priority
This feature is of high priority as well since we aim at helping patients get appointments
without having to wait for long hours in queues at hospitals for their appointments.
 6.3.2 Stimulus/Response
The doctor/Specialist is expected to set appointment dates for their patients if they have
agreed to have one on the chat section and inform them of how long their appointment
will take, which will be on the appointment’s section.
 6.3.3 Functional Requirements
In order for this feature to be executed the following should be considered.
REQ1: Patient to confirm or re-schedule the set date for their appointment.

6.4 External Interface Requirements

 6.4.1 User Interfaces
The Hospital Management Booking Application is displayed through a Graphical User
Interface that aims at fulfilling the end user desires.
The system targets three main users, the Admin, A doctor/specialist and a patient. The
GUI provides the Log in features that secures the users accounts thus without the correct
Login credentials one cannot bypass the system to interact with the data in the database.
An example of the UI is displayed below:
 6.4.2 GUI
The Graphical User Interface has various buttons that allow the user to navigate through
different forms and textboxes where the users can fill in relevant data.
 6.4.3 Menu
Each UI has a form with a list of tasks for the user to perform depending on the rank of
the user in the organization each user has a different menu.
 6.4.4 Messages
A good system should have the following type of messages of which they are
implemented in the system:
 Error message - Incase the user enters a different type of data apart from the expected
input an error message will pop up.
 Warning Message – When the user performs an operation that might cause harm to the
system a warning message will pop up as well.
 Informational message – After the user performs the desired operation like saving data to
the database an informational message will pop up informing the user that the operation
was successful.
6.5 Hardware Interfaces
The system being a mobile-based system it has limited number of hardware Interfaces.
The main and most important hardware interface is the mobile application that needs to
have certain specifications that were stated earlier in the proposal document.

6.6 Software Interfaces

Operating System
The Application can run on an android Operating System with a minimum version being
7.0 and a RAM of 2GB.
Database
The system uses MySQL database hosted on a XAMPP server.
6.7 Software Quality Attributes
 6.7.1 Correctness
The Hospital Management System has passed through all the system development stages
to ensure that an efficient and reliable product has been delivered to the end user.
 6.7.2 Reliability
The system being a bespoke software has focused on each and every end user and
ensured that the tasks to be executed by the end user have been delivered in the system.
 6.7.3 Portability
The software can be run on most android mobile phone.