ADP-CS FINAL PROJECT

Project-1

Hospital Management System

Project Advisor

<Advisor Name>

Presented by:
Group ID: xxxxxxx

Student Reg# Student Name

Faculty of Information Technology

University of Central Punjab

Software Requirements
Specification

Hospital Management System

Advisor: <Advisor Name>

Group <Group ID>

Member Name Primary Responsibility
 <Project Name>

Table of Contents
Table of Contents .......................................................................................................................i
1. Introduction and Background ............................................................................................ 1
1.1 Product (Problem Statement) ................................................................................................... 1
1.2 Background............................................................................................................................. 1
1.3 Scope...................................................................................................................................... 1
1.4 Objective(s)/Aim(s)/Target(s) .................................................................................................. 1
1.5 Completeness Criteria ............................................................................................................. 2
1.6 Business Goals ........................................................................................................................ 2
2. Functional Requirements .................................................................................................... 3
2.1 Functions of System ................................................................................................................ 3
2.2 Requirements Analysis and Modeling ...................................................................................... 4
2.3 Usage Scenarios ...................................................................................................................... 6
2.4 Adopted Methodology ............................................................................................................. 6
3. Nonfunctional Requirements .............................................................................................. 7
3.1 Performance Requirements ...................................................................................................... 7
3.2 Safety Requirements................................................................................................................ 7
3.3 Security Requirements ............................................................................................................. 7
3.4 Additional Software Quality Attributes .................................................................................... 7
4. Other Requirements ............................................................................................................ 8
5. Revised Project Plan ............................................................................................................ 8
6. References ............................................................................................................................ 8
Appendix A: Glossary ............................................................................................................... 9

<Group ID> Project-1 (RS) Page i

 <Project Name>

1. Introduction and Background

Hospital are the essential part of our lives, providing best medical facilities to people suffering from
various ailments, which may be due to change in climatic conditions, increased work-load, emotional
trauma stress etc. It is necessary for the hospitals to keep track of its day-to-day activities & records of
its patients, doctors, nurses, ward boys and other staff personals that keep the hospital running smoothly
& successfully. But keeping track of all the activities and their records on paper is very cumbersome and
error prone. It also is very inefficient and a time-consuming process Observing the continuous increase
in population and number of people visiting the hospital. Recording and maintaining all these records is
highly unreliable, inefficient and error- prone. It is also not economically & technically feasible to
maintain these records on paper.

1.1 Product (Problem Statement)

Keeping the working of the manual system as the basis of our project. We are going to develop an
automated version of the manual system, named as “Hospital Management System”. The main aim of
our project is to provide a paper-less hospital up to 90%. It also aims at providing low-cost reliable
automation of the existing systems. The system also provides excellent security of data at every level of
user- system interaction and also provides robust & reliable storage and backup facilities.

1.2 Background

The hospital management system (HMS) is an integrated software that handles different directions
of clinic workflows. It manages the smooth healthcare performance along with administrative, medical,
legal and financial control. That is a cornerstone for the successful operation of the healthcare facility.
Hospital Management System is a process of implementing all the activities of the hospital in a
computerized automated way to fasten the performance. This project is to maintain the patient details,
lab reports and to calculate the bill of the patient. You can also manually edit any patient details and
issue bill receipt to patient within few seconds.

1.3 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 usages. 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.4 Objective(s)/Aim(s)/Target(s)
The purpose of developing a Hospital Management System is to
 Automate the process of Hospital Management.
 To maintain two user levels i.e.
 Administrator Level
<Group ID> Project-1 (RS) Page 1
 <Project Name>
 User Level
 To maintain the record of patients.
 To provide prescriptions, precautions and dietary advices to patients.
 To provide and maintain all kinds of tests for a patient.

1.5 Completeness Criteria

The Hospital Management System will be successfully completed if it satisfies the following evaluation
criterion.

a) Planned approach towards working: The working in the organization will be well planned and
organized. The data will be stored properly in data stores, which will help in retrieval of
information as well as its storage.
b) Accuracy: The level of accuracy in the proposed system will be higher. All operation would be
done correctly and it ensures that whatever information is coming from the center is accurate.
c) Reliability: The reliability of the proposed system will be high due to the above stated reasons.
The reason for the increased reliability of the system is that now there would be proper storage
of information.
d) No Redundancy: In the proposed system utmost care would be that no information is repeated
anywhere, in storage or otherwise. This would assure economic use of storage space and
consistency in the data stored.
e) Immediate retrieval of information: - The main objective of proposed system is to provide for
a quick and efficient retrieval of information. Any type of information would be available
whenever the user requires.
f) Easy to Operate: The system should be easy to operate and should be such that it can be
developed within a short period of time and fit in the limited budget of the user.

1.6 Business Goals

An online Hospital Management System will offer information about doctor’s availability, work status,
and data acquisition and presentation. It will allow electronic sharing of patient history online, records,
the overall health of patients, lab results, Etc. It will be designed to manage all operations and useful to
Multi-Specialty hospitals, clinics, medical practitioners. Various users can easily interconnect with each
other to communicate and share information. Moreover, patients can find doctors as per their
department and book an online appointment based on the specialty, and convenient date.

<Group ID> Project-1 (RS) Page 2

 <Project Name>

2. Functional Requirements

2.1 Functions of System

The system will allow access only to authorized users with specific roles (Administrator, Operator).
Depending upon the user’s role, he/she will be able to access only specific modules of the system. A list
of the major functions that the software will perform is given below:

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 an ID and add it to the patient’s
record. This ID shall be used by the patient throughout his/her stay in hospital.

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.

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

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.

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 Availability: Every six hours the system shall generate reports on bed availability about the
following information: ward name, bed number, occupied/unoccupied

<Group ID> Project-1 (RS) Page 3

 <Project Name>
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.
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.

2.2 Requirements Analysis and Modeling

Use Case Diagram:

<Group ID> Project-1 (RS) Page 4

 <Project Name>

Activity Diagram:

<Group ID> Project-1 (RS) Page 5

 <Project Name>
2.3 Usage Scenarios

Identifier Add patient

This function gets details of a patient and add
Purpose record to the patient file and generate a patient
registration number
Priority High
Pre-conditions The operator should login with user account.
Post-
conditions Patient record added to patient file.
Typical Course of Action
S# Actor Action System Response
1. User selects “add patient Patient entry form displayed3.
1
entry” at home page.
User enter data to required
2 fields. Record added successfully,
message displayed.
User selects “Add entry Button”
3 System generates a patient Id
and display.
Alternate Course of Action
S# Actor Action System Response
1 Prompt user to enter all
if required fields left by user required fields
Reload the home page
2 If add patient option is not
visible at home page Search the option in search
bar.
Table 1: UC-1 (Add Patient)

2.4 Adopted Methodology

Hospital management system can be developed by using waterfall model which is a popular version
of development life cycle model for software engineering. It describes a development method that is
linear and sequential. It has distinct goals for each phase of development. In this model once, a phase of
development is completed, there is no turning back, the development proceeds to the next phase. The
advantage of this model is that it allows for departmentalization and managerial control.

<Group ID> Project-1 (RS) Page 6

 <Project Name>

3. Nonfunctional Requirements
3.1 Performance Requirements
 Response time: The system will give responses within 1 second after checking the patient
information and other information.
 Capacity: The system must support 1000 people at a time.
 User interface: User interface screen will response within 5 seconds.
 Conformity: The system must conform to the Microsoft accessibility

3.2 Safety Requirements

If there is extensive damage to a wide portion of the database due to catastrophic failure, such as
a disk crash, the recovery method restores a past copy of the database that was backed up to
archival storage and reconstructs a more current state by reapplying or redoing the operations of
committed transactions from the backed-up log, up to the time of failure.

3.3 Security Requirements

All the administrative and data entry operators have unique logins so system can understand who
is login in to system right now no intruders allowed except system administrative nobody cannot
change record and valuable data.

3.4 Additional Software Quality Attributes

The Quality of the system is maintained in such a way so that it can be very user-friendly. The software
quality attributes are assumed as under:

 AVAILABILITY: The system shall be available all the time.

 CORRECTNESS: A bug free software which fulfill 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.

 ACCURACY: The reliability on the information/output. Can depend/be sure of the outcome.

 STABILITY: The system outcome/output won’t change time to time. Same output will be
given always for a given input

<Group ID> Project-1 (RS) Page 7

 <Project Name>

4. Other Requirements
A degraded mode of operation should be possible in which each system can operate independently of
central scheduling. The software shall have failure and error recognition codes acting as a safety net,
thus keeping the software from performing any major catastrophic functions.

5. Revised Project Plan

Task Name Duration Start Date End Date Status
Idea No of Days to Starting Date Proposed Ending Finished or In
complete the of Task Date of Task Progress
task
Scope
Functional and Non-
Functional Requirements
Use Case/ Activity
Diagrams
Usage Scenarios
Work Plan
Design Phase
Database Design
Architectural Design
Detailed Design
User Interface
Testing
Final Results

6. References
<List all books, conference papers, journal articles, websites, etc. used in preparing the content of
this SRS. Provide enough information so that the reader could access a copy of each reference,
including title, author, volume/edition number, page number(s), and publication year. Mention
complete URLs for websites.>

<Group ID> Project-1 (RS) Page 8

 <Project Name>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations.
You may wish to build a separate glossary that spans multiple projects or the entire organization,
and just include terms specific to a single project in each SRS.>

<Group ID> Project-1 (RS) Page 9