OOSE Lab File E-5

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

+

EXPERIMENT – 5
AIM: Write use case description of your case study i.e. “Hospital Patient
Management System (HPMS)”.

USE CASES DESCRIPTION:

3.2.1 Login Use Case Description:

Introduction: This use case allows the user to access the system.
Actors:
Patient
Doctor
Admin

Precondition: The user must have their login id and password with them.
Postcondition: If the use case is successful, the user is granted access to the
system.

Event Flow:
Basic Flow
1. The user enters his/her login id and password.
2. The user’s login id and password are matched with the system’s database.
3. The user’s credentials match and he is granted access of the system.

Alternative Flow 1: Unauthorized employee


If the system does not validate the user’s login id or password (due to user not being in the system or
user entering wrong credentials), then an error message is flagged and the use case returns to the
beginning of the basic flow.
Alternative Flow 2: User exits
This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None
Associated use cases:
All other use cases are executable only after this login use case.
+

3.2.2 Doctor Available Use Case Description:

Introduction: This use case allows the user to check the doctor’s available.

Actors:
Patient

Precondition: The user must have their login id and password with them.

Postcondition: If the use case is successful, the user is given the information if the
Doctor is available.

Event Flow:
Basic Flow
The user gets the access to the list of available doctors available in the database.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:


Login
+

3.2.3 Available Appointments Use Case Description:

Introduction: This use case allows the user to access the list of available
appointments.

Actors:
Patient

Precondition: The user must be logged into the system before the use case begins.

Postcondition: If the use case is successful, a list of available appointments is


successfully displayed.

Event Flow:
Basic Flow
The user gets the access to the list of available appointments available in the database.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:


Login
+

3.2.4 Book Appointment Use Case Description:

Introduction: This use case allows the users to book and appointment for meeting
a doctor.

Actors:
Patient

Precondition: The user must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, details of appointment are


successfully entered into the system and maintained accordingly by the administrator.

Event Flow:
Basic Flow
The users enter the required details for booking an appointment which is to be maintained. Then
details of registration are updated in the database and maintained by the administrator.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
The details entered by the users should be in prescribed format (data handling).

Associated use cases:


Login
+

3.2.5 Manage Appointment Use Case Description:

Introduction: This use case allows the Patient and the Administrator to manage
appointments.

Actors:
Administrator

Patient

Precondition: The patient and the administrator must be logged onto the system before the use
case begins.
Postcondition: If the use case is successful, details of the appointment can be viewed and updated
by the Patient and the Administrator.

Event Flow:
Basic Flow
The patient/administrator enter their login details. Now they can update their appointment timings.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends without
registering into the application.

Special Requirements:
The details entered by the patient/administrator should be in prescribed format (data handling).

Associated use cases:


None
+

3.2.6 View Patient Records Use Case Description:

Introduction: This use case allows the admin to view all the user’s within the database

Actors:
Administrator

Precondition: The administrator must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, details of all the patients are
successfully viewed by the administrator.

Event Flow:
Basic Flow
The administrator logs into the system and views the records of all the patients.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:


None
+

3.2.7 View All Appointments Use Case Description:

Introduction: This use case allows the doctor and the administrator to view
all the appointments for a specific doctor.

Actors:
Administrator
Doctor

Precondition: The doctor and admin must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, details of appointments for a specific


doctor are viewed by the admin and the doctor.

Event Flow:
Basic Flow
The administrator/doctor enters the app and view their appointments.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:


Login
+

3.2.8 File Medical Reports Use Case Description:

Introduction: This use case allows the user to the doctor to file medical reports.

Actors:
Doctor

Precondition: The doctor must be logged onto the system before the use case begins.

Postcondition: If the use case is successful, a patient’s medical report


is saved in the system.

Event Flow:
Basic Flow
The administrator/data entry operator enters the required details of patient’s report which is to be
maintained.

Alternative Flow: User exits


This allows the user to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:


None
+

3.2.9 Update/Delete Records Use Case Description:

Introduction: This use case allows the doctor to update/delete patient records
Actors:
Doctor

Precondition: The doctor must have their login id and password with them.
Postcondition: If the use case is successful, the patient record is deleted.

Event Flow:
Basic Flow
1. The doctor enters his/her login id and password.
2. The doctor’s login id and password are matched with the system’s database.
3. The doctor’s credentials match and he is granted access of the system.
4. Now as the doctor clicks the delete button, the patient’s record is deleted
Alternative Flow 1: Unauthorized doctor
If the system does not validate the doctor’s login id or password (due to user not being in the system
or user entering wrong credentials), then an error message is flagged and the use case returns to the
beginning of the basic flow.
Alternative Flow 2: User exits
This allows the doctor to exit at any time during the use case. The use case ends.

Special Requirements:
None

Associated use cases:


None

You might also like