Sre Assign 03

BAHRIA UNIVERSITY,
(Karachi Campus)
Department of Software Engineering
Assignment#03– Fall 2023
PROBLEM BASED LEARNING
COURSE TITLE: SRE COURSE CODE: SEN-211

Class: BSE 3A&B Shift: Morning
Course Instructor: ENGR. BUSHRA FAZAL KHAN Assignment Date: 18-Dec-2023
Max. Marks: 5 Points: CLO 2 Assignment Due: 27- Dec -2023
_____________________________________________________________________________
Question 1)
For the client based projects assigned in the class you created a Scope Vision Document in
assignment 2 and we conducted Usecase workshop.
Now based on the findings of that workshop create Usecase document by analyzing client
requirements and business process to create UML Usecase Model.
Also produce Usecase Narrative for each usecase along with activity diagrams for normal flow
and alternate flow of each usecase. Template is attached
AL-SHIFA HOSPITAL MANAGEMENT SYSTEM
Use Cases
for
<AL-SHIFA HOSPITAL
MANAGEMENT SYSTEM>
Version 1.0 approved
Prepared by <MUHAMMAD HASEEB
AFRASYAB
SOHAIB SALEEM>
<PNS SHIFA>
<27/12/2023>
MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM ii

Use Case ID and Name

Give each use case a unique numeric identifier. State a concise name for the use case that indicates the
value the use case would provide to some user. Begin with an action verb, followed by an object.
Author and Date Created

Enter the name of the person who initially wrote this use case and the date it was written.
Primary and Secondary Actors

An actor is a person or other entity external to the software system being specified who interacts with the
system and performs use cases to accomplish something of value. Different actors often correspond to
different user classes, or roles. Name the primary actor that will be initiating this use case and any other
secondary actors (humans or systems) that will participate in the use case’s execution.
Description
Provide a brief description of the reason for and outcome of this use case, or a high-level description of
the sequence of actions and the outcome of executing the use case.
Trigger
Identify the event or user action that initiates the use case. This trigger alerts the system to test the
preconditions so it can judge whether to proceed with execution.
Preconditions
List any activities that must take place, or any conditions that must be true, before the use case can be
started. The system must be able to test each precondition. Number each precondition. Example: PRE-1.
User’s identity has been authenticated.
Postconditions
Describe the state of the system at the successful conclusion of the use case execution. Label each
postcondition in the form POST-X, where X is a sequence number. Example: POST-1. Price of item in
the database has been updated with the new value.
Normal Flow
Provide a description of the user actions and corresponding system responses that will take place during
execution of the use case under normal, expected conditions. This dialogue sequence will lead to
accomplishing the goal stated in the use case name and description. Show a numbered list of actions
performed by the actor, alternating with responses provided by the system. The normal flow is numbered
“X.0”, where “X” is the Use Case ID.
Alternative Flows
Document other successful usage scenarios that can take place within this use case. State the alternative
flow, and describe any differences in the sequence of steps that take place. Number each alternative flow
in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence number for the alternative flow.
For example, “5.3” would indicate the third alternative flow for use case number 5. Indicate where each
alternative flow would branch off from the normal flow, and if pertinent, where it would rejoin the normal
flow.
MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 3

Exceptions
Describe any anticipated error conditions that could occur during execution of the use case and how the
system is to respond to those conditions. Number each alternative flow in the form “X.Y.EZ”, where “X”
is the Use Case ID, Y indicates the normal (0) or alternative (>0) flow during which this exception could
take place, “E” indicates an exception, and “Z” is a sequence number for the exceptions. For example
“5.0.E2” would indicate the second exception for the normal flow for use case number 5. Indicate where
in the normal (or an alternative) flow each exception could occur.
Priority
Indicate the relative priority of implementing the functionality required to allow this use case to be
executed. Use the same priority scheme as that used for other requirements.
Business Rules
List any business rules that influence this use case. Don’t include the business rule text here, just its
identifier so the reader can find it in another repository when needed.
Assumptions
List any assumptions that were made regarding this use case or how it might execute.
Other Information
Identify any additional pertinent requirements or constraints for the use case, such as quality attributes.
Describe what should happen if the use case execution fails for some unanticipated or systemic reason
(e.g., loss of network access, timeout). If the use case results in a durable state change in a database or the
outside world, state whether the change is rolled back, completed correctly, partially completed with a
known state, or left in an undetermined state as a result of the exception.

Use Case List
Primary Actor Use Cases

Patient: Registering as a new patient
Scheduling appointments
Viewing medical history
Updating personal information
Doctor: Viewing patient information
Updating patient records
Prescribing medications
Scheduling surgeries or procedures
Nurse: Recording patient vitals
Administering medications
Updating patient charts
Front Desk Receptionist: Patient check-in/check-out
Appointment scheduling
Handling inquiries
Billing and Insurance Managing patient billing information
Clerk: Processing insurance claims
Handling payment transactions
Laboratory Technician: Recording and analyzing test results
Updating patient records with lab data
Pharmacist: Dispensing medications
Managing pharmacy inventory
Providing medication information
Quality Assurance Conducting quality audits of medical services
Manager: Ensuring compliance with healthcare standards
Finance Manager: Managing hospital finances
Budgeting and financial planning
Inventory Manager: Managing medical supplies and equipment inventory
Reordering supplies as needed
Security Manager: Monitoring and controlling access to sensitive areas
Handling security incidents
Use Case Template
ID and Name: Registring a new Patient

Author: Date Created:
Primary Actor: Patient
Secondary Actors: Front Desk Receptionist, Database System
Description: This use case involves a new patient registering in the hospital system. The
outcome is the creation of a new patient record in the system.

Trigger: Patient decides to register at the hospital.

Preconditions: PRE-1. The patient is not already registered.
PRE-2. The patient has personal identification documents.
Postconditions: POST-1. A new patient record is created in the system.
Normal Flow: 1. Patient provides personal identification documents to the Front Desk
Receptionist.
2. Front Desk Receptionist enters patient information into the system.
3. System validates the information and generates a unique patient ID.
4. Front Desk Receptionist provides the patient with the generated patient ID.
Alternative Flows: None
Exceptions: If the provided identification documents are invalid, inform the Front Desk
Receptionist.
Priority: High
Business Rules: BR-1: Access to patient information is restricted to authorized medical personnel.
Assumptions: AS-1: The system is capable of handling concurrent access by multiple doctors.
Other Information: In case of a system failure during information retrieval, notify the doctor and
attempt to recover the data.
Activity Diagram

ID and Name: Viewing Patient Information

Primary Actor: Doctor
Secondary Actors: Front Desk Receptionist, Database System
Description: This use case involves a doctor accessing and viewing a patient's medical
information. The outcome is the doctor gaining insight into the patient's health
records.
Trigger: Doctor needs to review a patient's medical history.
Preconditions: PRE-1. The doctor is authenticated and has the necessary access privileges.
PRE-2: The patient has an existing medical record in the system.
Postconditions: POST-1: The doctor successfully views the patient's medical information.
Normal Flow: 1. Doctor logs into the system.
2. Doctor enters the patient's unique identifier.
3. System retrieves and displays the patient's medical information.
Exceptions: 1.0.E1: If the doctor is not authenticated, deny access to patient information.
Priority: High
Business Rules: BR-1: Access to patient information is restricted to authorized medical personnel.
Assumptions: AS-1: The system is capable of handling concurrent access by multiple doctors.
Other Information: In case of a system failure during information retrieval, notify the doctor and
attempt to recover the data.
Activity Diagram:

ID and Name: Updating Patient Records

Primary Actor: Nurse
Secondary Actors: Database System
Description: This use case involves a nurse updating a patient's records with recent
information, such as vital signs or administered medications.
Trigger: Nurse administers care to a patient.
Preconditions: PRE-1. The nurse is authenticated and has the necessary access privileges..
Postconditions: POST-1: The patient's records are successfully updated with the new information.
Normal Flow: 1. Nurse logs into the system.
2. Nurse selects the patient's unique identifier.
3. System displays the patient's current records.
4. Nurse updates the records with the new information.
Exceptions: 2.0.E1: If the nurse is not authenticated, deny access to patient records.
Priority: High
Business Rules: BR-2: Only authorized medical personnel can update patient records.
Assumptions: AS-2: The system maintains an audit trail of all changes made to patient records.
Other Information: In case of a system failure during the update process, attempt to roll back changes
and notify the nurse.
Activity Diagram:

ID and Name: Prescribing Medications

Secondary Actors: Pharmacy System
Description: This use case involves a doctor prescribing medications to a patient. The outcome
is the generation of a prescription that can be fulfilled by the pharmacy.
Trigger: Doctor decides to prescribe medications to a patient.
Preconditions: PRE-1: The doctor is authenticated and has the necessary access privileges.
Postconditions: POST-1: A prescription is generated and added to the patient's records.
2. Doctor selects the patient's unique identifier.
3. System displays the patient's current medications and medical history.
4. Doctor adds a new prescription to the patient's records.
Exceptions: 4.0.E1: If the doctor is not authenticated, deny the prescription request.
Priority: High
Business Rules: BR-4: Only authorized doctors can prescribe medications.
Assumptions: AS-4: The pharmacy system is integrated for prescription fulfillment.
Other Information: In case of a system failure during prescription generation, attempt to recover the
data and notify the doctor.
Activity Diagram:

ID and Name: Scheduling Surgeries or Procedures

Secondary Actors: Operating Room Scheduler, Database System
Description: This use case involves a doctor scheduling a surgery or medical procedure for a
patient. The outcome is the creation of a schedule and notification to relevant
personnel.
Trigger: Doctor decides to schedule a surgery or procedure for a patient.
Preconditions: PRE-1: The doctor is authenticated and has the necessary access privileges.
Postconditions: POST-1: The surgery or procedure is successfully scheduled, and relevant
personnel are notified.
2. Doctor selects the patient's unique identifier.
3. System displays the patient's current medical information.
4. Doctor schedules the surgery or procedure, specifying date and time.
Exceptions: If the doctor is not authenticated, deny the scheduling request.
Priority: High
Business Rules: BR-5: Only authorized doctors can schedule surgeries or procedures.
Assumptions: AS-5: The Operating Room Scheduler is integrated for real-time scheduling
updates.
Other Information: In case of a system failure during scheduling, attempt to notify relevant personnel
and reschedule the surgery or procedure.
Activity Diagram:

ID and Name: Patient Check-In/Check-Out

Primary Actor: Front Desk Receptionist
Description: This use case involves a front desk receptionist facilitating the check-in and
check-out process for patients. The outcome is the successful registration or
departure of a patient from the hospital.
Trigger: Patient arrives for an appointment or is ready to leave the hospital.
Preconditions: PRE-1: The front desk receptionist is authenticated and has the necessary access
privileges.
PRE-2: The patient has a scheduled appointment or has completed treatment.
Postconditions: POST-1: The patient's status is updated to "checked-in" or "checked-out" in the
system.
Normal Flow: 1. Front desk receptionist logs into the system.
2. Patient provides necessary identification.
3. Front desk receptionist confirms appointment details or treatment
completion.
4. System updates the patient's status to "checked-in" or "checked-out."
Exceptions: 8.0.E1: If the front desk receptionist is not authenticated, deny access to check-
in/check-out functions.
Priority: High
Business Rules: BR-8: Check-in and check-out can only be performed by authorized front desk
personnel.
Assumptions: AS-8: The system is integrated with the appointment scheduling module.
Other Information: In case of a system failure during check-in/check-out, the process should be rolled
back, and the patient should be informed to repeat the check-in/check-out.
Activity Diagram:

ID and Name: Appointment Scheduling

Primary Actor: Front Desk Receptionist
Description: This use case involves a front desk receptionist scheduling appointments for
patients. The outcome is the successful creation of an appointment in the system.
Trigger: Patient requests a new appointment or needs to reschedule an existing one.
Preconditions: PRE-1: The front desk receptionist is authenticated and has the necessary access
privileges.
PRE-2: The patient has an existing record in the system.
Postconditions: POST-1: The appointment is successfully scheduled in the system.
Normal Flow: 1. Front desk receptionist logs into the system.
2. Patient provides details for a new appointment or requests a reschedule.
3. Front desk receptionist checks for available slots.
4. System schedules the appointment and updates the patient's records
Exceptions: 9.0.E1: If the front desk receptionist is not authenticated, deny access to
appointment scheduling.
Priority: High
Business Rules: BR-9: Appointment scheduling is subject to the availability of time slots.
Assumptions: AS-9: The system provides real-time updates on available appointment slots.
Other Information: In case of a system failure during appointment scheduling, attempt to notify the
patient and reschedule the appointment.
Activity Diagram:

ID and Name: Recording and Analyzing Test Results

Primary Actor: Lab Technician
Secondary Actors: Database System, Quality Assurance Manager
Description: This use case involves a lab technician recording and analyzing test results for a
patient. The outcome is the generation of test reports and data analysis for further
review.
Trigger: Lab technician receives patient samples for testing.
Preconditions: PRE-1: The lab technician is authenticated and has the necessary access
privileges.
PRE-2: The patient samples are correctly labeled and prepared for testing.
Postconditions: POST-1: Test results are recorded in the system, and reports are generated.
POST-2: Quality Assurance Manager reviews and approves the test results.
Normal Flow: 1. Lab technician logs into the system.
2. Lab technician scans or manually enters sample information.
3. Lab technician conducts tests and records results in the system.
4. System generates test reports.
5. Quality Assurance Manager reviews and approves the test results.
Exceptions: 11.0.E1: If the lab technician is not authenticated, deny access to recording and
analyzing test results.
11.0.E2: If the sample information is incorrect or incomplete, the lab technician
flags the issue for correction.
Priority: High
Business Rules: BR-11: Test results must undergo quality assurance review before being finalized.
Assumptions: AS-11: The system supports various types of tests and corresponding data
formats.
Other Information: In case of a system failure during result recording, the lab technician should have
a process to document results manually for later entry.

Activity Diagram:
ID and Name: Managing Pharmacy Inventory

Primary Actor: Pharmacy Manager
Secondary Actors: Inventory Management System
Description: This use case involves the Pharmacy Manager managing the inventory of
pharmaceuticals in the hospital pharmacy. The outcome is the effective tracking,
updating, and restocking of pharmacy inventory.
Trigger: Low stock levels or receipt of new pharmaceutical supplies.
Preconditions: PRE-1: The Pharmacy Manager is authenticated and has the necessary access
privileges.
PRE-2: The Inventory Management System is operational.
Postconditions: POST-1: Pharmacy inventory is updated with new stock levels.
POST-2: Notifications are sent for low stock levels or expired medications.
Normal Flow: 1. Pharmacy Manager logs into the system.
2. System displays the current inventory status.
3. Pharmacy Manager reviews low stock levels or expired medications.
4. Pharmacy Manager updates the inventory by adding new stock or
removing expired items.
5. System generates notifications for low stock levels or expired
medications.
Alternative Flows: 13.0.1: If the Inventory Management System is temporarily unavailable, the
Pharmacy Manager manually tracks inventory changes until the system is back
online.
Exceptions: 13.0.E1: If the Pharmacy Manager is not authenticated, deny access to managing
pharmacy inventory.

13.0.E2: If the system fails to generate notifications, the Pharmacy Manager

manually reviews inventory regularly.
Priority: High
Business Rules: BR-13: Inventory updates must be reflected in real-time to ensure accurate
tracking.
Assumptions: AS-13: The Inventory Management System is integrated with the pharmacy
system.
Other Information: In case of a system failure during inventory updates, the Pharmacy Manager
should document changes manually and synchronize with the system once
it is operational.
Activity Diagram:
ID and Name: Ensuring Compliance with Healthcare Standards

Primary Actor: Compliance Officer
Secondary Actors: Regulatory Compliance System, Healthcare Staff
Description: This use case involves the Compliance Officer ensuring that the healthcare
practices within the hospital comply with relevant healthcare standards and
regulations. The outcome is the identification, assessment, and resolution of
compliance issues.
Trigger: Periodic compliance audits or receipt of updates to healthcare standards.
Preconditions: PRE-1: The Compliance Officer is authenticated and has the necessary access
privileges.

PRE-2: The Regulatory Compliance System is up-to-date.

Postconditions: POST-1: Identified compliance issues are addressed and resolved.
POST-2: Reports on compliance status are generated for documentation.
Normal Flow: 1. Compliance Officer logs into the system.
2. System displays the latest healthcare standards and regulations.
3. Compliance Officer conducts audits to assess compliance with standards.
4. Compliance Officer identifies and records any non-compliance issues.
5. System generates reports on compliance status.
Alternative Flows: 14.0.1: If the Regulatory Compliance System is temporarily unavailable, the
Compliance Officer manually conducts audits and documents findings until the
system is back online.
Exceptions: 14.0.E1: If the Compliance Officer is not authenticated, deny access to ensuring
compliance with healthcare standards.
14.0.E2: If the system fails to generate compliance reports, the Compliance
Officer manually documents compliance status.
Priority: High
Business Rules: BR-14: Compliance audits must be conducted regularly to ensure ongoing
adherence to healthcare standards.
Assumptions: AS-14: The Regulatory Compliance System is regularly updated to reflect the
latest healthcare standards.
Other Information: In case of a system failure during compliance audits, the Compliance Officer
should document findings manually and synchronize with the system once
it is operational.
Activity Diagram:

ID and Name: Managing Hospital Finances

Primary Actor: Finance Manager
Secondary Actors: Accounting System, Department Heads
Description: This use case involves the Finance Manager managing the financial aspects of the
hospital, including budgeting, expenditure tracking, and financial reporting. The
outcome is the effective financial management to ensure the hospital's fiscal
health.
Trigger: Start of a fiscal period, receipt of financial reports, or budgeting cycles.
Preconditions: PRE-1: The Finance Manager is authenticated and has the necessary access
privileges.
PRE-2: The Accounting System is operational.
Postconditions: POST-1: Budgets are updated, and financial reports are generated.
POST-2: Department Heads are notified of budgetary allocations and spending
limits.
Normal Flow: 1. Finance Manager logs into the system.
2. System displays financial data, including income, expenditures, and
budgetary information.
3. Finance Manager reviews budgetary allocations and adjusts as needed.
4. Finance Manager tracks expenditures and ensures compliance with
budgetary limits.
5. System generates financial reports for the current fiscal period.
Alternative Flows: 15.0.1: If the Accounting System is temporarily unavailable, the Finance Manager
manually tracks financial data until the system is back online.
Exceptions: 15.0.E1: If the Finance Manager is not authenticated, deny access to managing
hospital finances.
15.0.E2: If the system fails to generate financial reports, the Finance Manager
manually compiles financial data for reporting.
Priority: High
Business Rules: BR-15: Budgetary adjustments must be based on accurate and up-to-date financial
data.
Assumptions: AS-15: The Accounting System is integrated with other hospital management
systems for seamless financial data flow.
Other Information: In case of a system failure during financial management, the Finance Manager
should document financial activities manually and synchronize with the system
once it is operational.

Activity Diagram:
ID and Name: Managing Medical Supplies and Equipment Inventory

Primary Actor: Inventory Manager
Secondary Actors: Supply Chain System, Department Heads
Description: This use case involves the Inventory Manager managing the inventory of medical
supplies and equipment within the hospital. The outcome is the efficient tracking,
ordering, and restocking of medical supplies and equipment.
Trigger: Low stock levels, receipt of new supplies, or periodic inventory checks.
Preconditions: PRE-1: The Inventory Manager is authenticated and has the necessary access
privileges.
PRE-2: The Supply Chain System is operational.
Postconditions: POST-1: Medical supplies and equipment inventory is updated with new stock
levels.
POST-2: Department Heads are notified of low stock levels or the arrival of new
supplies.
Normal Flow: 1. Inventory Manager logs into the system.

2. System displays the current inventory status for medical supplies and
equipment.
3. Inventory Manager reviews low stock levels or upcoming expiration
dates.
4. Inventory Manager places orders for new supplies or restocks existing
inventory.
5. System generates notifications for low stock levels or the arrival of new
supplies.
Alternative Flows: 16.0.1: If the Supply Chain System is temporarily unavailable, the Inventory
Manager manually tracks inventory changes until the system is back online.
Exceptions: 16.0.E1: If the Inventory Manager is not authenticated, deny access to managing
medical supplies and equipment inventory.
16.0.E2: If the system fails to generate notifications, the Inventory Manager
manually communicates updates to Department Heads.
Priority: High
Business Rules: BR-16: Inventory updates must be reflected in real-time to ensure accurate
tracking.
Assumptions: AS-16: The Supply Chain System is integrated with the hospital's inventory
management system.
Other Information: In case of a system failure during inventory updates, the Inventory Manager
should document changes manually and synchronize with the system once
it is operational.
Activity Diagram:

ID and Name: Monitoring and Controlling Access to Sensitive Areas

Primary Actor: Security Manager
Secondary Actors: Access Control System, Security Personnel

Description: This use case involves the Security Manager monitoring and controlling access to
sensitive areas within the hospital premises. The outcome is the prevention of
unauthorized access and the enforcement of security protocols.
Trigger: Attempted access to sensitive areas, change in personnel access permissions, or
security incidents.
Preconditions: PRE-1: The Security Manager is authenticated and has the necessary access
privileges.
PRE-2: The Access Control System is operational.
Postconditions: POST-1: Unauthorized access attempts are prevented, and security incidents are
logged.
POST-2: Access permissions are updated based on security protocols and
personnel changes.
Normal Flow: 1. Security Manager logs into the system.
2. Access Control System displays real-time access logs and current access
permissions.
3. Security Manager reviews access logs for sensitive areas.
4. Security Manager updates access permissions for personnel as needed.
5. Access Control System enforces access restrictions based on security
protocols.
Alternative Flows: 17.0.1: If the Access Control System is temporarily unavailable, security
personnel manually monitor sensitive areas until the system is back online.
Exceptions: 17.0.E1: If the Security Manager is not authenticated, deny access to monitoring
and controlling access to sensitive areas.
17.0.E2: If the system fails to log access attempts, the Security Manager manually
records incidents and updates access permissions.
Priority: High
Business Rules: BR-17: Access permissions must be regularly reviewed and updated based on
security protocols.
Assumptions: AS-17: Security personnel are trained to respond to security incidents manually if
the system is unavailable.
Other Information: In case of a system failure during access monitoring, security personnel should be
informed to heighten manual security measures until the system is operational.

Activity Diagram:

Sre Assign 03

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sre Assign 03

Uploaded by

Copyright:

Available Formats

BAHRIA UNIVERSITY,

COURSE TITLE: SRE COURSE CODE: SEN-211

Prepared by <MUHAMMAD HASEEB

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM ii

Use Case ID and Name

Author and Date Created

Primary and Secondary Actors

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 3

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 4

Use Case List

Primary Actor Use Cases

Use Case Template

ID and Name: Registring a new Patient

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 5

Trigger: Patient decides to register at the hospital.

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 6

ID and Name: Viewing Patient Information

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 7

ID and Name: Updating Patient Records

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 8

ID and Name: Prescribing Medications

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 9

ID and Name: Scheduling Surgeries or Procedures

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 10

ID and Name: Patient Check-In/Check-Out

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 11

ID and Name: Appointment Scheduling

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 12

ID and Name: Recording and Analyzing Test Results

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 13

ID and Name: Managing Pharmacy Inventory

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 14

13.0.E2: If the system fails to generate notifications, the Pharmacy Manager

ID and Name: Ensuring Compliance with Healthcare Standards

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 15

PRE-2: The Regulatory Compliance System is up-to-date.

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 16

ID and Name: Managing Hospital Finances

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 17

ID and Name: Managing Medical Supplies and Equipment Inventory

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 18

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 19

ID and Name: Monitoring and Controlling Access to Sensitive Areas

Secondary Actors: Access Control System, Security Personnel

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 20

MUHAMMAD HASEEB, AFRSYAB, SOHAIB SALEEM 21

You might also like