SOFTWARE REQUIREMENTS

SPECIFICATION

HOSPITAL MANAGEMENT
SYSTEM

J.Manogna AP19110010153
K.MohananjaliAP19110010182
SK.HashithaAP19110010301
 Table of
Contents
1. Introduction
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms, and Abbreviations 3
1.4 References 4
1.5 Overview 5
2. The Overall Description
2.1 Product Perspective 2
0
2.2 Product Functions 5
2.3 User Characteristics 7
2.4 Constraints 7
2.5 Assumptions and Dependencies 8
3. External interface Requirements
3.1 User Interfaces 9
3.2 Hardware Interfaces 9
3.3 Software Interfaces 1
0
3.4 Communications Interfaces 1
0
4. System Features 1
5. Other Non-Functional Requirements 0
5.1 Performance Requirements 1
5.1.1 Capacity 1
5.1.2 Dynamic Requirements 1
5.1.3 Quality 1
1
1
1
2
5.2 Software System Attributes 1
2
3.6.1 Reliability 1
2
3.6.2 Availability 1
2
3.6.3 Security 1
3
3.6.4 Maintainability 1
5.3 Business Rules 3
1
4
1. Introduction

1.1 Purpose

The purpose of this project is to develop software which is user-friendly, cost

effective and fast. It deals with the collection of patient information, doctor
information. The main function of this is to store patients and doctor details and use
them for later purposes. The hospital management system can enter a username and
password which will be accessible by only the doctor, and admin.
1.2 Scope

The technology will be used to collect data from patients, doctors and store it
for later use. A paper-based method is now in use. It is inefficient and unable to
supply updated patient lists in a timely manner and it requires so much space to
store the data. If someone wants details of old patients and doctors, searching for
those records will be a huge task. The system's goals are to minimize overtime pay
while also increasing the number of patients who can be appropriately treated and
doctors who can treat more patients. There are functional and non-functional
requirements statements in this document
1.3 Definitions, Acronyms, and Abbreviations.

HPIMS Hospital Patient Info Management system

PHN Personal Health Number on health card
Report an account of patients

Front-desk administrative staff that work at reception desk

staff
Logon ID a user identification number to enter the system
Password a word that enables one to gain admission into the
system.
Web- an application that runs on internet
based
applicatio
n
MySQL a query language to interrogate the system
GUI Graphical User Interface
SRS Software Requirements Specification
 1.3 References

The references for the above software are as follows:-

i. www.google.co.in

ii. www.winkipedia.com

1.4 Overview

Section 1.0 discusses the purpose and scope of the software.

Section 2.0 describes the overall functionalities and
constraints of the software and user
characteristics.
Section 3.0 details all the requirements needed to design the software.

2. The Overall Description

2.1 Product Perspective

This Hospital Management System is a self-contained system that manages

activities of the hospital as Patient Info such as patient name, dob, patient disease and
patient, delete patient, search patient, doctors info such as appointment, doctor activity,
no.of patients the doctor is handling, add doctor, delete doctor, admin info admin
activity, doctor management, patient management,
 2.2 Product Functions

Registration: When a patient is admitted, the staff checks to see if the

patient is already registered with the hospital. If the patient registration
number is entered into the computer or not Otherwise a new registration
number is given to the patient. The patient’s information such as date of
birth, address and telephone number is also entered into the computer
system.

Patient check out. If a patient checks out, the administrative staff will
delete the patient's bed details from the system and the just evacuated bed
is included in available-beds list.

Report Generation: The system generates reports on List of detailed

information regarding the patient who has been admitted into the hospital.

2.3 User Characteristics

The system will be used in the hospital. The administrators and staff will be
the main users. Some users may not know how to use computers. So, 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).

Staff:
All the staff will have general reception and secretarial duties. Every staff
member has some basic computer training. They are responsible for patient’s
check-in or notification of appropriate people .

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.

Constraints

The major constraints that the project has are as follows:-

 ● system must be user friendly
● maintenance cost should be less
● The user information cannot be disclosed to third party
● Patient details should not be altered or edited by other doctors who are
not assigned to them

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.External Interface Requirements

3.1User Interface Requirements

The interface provided to the user should be a very user-friendly one and it
should provide an optional interactive help for each of the services listed. The
interface provided is a menu driven one and the following screens will be
provided:-
Patient login: patient can choose the doctor and do appointments.
Doctor login: doctor can check the schedule.
Admin login: can see the doctor and patient details, schedules.
Can delete, access the data.
3.2 Hardware Interface Requirements
Operating system : windows
processor : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz 1.80
8GB RAM
3.3 Software Interface Requirements
Database: django
Server: sql
Language:python

3.4 Communication Interface Requirements

 window

4. System Features

Login module:
This module records only the user and password of the user.
Administration module:
This module enables the user to insert, update, view and delete the patient
information.
Patient module:
This module is used to store information about patients who were admitted in the
hospital
→ Patient Id, disease, Doctor, Date of admitted, Date of discharge.
→ Updation like deletion and modification is done.
Doctor’s module:
doctors info such as appointment, doctor activity, no.of patients the doctor is handling,
add doctor, delete doctor is managed.

5.other Nonfunctional Requirements

5.1Performance Requirements
● After reviewing the patient details and other information, the system will
respond within one second.
● Capacity: The system must be able to support 1000 persons at once.
● The user interface screen will respond in less than 5 seconds.
● Conformity – The system must adhere to Microsoft's accessibility guidelines.

5.1.1 Quality – The primary objective is to produce quality software.

As the quality of a piece of software is difficult to measure
quantitatively, the following guidelines will be used when judging
the quality of the software:

1. Consistency – All code will be consistent with respect to the

style. (This is implied when adhering to the standard).
2. Test cases – All functionality will be thoroughly tested

5.1.2 Safety requirements:

If a catastrophic failure, such as a disc crash, causes
extensive damage to a large portion of the database, the recovery method restores a
previous copy of the database that was backed up to archival storage and reconstructs a
more current state by reapplying or redoing committed transaction operations from the
backed up log, up to the time of failure.

5.1.3 Security requirements:

All administrative and data input operators have
unique logins, so the system can tell who is currently logged in. No intruders are allowed
except system administrators, and no one can edit records or sensitive data.

5.2Software System Attributes

1.Accessibility: The framework will be accessible constantly.

2.Rightness: A bug free programming which satisfies the right need/necessities of the
client.
3.Practicality: The capacity to keep up with change data and update fix problems of the
framework
4. Ease of use: programming can be utilized over and over without contortion.
5.Availability: Administrator and numerous different clients can get to the framework yet
the entrance level is controlled for every client as per their work scope.

5.3Business Rules

The business rules for the software are as follows:

 Want to the obligations of disasters because of hardware

malfunctioning.
 Warranty length of preserving the software program might be one year
 Additional bills may be analyzed and fee for in addition maintenance
 If any mistakes arise because of a user's unsuitable use. warranty will
now no longer be allotted to it.
 No cash again returns for the software program
 Trust hond placement ought to be performed earlier than designing and
coding .An strengthen or an agreement.

6 Other Requirements
None.