SWE 304
PROJECT TITLE: NEAR EAST
HOSPITAL PATIENT AND
MANAGEMENT SCHEDULING
SYSTEM
ENIOLA ABIODUN ABDUL
20225895
INTRODUCTION
PURPOSE:
This document defines the software requirement for a web-based
Appointment and scheduling system for Near east Hospital. It is intended for
developers, Doctors, Patients, which are the end users, testers and the one
managing the project (Project managers) to understand the system’s
objectives and functionalities.
SCOPE:
This system will replace the recent system and the manual patient system
which is outdated . This system will:
Allow patients to register, book appointments, and make payments
Enable doctors and hospital staff to manage appointments and
view/update patient records
Improve accuracy, reduce service delays, and enhance patient
satisfaction.
INTENDED USER AND PURPOSE
USER PURPOSE
Developers They understand architecture and
implement it.
Project Managers They review scope, milestone and
progress
Testers They use requirements to create
test cases
Receptionist/Admins They register patients, manage
records and generate reports
Users (Patients & Doctors) Interact with system for
appointments and records
Systems Admins Maintain database, backups and
security
. Overall Description
Product Perspective
The system is a replacement for the current manual and unstable hospital
management system. It will serve as a standalone application connected to a
backend database (MySQL) and developed with PHP, HTML/CSS, and
LucidChart for modeling.
Product Features:
Patient registration and login
Appointment scheduling, rescheduling, and cancellation
Doctor availability tracking
Medical records management
Payment processing (cash, card, insurance)
Admin dashboard for hospital staff
Notifications for appointments and updates
Report generation for analysis
User Classes and Characteristics
Usage
User Class Functions Accessed Expertise
Frequency
Registration, appointments, Basic tech
Patients Occasionally
payments knowledge
View appointments, update
Doctors Frequently Moderate
patient info
Receptionists/ Register, schedule, manage
Daily Moderate
Admin records/payments
System Configuration, logs, backup,
Occasionally Advanced
Admins access control
Specific Requirements
Functional Requirements:
FR1: The system shall allow a patient to register and create an
account.
FR2: The system shall allow a patient to book, reschedule, or cancel an
appointment.
FR3: The system shall allow the receptionist to confirm appointments.
FR4: The system shall allow doctors to update their availability.
FR5: The system shall store and manage patient medical history.
FR6: The system shall support online payments.
FR7: The system shall notify patients and doctors about upcoming
appointments.
FR8: The system shall generate statistical reports for admins.
Non-Functional Requirements:
NFR1: System must support 100 concurrent users.
NFR2: Must be available 24/7.
NFR3: User data must be encrypted and stored securely.
NFR4: The interface must be user-friendly and responsive.
NFR5: Patient data must be 99% accurate with input validation.
Use Case Description (Example: Schedule Appointment)
Actors: Patient, Receptionist, Doctor
Main Flow:
1. Patient logs in
2. Patient selects desired doctor/date
3. System checks availability
4. Receptionist confirms and finalizes the schedule
5. Doctor receives notification
Data Flow Diagrams (DFD)
Level-0 DFD (Context Diagram)
External Entities: Patient, Doctor, Receptionist
Main Process: Hospital Management System
Data Stores: Patient Data, Appointment Records, Payments
Level-1 DFD
Processes:
1.0 Register Patient
2.0 Request Appointment
3.0 Verify Availability
4.0 Confirm Appointment
5.0 Notify Doctor
6.0 Generate Report
Data Stores:
D1: Patient Records
D2: Appointment Schedule
D3: Doctor Availability
D4: Notifications
D5: Reports
Data Dictionary
Data
Data Element Description
Type
Unique ID for each
Patient_ID Integer
patient
Patient_Name Full name String
Unique appointment
Appointment_ID Integer
number
Appointment_D Scheduled date and DateTim
ate time e
Doctor_ID Unique ID for doctor Integer
Doctor_Name Doctor’s full name String
Unique transaction
Payment_ID Integer
number
Payment_Amou
Amount paid Decimal
nt
Payment_Metho Cash, Card, or
String
d Insurance
Insurance_Provi Name of insurance
String
der company
Importance of SRS
An SRS is critical because:
It defines the system's purpose, features, and goals
It aligns developer and client expectations
It helps avoid miscommunication and costly rework
It serves as a guide for testing and design
Most Important Part of the SRS
The Functional Requirements section is most important because:
It defines what the system must do
It drives system design and development
If this part is not complete, the whole system will not meet the user’s
needs