Experiment - 1

Problem Statement for Hospital Management System.

Objective:
Design and implement a Hospital Management System (HMS) that efficiently manages hospital operations,
including patient and doctor management, appointment scheduling, and billing.

Requirements:
1. Patient Management:

o Add new patients to the system with details such as name, age, gender, contact information,
and medical history.

o Update patient details.

o View a list of all patients.
o Search for a patient by name or ID.
o Delete a patient record from the system.
2. Doctor Management:

o Add new doctors with details like name, specialization, experience, and contact information.
o Update doctor details.
o View a list of all doctors.
o Search for a doctor by name or specialization.
o Delete a doctor record from the system.
3. Appointment Scheduling:

o Schedule appointments for patients with doctors, specifying the date, time, and reason for the
visit.

o Update appointment details.

o View a list of all appointments.
o Search for appointments by patient name, doctor name, or date.
o Cancel an appointment.
4. Billing System:

o Generate bills for patients based on services rendered, including consultation fees, medical
tests, and treatments.

o View and update billing information.

o Print bills or save them to a file.
5. Reports:

o List of all patients treated by a specific doctor.

o Daily/weekly/monthly appointment schedules.

o Financial reports summarizing billing information.

6. User Authentication:

o Implement basic user authentication to ensure that only authorized personnel can access
certain features of the system.

o User roles such as Admin, Doctor, and Receptionist should have different access levels.
7. Data Persistence:

o Store data (patients, doctors, appointments, billing) in files or a database so that it is preserved
between sessions.

o Load data from files or a database when the system starts.

8. Error Handling:

o Ensure that the system gracefully handles errors, such as invalid input or failed database
connections.

9. User Interface:

o Create a simple command-line interface (CLI) for interacting with the system.
o Ensure that the system is user-friendly and provides clear instructions.

Other Features :
● Integration with external systems for lab results or pharmacy management.

● Graphical User Interface (GUI) instead of CLI.

● SMS or email notifications for appointment reminders.

Deliverables:
● Source code of the C++ program.

● A brief documentation explaining how to set up and run the system.

● A sample data file for testing the system.

Experiment - 2

Objective: To create Initial Requirements Document (IRD) for a Hospital Management

System

Title of the project Hospital Management System

Stakeholders involved in capturing Doctors, Nurses, Hospital Administrators, Patients, IT Staff

requirements

Techniques used for requirement Interviews, Surveys, Workshops, Document Analysis

capturing (existing systems)

Name of the persons along with Dr. Ruchika Malhotra (Head of Department, SE, DTU)
designations
Nitin bansal(23/SE/107)

Mandeep(23/SE/93)

Date Feb 2025

Version 1.0
Consolidated list of initial requirements:
1. The system shall manage patient demographics (name, address, DOB, etc.).
2. The system shall track patient medical history (allergies, past illnesses, etc.).
3. The system shall manage patient appointments and scheduling.
4. The system shall generate unique patient identifiers.
5. The system shall allow patients to book appointments online or via phone.
6. The system shall send appointment reminders to patients.
7. The system shall allow staff to manage doctor schedules and availability.
8. The system shall manage doctor profiles (specialization, qualifications, etc.).
9. The system shall manage staff roles and permissions.
10. The system shall store patient medical records securely and confidentially.
11. The system shall allow authorized personnel to access and update medical records.
12. The system shall support electronic signatures for medical documents.
13. The system shall generate invoices for services rendered.
14. The system shall process payments (cash, card, insurance).
15. The system shall generate financial reports.
16. The system shall track medical supplies and equipment inventory.
17. The system shall generate alerts for low stock levels.
18. The system shall manage purchase orders and vendor information.
19. The system shall generate reports on patient demographics, treatments, and outcomes.
20. The system shall provide analytics on hospital performance metrics.
21. The system shall ensure data security and patient privacy.
22. The system shall implement role-based access control.
23. The system shall comply with relevant healthcare regulations (e.g., HIPAA).
24. The system shall integrate with laboratory information systems (LIS).
25. The system shall integrate with radiology information systems (RIS).
26. The system shall have a user-friendly interface.
27. The system shall be accessible on different devices (desktops, tablets).
28. The system shall allow administrators to manage users, permissions, and system settings.
29. The system shall provide audit trails for system activity.
Experiment - 3

Objective:
To create a detailed Use Case Diagram on the Hospital Management System.
Experiment – 4
Objective:
To create detailed Use Case Descriptions on the Hospital Management System.

Theory:
Actors in a Use Case Description represent external entities interacting with the system. Each
actor performs specific actions, known as use cases, based on their role within the system. In
a Hospital Management System, the main actors—Patient, Doctor, and Admin—each have
different functionalities they interact with. The use case descriptions for actors provide a
breakdown of the processes they engage with and help clarify their roles.

Procedure:
1. Identification of Actors:
○ Patient: Requests services like scheduling appointments, paying bills, and
viewing records.
○ Doctor: Manages patient medical records, issues prescriptions, and handles
schedules.
○ Admin: Manages hospital staff, generates reports, and overseas operations.
2. List of Use Cases for Each Actor:
○ For Patient: Request Appointment, View/Pay Bill, View Medical Records.
○ For Doctor: Access Patient Medical Records, Issue Prescription, Manage
Schedule.
○ For Admin: Manage Hospital Staff, Generate Reports, Manage Schedules.
3. Writing Actor-Centric Use Case Descriptions:
○ For each actor, define the use cases they interact with, focusing on the steps
they follow and the system's responses.

Actor Use Case Descriptions:

Actor: Patient
Use Case 1: Request Appointment

● Preconditions:
○ The patient must be registered in the system.
○ The system must have available appointment slots.
● Postconditions:
○ The appointment is scheduled, and the patient receives a confirmation.
● Main Flow:

1. The patient logs into the system.

2. The patient selects "Request Appointment."

3. The system displays available doctors and time slots.

4. The patient chooses a time and doctor.

5. The system confirms the appointment and sends a notification.

Use Case 2: View/Pay Bill

● Preconditions:
○ The patient must have an outstanding bill in the system.
○ The patient must be logged in.
● Postconditions:
○ The bill is paid, and the patient receives a receipt.
● Main Flow:

1. The patient navigates to the "Billing" section.

2. The system shows any pending bills.

3. The patient selects a bill and proceeds to payment.

4. The system processes the payment and provides confirmation.

Use Case 3: View Medical Records

● Preconditions:
○ The patient must be registered in the system.
○ The patient must have medical records stored in the system.
● Postconditions:
○ The patient successfully views their medical records.
● Main Flow:

1. The patient logs into the system.

2. The patient navigates to "Medical Records."

3. The system retrieves and displays the patient's medical history.

Actor: Doctor
Use Case 1: Access Patient Medical Records

● Preconditions:
○ The doctor must be logged into the system and have access to patient data.
● Postconditions:
○ The doctor successfully views or updates the patient's records.
● Main Flow:

1. The doctor logs in and selects a patient from the system.

2. The system displays the patient's medical records.

3. The doctor reviews or updates the records.

Use Case 2: Issue Prescription

● Preconditions:
○ The doctor must have access to the patient's medical history.
○ The doctor must be authorized to issue prescriptions.
● Postconditions:
○ The prescription is sent to the pharmacy and logged in the patient’s records.
● Main Flow:

1. The doctor selects a patient's record.

2. The doctor enters the prescription details.

3. The system sends the prescription to the pharmacy and provides confirmation.

Use Case 3: Manage Schedule

● Preconditions:
○ The doctor must be logged into the system.
● Postconditions:
○ The schedule is updated, reflecting new appointments.
● Main Flow:

1. The doctor logs into the scheduling system.

2. The system shows the doctor’s current schedule.

3. The doctor makes any necessary changes to appointments.

4. The system updates the schedule.

Actor: Admin
Use Case 1: Manage Hospital Staff

● Preconditions:
○ The admin must have access to staff management tools.
● Postconditions:
○ The staff details are updated in the system.
● Main Flow:

1. The admin logs into the system and accesses the "Staff Management" section.

2. The system shows a list of hospital staff.

3. The admin adds, updates, or removes staff details.

4. The system saves the changes.

Use Case 2: Generate Reports

● Preconditions:
○ The admin must be logged into the system and have access to report
generation.
● Postconditions:
○ The requested report is generated and available for review.
● Main Flow:

1. The admin logs into the system and navigates to "Reports."

2. The system prompts the admin to select the report type (e.g., financial, staff).

3. The system generates the report and makes it available for download or printing.

Use Case 3: Manage Schedule

● Preconditions:
○ The admin must have the necessary privileges to manage schedules.
● Postconditions:
○ Hospital staff schedules are updated.
● Main Flow:

1. The admin accesses the "Scheduling" section.

2. The system displays the current schedule for staff.

3. The admin adds or modifies appointments for staff members.

4. The system updates the schedules and provides confirmation.

Conclusion:
The Use Case Descriptions for actors in the Hospital Management System provide clear
insights into how Patients, Doctors, and Admins interact with the system. Each actor
performs specific actions that contribute to the system’s functionality, including appointment
scheduling, medical record access, and administrative management. Understanding these
interactions helps define system requirements and user behaviour.
SOFTWARE REQUIREMENT
SPECIFICATION

Version 1.0

Feb 10, 2024

HOSPITAL MANAGEMENT SYSTEM

Nitin bansal(23/SE/107)
Mandeep(23/SE/93)

BTech

In
Software Engineering

4th Semester
Software Requirements Specification (SRS)
1. Introduction

1.1 Purpose

The purpose of this SRS document is to define the requirements for the development of a Hospital
Management System (HMS). This system is intended to manage hospital operations including
patient registration, doctor scheduling, appointment management, billing, medical records, and
reporting.

1.2 Scope

The HMS will streamline and automate core hospital functions, including:

• Patient and doctor management

• Appointment scheduling

• Billing and financial reporting

• Medical record maintenance

• User authentication and role-based access

The system will support interfaces for Admin, Doctor, Receptionist, and Patient roles. The initial
version will be CLI-based, with a possibility of future GUI upgrades.

1.3 Definitions, Acronyms, and Abbreviations

• HMS – Hospital Management System

• CLI – Command Line Interface

• GUI – Graphical User Interface

• ID – Identifier

1.4 References

• IEEE Std 830-1998: Recommended Practice for Software Requirements Specifications

• Hospital Management System Use Case Diagram

• Internal Interviews and Surveys with hospital staff

1.5 Overview

This document is organized into functional and non-functional requirements, system descriptions,
constraints, and detailed specifications based on the IEEE 830 standard.
2. Overall Description

2.1 Product Perspective

HMS is a standalone system intended to replace manual hospital operations with automated
software functions.

2.1.1 System Interfaces

• External systems (e.g., Lab Information System, Pharmacy, Radiology) to be integrated in

future versions.

2.1.2 User Interfaces

• CLI interface (Phase 1)

• GUI planned for future version

• Clear menus and navigation prompts for different user roles

2.1.3 Hardware Interfaces

• Runs on standard desktops or servers

2.1.4 Software Interfaces

• File-based storage / Optional DB (SQLite/MySQL)

• OS compatibility: Windows, Linux

2.1.5 Communications Interfaces

• Future integration with APIs for notifications

2.1.6 Memory Constraints

• Minimal (CLI-based)

• Configurable storage for database/files

2.1.7 Operations

• CRUD operations for patients, doctors, appointments, and bills

2.1.8 Site Adaptation Requirements

• Customizable fields for hospitals with different specializations

2.2 Product Functions

• Add, update, delete, and search patient and doctor records

• Schedule and manage appointments

• Generate and update billing

• View reports and analytics

• Role-based access for users

2.3 User Characteristics

• Admin: Technical staff managing the system

• Doctor: Medical personnel accessing and updating records

• Receptionist: Manages appointments and patient entries

• Patient: Limited access (e.g., request appointment, view bill)

2.4 Constraints

• Only authorized users can access specific functions

• Must comply with patient data privacy standards

2.5 Assumptions and Dependencies

• Users are trained to operate CLI

• System is hosted on secure infrastructure

• Data is backed up periodically

2.6 Apportioning of Requirements

• Integration with external lab systems and SMS/email notifications to be implemented in

later versions

3. Specific Requirements

3.1 External Interfaces

• Optional: External lab or pharmacy systems (future version)

3.2 Functions

• Patient Management

• Doctor Management
• Appointment Scheduling

• Billing System

• Reporting

• Authentication

3.3 Performance Requirements

• CLI should respond within 1 second to user commands

• Can handle 1000+ patient records with minimal lag

3.4 Logical Database Requirements

• Patient: ID, Name, DOB, Gender, History, Contact

• Doctor: ID, Name, Specialization, Contact, Schedule

• Appointment: Patient ID, Doctor ID, Date, Time, Reason

• Billing: Services, Costs, Payment status

3.5 Design Constraints

3.5.1 Standards Compliance

• Follow local healthcare data protection guidelines

• Modular architecture for ease of maintenance

3.6 Software System Attributes

3.6.1 Reliability

• System must not crash during data entry or save operations

3.6.2 Availability

• Available during hospital working hours

3.6.3 Security

• Password-protected roles

• No unauthorized access to sensitive records

3.6.4 Maintainability

• Modular structure for easy updates and patches

3.6.5 Portability

• Compatible with Windows and Linux environments

3.7 Organizing the Specific Requirements

3.7.1 System Mode

• Admin Mode

• Doctor Mode

• Receptionist Mode

• Patient Mode

3.7.2 User Class

• Admin: Full access

• Doctor: View/edit medical records, prescriptions

• Receptionist: View schedules, manage appointments

• Patient: Limited access

3.7.3 Objects

• Patient

• Doctor

• Appointment

• Bill

• Report

3.7.4 Feature

• CRUD for entities

• Search and filters

• Report generation

3.7.5 Stimulus

• User commands via CLI

3.7.6 Response
• Appropriate success/failure messages and action results

3.7.7 Functional Hierarchy

1. Login

2. Role-based Dashboard

3. Entity Management (Patients, Doctors, Appointments, Billing)

4. Reports

3.8 Additional Comments

• Future version may include barcode scanning, lab integration, and automated report
generation

4. Supporting Information

• Sample data files

• Setup guide

• User manual (CLI usage)

• Interview/survey documentation from stakeholders

Experiment - 6

Objective:
To create a detailed Class Diagram on the Hospital Management System.
Experiment - 7
Objective:
To create a detailed Sequence Diagram on the Hospital Management System.

1. System Login

Basic Flow: Successful Login

Alternate Flow: Failed Login

2. Patient Registration

Basic Flow: New Patient Registration

Alternate Flow: Duplicate Patient Record

3. Doctor Management

Basic Flow: Add New Doctor

Alternate Flow: Missing Credentials for Doctor
4. Patient Medical Records

Basic Flow: Create Medical Record

Alternate Flow: Update Existing Medical Record