Bachelor of Science in Computer Science and Information Technology (B.Sc.

CSIT)

BIRAT KSHITIZ COLLEGE

Affiliated to T.U.

Biratnagar, Nepal

SOFTWARE REQUIREMENT SPECIFICATION (SRS)

ON

HOSPITAL MANAGEMENT SYSTEM

Submitted By:

 Dhiraj Pradhan (6068/071)

 Sanjay Karki (6079/071)

Date of Submission: 2074-10-15

ABSTRACT
“Hospital Management System” (HMS) is a web-based application designed for hospitals to
keep the record of the hospital in database. This software manages all information about patient
name, patient address, doctor information, staff information etc. It also store daily information of
patient which is done by doctor. Also stores information about billing, finally it calculate total
bill of patient.

ii
Contents
ABSTRACT....................................................................................................................................ii

List of Figures..................................................................................................................................v

1. INTRODUCTION....................................................................................................................1

1.1. Purpose..............................................................................................................................1

1.2. Scope.................................................................................................................................1

1.3. Overview...........................................................................................................................1

2. GENERAL DESCRIPTION....................................................................................................3

2.1. Product Perspective...........................................................................................................3

2.2. Product Features................................................................................................................3

2.3. Design and Implementation Constraints...........................................................................3

2.4. Assumptions and Dependencies........................................................................................3

3. FUNCTIONAL REQUIREMENTS.........................................................................................4

3.1. Description........................................................................................................................4

3.2. Technical Issues................................................................................................................5

4. INTERFACE REQUIREMENTS............................................................................................6

4.1. User Interface:...................................................................................................................6

4.2. Hardware Interface............................................................................................................6

4.3. Software Interface:............................................................................................................6

5. SOFTWARE REQUIREMENT ANALYSIS..........................................................................7

5.1. Define Problem.................................................................................................................7

5.2. Define Module and Functionality.....................................................................................7

6. SOFTWARE DESIGN.............................................................................................................8

6.1. State Diagram....................................................................................................................8

 6.2. Class Diagram.................................................................................................................10

6.3. Sequence Diagram..........................................................................................................11

6.4. E-R Diagram...................................................................................................................12

7. NON FUNCTIONAL REQUIREMENTS.............................................................................13

7.1. Performance....................................................................................................................13

7.2. Security...........................................................................................................................13

7.3. Availability......................................................................................................................13

7.4. Safety..............................................................................................................................13

7.5. Software Quality.............................................................................................................13

7.6. Reusability......................................................................................................................14

7.7. Maintainability................................................................................................................14

8. CONCLUSION......................................................................................................................14

9. REFERENCE.........................................................................................................................15
List of Figures
Figure 1- State Diagram for Doctor Object....................................................................................8
Figure 2- State Diagram for Patient Object....................................................................................9
Figure 3- Class Diagram...............................................................................................................10
Figure 4- Sequence Diagram.........................................................................................................11
Figure 5- E-R Diagram.................................................................................................................12
1. INTRODUCTION

1.1.Purpose
 The software is for the automation of Hospital Management.
 It maintains two levels of users:
i. Administrator Level
ii. User Level
 The Software includes maintaining patient details.
 Providing prescription, precautions and diet advice.
 Providing and maintaining all kinds of tests for a patient.
 Billing and report generation.

1.2.Scope
 The proposed software product is the Hospital Management System (HMS). The system
will be used to get the information from the patients and then storing that data for future
usage.
 The current system in use is a paper-based system. It is too slow and cannot provide
updated lists of patients within a reasonable timeframe.
 The intentions of the system are to reduce over-time pay and increase the number of
patients that can be treated accurately.
 Requirements statements in this document are both functional and non-functional.

1.3.Overview
This Software Requirements Specification (SRS) is the requirement work product that
formally specifies Hospital Management System (HMS). It includes the results of both
business analysis and systems analysis efforts. Various techniques were used to elicit the
requirements and we have identified your needs, analyzed and refined them. The
objective of this document therefore is to formally describe the system’s high level
requirements including functional requirements, non-functional requirements and
business rules and constraints.

1
The detail structure of this document is organized as follows:

Section 2 of this document provides an overview of the business domain that the proposed
Hospital Management System (HMS) will support. These include a general description of the
product, user characteristics, general constraints, and any assumptions for this system. This
model demonstrates the development team's understanding of the business domain and
serves to maximize the team's ability to build a system that truly does support the
business.

Section 3 presents the detail requirements, which comprise the domain model.

 Urine Test
 X-Ray
 Stool Test
 Sonography Test
 Gastroscopy Test
 Colonoscopy Test
 Blood Test
 Biochemistry Test
 Maintaining patient’s injection entry records

2
2. GENERAL DESCRIPTION

2.1.Product Perspective
Hospital Management System (HMS) is a self-contained system that manages activities
of the hospital and patient information. Various stakeholders are involved in the hospital
patient information system.

2.2.Product Features
The system functions can be described as follows:

Registration: When a patient is admitted, the front-desk staff checks to see if the
patient is already registered with the hospital.

 If he is, his/her Personal Health Number (PHN) is entered into the computer.
Otherwise a new Personal Health Number is given to this patient.
 The patient’s information such as date of birth, address and telephone number is also
entered into computer system.

Patient check out: If a patient checks out, the administrative staff shall delete his PHN
from the system and the just evacuated bed is included in available-beds list.

Generation: The system generates reports on the following information: list of detailed
information regarding the patient who has admitted in the hospital.

2.3.Design and Implementation Constraints

Database: The system shall use the MySQL Database, which is open source and free.

Operating System: The Development environment shall be Windows 2000.

Web-Based: The system shall be a Web-based application.

2.4.Assumptions and Dependencies

 It is assumed that one hundred IBM compatible computers will be available before
the system is installed and tested.
 It is assumed that the Hospital will have enough trained staff to take care of the
system.

3
3. FUNCTIONAL REQUIREMENTS

3.1.Description
Registration:

 Add Patients:

The HMS shall allow front-desk staff to add new patients to the system.

 Assign ID:

The HMS shall allow front-desk staff to give each patient an ID and add it to the
patient’s record. This ID shall be used by the patient throughout his/her stay in hospital.

 Delete Patient ID:

The administrative staff in the ward shall be allowed to delete the ID of the patient from
the system when the patient checks out.

 Add to Beds Available List:

The administrative staff in the ward shall be allowed to put the beds just evacuated in
beds-available list.

Report Generation:

 Patient Information:

The HMS shall generate reports on patients about the following information: patient’s
ID, patient’s name, ward name, bed number and the doctor’s name which was assigned.

 Bed Availability:

The HMS shall generate reports on bed availability about the following information:
ward name, bed number, occupied/unoccupied.

4
5
 Database:

 Patient Mandatory:

Each patient shall have the following mandatory information: first name, last name,
phone number, personal health number, address, postal code, city, country, patient
identification number.

 Update Patient Information:

The HMS shall allow the user to update any of the patient’s information.

3.2.Technical Issues
 Database:

The system shall use the MySQL Database, which is open source and free.

 Operating System:

The Development environment shall be Windows 7.

 Web-Based:

The system shall be a Web-based application.

6
4. INTERFACE REQUIREMENTS

4.1.User Interface:
 The software provides good graphical interface for the user any administrator can
operate on the system, performing the required task such as create, update, viewing the
details of the book.
 Allows user to view quick reports like Book Issues/Returned etc in between particular
time.
 Stock verification and search facility based on different criteria.

4.2.Hardware Interface
 Operating System: Windows
 Hard Disk: 40 GB
 RAM: 1GB
 Processor: Dual-core CPU and more.

4.3. Software Interface:

 Java Language
 Net Beans IDE 7.0.1
 MySQL Server

7
5. SOFTWARE REQUIREMENT ANALYSIS

5.1.Define Problem
We develop the hospital management system for the hospital staff and other department
of hospital for keeping record of the patient, doctors, nurses, beds, etc.

5.2.Define Module and Functionality

The system functions can be described as follows:

 Registration:

When a patient is admitted, the front-desk staff checks to see if the patient is already
registered with the hospital. If he is, his/her Personal Health Number (PHN) is entered
into the computer. Otherwise a new Personal Health Number is given to this patient.
The patient’s information such as date of birth, address and telephone number is also
entered into computer system.

 Patient Check out:

If a patient checks out, the administrative staff shall delete his PHN from the system
and the just evacuated bed is included in available-beds list.

8
6. SOFTWARE DESIGN

6.1.State Diagram
State Diagram for Doctor Object

Figure 1- State Diagram for Doctor Object

9
State Diagram for Patient Object:

Figure 2- State Diagram for Patient Object

10
6.2.Class Diagram

Figure 3- Class Diagram

11
6.3.Sequence Diagram

Figure 4- Sequence Diagram

12
6.4.E-R Diagram

Figure 5- E-R Diagram

13
7. NON FUNCTIONAL REQUIREMENTS

7.1.Performance
 The system shall give responses in 1 second after checking the patient’s information.
 The System must support 1000 people at a time.
 The user-interface screen shall respond within 5 seconds.
 The systems must conform to the Microsoft Accessibility.

7.2.Security
 The system requires the patient to identify him /her using Personal Heath Number
(PHN).
 Any user who uses the system shall have a Logon ID and Password.
 Any modification (inert, delete, update) for the Database shall be synchronized and only
by the administrator in the ward.
 Front Desk staff shall be able to view all information in HMS, add new patients to HMS
but shall not be able to modify any information in it.
 Administrators shall be able to view and modify all information in HMS.

7.3.Availability
The system shall be available anytime.

7.4.Safety
Humans are error-prone, but the negative effects of common errors should be limited.
E.g. users should realize that a given command will delete data, and be asked to confirm
their intent or have the option to undo.

7.5.Software Quality
Good quality of the framework which produces robust, bug free software which contains
all necessary requirements Customer satisfaction.

14
 7.6.Reusability
It is part of the code going to be used elsewhere which produces simple and independent
code modules that can be reused.

7.7.Maintainability
 The system shall provide the capability to back-up the Data.
 The system shall keep a log of all the errors.

8. CONCLUSION
This project “Hospital Management System” is designed to solve the problem regarding
managing the hospital. With the development, the hospital staff can easily view the number
of patients, keep record of patient’s information, number of beds available, doctors available
and appointments of patients with the doctor and so on.

15
9. REFERENCE
 http://www.jaysonjc.com/programming/how-to-write-a-software-requirements-
specification-srs-document.html
 https://www.slideshare.net/kataria55/srs-for-hospital-management-system

16