Final Year Design Project System Design Specification

Prescripto

Software Design Specification Document

By

Swera Kiran 056474

Taskeen Fatima 056433

Project Advisor: Prof. Imran Shafique

Faculty of Computing & Information Technology,

Govt. Graduate Islamia College, Gujranwala, Pakistan.
(2025)
 Prescripto

Executive Summary

The Online Doctor Appointment Project is a web-based application that enables patients to book doctor
appointments online. The system aims to simplify the appointment scheduling process, reduce wait times,
and improve overall patient experience.

Here's a summary of key points for Prescripto, an Online Doctor Appointment System:

Key Points

1. Objective: Simplify appointment scheduling, reduce wait times, and improve patient
experience.
2. Features: Patient registration, doctor search, appointment scheduling, reminders, and
notifications.
3. Benefits: Convenience, reduced wait times, improved patient experience, increased
efficiency, and enhanced accessibility.
4. Technologies: React, [Link], [Link], MongoDB, and other relevant
technologies.
5. Importance: Addresses the need for efficient appointment scheduling, improves
patient satisfaction, and streamlines healthcare services.
Table of Contents
1. Design Considerations......................................................................................................5
2. Requirements Traceability Matrix..................................................................................5
3. Design Models...................................................................................................................6
3.1 Architectural Design...............................................................................................11
3.2 Data Design..............................................................................................................16
3.2.1 Data Dictionary................................................................................................18
3.3 User Interface Design..............................................................................................23
3.3.1 Screen Images...................................................................................................24
3.3.2 Screen Objects and Actions.............................................................................25
Use Case 1: View Profile Information.................................................................................30
Screen Objects..................................................................................................................30
1.4. Behavioral Model.....................................................................................................31
4. Design Decisions.................................................................................................................33
5. Summary..........................................................................................................................34
References.................................................................................................................................1
List of Tables

Table 1 Requirement Traceability Matrix……………………………………………………7

Tables of Figures
Figure 1 Class Diagram 7
Figure 2 Sequence Diagram 9
Figure 3 State Transition Diagram 10
Figure 4 UML Class Relation Diagram 12
Figure 5 UML Component Diagram 13
Figure 6 Interaction Diagram 31
Figure 3 State Transition Diagram 32

4
System Design
Explain the product perspective in which software will operate including dependencies and
interaction with other system. List the design constraints (like performance requirements)
impacting design.

Product Perspective
The Online Doctor Appointment System is a web-based application that enables patients to book doctor
appointments online. The system operates in the healthcare industry, providing a platform for patients to
interact with doctors and healthcare providers.

Dependencies
1. User Authentication System: The system relies on an external user authentication system to
verify patient identities.
2. Payment Gateway: The system integrates with a payment gateway to process appointment
fees and payments.

Interactions with Other Systems

1. Patient Portal: The system integrates with the patient portal to provide patients with access to
their medical records, appointment schedules, and billing information.
2. Doctor Portal: The system interacts with the doctor portal to provide doctors with access to
their schedules, patient information, and appointment requests.
3. Hospital Information System : The system integrates to retrieve doctor schedules, patient
medical records, and other relevant information.

Design Constraints

1. Security Requirements: The system ensuring the confidentiality, integrity, and availability of
patient data.
2. Usability Requirements: The system should have an user interface, with clear navigation and
minimal cognitive load.
3. Scalability Requirements: The system should be able to scale horizontally, with the ability to
add or remove servers as needed to handle changes in traffic.

5
1. Design Considerations
Here are some Assumptions and Dependencies, Limitations, and Risks for the Online Doctor
Appointment System:

Assumptions
1. Availability: Doctors and healthcare providers have existing schedules and availability that can
be integrated into the system.
2. Doctor Availability: Doctors maintain their availability schedules accurately in the system.
3. Secure Authentication: User login and authentication mechanisms are secure.
4. System Maintenance: Regular updates and maintenance are assumed to ensure smooth
functioning.

Dependencies
1. Internet Connections: Reliable internet connectivity and server to ensure system availability.

2. Database: To store user, doctor, and appointment data.

3. Web Server/Backend: To handle login, booking, and doctor management.

4. Authentication: For secure login (e.g., email/password).

5. Notification System: To send appointment reminders (email or SMS).

Limitations
1. Technical Limitation: The system may not be compatible with older browsers or devices.
2. Functional Limitation: The system may not support advanced features like video
conferencing or real time chat.
3. Scalability Limitation: The system may experience performance issues with a large number
of users.

Risks
1. Security Risk: Patient data may be compromised due to security measures.
2. Technical Risk: System downtime or performance issues may occur due to technical failures.
3. Functional Risk: The system may not meet the needs of patients on healthcare providers.
4. Regulatory Risk: The system may not comply with relevant healthcare regulations.

2. Requirements Traceability Matrix

Shows how each design element traces back to a specific requirement in the Software
Requirements Specification (SRS), ensuring that all requirements are accounted for in the
design. Use table to document requirements traceability, where requirement ID is a unique
identifier assigned to the requirement, requirement description refers to brief description of
6
the requirement discussed. Design specification entails list of the
components/classes/algorithm where the requirement is addressed.

Table 1 Requirements Traceability Matrix

Requirement Requirement Description Design Specification

ID

R1 The system must allow patients to view

Component “Doctor
available doctors, their specialization
Schedule Management”
and schedule.

R2 Patients can be able to book, reschedule Component “Appointment

and cancel appointment. Management”

R3 The system should provide role based

Component “Access
access control for different user types
Control”
(Admin, doctor, patient).

R4 Admin manage system setting. Component “Admin Panel”

3. Design Models
Provide the descriptions of the following models used to describe the system design. Also
ensure visibility of all diagrams.

The applicable models for the project using object-oriented development approach may
include:

1. Class Diagram

7
 Figure 1 Class Diagram
Description:
This model represents the static structure of the system, including classes, attributes, and
relationships. For an online doctor appointment system, classes might include:
 User (Abstract Class):

8
 o The User class defines common properties and behaviors shared by all users
of the system, such as patients, doctors, and admins. It includes authentication
features like login and logout, and user profile management.
 Patient:
o They can book and cancel appointments, view prescriptions, and join a
waiting list if no slots are available.
 Doctor:
o The Doctor class includes attributes related to a medical professional, such as
specialization, and availability. Doctors can manage their schedule, view
upcoming appointments, and issue prescriptions.
 Admin:
o The Admin class represents the administrative users who oversee platform
operations. They can verify doctors, manage patients, generate system-wide
reports.
 Appointment:
o This class handles appointment data between a patient and a doctor. It
includes scheduling details, status, and links to the payment made for the
consultation.
 Payment:
o Handles payment information linked to an appointment. This includes the
amount, method, and status.
 Calendar:
o Represents each doctor’s availability schedule. It includes available time slots,
blocked dates, and functions to update availability.
 Update:
o Represents system-generated notifications such as appointment reminders,
prescription availability, or changes in schedules.

2. Interaction Diagram (Either sequence or collaboration)

9
 Figure 2 Sequence Diagram
Description:
A sequence diagram for online doctor appointment might show the steps involved in
scheduling an appointment, such as:

 Patient: They can book and cancel appointments, view prescriptions, and join a
waiting list if no slots are available and search for a doctor by specialization.
 Doctor: The Doctor attributes related to a medical professional, such as
specialization and availability. Doctors can manage their schedule, view upcoming
appointments, and issue prescriptions.
 Appointment: This can handles appointment data between a patient and a doctor. It
includes scheduling details, status, and links to the payment made for the
consultation.
 User: They can define common properties and behaviors shared by all users of the
system, such as patients, doctors, and admins. It includes authentication features like
login and logout, and user profile management.
3. State Transition Diagram (for the projects which include event handling and backend
processes)

10
 Figure 3 State Transition Diagram
Description:

Here is a detailed description of the state transition diagram for an online doctor appointment
system:

11
States:

1. Initial State: The system is idle, waiting for user interaction.

2. Searching for Doctor: The user is searching for a doctor.
3. Doctor Available: The system has found a doctor who is available.
4. Schedule: The user is scheduling an appointment with the doctor.
5. Confirmed: The appointment has been confirmed.
6. Rescheduled: The appointment has been rescheduled.
7. Cancelled: The appointment has been cancelled.
8. Completed: The appointment has been completed.
9. Payment Confirmed: The payment for the appointment has been confirmed.
10. Payment Failed: The payment for the appointment has failed.

Events:

1. Search Doctor: User searches for a doctor.

2. Select Doctor: User selects a doctor.
3. Schedule Appointment: User schedules an appointment.
4. Confirm Appointment: Appointment is confirmed.
5. Reschedule Appointment: User reschedules the appointment.
6. Cancel Appointment: User cancels the appointment.
7. Complete Appointment: Appointment is completed.
8. Make Payment: User makes a payment.
9. Payment Success: Payment is confirmed.
10. Payment Failure: Payment fails.

3.1 Architectural Design

Develop a component structure and explain the relationships between these components
to achieve the complete functionality of the system. This is a high-level overview of system’s
inter-modules collaboration to achieve the desired functionality.

Provide a diagram showing the major subsystems and their connections.

● UML Class relationship diagram

12
 Figure 4 UML Class Relation Diagram
Description:

The UML class relationship diagram illustrates the relationships between classes.

Class Relationships

 User is the parent class for Doctor, Patient, and Admin (Generalization/Inheritance).
 A Doctor can have multiple Appointments (One-To-Many).
 An Appointment is associated with one Doctor and one Patien.
 A Payment is associated with one Appointment.
 An Admin can manage multiple Users and Appointments (One-To-Many).

Multiplicity

 A Doctor can have 0..* (zero to many) Appointments.

 An Appointment is associated with 1 (one) Doctor and 1 (one) Patient.

13
  A Payment is associated with 1 (one) Appointment.

● UML Component diagram

Figure 5 UML Component Diagram

Description:

The UML component diagram illustrates the high-level architecture of the online doctor
appointment system, highlighting the interactions between various components.

Components

1. Frontend UI: The user interface component, responsible for user interactions,
displaying information, and sending requests to services.
2. Authentication Service: Handles user authentication, registration, and authorization.
3. Appointment Service: Manages appointment scheduling, cancellations, and updates.
4. Doctor Service: Handles doctor information, availability, and schedules.
5. Payment Service: Processes payments for appointments.
6. Admin Service: Provides administrative functionality, such as user management and
system monitoring.

14
 7. Notification: Sends notifications to users, doctors, and admins regarding
appointments, payments, and system updates.

Interfaces

Each component provides and consumes interfaces:

 Frontend UI: Consumes interfaces from services (e.g., Appointment Service, Doctor
Service) and provides interface for user interactions.
 Services: (Authentication, Appointment, Doctor, Payment, and Admin) provide
interfaces for other components to interact with them.
 Notification: Consumes interfaces from services to send notifications.

Interactions

Components interact with each other through well-defined interfaces:

 Frontend UI sends requests to Appointment Service to schedule or cancel

appointments.
 Appointment Service interacts with Doctor Service to retrieve doctor availability.
 Payment Service processes payments for appointments scheduled through
Appointment Service.
 Admin Service interacts with all services for administrative purposes.
 Notification sends notifications based on events triggered by services

● After finalizing architecture style/pattern diagram (MVC, Client-Server, Layered,

Multi-tiered) create a detailed mapping modules/components to each part of the architecture.

Here's a detailed mapping of the online doctor appointment system using the Multi-Tiered architecture
pattern:

Presentation Tier (Client-Side)

User Interface (UI) Component:

 Patient Registration Form

 Doctor Profile Page
 Appointment Scheduling Form
 Payment Gateway Integration

Client-Side Technologies:
 HTML/CSS for UI
 JavaScript for dynamic UI interactions
15
  ReactJS UI component management

Application Tier (Server-Side)

Business Logic Components:

 Patient Registration Service

 Doctor Profile Management Service
 Appointment Scheduling Service
 Payment Processing Service

Server-Side Technologies:

 [Link] for server-side runtime environment

 [Link] for server-side routing and middleware management
 MongoDB for MYSQL database management

Data Tier (Database)

Database Schema:

 Patients Collection
 Doctors Collection
 Appointments Collection
 Payments Collection

Database Technologies:

 MongoDB for MySQL database management

 Mongoose for MongoDB schema management and interaction

Mapping of Components and Technologies

Component and Technology

 Patient Registration Form: HTML/CSS, JavaScript, ReactJS

 Doctor Profile Page: HTML/CSS, JavaScript, ReactJS
 Appointment Scheduling Form: HTML/CSS, JavaScript, ReactJS
 Payment Gateway Integration: JavaScript, [Link], [Link]
 Patient Registration Service: [Link], [Link], MongoDB
 Doctor Profile Management Service: [Link], [Link], MongoDB
 Appointment Scheduling Service: [Link], [Link], MongoDB

16
3.2 Data Design

Here’s an explanation of how the information domain of the online doctor appointment system is
transformed into data structures:

Information Domain Transformation

The information domain of the system consists of patients, doctors appointment, payments, and
notifications. These entities are transformed into data structures as follows:

 Patient
o Patient ID (unique identifier
o Name
o Email
o Password
o Contact information
o Medical history
 Doctors
o Doctor ID (unique identifier)
o Name
o Specialty
o Availability
o Contact information
 Appointments
o Appointment ID (unique identifier)
o Patient ID
o Doctor ID
o Date and time
o Status (scheduled, confirmed, cancelled)
 Payments
o Payment ID (unique identifier)
o Appointment ID
o Payment method
o Payment date
o Amount
 Notifications

17
 o Notification ID (unique identifier)
o Appointment ID
o Notification type (reminder, confirmation, cancellation)

Data Structures

The system uses a relational database management system (RDBMS) to store and manage data. The
following data structures are used:

Tables

 Patients
o Patient ID (primary key)
o Name
o Email
o Password
o Contact information
o Medical history
 Doctors
o Doctor ID (primary key)
o Name
o Specialty
o Availability
o Contact information
 Appointments
o Appointment ID (primary key)
o Patient ID (foreign key)
o Doctor ID (foreign key)
o Date and time
o Status
 Payment
o Payment ID (primary key)
o Appointment ID (foreign key)
o Payment method
o Payment date
o Amount

18
  Notifications
o Notification ID (primary key)
o Appointment ID (foreign key)
o Notification type
o Notification date and time

Relationship

1. A patient can have multiple appointments (one-to-many).

2. A doctor can have multiple appointments (one-to-many).
3. An appointment is associated with one patient and one doctor (many-to-one).A payment is
associated with one appointment (many-to-one).
4. A notification is associated with one appointment (many-to-one).

Dataset/Database Design

The database design follows the principles of normalization to minimize data redundancy and
improve data integrity.

Normalization Rule

1. First Normal Form (1NF): Each table cell contains a single value.
2. Second Normal Form (2NF): Each non-key attribute depends on the entire primary key.
3. Third Normal Form (3NF): If a table is in 2NF, and a non-key attribute depends on another
non-key attribute, then it should be moved to a separate table.

Database Schema

The database schema is designed to support the data structures and relationship described above.

Data Storage

The system stores data in a relational database management system (RDBMS) such as MySQL.

Data Processing

The system processes data using SQL queries and stored procedures.

Data Organization

The system organizes data into tables, with each table representing a specific entity or relationship.

3.2.1 Data Dictionary

 Alphabetical List of System Entities or Major Data with Types and Descriptions:

19
 ● Prepare an alphabetical list of all system entities or significant data. For each entry,
include the data type and provide a brief description of its purpose within the
system.

Here is an alphabetical list of system entities or major data for the online doctor appointment

Entities and Data

1. Appointment
1. Type: Object
2. Description: Represents a scheduled appointment between a patient and a doctor.
2. Appointment Date
1. Type: Date
2. Description: The date of the scheduled appointment.
3. Appointment Time
1. Type: Time
2. Description: The time of the scheduled appointment.
4. Doctor
1. Type: Object
2. Description: Represents a doctor with their profile information.
5. Doctor Name
1. Type: String
2. Description: The name of the doctor.
6. Doctor Specialty
1. Type: String
2. Description: The medical specialty of the doctor.
7. Patient
1. Type: Object
2. Description: Represents a patient with their profile information.
8. Payment Method
1. Type: String
2. Description: The payment method used by the patient.
9. Speciality
1. Type: String
2. Description: A medical specialty (e.g., cardiology, pediatrics).

● Present this information in a two-column format:

20
 o The first column will contain the terminology (e.g., object name, attribute,
method, or method parameter).

o The second column will provide the description, including data types, roles, or any
other relevant information.

Terminology Description

User Represent the user entity which can be patient, doctor or admin.

Name Full name of user. (String)

Email Email address for communication and login.(String)

Role Specifies the user's role: Patients, Doctors or Admin. (Enum)

Specialization Medical field of the doctor. (String)

Appointment Entity to manage booking details between doctors and patients.

Profile View Detailed view of doctor profiles with rating and availability.

User Dashboard Personalized dashboard for patients and doctors.

Admin Panel Control panel for managing patients and, doctors.

 Structured Approach: Functions and Function Parameters:

● For systems following a structured programming paradigm, list all functions along
with their function parameters. For each function, provide a description detailing its

● Functionality, and for each parameter, specify the data type and its role within the
function.

Here's a list of functions for the online doctor appointment system, along with their parameters,
descriptions, and data types:

 register Patient
o patient Name (String): The patient’s name
o Email (String): The patient’s email address.
o Password (String): The patient’s password.
o Phone Number (String): The patient’s phone number.
o Description: Registers a new patient in the system.

21
  login Patient
o Email (String): The patient’s email address.
o Password (String): The patient’s password.
o Description: Authenticates a patient and logs them into the system.
 viewDoctorProfile
o Doctor ID (Integer): The unique ID of the doctor.
o Description: Retrieves and displays a doctor’s profile information.
 schedule Appointment
o Patient ID (Integer): The unique ID of the patient.
o Doctor ID (Integer): The unique ID of the doctor.
o Appointment Date (Date): The date of the appointment.
o Appointment Time (Time): The time of the appointment.
o Description: Schedules an appointment between a patient and a doctor
 cancel Appointment
o Appointment ID (Integer): The unique ID of the appointment.
o Description: Cancels a scheduled appointment.
 viewAppointmentSchedule
o Doctor ID (Integer): The unique ID of the doctor.
o Date (Date): The date for which to view the appointment schedule.
o Description: Retrieves and displays a doctor’s appointment schedule for a specific date.
 make Payment
o Appointment method (Integer): The unique ID of the appointment.
o Payment Method (String): The payment method used.
o Payment Amount (Float): The amount paid.
o Description: Processes a payment for a scheduled appointment.

 Object-Oriented (OO) Approach: Objects, Attributes, Methods, & Method

Parameters:
● For systems using the Object-Oriented (OO) approach, list the objects and
their attributes, followed by a description. Additionally, list the methods associated with
each object, along with their method parameters.

Here's a list of objects, attributes, descriptions, methods, and method parameters for the online doctor
appointment system using the Object-Oriented (OO) approach:

Objects, Attributes, and Descriptions

22
 1. Patient
o Patient ID (Integer): Unique ID of the patient.
o Name (String): Patient's name.
o Email (String): Patient's email address.
o Password (String): Patient's password.
o Phone Number (String): Patient's phone number.
o Description: Represents a patient in the system.
2. Doctor
o Doctor ID (Integer): Unique ID of the doctor.
o Name (String): Doctor's name.
o Specialty (String): Doctor's medical specialty.
o Availability (Array): Doctor's available time slots.
o Description: Represents a doctor in the system.
3. Appointment
o Appointment ID (Integer): Unique ID of the appointment.
o Patient ID (Integer): ID of the patient associated with the appointment.
o Doctor ID (Integer): ID of the doctor associated with the appointment.
o Appointment Date (Date): Date of the appointment.
o Appointment Time (Time): Time of the appointment.
o Description: Represents an appointment between a patient and a doctor.
4. Payment
o Payment ID (Integer): Unique ID of the payment.
o Appointment ID (Integer): ID of the appointment associated with the payment.
o Payment Method (String): Payment method used (e.g., credit card, PayPal).
o Payment Amount (Float): Amount paid.
o Description: Represents a payment made by a patient for an appointment.

Methods and Method Parameters

 Patient Object
o Register Patient (name, email, password, phone Number.
o Description: Registers a new patient in the system.
o login Patient(email, password)
o Description: Authenticates a patient and logs them into the system.
 Doctor Object
23
 o Add Doctor (name, specialty, availability).
o Description: Adds a new doctor to the system.
o viewDoctorProfile (doctor ID)
o Description: Retrieves and displays a doctor's profile information.
 Appointment Object
o schedule Appointment (patient ID, doctor ID, appointment Date, appointment Time)
o Description: Schedules an appointment between a patient and a doctor.
o cancel Appointment (appointment ID)
o Description: Cancels a scheduled appointment.
 Payment Object
o Make Payment (appointment ID, payment Method, payment Amount).
o Description: Processes a payment for a scheduled appointment.
o ViewPaymentHistory (patient ID)
o Description: Retrieves and displays a patient's payment history.

3.3 User Interface Design

Here's an overview of the functionality of the online doctor appointment system from the
user's perspective:

User Role
1. Patient: A patient can register, log in, schedule appointments, view appointment
history, and make payments.
2. Doctor: A doctor can register, log in, manage availability, confirm/cancel
appointments, and view appointment schedules.

Patient Workflow
1. Registration: The patient registers by providing personal details, contact information
and medical history.
2. Login: The patient logs in using their credentials.
3. Schedule Appointment: The patient selects a doctor, date, and time for appointment.
4. Appointment Confirmation: The patient receives a confirmation notification for the
scheduled appointment.
5. Appointment History: The patient can view their appointment history, including
upcoming and past appointments.
6. Payment: The patient makes a payment for an appointment using a secure payment
gateway.
24
 7. Notification: The patient receives notifications for appointment reminders,
confirmations, and cancellations.

Doctor Workflow
1. Registration: The doctor registers by providing personal details, contact information,
and availability schedule.
2. Login: The doctor logs in using their credentials.
3. Manage Availability: The doctor updates their availability schedule.
4. Confirm/Cancel Appointments: The doctor confirms or cancels appointments.
5. View Appointment Schedule: The doctor views their upcoming and past
appointment.
6. Notification: The doctor receives notifications for appointment confirmations,
cancellations, and reminders.

Feedback Information
The system provides feedback to users through:
1. Notifications: Automatic notifications for appointment confirmations, cancellations,
and reminders.
2. Email: Email notifications for appointment confirmations and cancellations.
3. Dashboard: A user dashboard displaying upcoming appointments, appointment
history, and payment status.

Expected Features
1. Secure Registration: Patients and doctors can register securely.
2. Appointment Scheduling: Patients can schedule appointments with doctors.
3. Appointment Confirmation: Patients receive confirmation notifications for schedule
appointments.
4. Payment Processing: Patients can make payments for appointments.
5. Notification System: Patients and doctors receive notifications for appointment
reminders, confirmations, and cancellations.
6. User Dashboard: Patients and doctors have access to a user dashboard displaying
relevant information.

25
 3.3.1 Screen Images

3.3.2 Screen Objects and Actions

A discussion of screen objects and actions associated with those object for two use cases.
Here's a discussion of screen objects and actions associated with those objects for two use cases of the
online doctor appointment system:

Use Case 1: Patient Finding a Doctor by Specialty

Screen Objects
1. Find by Specialty: A dropdown menu or search bar allowing patients to select a medical
specialty.
2. Header Banner: A banner displaying the system's logo, navigation menu, and search bar.

Actions

1. Select Specialty: Patient selects a medical specialty from the dropdown menu or search bar.
2. Book Appointment: Patient clicks on a doctor's profile to book an appointment.
3. Search: Patient uses the search bar in the header banner to search for doctors or medical
specialties.

26
Use Case 1: Filtering Doctors by Specialization
Screen Objects:
1. Specialization Buttons (e.g., "General physician", "Gynecologist", etc.)
2. Doctor Cards (Name, Image, Availability, Specialty)

Actions:
1. Click on Specialization Button: Filters the visible doctor cards to show only those
matching the selected specialization.
2. View Filtered Results: The display updates in real-time, hiding all unrelated doctors
and showing only the relevant ones.

27
Use Case 2: Viewing Doctor Details or Booking an Appointment
Screen Objects:
1. Doctor Cards (Clickable area)
2. Doctor Name and Image (potentially part of the clickable area)

Actions:
1. Click on Doctor Card: Navigates to a detail view page for that doctor (not visible in
the screenshot, but likely part of the app).

Use Case 1: Viewing about Page Information

Screen Objects
1. Navigation Bar (ABOUT link)
2. Image (of doctors)
3. Text Content Section (ABOUT US, Our Vision)
4. Why Choose Us Section (Efficiency, Convenience, and Personalization)

Action
1. User clicks on the “About” link in the top navigation bar.
2. Displayed as a static image to add trust and visual appeal (no action required).
3. User reads static text content detailing company mission and vision.
28
 4. User scrolls and reads each card or column for platform benefits.

Use Case 2: Getting in Touch with the Company

Screen Objects
1. Footer Section (GET IN TOUCH):
2. Phone Number Object (+92-345-789990)
3. Email Address Object (bzt2021sm.253@[Link])

Actions
1. User can tap/click to initiate a phone call (on mobile).
2. User clicks to open their email client with pre-filled email address.

Use Case 1: View and Manage Appointments

Screen Objects:
1. Doctor Card
2. Doctor's name and photo
3. Specialization
4. Address
5. Date and Time of Appointment
6. Buttons
7. Pay online button
8. Cancel appointment button

29
Actions:
1. View Appointment Details: Users can view key information like the doctor’s
specialization, location, and appointment date/time.
2. Pay for Appointment: Clicking the “Pay Online” button likely redirects to a payment
gateway or initiates a payment process.
3. Cancel Appointment: Clicking the “Cancel appointment” button would likely trigger a
confirmation dialog and, upon confirmation, remove the appointment from the list or
update its status.

Use Case 2: Navigation and Profile Interaction

Screen Objects:
1. Navigation Bar
 Home
 All Doctors
 About
 Contact
2. User Profile Icon: Located at the top-right corner
3. Footer: Contains links and contact info

Actions:
1. Navigate Through Pages: Clicking on the navbar items takes the user to different
sections of the site (e.g., list of doctors, about page).
2. Access User Profile/Settings: Clicking on the user icon may open a dropdown with
options like “My Profile,” “Logout,” or “Settings.”
3. Contact Support: Information in the footer (phone number and email) allows the user
to reach out to support or for inquiries.

30
Use Case 1: View Profile Information
Screen Objects

1. Profile Image
2. Name
3. Email, Phone, Address
4. Gender, Birthday

Actions

1. User can view their contact and basic info.

2. User can switch to other pages (Home, about, etc.).

Use Case 2: Edit Profile Information

Screen Objects

1. “Edit Button”

Actions

1. Click “Edit” to transit the page to editable format.

2. Update Fields to modify names, phone etc.
3. Save Changes a button to submit updates.

31
 4. Cancel Edit.

1.4. Behavioral Model

Interaction Diagrams:

Figure 6 Interaction Diagram

Description:
A sequence diagram for online doctor appointment might show the steps involved in
scheduling an appointment, such as:

 Patient: They can book and cancel appointments, view prescriptions, and join a
waiting list if no slots are available and search for a doctor by specialization.
 Doctor: The Doctor attributes related to a medical professional, such as
specialization and availability. Doctors can manage their schedule, view upcoming
appointments, and issue prescriptions.
 Appointment: This can handles appointment data between a patient and a doctor. It
includes scheduling details, status, and links to the payment made for the
consultation.
 User: They can define common properties and behaviors shared by all users of the
system, such as patients, doctors, and admins. It includes authentication features like
login and logout, and user profile management.

State Diagrams:
32
 Figure 7 State Transition Diagram

Description:

33
Here is a detailed description of the state transition diagram for an online doctor appointment
system:

States:

1. Initial State: The system is idle, waiting for user interaction.

2. Searching for Doctor: The user is searching for a doctor.
3. Doctor Available: The system has found a doctor who is available.
4. Schedule: The user is scheduling an appointment with the doctor.
5. Confirmed: The appointment has been confirmed.
6. Rescheduled: The appointment has been rescheduled.
7. Cancelled: The appointment has been cancelled.
8. Completed: The appointment has been completed.
9. Payment Confirmed: The payment for the appointment has been confirmed.
10. Payment Failed: The payment for the appointment has failed.

Events:

1. Search Doctor: User searches for a doctor.

2. Select Doctor: User selects a doctor.
3. Schedule Appointment: User schedules an appointment.
4. Confirm Appointment: Appointment is confirmed.
5. Reschedule Appointment: User reschedules the appointment.
6. Cancel Appointment: User cancels the appointment.
7. Complete Appointment: Appointment is completed.
8. Make Payment: User makes a payment.
9. Payment Success: Payment is confirmed.
10. Payment Failure: Payment fails.

4. Design Decisions
Highlight the design choices while designing your system (e.g. choosing the Object oriented
design pattern, choosing between the algorithmic approaches and normalization level of the
database). Clearly specify which approach you have used and why you have made a specific
design choice.

Here’s how we can explain the design choice while developing online doctor appointment
System.

Design Choice

34
 1. Frontend Framework
o ReactJS: We chose ReactJS as the front-end framework for building the user
interface of the online doctor appointment system. ReactJS provides a component-
based architecture, making it easy to manage and reuse UI components.
2. Backend Framework
o [Link] with [Link]: We used [Link] with [Link] as the back-end
framework for handling server-side logic, API routing, and database interactions.
[Link] provides an event-driven, non-blocking I/O model, while [Link] offers a
flexible and modular framework for building web applications.
3. Database Management System
o MongoDB: We selected MongoDB as the No SQL database management system for
storing and managing data. MongoDB provides flexible schema design, high
scalability, and ease of use.
4. Authentication and Authorization
o JSON Web Tokens (JWT): We implemented JSON Web Tokens (JWT) for
authentication and authorization. JWT provides a secure and secure way to
authenticate users and protect API routes.
5. API Design
o REST full API: We designed a REST full API for interacting with the back-end
server. The API follows standard HTTP methods (GET, POST, PUT, and DELETE)
and provides clear, descriptive endpoints for accessing and manipulating data.
6. Error Handling and Logging
o Try-Catch Blocks: We used try-catch blocks to handle runtime errors and
exceptions.
7. Code Organization and Modularity
o Modular Code Structure: We organized the code into separate modules and folders,
following a consistent naming convention. This structure makes it easy to locate
specific code files, maintain the code base, and reuse components.

5. Summary
Summary of the key design ideas discussed, design refinement and decisions taken in the
chapter. It may also reiterate chapter’s importance in addressing the projects objectives

Here's a summary of the key design ideas discussed, design refinement, and decisions taken:

Key Design Ideas

35
 1. Object-Oriented Design Pattern: Ensures modularity, reusability, and Scalability.
2. Relational Database Management System (RDBMS): Provides data consistency and
3. Integrity.
4. Robust Error Handling: Ensures system stability and provides useful error messages.
Design Refinement and Decisions
1. Modularity: Facilitates easier maintenance and updates.
2. Scalability: Handles a large number of users and appointments efficiently.
3. Security: Protects sensitive data and prevents common web vulnerabilities.
4. Usability: Provides a user-friendly interface for patients and doctors.
Chapter Importance
This chapter is crucial in addressing the project's objectives by providing a detailed design of the online
doctor appointment system. The design decisions and refinement made in this chapter ensure that the
system is:
1. Scalable: Handles a large number of users and appointments efficiently.
2. Secure: Protects sensitive data and prevents common web vulnerabilities.
3. Usable: Provides a user-friendly interface for patients and doctors.
4. Maintainable: Designed with modularity, making it easier to maintain and update.

36
References
Books
Pressman, R. S. (2014). Software engineering: A practitioner's approach (8th d.). McGraw-
Hill Education.
Sommerville, I. (2015). Software engineering (10th Ed.). Pearson Education Limited.
YouTube Tutorials
Apna College. (n.d.). Complete MERN stack development tutorial. YouTube.
[Link]
Code With Harry. (n.d.). [Link] tutorials for beginners. YouTube.
[Link]
WsCube Tech. (n.d.). MERN stack full course. YouTube.
[Link]

36