Professional Documents
Culture Documents
Version 1.1
20-12-2016
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
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
Economical Feasibility:
Hospital management system uses softwares that are open source which are free of 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
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
https://www.scribd.com/doc/37005582/hospital-management-srs
http://www.freestudentprojects.com/studentprojectreport/hospitalmanagement-system/
2
SRS 03/16/17
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.
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.
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
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.
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:
4
SRS 03/16/17
Generation
For this theuser must be connected to the Internet and then connect 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.
Hospital Management System provides performance like response time, capacity and
access.
Response time: The system must give responses immediately after checking the patients
information.
Maintainability: The system shall provide back-up the data in case of any damage.
XAMPP.
PHP.
MY SQL.
Server.
able to search a patient either by his nameor patientvisit no. If the search result yields more
6
SRS 03/16/17
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
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:
online reports
3.2.2. Survey
8
SRS 03/16/17
9
SRS 03/16/17
10
SRS 03/16/17
11
SRS 03/16/17
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
The connection to the Hospital Database will be done with Windows. Each page of
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
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