17.03.

2016

Session: 2014 - 2016 | <Department of computer science & it>

Project Title

Revision History
Date
<date>

Description
<Version 1>

Author

Comments

Samia Afzal

<First Revision>

Document Approval
The following Software Requirements Specification has been accepted and approved by the following:
Signature

Printed Name
Dr. Shazad Mumtaz

Title
Supervisor, CSIT 21306

Date
<date>

Project Title

Table of Contents

CHAPTER 1
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations.
1.4 References
1.5 Overview
CHAPTER 2
2. The Overall Description
2.1 Product Perspective
2.1.1 Operations
2.2 Product Functions
2.3 User Characteristics
CHAPTER 3
3. Specific Requirements

Non-Functional Requirements

Functional Requirements

3.1 External Interface Requirements

3.1.1 System Interfaces
3.1.2 Interfaces
3.1.3 Hardware Interfaces
3.1.4 Software Interfaces
3.1.5 Communications Interfaces
3.2 Functional Requirements
3.3 Use Case Diagrams:
3.5 Non-Functional Requirements
3.7Logical Database Requirements
5. Supporting Information
Appendix A Background Research on:
Appendix B Data Dictionary

Project Title

CHAPTER 1
1. Introduction
The following subsections of Software Requirement Specifications Document should facilitate in
providing the entire overview of the Information system Hospital Management System under
development. This document aims at defining the overall software requirements for admin.
Efforts have been made to define the requirements of the Information system exhaustively and
accurately.
1.1 Purpose
The main purpose of Software Requirement Specifications Document is to describe in a precise
manner all the capabilities that will be provided by the Software Application Hospital
Management System. It also states the various constraints which the system will be abide to.
This document further leads to clear vision of the software requirements, specifications and
capabilities. These are to be exposed to the development, testing team and end users of the
software.
1.2 Scope
The proposed software product is the Hospital Management System (HMS). The system will be
used in any Hospital, Clinic, Dispensary or Pathology labs in any Hospital, Clinic, Dispensary or
Pathology labs to get the information from the patients and then storing that data for future
usage
The current system in use is a paper-based system. It is too slow and cannot provide updated lists
of patients within a reasonable timeframe. The intentions of the system are to reduce over-time
pay and increase the number of patients that can be treated accurately. Requirements statements
in this document are both functional and non-functional.
1.3 Definitions, Acronyms, and Abbreviations.
CFD: Context Flow Diagram
DFD: Data Flow Diagram
IDE: Integrated Development Environment
SQL: Structured Query Language
SRS: Software Requirement Specification.
GUI: - Graphical User Interface

SRS Document 1.0

Page 1 of 9

03/17/16

Project Title

1.4 References
i
ii

Software Engineering by K.K.Aggrawal, Singh, Yogesh.

Ian Somerville, Software Engineering, Third Edition.

1.5 Overview
1
2
3

To computerize all details regarding patient details & hospital details.

Scheduling the appointment of patient with doctors to make it convenient for both.
Scheduling the services of specialized doctors and emergency properly so that facilities

provided by hospital are fully utilized in effective and efficient manner.

If the medical store issues medicines to patients, it should reduce the stock status of the

medical store and vice-versa.

It should be able to handle the test reports of patients conducted in the pathology lab of

6
7

the hospital.
The inventory should be updated automatically whenever a transaction is made.
The information of the patients should be kept up to date and there record should be kept
in the system for historical purposes.

CHAPTER 2
2. The Overall Description
Hospital are the essential part of our lives, providing best medical facilities to people
suffering from various ailments, which may be due to change in climatic conditions,
increased work-load, emotional trauma stress etc. It is necessary for the hospitals to keep
track of its day-to-day activities & records of its patients, doctors, nurses, ward boys and
other staff personals that keep the hospital running smoothly & successfully.
But keeping track of all the activities and their records on paper is very cumbersome and
error prone. It also is very inefficient and a time-consuming process Observing the
continuous increase in population and number of people visiting the hospital. Recording
SRS Document 1.0

Page 2 of 9

03/17/16

Project Title

and maintaining all these records is highly unreliable, inefficient and error-prone. It is
also not economically & technically feasible to maintain these records on paper.
Thus keeping the working of the manual system as the basis of our project. We have
developed an automated version of the manual system, named as Hospital Management
System.
The main aim of our project is to provide a paper-less hospital up to 90%. It also aims at
providing low-cost reliable automation of the existing systems. The system also provides
excellent security of data at every level of user-system interaction and also provides
robust & reliable storage and backup facilities.
2.1 Product Perspective
The application will be windows-based, self contained and independent software product.
Visual Basic 6.0
MS-Access

2.1.1 Operations
This product will not cover any automated housekeeping aspects of database. The DBA at client
site will be manually deleting old/ non required data. Database backup and recovery will also
have to be handled by DBA.
2.1.2 System Features
2

Login module

Description
This module records only user and password of the user.

SRS Document 1.0

Page 3 of 9

03/17/16

Project Title

Patient module

Description
It keeps track of all details about both in-patient and out-patient. Patient id, patient name,
address, admitted date, doctor name, and room no are entered in a form and stored for future
reference. Also particular patient details can be viewed in the table using a separate form with an
attribute patient id.
4

Inpatient module

Description
Admission request will be made here. Request for admission is made before patient admitting the
hospital.
5

Outpatient module

Description
This module manages activities related to patient who visits the Hospital or Resident Doctor or
Consultant Doctor for Medical Consultations, diagnosis and treatment.
6

Pathology module
Description
This module Generates reports which will be done in pathology lab of the Hospital.

Billing module

Description
This module bills the both inpatient and outpatient who comes to hospital. It also includes
Payment details of patients. Depending on the payments bill report is generated.
2.2 Product Functions
The system will allow access only to authorized users with specific roles (Administrator,
Operator). Depending upon the users role, he/she will be able to access only specific modules of
the system.
A summary of the major functions that the software will perform:
i

A login facility for enabling only authorized access to the system.

SRS Document 1.0

Page 4 of 9

03/17/16

Project Title

ii

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 Name is entered into the computer.

iii
iv

Otherwise a new Patient ID is given to this patient.

If a patient checks out, the administrative staff shall delete his patient ID from the system.
The system generates reports on the following information: List of detailed information
regarding the patient who has admitted in the hospital.

2.3 User Characteristics

1. Educational Level: At least graduate and should be comfortable with English language.
2. Technical Expertise: Should be a high or middle level employee of the organization
comfortable with using general purpose applications on a computer.

CHAPTER 3
3. Specific Requirements
The system is fully computerized and automated for sending and receiving messages. There are two types
of requirement every system have:-

Non-Functional Requirements

Functional Requirements

3.1 External Interface Requirements

3.1.1 System Interfaces
List each system interface and identify the functionality of the software to accomplish the
system requirement and the interface description to match the system. These are external
systems that you have to interact with. For instance, if you are building a business
application that interfaces with the existing employee payroll system, what is the API to
that system that designers will need to use?
SRS Document 1.0

Page 5 of 9

03/17/16

Project Title

3.1.2 Interfaces
The application will have a user friendly and menu based interface. Following screens will be
provided.
i

A Login Screen for entering username, password and role (Administrator, operator) will

ii
iii

be provided. Access to different screens will be based upon the role of the user.
A Form for Search the details of a patient.
The Form for creating a new patient record will contain text fields where the Patient ID

iv

will be machine generated and the rest of the details will have to be filled up.
A Form for generating the tests reports.

The Form to produce a bill will create fields such as Patient ID, Appointment No.,
Doctors charges, Hospital charges etc. which will need to be filled up.
The following reports will be generated:
i

Tests reports

3.1.3 Hardware Interfaces

Processor: Pentium IV AND motherboard
RAM: 512MB or above
Hard Disk: 40GB or above
Input Devices: Keyboard, Mouse
Output Devices: Monitor; -14 VGA
3.1.4 Software Interfaces
OPERATING SYSTEM: Windows 10
FRONT END: C#
BACK END: MY SQL
3.1.4.1 Microsoft SQL Server

The system must use SQL Server as its database component. Communication with the
DB is through ODBC connections. The system must provide SQL data table definitions
to be provided to the company DBA for setup.

SRS Document 1.0

Page 6 of 9

03/17/16

Project Title

A key point to remember is that you do NOT want to specify software here that you think
would be good to use. This is only for customer-specified systems that you have to
interact with. Choosing SQL Server as a DB without a customer requirement is a Design
choice, not a requirement. This is a subtle but important point to writing good
requirements and not over-constraining the design.
3.1.5 Communications Interfaces
The system shall be a standalone product that does not require any communication
interfaces.

3.2 Functional Requirements

Sr. No.

Description

SRS-01

System should be able to Save Patient Record

SRS-02

System should be able to Save Doctor Record

SRS-03

System should be able to Save Bed Record

SRS-04

System should be able to Show Patient Report

SRS-05

System should be able to Show Doctor Report

SRS-06

System should be able to Show Bed Report

SRS-07

System should be able to Show Patient History

SRS-08

System should be able to Admit the patient

SRS Document 1.0

Page 7 of 9

03/17/16

Project Title

3.3 Use Case Diagrams:

UC: 01

SRS Document 1.0

Page 8 of 9

03/17/16

Project Title

UC: 02
Use Case Add Patient
SRS Document 1.0

Page 9 of 9

03/17/16

Project Title

Description: This use case describes the process of saving patient in the application.
Actor: User

Pre-condition:1- User must open Patient Form

Flow of events:Primary Scenario:1. User will run application and open Patient Form.
2. User will enter patient Data.
3. User will click the Add Button.
4. Patient Data will be Saved
5. This use case ends.

Exceptions:(a) User given Invalid Patient Id

Post Condition:
SRS Document 1.0

Page 10 of 9

03/17/16

Project Title

The Data will saved successfully.

UC: 03
Use Case Add Doctor
Description: This use case describes the process of saving Doctor Record in the application.
Actor: User

Pre-condition:1. User must open Doctor Form

Flow of events:Primary Scenario:1.

2.
3.
4.
5.

User will run application and open doctor Form.

User will enter doctor Data.
User will click the Add Button.
Doctor Data will be Saved
This use case ends.

Exceptions:SRS Document 1.0

Page 11 of 9

03/17/16

Project Title

(a) User given Invalid Doctor Id

Post Condition:
The Data will save successfully.

UC: 04

Use Case Add Bed Record

Description: This use case describes the process of saving Bed Record in the application.
Actor: User

Pre-condition:1. User must open Bed Form

Flow of events:-

SRS Document 1.0

Page 12 of 9

03/17/16

Project Title

Primary Scenario:1.
2.
3.
4.
5.

User will run application and open Bed Form.

User will enter Bed Data.
User will click the Add Button.
Bed Data will be Saved
This use case ends.

Exceptions:(a) User given Invalid Bed Id

Post Condition:
The Data will saved successfully.

UC: 05
Use Case Admit Patient

Description: This use case describes the process of saving Admission Record of patient in the
application.

Actor: User

SRS Document 1.0

Page 13 of 9

03/17/16

Project Title

Pre-condition:1. User must open Admission Form

Flow of events:Primary Scenario:1.

2.
3.
4.
5.
6.
7.
8.

User will run application and open Admission Form.

User Will select Patient Id
User Will select Doctor Id.
User Will select Bed Id
User will enter Disease Data
User will click the Add Button.
Patient will be admitted
This use case ends.

Exceptions:(a) User given Invalid Bed Id, Patient Id and Doctor Id

Post Condition:
The Patient Will admitted successfully

SRS Document 1.0

Page 14 of 9

03/17/16

Project Title

UC: 06
Use Case view Patient History
Description: This use case describes the process of view Patient History the in this
application

Actor: User

Pre-condition:
User should open Patient History Form.

Flow of events:Primary Scenario:1.

2.
3.
4.
5.

User will click on Patient History Form

User will select Patient Id
User will click on View History
History of patient will be viewed.
This use case ends.

Exceptions:(a) No Patient is entered

Post Condition:
The Patient History will be viewed.
SRS Document 1.0

Page 15 of 9

03/17/16

Project Title

3.5 Non-Functional Requirements

Descriptions

Sr No.
01

It necessary for run the project to install the Visual Studio 2010

02
There should be running windows operating system

03 Crystal Report Component should be installed

04
SQL Server should be installed

05
Data base file should be Accessible

3.7Logical Database Requirements

The proposed information system contains the following data tables in its database collection.
i
ii
iii
iv

Patient Details table

Doctor Details Table
Room Details Table
Bill Details table

5. Supporting Information
Appendix A Background Research on:
Topic 1
Topic 2
Topic 3

Topic n
Appendix B Data Dictionary

SRS Document 1.0

Page 16 of 9

03/17/16