PROJECT REPORT

ON
HOSPITAL MANGEMENT

SOFTWARE REQUIREMENT SPECIFICATION

SUBMITTED BY
MUHAMMAD ABDURREHMAN (FA-19-BSCS-10)

WAQAR UL HASSAN(FA-19-BSCS-17)

MARGHOOB AHMED KHALID (FA-19-BSSE-013)

YTable of Contents.......................................................................................................................................ii
Introduction.................................................................................................................................................1
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References
Overall Description........................................................................................................................................
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3.External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4.System Features.........................................................................................................................................
4.1 System Feature 1
4.2 System Feature 2 (and so on)
5.Other Nonfunctional Requirements.........................................................................................................4
5.1 Performance Requirements
5.2 Safety Requirements 5
5.3 Security Requirements 5
5.4 Software Quality Attributes
5.5 Business Rules 5
6.Other Requirements.................................................................................................................................5
Appendix A: Glossary...................................................................................................................................5
Appendix B: Analysis Models.......................................................................................................................5
Appendix C: To Be Determined List.............................................................................................................6
INTRODUCTION

This is a Software Requirements Specification (SRS) for the Hospital Management System. It
describes the functions, goals and tasks that the system can perform. This is used to describe
the scope of the project and to plan for the system’s design and implementation.
The following features are the high-level requirements that this system satisfies:

 Work Scheduling - Assigning nurses to doctors and doctors to patients

• Admissions - Admitting patients, assigning the patients to appropriate wards

• Patient Care - Monitoring patients while they are in the hospital

• Surgery Management - Planning and organizing the work that surgeons and nurses perform
in the operating rooms
• Ward Management - Planning and coordinating the management of wards and rooms
• Waiting list - Monitoring to see if there are any patients waiting for available beds, assigning
them to doctors and beds once these become available.
The Requirements are classified into two categories:
• Functional requirements

• Non-functional requirements

1.1 PURPOSE:
The software is used for automation hospital management it maintains two levels
1. Administration level
2. User level
The software includes maintaining patient’s details.

 Providing the prescription proving prescription and diet advice

 Providing and maintain all kind of tests for patients
 Billing and the report generation
The purpose is to describe all the requirements for the Hospital Management System. The
following some are some of the stake holders:
1. Administrative staff
2. Doctors
3. Nurses
4. Surgeons
5. Developers.

The hospital management and its team members use this document as the primary means to
communicate confirmed requirements to the development team. The development team
expects many face-to-face conversations that will undoubtedly be about requirements and
ideas for requirements. However only the requirements that appear in this document or a
future revision, will be used to define the scope of the system.

1.2 Document convention

The SRS document contain few different Font sizes for clear distinction. The main Headings
have size 16 font. The normal details are also in a size of 12.

1.3 Intended Audience and Reading Suggestions:

The software requirement is intended for software engineer’s system tester and software
designer in developing testing and producing the SHMS and for the project it is suggested to read the
sections sequentially and to the reference the appendices as one progress

1.4 Project Scope:

This SRS explains how the Soft Right Hospital Management System project and its five subsystems came
to be. This project is open source, and Soft Right Inc. will not impose any restrictions on its modification.
Soft Right Inc. is not liable or responsible for any improvements made to this project since it was first
published.
Overall Description
2.1 Product Perspective
The Soft Right Hospital Management System is a free and open-source system with five
subsystems. The following are the five subsystems:
Similar to how Microsoft Word is a separate program within the Microsoft Office suite, the
FOSS RIS project is a separate program that is a part of a broader FOSS Hospital Management
System (HMS). The FOSS RIS software conducts all of the tasks in the FOSS HMS method.
Hospital Information System will replace all traditional and outdated means of tracking patient
information and other data useful to the hospital. A Hospital Information System shall replace
forms of databases using manual or outdated hardcopy databases. Accessing data can be better
monitored, organized, and time conscientious. The IAM program shall be a new management
system which shall make individual systems obsolete. It shall allow one program to control all
the different image acquisition devices and shall interact with the other components of the
hospital management system being designed. The driving principle of this PACS is to automate
and provide the infrastructure to digitally control the storage and transportation of images
taken with compatible devices within a general hospital. The ADT/PRS subsystem stores patient
data, which other subsystems can access as required. This is accomplished by granting the
other systems access to this subsystem’s patient database

2.2 Product Features

2.3 User Classes and Characteristics
There are a number of users in the FOSS SHMS suite application, each with different security
privileges. Head doctor/nurse and doctor/nurse are the two user forms. The head doctor/nurse
has read/write permissions on sending, can monitor much of the system, and can move data
in/out of hospital networks and to other doctors/nurses who need the patient's medical
information from the patient database.

2.4 Operating Environment

HMS program runs on Windows 10, for 64-bit/x86 and 64-bit/x64 PC architectures. The
software for the RIS subsystem will be written in C#, using Microsoft Visual Studio 2019. The
program will be GUI-based (like with most modern Windows software). And data will be stored
tin database of my SQL server.

2.5 Design and implementation Constraints

It is a desktop-based application.
Database
The system will use my sql serever 2019 which open source free
Operating system
The developemetn will be in window 10

2.6 User Documentation

The application will come with an “About” tab, which will allow users to access the offline and
online HTML .hlp help manual. This manual will be updated with each new service pack. Other
user documentation includes one user manual for lowest level users, one technical document
describing the functionality of the subsection in detail for use of technicians, one copy of
documentation and link to current source for future contributors.

2.7 Assumption and Dependencies

The project will have to depend on FOSS (free and open-source) SQL database libraries, 7zip .7z
compression libraries, Open TLS libraries, TCP/IP libraries, and other FOSS libraries, in order to
keep this software free of proprietary libraries, in order to keep the software in a FOSS status.
This project is developed under the working assumption that as an open-source project it shall
be noted that the project shall change overtime. Regular changes to this SRS shall occur for
each change enacted by Soft Right Inc.

2.8 Context Diagram

Flow diagram
 2.10 Assumptions and dependencies:

It is a Desktop-based application. It will be more benefitted and to make this system secure. It
depends on the Hospital management.

3 External Interface Requirements

3.1 Users interface

 User will have GUI based simple login form.
 User will enter the patient details.
 It will be user friendly.
3.2 Hardware Interfaces

Our system can interact with a hardware device directly. We have to connect our system to the
bill printer for handing the hard copy of the bill to the user. For billing module, we may
have to use a credit card reader for payment.

3.3 Software Interfaces

 It includes SQL for database which will store data for patient’s and doctor details.
 It includes visual studio where we will work on GUI and other programs related to our
system.
 System will run on Desktop.
USE CASE NAME Login

SCOPE Admin
LEVEL admin will be able to login
PRIMARY ACTOR Admin

PRE-CONDITIONS Admin must have correct username and password to login. If they don’t have, they
can’t login
SUCCESS
After correct login admin should check the dashboard
Guarantee

Main success User action System action

scenario
1- admin enter username 2- system verify the information and enter by the
and password and click admin login
login button
Extensions User action System action

1a] if admin enter wrong 2a] system will pop a message written wrong username or
password or username password
Special Nil
requirements

Frequency Low

USE CASE COMMENTS

SECTION
USE CASE Patient registration
NAME

SCOPE Admin
LEVEL Admin will be able to add the details of the patients
PRIMARY Admin
ACTOR

PRE- Admin must have logged in the system

CONDITIONS
SUCCESS
All entries of patient would be done by admin
Guarantee

Main success User action System action

scenario
1- admin presses add button 2- Added the patient details

Extensions User action System action

1a] if user enter wrong 2a] system will pop a message written wrong
password or user name login
unsuccess full

Special Nil
requirement
s
Frequency Low

USE CASE SECTION COMMENTS

USE CASE NAME Doctor

SCOPE Admin

LEVEL Admin will be able to add doctor details

PRIMARY ACTOR Admin

PRE- Admin must have logged in the system

CONDITIONS

SUCCESS
All entries of doctor would be done by admin
Guarantee

Main success User action System action

scenario
1- admin presses add button 2- Added the doctor details

Extensions User action System action

1a] if user enter wrong 2a] system will pop a message written wrong
password or user name login
unsuccess full

Special Nil
requirements

Frequency Low

USE CASE COMMENTS

SECTION
USE CASE appointment
NAME

SCOPE Admin

LEVEL admin will be able to add appointment information

PRIMARY Admin
ACTOR

PRE- admin must have logged in the system

CONDITIONS

SUCCESS
Appointment detail must be added
Guarantee

Main success User action System action

 scenario

1- admin click add 2- System will display doctor info

button to add patient
booker info button
Extensions User action System action

Nil Nil

Special Nil
requirements

Frequency High

USE CASE COMMENTS

SECTION
USE CASE Admin
NAME

SCOPE Admin
LEVEL admin will be able to search patient and doctor
PRIMARY Admin
ACTOR

PRE- admin must have logged in the system

CONDITIONS
SUCCESS
Details must be shown
Guarantee

Main success User action System action

scenario
1- admin click add button 2- System will display doctor info
to add patient booker
info button

Extensions User action System action

Nil Nil

Special Nil
requirements
Frequency High
 USE CASE SECTION COMMENTS

USE CASE NAME Laboratory

SCOPE Admin

LEVEL Admin will be able to take patient test

PRIMARY ACTOR Admin

PRE-CONDITIONS Admin must have logged in the system

SUCCESS
All entries of patient test would be done by admin
Guarantee

Main success User action System action

scenario
1- admin presses add button 2- Added the patient details

Extensions User action System action

1a] if user enter wrong 2a] system will pop a message written wrong
password or user name login
unsuccess full

Special requirements Nil

Frequency Low
4.1 Use case model
4.2 Activity diagram (complete system)
Sequence diagram
Class Diagram
functional Requirements: 
There are a lot of software requirements specifications included in the functional requirements
of the Hospital Management System, which contains various process, namely Registration,
Check out, Report Generation, and Database.

 
Registration Process of SRS (Software Requirements Specification) 
Adding Patients: The Hospital Management enables the staff in the front desk to include new
patients to the system.
Assigning an ID to the patients: The HMS enables the staff in the front desk to provide a unique
ID for each patient and then add them to the record sheet of the patient. The patients can
utilize the ID throughout their hospital stay. 

Check Out of SRS: 

Deleting Patient ID: The staff in the administration section of the ward can delete the patient ID
from the system when the patient's checkout from the hospital.
 Adding to beds available list: The Staff in the administration section of the ward can put the
bed empty in the list of beds-available.

Report Generation of SRS:

Information of the Patient: The Hospital Management System generates a report on every
patient regarding various information like patient’s name, Phone number, bed number, the
doctor's name whom its assigns, ward name, and more.
Availability of the Bed: The Hospital Management system also helps in generating reports on
the availability of the bed regarding the information like bed number unoccupied or occupied,
ward name, and more. 

Database of SRS: 
Mandatory Patient Information: Every patient has some necessary data like phone number,
their first and last name, personal health number, postal code, country, address, city, 'patient's
ID number, etc.
Updating information of the Patient: The hospital management system enables users to update
the information of the patient as described in the mandatory information included.

Non-Functional Requirements 
There are a lot of software requirements specifications included in the non-functional
requirements of the Hospital Management System, which contains various process, namely
Security, Performance, Maintainability, and Reliability.

Security:
Patient Identification: The system needs the patient to recognize herself or himself
using the phone.
Login ID: Any users who make use of the system need to hold a Logon ID and
password.
Modifications: Any modifications like insert, delete, update, etc. for the database can be
synchronized quickly and executed only by the ward administrator.
Front Desk Staff Rights: The staff in the front desk can view any data in the Hospital
Management system, add new patients record to the HMS but they don't have any rights alter
any data in it.
Administrator rights: The administrator can view as well as alter any information in the
Hospital Management System.

Performance: 
Response Time: The system provides acknowledgment in just one second once the 'patient's
information is checked.
Capacity: The system needs to support at least 1000 people at once.
User-Interface: The user interface acknowledges within five seconds.
Conformity: The system needs to ensure that the guidelines of the Microsoft accessibilities are
followed.

Maintainability: 
Back-Up: The system offers the efficiency for data back-up.
Errors: The system will track every mistake as well as keep a log of it. 

Reliability: 
Availability: The system is available all the time. 
Hope you got a clear idea on the functional and non-functional requirements and the features
required by the hospital. Any other queries on the topic are welcome.
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: To Be Determined List
Dashboard

Doctor
Paitent
Admin

Appoiment
lbroartry