COMSATS University Islamabad (CUI)

Software Design Description

(SDS DOCUMENT)

for

Express Charity

Version 1.0

By
Muhammad Qasim CIIT/FA19-BSE-033/ISB
Syed Aown Asghar Raza CIIT/FA19-BSE-014/ISB

Supervisor
Dr. Usman Yaseen

Bachelor of Science in Computer Science (2022-2023)

Software Design Description for Express Charity Page ii

Table of Contents
Revision History...........................................................................................................................iii
Application Evaluation History...................................................................................................iv
1. Introduction............................................................................................................................1
1.1 Modules.......................................................................................................................................1
2. Design Methodology and Software Process Model.............................................................3
3. System Overview....................................................................................................................3
3.1 Architectural Design....................................................................................................................3
4. Design Models........................................................................................................................5
4.1 Activity Diagrams........................................................................................................................5
15.2 State Transition Diagrams..........................................................................................................14
15.3 Data Flow Diagrams..................................................................................................................16
5. Data Design...........................................................................................................................20
5.1 Data Dictionary..........................................................................................................................20
6. Human Interface Design.....................................................................................................25
6.1 Screen Images............................................................................................................................25
6.2 Screen Objects and Actions.......................................................................................................32
7 Implementation....................................................................................................................35
7.1 Algorithm...................................................................................................................................35
Output: User logged into his.................................................................................................................36
1: for at.................................................................................................................................................36
7.2 External APIs/SDKs..................................................................................................................36
7.3 Deployment................................................................................................................................36
8. Testing and Evaluation........................................................................................................37
8.1 Unit Testing...............................................................................................................................37
8.2 Functional Testing.....................................................................................................................38
8.3 Integration Testing.....................................................................................................................38
9. References.............................................................................................................................40
Software Design Description for Express Charity Page iii

Revision History
Name Date Reason for changes Version
Software Design Description for Express Charity Page iv

Application Evaluation History

Comments (by committee) Action Taken

*include the ones given at scope time both in doc and
presentation

Supervised by
Supervisor’s Name

Signature______________
1. Introduction
Our project is an interactive tool that will not only allow donors to make donations in an easy
and responsive way but also focuses on providing the best loan and charity facilities to the needy
through beneficiary verification. The system ensures secure and effective donations through its
tracking and feedback system. Furthermore, the admins will have complete access to all the donations
and financial details of the organization. The admins will also have total control over all the charity
campaigns that are being displayed on the web and mobile applications. This freedom of control will
allow them to keep the website up to date. Audit reports, financial sheets, and donation analytics will
ensure the transparency of the organization with both the donors and the admins. 

The applications for donations will only be operational in Pakistan. Moreover, donations can only be
made through credit card payments and payments will be conducted using the Stripe API. There is no
blockchain-based solution for payment and donation verification will be added. The system will also
not be able to automatically validate the documents uploaded by a beneficiary, this task will be
performed manually by an admin. 

1.1 Modules

1.3.1 Module 1: Profile Management

FE-1: Allow new users to register onto the system.
FE-2: Allow already registered users to log in to the system.
FE-3: Display accurate user information and data which is in accordance with a users’ account data.

1.3.2 Module 2: Analytics

FE-1: Keep track of all the donations that have been made to the system and visualize the information
using graphs and reports.
FE-2: Generate user-specific graphs and reports for each donor.

1.3.3 Module 3: Beneficiary Verification

FE-1: Verify authenticity of a beneficiary through automatic and manual checks.
FE-2: Allow beneficiaries to upload documents for proof of claim.
FE-3: Perform automatic checks on uploaded documents using IR and OCR technologies.

1.3.4 Module 4: Social Media Integration

FE-1: Provide a news feed to users.
FE-2: Allow users to view comments from other social media platforms about our
system/organization.

1
 1.3.5 Module 5: Interactive Map
FE-1: Show an interactive SVG map showing donations distributed over the regions.
FE-2: Allow user to navigate to specific regional campaigns through the map.
FE-3: Allow exploration of sub-regions of the map with the use of a search bar.
FE-4: Show location of a campaign on click using the Google Maps API.

1.3.6 Module 6: Donor trails and categorization

FE-1: Keep a track record of all donations made by each donor.
FE-2: Show all donation details of each donor on their specific profile.
FE-3: Allow admins to categorize each donor into separate loyalty groups (Gold, Silver, Bronze).

1.3.7 Module 7: Charity and Debt Management

FE-1: Allow admins to create charity campaigns where donors can donate.
FE-2: Keep a record and display information of all the beneficiaries that have been provided with a
loan.
FE-3: Search and filtering options will be available for admins to sort through all beneficiaries that
have taken a loan.

1.3.8 Module 8: Financial sheets/ Audit report:

FE-1: Generate financial sheets and audit reports.
FE-2: The Financial sheet will contain information such as opening and closing balance, Credit and
Debit payments, and donation coverage.
FE-3: The Audit Report will be generated after each charity campaign has achieved its goal.

2
2. Design Methodology and Software Process Model
Design Methodology: Iterative

Rationale: Below are the reasons for choosing Iterative development approach.
1. Develop modules and features of the project incrementally and integrate with the system.
2. The project implementation can be tackled piece by piece instead of developing the entire
system. This greatly reduces development and error handling efforts and is more practical as
each small increment or functionality is tested for correctness before integration.
3. Different parts/modules of project require expertise in different skills. As an educational
project, incremental approach helps us to set deadlines for different tasks/modules based on the
size, complexity and effort required for the work.
4. With incremental approach, testing development of each module goes hand in hand, thus errors
are easier to remove and the integrated product is relatively free from error as the modules are
previously tested.

3.  System Overview

3.1 Architectural Design

A system architecture is the conceptual model that defines the behavior, structure, and views of a
system. An architecture description is a formal description and representation of a system, organized in
a way that supports reasoning about the behaviors and structures of the system. Express Charity will
follow hybrid architecture. As Express Charity is based on heavy user interaction so we will use MVC
design pattern at application level. Client architecture will have MVC (Model-View Controller)
pattern, which will communicate with server. It will have 2-tier architecture. Client (Web Application)
will send requests to read and write data on server. Application retrieve and send data to database
(Mongo DB). Furthermore, application will also communicate with database to send requests and get
responses.

3
Figure 1: Box and Line Diagram

4
Web
Application

Figure 2: System Architecture Diagram

5
4. Design Models

4.1 Activity Diagrams

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
15.1

15.1.1 User Authentication

6
Figure 3: Donor Login Activity Diagram

7
 Figure 16: Admin Login Activity Diagram

Figure 17: Beneficiary Login Activity Diagram

8
9
Figure 18: Beneficiary Verification Activity Diagram

15.1.2 Loan Management

10
Figure 19: Loan Management Activity Diagram

15.1.3 Campaign Management

11
Figure 20: Campaign Management Activity Diagram

15.1.4 Email System

12
Figure 21: Email System Activity Diagram

15.1.5 Make Donation

13
Figure 22: Make Donation Activity Diagram

15.1.6 Report Generation

14
 Figure 23: Generate Balance Sheet Activity Diagram

15.2 State Transition Diagrams

15
Figure 24: Application Analytics Transition Diagram

Figure 25: Online Payment Transition Diagram

16
15.3 Data Flow Diagrams

15.3.1 System Level Diagrams

Figure 4: Level 0 DFD

17
Figure 5: Level 1 DFD

Figure 6: Level 2 DFD

18
15.3.2 Functionality Wise Diagrams

Figure 29: Beneficiary Verification DFD

19
Figure 30: User Signup and Google Location DFD

Figure 31: View Report DFD

20
5. Data Design
Database: MongoDB.
The application uses the NoSQL database to store data for different data entities.

Major data entities used in the project include:

- General Campaign
- Specific Campaign
- Donation
- Donor
- Beneficiary
- Admin
- Loan
- Comment
- Audit

5.1 Data Dictionary

Data Entity Attribute Type Description

Admin Unique identifier as primary key in the
id ObjectId
database
name String Store name of the admin
Age Number Store age of the admin
String – Email
email Store admin email
format only
Store admin account password
password String – encrypted
contact String Store the contact information for the user
Store the location information for the
location Array<Number>
user as longitude and latitude.
Array<ObjectId> –
Specific Ref: Store reference to the specific campaigns
Campaigns SpecificCampaigns created by the Admin.
.id
Array<ObjectId> –
Specific
Ref: Store reference to the general campaigns
Campaigns
GeneralCampaigns. created by the Admin.
id
Store date and time when admin account
createdAt DateTime
was successfully created.
updatedAt DateTime Store date and time when admin account

21
 was successfully updated.

Data Entity Attribute Type Description

Unique identifier as primary key in the
id ObjectId
database
name String Store name of the Beneficiary
Age Number Store age of the Beneficiary
String – Email
email Store Beneficiary email
format only
Store Beneficiary
password String – encrypted account password

Array<ObjectId> –
Appealed
Ref: Store reference to the specific campaigns
Specific
Beneficiary SpecificCampaigns appealed by the Beneficiary.
Campaigns
.id
Appealed ObjectId – Ref: Store reference to Loans requested by the
Loans Loan.id beneficiary.
Store the longitude and latitude for the
location Array<Numbers>
beneficiary location
Account Object:
Store Account details for the beneficiary
Details AccountDetails
Store date and time when beneficiary
createdAt DateTime
account was successfully created.
Store date and time when beneficiary
updatedAt DateTime
account was successfully updated.

Data Entity Attribute Type Description

Donor Unique identifier as primary key in the
id ObjectId
database
name String Store name of the donor
Age Number Store age of the donor
String – Email
email Store donor email
format only
Store donor account password
password String – encrypted
Array<ObjectId> –
Donated
Ref: Store reference to the specific campaigns
Specific
SpecificCampaigns donated by the donor.
Campaigns
.id
Doanted Array<ObjectId> – Store reference to the general campaigns
General Ref: donated by the donor.
Campaigns GeneralCampaigns.
22
 id
Store the longitude and latitude for the
location Array<Numbers>
donor location
Account Object:
Store Account details for the Donor
Details AccountDetails
Store date and time when donor account
createdAt DateTime
was successfully created.
Store date and time when donor account
updatedAt DateTime was successfully updated.

Data Entity Attribute Type Description

Unique identifier as primary key in the
id ObjectId
database
Amount Number Amount donated by the donor
Store whether the given donation is a
isLoan Boolean
loan or not
ObjectId – Ref:
donor Store the reference of the donor
Donor
Donation
String: Enum
Store whether the donation is made to a
Campaign type [“Specific”,
specific campaign or a general campaign.
“General”]
Store date and time when beneficiary
createdAt DateTime
account was successfully created.
Store date and time when beneficiary
updatedAt DateTime
account was successfully updated.

Data Entity Attribute Type Description

Unique identifier as primary key in the
id ObjectId
database
text String The text or the comment body
Person String Name of the person who commented
Name of the platform where the
platform String
Comment comment was fetched from.
Store date and time when the comment
createdAt DateTime
was created.
Store date and time when comment was
updatedAt DateTime successfully updated.

Data Entity Attribute Type Description

Loan id ObjectId Unique identifier as primary key in the

23
 database
Loan Title String Store name of the campaign
description String Store the campaign description
Required
Number Store amount required by the campaign
Amount
Donated
Number Store amount donated to the campaign
Amount
Returned Store amount returned by the
Number
Amount beneficiary.
String: Enum
[‘Educational’, Store reference to the specific campaigns
Category
‘Medical’, ‘Family appealed by the Beneficiary.
Support’, …]
ObjectId – Ref: Store reference to the beneficiary who
Beneficiary
Benificiary.id requested the campaign.
Received Array<ObjectId> – Store references to all the donations
Loans Ref: Donation.Id made to the campaign.
Array<Object> - Stores information of loans returned by
Return Entries
{Amount, Date} the beneficiary.
Store whether the given loan is approved
Approved Boolean
or not?
Store whether the loan is completed or
Completed Boolean
not
Rejected Boolean Store whether the loan is rejected or not?
Store date and time when the loan was
createdAt DateTime
successfully created.
Store date and time when the loan was
updatedAt DateTime
successfully updated.

Data Entity Attribute Type Description

Unique identifier as primary key in the
id ObjectId
database
Campaign Title String Store name of the campaign
description String Store the campaign description
Required
Number Store amount required by the campaign
Amount
Donated
Specific Number Store amount donated to the campaign
Amount
Campaign
String: Enum
[‘Educational’, Store reference to the specific campaigns
Category
‘Medical’, appealed by the Beneficiary.
‘Support’, …]
ObjectId – Ref: Store reference to the beneficiary who
Beneficiary
Benificiary.id requested the campaign.
Donations Array<ObjectId> – Store references to all the donations

24
 Ref: Donation.Id made to the campaign.
Store whether the given campaign is
Approved Boolean
approved or not?
Store whether the campaign is completed
Completed Boolean
or not
Store whether the campaign is rejected or
Rejected Boolean
not?
Store date and time when the campaign
createdAt DateTime
was successfully created.
Store date and time when the campaign
updatedAt DateTime
was successfully updated.

Data Entity Attribute Type Description

Unique identifier as primary key in the
id ObjectId
database
Campaign Title String Store name of the campaign
description String Store the campaign description
Required
Number Store amount required by the campaign
Amount
Donated
Number Store amount donated to the campaign
Amount
String: Enum
[‘Educational’, Store reference to the specific campaigns
General Category
‘Medical’, appealed by the Beneficiary.
Campaign
‘Support’, …]
Array<ObjectId> – Store references to all the donations
Donations
Ref: Donation.Id made to the campaign.
Store whether the campaign is completed
Completed Boolean
or not
Store date and time when the campaign
createdAt DateTime
was successfully created.
Store date and time when the campaign
updatedAt DateTime was successfully updated.

Data Entity Attribute Type Description

Unique identifier as primary key in the
id ObjectId
database
Audit Title String Store name of the campaign
Audit Result Number Store the result of the audit
Audit
Audit Remarks Number Store Remarks for the audit.
Set the date by which the audit must be
Audit Due Date DateTime
completed
Campaign ObjectId – Ref: Store reference to the campaign for

25
 Campaign.id which the audit is done.
ObjectId – Ref: Store reference to the beneficiary who
Beneficiary
Benificiary.id requested the campaign.
ObjectId – Ref: Store references to all the donations
Auditor
Admin.Id made to the campaign.
Store whether the audit is completed or
Completed Boolean
not
ObjectId – Ref: Reference to the file uploaded by the
File
file.id admin.

Store date and time when the loan was

createdAt DateTime
successfully created.
Store date and time when the loan was
updatedAt DateTime
successfully updated.

6. Human Interface Design

6.1 Screen Images

Figure 32: Admin Dashboard

26
Figure 33: View Users

Figure 34: View Donations

27
Figure 35: View Recent Donations

Figure 36: Create Campaign

28
Figure 37: Analytical Graphs (Bar)

Figure 38: Analytical Graphs (Pie)

29
Figure 39: Analytical Graphs (Line)

Figure 40: Interactive Map

30
Figure 41: Login Screen

31
Figure 42: Register Screen

32
6.2 Screen Objects and Actions

Screen object Action

Login button refers to user logging in our web

application using their credentials

This forgot password refers to situation when the

user has forgotten their password and want to
recover it. This will take user to enter recovery
email screen.

This Register button refers when user wants to

sign up for our website. This will take them to
signup screen.

33
This Dashboard button is in admin panel, from
this button the admin can view all of the major
analytics and recent information.

The Users button is in the admin panel and lets

the admin view all of the registered users in the
system.

The Donation Info button allows the admin to

view donation information against each user. The
donation record shown here is the total amount
donated by each donor.

The Recent Donations button in the admin

dashboard allows the admin to view all of the
recently made donations to the system.

The Create Campaign button in the admin

dashboard allows the admin to enter information
in fields that will be used to create a campaign.

34
The Graphs button allows the admin to view all of
the donation related analytics and interact with
them.

The Geography Map button allows the admin to

view the interactive map of the world. This map
showcases the donations received from each
country.

35
1 Implementation

Chapter 1:

1.1 Algorithm
 
Algorithm 1: Create campaign 
Input: Campaign name, Description, Donation, file 
Output: Campaign is created. 
1:        if (fields not filled) 
2:         output ← Campaign not created 
3:         send response (401) 
2:        if (fields filled) 
3:                create(campaign) 
4:                output ← execute(campaign.save()) 
5:        send response (201) 
6:     end 
Algorithm 2 Appeal campaign 
Input: name, description, location, amount required 
Output: Campaign appeal request created 
1:         enter all the fields 
2:          if(required fields missing) 
3:                output← Appeal cannot be made 
4:          else{ 
5:                     Check if the data entered is correct 
6:             then add to database 
7:             Admin can view the campaign on his dashboard 
8:          Admin can then approve or reject the appeal} 
9:       end 
 
Algorithm 3: Make Donation 
Input: donation amount, campaign id 
Output: Money donated to campaign 
1:  press donate: 
2:  Stripe checks, verifies and processes the donation and returns a verification message. 
3:  if (donation successful) { 
4:   Create a donation entry and add donor id and amount to it. 
5: Push the donation reference in to the campaign where donated. 
6:   else  
7:          return response(“Donation failed”) 
8: end 
Algorithm 4: User registration 
Input: Email, Age, Address location, password  
Output:  User account gets created 
1: Enter registration fields 
2: If user with same email does not exist: 
3: If fields entered correctly: 
4: send a verification email to the user token 
5: User goes, and presses verify from his/her email 

36
6: User account gets registered 
7: else if filed not entered correctly: 
8: Send response => “Enter fields correctly” 
9: else if same email person exists: 
10: response -> “Email already registered, Sign In instead” 
Algorithm 5: User authentication 
Input: User email and password  Input: User email and password 
Output: User logged into his/her account  Output: User logged into his/her account 
1: for attempt=0; attemp < 3:  1: for attempt=0; attemp < 3: 
2: Input credentials  2: Input credentials 
3: Query database for user with the credentials   3: Query database for user with the credentials  
4: If the input credentials are correct(user matched)  4: If the input credentials are correct(user matched) 
5: display success message  5: display success message 
6: return -> Redirect user to his.her console  6: return -> Redirect user to his.her console 
7: else:  7: else: 
8: response -> “Incorrect credentials”  8: response -> “Incorrect credentials” 
8: retry signing in  8: retry signing in 
9: return -> Block user from any more attempts  9: return -> Block user from any more attempts 

1.2 External APIs/SDKs 

 
Table 2: Details of APIs used in the project 
Name of API and Description of API  Purpose of usage  List down the API
version  endpoint/function/class in which it is
used 
Stripe  Credit Card Sandbox used for the  
payment orders payment.  Donor/Donate 
integration 

Google Maps  Location services Location of donors and Admin/AnalyticsMap 

integration  beneficiaries for data Donor/AnalyticsMap 
  analytics.   
 
TensorFlow Implement Machine Make a ML model for Beneficiary/AppealCampaign/Verify 
Keras  Learning   beneficiary verification 
   

1.3 Deployment 
Currently, for development phase, our application is deployed on local machine. The Node Express
application is running at localhost:5000, whereas the frontend React server is running at
localhost:3000. The database used in Mongo DB, installed on the local machine and is running on
localhost:27017.  
 
When deploying the live app, the app shall run on Azure virtual Machine. Mongo DB atlas would be
used as cloud DB to store data and the backend and servers shall run on ports 5000 and 3000
respectively of the IP of the Azure Machine. 
37
8. Testing and Evaluation

Chapter 2:

Chapter 3:

8.1 Unit Testing

Unit Testing 1:   Login as Patient with valid and invalid credentials 
Testing Objective: To ensure the login form is working correctly with valid and invalid
credentials/inputs. 
 
No.  Test case/Test script   Attribute and value   Expected result   Result  
       
1  Check the email field of Email:  Validates email Pass 
  login to validate that it abc@gmail.com  address and
takes proper email  moves cursor to
next textbox 
2  Check the email field of Email:  Highlights field Pass 
login to validate that it abc.gmail.com  and displays error
displays error message.  message 
3  Check password to Password:  Error indicating Pass 
ensure it is not empty    password cannot
be empty. 
4  Check to see if password Password:   Error raised that Pass 
does not contain the Password123  password cannot
word ‘password’  contain
‘password’ 
5  Check to see if password Password:   Valid Password. Pass 
does not contain the lisa123  No error raised 
word ‘password’ 
6  User Signup with an Email:  Signup Pass 
email that does not exist Adam123@gmail.com  Successful 
in the database  Password: 
Adamlee123 
 
7    Email:  Signup not Pass 
User Signup with an Adam123@gmail.com  Successful 
email that does exist in Password:   
the database  Adamlee12345 
38
    
8  Request to get all URL: (Get)  All the campaigns Pass 
campaigns made from http://localhost:5000/campaigns/  stored in the
client software  database are
returned. 
9  Request to get all donors URL: (Get)  All the campaigns Pass 
made from client http://localhost:5000/donor/  stored in the
software  database are
  returned 
10  Change donor Password  URL: (Post) Password updated Pass 
http://localhost:5000/donor/:id/changepass to abc123 
word 
 
Password: 
abc123 

2.1

2.2 Functional Testing 

Functional testing will take place after the unit testing. In this functional testing, the functionality of
each of the modules is tested. This is to ensure that the system produced meets the specifications and
requirements. 
 
Functional Testing 1: Login with different roles (Management, Patient, Doctor)  
Objective: To ensure that the correct page with the correct navigation bar is loaded.   
 
 
No.  Test case/Test Attribute and value   Expected result   Actual result  Result  
script        
 
1.  Login as an Username: (correct username Admin JWT token No token created.  Fail 
“Admin”.   M003)   created and sent to  
  Password:   browser 
(Correct password 1234)    

2.  Login as a Username:incorrect  lamada323  User is prompted of the Login failed – Pass 
  ‘Donor’.   Password:   invalid email and/or invalid credentials  
  323lama  password and access is error 
denied.  
 
3  Login as Username: (correct username)   User logged in to the User logged into the Pass 
“Beneficiary”  Password:   system. User session is system. User session
39
 (Correct password)  created  created 

2.3 Integration Testing 

Integration tests assess whether a set of classes that must work together do so without error. They 
ensure that the interfaces and linkages between different parts of the system work properly. At this
point, the classes have passed their individual unit tests, so the focus now is on the flow of control
among the classes and on the data exchanged among them. Integration testing follows the same general
procedures as unit testing: The tester develops a test plan that has a series of tests, which, in turn, have
a test. Integration testing is often done by a set of programmers and/or systems analysts. 
 
Integration Testing 1:   Scheduling Patient Appointment 
Testing Objective: To ensure the scheduling is being done correctly and the interface between module
‘Patient/Doctor Management’ and module ‘Appointment/Scheduling’ is running correctly. 
 
 
No.  Test case/Test Attribute and value   Expected result   Actual result  Result  
script        
 
1.  Make Donate  Donation amount, Bank Money is transferred from Functionality not To be
account details, donor bank account to yet implemented or tested 
beneficiary details.  beneficiary's bank account.  tested   
   

2.  Approve Campaign request, Beneficiary campaign gets Functionality not To be

beneficiary Campaign status approved and is visible to yet implemented or tested 
Campaign.  verified.  donors for donation.  tested   
   
3  Audit Campaign  Completed campaign, Campaign is archived and Functionality not To be
  audit due date  an audit report for the yet implemented or tested. 
campaign is produced.  tested 
 
4  Generate Report filters,  A financial report is Functionality not To be
financial report.  Time duration  generated with respect to the yet implemented or tested. 
applied filters. Admin can tested 
reapply filters to modify  
results. Admin can
download the final report if
he wants. 
5  Give loan to Loan amount, Bank Money is transferred from Functionality not To be
beneficiary  account details, donor bank account to yet implemented or tested 
beneficiary details.  beneficiary's bank account. tested 
Beneficiary loan details are  
updated. 
 
6  Return Loan  Return amount, Bank Money is transferred from Functionality not To be
  account details, donor donor bank account to yet implemented or tested 
details.  beneficiary's bank account. tested   
  Beneficiary loan details are  

40
updated. 
 

41
9. References

[1] Wfp.org. 2022. Donate | World Food Programme. [online] Available at:

<https://www.wfp.org/support-us/stories/donate? 6 October 2022.

[2] Transparent Hands. 2022. About Us | How we work and Who we are | Transparent Hands. [online] Available at:
<https://www.transparenthands.org/about-us/> 7 October 2022.

[3] Edhi.org. 2022. Edhi Welfare Organization – Serving Humanity in the Spirit of All Religions. [online] Available
at: <https://edhi.org/> 7 October 2022.
[4] Software Requirements Engineering 3rd edition, Karl Wiegers and Joy Beatty [online pdf]
<https://books.google.com.pk/books/about/Software_Requirements.html?id=40lDmAEACAAJ&redir_esc=y>

10. Plagiarism Report

42
43