specification requirement document hospital management

1. SOFTWARE REQUIRMENT DOCUMENT
Assignment 2
2014-UETR-CS-03
14-11-2016
Submitted to:
Miss Asma Fiaz
Submitted by:
M Aamir Farooq

2. Hospital Management System
Abstract
Hospital Management System was done as a part of our
curriculum for Third year BSCS 5th semester using VB and
Oracle. Consisted of a database of Patient, Doctor, availability
of Wards, entry of various hospital records and other fields. It
also dealt with discharge of patient and bill information
accordingly. GUI made was very user-friendly and easy to
understand and function
This project is related to a hospital management system.it
maintains records of all the operations that occur at any of the
medical center in public institutions.it maintains two level
of users, administrator level and the user level. the
administrator lever encompasses the nurses and the doctors
while the user level includes the receptionist. The
administrators are able to perform operations on
more sensitive and confidential documents /modules that
contains different information about students and staff to
ensure confidentiality. The modules include laboratory,
treatment, consultation and medicine stock modules. The user
level is able to manage other modules such as registration and
report generation for stock of medicine and staff reports. The
system enables registration of new students, staff, nurses and
doctors at the reception level. The current diagnosis details of
a patient are recorded in the consultation which are retrieved
as previous details upon the subsequent visit.
1.INTRODUCTION
The SRS is technical specification of requirement of Hospital
Management system. This specification describes what the
proposed system should do without describing how it will do
it. It also describes complete external behavior of proposed
system.
1.1 PURPOSE
The main purpose of our system is to make
hospital task easy and is to develop software that
replaces the manual hospital system into
automated hospital management system. This
document serves as the unambiguous guide for the
developers of this software system.
1.2 SCOPE
The document only covers the requirement
specification for the hospital management system. This
document does not provide any references to the other
component of the hospital management system. All the
external interfaces and the dependencies are also identified in
this document.
1.3 INTENDED AUDIENCE AND READING
SUGGESTIONS
Hospital and Clinic Administrators: Hospital and Clinic
Administrator will be using this software for overall
management.
Doctors: Doctors will be using this to keep track of their
patients, appointments, their consultation fees, and other
details
Computer Operators: Computer Operators will be using this
software to for patient billing, accounting and inventory
tracking, patient records, employee records, etc.
1.4 SCOPE OF DEVELOPMENT PROJECT
The purpose of the MPPS software is to simplify the handling
of day-to-day administrative and financial tasks so as to
improve the efficiency. It shall integrate all aspects of running
a hospital, as well as provide relevant information to various
departments and doctors as and when required. Aamir is an
enterprise wide resource planning solution for hospitals, which
addresses the issues from multi disciplines vis-à-vis patient,
hospital management, doctors and pharmacy. This solution is
modular in nature having following modules- Billing, Patient
Records, Accounting and Inventory Tracking and Human
Resources Management Module for medical and non-medical
staff.
1.5 FEASIBILITY STUDY
The overall scope of the feasibility study was to provide
sufficient information to allow a decision to be made as to
whether the hospital management system project should
proceed and so, its relative priority in the context of the other
existing hospital management system.
The feasibility study of this project had undergone
through various steps which as describe as under:
a) Identify the origin of the information at different level.
b) Identify the expectation of user from computerized
system.
c) Analyze the drawback of existing system.
1.6 OVERVIEW
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

3. patient. You can also manually edit any patient details and
issue bill receipt to patient within few seconds.
2. OVERALL DESCRIPTION
2.1 Product Perspective
This Hospital Management System is a self-contained
system that manages activities of the hospital as Patient
Information. Various stakeholders are involved in the
hospital patient info system.
2.2 Product features
The system functions can be described as follows:
Registration: When a patient is admitted, the front-desk staff
checks to see if the patient is already registered with the
hospital.
If he is, his/her Personal Health Number (PHN) is entered into
the computer. Otherwise a new Personal Health Number is
given to this patient
.
The patient’s information such as date of birth, address and
telephone number is also entered into computer system.
Patient check out: If a patient checks out, the administrative
staff shall delete his PHN from the system and the just
evacuated bed is included in available-beds list.
Generation: The system generates reports on the following
information: List of detailed information regarding the
patient who has admitted in the hospital
.
2.3 Design and Implementation Constraints
Database :
The system shall use the MySQL Database, which is open
source and free.
Operating System
The Development environment shall be Windows 2010.
2.4 Design Implementation Constraints
It is assumed that the terminals are connected to Oracle 10.0g
User Constraints
Each user can access only those modules and information
permitted to him
Each user must keep the password private and that they must
be greater than 7 characters.
Each user can access only from 1 site at a time.
At a time a maximum of 101 users can log in to the system
(MySQL constraint)
2.5 User Documentation
The documentation and tutorials for the software will be
provided after the product is fully developed and tested
2.6 Assumptions and Dependencies
Assumptions
Each terminal is always connected to the Oracle whenever HR
is running
The terminal running HR supports at least Oracle 10.0g.
2.7 Hardware Dependencies/System Dependencies
Requires minimum 128 MB RAM and recommended RAM is
256 MB
Requires minimum 500 MHz Processor
2.8 Overview of Data Requirements
Input: Patient information, previous records if any, patient-
type, bed no, bills as and when charged to patients, patient's
lab and test reports. Doctor’s information, appointment
schedules, purchase receipts of medicines and bio-medical
instruments, etc.
Output: Electronic Patient's Record, Doctors' record, etc.
2.9 USER VIEW OF PRODUCT USE
First, a patient is admitted to hospital. The patient is assigned a
unique Patient Identification Number (PIN). All the required
information is entered into HR database. As and when the tests
and diagnosis are carried out, their reports are inputted. Also,
appropriate bills are charged to the patient. When the patient is
to be discharged or transferred to another hospital, all his
medical reports, bills, etc is quickly made available. Also
discrepancies if any can be checked.
The doctor enters details about the patients he is looking after,
also consultations provided, etc. As and when medicines and

4. other equipment’s are purchased their details are inputted into
the database.
3. External Interface Requirements
3.1 User Interface:
Login Screen: The users log in and access the system
depending on privileges given.
Registration form: At the time of admission, patient's details
like patient name, patient type, sex, bed number, referred
from, doctor's name, illness, blood group, contact details,
previous illness, etc
Inventory Management Screen: Present stock, usage.
Admin screen: Add and remove system users / change rights,
password, perform backup and restore operations, change
configurations, etc.
HR Screen: Administrator enters details about all the
employees, which includes medical and non-medical staff.
Their salaries payable, perks, etc.
Report preparing utility: Settings for preparing the reports
such as medical reports, bills, etc.
3.2 Hardware interface
Main Server: server is located in the hospital premises which
hosts the database using MySQL
3.3 Software interface
HR is a multi-user, multi-tasking environment. It uses VB
Standard Edition as front end and MySQL as backend
database.
3.4 Communication Interface:
The entire communication interface is handled by the
operating system. Example sockets are used for
communication between MySQL server and HR.
4 SYSTEM FEATURES
4.1 Modules:
4.1.1 Patient Records
This module consists of Registration, OPD and IPD panels.
This module provides all the information about the patient as
per the user access level.
• Doctors have access to the patient’s medical records.
They can view the results of tests conducted and
medical history. They can also append medical
details of the patient as per their diagnosis.
• Lab technicians attach reports of the various tests
conducted in the hospital.
• Computer operators can add/edit other relevant
patient information. They also perform registration
and other formalities.
4.1.2 Human Resources Module
This module is responsible for employee management. Typical
hospital consists of doctors, nurses, ward boys, lab technician,
housekeeping staff and clerks. HR module keeps track of
various details such as salaries, perks, medical benefits, leaves,
etc. However, only the HR staff and Administrators can access
this module.
4.1.3 Accounting and Inventory Module
This module allows tracking of the inventory and finances. All
purchases made by hospital such as medicines, bio-medical
equipment’s and other relevant items are recorded by this
module. It allows bookkeeping, generates Income and
Expenditure Account, Balance Sheet and other accounting
reports. It generates various Inventory reports, allows the
hospital staff to view total stock available. Based upon the
reports hospital can decide which medicines are sold faster so
that they can keep adequate stock of it.
4.1.4 Billing Module

5. This module generates bills of patients as per the information
about the various services offered. The services include the
bed, tests, consultation, medicines, etc. The module
automatically generates bills according to the services used by
the patient.
4.1.5 Pharmacy Module
The Pharmacy Department will basically use this module. This
module keeps tracks of sales of medicines. This module will
be linked to Accounting and Inventory module so that the net
stock of medicines is always available.
5 OTHER NON-FUNCTIONAL REQUIREMENTS:
5.1 Performance requirements
The important aspect of HR is that it must offer complete
control management and all information at the click of a
button. Response time of server may not be greater than 1 min.
Number of terminals is not restricted by the application but the
operating system or N/w may impose some restrictions, in any
case only one login per terminal and only one login per user
name is allowed
5.2 Safety Requirements:
HR must guarantee that the data is safe.
It keeps backup of all data files in separate directory, tape
drives, etc.
5.3 Security requirements
1. Access to the system will only be granted to the
operators after authentication
2. Each user will be provided with a user name,
password (minimum 8 characters) and access level.
The user can access only those modules and features
as permitted by the administrator.
3. Administrator(s) will have access to entire system
5.4 Software quality attributes
The product is open source so its source code will be available
for everyone to see. It will be free for further modifications
and improvements.
5.4.1 Portability
• HR must have a simple, user-friendly interface so
customers can save time.
• The software system must be intuitive enough such
that a user with average background in using
computers with little knowledge of HR can quickly
learn how to use it.
• The software must provide a modern point-click user
interface for the operators of the system to use.
5.4.2 Reliability
The reliability of the software system is important. Any failure
reporting must be correctly reported. It should reject invalid
user input without crashing. Errors should be displayed to the
user in a simple language. HR must ensure proper memory
management.
5.4.3 Testability
The requirement of this SRS will be verified through the
exercising of test cases as described by the requirement. Each
requirement of this SRS will be tested by thoroughly running
the system with all forms of input. System should be closely
monitored during and after user testing to ensure that any fault
is quickly fixed
5.5 Special User requirements
5.5.1 Backup and Recovery
1. Keep backups of all data files in tape drives, separate
directory/drive

6. 2. Frequently auto save information in case of system
failure
5.5.2 Data Migration and Retention
As all information is stored in a MySQL database, data
migration and retention can be easily performed.
5.6 Installation
Setting up a conducive environment for the efficient running
of Window 10, like setup of Database Server, etc.
7 ENTITY RELATIONSHIP DIAGRAM
8.REFRANCES
1.SOFTWARE ENGINEERING ninth edition by
Lan Somervell
2.www.slideshare.comhospital management system
3. https://www.scribd.com/doc/24070840/Hospital-
Management-System-Synopsis-and-Project-Report

7. 2. Frequently auto save information in case of system
failure
5.5.2 Data Migration and Retention
As all information is stored in a MySQL database, data
migration and retention can be easily performed.
5.6 Installation
Setting up a conducive environment for the efficient running
of Window 10, like setup of Database Server, etc.
7 ENTITY RELATIONSHIP DIAGRAM
8.REFRANCES
1.SOFTWARE ENGINEERING ninth edition by
Lan Somervell
2.www.slideshare.comhospital management system
3. https://www.scribd.com/doc/24070840/Hospital-
Management-System-Synopsis-and-Project-Report