SOFTWARE

DESIGN
DOCUMENT
GROUP 20

LifeSavers Pakistan
OVERVIEW

TABLE OF CONTENT
1. OVERVIEW ....................................................................................................................................................... 12
1.1. SCOPE ............................................................................................................................................................ 12
1.2. PURPOSE ...................................................................................................................................................... 12
1.3. INTENDED AUDIENCE ........................................................................................................................... 12
2. DEFINITIONS ............................................................................................................................................. .... 13
3. CONCEPTUAL MODEL FOR SOFTWARE DESIGN DESCRIPTION ............................................. 14
3.1. SOFTWARE DESIGN IN CONTEXT .................................................................................................... 14
3.2. SOFTWARE DESIGN DESCRIPTIONS WITHIN THE LIFE CYCLE ........................................ 14
3.2.1. INFLUENCES ON SDD PREPARATION ....................................................................................... 14
3.2.2. INFLUENCES ON SOFTWARE LIFE CYCLE PRODUCTS ...................................................... 14
3.2.3. DESIGN VERFICATION AND DESIGN ROLE IN VALIDATION .......................................... 14
4. DESIGN DESCRIPTION INFORMATION CONTENT ........................................................................ 15
4.1. INTRODUCTION ....................................................................................................................................... 15
4.2. SDD IDENTIFICATION ........................................................................................................................... 15
4.3. DESIGN STAKEHOLDERS AND THEIR CONCERNS ................................................................... 15
4.4. DESIGN VIEWS .......................................................................................................................................... 15
4.5. DESIGN VIEWPOINTS ............................................................................................................................ 15
4.6. DESIGN ELEMENTS ................................................................................................................................ 16
4.6.1. DESIGN ENTITIES ............................................................................................................................... 16
4.6.2. DESIGN ATTRIBUTES ....................................................................................................................... 16
4.6.3. DESIGN CONSTRAINTS..................................................................................................................... 17
4.7. DESIGN RATIONALE ...............................................................................................................................17
4.8. DESIGN LANGUAGES .............................................................................................................................. 18
5. DESIGN VIEWPOINTS ................................................................................................................................. 19
5.1. INTRODUCTION ....................................................................................................................................... 19
5.2. CONTEXT VIEWPOINT .......................................................................................................................... 19
5.2.1. DONOR USECASE ................................................................................................................................ 20
5.2.1.1. REGISTER AS DONOR ................................................................................................................... 21

Page 2
10
OVERVIEW

5.2.1.2. VIEW DONTION HISTORY .......................................................................................................21

5.2.1.3. CHOOSE DONATION PREFERENCE ....................................................................................... 21
5.2.1.4. TAKE PART IN AWARENESS CAMPAIGN ............................................................................ 22
5.2.1.5. FEEDBACK AND SUPPORT ........................................................................................................ 22
5.2.1.6. RECEIVE POST SURGERY SUPPORT ...................................................................................... 23
5.2.1.7. VIEW DONATION REQUESTS .................................................................................................... 23
5.2.2. RECEIVER USE CASE ......................................................................................................................... 24
5.2.2.1. REGISTRATION ............................................................................................................................... 25
5.2.2.2. SEARCH FOR COMPATIBLE DONORS .................................................................................... 25
5.2.2.3. ACCESS PROFILES .......................................................................................................................... 25
5.2.2.4. SUBMIT HEALTH REPORTS ....................................................................................................... 26
5.2.2.5. LOGISTICS SYSTEM ....................................................................................................................... 26
5.2.2.6. FEEDBACK AND SUPPORT ......................................................................................................... 26
5.2.2.7. ORGAN MATCH STATUS .............................................................................................................. 27
5.2.2.8. ENGAGE IN AWARENESS CAMPAIGNS ................................................................................. 27
5.2.2.9. COORDINATE WITH HEALTHCARE PROFESSIONAL ..................................................... 27
5.2.3. ADMIN USE CASE ................................................................................................................................ 28
5.2.3.1. MANAGE USER ACCOUNT .......................................................................................................... 29
5.2.3.2. MANAGE FEEDBACK AND SUPPORT .................................................................................... 29
5.2.3.3. MONITOR SYSTEM PERFORMANCE ...................................................................................... 29
5.2.3.4. COORDINATION WITH HEALTHCARE PROFESSIONALS ............................................ 30
5.2.3.5. VIEW USER HISTORY ................................................................................................................... 30
5.2.3.6. SEARCH FOR DONORS ................................................................................................................ 31
5.2.3.7. FACILITAE ORGAN DONATION .............................................................................................. 31
5.2.3.8. LOGISTICS SYSTEM ...................................................................................................................... 32
5.2.3.9. UPDATE DONATION CENTER DIRECTORY ....................................................................... 32
5.2.4. HEALTHCARE PROFESSIONAL USE CASE ............................................................................... 33
5.2.4.1. MATCHING OF ORGAN ................................................................................................................34
5.2.4.2. VIEW PATIENT PROFILES ......................................................................................................... 34
5.2.4.3. MONITOR POST SURGERY SUPPORT ................................................................................... 34

Page 3
OVERVIEW

5.2.4.4. ENGAGE IN AWARENESS CAMPAIGNS ............................................................................... 35

5.2.4.5. VERIFY ORGAN FOR DONATION.............................................................................................. 35
5.3. LOGICAL VIEWPOINT ............................................................................................................................ 36
5.3.1. USER CLASS ........................................................................................................................................... 37
5.3.1.1. FIELDS ................................................................................................................................................ 37
5.3.1.2. FUNCTIONS ...................................................................................................................................... 37
5.3.2. ADMIN CLASS …………………............................................................................................................. 38
5.3.2.1. FUNCTIONS ...................................................................................................................................... 38
5.3.3. RECIPIENT CLASS .............................................................................................................................. 38
5.3.3.1. FIELDS ................................................................................................................................................ 39
5.3.3.2. FUNCTIONS ...................................................................................................................................... 39
5.3.4. DONOR CLASS …………………............................................................................................................. 39
5.3.4.1. FIELDS ................................................................................................................................................ 40
5.3.4.2. FUNCTIONS ...................................................................................................................................... 40
5.3.5. DONATION REQUEST CLASS ......................................................................................................... 40
5.3.5.1. FIELDS ................................................................................................................................................ 40
5.3.6. ORGAN MATCHING CLASS .............................................................................................................. 40
5.3.6.1. FUNCTIONS ...................................................................................................................................... 41
5.3.7. DONATION CLASS .............................................................................................................................. 41
5.3.7.1. FIELDS ................................................................................................................................................ 41
5.3.8. DONATION HISTORY CLASS .......................................................................................................... 41
5.3.8.1. FUNCTIONS ...................................................................................................................................... 42
5.3.9. DONATION CENTER CLASS ........................................................................................................... 42
5.3.9.1. FIELDS ................................................................................................................................................ 43
5.3.9.2. FUNCTIONS ...................................................................................................................................... 43
5.3.10. NOTIFICATION SYSTEM CLASS …................................................................................................ 43
5.3.10.1. FUNCTIONS ...................................................................................................................................... 43
5.3.11. FEEDBACK CLASS ............................................................................................................................... 43
5.3.11.1. FUNCTIONS ...................................................................................................................................... 44
5.3.12. POST SURGERY CLASS …….............................................................................................................. 44

Page 4
10
OVERVIEW

5.3.12.1. FIELDS ..............................................................................................................................................45

5.3.12.2. FUNCTIONS ...................................................................................................................................... 45
5.3.13. LOGISTICS CLASS ................................................................................................................................ 45
5.3.13.1. FIELDS ................................................................................................................................................ 45
5.3.13.2. FUNCTIONS ...................................................................................................................................... 45
5.3.14. PROFILE MANAGEMENT CLASS .................................................................................................. 46
5.3.14.1. FUNCTIONS ...................................................................................................................................... 46
5.3.15. AWARENESS CAMPAIGNS CLASS ….............................................................................................46
5.3.15.1. FUNCTIONS ...................................................................................................................................... 47
5.3.16. HEALTHCARE PROVIDER CLASS ................................................................................................. 48
5.3.16.1. FIELDS ................................................................................................................................................. 48
5.3.16.2. FUNCTIONS ...................................................................................................................................... 48
5.3.17. PAYMENT CLASS ................................................................................................................................. 48
5.3.17.1. FIELDS ................................................................................................................................................. 48
5.3.17.2. FUNCTIONS ...................................................................................................................................... 49
5.4. INTERFACE VIEWPOINTS .................................................................................................................... 50
5.4.1. SYSTEM INTERFACE.......................................................................................................................... 50
5.4.1.1. LIFESAVERS PAKISTAN MANAGEMENT SYSTEM .......................................................... 50
5.4.1.2. LIFESAVERS PAKISTAN WEBSITE ......................................................................................... 55
5.4.2. USER INTERFACE ............................................................................................................................... 60
5.4.2.1. HOME PAGE USER INTERFACE ............................................................................................... 60
5.4.2.2. REGISTRATION USER INTERFACE ........................................................................................ 62
5.4.2.3. LOGIN PAGE USER INTERFACE .............................................................................................. 63
5.4.2.4. RECVER PASSWORD USER INTERFACE .............................................................................. 63
5.4.2.5. MAIN MENU USER INTERFACE ............................................................................................... 64
5.4.2.6. VIEW PROFILE USER INTERFACE ......................................................................................... 66
5.4.2.7. EDIT PROFILE USER INTERFACE ........................................................................................... 66
5.4.2.8. DONATE ORGAN USER INTERFACE ...................................................................................... 67
5.4.2.9. SELECT DONATION CENTER USER INTERFACE.............................................................. 68
5.4.2.10. CONFIRM DONATION CENTER USER INTERFACE ......................................................... 70

Page 5
OVERVIEW

5.4.2.11. DONATION SUCCESSFUL MESSAGE INTERFACE .......................................................... 71

5.4.2.12. FIND ORGAN USER INTERFACE .............................................................................................. 72
5.4.2.13. LIST OF DONORS USER INTERFACE ..................................................................................... 72
5.4.2.14. DONOR SELECTION USER INTERFACE ............................................................................... 73
5.4.2.15. DONOR INFORMATION’S USER INTERFACE .................................................................... 74
5.4.2.16. ORGAN RECEIVING SUCCESSFUL MESSAGE USER INTERFACE ………………….... 75
5.4.2.17. DONATION HISTORY USER INTERFACE ............................................................................. 76
5.4.2.18. AWARENESS CAMPAIGNS ......................................................................................................... 77
5.4.2.19. FEEDBACK FORM USER INTERFACE ................................................................................... 78
5.4.2.20. POST-SURGERY SUPPORT USER INTERFACE .................................................................. 79
5.4.2.21. CHAT USER INTERFACE ............................................................................................................. 81
5.5. INTERACTION VIEWPOINT .................................................................................................................82
5.5.1. USER REGISTRATION AND PROFILE MANAGEMENT......................................................... 82
5.5.2. LOGISTICS COORDINATION…........................................................................................................ 84
5.5.3. ORGAN MATCHING............................................................................................................................. 85
5.5.4. ORGAN DONATION ………………….................................................................................................. 86
5.5.5. PREVENTING ILLEGAL ORGAN SALES ..................................................................................... 87
5.5.6. POST-SURGERY SUPPORT ………………....................................................................................... 88
5.5.7. DONOR AND RECIPIENT HISTORY MANAGEMENT ........................................................... 89
5.5.8. FEEDBACK AND SUPPORT.............................................................................................................. 90
5.5.9. AWARENESS CAMPAIGNS AND COMMUNITY SUPPORT.................................................. 91
5.6. STATE DYNAMIC VIEWPOINT ........................................................................................................... 92
5.6.1. SYSTEM COORDINATOR / ADMIN .............................................................................................. 92
5.6.1.1. LOGIN .................................................................................................................................................. 92
5.6.1.2. SYSTEM COORDINATOR DASHBOARD ................................................................................. 92
5.6.1.3. MANAGE USERS ...............................................................................................................................93
5.6.1.4. AWARENESS CAMPAIGNS ...........................................................................................................93
5.6.1.5. REVIEW REPORTS ..........................................................................................................................93
5.6.1.6. MONITOR TRANSACTIONS..........................................................................................................93
5.6.1.7. FLAG SUSPICIOUS ACTIVITY ......................................................................................................93

Page 6
10
OVERVIEW

5.6.1.8. ILLEGAL ACTIVITY PREVENTION .......................................................................................... 93

5.6.1.9. APPROVE OR REJECT ORGAN MATCH ...................................................................................93
5.6.1.10. LOGISTICS COORDINATION .......................................................................................................93
5.6.1.11. POST-SURGERY SUPPORT .......................................................................................................... 93
5.6.2. ORGAN RECEIVER .............................................................................................................................. 94
5.6.2.1. LOGIN ................................................................................................................................................... 94
5.6.2.2. RECEIVER DASBOARD ................................................................................................................. 94
5.6.2.3. UPDATE PROFILE AND MEDICAL REQUIREMENTS .......................................................94
5.6.2.4. APPLY FOR ORGAN MATCH .......................................................................................................95
5.6.2.5. LOGISTICS COORDINATION .......................................................................................................95
5.6.2.6. AVAIL SURGERY ..............................................................................................................................95
5.6.2.7. REQUEST POST-SURGERY SUPPORT .....................................................................................95
5.6.2.8. AVAIL POST SURGERY .................................................................................................................95
5.6.2.9. VIEW SURGERY AND POST-SURGERY RECORDS ……………………………………….… 95
5.6.2.10. AWARENESS CAMPAIGNS ......................................................................................................... 95
5.6.2.11. FEEDBACK AND SUPPORT ......................................................................................................... 95
5.6.3. ORGAN DONOR ……............................................................................................................................. 96
5.6.3.1. LOGIN …............................................................................................................................................... 96
5.6.3.2. DONOR DASHBOARD …................................................................................................................97
5.6.3.3. ORGAN DONATION REGISTRATION ….................................................................................. 97
5.6.3.4. PROFILE AND MEDICAL HISTORY …...................................................................................... 97
5.6.3.5. DONATION HISTORY MANAGEMENT …............................................................................... 97
5.6.3.6. DONATION AND GRANTS …....................................................................................................... 97
5.6.3.7. LOGISTICS COORDINATION …................................................................................................... 97
5.6.3.8. AVAIL SURGERY ….......................................................................................................................... 97
5.6.3.9. REQUEST POST SURGERY SUPPORT …................................................................................. 97
5.6.3.10. POST SURGERY SUPPORT …...................................................................................................... 97
5.6.3.11. AWARENESS CAMPAIGN …........................................................................................................ 97
5.6.3.12. FEEDBACK AND SUPPORT …..................................................................................................... 98
5.6.4. HEALTHCARE PROFESSIONALS …............................................................................................... 98

Page 7
OVERVIEW

5.6.4.1. LOGIN ….............................................................................................................................................. 99

5.6.4.2. HEALTHCARE PROFESSIONAL DASHBOARD …................................................................ 99
5.6.4.3. PATIENT RECORD MANAGEMENT …..................................................................................... 99
5.6.4.4. ORGAN MATCH REVIEW …......................................................................................................... 99
5.6.4.5. LOGISTICS COORDINATION ….................................................................................................. 99
5.6.4.6. SURGICAL PREPARATION …...................................................................................................... 99
5.6.4.7. POST-OPERATIVE MONITORING …........................................................................................ 99
5.6.4.8. FEEDBACK AND SUPPORT …..................................................................................................... 99
5.6.4.9. AWARENESS CAMPAIGNS ………………………………………………………………………..... 99
6. PLANNING OF PROJECT ………………………………………………………………………………………. 101

Page 8
10
OVERVIEW

TABLE OF FIGURES
Figure 1. Visualization of Donor Use Case Diagram ........................................................................................................... 20
Figure 2. Visualization of Register as Donor Use Case Diagram .................................................................................. 21
Figure 3. Visualization of View Donation History Use Case Diagram ........................................................................ 21
Figure 4. Visualization of Choose Donation Preference Use Case Diagram ............................................................ 22
Figure 5. Visualization of Take Part in Awareness Campaigns Use Case Diagram .............................................. 22
Figure 6. Visualization of Feedback and Support Use Case Diagram ......................................................................... 22
Figure 7. Visualization of Receive Post Surgery Support Use Case Diagram .......................................................... 23
Figure 8. Visualization of View Donation Request Use Case Diagram ....................................................................... 23
Figure 9. Visualization of Receiver Use Case Diagram...................................................................................................... 25
Figure 10. Visualization of Registration Use Case Diagram ........................................................................................... 25
Figure 11. Visualization of Search for Compatible Donors Use Case Diagram ...................................................... 26
Figure 12. Visualization of Access Profile Use Case Diagram ........................................................................................ 26
Figure 13. Visualization of Submit Health Report Use Case Diagram ........................................................................ 26
Figure 14. Visualization of Logistics System Use Case Diagram .................................................................................. 26
Figure 15. Visualization of Feedback and Support Use Case Diagram ..................................................................... 27
Figure 16. Visualization of Organ Match Status Use Case Diagram ............................................................................ 27
Figure 17. Visualization of of Engage in Awareness Campaigns Diagram ............................................................... 27
Figure 18. Visualization of Coordinate with HealthCare Professional Use Case Diagram ................................ 28
Figure 19. Visualization of Admin Use Case Diagram ....................................................................................................... 28
Figure 20. Visualization of Manage User Account Use Case Diagram ........................................................................ 29
Figure 21. Visualization of View Donation Request Use Case Diagram .................................................................... 29
Figure 22. Visualization of Monitor System Performance Use Case Diagram ........................................................ 30
Figure 23. Visualization of Coordination with HealthCare Professional Use Case Diagram ........................... 30
Figure 24. Visualization of View User History Use Case Diagram ............................................................................... 31
Figure 25. Visualization of Search for Donors Use Case Diagram ............................................................................... 31
Figure 26. Visualization of Facilitate Organ Donation Support Use Case Diagram ............................................. 31
Figure 27. Visualization of Logistics System Use Case Diagram .................................................................................. 32
Figure 28. Visualization of Update Donation Center Directory Use Case Diagram.............................................. 32
Figure 29. Visualization of HealthCare Professional Use Case Diagram ................................................................... 33
Figure 30. Visualization of Matching of Organ Use Case Diagram............................................................................... 34
Figure 31. Visualization of View Patients Profile Use Case Diagram ......................................................................... 34
Figure 32. Visualization of Monitor Post Surgery Support Use Case Diagram ...................................................... 35
Figure 33. Visualization of Engage in Awareness Campaigns Use Case Diagram................................................. 35
Figure 34. Visualization of Verify Organ for Donation Use Case Diagram ............................................................... 35
Figure 35. Visualization of Class Diagram .............................................................................................................................. 36
Figure 36. Visualization of User Class Diagram ................................................................................................................... 37
Figure 37. Visualization of Admin Class Diagram ............................................................................................................... 38

Page 9
OVERVIEW

Figure 38. Visualization of Recipient Class Diagram ......................................................................................................... 39

Figure 39. Visualization of Donor Class Diagram................................................................................................................ 39
Figure 40. Visualization of Donation Class Diagram ......................................................................................................... 40
Figure 41. Visualization of Organ Matching Class Diagram............................................................................................ 41
Figure 42. Visualization of Donation Class Diagram ......................................................................................................... 41
Figure 43. Visualization of Donation History Class Diagram ......................................................................................... 42
Figure 44. Visualization of Donation Center Class Diagram .......................................................................................... 42
Figure 45. Visualization of Notification System Class Diagram .................................................................................... 43
Figure 46. Visualization of Feedback Class Diagram ......................................................................................................... 44
Figure 47. Visualization of Post Surgery Support Class Diagram ................................................................................ 45
Figure 48. Visualization of Logistics Class Diagram .......................................................................................................... 45
Figure 49. Visualization of Profile Management Class Diagram .................................................................................. 46
Figure 50. Visualization of Awareness Campaigns Class Diagram .............................................................................. 47
Figure 51. Visualization of Search for HealthCare Provider Diagram ....................................................................... 47
Figure 52. Visualization of Payment Class Diagram .......................................................................................................... 48
Figure 53. Visualization of LifeSavers Pakistan Deployment Diagram ..................................................................... 50
Figure 54. Visualization of LifeSavers Pakistan System Node ..................................................................................... 51
Figure 55. Visualization of System Coordinator PC Node ............................................................................................... 51
Figure 56. Visualization of System Coordinator Mobile Phone Node ....................................................................... 52
Figure 57. Visualization of Data Analytics Server Node................................................................................................... 52
Figure 58. Visualization of XGBoost Server Node .............................................................................................................. 53
Figure 59. Visualization of New Donor & Recipient Database Server Node .......................................................... 53
Figure 60. Visualization of LifeSavers Database Server Node ..................................................................................... 54
Figure 61. Visualization of LifeSavers Pakistan Website Deployment Diagram ................................................... 55
Figure 62. Visualization of LifeSavers Pakistan Website Node ................................................................................... 56
Figure 63. Visualization of Admin Device Node ................................................................................................................. 56
Figure 64. Visualization of Donor Device Node .................................................................................................................. 57
Figure 65. Visualization of Recipient Device Node ........................................................................................................... 57
Figure 66. Visualization of HealthCare Professionals Device Node ........................................................................... 58
Figure 67. Visualization of Backup Server Node ................................................................................................................ 58
Figure 68. Visualization of Web Server Node ...................................................................................................................... 59
Figure 69. Visualization of Backup Server Node ................................................................................................................. 59
Figure 70. Visualization of Home Page User Interface ..................................................................................................... 61
Figure 71. Visualization of Registration User Interface ................................................................................................... 62
Figure 72. Visualization of Login Page User Interface ...................................................................................................... 63
Figure 73. Visualization of Recover Password User Interface ...................................................................................... 64
Figure 74. Visualization of Main Menu User Interface ..................................................................................................... 65
Figure 75. Visualization of View Profile User Interface ................................................................................................... 66

Page 10
10
OVERVIEW

Figure 76. Visualization of Edit Profile User Interface ..................................................................................................... 67

Figure 77. Visualization of Donate Organ User Interface ................................................................................................ 68
Figure 78. Visualization of Select Donation Center User Interface ............................................................................. 69
Figure 79. Visualization of Confirm Donation Center User Interface ........................................................................ 70
Figure 80. Visualization of Donation Successful Message User Interface ................................................................ 71
Figure 81. Visualization of Find Organ User Interface...................................................................................................... 72
Figure 82. Visualization of List of Donors User Interface................................................................................................ 73
Figure 83. Visualization of Donor Selection User Interface ........................................................................................... 74
Figure 84. Visualization of Donor’s Information User Interface .................................................................................. 75
Figure 85. Visualization of Organ Receiving Successful Message User Interface ................................................. 76
Figure 86. Visualization of Donation History User Interface ......................................................................................... 77
Figure 87. Visualization of Awareness Campaigns User Interface .............................................................................. 78
Figure 88. Visualization of Feedback Form User Interface ............................................................................................ 79
Figure 89. Visualization of Feedback Support User Interface ....................................................................................... 80
Figure 90. Visualization of Chat User Interface ................................................................................................................... 81
Figure 91. Visualization of User Registration Sequence Diagram ............................................................................... 82
Figure 92. Visualization of Profile Management Sequence Diagram ......................................................................... 83
Figure 93. Visualization of Logistics Coordination Sequence Diagram .................................................................... 84
Figure 94. Visualization of Organ Matching Sequence Diagram .................................................................................. 85
Figure 95. Visualization of Organ Donation Sequence Diagram .................................................................................. 86
Figure 96. Visualization of Preventing Illegal Organ Sales Sequence Diagram ..................................................... 87
Figure 97. Visualization of Post-Surgery Support Sequence Diagram ...................................................................... 88
Figure 98. Visualization of Donor and Recipient History Management Sequence Diagram............................ 89
Figure 99. Visualization of Feedback and Support Sequence Diagram ..................................................................... 90
Figure 100. Visualization of Awareness Campaigns and Community Engagement Sequence Diagram .... 91
Figure 101. Visualization of System Coordinator State Chart Diagram .................................................................... 92
Figure 102. Visualization of Organ Receiver State Chart Diagram ............................................................................. 94
Figure 103. Visualization of Organ Donor State Chart Diagram ................................................................................. 96
Figure 104. Visualization of HealthCare Professionals State Chart Diagram ......................................................... 98

Page 11
OVERVIEW

1. OVERVIEW
The Software Design Document (SDD) for the LifeSavers Pakistan contains definitions that
are necessary to build a concept and further form the design of the software. The document is
structured based on the requirements and functionalities that were mentioned in the software
requirements specifications (SRS) report. The goal is to supply comprehensible guidance for a
design that can be easily implemented by any programmer who reads this document. The
document holds fast the IEEE standards (IEEE Std 1016 - 2009).

1.1. SCOPE
The following SDD contains a full outline of the project, including its main features, design
constraints, system architecture and data structure. Moreover, it also provides a summary of
the timeline of our project and our current progress. By the use of UML diagrams, we have
visually represented the design of the system and its subsystems/modules the purpose of it is
to make it easier for the programmers to have a clear idea of the information provided in this
document.

1.2. PURPOSE
The objective of this SDD for the LifeSavers Pakistan is to provide a design that adheres to
the functional and non-functional requirements of the SRS document. It acts as a guide for the
developers during the course of the entire project to ensure that the application is able to
efficiently link the available donors with the people in need and further the cause of organ as
well as blood donation within Pakistan.

1.3. INTENDED AUDIENCE

The primary target audience regarding this document comprise the development team that
has been assigned to build the LifeSavers Pakistan and the advisors who are providing support
and guidance during the development.

Page 12
10
2
.
DEFINITIONS
D
E
F
I
N
2. DEFINITIONS
I
T DEFINITIONS TABLE
I
TERMS DEFINITIONS
O
N
API Application Programming Interface
S
ETA Estimated Time of Arrival

GUI / UI Graphical User Interface / User Interface

FAQ Database Management System

IEEE Institute of Electrical and Electronics Engineers

SDD Software Design Description

SRS System Requirements Specification

Receiver User who is in need of organ transplant

Donor A user who voluntarily registers to donate an organ

HealthCare A licensed medical expert who provides guidance

Professionals and support throughout the organ donation and
transplant process

WLAN Wireless Local Area Network

LAN Local Area Network

Figma A versatile web design tool for building interactive

user interface prototypes

UML Unified Modeling Language

Page 13
3
2
. CONCEPTUAL MODEL FOR SOFTWARE DESIGN
D DESCRIPTION
E
F
I
N 3. CONCEPTUAL MODEL FOR SOFTWARE DESIGN
I
T DESCRIPTION
I
O Basic terms, concepts and context of SDD will be given in this part.
N
S 3.1. SOFTWARE DESIGN IN CONTEXT
The LifeSavers Pakistan project aims to create seamless connections between organ and
blood donors and those in dire need of assistance, facilitating timely and effective support. The
app provides a platform where donors and recipients can easily connect with each other,
enabling a rapid response to life-saving donations. By providing critical tools and information,
Lifesavers Pakistan aims to improve healthcare outcomes by creating a sustainable blood and
organ donation network.

The app is scripted in JavaScript and PHP, and styled in CSS and Bootstrap. In addition, a
location-based API is integrated to help donors find nearby donation centers, making the
donation process more convenient.

3.2. SOFTWARE DESIGN DESCRIPTIONS WITHIN THE LIFE CYCLE

3.2.1. INFLUENCES ON SDD PREPARATION

The Software Requirements Specification (SRS) document is the main source of
guidance for the design of this software application. The Key requirements of the SRS,
including functional, non-functional, and interface requirements, and the expectations of the
stakeholders, determines the design process for the LifeSavers Pakistan.

3.2.2. INFLUENCES ON SOFTWARE LIFE CYCLE PRODUCTS

During the development or implementation phase of the Software Design Document
(SDD), certain requirements may be adjusted. The SDD also plays a crucial role in designing
the test plans and documentation required for the LifeSavers Pakistan.

3.2.3. DESIGN VERFICATION AND DESIGN ROLE IN VALIDATION

Verification and validation are performed after the preparation of relevant test cases.
Each part of the system is evaluated against these cases to ensure that all requirements are
met and the application works as expected

INFORMATION CONTENT

Page 14
4
DESIGN DESCRIPTION INFORMATION CONTENT

4. DESIGN DESCRIPTION INFORMATION CONTENT

4.1. INTRODUCTION
The design and execution strategies for this life-saving donation platform are described in
LifeSavers Pakistan's Software Design Description (SDD). Diagrams, user views, and user
interactions with the application are all included in this document.

4.2. SDD IDENTIFICATION

The LifeSavers Pakistan will be deployed for the use of the real-world after the validation
and verification testing is done. To protect their privacy, donors and receivers will each have a
unique profile that is password-protected. Recipients can submit requests for specific needs,
while donors can express their donation preferences, for example certain blood types or organs.
Donors and receivers can communicate with each other directly to enable quick and timely
donations, and a location-based function will route donors to donation sites within the area.

4.3. DESIGN STAKEHOLDERS AND THEIR CONCERNS

Developers, testers, healthcare providers and end users (donors and recipients) are all
stakeholders in the LifeSavers Pakistan. The software should be simple and easy to use, have an
intuitive UI, and should handle data securely to preserve user's privacy given its important
function. Moreover, a trustworthy environment is essential for preserving user confidence.

4.4. DESIGN VIEWS

The application will have a modular structure and will follow object-oriented design and the
MVC architectural pattern. The addition, modification, and removal of features is made simpler
by this approach. For instance, the modular approach will make it easier to incorporate
additional features like a medical eligibility tracker.

A context view will show system services and user interactions with UML use case diagrams
and a structured context diagram. Input-output relationships will be clearly defined with the
help of interface views.

4.5. DESIGN VIEWPOINTS

User responsibilities and anticipated interactions are specified by the context viewpoint.
The roles of each user type (donor, recipient, and healthcare provider) as well as the boundaries
of the system and the information flow between users and the system are also described. Input-
output relationships and methods for analyzing and assessing these perspectives will be
included in the design.

Page 15
3
DESIGN DESCRIPTION INFORMATION CONTENT

INFORMATION CONTEN
The information view uses entity-relationship and UML class diagrams to give a
thorough look into persistent data. The composition view will show the staffing needs,
projected expenses, and team structure. Relationships between classes are depicted clearly
for ease of understanding. Service definitions and access mechanisms are described with
the help of interaction views. The guidance for test cases is provided by the interface
viewpoint, which also contains internal and external interface specifications. Lastly, the
state dynamic view illustrates the app state transitions with diagrams.

4.6. DESIGN ELEMENTS

4.6.1. DESIGN ENTITIES

• User
• Contactinfo
• DonorList
• DonationRequest
• Message
• Inbox
• Outbox
• DonationCenter
• DonationSchedule
• Request
• DonationHistoru
• Rating

4.6.2. DESIGN ATTRIBUTES

Below is the list of entities along with its description.

DEFINITIONS TABLE

TABLE NAME DESCRIPTION

User Holds the information of the users (donors and recipients).

ContactInfo Holds contact information of the user.

DonorList Holds the ids of registered users.

Page 16
DESIGN DESCRIPTION INFORMATION CONTENT

DonationRequest Holds the information about requests made by recipients.

Messages Holds the entire messages.

Inbox Holds the messages send to user.

Outbox Holds the messages send by the user.

DonationCenter Holds the information of donation center.

DonationSchedule Holds schedules for availability of donation services.

Request Holds donation requests submitted by recipients.

DonationHistory Holds the record of past donations.

Rating Holds the rating information.

INFORMATION CONTENT

4.6.3. DESIGN CONSTRAINTS

The LifeSavers Pakistan system is subject to the following constraints:
Regulatory and Trust constraints: Because blood and organ donations are delicate, it is
crucial that users have mutual trust. Although the platform makes relationships easier,
donor safety and confidentiality are protected by government legislation and established
healthcare practices.
Reliability constraints: The system's operation and data storage rely on a dependable
distant server. Users may experience disruptions in using the application until server
operations are resumed in the case of a server failure.
Security Constraints: User data is safely kept in a database, but there is a chance that this
data might face security threats. Security procedures must be given top priority in order to
protect the privacy of donor and recipient data.
The app's design allows for continual improvement and risk minimization by managing
these constraints related to safety, security, dependability, and regulations.

4.7. DESIGN RATIONALE

The MVC (Model-View-Controller) architectural pattern and an object-oriented design is
adopted to ensure efficiency and scalability

Page 17
DESIGN DESCRIPTION INFORMATION CONTENT

MVC Pattern: Data and user interface elements can be managed centrally using the MVC
Pattern, which divides the application into three primary parts: the controller, view, and model.
This makes it simpler to scale, maintain, and update the system.

Object-Oriented Design: This method improves maintainability, allowing developers to

swiftly isolate and fix bugs or add features. Each function's comments will serve as a guide for
developers, enabling seamless code modifications and handovers. To optimize different aspects
of the system's design, the following perspectives were chosen:

Context Viewpoint: This view aids in describing each user's path and interactions inside the
system, especially if the app's interactions are event-based (such as notifications and donation
requests).

Logical Viewpoint: The application's object-oriented design makes it ideal for class
diagrams, which efficiently illustrates complex interrelationships.

Interface Viewpoint: The LifeSavers Pakistan relies heavily on user behavior, which calls for
user-friendly interfaces and clear component diagrams.

Interaction Viewpoint: the developers and stakeholders must be able to see how the system
reacts to user activities such as submitting a request or getting in touch with a donor.

State Dynamic Viewpoint: The web pages of the application act as states, and in order to
preserve user flow, transition between these states must be carefully mapped.

4.8. DESIGN LANGUAGES

The design viewpoints have been explicitly structured and represented using the Unified
Modeling Language (UML). A visually structured and developer-friendly document can be
produced with the help of UML diagrams.

Page 18
DESIGN VIEWPOINTS

5. DESIGN VIEWPOINTS
5.1. INTRODUCTION
In this document, five viewpoints are designed for the system as listed below;

• Context Viewpoint
• Logical Viewpoint
• Information Viewpoint
• Interface Viewpoint
• Interaction Viewpoint
• State Dynamic Viewpoint

5.2. CONTEXT VIEWPOINT

There are four kinds of users in our system, namely donor, recipient, admin and healthcare
professionals.
A more detailed information about use cases can be found in system requirement
specification document.

Page 19
DESIGN VIEWPOINTS

5.2.1. DONOR USE CASE

Figure 1. Visualization of Donor Use Case Diagram

Page 20
DESIGN VIEWPOINTS

5.2.1.1. REGISTER AS DONOR

Potential donors register by submitting their details. This use case includes "Verify
Registration" to confirm the donor's eligibility and "Enter Profile Information" for
completing their personal and medical data. If the donor wishes to modify their details later,
the use case extends to "Update or Edit Profile Information." When the profile is updated
then it includes receive notifications so that the donor is notified about the update.

Figure 2. Visualization of Register as Donor Use Case Diagram

5.2.1.2. VIEW DONATION HISTORY

Donors can review their past donation records, including recipient matches and the
status of previous donations.

Figure 3. Visualization of View Donation History Use Case Diagram

5.2.1.3. CHOOSE DONATION PREFERENCE

The donors can set their "Donation Preference" for which organs they are willing to
donate. It includes “set donation availability” so that Donors can specify the time and dates
they are available for donation. and includes a system search to "Find Possible Match" based

Page 21
DESIGN VIEWPOINTS

on recipient needs. If the donor is satisfied with the match and willing to proceed further
with the donation, then it extends to confirm donation use case.

Figure 4. Visualization of Choose Donation Preference Use Case Diagram

5.2.1.4. TAKE PART IN AWARENESS CAMPAIGNS

Donors can join awareness campaigns to help promote organ donation and encourage
other people to register and take part in the donation initiative.

Figure 5. Visualization of Take Part in Awareness Campaigns Use Case Diagram

5.2.1.5. FEEDBACK AND SUPPORT

Donors can provide feedback about the process and their experience with the
application and reach out for any support they might need.

Figure 6. Visualization of Feedback and Support Use Case Diagram

Page 22
DESIGN VIEWPOINTS

5.2.1.6. RECEIVE POST SURGERY SUPPORT

After donating an organ, donors receive post-surgery support from healthcare
professionals to ensure a smooth recovery.

Figure 7. Visualization of Receive Post Surgery Support Use Case Diagram

5.2.1.7. VIEW DONATION REQUESTS

The donor can view all the donation requests. Once matched with a recipient, donors can
review the request and choose to accept it. If they accept, the donation process moves
forward. If the donor is satisfied with the match, this use case extends to "Confirm Donation,"
ensuring all details are finalized.

Figure 8. Visualization of View Donation Request Use Case Diagram

Page 23
DESIGN VIEWPOINTS

5.2.2. RECEIVER USE CASE

Figure 9. Visualization of Receiver Use Case Diagram

Page 24
DESIGN VIEWPOINTS

5.2.2.1. REGISTRATION

Receivers register by entering their personal and medical information. This use case
includes "Enter Credentials and Medical Data" for account creation. If the receiver’s data
matches with a suitable donor, the process extends to "Search for Compatible Donors”.

Figure 10. Visualization of Registration Use Case Diagram

5.2.2.2. SEARCH FOR COMPATIBLE DONORS

The system searches for donors who match the receiver’s medical requirements.
This includes viewing the "Donor Registry" to find available organs compatible with the
receiver's needs and Submit Health Reports" to document their medical background.

Figure 11. Visualization of Search for Compatible Donors Use Case Diagram

5.2.2.3. ACCESS PROFILES

The Access Profile use case allows receivers to view and manage their personal
information on the platform. This use case includes View Donor Registry, allowing the
receiver to search through and view potential donors registered in the system. This access
provides the receiver with transparency regarding available donor options and
compatibility status.

Page 25
DESIGN VIEWPOINTS

Figure 12. Visualization of Access Profile Use Case Diagram

5.2.2.4. SUBMIT HEALTH REPORTS

The receivers can submit their health reports so that their medical background and
history can be monitored.

Figure 13. Visualization of Submit Health Report Use Case Diagram

5.2.2.5. LOGISTICS SYSTEM

This use case ensures that the organ reaches the receiver in a timely manner, managing
all transportation and coordination tasks. It includes the final step in the donation process,
where the receiver is provided with the organ.

Figure 14. Visualization of Logistics System Use Case Diagram

5.2.2.6. FEEDBACK AND SUPPORT

Receivers can provide feedback about their experience and seek additional support if
needed.

Page 26
DESIGN VIEWPOINTS

Figure 15. Visualization of Feedback and Support Use Case Diagram

5.2.2.7. ORGAN MATCH STATUS

Receivers can view the current status of their organ match requests and see any updates
regarding potential donors.

Figure 16. Visualization of Organ Match Status Use Case Diagram

5.2.2.8. ENGAGE IN AWARENESS CAMPAIGNS

Receivers have the opportunity to participate in campaigns to spread awareness about
organ donation and its importance.

Figure 17. Visualization of Engage in Awareness Campaigns Use Case Diagram

5.2.2.9. COORDINATE WITH HEALTHCARE PROFESSIONAL

The receiver coordinates with a healthcare professional to receive support after surgery
and to monitor their recovery. If the receiver opts for additional post-surgery assistance, the
process extends to "Coordinate with Healthcare Professional."

Page 27
DESIGN VIEWPOINTS

Figure 18. Visualization of Coordinate with HealthCare Professional Use Case Diagram

5.2.3. ADMIN USE CASE

Figure 19. Visualization of Admin Use Case Diagram

Page 28
DESIGN VIEWPOINTS

5.2.3.1. MANAGE USER ACCOUNT

Admins manage user accounts, including registration, verification, and access control.
This includes "Verify Donor Registry" to ensure that all registered donors are valid and meet
the standards of the platform.

Figure 20. Visualization of Manage User Account Use Case Diagram

5.2.3.2. MANAGE FEEDBACK AND SUPPORT

The Manage Feedback and Support use case enables admins to receive and respond to
user feedback, assisting users with any issues or concerns they have with the platform. This
feature ensures user satisfaction and addresses any platform-related problems.

Figure 21. Visualization of View Donation Request Use Case Diagram

5.2.3.3. MONITOR SYSTEM PERFORMANCE

Monitor System Performance allows admins to continuously oversee the platform's
operational health, identifying and resolving performance issues to ensure that users
experience minimal downtime and a smooth interface.

Page 29
DESIGN VIEWPOINTS

Figure 22. Visualization of Monitor System Performance Use Case Diagram

5.2.3.4. COORDINATION WITH HEALTHCARE PROFESSIONALS

Admins coordinate with healthcare professionals to facilitate organ matching, donation,
and post-surgery care. This use case extends to "Post-Surgery Support" if the recipient
requires additional assistance after the procedure. And the post-surgery support includes
the book appointment use case to book appointments during the post-surgery support.

Figure 23. Visualization of Coordination with HealthCare Professional Use Case Diagram

5.2.3.5. VIEW USER HISTORY

View User History enables admins to access the profiles and history of both donors and
recipients, including medical data and past interactions within the system. This access helps
in assessing compatibility and facilitating organ matching. This use case includes Conduct
System Audit to check the authenticity and compliance of users based on their activities
within the platform. Conduct system audit includes monitoring illegal activity so that the
admin can monitor if there is any illegal activity going on within the platform if the admin
suspects of any user being involved in such activity then it extends to suspension of that
user’s account from the platform.

Page 30
DESIGN VIEWPOINTS

Figure 24. Visualization of View User History Use Case Diagram

5.2.3.6. SEARCH FOR DONORS

The Search for Donors use case allows admins to browse through the registry of donors
to find suitable matches based on recipient needs and medical compatibility. Admins can
filter and sort donors to optimize the matching process.

Figure 25. Visualization Search for Donors Use Case Diagram

5.2.3.7. FACILITATE ORGAN DONATION

The Facilitate Organ Donation use case allows admins to coordinate the organ donation
process by managing interactions between donors, recipients, and healthcare professionals.
This coordination ensures that matching, medical compatibility, and necessary
documentation are efficiently handled, creating a streamlined experience for all parties
involved.

Figure 26. Visualization of Facilitate Organ Donation Support Use Case Diagram

Page 31
DESIGN VIEWPOINTS

5.2.3.8. LOGISTICS SYSTEM

Admins oversee the logistics of organ delivery, ensuring timely and efficient
coordination. This use case includes the "Transportation System" and "Organ Delivery
Scheduling System" to handle all transportation and scheduling requirements.

Figure 27. Visualization of Logistics System Use Case Diagram

5.2.3.9. UPDATE DONATION CENTER DIRECTORY

Admins update and manage the directory of registered donation centers. This includes
managing notifications to keep users informed about updates in the directory.

Figure 28. Visualization of Update Donation Center Directory Use Case Diagram

Page 32
DESIGN VIEWPOINTS

5.2.4. HEALTHCARE PROFESSIONAL USE CASE

Users may need to ask questions to each other. In such cases, they can send messages to
each other.

Figure 29. Visualization of HealthCare Professional Use Case Diagram

Page 33
DESIGN VIEWPOINTS

5.2.4.1. MATCHING OF ORGAN

The healthcare professional initiates a search to find potential organ donors. This
includes accessing the "View Donor Registry" to browse through registered donors and their
available organs, “Matching of organ” for matching a recipient's needs with a suitable
donor’s organ and accessing the "Verify Organ for Donation" feature to confirm organ
compatibility before proceeding.

Figure 30. Visualization of Matching of Organ Use Case Diagram

5.2.4.2. VIEW PATIENT PROFILES

This use case allows healthcare professionals to access patient records, including
medical history and donor-recipient matching history. It includes the "View Donor and
Recipient History" to gain a complete view of the patient's background.

Figure 31. Visualization of View Patients Profile Use Case Diagram

5.2.4.3. MONITOR POST SURGERY SUPPORT

After the surgery, healthcare professionals monitor the recipient's recovery process,
ensuring the organ transplant was successful and the patient is on a healthy recovery path.

Page 34
DESIGN VIEWPOINTS

Figure 32. Visualization of Monitor Post Surgery Support Use Case Diagram

5.2.4.4. ENGAGE IN AWARENESS CAMPAIGNS

Healthcare professionals can participate in or initiate awareness campaigns to educate
the public about organ donation and encourage more donors to register.

Figure 33. Visualization of Engage in Awareness Campaigns Use Case Diagram

5.2.4.5. VERIFY ORGAN FOR DONATION

Healthcare professionals verify that the selected organ meets the required medical
standards and is compatible with the recipient. If the organ match is confirmed, the process
extends to "Coordinate Logistics," where arrangements for the organ's transport to the
recipient are made.

Figure 34. Visualization of Verify Organ for Donation Use Case Diagram

Page 35
DESIGN VIEWPOINTS

5.3. LOGICAL VIEWPOINT

Figure 35. Visualization of Class Diagram

Page 36
DESIGN VIEWPOINTS

5.3.1. USER CLASS

This class contains all the attributes that are related to a user, their name, contact details,
and login information. It provides functions to manage the user registration, profile editing,
account validation, and recovery of password.

Figure 36. Visualization of User Class Diagram

5.3.1.1. FIELDS
• name: this is a string that is used to define the user's name. This attribute is
defined by the user
• email: this is a string that defines the user's email address, used for login and
notifications. It is defined by the user
• password: this is a string used for user's account password for authentication.
This attribute is defined by the user.
• phoneNo: this is an integer defined by the user to hold the contact no for
notification and communication.
• isVerified: this is a boolean set by the system or admin after the account is
successfully verified.
• role: this is a string that specifies the user role, for example admin, donor, or
recipient. It is defined by the user.

. 5.3.1.2. FUNCTIONS
• register(): this function allows a new user to create an account by providing
necessary details.
• editProfile(): this function allows the users to make changes to their profile
information.

Page 37
DESIGN VIEWPOINTS

• validateAccount(): this function is used to verify the user's account after the
registration is done.
• recoverPassword(): this function is called when the user wants to recover
his/her password if forgotten.

5.3.2. ADMIN CLASS

This class is used to represent the admin’s role in the system, it includes a unique
identifier attribute and functions that enables the admin to verify users, manage reports, and
overview the content within the system.

Figure 37. Visualization of Admin Class Diagram

5.3.2.1. FUNCTIONS
• verifyUser(): this function allows the admin to verify a new user's identity and
information.
• manageReports(): this function provides tools for the admin to view and handle
user related reports.
• manageContent(): this function allows the admin to manage and moderate the
system content within the application.

5.3.3. RECIPIENT CLASS

This class consists all the attributes and functions that are related to the recipients who
are seeking donations. It includes details like blood and organ type, urgency level, and
donation history, along with functions to post requests for organs and view donation
matches.

Page 38
DESIGN VIEWPOINTS

Figure 38. Visualization of Recipient Class Diagram

5.3.3.1. FIELDS
• bloodType: this is a string that is used to store the blood type required by the
recipient. It is defined by the recipient himself.
• organTypeNeeded: this is a string that is used to specify the type of organ needed
by the recipient. It is defined by the recipient.
• urgencyLevel: this is a string that indicates the level of urgency for the recipient's
request. It is defined by the recipient.
• history_DonationHistory: this attribute links to the donation history of the
recipient.

5.3.3.2. FUNCTIONS
• postRequest(): this function allows the recipients to make a new donation
request.
• viewDonationMatch(): this function allows the recipients to view potential
donor matches.

5.3.4. DONOR CLASS

This class contains all the attributes and functions that are related to donors, such as the
blood type and donation history. It provides functions to donate and track for updates on
the donation process.

Figure 39. Visualization of Donor Class Diagram

Page 39
DESIGN VIEWPOINTS

5.3.4.1. FIELDS
• bloodType: This is a string defined by the donor that is used to indicate the blood
type of the donor.
• organType: this is a string that is defined by the donor to specify the type of
organ that the donor wants to donate.
• history_DonationHistory: this attribute is linked by the system, connects to the
donation history of donor.
5.3.4.2. FUNCTIONS
• applyDonation(): this function is called when a donor wants to apply for a
donation.
• viewUpdates(): this function is called when the donor wants to check or view
updates about the donation status.

5.3.5. DONATION REQUEST CLASS

This class is used to store details about each donation request, it includes the request id
and its status. It helps to track and manage donation requests within the system.

Figure 40. Visualization of Donation Request Class Diagram

5.3.5.1. FIELDS
• requestId: this is a unique id defined by the system whenever a request for
donation is made by the recipient.
• status: this is a string that is set by the system which shows the current status of
the donation request.

5.3.6. ORGAN MATCHING CLASS

This class is responsible for the organ matching process between the donors and
recipients. It includes functions for matching donors, notifying when a match is found,
and performing compatibility checks.

Page 40
DESIGN VIEWPOINTS

Figure 41. Visualization of Organ Matching Class Diagram

5.3.6.1. FUNCTIONS
• matchDonor(): this function is called to match potential donors with recipients
based on the requirements.
• notifyMatch(): this function is called when a match is found to notify the donor
and recipient.
• performCompatibilityCheck(): this function is called to check compatibility
between donor and recipient.

5.3.7. DONATION CLASS

This class is used to store the details about each donation that is made by the donor. It
includes attributes like the donation id, date and the amount or quantity of donation.

Figure 42. Visualization of Donation Class Diagram

5.3.7.1. FIELDS
• donationId: this is a unique identifier given by the system each donation entry.
• Date: This is an attribute that is used to store the date of when the donation is
made by the donor.
• amount: this is a double used to store the quantity or amount of the donation
made by donor (e.g., units of blood).

5.3.8. DONATION HISTORY CLASS

Page 41
DESIGN VIEWPOINTS

This class is used to keep track of the donation history for both the donors and
recipients. It contains functions to record donations and for viewing and updating
history.

Figure 43. Visualization of Donation History Class Diagram

5.3.8.1. FUNCTIONS
• recordDonation(): this function is called whenever a new donation is made to
record the details about the new donation.
• viewHistory(): this function is used whenever a user wants to view his/her
donation history.
• updateHistory(): this function is used whenever a user wants to update (delete
or edit) his/her existing donation record.

5.3.9. DONATION CENTER CLASS

This class provides information about the donation centers, such as their name, address,
and contact info. It includes functions to view a list of centers and also get directions to a
specified center.

Figure 44. Visualization of Donation Center Class Diagram

Page 42
DESIGN VIEWPOINTS

5.3.9.1. FIELDS
• centerId: this is a unique identifier that is given to each donation center by the
system.
• name: this is a string that is defined by the system or the center to hold the name
of the donation center.
• address: this is a string defined by the center that is used to store the address of
donation center.
• contactInfo: this is a string to hold the contact information for the center and is
defined by the center.
5.3.9.2. FUNCTIONS
• viewCenterList(): this is a function that is used to display a list of all the donation
centers.
• getDirections(): this function is called when the directions to a specific donation
center is required.

5.3.10. NOTIFICATION SYSTEM CLASS

This class is used to manage user notifications and reminders related to the donation
activities. It includes functions to send alerts and reminders related to donation.

Figure 45. Visualization of Notification System Class Diagram

5.3.10.1. FUNCTIONS
• sendAlert(): this function is used to send an alert for important notifications
about donation activities.
• sendReminder(): this function is used to send reminders for donation schedules
and updates.

5.3.11. FEEDBACK CLASS

Page 43
DESIGN VIEWPOINTS

This class is made to collect feedback from the users, it has attributes like feedback
content, rating, and feedback submission date. It also provides functions to submit feedback
and view FAQs.

Figure 46. Visualization of Feedback Class Diagram

5.3.11.1. FIELDS
• feedbackId: it is a unique identifier assigned to each feedback entry by the
system.
• content: this is a string that holds the text content of the feedback that is
provided by the user.
• rating: this is an integer used to hold the rating provided by the user.
• Date: this is an attribute used to store the Date of the feedback submission.
•
5.3.11.2. FUNCTIONS
• submitFeedback(): this is a function that allows the user to submit their
feedback.
• viewFAQ(): this is a function that provides users access to frequently asked
questions.

5.3.12. POST SURGERY CLASS

This class provides post-surgery support for recipients, including functions like follow-
up scheduling and recovery resources. It also includes functions to send reminders for
medication.

Page 44
DESIGN VIEWPOINTS

Figure 47. Visualization of Post-Surgery Class Diagram

5.3.12.1. FUNCTIONS
• scheduleFollowUp(): this function allows to make schedules for follow-up
appointments after the surgery.
• provideRecoveryResources(): this function is used to provide recovery
resources to the recipients.
• sendMedicationReminder(): this function is called to send reminders for
medication intake.

5.3.13. LOGISTICS CLASS

This class is used to manage logistical aspects of the donation process, including
scheduling, tracking delivery, and updating estimated arrival times.

Figure 48. Visualization of Logistics Class Diagram

5.3.13.1. FIELDS
• location: defined by the system or logistics team. Used to store the location of
the donation or pickup.

5.3.13.2. FUNCTIONS

Page 45
DESIGN VIEWPOINTS

• scheduleDonation(): this function is called to schedule the logistics for a

donation.
• trackDelivery(): this function is called to track the status of the delivery of
donation.
• updateETA(): this function is used to update the estimated time of arrival for a
donation.

5.3.14. PROFILE MANAGEMENT CLASS

This class handles the functionalities related to profile management for users, including
creating, updating, and verifying profile details.

Figure 49. Visualization of Profile Management Class Diagram

5.3.14.1. FUNCTIONS
• createProfile(): this function allows the users to create their profile on the
system.
• updateProfile(): this function is called when users to make changes to their
profile.
• verifyDetails(): this function is called to Verify profile details for accuracy and
security.

5.3.15. AWARENESS CAMPAIGNS CLASS

This class manages the awareness campaigns and all the content related to organ and
blood donations. It includes functions to share content, organize campaigns, and post
success stories.

Page 46
DESIGN VIEWPOINTS

Figure 50. Visualization of Awareness Campaigns Class Diagram

5.3.15.1. FUNCTIONS
• shareContent(): this function is called whenever a user wants to share
awareness content with the community.
• manageCampaign(): this function is used to organize and oversee the awareness
campaigns.
• postSuccessStory(): this function is called whenever a user wants to posts
success stories to inspire and inform other users.
•
5.3.16. HEALTHCARE PROVIDER CLASS
This class provides information about the donation centers, such as their name, address,
and contact info. It includes functions to view a list of centers and also get directions to a
specified center.

Figure 51. Visualization of Healthcare Provider Class Diagram

Page 47
DESIGN VIEWPOINTS

5.3.16.1. FIELDS
• providerId: it is a unique identifier assigned to each healthcare provider by the
system.
• name: it is a string defined by the provider to store the name of the healthcare
provider.
• location: it is a string defined by the provider to store the Location details of the
healthcare provider.
5.3.16.2. FUNCTIONS
• registerPatient(): this function is called when a patient is needed to be registered
for donation services.
• checkRegistry(): this function allows you to check the registry of patients that
are in need of donations.

5.3.17. PAYMENT CLASS

This class manages the payment transactions in the system, storing details like the payment ID,
amount, and date of transaction. It also provides a function for processing payments.

Figure 52. Visualization of Payment Class Diagram

5.3.17.1. FIELDS
• paymentId: it is a unique identifier for each payment transaction. It is defined by
the system.
• amount: it is a double used to store the amount of the payment and it is defined
by the user.
• date: it is an attribute that is defined by the system to hold the date of the
transaction made.

Page 48
DESIGN VIEWPOINTS

5.3.17.2. FUNCTIONS
• processPayment(): this function is called to process the payment transactions.

Page 49
DESIGN VIEWPOINTS

5.4. INTERFACE VIEWPOINTS

5.4.1. SYSTEM INTERFACE

The purpose of this viewpoint diagram is to show system interface with hardware
components. This gives information about the correct usage of services provided by a design
object.

5.4.1.1. LIFESAVERS PAKISTAN MANAGEMENT SYSTEM

Figure 53. Visualization of LifeSavers Pakistan Deployment Diagram

Page 50
DESIGN VIEWPOINTS

 LifeSavers Pakistan Management System (Central Node):

Figure 54. Visualization of LifeSavers Pakistan System Node

The LifeSavers Pakistan management system is the central node of the

deployment diagram consisting of eight nodes, each component performing a specific
task.

 System Coordinator PC:

Figure 55. Visualization of System Coordinator PC Node

Page 51
DESIGN VIEWPOINTS

The system coordinator PC is the hardware node through which system

coordinator can access the management system, connected through WLAN to the central
node containing a desktop application UI component and an .exe file to run software.

 System Coordinator Mobile Phone:

Figure 56. Visualization of System Coordinator Mobile Phone Node

The System Coordinator mobile phone is the hardware device through which
system coordinator can interact with the management system, connected to central
node through WLAN, also containing Mobile App UI component and an artifact (.apk file)
for installing and running mobile application.

 Data Analytics Server:

Figure 57. Visualization of Data Analytics Server Node

Page 52
DESIGN VIEWPOINTS

This node is used for processing and analyzing health data to support donor-
patient matching, connected to the central node through the internet.

 Data Analytics Server:

Figure 58. Visualization of XGBoost Server Node

This node is used to match potential donors with patients, connected to the
central node through internet. It uses health data to identify compatibility.

 New Donor & Recipient Database Server:

Figure 59. Visualization of New Donor & Recipient Database Server Node

This node contains the data files of the donor and recipients, used by
LifeSavers Pakistan management system when a new donor/recipient registered. It is
connected by central node through internet and database API for secure connection.

Page 53
DESIGN VIEWPOINTS

 LifeSavers Database Server:

Figure 60. Visualization of LifeSavers Database Server Node

This node contains data files for storing data in LifeSavers Pakistan Management
System. It is connected to central node through LAN. The database base is managed by
MySQL.

Page 54
DESIGN VIEWPOINTS

5.4.1.2. LifeSavers Pakistan Website

Figure 61. Visualization of LifeSavers Pakistan Website Deployment Diagram

Page 55
DESIGN VIEWPOINTS

 LifeSavers Pakistan Website (Central Node):

Figure 62. Visualization of LifeSavers Pakistan Website Node

This is the central node of the deployment diagram containing four software components for
visualizing different features of the website. Each component performs different functionality.

 Admin device:

Figure 63. Visualization of Admin Device Node

This node allow admin to access the LifeSavers website. It contains a nested node
(web browser), reading the front-end files for the website and loads admin web UI on
the admin device. It is connected to central node through WLAN connection.

Page 56
DESIGN VIEWPOINTS

 Donor device:

Figure 64. Visualization of Donor Device Node

This node allows donors to access the LifeSavers website. It contains a nested
node (web browser), reading the front-end files for the website and loads donor web UI
on the donor device. It is connected to central node through internet connection.

 Recipient device:

Figure 65. Visualization of Recipient Device Node

This node allows recipients to access the LifeSavers website. It contains a nested
node (web browser), reading the front-end files for the website and loads donor web UI
on the recipient device. It is connected to central node through internet connection.

Page 57
DESIGN VIEWPOINTS

 HealthCare Professionals device:

Figure 66. Visualization of HealthCare Professionals Device Node

This node allows healthcare professionals to access the LifeSavers website. It

contains a nested node (web browser), reading the front-end files for the website and
loads healthcare professional web UI on the healthcare professionals’ device. It is
connected to central node through internet connection.

 Backup Server:

Figure 67. Visualization of Backup Server Node

This node allows automated backup for the database, connected to the central
node through the internet.

Page 58
DESIGN VIEWPOINTS

 Web Server:

Figure 68. Visualization of Web Server Node

This node provides a secure interface for the users, connected to the central node
through the internet.

 Website Database Server:

Figure 69. Visualization of Backup Server Node

This node contains data files for storing the data. It is connected to the central
node through LAN. The data inside the server is managed by MongoDB database
management system.

Page 59
DESIGN VIEWPOINTS

5.4.2. USER INTERFACE

All of the user interface layouts are mentioned in section 5.1. in SRS document. Some of
these are shown below.

5.4.2.1. HOME PAGE USER INTERFACE

The home page of the lifesavers App Pakistan displays an interactive user
interface. The central section provides an overview of the application firstly it introduces
LifeSavers Pakistan as a platform connecting organ donors and recipients in Pakistan,
with a mission to save lives and raise awareness. The app’s logo is displayed prominently
on the top left corner. To the right of the logo we have four main navigation options:
Home that returns the users to the main home page, About Us that offers insights into
the mission, values and purpose of Lifesavers App Pakistan, Find Organ that guides the
user through the process of searching for an organ and Register Now that allows the
users to register themselves in the application as an organ donor or recipient. A login
button is also provided on the top right corner. The design of home page ensures that
users can easily access vital information and navigate the app.

Page 60
DESIGN VIEWPOINTS

Figure 70. Visualization of Home Page User Interface

Page 61
DESIGN VIEWPOINTS

5.2.2.2. REGISTRATION USER INTERFACE

The registration page of LifeSavers App has a clean and user-friendly interface
which collects the personal information to create an account. It includes text boxes for
the user's first name, last name, phone number, email, password, address, age, and blood
group. A submit button is also provided in the page to submit details whereas an
“Already have an account?” button directs the user to the login page. The design enables
smooth registration experience with appropriate validation for data accuracy.

Figure 71. Visualization of Registration User Interface

Page 62
DESIGN VIEWPOINTS

5.4.2.3. LOGIN PAGE USER INTERFACE

By clicking on the login button the user navigates to a login page designed for
easy access into their lifesavers accounts. The login form consists of an Email field which
prompts the users to enter their registered email address and a password field for users
to enter their account password. If a user has forgotten their password, a Forgot
Password link is available below the login button that initiates the password recovery
process.

Figure 72. Visualization of Login Page User Interface

5.4.2.4. RECOVER PASSWORD USER INTERFACE

By clicking on the Forgot Password link on the login page, the user navigates to
this page, that is designed to help users securely reset their password. The users have to

Page 63
DESIGN VIEWPOINTS

enter their registered email address in the field provided. The email is used to verify
their account. After entering the email, users click the Set New Password button to
request a password reset link. This will allow the user to set a new password.

Figure 73. Visualization of Recover Password User Interface

5.2.2.5. MAIN MENU USER INTERFACE

The focus of the first organ donation interface is the homepage activity which
provides easy access for the donors to all the important functions and activities. The
page has a total of 8 buttons namely: View profile, Donate organ, Find organ, View
donations made, Campaign for organ donation awareness, A page for giving feedback,
Counseling and help for the post-operative period and Lifesavers Forums. Each of these
buttons leads to another specific effective area of the site containing that feature. By
clicking on the button View Profile, the user is able to edit her/his personal details and

Page 64
DESIGN VIEWPOINTS

current status on donations. Clicking on Donate Organ, the user is taken to a page which
contains registration instructions and forms necessary for an organ donor. By searching
for an organ, Find Organ users are able to search available organs according to their type,
need and desperation. Also View Donation History demonstrates the record of some past
donations. In that regard, the page Awareness Campaigns contains material in relation
to actions towards enhancing the rate at which people donate organs including inspiring
stories and educative content. Another way to provide useful feedback is the Viewing
Feedback Form where all the involvements and experiences on the website can be
posted. In addition to that, for donors and recipient’s post-surgery. Post-Surgery
Support has provided information and help on what to do after the operative procedure.
Watching this video of the interview reinforces the ideas presented in the Lifesavers
Forum about finding a community that’s there for you. Generally speaking, the main
menu page caters for the ease of access of the reader to the necessary tools and resources
available in the website for contributing in the activity of promoting organ donation.

Figure 74. Visualization of Main Menu User Interface

Page 65
DESIGN VIEWPOINTS

5.4.2.6. VIEW PROFILE USER INTERFACE

By clicking on the button View Profile, the user is able to edit her/his personal
details and current status on donations. User can see his/her personal information like
full name, email, district, phone number, pin code, age, blood group, address and last
donation date. There is an edit profile button which will direct the user to the edit profile
page. On the side of the page, there is a calendar and a box for donation history. Users
can also access the calendar to check the upcoming dates.

Figure 75. Visualization of View Profile User Interface

5.4.2.7. EDIT PROFILE USER INTERFACE

On the edit profile page, the user will be allowed to change his/her personal
information. Users will be allowed to update their full name, phone number, email,
address, blood group and age. There is a submit button by which the user can submit
his/her updated information. Users can access the edit profile page from the view profile
page. The design enables smooth registration experience with appropriate validation for
data accuracy.

Page 66
DESIGN VIEWPOINTS

Figure 76. Visualization of Edit Profile User Interface

5.2.2.8. DONATE ORGAN USER INTERFACE

By selecting the Donate Organ option, the user navigates to the donate organ
page which asks for information about the potential organ donor. The donor selects their
Blood Group from a dropdown menu. Moreover The donor details form contains fields
like Organ Donation Status, Health status, Organ Type and Donation Center. After
completing the form, the donor clicks on the Proceed button to submit their details and
move forward in the organ donation process.

Page 67
DESIGN VIEWPOINTS

Figure 77. Visualization of Donate Organ User Interface

5.4.2.9. SELECT DONATION CENTER USER INTERFACE

A When the user fills in his/her donation details and clicks on proceed, it will be
directed to a donation center page where the user will select the donation center for the
surgery, date and time of the surgery. The user will select the donation center by
pointing the location cursor on the map. When the user will click on date and time, users
can have a variety of donation centers to proceed the donation.

Page 68
DESIGN VIEWPOINTS

Figure 78. Visualization of Select Donation Center User Interface

Page 69
DESIGN VIEWPOINTS

5.4.2.10. CONFIRM DONATIION CENTER USER INTERFACE

When the user fills confirm the donation center page and clicks on the confirm
button, the user will be directed to a donation confirmation page where the user's
donation is confirmed. The confirmation page includes full name, phone number,
address, age, blood group, organ type, and donation center. There is a confirm button at
the end of the report which will allow the user to confirm the donation details and
proceed to the next step.

Figure 79. Visualization of Confirm Donation Center User Interface

Page 70
DESIGN VIEWPOINTS

5.2.2.11. DONATION SUCCESSFUL MESSAGE INTERFACE

When the user will complete the donation process, it will be directed to a
donation successful page where he/she will be appreciated and a pop up message will
appear on the page where there will be the user's name, location and contact number
mentioned. There will also be a confirmation line “Your donation is successful” for the
user. There is a back button for the user at the end of the page which will direct the user
back to the main menu page.

Figure 80. Visualization of Donation Successful Message User Interface

Page 71
DESIGN VIEWPOINTS

5.4.2.12. FIND ORGAN USER INTERFACE

By navigating to the Recipients details page, users in need of an organ provide
essential information to help in matching them with a potential donor. The recipient is
required to fill the fields like Blood Group, Organ Type Needed, Health status and
urgency level. After filling in the required details, recipients click the proceed button to
submit their request and initiate the matching process.

Figure 81. Visualization of Find Organ User Interface

5.4.2.13. LIST OF DONORS USER INTERFACE

After filling the find organ information, the user will be directed to a page
consisting of a list of donors. The page will display the donors according to the user’s
needs. The list will contain donors name and contact number in the list. There is also an
auto call button, who will call any random donor automatically from the list. There is a

Page 72
DESIGN VIEWPOINTS

refresh button through which the donors will be updated and the users will get all the
updates. In the den, there is a name and a number of the admin which will be called when
any of the contacts in the list are not available.

Figure 82. Visualization of List of Donors User Interface

5.2.2.14. DONOR SELECTION USER INTERFACE

When the user selects a donor, it will be directed to a confirmation page in which
a pop up message will appear with the information of the selected donor. There will be
the donor's name, location and contact number in the pop up message. After the donor’s
details, there will be a confirmation line “Is ready to donate” for the confirmation of the
donation.

Page 73
DESIGN VIEWPOINTS

Figure 83. Visualization of Donor Selection User Interface

5.4.2.15. DONOR INFORMATION’S USER INTERFACE

After a successful match the user navigates to the Receiving confirmation page
where the recipient can review key information about the matched donor before
proceeding. The donor details displayed are his/her Full Name, Contact number,
Address, Age, Blood Group, Organ Type and Donation center. After reviewing the donor
details, the recipient can click the confirm acceptance button to accept the organ and
proceed with the next steps in the process.

Page 74
DESIGN VIEWPOINTS

Figure 84. Visualization of Donor’s Information User Interface

5.4.2.16. ORGAN RECEIVING SUCCESSFUL MESSAGE USER INTERFACE

After confirming acceptance, the user is directed to the Receiving successful
page, which provides a clear confirmation of the organ acceptance. A prominent message
appears in the pop up box that says “Your acceptance is successful” followed by the

Page 75
DESIGN VIEWPOINTS

name, address and contact number of the donor. A back button is available, allowing the
users to return to the main menu.

Figure 85. Visualization of Organ Receiving Successful Message User Interface

5.2.2.17. DONATION HISTORY USER INTERFACE

When the user clicks on the view donation history button on the main menu, the
user will be directed to a donation history page where all the past donation history will
appear to the user. The donation history consists of the donated organ, date, time and
location where the organ is donated. There is a back button at the end of the page, on
clicking it the user will be directed to the main menu page.

Page 76
DESIGN VIEWPOINTS

Figure 86. Visualization of Donation History User Interface

5.4.2.18. AWARENESS CAMPAIGNS USER INTERFACE

Upon selecting the Awareness Campaign option, the user navigates to the
Awareness Campaign page, designed to educate and inform users about various organ
donation initiatives and campaigns. The page features a list of different awareness
campaigns.

Page 77
DESIGN VIEWPOINTS

Figure 87. Visualization of Awareness Campaigns User Interface

5.4.2.19. FEEDBACK FORM USER INTERFACE

When the user clicks on the feedback form button on the main menu page,
he/she will be directed to a feedback form page where the user will give his/her opinion
about the app. The user will first have to rate his/her experience from a scale of 1 to 5
star rating. Once the user has given his/her rating, the user will then have to describe
his/her experience in the textbox. There is a submit button at the bottom of my page,
where on clicking the submit button, the review and feedback of the user will be
submitted.

Page 78
DESIGN VIEWPOINTS

Figure 88. Visualization of Feedback Form User Interface

5.2.2.20. POST SURGERY SUPPORT USER INTERFACE

On selecting the post-surgery support option the user navigates to this page
designed to assist the recipients and donor in the recovery process. The page features

Page 79
DESIGN VIEWPOINTS

resources like Recovery Tips for providing essential tips and guidelines for a smooth
recovery, A Follow Up appointments so users can access a calendar or list of
recommended follow up appointments, Medication Reminders for setting reminders for
medication that the recipient might need to take as a part of recovery and a contact
medical expert feature to reach out to healthcare professionals for any questions or
concerns regarding their recovery.

Figure 89. Visualization of Feedback Support User Interface

Page 80
DESIGN VIEWPOINTS

5.4.2.21. CHAT USER INTERFACE

When the user will select the LifeSavers Forum on the main menu, the user will
be directed to a chat page where the user can chat with different other users on the
forum. All the recipients will appear on the left vertical column of the page whereas the
selected recipient will appear on the right side of the page. On the left side, there is a
search button by which the user can search for the other users whereas the search
button on the left side allows the user to search a specific message in the recipient’s chat.
The three dots at the top right part of the page allows user to block, mute or report the
recipient.

Figure 90. Visualization of Chat User Interface

Page 81
DESIGN VIEWPOINTS

5.5. INTERACTION VIEWPOINTS

5.5.1. USER REGISTRATION

Figure 91. Visualization of User Registration Sequence Diagram

Users registration will be done with individual information by the Registration System
which uses multi-factor authentications to ensure security while allowing uploading of
medical details, selecting roles as the donor or recipient, verification process.

Page 82
DESIGN VIEWPOINTS

5.5.1.1.PROFILE MANAGEMENT

Figure 92. Visualization of Profile Management Sequence Diagram

The profile is maintained safely, and data for profile can be edited, viewed, or removed
from the profile. Update profile data, view data, delete data from a profile; notifications are
shown to profile changes, where an administrator verifies the credentials.

Page 83
DESIGN VIEWPOINTS

5.5.2.LOGISTICS COORDINATION

Figure 93. Visualization of Logistics Coordination Sequence Diagram

Organ transportation needs logistics for its users who book it scheduled by Logistics
System with their integration calendar. Third parties perform transportation while giving
alerts of status on delivery or even a notification based on location. The system trackable for
delays. Optimized routing to many deliveries are provided by the system.

Page 84
DESIGN VIEWPOINTS

5.5.3. ORGAN MATCHING

Figure 94. Visualization of Organ Matching Sequence Diagram

The Matching System pools the donor organs and the recipients together using various
criteria such as blood type and urgency level. The compatibility checks are made and users
are alerted on any possible matches. Health providers are permitted to access information
of user and match records that are updated in real-time to make follow-up easier.

Page 85
DESIGN VIEWPOINTS

5.5.4. ORGAN DONATION

Figure 95. Visualization of Organ Donation Sequence Diagram

The Matching System pools the donor organs and the recipients together using various
criteria such as blood type and urgency level. The compatibility checks are made and users
are alerted on any possible matches. Health providers are permitted to access information
of user and match records that are updated in real-time to make follow-up easier.

Page 86
DESIGN VIEWPOINTS

5.5.5.PREVENTING ILLEGAL ORGAN SALES

Figure 96. Visualization of Preventing Illegal Organ Sales Sequence Diagram

User Registers for Organ Donation by filling a form with their personal details and
medical information and select which organ they want to donate or request. Their medical
records are checked by medical experts or doctors and then tested for matching of organ. If
satisfactory organ is found for receiving or donor is found for donating the application
proceeds by contacting the logistics team which will then deliver the organ to people in need.
The system ensures that all user data is encrypted for privacy and security.

Page 87
DESIGN VIEWPOINTS

5.5.6. POST-SURGERY SUPPORT

Figure 97. Visualization of Post-Surgery Support Sequence Diagram

Organ recipients can use the Support System to access post-surgical support services,
and the system also offers reminder services for appointments and medications. The users
may update schedules; the organ recipient receives recovery resources, instructions, and
access. It follows the adherence to the medical schedules by alerting users whenever their
check-ups or medication has been missed.

Page 88
DESIGN VIEWPOINTS

5.5.7.DONOR AND RECIPIENT HISTORY MANAGEMENT

Figure 98. Visualization of Donor and Recipient History Management Sequence Diagram

This includes History Management System with all donor and recipient's history and
records. So, in case users ever need them, they would be available to view them, edit them,
and manage those records. With logs viewable by admin, user receives a record of every time
something has been altered in his history. Backing of historical data can be taken to ensure
complete accuracy of data and information.

Page 89
DESIGN VIEWPOINTS

5.5.8.FEEDBACK AND SUPPORT

Figure 99. Visualization of Feedback and Support Sequence Diagram

The user submits a feedback form that goes to feedback system and is stored in the
database which then messages the user that feedback has been submitted and if the user
wants to view FAQs the database will show them to the user.

Page 90
DESIGN VIEWPOINTS

5.6.9. AWARENESS CAMPAIGNS AND COMMUNITY ENGAGEMENT

Figure 100. Visualization of Awareness Campaigns and Community Engagement Sequence Diagram

Users can access educational content and campaign materials on organ donation. Users
can share their success stories on social media, participate in forums, and become part of
the awareness programs. The Campaign System provides users with information about
events that are yet to come, and users can subscribe to the system for the next
set of campaigns.

Page 91
DESIGN VIEWPOINTS
5.6. STATE DYNAMIC VIEWPOINTS

There are four key state holders in our system and their actions are documented well in the

diagrams below. TS
5.6.1. SYSTEM COORDINATOR / ADMI

Figure 101. Visualization of System Coordinator State Chart Diagram

5.6.1.1. LOGIN
When a user opens the website, a login page appears, where they can login by entering
their email and password. If the login fails, the user will re-enter the credentials.

5.6.1.2. SYSTEM COORDINATOR DASHBOARD

If the credentials are correct and user has registered as a system coordinator, the
system coordinator dashboard opens, which shows the key functionalities of the app.
From this dashboard, the coordinator can choose if he wants to manage user profile,
review reports, monitor transactions, approve or reject organ match requests, or to
investigate suspicious activities.

Page 92
DESIGN VIEWPOINTS

5.6.1.3. MANAGE USERS

In this state, the coordinator can view, add or modify the users profile, helping to keep
the data up-to-date and make sure that all the users are registered with correct
information.

5.6.1.4. AWARENESS CAMPAIGN

In this state, the coordinator can handle the awareness campaigns related to the organ
donations, can add videos or photos related to it, creating an awareness among the
people about the safe organ donation and encourage people to go for organ donation.

5.6.1.5. REVIEW REPORTS

In this state, the coordinator can access all the reports and can analyze them to ensure
compliance & can also analyze the app performance.

5.6.1.6. MONITOR TRANSACTIONS

The monitor transaction state allows the coordinator to review all the transactions
which are being made using the app. Also if any suspicious activity is detected, the app
will automatically flags it, and the coordinator can investigate it further.

5.6.1.7. FLAG SUSPICIOUS ACTIVITY

If any suspicious activity is detected in the monitor transaction state, the coordinator
can review flagged transaction and can proceed to illegal activity prevention.

5.6.1.8. ILLEGAL ACTIVITY PREVENTION

In this state, the coordinator first verifies if the flag suspicious activity is really present
or not, if it is confirmed then the coordinator can take appropriate actions to stop that
activity to prevent further issues. And after the investigation the coordinator can exit
this state.

5.6.1.9. APPROVE OR REJECT ORGAN MATCH

From the system coordinator dashboard, the coordinator can move to the approve or
reject organ match page, where he can review organ requests and can make decisions
on approval or rejection on the basis of information from the database. If the request is
approved the coordinator can proceed to logistics coordination state to arrange
necessary requirements for the organ transplant.

5.6.1.10. LOGISTICS COORDINATION

In this state, the coordinator can arrange all the necessary logistics for the organ
transplant which includes scheduling and transport managements. After the surgery is
successfully done the coordinator can move to the post-surgery state.

5.6.1.11. POST-SURGERY SUPPORT

Page 93
DESIGN VIEWPOINTS
After the successful transplant, the coordinator can move to this state to organize
follow-up care like scheduling follow-up appointments or the support services for the
organ donor/receiver ensuring that the patient receives the proper care for the smooth
recovery. After this state, the coordinator can exit the app.

5.6.2. ORGAN RECEIVER

Figure 102. Visualization of Organ Receiver State Chart Diagram

5.6.2.1. LOGIN
When a user enters the website, a login page appears, where they can login by entering
their email and password. If the login fails, the user will re-enter the credentials.

5.6.2.2. RECEIVER DASHBOARD

If the credentials are correct and user has registered as a receiver, the receiver
dashboard opens, from where the receiver access the features like they can update
their profile and medical requirement, can apply for organ matching, view surgery and
post-surgery records, or can provide feedback.

5.6.2.3. UPDATE PROFILE AND MEDICAL REQUIREMENTS

In this state, the receiver can view or edit their profile details, health status, or medical
history when needed.

Page 94
DESIGN VIEWPOINTS

5.6.2.4. APPLY FOR ORGAN MATCHING

In this state, the receiver can request for the matching organ for the transplant by
providing relevant medical information. If the match is found the receiver moves to the
logistics coordination otherwise will wait till the match is found.

5.6.2.5. LOGISTICS COORDINATION

After the matching organ is found, the receiver can manage the necessary logistical
arrangements, like the scheduling and hospital preparation. After the logistics are
confirmed and the surgery is completed, receiver can proceed to request the post-
surgery support.

5.6.2.6. AVAIL SURGERY

In this state, after the logistics are confirmed the receiver undergoes the organ
transplant surgery. This is the most critical phase. Once the transplant is complete, the
receiver may exit or request for post-surgery care.

5.6.2.7. REQUEST POST-SURGERY SUPPORT

After the successful surgery, receiver can request additional support by submitting a
form for follow-up medical assistance, counseling, or any other post-operative care.

5.6.2.8. AVAIL POST-SURGERY

After the post-surgery form is accepted, the receiver can get ongoing care including
medical guidance, follow-ups and additional care, ensuring donors’ wellbeing and full
recovery. After this, the donor may exit the app.

5.6.2.9. VIEW SURGERY AND POST-SURGERY RECORDS

In this state, the receiver can access record of their previous surgeries, follow-up care
and all the medical history within the app.

5.6.2.10. AWARENESS CAMPAIGN STATE

In this state, the receiver can access educational content on safe organ transplant,
raising awareness and providing the important information related to the
transplantation process and also its significance which helps the receiver to
understand the impact and safety of organ transplants. This solve the concerns receiver
may have about the transplant.

5.6.2.11. FEEDBACK AND SUPPORT

In this state, the receiver can give their feedback about their experience or request
assistance or can also ask for any help. The receiver can also report any problem or can
give suggestions for the improvement of the app. After this the receiver can exit the
app.

Page 95
DESIGN VIEWPOINTS
5.6.3. Organ Donor

Figure 103. Visualization of Organ Donor State Chart Diagram

5.6.3.1. LOGIN
When a user enters the website, a login page appears, where they can login by entering
their email and password. If the login fails, the user will re-enter the credentials.

Page 96
DESIGN VIEWPOINTS

5.6.3.2. DONOR DASHBOARD

If the credentials are correct and user has registered as a donor, the donor dashboard
opens, where the donor can access the features like organ donation registration page,
can visit profile and medical history or can see their donation history.

5.6.3.3. ORGAN DONATION REGISTRATION

In this state if the donor wants to register for organ donation can fill the registration
form with all the relevant information to join donor registry. If the registration is
successful, the donor will move to next state otherwise the system will ask to enter the
correct and complete information.

5.6.3.4. PROFILE AND MEDICAL HISTORY

In this state, the donor can view and update their personal and medical information.
This state is important because the donor health care record should be save correctly.

5.6.3.5. DONATION HISTORY MANAGEMENT

In this state, the donor can view all the donations made by him with all details like
dates and the arrangements.

5.6.3.6. DONATION AND GRANTS

In this state, the donor can specify what they are donating and handle the logistics for
the process. After the confirmation they can move to the logistics coordination.

5.6.3.7. LOGISTICS COORDINATION

In this state, the donor can view about the logistics of the donation like the
transportation or the coordination with the medical teams. After the donation is
complete, the donor can move to the post-surgery support state for the recovery
assistance.

5.6.3.8. AVAIL SURGERY

In this state, the donor undergoes the surgical procedure for the donation. And after
this state, the donor can exit or can request for post-surgery care.

5.6.3.9. REQUEST POST SURGERY SUPPORT

After the successful surgery, the donor can request for the post-surgery support by
filling a request form.

5.6.3.10. POST SURGERY SUPPORT

In this state, after the request for post-surgery request is accepted, the donor can get
ongoing care including medical guidance, follow-ups and additional care, ensuring
donors’ wellbeing. After this, the donor may exit the app.

5.6.3.11. AWARENESS CAMPAIGN

Page 97
DESIGN VIEWPOINTS
In this state, the donor can access educational content on safe organ transplant, raising
awareness and providing the important information related to the transplantation
process and also its significance.

5.6.3.12. FEEDBACK AND SUPPORT

In this state, the donor can give their feedback about their experience or can also ask
for any help. The donor can also report any problem or can give suggestions for the
improvement of the app. After this the donor can exit this state.

5.6.4. HEALTHCARE PROFESSIONALS

Figure 104. Visualization of HealthCare Professionals State Chart Diagram

Page 98
DESIGN VIEWPOINTS

5.6.4.1. LOGIN
When a user opens the website, a login page appears, where they can login by entering
their email and password. If the login fails, the user will re-enter the credentials.

5.6.4.2. HEALTHCARE PROFESSIONAL DASHBOARD

If the credentials are correct and user has registered as a healthcare professional, the
healthcare professional dashboard opens, which shows the key functionalities of the
app. From this dashboard, the coordinator can choose if he wants to manage user
profile, review reports, monitor transactions, approve or reject organ match requests,
or to investigate suspicious activities.

5.6.4.3. PATIENT RECORD MANAGEMENT

In this state, the healthcare professionals can view, add or modify the patients record,
helping to keep the data up-to-date and make sure that the patient gets correct
treatment and care.

5.6.4.4. ORGAN MATCH REVIEW

In this state, the healthcare professionals can review the organ match requests. On the
basis of medical reports, they can match the compatibility of the donor and recipient
organs, so that the surgery will be possible.

5.6.4.5. LOGISTICS COORDINATION

After the organ match is found/approved, the healthcare professional can arrange the
logistics for the transplant, including the schedule of the surgery.

5.6.4.6. SURGICAL PREPARATION

In this stage, the healthcare professionals get everything ready for the transplant,
ensuring that all the facilities, medical supplies and the staff is prepared for the
operation or not.

5.6.4.7. POST-OPERATIVE MONITORING

After the surgery is successful, the healthcare professional monitors the patient’s
condition, making sure that the patient is following the after surgery precautions. After
this they can exit the app.

5.6.4.8. FEEDBACK AND SUPPORT

In this state, the healthcare professional can give feedback about the transplant
processes and can share the ideas for the betterment of the application, & also ask any
issues they face while using this app.

5.6.4.9. AWARENESS CAMPAIGNS

In this state, to raise awareness among the people for the organ donations, the
healthcare professional can take part in the awareness campaigns. They can add
educational materials like the blogs, images or the video which encourage people. The

Page 99
DESIGN VIEWPOINTS
healthcare professional can also participate in community to support organ donations.
After this, they can exit the app.

Page 100
PLANNING OF PROJECT

6. PLANNING OF THE PROJECT

The Planning of the project is listed below:

PLANNING TABLE
DATE TASK

12.09.2024 Sign Up and Profile Management Modules should be completed.

19.09.2024 Donor and Patient Registry Modules should be completed.

26.09.2024 Search and Matching Modules should be completed.

03.10.2024 Logistics Coordination Module should be completed.

10.10.2024 Organ Donation and Monitoring Modules should be completed.

17.10.2024 Feedback and Support Module should be completed.

24.10.2024 Security and Compliance Checks should be completed.

31.10.2024 Compatibility of the entire system should be completed.

02.11.2024 Unit Testing should be done.

04.11.2024 System Testing should be done.

05.11.2024 System Release.

Page 101
 NED University of Engineering & Technology
Department of Software Engineering

SRS: LifeSavers Pakistan

Page 102
1. Introduction
1.1 Project Description

A simplified online platform called LifeSavers Pakistan was created to address

Pakistan's urgent requirements for organ and blood donation. The initiative includes a
website for public awareness-raising and resource provision, as well as a full mobile
app for donors, recipients, and healthcare providers. Donors can use the app to set
availability for particular organs or blood types, create and manage comprehensive
profiles, and verify their eligibility for donation. In order to enable prompt donations,
recipients can submit urgent requests, locate matches based on blood type, and get in
touch with donors directly.

In order to improve the efficiency of medical treatments that rely on blood or organ
donations, LifeSavers Pakistan provides healthcare practitioners with a centralized
registry to expedite patient-donor matching. To keep users updated on urgent
donation needs and impending eligibility for their next donation, the app additionally
offers analytics and real-time notifications.

In the meanwhile, the website acts as a gateway for users to peruse instructional
materials, discover the significance of being a member of the donor community, and
learn about the impact of gifts. The platform, which is run by an administrator, makes
sure that the public has access to the most recent information on donation centers and
awareness materials, creating a welcoming atmosphere for both donors and receivers.

1.2 Purpose

LifeSavers Pakistan is a simple and appropriate solution to the biggest problem of our country
where donors are far away from receivers, this app links donor with receiver in real time.
Some of the time medical procedures get delayed impacting the health care system and finally
patients too, because there is no comprehensive resources to support both blood donation and
cadaveric organ. LifeSavers Pakistan aims to close this bridge by creating a systematic,
accessible and organized network of help that facilitates donors in reaching the parties quickly
who need donations at healthcare providers end; on an endeavor level public awareness is also
generated for importance of donation. LifeSavers Pakistan envisions the country becoming
self-sustainable in lifesaving blood and organ donation by improving access to, availability of
safe and adequately screened products, as well as promoting a culture of responsible voluntary
non-remunerated donations.

1.3 Expected Functionalities

LifeSavers is a comprehensive donation management, awareness and accessibility solution for

Pakistan with the following characteristics:
Donor Registration and Profile Management: Donors can register with appropriate
information, create comprehensive profiles on their own along with availability update in the
system.
Donor Matching and Recipient Requests: Request donations can be posted by recipients, the
system matches them with potential donors based on blood type, organ needs and location.

Page 103
 Healthcare provider integration: provides a functionality where hospitals or clinics can look
into a main registry to make this matching and alert patients during an emergency,
Location-Based Donation Center Directory: Provides a list of donation centers in the vicinity
based on current location. Includes facility contact information and directions for donor
convenience
Alerts/Notification System: alerts to provide immediate support to the recipient, reminders
to available donor and important news updates.
Providing Educational Resources and Awareness Campaigns: The app includes a variety of
informational content that helps to raise public awareness and encourage the involvement of
communitites.
Interactive Data Analytics for Research: Provide healthcare providers and researchers with
report templates, as well as data visualization tools that allow them to grasp donation patterns
in order improve services.

1.4 Target Audience

Audience of LifeSavers Pakistan includes:

Donors: In other words one that wants to donate something such as blood, organs etc and help
people live a good life.
For patients and families: Individuals needing immediate access to blood, organ donors in
order to address critical medical needs.
Healthcare Providers: Hospitals, clinics and donor centers who need a constant influx of
donors to handle medical needs.
General public: desire to know more about donation and join a community that supports the
culture of life-saving giving.

5. System Features:

5.1 . User Registration and Profile Management:

5.1.1 Description
Users can register with various options, confirm their identification, and manage
personal information including health details and role-based because of this
functionality, which also allows user account creation, authentication, and profile
management. A safe and effective user onboarding process is supported by
administrators' ability to verify the veracity of user information.

5.1.2 Functional Requirements

1. Users should be able to register using their email, phone number, or social media accounts.
2. Multi-factor authentication should be employed to ensure secure login.
3. Users should be able to upload their health-related information such as blood type, organ
donation status, and their health history.
4. Users should also be able to upload their profile pictures.
5. Implement role-based access such as donor, recipient, and the administrator.
6. Implement registration for donor verification.
7. Users should also be able to update, view and delete their profile information.
8. Password recovery option should be available.
9. Notify users of profile changes via email or SMS.

Page 104
 10. The Admin should be able to verify these profile details.

5.1.3 Non-Functional Requirements

1. Ensure fast registration and login time, the registration process should take no more than 2
minutes.
2. The system must ensure data privacy and security, through encryption.
3. The system should provide the users with an interface that is easy to understand and use in
order to enhance user friendliness.
4. High reliability, with nearly 99.9% uptime for user management services.
5. The system should be scalable to accommodate a growing user base.

5.1.4. Domain Requirements

1. Role-based access, safe data storage, and identity verification requirements must all be met
during user registration. To stop unwanted access, encryption and multi-factor
authentication are necessary.

5.2. Logistics Coordination

5.2.1 Description
Transportation, scheduling, and delivery tracking for donations are handled by logistics
coordination. This tool streamlines delivery routes and guarantees effective logistics for
donation events with calendar support, ETA notifications, and connectivity with third-party
providers. Notifying users of logistics updates contributes to speedy and seamless contribution
procedures.

5.2.2 Functional Requirements

11. Calendar Support for Scheduling Donation Events.
12. Offer transportation help for donations
13. Display the delivery status and ETA of goods in transit.
14. Connect with third-party logistics providers for more comprehensive needs.
15. Stay updated with delay or schedule change notifications.
16. Turn on location based notifications near donors.
17. Optimize routing for multiple deliveries.

5.2.3 Non-Functional Requirements

6. The real-time system update on logistics should take not more than 5 seconds.
7. It should run efficiently at high loading times.
8. Ensure the app can handle peak traffic without delay.
9. Use of minimal data for real-time tracking updates.
10. The APIs used for location and mapping services should be reliable.
11. It should come out well when integrating with third party logistics.

5.2.4. Domain Requirements

2. Logistics feature should guarantee dependable, real-time data handling and adhere to
location-based privacy regulations. Accurate tracking and smooth coordination must be
supported by integration with third-party suppliers, particularly during busy periods.

Page 105
5.3. Matching of Organ
5.3.1. Description
The "Matching of Organ" feature is critical to the LifeSavers Pakistan, allowing users to find
matching organs for transplantation. It chooses appropriate organs by considering medical
criteria such as blood type, tissue compatibility, and urgency, increasing the possibility of
successful transplants and, ultimately, saving lives.

5.3.2. Functional Requirements

18. The app will match a donor’s organ with a recipient’s needs based on key factors, including
blood type, tissue compatibility, age, and organ type.
19. When a match is found, the app will notify both donors and recipients, providing clear and
complete information about the match.
20. The app will perform compatibility checks (like blood type and tissue matching) and
straightforwardly present the results to healthcare professionals.
21. The app will keep a record of organ matches and compatibility checks, so the healthcare
professional can review the matches and make decisions accurately.
22. The app shall prioritize matches based on the urgency of the recipient's condition.
23. The app will update the match status in real-time as new information comes in.

5.3.3. Non-Functional Requirements

12. The app must keep users’ personal and medical information safe by using encryption.
13. The compatibility checks should be conducted quickly, and the results need to be shown to
healthcare professionals without major delays.
14. The app should give priority to matches according to how urgent the recipient's condition
is, making sure that urgent cases are handled quickly and correctly.
15. It should quickly find matches for donors and recipients, ideally in just a few seconds.
16. The app must give real-time updates on the match status as new information comes in, so
users get the latest details to help them decide.

5.3.4. Domain Requirements

3. The System Coordinator is the primary stakeholder in charge of overseeing the organ
matching process. This includes overseeing compatibility checks, prioritizing cases based
on recipient urgency, and informing healthcare professionals of match details for further
action.

5.4. Organ Donation

5.4.1. Description
The “Organ Donation” feature allow user to easily sign-up as an organ donor, by simply filling
up a form, selecting which organ they want to donate, and share necessary health details to
ensure safe donation.

5.4.2. Functional Requirements

24. Users must fill out a form with their name, contact details and their medical history.
25. Users can choose specific organ which they wish to donate.
26. Users must provide their health information to determine their eligibility for the organ
donation.
27. The system will send a confirmation message to users once their donation request is
accepted.

Page 106
 28. Users can view, update, or delete their organ registration any time.
29. Users can check their registration status to see if they are listed as donor or not.
30. Users can withdraw their registration at any time.

5.4.3. Non-Functional Requirements

17. The system should have easy-to-use GUI, so the user can easily fill out the forms.
18. The system must be available 99.9% of the time so that users can donate whenever they
want.
19. The system should process actions like filling form and confirmation should be process
within 2 seconds.
20. Users should receive notifications and confirmation messages promptly, ideally within
seconds of their actions, to enhance their experience.
21. The user personal and medical information must be securely stored by using encryption.
22. The system should be able to handle lots of users and donations at the same time without
slowing down, so everything loads quickly and works well.
23. The system must ensure that the information entered by user is correct.

5.4.4. Domain Requirements

4. The system must follow all organ donation laws and regulations.
5. All medical and health information must be checked and approved by a doctor.

5.5 Preventing Illegal Organ Sales

5.5.1. Description
This feature prevents the illegal trading of organs on the LifeSavers Pakistan platform. It has
sophisticated detection algorithms monitoring and identifying anomalous user activity
patterns that might expose illegal trading. The Users can report suspicious activities of other
users whether donors or acceptors. The system responds by initializing an investigation on the
reported user and suspends their account if they are proved to be functioning again
international laws. This feature ensures ethical and legal organ donation for better security
and integrity of the platform.

5.5.3. Functional Requirements

31. The system will conduct an automatic follow-up on every user after a fixed time period
and will hence detect any suspicious or unusual behavior and transactions from any
particular user or users so as to negate illegal organ trading activities.
32. The system will give users a reporting tool to report any suspicious activities related to
illegal organ sales.
33. Upon receiving a report or detecting suspicious activity, the system will initiate an
automated investigation process to verify the suspected illegal activities.
34. Data and other related transaction records along with communication logs regarding this
suspicious illegal organ selling business activity will be collected in this system.
35. This system will ascertain the gravity of the dubious activities based on the analyses
made on the data collected.
36. Once the system receives sufficient evidence of dealing illegally, the users dealing in such
activities will be taken into action promptly
37. The system keeps the users involved in the illegal operations aware of which violation
they commit with all the consequences that follow along with them.

Page 107
 38. The system will withhold all transactions with the illegal activity doer or illegal dealer
and may in very dangerous cases suspend the account.
39. In the very severe cases, or as dictated by law, the system shall report illegal activities
performed to appropriate authorities for proper further investigation.
40. The system shall constantly monitor user activities and transactions to detect and
prevent the recurrence of illegal organ trading activities.

5.5.3. Non-Functional Requirements

24. The detection algorithm should be updated and improved constantly by new trends and
patterns about illegal organ trading.
25. The system should introduce preventive measures that can prevent illegal activity and
maintain the integrity of the site.

5.5.4. Domain Requirements

6. The system should be able to comply with local and international legal requirements on
organ donation and illegal organ trading.
7. The reporting suspicious activity tool should be available and easy to use.

5.6. Post-Surgery Support

5.6.1 Description
The feature allows the organ recipients complete resource and support in terms of help that is
provided post-surgery to aid them to regain complete recovery after the surgical operation.
The feature lets users apply for post-surgical medical assistance, post-op reminders,
medication timetables, and resources or get connected with support providers as well as the
available healthcare providers to support the recipient for recovery.

5.6.2. Functional Requirements

41. The system shall enable direct post-surgical medical help applications by the recipients
using the app.
42. The system shall enable post-surgical medical aid requests directly from the receiver
through the app.
43. The system will remind organ recipients on follow-up checkup appointments.
44. The system should remind them of their prescription of a medication schedule.
45. The system shall avail the recovery guidelines and tips to the organ recipients in a library
of support resources post-surgery.
46. The system shall enable organ recipients to receive contact with medical personnel
assistance/advice to their postsurgical recovery.
47. The system should keep a record of the checkup and medication adherence schedule of
the recipient and notify them whenever a checkup or a dose of medication is missed.
48. The system shall provide an interface that will enable the medical practitioners to update
the schedules for the recipients on follow-up visits and medication through the app itself.

5.6.3. Non-Functional Requirements

26. The system will remind organ recipients when it is time for their rehabilitation (if
needed) or time to take medicine.
27. The system interface should be intuitive and simple in nature so the recipients easily
understand how to request aid and see reminders.

Page 108
 28. The post-surgical supports need to be timely updated and verified by medically
acknowledged experts.

5.6.4. Domain Requirements

8. The system needs to guarantee the fulfillment of privacy as well as medical confidentiality
regulation to ensure that the medicine communication is encrypted.
9. Medical workers can view and update patients schedules to follow up after operation.

5.7. Donor and Recipient History Management

5.7.1. Description
For both donors and recipients, this feature makes it possible to maintain an extensive history
management system that records previous contributions and exchanges. While administrators
supervise and examine all logs, users can monitor and control their history. With notification
systems to inform users of changes to their historical data, this functionality guarantees
accountability, transparency, and error correction.

5.7.2. Functional Requirements

49. The system should record donor’s and recipient’s donation history.
50. The users should be able to view their history of interactions and also have access to
manage it whenever needed.
51. The system should monitor and control all interactions and transactions.
52. The system should notify the users about any updates in data history.
53. The system should allow the admin to review all history logs.
54. Users should be able to request their history be modified in the event of errors.

5.7.3. Non-Functional Requirements

29. Historical data retrieval should be less than 2 seconds.
30. Data should be stored securely and only available to authorized users.
31. System should periodically back up to avoid losing data.
32. The system should ensure real time data synchronization.

5.7.4. Domain Requirements

10. Laws governing the protection of health data must be followed by the system to provide
safe and approved access to historical data. All modifications should be documented in an
audit trail, and users must be able to ask for their records to be corrected.

5.8. Feedback and Support

5.8.1. Description
This feature makes it easier for people to ask for help, share their experiences, or make
comments. Users may swiftly resolve difficulties and rate service for ongoing improvement in a
responsive support environment created by live chat help, FAQs, and inquiry monitoring. User
happiness and confidence are increased when the status of help requests is transparent.

5.8.2. Functional Requirements

55. The users should be able to provide feedback and request support based on their
experiences.

Page 109
 56. Through Live chat support, Users must be given an option to sort their problems right then
and there.
57. Confirmation should be received when submitting feedback or support requests.
58. Each feedback or support response can be rated by users to increase the level of service.
59. There should be an FAQ section to answer common questions, reducing the load of queries.
60. Users should be able to track the progress of their submitted queries (for transparency).
61. Unresolved issues are flagged for admins to follow up, and the same is tracked with email
notifications.

5.8.3. Non-Functional Requirements

33. In order to enhance user satisfaction, Feedback and support should have a quick response
time.
34. The feedback form should be clear and easy to use, to minimize any errors at the time of
submission.
35. Feedback data should be securely handled to protect user privacy.
36. FAQs should be updated regularly to reflect common and emerging user issues.
37. There should be minimal delays in support communication to improve responsiveness.

5.8.4. Domain Requirements

11. Customer service standards should be followed when handling user comments and
support data. To increase customer satisfaction, frequently updated FAQs and real-time
help that prioritizes prompt, responsive assistance are essential.

5.9. Awareness Campaigns and Community Engagement

5.9.1. Description
Awareness Campaigns and Community Engagement module stimulates awareness about organ
donation by education campaigns and facilitates involvement between the users with their
society. It shares stories on social media that link social media with donations. Therefore, it
introduces forums between the donor and the recipients for community discussion.

5.9.2. Functional Requirements

62. The provision of educational campaigns on issues related to organ donation such as
videos, articles, and infographics should be established.
63. Users should be enabled to share success stories and conscious content about donation
through connected social media.
64. Users have the access to the forum in which donors and recipients can connect, share
their experiences, and help one another.
65. The system should engage the users in awareness programs through their own organ
donation stories or testimonials and thus can share them.
66. The statistics and the rates of success in terms of organ donations should appear on the
system to ensure increased participation in the campaigns among the users.
67. The system should be updating the users about campaigns, events, or any kind of
webinars coming ahead related to organ donation.
68. A subscription package will be provided so that users can stay tuned into the campaigns
to be held later on for further awareness of even more people.

5.9.3. Non-Functional Requirements

Page 110
 38. The user interface for shareable donation stories and informative campaigns should be
user friendly and accessible to all classes of users.
39. It shall integrate with popular media sites, thus allowing one to share content without
problems.
40. Community forum interactions should be monitored and moderated so that participants
respect and support one another.

5.9.4. Domain Requirements

12. The system must adhere to data privacy regulations so that any user-generated content
that is uploaded to forums or via social media should be treated securely and according to
the privacy policy.
13. Knowledge-locked content in awareness programs must also be professionally validated by
doctors and updated frequently for accuracy.

Page 111