Scribd
Upload
5 views

SRS Document

The document outlines the software requirements for a web-based Appointment and Scheduling System for Near East Hospital, aimed at improving patient management and service efficiency. It details the system's functionalities, including patient registration, appointment management, and payment processing, while specifying user roles and their interactions. The document emphasizes the importance of functional requirements in guiding system design and ensuring user satisfaction.

Uploaded by

eniola.abdul69
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
5 views

SRS Document

The document outlines the software requirements for a web-based Appointment and Scheduling System for Near East Hospital, aimed at improving patient management and service efficiency. It details the system's functionalities, including patient registration, appointment management, and payment processing, while specifying user roles and their interactions. The document emphasizes the importance of functional requirements in guiding system design and ensuring user satisfaction.

Uploaded by

eniola.abdul69
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

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

You might also like