Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 12

<Enter team name here>

<Hospital Patient Management System >


Software Requirements Specification
Version <1.0>
11/16/2020

© 2020 <Enter team name here> <Drive:\Directory\Filename.ext>


Software Requirements Specification

Document Control
Approval
The Guidance Team and the customer shall approve this document.

Document Change Control


Initial Release: Version 1
Current Release: Version 1
Indicator of Last Page in Document: 13
Date of Last Review: 9/11/2020
Date of Next Review: 20/11/2020
Target Date for Next Update: None Scheduled

Distribution List
This following list of people shall receive a copy of this document every time a new version of this document
becomes available:
Guidance Team Members:
Mrs. Wafa Al-Tarawneh
Customer:
Software Team Members: <<1-Lujain Salah
2- Salsabeel Aldarabie >>

Change Summary
The following table details changes made between versions of this document

Version Date Modifier Description


1 9/11/2020 team members Study for software Requirements
Specification document for the system

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 2
Software Requirements Specification

Table of Contents

DOCUMENT CONTROL II
APPROVAL II
DOCUMENT CHANGE CONTROL II
DISTRIBUTION LIST II
CHANGE SUMMARY II

1. INTRODUCTION 3
1.1. PURPOSE AND INTENDED AUDIENCE 3
1.2. SCOPE OF PRODUCT 3
1.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS 3
1.3.1. Definitions 3
1.3.2. Acronyms 3
1.3.3. Abbreviations 3
1.4. OVERVIEW 3
1.5. REFERENCES 3
2. GENERAL DESCRIPTION 3
2.1. PRODUCT PERSPECTIVE 3
2.2. PRODUCT FUNCTIONALITY AND FEATURES 3
2.3. USER CHARACTERISTICS 3
2.4. GENERAL CONSTRAINTS 3
2.5. ASSUMPTIONS AND DEPENDENCIES 3
3. SPECIFIC REQUIREMENTS 3
3.1. EXTERNAL INTERFACE REQUIREMENTS 3
3.1.1. User Interfaces 3
3.1.2. Hardware Interfaces 3
3.1.3. Software Interfaces 3
3.1.4. Communications Interfaces 3
3.2. BEHAVIORAL REQUIREMENTS 3
3.2.1. Same Class of User 3
3.2.3. Stimulus 3
3.2.4. Related Features 3
3.2.5. Functional 3
3.3. NON-BEHAVIORAL REQUIREMENTS 3
3.3.1. Performance Requirements 3
3.3.2. Qualitative Requirements 3
3.3.3. Design and Implementation Constraints 3
3.4. OTHER REQUIREMENTS 3
3.4.1. Database 3
3.4.2. Operations 3
3.4.3. Site Adaptation 3

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 3
Software Requirements Specification

1. Introduction
1.1. Purpose and Intended Audience
The purpose of this document is to describe all the requirements for the Hospital Patient Management
System(HPMS). The intended audience includes all stakeholders in the potential system. These include, but are
not necessarily limited to, the following: administrative staff, doctors, nurses, surgeons and developers.

Developers should consult this document and its revisions as the only source of requirements for the project.
They should not consider any requirements statements, written or verbal as valid until they appear in this
document or its revision.

The hospital management and its team members should use this document and its revisions 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.
Please note that only the requirements that appear in this document or a future revision, however, will be
used to define the scope of the system.

1.2. Scope of Product


The proposed software product in the Hospital Patient Management System (HPMS). The system will be
used to allocate beds to patients on a priority basis, and to assign doctors to patients in designated wards as
need arises. Doctors will also use the system to keep track of the patients assigned to them Nurses who are in
direct contact with the patients will use the system to keep track of available beds, the patients in the
different wards, and the type of medication required for each patient. 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.
Doctors must make rounds to pick up patients' treatment cards in order to know whether they have cases to
treat or not. The intentions of the system are to reduce overtime 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


1.1.1. Definitions

Word Meaning

Report an account of patients

Database collection of information in a structured form

Front-desk staff administrative staff that work at reception desk

Login ID a user identification number to enter the system

Password a word that enables one to gain admission into


the system

Web -based application an application that runs on the Internet

Windows 2000 an operating system produced by Microsoft


corporation that is Used to operate the
computer using a graphical user interface

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 1
Software Requirements Specification

1.1.2. Acronyms

Word Meaning

MySQL A query language to interrogate the system

ID Patient Identification number

1.1.3. Abbreviations

Word Meaning

HPMS Hospital Patient Management System

PHN Personal Health Number on health card

GUI Graphical User Interface

SRS Software Requirements Specification

1.4. Overview
This software Requirements Specification (SRS) is the requirements work product that formally specifies
Hospital Patient Management System (HPMS). it includes the results of both business analysis and system
analysis efforts. Various techniques were used to elicit the requirements and we have identified your needs,
analyzed and refined them. The objective of this document therefore is to formally describe the system’s high
level requirements including functional requirements, non-functional requirements and business rules and
constraints. The detailed structure of this document is organized as follows:
Section 2 of this document provides an overview of the business domain that the proposed Hospital Patient
Management System (HPMS) will support. These include a general description of the product, user
characteristics, general constraints, and any assumptions for this system. This model demonstrates the
development team’s understanding of the business domain and serves to maximize the team’s ability to build
a system that truly does support the business.

Section 3 presents the detail requirements, which comprise the domain model. Picture 1 shows an overview of
the Hospital Patient Management System and the relationships between requirements.

1.5. References
1- E-learning (Example_software_requirement_specification_report)

2.

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 2
Software Requirements Specification

3. General Description

1.6. Product Perspective


This Hospital Patient Management System is a self-contained system that manages activities of the hospital as
bed assignment, operation scheduling, personnel management and administrative issues. Various
stakeholders are involved in the hospital system. A general picture of the system and the relationship between
various stakeholders in the hospital in shown in picture 2

1.7. Product Features


The System functions can be described as follows:
Registration: When a patient is admitted, the front-desk staff check 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 the computer system.
Consultation: The patient goes to consultation-desk to explain his/her condition so that the
consulting nurse can determine what kind of ward and bed should be assigned to him/her.
There are Two possible circumstances:
a) if there is a bed then the patient will be sent to the bed to wait for the doctor to
come.
b) if there is no bed, the patient is put on a waiting list until a bed becomes available.
Patient check out: If the patient checks out, the administrative staff shall delete his (PHN)
from the system and the just evacuated bed is included in available- beds list.
Report Generation: The system generated reports on the following information patients, bed
availability and staff schedules after every six hours. It prints out all the information on who
has used which bed, when and the doctor that is taking care of a given patient as well as
expected medical expenses.

1.8. User Characteristics


The system will be used in the hospital. the administrators, doctors, nurses and front-desk staff will be the
main users. Given the condition that not all the users are computer-literate. Some users may have to be
trained on using the system. The system is also designed to be user-Friendly. it uses a Graphical User
Interface(GUI).
Front-desk staff:
they all have general reception and secretarial duties. Every staff has some basic computer training. They are
responsible for patient’s check-in or notification of appropriate people.

Administrators:
They all have post-secondary education relating to general business administration practices. Every
administrator has basic computer training. they are responsible for all the scheduling and updating day/night
employee shifts. Administration in the wards are responsible for assigning doctors and nurses to patients.

Nurses:
All nurses have post-secondary education in nursing. Some nurses are computer literate. Consulting nurses to
whom patients give short descriptions of their conditions are also responsible for assigning patients to

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 3
Software Requirements Specification

appropriate wards if the beds are available, otherwise putting patients on the waiting list. Nurses in wards will
use the HPMS to check their patient list.

Doctors:
All doctors have a medical degree. Some have further specialized training and are computer literate. Doctors
will use the HPMS to check their patient’s lists.

1.9. General Constraints


1- System is wirelessly networked with an encryption .
2- System is only accessible within the hospital premises only .
3- Daily entries are recorded in the database .
4- Database is password protected .
5- Each user should have an individual ID and password .
6- Only the administrator can access the whole system .
7- System must be user-friendly .
8- System must be delivered by deadline .

1.10. Assumptions and Dependencies


- The computer that will run the system should have a semi-distinct specification of at least Pentium 4
and 256 MB =RAM.
- The server must be programmable bto (DB Oracle).
- The hospital will have enough staff to take care of the system .
- Each user must have a valid user ID and password .
- Only the administrator can delete records .

4.

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 4
Software Requirements Specification

5. Specific Requirements

1.11. External Interface Requirements


------------

1.1.4. User Interfaces


The application will have a user friendly interface.Following screens will be provided
1- A login Screen for entering username, password and role will be provided(Administrator,patient).
Access to different screens will be based upon the role of the user
2- A Form for Search the details of a patient
3- The form for creating a new patient record will contain text fields where the Patient ID will be
machine generated and the rest of the details will have to be filled up

1.1.5. Hardware Interfaces


Operating system:windows
Hard Disk:40GB
RAM:256 MB
Processor:Pentium(R)Dual-core CPU

1.1.6. Laptop/Desktop PC
core i5 processor
4GB RAM
500GB HDD
The purpose of this PC is to give information when patients ask information about doctors,medicine available,
lab tests etc. To perform such Action it needs a very efficient computer otherwise due to that reason patients
have to wait for a long time to get why they ask for it .

- Display Unit (LED/LCD Monitor/tv)


This unit is for displaying the channel number when the patients come to see their consultants. it will
avoid chaos.

- Wi-Fi router
Wi-Fi routers are used for internetwork operations inside of a hospital and simply data transmission
from pc to server.

1.1.7. Software Interfaces


- Developing end
JDK 1.8 -java is fast.secure and reliable
MySQL server -Database connectivity and management
- Client end
OS-Windows 7/8/10 - user-friendly OS

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 5
Software Requirements Specification

MySQL server -Database connectivity

1.1.8. Communications Interfaces


Windows

1.12. Behavioral Requirements


1.1.9. Same Class of User
The people who will use the system are:
● Front Desk staff
● Doctors
● Nurses
● Patients
All of the them have the ability to handle the system easily

1.1.10. Stimulus
● Time saving technology
● reduces scope of error
● Data Security and correct data retrieval made possible
● improved patient care made possible

1.1.11. Related Features


Patient Registration Process
This section allows you to seek important information about patient information
charts and the available time slots of your most preferred doctor.
Action Plan Management
This feature is useful to maintain a detailed plan for all the treatment goals. This
solution facilitates everyone at the operating level to prepare and implement a
related action plan. Doctors,staff,and patients are automatically alerted for and
after every move with regard to the action plan .

1.1.12. Functional
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 HPMS 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.
Check out
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
Database
Mandatory Patient information: Every patient has some necessary date like phone number, their first and last
name, personal health number, postal code, county, address, city, patient’s ID number

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 6
Software Requirements Specification

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

1.13. Non-behavioral Requirements


1.1.13. Performance Requirements
Response Time
The system shall give responses in 1 second after checking the patient’s information
Capacity
The system must support 1000 people at a time
User- interface
The user-interface screen shall respond within 5 seconds
Conformity
The system must conform the the Microsoft Accessibility guidelines

1.1.14. Qualitative Requirements


Good Quality of the framework=produces robust, bug free software which contains
all necessary requirements Customer Satisfaction

1.1.1.1. Availability
The system shall be available all the time.

1.1.1.2. Security
Patient Identification
The system requires the patient to identify himself/herself using PHN

Login ID
Any user who uses the system shall have a Login ID and Password.

Modification
Any modification(insert,delete,update) for the Database shall be synchronized and done only by the
administrator in the ward

Compliance
The system must comply with the Regional Health Authority Regulations concerning privacy

Front Desk staff rights


Desk Staff shall be able to view all information in HPMS, add new patients to HPMS but shall not be able to
modify any information in it.

Administrator’s Rights
Administrators shall be able to view and modify all information in HPMS

Nurse’s Rights
Nurses shall only be able to view all information in HPMS

Doctors rights

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 7
Software Requirements Specification

Doctors shall only be able to view all information in HPMS

1.1.1.3. Maintainability
Back up
The system shall provide the capability to back-up the data
Errors
They system shall keep a log of all the errors

1.1.1.4. Portability
The application will be easily portable on any windows-based system that has oracle installed

1.1.15. 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 10
Web-Based
The system shall be a Web-based-application.

1.14. Other Requirements


1.1.16. Database
Patient Mandatory Information
Each patient shall have the following mandatory information: first name, last name, phone number,
personal health number,address, postal code, city, country, patient identification number.
Update Patient Information
The HPMS shall allow the user to search for patient’s information by last name of PHN or patient ID
Search for Patient
the HPMS shall allow the user to search for patient’s information by last name or PHN or patient ID
Staff Mandatory Information
Each staff in hospital shall have the following mandatory information: identification number,
firstname, lastname,phonenumber,address,postal code,city,country,employee type,duty schedule
Update Staff Information
The HPMS shall allow the user to update any of the staff’s information
Employee Information
The HPMS shall allow the user to search for employee information by lasata name, or ID Number
Ward Types
The ward is categorized into four types:Maternity, Surgical, Cancer and Cardiac
Ward information

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 8
Software Requirements Specification

Each ward in HPMS shall include the following mandatory information: ward name, ward number, list
of rooms in ward.
Room Information
Each room in HPMS shall include the following mandatory information: room number, list of beds in
room, full/not full.
Bed Information
Each bed in HPMS shall include the following information:bed number,occupied/unoccupied, patient
PHN
Ward Search
The HPMS shall allow users to search the ward, room, and bed directly by ward number, room and
bed number respectively, or hierarchical hyperlinks from ward to bed .

1.1.17. Operations
The system will allow access only to authorized users will specific roles(Administrator, patient)Depending upon
the user's 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
● A login facility for enabling only authorized access to the system
● When a patient is admitted, the front desk staff check to see if the patient is already registered with
the hospital . if he is , his/her Name is entered into the computer Otherwise a new Patient ID is given
to the patient
● If a patient check 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 had admitted in the hospital

1.1.18. Site Adaptation


This system will be linked to the Ministry of Health website where a link to the system will be on the main
page of the site so that any patient can access it once accessing the ministry's website.

Software Requirements Specification <Enter team name here> Date Page


11/16/2020 3:49 AM 9

You might also like