Software Requirements Analysis Document (RAD)
Project Title: Hospital Management System
Name (s):
1) Shishir Oyshi
2) Md. Ashrafur Islam
TABLE OF CONTENTS
1. Introduction
1.1 Purpose of the system
1.2 Scope of the system
1.3 Objective and success criteria of the project
1.4 Definitions and Acronyms and abbreviations
1.5 References
1.6 Overview
2. OverallDescription
2.1 Product Perspective
2.2 Product Function
2.3 User Profiles
2.4 Constraint
2.5 Assumption and Dependencies
3. Proposed System
3.1 Overview
3.2 Functional Requirement
3.2.1
Requirement 1 (id, name, description, priority)
3.2.2
Requirement 2 (id, name, description, priority)
3.2.3
...
……
…
3.2.20 Requirement 20 (id, name, description, priority)
3.3
Non Functional Requirement
3.3.1
Usability
3.3.2
Reliability
3.3.3
Performance
3.3.4
Supportability
3.3.5
Implementation
3.3.6
Scalability
3.3.7
Security
3.3.8
Maintainability
3.3.9
Testability
1
1
2
3
…
…
…
3.4
System Models
3.4.1
Scenarios
3.4.1.2
Scenario 1
3.4.1.2
Scenario 2
…….
………….
3.4.1.20 Scenario 20
3.4.2
Use cases
3.4.2.1
Use case 1 (name, actors, flow of event, special
..)
….
……………
3.4.2.20 Use case 20 (name, actors, flow of event,
special..)
3.4.3
Use case model
3.4.4
Dynamic model
3.4.4.1
Sequence Diagram
3.4.4.2
Activity Diagram
3.4.4.3
State Diagram
3.4.5
User Interface
3.4.5.1 User Interface
3.4.5.2 Software Interface
3.4.5.3 Hardware Interface
4. Supporting Information
1.1 Purpose of the System:
The hospital management system is a software application designed to help healthcare
organizations manage their daily operations more efficiently. The system's purpose is to
provide healthcare professionals with a user-friendly platform that can be used to
manage patient data, track medical inventory, and schedule appointments, among other
tasks. By using the hospital management system, healthcare organizations can save
time, reduce errors, and improve the quality of patient care.
1.2 Scope of the System:
This RAD covers the requirements for version 1.0 of the hospital management system.
The system is designed to be used by healthcare organizations of all sizes, from small
clinics to large hospitals. The system will consist of several modules, including patient
management, inventory management, appointment scheduling, and billing. The system
will be accessible through a web-based interface and will be compatible with all major
web browsers.
1.3 Objective and Success Criteria of the Project:
The primary objective of the hospital management system project is to create a software
application that meets the needs of healthcare organizations and healthcare
professionals. The success of the project will be measured by the following criteria:





The system must be user-friendly and easy to navigate.
The system must be able to handle a large amount of patient data without slowing down
or crashing.
The system must be able to generate accurate reports on patient care, inventory
management, and billing.
The system must be secure and protect patient data from unauthorized access.
The system must be scalable and able to accommodate the needs of growing
healthcare organizations.
1.4 Definitions and Acronyms and Abbreviations:



Healthcare organization: A company or entity that provides healthcare services to
patients.
Patient management: The process of collecting, storing, and managing patient data.
Inventory management: The process of tracking medical inventory, including
medications, equipment, and supplies.




Appointment scheduling: The process of scheduling patient appointments with
healthcare professionals.
Billing: The process of generating invoices for healthcare services.
RAD: Rapid Application Development.
GUI: Graphical User Interface.
1.5 References:



Hospital Management System Vision and Scope Document, Version 1.0, XYZ
Corporation.
Hospital Management System User Interface Specification, Version 1.0, XYZ
Corporation.
Hospital Management System System Requirements Specification, Version 1.0, XYZ
Corporation.
1.6 Overview:
The hospital management system is a web-based software application designed to help
healthcare organizations manage their daily operations more efficiently. The system
consists of several modules, including patient management, inventory management,
appointment scheduling, and billing. The system is designed to be user-friendly, secure,
and scalable, and will be compatible with all major web browsers. This RAD covers the
requirements for version 1.0 of the hospital management system, and is one of several
documents that will be produced during the project's development.
2.1 Product perspective: Our software product is a new, self-contained product
designed to provide a web-based platform for healthcare management. It is not a followon member of any existing product family or a replacement for any existing system. The
product will have several subsystems that will interact with external interfaces.
2.2 Product functions: The major functions of our software product are as follows:




Allow patients to create and manage their profiles
Enable patients to schedule appointments with doctors and view their medical history
Allow doctors to manage their appointments and patient records
Enable administrators to manage user accounts and access control

Provide data analytics and reporting functionalities
2.3 User Profiles: The user classes that we anticipate will use our product are patients,
doctors, and administrators. The pertinent characteristics of each user class are as
follows:



Patients: They have limited technical expertise and may have varying educational
levels. They are expected to use the software frequently to manage their health-related
activities.
Doctors: They have high technical expertise and educational levels. They are expected
to use the software frequently to manage their appointments and patient records.
Administrators: They have high technical expertise and educational levels. They are
expected to use the software infrequently to manage user accounts and access control.
2.4 Constraints: The following constraints will limit the options available to our
developers:



Hardware limitations: The software must be designed to run on a variety of hardware
configurations, including mobile devices.
Communications protocols: The software must use secure communication protocols to
ensure the privacy and security of patient data.
Design conventions or programming standards: The software must adhere to
programming standards and design conventions to ensure maintainability and
extensibility.
2.5 Assumptions and dependencies: The following assumptions and dependencies
could affect the requirements stated in this RAD:


Third-party or commercial components: We assume that we will be able to use existing
third-party components to implement certain features of the software, such as data
analytics.
Development or operating environment: We assume that the development and
operating environments will be stable and will not change significantly during the
project.
3. Specific Requirement
3.2 Functional Requirement:
Admin: This user should allow edit, delete, insert information of the patient portal
as well as doctor portal, Pathologist, medicine shop portal. This user also can handle
the ICU, CCU, Operation theater.
Patient Management: The system should allow patients to register online and book
appointments with doctors. The system should be able to manage patient records,
including their medical history, treatments, and medication.
Doctor Management: The system should allow doctors to manage their schedules
and view patient appointments. The system should also allow doctors to update
patient records with their diagnosis, treatment plan, and medication. The system
should allow patients to book appointments with doctors and manage their
appointments. The system should also allow doctors to manage their schedules and
view patient appointments.
Pathologist: The system should manage laboratory test requests and results and also
should provide emergency services like ambulance and emergency contact numbers
for patients.
Medicine Shop: The system should manage pharmacy inventory and dispensing of
medication.
3.3 Non Functional Requirement:
Usability: The system should have a user-friendly interface that allows users to
easily navigate and find what they are looking for. This includes clear and intuitive
menus, icons and search functions. All users, including people with disabilities or
special needs, can access the system. This means that the system must have features
such as keyboard navigation and a screen reader.
Reliability: The system should have mechanisms to ensure that patient data is
accurate and up-to-date. This includes data validation checks and data
synchronization across different modules and departments. The system should be
available at all times, with minimal downtime for maintenance or upgrades. This is
particularly important for critical functions such as patient care and emergency
services. The system should have regular backups of all data and be able to recover
data quickly in the event of a system failure or data loss.
Performance: The system should respond quickly to user requests, with minimal
loading times for pages and modules. This is particularly important for critical
functions such as patient care and emergency services. The system should respond
promptly to user actions, with minimal delay or lag time.
Supportability: The system should be designed and built with maintainability in
mind, which includes easy upgrades, bug fixes, and modifications. This is important
for ensuring that the system remains current with the latest technology and continues
to meet the evolving needs of the hospital.
Scalability: The system should be designed to scale as the hospital grows, with the
ability to handle increased user traffic, data processing, and storage requirements
Security: The system should have robust security measures in place to protect
patient data from unauthorized access, data breaches, and other security threats.
Maintenance: The system should be easy to maintain, with the ability to apply
updates and patches without disrupting hospital operations.
Testability: The system should have a comprehensive set of test cases that cover all
of its features and functions, including edge cases and error scenarios.
3.4 System Models
3.4.1 Scenarios
A patient visits the hospital and registers themselves with the receptionist. The
receptionist creates a new patient record in the system and assigns the patient an ID
number. The patient then consults with a doctor. The doctor logs into the system,
retrieves the patient's record, and creates a new medical record for the patient. The
doctor performs various tasks such as diagnosing the patient, prescribing medication,
and ordering lab tests.
The doctor requests lab tests for the patient, which are then processed by the
pathologist. The pathologist logs into the system, retrieves the lab test request,
performs the lab tests, and updates the lab results in the system. The doctor then
prescribes medication for the patient. The medicine shopkeeper logs into the system,
retrieves the patient's prescription, and dispenses the medication to the patient. The
patient returns for a follow-up visit, where the doctor retrieves the patient's medical
record, reviews their progress, and makes any necessary updates to the record. The
patient is eventually discharged from the hospital, at which point their medical
record is marked as closed in the system.
In addition to the above, the system also supports various administrative tasks such
as managing staff, managing inventory, and generating reports.
3.4.2 Use cases
3.4.4 Dynamic Model
3.4.4.1 Sequence Diagram
3.4.4.2 State Chart Diagram
3.4.4.3 Activity Diagram
3.4.5 Interfaces
3.4.5.1 User Interface
The user interface of the hospital management system will be designed to be userfriendly and intuitive. It will have different interfaces for different types of users, such as
doctors, nurses, administrators, and patients. The user interface will include features
such as easy navigation, drop-down menus, clickable icons, search functions, and
alerts for pending tasks. The user interface design will adhere to industry standards for
GUI and will be documented in a separate user interface specification.
3.4.5.2 Software Interface
The hospital management system will interface with several software components,
including databases, operating systems, tools, libraries, and integrated commercial
components. The following are the major software interfaces for the hospital
management system:
1. Database Interface: The system will interface with a database management system
such as MySQL to store and retrieve patient information, medical history, staff
information, inventory information, and billing information. The purpose of this interface
is to enable the system to perform efficient and effective data storage, retrieval, and
processing.
2. Operating System Interface: The hospital management system will interface with the
operating system of the host computer on which it is installed. The purpose of this
interface is to manage system resources, such as memory, CPU, and input/output
devices, to enable the system to perform its functions efficiently and effectively.
3. Messaging Interface: The system will interface with messaging protocols such as
Simple Mail Transfer Protocol (SMTP) and Short Message Service (SMS) to send
notifications and alerts to patients, doctors, and other staff members. The purpose of
this interface is to facilitate timely communication and information exchange among
stakeholders.
4. Electronic Medical Record Interface: The system will interface with Electronic Medical
Record (EMR) systems used by other healthcare providers, such as labs and
pharmacies, to enable seamless sharing of patient data across different healthcare
settings. The purpose of this interface is to ensure continuity of care and avoid
duplication of efforts.
5. Medical Devices Interface: The system will interface with medical devices such as blood
pressure monitors, heart rate monitors, and ECG machines, to capture patient vital
signs and other medical data. The purpose of this interface is to enable the system to
provide real-time monitoring and alerting of critical medical conditions.