You are on page 1of 16

Software Requirements Specification

Version 1.1

20-12-2016

Hospital Management System

Moparthy.Rajya Lakshmi (14BQ1A05D4)


Makkena. Pramod (14BQ1A05C4)
Nidamanuri.VenkataKalyan (14BQ1A05F3)
Popuri.BinduSree (14BQ1A05H8)

Table of Contents
Table of Contents................................................................................................................................................ii
Table of Figures.................................................................................................................................................iii
1.0. Purpose..........................................................................................................................................................1
1.1. Introduction...................................................................................................................................................1
1.2. Scope.............................................................................................................................................................1
1.3. Glossary........................................................................................................................................................1
1.4. References.....................................................................................................................................................2
1.5. Document overview......................................................................................................................................2
2.0. Overall description.....................................................................................................................................4
2.1. System environment.....................................................................................................................................4
2.2. Functional requirements definitions.............................................................................................................4
2.3. Use cases.......................................................................................................................................................5
2.3.1. Use Case: Access Alumni Home Page...................................................................................................6
2.3.2. Use Case: Alum Chooses Survey..........................................................................................................7
2.3.3. Use Case: Create New Entry.................................................................................................................8
2.3.4. Use Case: Update an Entry....................................................................................................................9
2.3.5. Use Case: Search for an Alumni/E-mail and Alumni..........................................................................10
2.4. Non-functional requirements......................................................................................................................11
3.0. Requirement specifications...................................................................................................................12
3.1. External interface specifications.................................................................................................................12
3.2. Functional Requirements............................................................................................................................12
3.2.1. Access Alumni Home Page..................................................................................................................12
3.2.2. Survey..................................................................................................................................................12
3.2.3. Create a new entry...............................................................................................................................13
3.2.4 Update an Entry....................................................................................................................................14
3.2.5. Search for an Alumni/E-mail an Alumni.............................................................................................15
3.3. Detailed non-functional requirements........................................................................................................17
3.4. System Evolution........................................................................................................................................18
4.0. Index.............................................................................................................................................................19
SRS 03/16/17

Table of Figures
Figure 1 System Design...........................................................................................................................................4
Figure 2 Hospital Requirements Home page...........................................................................................................5
Figure 4 Alum Selects Create a New Entry.............................................................................................................8
Figure 5 Alum Selects Update an Entry..................................................................................................................9

2
SRS 03/16/17

1. Feasibility study:
Operational Feasibility:

Hospital management system is a web based project and the user must have a computer with

web browser to access it. Our software is operationally feasible as the user interface is

available in basic languages (Telugu, Hindi, English). Each and every end user must have

basic knowledge of web browser and its accessing. So it is understandable and accessible by

the end user and customer.

Technically Feasible:

Hospital management system deals with software like PHP, my SQL which is provided by

Xamp. We also require a server to maintain the database. All the softwares used are open

source which provides technical feasibility.

Economical Feasibility:

Hospital management system uses softwares that are open source which are free of cost.

Despite we require a server additionally it is economically feasible due to its cost

effectiveness.

1.0. Purpose
Hospital management system is designed to automate various activities usually takes place in

a hospital such as creating patient database, allotment of rooms, checking the availability of

the doctor, tracking medical history, storing test reports into the database etc.

1.1. Introduction

This Software Requirements Specification provides a complete description of all the

functions and specifications of the Online Hospital Management System. This project is

aimed to automate the hospital management which may keep the records of the patients and

1
SRS 03/16/17

doctors, time slots, availability of the doctors, availability and allotment of the rooms, Bills,

Bill payment.

1.2. Scope

This Hospital Management System focusses oncreating patient database, checking the

availability of the doctor, tracking medical history, storing test reports into the database, time

slots, availability and allotment of the rooms, Bills, Bill payment etc.However some activities

such as buying medicines and attending tests is not included in the project.

1.3. Glossary

Term Definition
OHMS Online Hospital Management System
DD Duty Doctor
IP In-patient
OP Out-patient
Case Sheet Patient details
Html Hyper- text markup language
IEEE Institute of Electrical and Electronic
Engineers
Test Report Details of lab results about patient disease
Prescription Details given doctor to patient to be issued
with medicines and tests
SRS Software Requirement Specifications

1.4. References

http://files.spogel.com/abstracts/p-8729-- Hospital management system using php.pdf

https://www.scribd.com/doc/37005582/hospital-management-srs

http://www.freestudentprojects.com/studentprojectreport/hospitalmanagement-system/

2
SRS 03/16/17

1.5. Document overview

The remainder of this document describes about detailed functional and non-functional

requirements like maintainability, portability, reliability, accuracy of results. It deals with the

hardware and software interfaces. It lists all the functions performed by the system. This

document deals with use cases, requirement specifications and system evolution.

2.0. Overall description

The hospital management system encompasses numerous files and information about

the patients and doctors, billing. Each patient will consult the doctor based on the

appointment.If the doctor is freeon his/her duty time, the outpatient can consult the doctor

after the spotappointments are made.The doctor's appointment with various slots for patient

is created andmaintained by system. The appointments can be altered at any time before an

hourof the actual appointment schedule. The doctors and patients details must beregistered to

create the appointments.This project gives the procedural approach of patient about date of

treatment and finally depending on different criteria like room allocated, lab reports, billing.

2.1. System environment

Figure 1 System Design

3
SRS 03/16/17

The Hospital management system web site will be operated from the hospital web server.

When an patient connects to the hospital Web Server, the hospital Web Server will pass the

patient data to the patient data base. The Server will then interact with the patient

Databaseprovides deatils required for the patient.

2.2. Functional requirements definition

Functional Requirements are those that refer to the functionality of the system, i.e.,

what services it will provide to the user. Nonfunctional (supplementary) requirements pertain

to other information needed to produce the correct system and are detailed separately.

2.3. Use cases


The system will consist of CIS Alumni Home page with five selections.

Initially The patient connects to the Hospital Web Server. The patient elects the patient link

on the Hospital home page. The Hospital Web Server passes the patient details to the

Hospital Home Page. In Hospital home page we have the following details:

home - Its used to display the Hospital Management Home page.


About us - Its used to overview of the hospital details, logos, equipment available,

treatments offered etc.


Doctors - This consists of details of doctors like doctor name, specialization,

doctor number/id, update/delete details.


Patients - This deals with patient details, diseases, reports, allotment of rooms etc.
Bills: It contains all the billing details.

2.3.1. Use Case: Hospital Home Page

4
SRS 03/16/17

Generation

Figure 2 Hospital Requirements Home Page


Brief Description:

The Hospital Web Server is ready for responding topatientwho is connected.

Initial step-by-step description:

For this theuser must be connected to the Internet and then connect to the Hospital Web

server.

1. The patient connects to the Hospital Web Server.

5
SRS 03/16/17

2. The patient elects the patient link on the Hospital home page.

3. The Hospital Web Server passes the patient details to the Hospital Home Page.

Reference SRS 3.2.1

2.4. Non-functional requirements

Hospital Management System provides performance like response time, capacity and

access.

Capacity:The system must support 10,000 at a time.

Response time: The system must give responses immediately after checking the patients

information.

Accessibility: Easy for accessing by patients, user friendly.

Reliability: It consistently performs according to its specifications. Hospital management

System hires payment gateways like HDFC, Citrus etc.

Maintainability: The system shall provide back-up the data in case of any damage.

3.1. External interface specifications

XAMPP.

PHP.

MY SQL.

Server.

3.2. Functional Requirements


Hospital Management System provides functional requirements like the user will be

able to search a patient either by his nameor patientvisit no. If the search result yields more

6
SRS 03/16/17

than one patients data,then information (already stored in the database

throughAdmissionmodule)of all those patients will be displayed. The user then will be able

to select the particular patient he is looking for. The information that are to be displayed

automatically are:

Patients:

Name

Address

Date of Birth

Sex (M/F)

Date of Admission

Patients type (inpatient/outpatient)

Diagnosis details

Modify/Delete

Doctors:

Name

Doctor No

Specialization

Modify/Delete

Appointment:

Date

Time

Doctors Name

7
SRS 03/16/17

Patients Name

Modify/Delete

Bills:

send a message for every new bill of patient

provide online transactions for paying bill

rooms allotment details

booking slots for consulting

online reports

3.2.1. Access Hospital Home Page

Use Case Name: Access Hospital Home Page


Priority Essential
Trigger Menu selection
Precondition Patient is connected to the Internet and
connect to Hospital home page
Basic Path 1. the hospital Web Server will pass the
patient data to the patient data base.
Alternate Path N/A
Post condition The Patient details are on the Hospital Home
Page
Exception Path If there is a connection failure the Hospital
Server returns to the wait state
Other
Reference SRS 2.3.1

3.2.2. Survey

Use Case Name: Survey


Priority Essential
Trigger Selects
Precondition The Patient is connected to the Internet and
on the Hospital Home Page
Basic Path 1. The Hospital server presents the patient
with a form.

8
SRS 03/16/17

2. The patient fills in the form and click


submit
3. The Hospital Server checks to see if all
required fields are not empty.
4. If the required fields are not empty, the
Hospital Server creates a new record in
the patient Database.
5. If any of the required fields are empty,
the Hospital Server returns a message and
returns the patient to the Survey form.
6. The Hospital Server returns the patient to
the patient Home Page
Alternate Path N/A
Post condition The survey record is created in the Survey
Table of the Hospital Database.
Exception Path 1. If the connection is terminated before the
form is submitted, the fields are all
cleared and the Departmental Server is
returned to the wait state.
Other
Reference: SRS 2.3.2

3.2.3. Create a new entry

Use Case Name: Create a new entry


Priority Essential
Trigger Menu selection
Precondition The patient must be connected to the Internet
and on the Hospital Home page.
Basic Path 1. The Patient clicks on add a new entry.
2. The Hospital Server returns a form.
3. The patient fills in the form and clicks
submit.
4. The Hospital Server checks to see if any
required field is empty.
5. If any required field is empty the
Hospital Server will send a message and
return the patient to the new entry form
page.
6. If no required field is empty the Hospital

9
SRS 03/16/17

Server will create a new record in the


Hospital Table in the Hospital Database,
and return the patient to the Hospital
Home Page.
7. The patient may select Cancel.
8. If the patient selects Cancel, the form is
cleared and the patient is returned to the
Hospital Home page.
Alternate Path N/A
Postcondition A record is created in the Hospital Table of
the Hospital Database.
Exception Path 1. If the connection is terminated before the
form is submitted, the fields are cleared
and the Hospital Server is returned to the
wait state.
2. If the connection is terminated after the
form is submitted, but before the patient
is returned to the Hospital Home Page,
the record is created in the hospital Table
of the hospital Database.
Other
Reference: SRS 2.3.3

3.2.4 Update an Entry

Use Case Name: Update an Entry


Priority Essential
Trigger Menu selection
Precondition The Patient must be connected to the Internet
and on the Hospital Entries Page.
Basic Path 1. The patient clicks on update an entry
link.
2. The Hospital Server returns a form.
3. The patient enters his/her details.
4. The Hospital Server queries the Patient
Database from that table of all patients.
5. If the patient name/Patient no does not
match the Hospital Server returns a
message and allows the patient to try it
again.
6. If after 3 tries the details does not match,
the Hospital Server will return a message
telling the patient to contact the Hospital
management.

10
SRS 03/16/17

7. If the details matches go to 8.


8. The Hospital Server returns a form with
the data for that patient in it and a
message to update the data they wish and
click submit.
9. The Hospital Server will replaces the old
data with the new data and returns the
patient details the Hospital Home Page.
Alternate Path If after three attempts to match the name or
patient no the Hospital Server will return a
message and block the patient from the
update section.
Postcondition The record in the Hospital Table of the
Hospital Database has been updated and the
patient data is returned to the Hospital Home
Page.
Exception Path 1. If the connection is terminated before the
form is submitted, the fields are cleared
and the Hospital Server is returned to the
wait state.
2. If the connection is terminated after the
form is submitted, but before the patient
is returned to the Hospital Home Page,
the record in the Hospital Table of the
Hospital Database is updated and the
Hospital web Server is returned to the
wait state.
Other
Reference: SRS 2.3.4

3.2.5. Search for an Patient

Use Case Name: Search for an Alumni


Priority If time permits.
Trigger Menu selection
Precondition The patient is connected to the Internet and
on the Hospital Home Page.
Basic Path 1. The patient clicks on hospital link.
2. The Hospital Server returns a form with
the data for that patient
Alternate Path N/A
Post condition The patient receives the information of the
requested patient, receives details from
Hospital home page.

11
SRS 03/16/17

Exception Path 1. If the connection is terminated before the


information is returned, the Hospital
Server is returned to the wait state.
2. If the connection is terminated after the
information is returned, the Hospital
Server is returned to the wait state
Other
Reference: SRS 2.3.5

3.3. Detailed non-functional requirements

Hardware: Hospital Web Server

Software: XAMPP, MY SQL, PHP

Internet Connection Existing Mobile/telephone lines

Code Standard The web pages will be coded in html by using Front Page.

Performance The system should generate the records in the appropriate table of the

Hospital Database 100% of the time.

The connection to the Hospital Database will be done with Windows. Each page of

the web site will be fully documented.

3.4. System Evolution

In the future this system will be updated knowing the requirements of the users

feedbacks. Lastly Hospital Management System is user friendly and can updated from time

to time for the ease of users.

12
SRS 03/16/17

4.0. Index
Audience, 1
Borland Database Engine, 1, 3, 16
Configuration Item, 1
Customer, 3
Database, i, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 16
Developer, 1
Function, 1, 2
Institute of Electrical & Electronic Engineers, 1, 2
Non-functional, 14
Quality Assurance, 1, 2
Server, 1, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Software Configuration Management Plan, 1
Software Design Document, 1
Software Engineering Institute, 2
Software Project Management Plan, i, 2
Software Quality Assurance Plan, 2
Software Requirement Document, 2
System, 1, 2, 3, 9, 15, 16
Use Case, 3, 5, 6, 7, 8

13

You might also like