Software Requirement Specification (SRS) Document

Healthcare Management System

Table of contents
1. Introduction
 Purpose
 Scope
 References
2. Overall Description
 Product Perspective
 Product Function
 User Classes and characteristics
 Operating Environment
 Assumptions and Dependencies
3. External Interface Requirements
 Software Requirements
 Hardware Requirements
4. Non-Functional Requirement
 Usability Requirements
 Security Requirements
 Availability Requirements
 Scalability Requirements
 Performance Requirements
5. Design
 ER Model of HMS
 Use Case Diagram
 Class Diagram
1. Introduction
Purpose:
This software will help the company to be more efficient in registration of their
patients and manage appointments, records of patients. It enables doctors and
admin to view and modify appointments schedules if required. The purpose of
this project is to computerize all details regarding patient details and hospital
details.
Scope of the Project:
The system will be used as the application that serves hospitals, clinic,
dispensaries or other health institutions. The intention of the system is to
increase the number of patients that can be treated and managed properly. If the
hospital management system is file based, management of the hospital has to
put much effort on securing the files. They can be easily damaged by fire,
insects and natural disasters. Also could be misplaced by losing data and
information.
References:
 Software Requirements (Microsoft) Second Edition By Karl E. Wiegers
 Fundamentals of Database System By Elmasri
 Software Requirements and Specifications: A Lexicon of Practice,
Principles and Prejudices (ACM Press) by Michael Jackson
 Fundamentals of Software Engineering By Rajib Mall
 Software Engineering: A Practitioner’s Approach Fifth Edition By Roger
S. Pressman

2. Overall description
Product Perspective:
This Hospital Patient Info Management System is a self-contained system that
manages activities of the hospital. Due to improperly managed details medical
center faces quite a lot of difficulties in accessing past data as well as managing
present data. The fully functional automated hospital management system which
will be developed through this project will eliminate the disadvantages caused
by the manual system by improving the reliability, efficiency and performance.
The usage of a database to store patient, employee, stock details etc. will
accommodate easy access, retrieval, and search and manipulation of data. The
access limitations provided through access privilege levels will enhance the
security of the system. The system will facilitate concurrent access and
convenient management of activities of the medical center..

Product Functions:
 Provide access to registered users only.
 Registration of new patients.
 Enable patient to view their record.
 Enable patient to update their record.
 Generate appointment date and timing.
 Confirmation by doctor.
 Patients can do Payment.
 Modification in schedule by patient.
 Admin access to patient’s record.
 Admin Verify Payment and Generate Bill/Receipt.
 Admin can view monthly/yearly records.
User Class and Characteristics:
1. Patient Registration:
 Users (patients) can register and provide essential demographic
information.
2. Appointment Scheduling:
 Users can schedule appointments with healthcare providers.
3. Electronic Health Record Access:
 Users have access to their own electronic health records.
 4. Billing and Invoicing:
 Users may interact with the system for billing inquiries and
payments.

Operating Environment :
 Front-End: HTML, CSS, JavaScript, and Bootstrap are used for web page
structure, styling, and responsive design.
 Back-End: PHP handles server-side logic, with XAMPP providing
Apache, MariaDB/MySQL, and PHP for development and testing.
 Database: SQL+ Database manages and queries relational data.
 Operating System Compatibility: Windows 7, 8, and 10 are supported.
 Hardware Requirements: Intel Core i3 processor and 40GB of storage are
recommended

Assumptions and Dependencies:

 The distributed healthcare management system supports patient
appointments and medical record updates from any location.
 It provides access to connected medical services if direct services are
unavailable.
 The system tracks frequent patients (high-volume users) and calculates
appropriate reward points or benefits.
 Transactions for appointment scheduling and record updates are treated as
single transactions.
 The distributed database is geographically dispersed across four cities:
Delhi, Mumbai, Chennai, and Kolkata.

3. External Interface Diagram

Functional Requirements
This document outlines the software and hardware requirements for a software
package developed with a specific technology stack. The package includes a
combination of frontend, backend, and database technologies, and is designed to
run on a Windows operating system. Below is a detailed description of the
requirements and specifications.
Frontend Technologies
 HTML (HyperText Markup Language): Used for structuring the content
on web pages.
 CSS (Cascading Style Sheets): Employed for styling the visual
presentation of web content. JavaScript: Provides dynamic functionality
and interactive elements on the web pages.
 Bootstrap: A popular front-end framework for designing responsive and
visually appealing web interfaces.
Backend Technologies
 PHP (Hypertext Preprocessor): Server-side scripting language used to
handle business logic, server-side operations, and integration with the
database.
 XAMPP Server: An open-source cross-platform web server solution stack
package. It includes Apache (a web server), MariaDB/MySQL (a
database server), and PHP/Perl (scripting languages), providing an
integrated environment for developing and testing the software.
Hardware Requirements
 Operating System Compatibility Windows: The software package is
compatible with the following versions of the Windows operating system:
Windows 7 Windows 8 Windows 10.
 Processor: An Intel Core i3 or above is recommended to ensure stable
operation and efficient data processing.
 Hard Disk: Minimum of 40GB of storage space is required to
accommodate the software and related data.
 RAM (Random Access Memory): Minimum: 256MB Recommended:
2GB or more for optimal performance. Sufficient RAM enhances the
software’s ability to handle tasks efficiently, reducing delays and
improving data retrieval times.
4. Non-Functional Requirement
Software Quality Attributes:
 Our user interface should be interactive simple and easy to understand .
The system should prompt for the user and administrator to login to the
application for proper input criteria.
 Healthcare Management System shall handle expected and non –
expected errors in ways that prevent loss in information and long
downtime period.
Security Requirements:
 System should use secured Database.
 Normal users can just read information but they cannot edit or modify
anything except their personal and some other information.
 System will have different types of users and every user has access
constraints.
 Proper user authentication should be provided.
 No one should be able to hack users password .
 There should be separate accounts for admin and members such that no
member can access the database and only admin has the rights to update
the database.
Performance Requirements:
 The system shall accommodate high number of booking and users
without any fault.
 Responses to view information shall take no longer than 5 seconds to
appear on the screen.
Safety Requirements:
HMS product shall handle expected and non-expected errors in ways that
prevent loss in information and long downtime period.
 5. Design
ER Diagram of Healthcare Management System

Entities
1. Patient
 P-ID: Primary Key
 Name: Name of the Patient.
 DOB: Date of borthf of Patient.
 Gender: Gender of Patient.
 Mob-No: Contact number of the Patient.
 Age: Age of Patient.
2. Employee
 E-ID: Primary Key
 Name: Name of the Employee.
 Salary: Salary of Employee
 Sex: Gender of Employee.
 Mob-No: Contact number of the Employee.
 Address: Address of Employee.
 State: State of Employee
 City: city of Employee
 Pin–no: Pin no of Employee
3. Doctor
 E-ID (Foreign Key referencing Employee):
 Department: Department of doctor.
 Qualification: Qualification of Doctor
4. Nurse
 E-ID: E-ID is a foreign key linking a table to the Employee table through
the Employee ID.
5. Room
 R-ID: It is an room id every room has different room number or ID.
 Type: It define the quality of room such as deluxe, private general etc.
 Capacity: It defines the number of people can stay in room.
 Availability: It define the duration or Availability of room.
6. Receptionist
 E-ID (Foreign Key referencing Employee): E-ID is a foreign key in a
table that references the Employee table, typically used to establish a
relationship between the two tables based on the Employee ID.
7. Test Report
 R-ID: Primary Key
  P-ID (Foreign Key referencing Patient): P-ID is a foreign key in a table
that references the Patient table, typically used to establish a relationship
between the two tables based on the Patient ID.
 Test Type: It define the what kind of test.
 Result: It shows the test result.
8. Bill
 B-ID: Primary Key
 P-ID (Foreign Key referencing Patient): P-ID is a foreign key in a table
that references the Patient table, typically used to establish a relationship
between the two tables based on the Patient ID.
 Amount: The Amount which Patient has to pay to the Hospital.
9. Records
 Record-no: Every record book has some number for each Patient.
 App-no: Every app book has some number for each Patient.
Relationships:
Patient – Doctor Relationship
This is a Many-to-Many as multiple Patient can visit multiple Doctor.
Nurse – Rooms Relationship
This is a many-to-many relationship between nurses and rooms, each nurse can
be assigned to multiple rooms, and each room can have multiple nurses
assigned to it.
Receptionist – Records Relationship
This is a many-to-many relationship between receptionists and records, each
receptionist can manage multiple records, and each record can be managed by
multiple receptionists.
Patient – Bills Relationship
This is a one-to-many relationship between patients and bills, each
patient can have multiple bills, but each bill belongs to only one patient.
Patient – Test Report Relationship
This is a one-to-many relationship between patients and test reports, each
patient can have multiple test reports, but each test report belongs to only one
patient.
Rooms – Patient Relationship
This is a one-to-many relationship between rooms and patients, each room can
accommodate multiple patients, but each patient occupies only one room at a
time.
 USE Case Diagram
A Use Case Diagram for a Healthcare Management System (HMS) depicts the
interactions between actors (users or external systems) and the system to
achieve specific goals. Here’s a simplified version of a Use Case Diagram for an
HMS:
For a Healthcare Management System (HMS), the class diagram and its
characteristics would typically include:
1. Classes: Representing entities such as Patient, Doctor, Nurse, Employee,
Bill etc.
2. Attributes: Each class would have attributes representing its properties.
For example, the Patient class might have attributes like patientID, name,
gender, dateOfBirth, and contactDetails.
3. Associations: Relationships between classes would be depicted to show
how they are connected. For instance, an association between Patient and
Doctor classes would show that a patient can be associated with one or
more doctors.

4. Multiplicity: Multiplicity would specify how many instances of one class

are associated with instances of another class. For example, a Doctor can
have multiple patients, indicating a one-to-many relationship.

5. Inheritance (Generalization): If there are common attributes or methods

shared between classes, inheritance can be used to depict this
relationship. For example, Doctor and Nurse classes might inherit from a
common superclass called HealthcareProfessional.

6. Composition and Aggregation: These relationships would show how

one class contains or is composed of another class. For example, a
Healthcare class may have a composition relationship with the
Department class, indicating that a healthcare consists of multiple
departments.

7. Dependency: This would show when one class relies on another class,
usually through method parameters or return types. For example, the Bill
class may have a dependency on the Patient class to retrieve patient
information for billing purposes.