Table of Contents

1.Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, And Abbreviations
1.4 References
1.5 Overview
2. User Classes and Characteristics
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 System Specifications
2.1.2.1 H/W Requirement
2.1.2.2 S/W Requirement
2.1.3 Communication Interfaces
2.2 Product functions
2.3 Use Case Description
2.4 User characteristics
2.5 Constraints
2.6 Assumptions and dependencies
3. Design and Implementation Constraints
3.1 Performance Requirements
3.2 Safety Requirements
3.3 Security Requirements
3.4 Software System Attributes
3.4.1 Usability
3.4.2 Availability
3.4.3 Correctness
3.4.4 Maintainability
3.4.5 Accessibility
4. Other Requirements
1.Introduction
1.1 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.

1.2 SCOPE

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.

1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS

1. Cardiologist - treats heart disease.

2. Pediatrician - treats infants, toddlers, children and teenagers.
3. Plastic Surgeon - restores, reconstructs, corrects or improves in the shape and appearance
of damaged body structures, especially the face.
4. Psychiatrist - treats patients with mental and emotional disorders. 5. Ophthalmologist -
treats eye defects, injuries, and diseases
6. ENT- Ear, Nose and Throat Specialist.
• SRS: Software Requirement Specification.
• DFD: Data Flow Diagram.
• ENT- Ear, Nose and Throat Specialist.
• BG - Blood group
 Appt – Appointment.
 Sign up - Creating New User.
 Log in - Logging in Existing User.
 PhNo - Mobile number.
 Addr – Address.
 Expr – Experience.

1.4 REFERENCES

• https://www.officetimeline.com/make-gantt-chart/excel
• https://medium.com/@datamateuaecrescent/hospital-management-systemfeatures-
objectives-62eeb13f4fc4
 • R.S Pressman, Software Engineering: A Practitioner’s Approach, Mc-Graw-Hill,
Edition-7 (2010).
• P. Jalote, an Integrated Approach to Software Engineering, Narosa publication house,
Edition -3 (2011).

1.5 OVERVIEW

Our application contains two modules – the admin module and the user module. Our
application will not only help the admin to preview the monthly and/or yearly data but
it will also allow them to edit, add or update records. The software will also help the
admin to monitor the transactions made by the patients and generate confirmations for
the same. The admin will be able to manage and update information about doctors.
The user module can be accessed by both the doctors and the patients. The doctor can
confirm and/or cancel appointments. The doctors can even add prescriptions for their
patients using our application. The patients will be able to apply for the appointment
and make transaction for the same, and can even cancel appointments with the doctors.
They can track details about the previous transactions made by them.

Advantages

• The system automates the manual procedure of managing hospital activities.

• Doctors can view their patients’ treatment records and details easily.
• It even generates an instant bill.
• The system is convenient and flexible to be used.
• It saves their time, efforts, money and resources.

Disadvantages

• Requires large database.

• The admin has to manually keep updating the information by entering the details in
the system.
• Need Internet connection.
2. User Classes and Characteristics
2.1 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.

2.1.1 System Interfaces

❖ User Interfaces
• This section provides a detailed description of all inputs into and outputs from the
system. It also gives a description of the hardware, software and communication
interfaces and provides basic prototypes of the user interface.
• The protocol used shall be HTTP.
• The Port number used will be 80.
• There shall be logical address of the system in IPv4 format.

❖ Hardware Interfaces
• Laptop/Desktop PC-Purpose of this is to give information when Patients ask
information about doctors, medicine available lab tests etc. To perform such
Action it need very efficient computer otherwise due to that reason patients
have to wait for a long time to get what they ask for.
• Laser Printer (B/W) - This device is for printing patients’ info etc.
• 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.

❖ Software Interfaces
• JDK 1.8 - Java is fast, secure, and reliable. From laptops to data centers, game
consoles to scientific supercomputers, cell phones to the Internet,
• Mysql server - Database connectivity and management
• OS Windows 7/8/8.1- Very user friendly and common OS
• JRE 1.8 - JAVA Runtime Environment for run Java Application and System

2.1.2 System Specifications

2.1.2.1 H/W Requirement

  Core i5 processor  2GB Ram.
 20GB of hard disk space in terminal machines
 1TB hard disk space in Server Machine

2.1.2.2 S/W Requirement

 Windows 7 or above operating system
 JRE 1.8
 Mysql server

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

2.3 Product functions

o Provide access to registered users only.

o Registration of new patients. o Enable patient to view their record. o Enable patient to
update their record. o Generate appointment date and timing.
o Confirmation by doctor. o Patients can do Payment. o Modification in schedule by
patient. o Admin access to patient’s record.
o Admin Verify Payment and Generate Bill/Receipt.
o Admin can view monthly/yearly records.

2.4 Use Case Description

(1) PATIENT

* REGISTRATION
DESCRIPTION - The new patient can register themselves and add their details like name,
age , gender, blood group etc. The patient entry will be made in the hms database.

PRE -CONDITION – The patient must be a new patient, If necessary fields left by user then
prompt user to fill the necessary fields.

MAIN FLOW OF EVENTS

1. Patient selects sign up in login
module. 2. A registration form get
displayed
3. Patient fills the required details.

POST CONDITIONS - Patient record is added to hms database.

* UPDATION
DESCRIPTION-The patient should be enabled to update his/her details and the changes
should reflect in hms database.

PRE-CONDITION – The patient must be a registered patient, The patient cannot update
details after treatment starts.

MAIN FLOW OF EVENTS

1. Patient logs in to the system.
2. Patient view his record
3. Patient selects update details.
4. Now patient may change the necessary fields.
5. Pop of update details.

POST CONDITION - The record of patient is updated in hms database.

*APPOINTMENT
DESCRIPTION - It shows users a list of available doctors, timings, dates and enables patients
to select the most suitable appointment date and doctor. The patient may also the cancel the
appointment.

PRE-CONDITION - The patient must be a registered patient, Patient can fix only one
appointment for a particular department.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.
3. Create a new appointment or cancel the appointment..

POST CONDITIONS - patient details are displayed and a new appointment is fix or a
existing appointment is cancelled. The hms database is updated.

*PAYMENT
DESCRIPTION – It enables user to pay the consultant fee of Doctor online.

PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants to pay
online he/she can pay by cash also.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.
3. Appointment confirmed by the Doctor then go for Payment.

POST CONDITIONS – A Reciept will be displayed. The hms database is updated

(2) DOCTOR
DESCRIPTION- The doctor view patient record/ update his details and add description of the
treatment given to patient.

PRE-CONDITION – The doctor must be a registered doctor, System does not allow the
doctor to modify the qualification, hospital managed details.

MAIN FLOW OF EVENTS

1.Doctor logs in to the system.
2. Doctor may select view patient.
2.1 Patient record is displayed with treatment history.
3. Doctor add description of patient treatment.
4. Doctor may select appointment details
4.1 Appointment Requests is displayed with schedule.
5. Doctor confirm or cancel appointment.

POST CONDITION – The patient and doctor ‘s database are updated.

(3) ADMIN

DESCRIPTION - The admin add doctor, update docotr details and verify payment and
generate Bill/Reciept for the same.

MAIN FLOW OF EVENTS

1. Admin logs in the system.
2. Admin may add doctor new doctor.
2.1 admin fills the doctor’s details.
3. Admin view Doctor record.
3.1 Admin enters the doctor id in the system.
3.2 Doctor details are displayed, Admin can update details.
4. Admin Verify the payment submited by the Patient.
4.1 Generate Bill/Reciept and confirmation message for the same.

PRE –CONDITION - Admin must first log in with his/her credentials.

POST CONDITION - The hms database is updated.

2.5 User characteristics
ADMIN
Admin has the full access to the system which means he is able to manage any activity with
regard to the system. He is the highest privileged user who can access to the system.

Key functions:
•Access patient record, doctor Record.
•Add new doctor entry in system database.
• Confirm Payment and Generate Bill.
• View Records.(Total no of patients treated, doctor added/remove, consultant fee).

PATIENT
Patients can choose the best preferred appointments from the options provided and can also
change the appointment schedule or cancel it. After appt. is confirmed by the respective
doctor they can pay their consultant fee online. Patients have access to only their records.

Key functions:
• Make appointment.
• Cancel appointment.
• Update Details.
• Payment.
• View Payment History.
•
DOCTOR
Doctors can view the patient appointment list and provide the confirmation or make changes
in the appointment list if required. Doctors have access to only records of those patients
whom they are treating.

Key functions:
• Confirmation of appointment.
• Cancellation of appointment.
• Modification of appointment list.
• Add Prescription.

2.6 Constraints

• System is wirelessly networked with an encryption.

• System is only accessible within the hospital’s website only.
• Database is password protected.
• Should use less RAM and processing power.
• Each user should have individual ID and password.
• Only administrator can access the whole system.
2.7 Assumptions and dependencies

▪ Each user must have a valid user id and password ▪ Server must be
running for the system to function ▪ Users must log in to the system to
access any record.
▪ Only the Administrator can delete records.
3. Design and Implementation Constraints
3.1 PERFORMANCE REQUIREMENTS

o Response time- The system will give responses within 1 second after checking the patient
information and other information.
o Capacity-The system must support 1000 people at a time
o User interface- User interface screen will response within 5 seconds

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. 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.3 SECURITY REQUIREMENTS

1. Want take the responsibility of failures due to hardware malfunctioning.

2. Warranty period of maintaining the software would be one year.
3. Additional payments will be analyzed and charged for further maintenance.
4. If any error occur due to a user’s improper use. Warranty will not be allocated to it.
5. No money back returns for the software.

3.4 SOFTWARE SYSTEM ATTRIBUTES

3.4.1 Usability: Software can be used again and again without distortion.

3.4.2 Availability: The system shall be available all the time.

3.4.3 Correctness: Bug free software which fulfills the correct need/requirements of the
client.

3.4.4 Maintainability: The ability to maintain, modify information and update fix
problems of the system.

3.4.5 Accessibility: Administrator and many other users can access the system but the
access level is controlled for each user according to their work scope.
 3.5 FUNCTIONAL REQUIREMENTS

S.No. MODULE NAME APPLICABLE DESCRIPTION

ROLES

1. LOGIN PATIENT PATIENT: Can login using unique Id and Password

DOCTOR after this system shall show his/her profile.
ADMIN
DOCTOR: Can login using unique Id and Password
after this system shall show his/her profile.

ADMIN: Can login using unique Id and Password

after this system shall show a profile with links to
maintain the website.

2. REGISTRATION PATIENT PATIENT: Can Register by filling all the required

details, after this the system will verify the details
and check if already registered or not.

3. MAKE APPT. PATIENT PATIENT: Can Select doctor, date time and make an
appointment request after this system shall show a
confirmation for appointment request.

4. CANCL APPT. PATIENT PATIENT : Can Cancel appointment if want to by

DOCTOR just one click after this system shall ask for re-
schedule or refund of payment.

DOCTOR : Can Cancel appointment if want to by

just one click after this system shall send a message
to the patient.

5. PAYMENT PATIENT PATIENT : Enter payment details and make

payment after this system shall show the generated
bill by the hospital.
6. DOCTOR ADMIN ADMIN : Can add a new doctor by filling all the
MODULE details after this system shall show a confirmation
message.
Can Remove a doctor by just one click after this
system shall show confirmation message.

7. PATIENT MODULE PATIENT PATIENT : Can view payment history or can search
for a particular bill also after this system shall show a
bill or history.

Can also See or search for a doctor by entering dept.

name or doctor id if known after this system will
check for the doctor if found shall show doctor’s
profile.

Can also update details after this system shall ask for
re-enter password and after verifying password shall
update details.

8. ADD DOCTOR DOCTOR : Enter Patient Id and after this all the
PRESCRIPTION treatment details and medicine, remark and advice for
the patient after this system shall show a message for
update.
4. Other Requirements

User interface should be effective and interactive and appealing for maximum effect. Software should be
approved for use in respective area without violating any rules and regulations of CopyRight Act and
existing patents in the country in which it is used