+

EXPERIMENT – 3
AIM: Write the Software Requirement Specification Document of the case study i.e.
“Hospital Patient Management System (HPMS)”.

SOFTWARE REQUIREMENT SPECIFICATION:

TABLE OF CONTENTS FOR SRS DOCUMENT:

1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, Acronyms and Abbreviations
1.4. References
1.5. Overview

2. Overall Description
2.1. Product perspective
2.1.1. System Interfaces
2.1.2. User Interfaces
2.1.3. Hardware Interfaces
2.1.4. Software Interfaces
2.1.5. Communication Interfaces
2.1.6. Memory Constraints
2.1.7. Operations
2.1.8. Site Adaptation Requirements

2.2. Product Functions

2.3. User Characteristics
2.4. Constraints
2.5. Assumptions for dependencies

3. Specific Requirements
3.1. External Interface Requirements
3.1.1. User Interfaces
3.1.2. Hardware Interfaces
3.1.3. Software Interfaces
3.1.4. Communication Interfaces
+

3.2. Functional Requirements

3.2.1. Registration
3.2.2. Consultation
3.2.3. Medical matter management
3.2.4. Check Out
3.2.5. Report Generation
3.2.6. Database
3.3. Performance Requirements
3.4. Software System Attributes
3.5. Design Constraints
+

1. Introduction
1.1 Purpose
The purpose is to describe all the requirements for the Hospital Management System. The
following are some of the stake holders:
• administrative staff
• doctors
• nurses
• surgeons
• developers.
The hospital management and its team members uses this document as the primary means to
communicate confirmed requirements to the development team. The development team
expects many face-to-face conversations that will undoubtedly be about requirements and
ideas for requirements. However only the requirements that appear in this document or a
future revision, will be used to define the scope of the system.

1.2 Scope
The software product is the Hospital Management System. The system will be used to
allocate beds to patients on a priority basis, and to assign doctors to patients in designated
wards as need arises. Doctors will also use the system to keep track of the patients assigned to
them. Nurses who are in direct contact with the patients will use the system to keep track of
available beds, the patients in the different wards, and the types of medication required for
each patient. Doctors must make rounds to pick up patients’ treatment cards in order to know
whether they have cases to treat or not. 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 Definitions, acronyms and abbreviations SRS:

PHN Personal Health Number on health card
Report An account of patients
Database Collection of information in a structured form
Front-desk staff Administrative staff that work at reception desk
Logon ID A user identification number to enter the system
Password A word that enables one to gain admission into the system
ID Patient Identification number
GUI Graphical User Interface
SRS Software Requirements Specification

1.4 References
a) Lauesen, S, (2003),Task Descriptions as Functional Requirements, IEEE Computer
Society,Available:http://www.itu.dk/~slauesen/Papers/IEEEtasks.pdf
+

1.5 Overview
This Software Requirements Specification (SRS) is the requirements work product that
formally specifies Hospital Patient Info Management System (HPIMS). 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. The sections of the SRS document that lies ahead are: Overall Description,
Specific Requirements and Supporting Information.
+

2. Overall Description
2.1. Product Perspective
The HPMS is a software developed for registration of patients and generating their
final reports. It is also responsible for ensuring smooth process of consultation for the
patients. It
makes life easy for the people running the hospital as two very big tasks that is
manual
registration and report generation with the help of the software. It also takes care of
database.

The administrator will have to maintain the following information:

• Patient Details
• Doctor Details
• Report Details

The administrator will perform the following functions:

• Complaint Resolution
• Report Generation
• Bed Allocation
• Payroll Management and patient management

The patient requires the following information from the system:

• Available Beds
• Final Reports

2.1.1 System Interfaces

None

2.1.2 User Interfaces

The HPMS will have the following user-friendly and menu-driven interfaces:

(a) Login: to allow the entry of only authorized patients/doctors through valid login ID and
password.
(b) Patient Details: to maintain database of patients.
(c) Report Details: to maintain patient reports.
(d) Bed Details: to make beds available for patient to avail.
(e) Complaint Registration: to register a complaint if any anomaly is found.

The software should generate the following information:

(a) Report of each patient.
(c) Patient registered for each bed.
+

2.1.3 Hardware Interfaces

 Laptop/Desktop PC
 core i5 processor
 4GB RAM
 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action, it needs very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
 Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come to see their
consultants. It will avoid chaos. And also display Hospital welcome screen, video,
information etc.
 Laser Printer (B/W)
Simply this device is for printing bills and view reports.
 Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a hospital and simply data
transmission from pc’s to sever.

2.1.4 Software Interfaces

(a) MS-Windows Operating System (XP/Vista/8/10)
(b) HTML and CSS for designing front end.
(c) PHP and MySQL for designing the back end.

2.1.5 Communication Interfaces

In the URMS, communication is via local area network (LAN) and it is a web-enabled
system.

2.1.6 Memory Constraints

At least 2 GB RAM and 1 GB space of hard disk will be required to run the software.

2.1.7 Operations
None

2.1.8 Site Adaptation Requirements

The terminal at the client side will have to support the hardware and software interfaces
specified in sections 2.1.3 and 2.1.4, respectively
+

2.2 Product Functions

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.

Consultation: The patient goes to consultation-desk to explain his/her condition so that the
consulting nurse can determine what kind of ward and bed should be assigned to him/her.
There are two possible circumstances:
a) If there is a bed then the patient will be sent to the bed to wait for the doctor to come.
b) If there is no bed, the patient is put on a waiting list until a bed becomes available.

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.

Report Generation: The system generates reports on the following information: patients,
bed availability and staff schedules after every six hours. It prints out all the information on
who has used which bed, when and the doctor that is taking care of a given patient as well as
expected medical expenses.

2.3 User Characteristics

The system will be used in the hospital. The administrators, doctors, nurses and front-desk
staff will be the main users. Given the condition that not all the users are computer-literate.
Some users may have to be trained on using the system. The system is also designed to be
user-friendly. It uses a Graphical User Interface (GUI).

Front-desk staff: They all have general reception and secretarial duties. Every staff has
some basic computer training. They are responsible for patient’s check-in or notification of
appropriate people (e.g. notify administrator or nurse when an event occurs).

Administrators: They all have post-secondary education relating to general business

administration practices. Every administrator has basic computer training. They are
responsible for all of the scheduling and updating day/night employee shifts. Administrators
in the wards are responsible for assigning doctors and nurses to patients.

Nurses: All nurses have post-secondary education in nursing. Some nurses are computer
literate. Consulting nurses to whom patients give short descriptions of their conditions are
also responsible for assigning patients to appropriate wards if the beds are available,
+

otherwise putting patients on the waiting list. Nurses in wards will use the system to check
their patient list

Doctors: All doctors have a medical degree. Some have further specialized training and are
computer literate. Doctors will use the system to check their patient’s list.

2.4 Constraints
 The system must be delivered by deadline.
 The system must be user-friendly

2.5 Assumptions for dependencies

 It is assumed that 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. Specific Requirements
This section contains the software requirements in detail along with the various forms to be
developed.

3.1 External Interface Requirements

3.1.1 User Interfaces

The HPMS will have the following user-friendly and menu-driven interfaces:

(a) Login: to allow the entry of only authorized patients/doctors through valid login ID and
password.
(b) Patient Details: to maintain database of patients.
(c) Report Details: to maintain patient reports.
(d) Bed Details: to make beds available for patient to avail.
(e) Complaint Registration: to register a complaint if any anomaly is found.

The software should generate the following information:

(a) Report of each patient.
(c) Patient registered for each bed.

3.1.2 Hardware Interfaces

 Laptop/Desktop PC
 core i5 processor
 4GB RAM
 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action, it needs very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
 Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come to see their
consultants. It will avoid chaos. And also display Hospital welcome screen, video,
information etc.
 Laser Printer (B/W)
Simply this device is for printing bills and view reports.
 Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a hospital and simply data
transmission from pc’s to sever.

3.1.3 Software Interfaces

(a) MS-Windows Operating System (XP/Vista/8/10)
(b) HTML and CSS for designing front end.
(c) PHP and MySQL for designing the back end.
+

(d) HTML/CSS to design the frontend.

3.1.4 Communication Interfaces

 NIC (Network Interface Card) – It is a computer hardware component that allows a

computer to connect to a network. NICs may be used for both wired and wireless
connections.
 CAT 5 network cable- for high signal integrity
 TCP/IP protocol- Internet service provider to access and share information over the
Internet
 Ethernet Communications Interface- Ethernet is a frame-based computer network
technology for local area networks (LANs)
 Ubiquitous, easy to set up and easy to use. Low cost and high data transmission rates.

3.2 Functional Requirements

3.2.1 Registration
 Add patients
The system shall allow front-desk staff to add new patients to the system.
 Assign ID
The system shall allow front-desk staff to give each patient a ID and add it to the
patient’s record. This ID shall be used by the patient throughout his/her stay in
hospital.

3.2.2 Consultation
 Assign Ward
The consulting nurse shall use system to assign the patient to an appropriate ward.
 Assign to Waiting List
The consulting nurse shall use system to assign Patient to a waiting list if no bed is
available.

3.2.3 Medical matter management

 Assign Doctor
The administrative staff in the ward shall use system to assign a doctor to a given
patient.
 Assign Nurse
The administration staff in the ward shall use system to assign a nurse to a given
patient.
 Inform Doctors
The system shall inform doctors of new patients.
 Inform Nurses
The system shall inform nurses of new patients.
 Emergency Case
In an emergency case, the administrative staff shall use system to assign an
emergency room, doctors and nurses to the patient immediately.
+

 Surgery case
In a surgery case, the administrative staff shall use system to assign a surgery room,
surgeon and nurses to the patient.
 Generate Report (normal)
The system shall generate the patient’s situation record every two hours for normal
patients.
 Generate Report (Severe)
The system shall generate patient’s situation record every half hour for severe
patients.
 Record procedure
The whole treatment procedure for the patient shall be recorded by the system.
 Inform patient
The system shall automatically inform the patients who are on the bed waiting list of
available beds whenever they become available.

3.2.4 Check Out

 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.

3.2.5 Report Generation

 Patient information
Every six hours the system shall generate reports on patients about the following
information: patient’s PHN, patient’s name, ward name, bed number and the doctor’s
name.
 Bed Aavailability
Every six hours the system shall generate reports on bed availability about the
following information: ward name, bed number, occupied/unoccupied
 Staff Schedule
Every six hours the system shall generate reports on staff schedule about the
following information: staff ID, staff name, staff type, duty shift.

3.2.6 Database
 Patient Mandatory Information
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 system shall allow the user to update any of the patient’s information
 Search for Patient
The system shall allow the user to search for patient’s information by last name or
PHN or patient ID.
 Staff Mandatory Information
Each staff in hospital shall have the following mandatory information: identification
number, first name, last name, phone number, address, postal code, city, country,
employee type, duty schedule.
+

 Update Staff Information

The system shall allow the user to update any of the staff’s information as described
in SRS023.
 Employee Information
The system shall allow the user to search for employee information by last name, or
ID number.
 Ward Types
The ward is categorized into four types: Maternity, Surgical, Cancer and Cardiac.
 Ward Information
Each ward in system shall include the following mandatory information: ward name,
ward number, list of rooms in ward.
 Room Information
Each room in system shall include the following mandatory information: room
number, list of beds in room, full/not full.
 Bed Information
Each bed in system shall include the following information: bed number,
occupied/unoccupied, patient PHN.

3.3 Performance Requirements

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

3.4 Design 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.

3.5 Software System Attributes

 AVAILABILITY: The system shall be available all the time.
 CORRECTNESS: A bug free software which fulfil the correct need/requirements of
the client.
 MAINTAINABILITY: The ability to maintain, modify information and update fix
problems of the system
 USABILITY: software can be used again and again without distortion.
+

 ACCESSIBILITY: Administrator and many other users can access the system but
the access level is controlled for each user according to their work scope.