Mobile-Based Patient Management System: Software Requirements

This Software Requirements Specification (SRS) document details the requirements for a mobile-based patient management system designed for medical facilities. The document outlines the system's purpose, which is to streamline patient record management using an Android application. It defines the scope of the software, including patient registration, diagnosis, and medication tracking, while excluding billing, payroll, and HR functions. The document describes the system's interfaces, including login, welcome screen, patient records, doctor records, staff records, payment information, and patient information interfaces, detailing their characteristics and functionalities. Hardware and software interfaces are also specified, including the use of a Firebase server for the real-time database and HTTPS for communication. The SRS outlines product functions such as storing patient and staff records, managing billing, and creating an efficient platform to reduce queues. User characteristics and constraints, including security measures and financial data integrity, are also addressed. Assumptions, dependencies, and a list of features not included in the initial version are provided. Finally, the document covers system requirements, external interfaces, performance requirements, logical database requirements, design constraints, software attributes like reliability and security, and a change management process.

MOBILE BASED PATIENT MANAGEMENT SYSTEM
Software Requirements Specification
Document
(Team Number)
(Team Members Name and Student ID)

Versions
Version Primary
Author(s)
Description of Version Date
Completed
Review & Approval
Approving Party Version
Approved
Signature Date

Table of Contents
1.0 Introduction................................................................................................................................4
1.1 Purpose....................................................................................................................................4
1.2 Scope.......................................................................................................................................4
1.3 Definitions, Acronyms, and Abbreviations............................................................................4
1.4 References...............................................................................................................................4
1.5 Overview.................................................................................................................................4
2.0 Overall Description....................................................................................................................5
2.1 Product Perspective.................................................................................................................5
2.1.1 System interfaces.............................................................................................................5
2.1.2 Interfaces..........................................................................................................................6
2.1.3 Hardware Interfaces.........................................................................................................6
2.1.4 Software Interfaces...........................................................................................................6
2.1.5 Communication Interfaces...............................................................................................6
2.1.6 Memory Constraints.........................................................................................................6
2.1.7 Operations........................................................................................................................6
2.1.8 Site Adaptation Requirements..........................................................................................7
2.2 Product Functions...................................................................................................................7
2.3 User Characteristics................................................................................................................7
2.4 Constraints..............................................................................................................................7
2.5 Assumptions and Dependencies.............................................................................................7
2.5 Apportioning of requirements.................................................................................................7
3.0 System Requirements.................................................................................................................8
3.1 External Interfaces..................................................................................................................8
3.1.1 User Interfaces.................................................................................................................8
3.1.2 Hardware Interfaces.........................................................................................................8

3.1.3 Software Interfaces...........................................................................................................8
3.1.4 Communication Interfaces...............................................................................................8
3.2 Functions.................................................................................................................................9
3.3 Performance Requirement......................................................................................................9
3.4 Logical database requirements................................................................................................9
3.5 Design Constraints................................................................................................................10
3.5.1 Standards Compliance....................................................................................................10
3.6 Software System Attributes..................................................................................................10
3.6.1 Reliability.......................................................................................................................10
3.6.2 Availability.....................................................................................................................11
3.6.3 Security..........................................................................................................................11
3.6.4 Maintainability...............................................................................................................11
3.6.5 Portability.......................................................................................................................11
3.7 Organizing Specific Requirements.......................................................................................11
4.0 Change Management Process...................................................................................................12
5.0 Document Approvals................................................................................................................12

1.0 Introduction
The software requirement specification document is on the patients’ management system. The
document gives a clear description on the flow of information of the patients’ management
system. The modules which are required in the development of the system is explained in this
particular document. Different modeling designs of the system have been given out in order to
help the developer of the system with how exactly the system is supposed to be developed.
Patients management system is a system which tracks the information of the patient who is
visiting the medical centre. The system stores the information for future retrieval and to reduce
redundancy of information. Patient information can be retrieved at any department of the medical
centre if required by the use of a unique number which will be given to the patient at the very
first stage of registration. The system to be developed according to the system requirement
specification document is and android application for management of patients.
1.1 Purpose
The main purpose of this software requirement specification, is to give a detailed description of
how an android based patient management system has to be developed. The SRS document
targets the medical facilities management which are the main contractor of this particular project.
1.2 Scope
The software to be developed is a mobile based patient management system. The application will
be tracking the flow of patients record in the medical facility which includes patient registration,
patient diagnosis and medication as well as discharge. The software will not track billing system
for the pharmacy, staff payroll system as well as human resource which deal with employment.
The software design is only limited to the scope above.
The software will be helping the staff in the medical facility to record and store patients
information with ease as well as creating a platform where doctors can be able to monitor patients
information and health. By reduce the time wasted for manually checking the patient records, the
application will be able to improve the general service delivery of the facility by taking the
shortest time possible for the patient to be served.
1.3 Definitions, Acronyms, and Abbreviations
SRS -----Software Requirement Specification

CDN ….. Content Delivery Network
HTTPS……. HyperText Transfer Protocol Secure
1.4 References
References
[1]C. Martorella, "Implementing a Patient Classification System", Nursing Management
(Springhouse), vol. 27, no. 12, pp. 29???32, 2014. Available: 10.1097/00006247-199612000-
00008.
[2]S. Withall, Software Requirement Patterns. Sebastopol: Microsoft Press, 2010.
[3]M. Virvou and S. Matsuura, Knowledge-Based Software Engineering. Amsterdam: IOS Press,
2012.
[4]Social Modeling for Requirements Engineering. MIT Press, 2011.
[5]K. Qian, D. Den Haring and L. Cao, Embedded Software Development with C. Boston, MA:
Springer US, 2009.
[6]A. Rashid and M. Aksit, Transactions on Aspect-Oriented Software Development IV. .
[7]"Software requirements specification - Wikipedia". [Online]. Available:
https://en.wikipedia.org/wiki/Software_requirements_specification. [Accessed: 2019].
[8]"Software Requirement Specification (SRS)". [Online]. Available:
https://www.softwaretestingclass.com/software-requirement-specification-srs/. [Accessed: 2019].
[9]"Software Requirements Specification - cse.chalmers.se". [Online]. Available:
http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_group2.pdf.
[Accessed: 2019].
[10]"Software Requirements Specifications: How To Write SRS ...". [Online]. Available:
https://www.bmc.com/blogs/software-requirements-specification-how-to-write-srs-with-
examples/. [Accessed: 2019].
[11]"Hardware and software requirements for SharePoint 2013 ...". [Online]. Available:
https://docs.microsoft.com/en-us/SharePoint/install/hardware-and-software-requirements-0.
[Accessed: 2019].
1.5 Overview
The SRS document contain six major sections, from the six sections, two of the sections are more
important and necessary to note. The SRS contains the introduction, overall description, specific

requirements, change management process, document approvals and supporting information
sections.
Section two of the document is more appropriate to the customer as it contains the general
description of the software to be developed.
Section 3 of the document contains what the developer of the system needs to develop the
software as it contains all the requirement specification as well as the design models which
describes the flow of information and correlation of the software modules.

2.0 Overall Description
2.1 Product Perspective
Just like other softwares which functions in the medical facilities like the hospital management
system, patients file record tracking system, patient diagnostic system and hospital enterprise
management system, mobile based patient management system is an independent system which
does not depend on any other system which functions within the medical facility for information
and data. The software keeps track of all the records, information and data related to the patients.
The system depends on the human interaction which the main users of the system being the staff
member of the medical facility. This includes the receptionist, registration staff, nurses, doctors,
pharmacists, radiologists, surgeons as well as any other staff of the hospital for any departmental
category.
2.1.1 System interfaces
Based on the software which is going to be developed, it will have the following interfaces which
the user will be interacting with;
2.1.1.1 Login interface: This is the interface used by the user of the system to access the
software content. It is where the user enters the personal credentials to access the software.
2.1.1.2 The welcome screen interface: This is the very first interface on the software where it
displays the information of the medical facility and all the modules which respective staff of
the facility can access. It has the doctor’s records, patient’s records, staff records, payment
information and the doctor’s feedback modules.
2.1.1.3 Patients records interface: This is the interface which is used by the user/ receptionist
in the medical facility to register the patient into the system. The interface has the panel for
entering patient personal details and a save button. The interface also captures the patient
medical condition.
2.1.1.4 Doctors records interface: This is the interface where all the doctors serving in that
particular facility will have to register themselves in order to get accounted by the system. It
will also help to get to know which doctor has logged into the system.

2.1.1.5 Staff records interface: This is the interface where all the staff serving in that
particular facility will have to register themselves in order to get accounted by the system. It
will also help to get to know which staff has logged into the system.
2.1.1. 6 Payment information interface: This is the interface which is accessed by the
accountant and the billing department. The bills which have been accumulated by the patient
for the service offered is entered from this section so that the patient can be able to check and
settle.
2.1.1.7 Patient information interface: This is the interface where the patients health
information is displayed so that the doctor can take necessary actions. It is also used by the
doctors to invite the patient to the medication rooms hence saving a lot of time.
2.1.2 Interfaces
General interface characteristics
Each interface has a GUI for interaction with the user.
Specific interface characteristics
2.1.2.1 Login interface: the user will enter the username and the password and press enter.
The empty fields are case sensitive.
2.1.2.2 The welcome screen interface: The user will select their respective section that they
operate on.
2.1.2.3 Patients records interface: All the fields are case sensitive. The user will enter the
information of the patient and press save button.
2.1.2.4 Doctors records interface: All the fields are case sensitive. The user will enter the
information of the doctor and press save button.
2.1.2.5 Staff records interface: All the fields are case sensitive. The user will enter the
information of the staff and press save button.
2.1.2.6 Payment information interface: The accountant will enter the expenses that the patient
has accrued in the treatment process,

2.1.2.7 Patient information interface: The doctor will check all the data of the patient with
their conditions. The doctor has no right to edit anything here.
2.1.3 Hardware Interfaces
The system does not have any hardware interface required
2.1.4 Software Interfaces
2.1.4.1 Firebase server 3.6. This system must use the firebase server as the real time database.
Communication with firebase connections. The system connectivity is online and no setup
required for firebase.
2.1.5 Communication Interfaces
Since the system has its database on the web servers, the system will use HTTP secure as a
communication interface transferring data via the Content delivery network (CDN).
2.1.6 Memory Constraints
The software to be developed has no memory constraints since its database is hosted in the web
servers the application can work under any memory given.
2.1.7 Operations
The software application operates each and every time it is accessed. There is no specific period
that the software application cannot operate. When the application is not used for a period of 30
minutes, it will logout itself hence in order to use it again, the user has to login first. The system
will also need internet access in order for data processing to take place. The application backup
functions take place at the backed side without interfering with the client side operations. In case
of data loss, recovery of data takes place automatically once there is a gap noted in the backend
side between the primary and the secondary database.
2.1.8 Site Adaptation Requirements
The software application operates on a mobile based android device; therefore, the medical
facility will have to purchase android mobile phones which will be installed to each departmental
office prior to the system installation.
2.2 Product Functions
The software will be providing the following major functions;

2.2.1 Storing patients’ records.
2.2.2 Storing staff records for accountability and budgeting.
2.2.3 Storing doctor’s details for easy accountability.
2.2.4 Manage patients billing and payment information.
2.2.5 Create an ease platform to eliminate long queues in the facility.
2.3 User Characteristics
The user of the system must have the following characteristics to operate the system;
2.3.1 Must be a medical facility employee.
2.3.2 Must be computer literate.
2.3.3 Must be conversant with medical terms.
2.3.4 User who operates the billing section must have knowledge with accounting and
finance.
2.4 Constraints
2.4.1 The software must be secure with password fields encrypted with MD5 to avoid attackers
and soft hackers.
2.4.2 The software must be able to produce a balanced financial data for audit and authentication.
2.4.3 The software must be reliable in such a way that; it should not fail at any point during
operation.
2.5 Assumptions and Dependencies
It is assumed that each mobile phone bought has android operating system on which the
application will be installed. If this android operating system will not be there, then the
requirement on the SRS will be changed as the system will completely depend on the android
operating system.
2.5 Apportioning of requirements
The following are the features which will not be available in the first version of the system.

2.5.1 The receipt printing feature for the billing department.
2.5.2 The ledger and balance sheet feature in the billing department.
2.5.3 The disease diagnostic assistant feature for doctors.
2.5.4 The in-patient management section feature.