Final Project Report

Donate Medicine for Needy

Project Supervisor
[email protected]

Submitted By

S2002821F7

HASSAN JAVAID MC170202198

AQSA GHULAM RASOOL BC170202434

Software Projects & Research Section,

Department of Computer Sciences,
Virtual University of Pakistan

Page | 1
 CERTIFICATE

HASSAN JAVAID ,MC170202198

This is to certify that
AQSA GHULAM RASOOL, BC170202434 have worked on and
completed their Software Project at Software & Research Projects Section,
Department of Computer Sciences, Virtual University of Pakistan in partial
fulfillment of the requirement for the degree of BS in Computer Sciences under
my guidance and supervision.

In our opinion, it is satisfactory and up to the mark and therefore fulfills the
requirements of BS in Computer Sciences.

Supervisor / Internal Examiner

AMNA BIBI
Supervisor,
Software Projects & Research Section,
Department of Computer Sciences
Virtual University of Pakistan

___________________
(Signature)

External Examiner/Subject Specialist

<<External Supervisor Name>>

___________________
(Signature)

Accepted By:

_____________
(For office use)

EXORDIUM
Page | 2
 In the name of Allah, the Compassionate, the
Merciful.

Praise be to Allah, Lord of Creation,

The Compassionate, the Merciful,
King of Judgment-day!

You alone we worship, and to You alone we pray

for help,
Guide us to the straight path

The path of those who You have favored,

Not of those who have incurred Your wrath,

Nor of those who have gone astray.

Page | 3
 DEDICATION

I/We, hereby, declare that “No portion of the work referred to, in this project has been
submitted in support of an application for another degree or qualification of this or any
other university/institute or other institution of learning”. It is further declared that
this undergraduate project, neither as a whole nor as a part thereof has been
copied out from any sources, wherever references have been provided.

MEMBERS’ SIGNATURES

Page | 4
 ACKNOWLEDGEMENT

I would like to express my very great appreciation to Miss. Amna Bibi for his
valuable and constructive suggestions during the planning and development of
this project work. His willingness to give so generously has been very much
appreciated.
I would like to express my deepest appreciation to all those who provide us the
possibility to complete this report. A special gratitude we give to our final year
project Coordinator, Ms. Amna Bibi, whose contribution in stimulating
suggestions and encouragement, helped us to co-ordinate our project
especially in writing this report. 
We would also like to extend my thanks to the technician and lab assistants of
the Labs of the Computer Science department for their help in offering us the
resources in running program.
Finally, we wish to thank our parents for their support and encouragement
throughout our study.

Page | 5
 PREFACE
This basis for this research originally stemmed from my passion for
developing better methods of data storage and preservation. As the world
moves further into the digital age, generating vast amounts of data and
born digital content, there will be a greater need to access legacy materials
created with outdated technology. How will we access this content? It is
my passion not only finds out, but to develop tools to break down barriers
of accessibility for future generations.

In truth, I could not have achieved my current level of success without a

strong support group. First of all, my parents, who supported me with love
and understanding and secondly, my committee members, each of whom
has provided patient advice and guidance throughout the research process.
Thank you all for your unwavering support.

Page | 6
 TABLE OF CONTENTS

CHAPTER NO. 1
GATHERING & ANALYZING INFO...................................................10

1.1 INTRODUCTION
1.2 PURPOSE
1.3 SCOPE
1.4DEFINITIONS, ACRONYMS AND ABBREVIATIONS
1.5USE CASES AND USAGE SCENARIOS

1.5.1 Use Case Diagrams

1.5.2 Usage Scenarios
1.6SUPPLEMENTARY REQUIREMENTS
1.6.1 Usability
1.6.2 Reliability
1.6.3 Supportability
1.6.4 System Requirements

CHAPTER NO. 2
PLANNING THE PROJECT..............................................................11
2.1 INTRODUCTION
2.2 METHODOLOGY
AVAILABLE METHODOLOGIES
CHOSEN METHODOLOGY
REASONS FOR CHOSEN METHODOLOGY
WORK PLAN
PROJECT STRUCTURE
2.3.1 Team Structure
2.3.2 Project Schedule (Submission Calendar)

CHAPTER NO. 3
DESIGNING THE PROJECT............................................................12
3.1INTRODUCTION
3.2 PURPOSE
3.3SCOPE
DEFINITIONS, ACRONYMS AND ABBREVIATIONS
ARCHITECTURAL REPRESENTATION (ARCHITECTURE DIAGRAM)
DYNAMIC MODEL: SEQUENCE DIAGRAMS

Page | 7
 OBJECT MODEL/LOGICAL MODEL: CLASS DIAGRAM
DATABASE MODEL (DATABASE DIAGRAM)
GRAPHICAL USER INTERFACES

CHAPTER NO.4
DEVELOPMENT.............................................................................13
4.1 DEVELOPMENT PLAN (ARCHITECTURE DIAGRAM)

Page | 8
Page | 9
 CHAPTER 1
Gathering & Analyzing Info

1.1 INTRODUCTION

Page | 10
 The project team is going to develop a donate medicine for needy people. This
project will be a web application. This project will be based on Microsoft Visual Studio
(C#.Net) and SQL Server. The purpose of this project is to save the money and human
lives that are a big problem for poor people. As well as in this project, the project team
will take care of needy person’s records in system. Donate medicine for needy people
project will help to save the lives of people by donating the medicine to the time.

This medicine donation web application aims to donate medicines which are not used.
As we know that many companies’ medicines do not sellout and at the end they have to
waste it. But there are many of us who cannot buy medicines because of their costs.
Then poor people have to go to Govt. Hospitals for their cure and medicines. By using
this application the unused medicine can be donated for further utilization by a needy
person.

Around the world, people struggle to afford medication while drugs worth billions of
dollars go to waste. There isn’t detailed data on what happens to these unused drugs,
but anecdotal evidence suggests some are thrown in the trash or incinerated. There have
even been reports of medical facilities flushing unused medications down the toilet.
This drug donation system helps the user to donate un-used medicines to NGOs. With
the help of this application we can save the costs of medicines and also we can provide
the medicines to needy people. The medicines will be free of any cost. By using this
application we can save many lives as well.

1.2 PURPOSE
The purpose of this project is to save the money and human lives that are a big
problem for poor people. As well as in this project, the project team will take care of
needy person’s records in system. Donate medicine for needy people project will help
to save the lives of people by donating the medicine to the time.

This drug donation system helps the user to donate un-used medicines to NGOs. With
the help of this application we can save the costs of medicines and also we can provide
the medicines to needy people. The medicines will be free of any cost. By using this
application we can save many lives as well.

1.3SCOPE
This project is for needy people. Poor people can contact to the NGOs online
and can submit a request for the required medicine. Donate medicine for needy people
project will help to save the lives of people by donating the medicine to the time. This
drug donation system helps the user to donate un-used medicines to NGOs. With the
help of this application we can save the costs of medicines and also we can provide the
medicines to needy people. The medicines will be free of any cost. By using this
application we can save many lives as well.

1.4DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Page | 11
 1.5USE CASES AND USAGE SCENARIOS

1.5.1 Use Case Diagrams

1.5.2 Usage Scenarios

Page | 12
 Table 4.1: Login
Use Case Id: UC-01
Use Case Name: Login
Actors: NGO(Primary)
Admin(Primary)
Member(Primary)
Description: In this use case, user can login to account.
Trigger: User clicks on the Login button on the home page.
Preconditions: User must have registered account in which he’s logging in.
User must have internet connection.
Post conditions:  User successfully Login in the system.
 System will direct the user to his/her dashboard.
Normal Flow
User System
1. User will select the account I. System displays the drop down menu to select the
type. account type “Login as Student” or “Login as an
admin”.
II. System displays the login page.

2. User clicks on Login button.

3. User enters his email. III. System verifies that all the input fields are filled
4. User enters the password. out.
IV. System checks if account is created with given
Email.
V. System verifies password.
VI. System validates the data entered by user.
VII. System will direct user to his account homepage

Alternate Flow: 3a. In step 3 of normal flow user selects the account type “Register as a
Role”

1. User clicks on Login button.

2. User displays the drop down menu to select he account type “Login
as NGO” or “Login as an admin” or “Login as a Member”.
3. User will select the Login as member.
4. System displays the login page.
5. User enters his email.
6. User enters the password.
7. System verifies that all the input fields are filled out.
8. System checks if account is created with given email.
9. System verifies password.
10. System validates the data entered by user.
11. System will direct user to his account homepage.

Special
Requirements:
Assumptions:  User can understand the English language.
 Internet connection is available.
Notes and Issues: 1. Length of the password is greater than 5 digits that include
Page | 13
 numbers and characters.
2. All the input fields are mandatory to complete the sign up
process.
Table 4.2 Registration
Use Case Id: UC-02
Use Case Name: Registration
Actors: NGO(Primary)
Member(Primary)
Description: In this use case, user can create an account.
Trigger: User clicks on the sign-up/register button on the home page.
Preconditions: User must have internet connection.
Post conditions:  User successfully registered in the system.
 System will direct the user to his/her Login Page.
Normal Flow
NGO/Member System
1. System displays the sign-up/register page.
1. NGO/Member clicks on “sign-
up/register “button.
2. NGO/Member enters his/her Email
for account being created.
3. NGO/Member enters the password
that will be less than 20 and more
than 5 and it must contain numbers
and characters.
4. NGO/Member re-enter the password.
5. Student clicks the “Register” button.

2. System prompts options “Create

Account”.
3. System verifies that all the input fields are filled
out.
4. System checks the availability of email.
5. System validates both passwords to match them.
6. System validates the data entered by Student.
7. System stores the information.

8. System displays the message “Request has been

sent successfully”.

Special Security requirement

Requirements:
Assumptions:  User can understand the English language.
 Internet connection is available.
Notes and Issues: 1. Length of the password is greater than 5 digits that include
numbers and characters.
2. All the input fields are mandatory to complete the sign up
process.
Table 4.3 Logout

Page | 14
Use Case ID: UC-03

Use Case Name: Sign out

Actors: NGO(Primary)
Admin(Primary)
Member(Primary)
Description: In this use case, user can Logout from account.
Trigger: User clicks on the Sign out button on the dashboard.
Preconditions: User Should be logged in.
User must have internet connection.
Post conditions: 1. User successfully sign out from the system.
2. System will direct the user web site homepage.
Normal Flow

User System
1. User clicks on Sign out/Logout button.
2. System will direct user to web site home page. i. System will redirect user to website of the
home page.

Alternative Flows:

Includes:

Special Requirements:

Assumptions: a. User can understand the English language.

b. Internet connection is available.

Notes and Issues:

Table 4.4 Check Delivery Status

Use Case ID: UC-04

Use Case Name: Check Delivery Status

Actors: Member
Description: In this use case Member will view Delivery Status.
Trigger: Member clicks on the “View Delivery Status” button in his/her
account.
Preconditions: 1. Member is logged-in to the system.
2. Member must have internet connection.

Page | 15
Post conditions: Member will successfully view Delivery Status.
Normal Flow

Student System

1. Member clicks on “View Delivery Status i. System displays the delivery status page.
“button or link.
ii. System will show the delivery status of
2. Member will view the Delivery Status. medicines.

Alternative Flows:

Exceptions:

Table 4.5 Donate Medicine

Use Case Id: UC-05
Use Case Name: Donate Medicine
Actors: Member(Primary)
Description: In this use case, Member add medicine to donate for the NGO.
Trigger: User clicks on the Donate Medicine button on his/her dashboard.
Preconditions: User must have registered account in which he’s logging in.
User must have internet connection.
Post conditions:  User successfully Login in the system.
 System will direct the user to his/her dashboard.
Normal Flow
User System
1. Member clicks on “Donate Medicine
“option.  System displays the list of all the in which
user enter the details.

2. After that medicine details page are  System will show empty field and submit
appear user enter the medicine details button
like Medicine name, expire date,  System will send details to admin.
Quantity etc by default the Delivery
status is set to pending and click on
submit button.

Alternate Flow: 3a. In step 3 of normal flow Member selects “Donate Medicine” from
the options
1. System displays the detail of the form which include:
 Medicine Name.
 Expire Date.
 Quantity.
Include: UC-01, UC-02
Assumptions:  User can understand the English language.
 Internet connection is available.
Notes and Issues:

Page | 16
 Table 4.6 Update Information
Use Case ID: UC-06

Use Case Name: Update Information

Actors: NGO
Description: In this use case NGO update his information.
Trigger: NGO clicks on the “Profile” option then update profile button are visible.
Preconditions: 1. NGO is logged-in to the system.
2. NGO must have internet connection.
Post conditions: 1. NGO successfully update his information.
2. System will redirect the NGO to profile page.

Normal Flow

NGO System
1. NGO clicks on “Profile” button or link. i. System displays the Profile page with
update information button.

ii. System will provide text fields:

 Name.
 Address.
 Registration date.

2. Then on profile page the update profile

button are visible then click on button the
update page are visible user update the field
then click on save button and system will
redirect to profile page

iii. System will check the text fields.

iv. Save data to database.
Alternate Flow:

Includes: UC-01, UC-02

Special
Requirements:

Assumptions: 1 User can understand the English language.

2 Internet connection is available.

Page | 17
 Notes and Issues:

Table 4.7 Manage Stock

Use Case ID: UC-07

Use Case Name: Manage Stock

Actors: Admin
Description: In this use case Admin will manage the stock.
Trigger: Admin clicks on the “Stock” option
Preconditions:  Admin is logged-in to the system.
 Admin must have internet connection.
Post conditions:  Admin successfully Add the information.
 Admin successfully update the information.
 Admin successfully Delete the information.
 System will redirect the Admin to Index page.
Normal Flow

Admin System
1. Admin clicks “Stock” option. x. System displays the list of all the Stocks.
xi. Each stock row has “Update” and
“Delete” button and top of the add entry
button.
2. Admin will choose Stock row and click on
“Update” button. xii. System will redirect Admin to stock
update page which includes:
• Name.
• Quantity etc
xiii. Page has “Save Changes” button at
bottom.
xiv. System will check all the fields.
3. Admin will make changes in given fields.
Admin will click on “Save Changes”.

xv. System will update changes.

xvi. System will redirect to index page.

5. Admin will click on “Add stock” button and

the form are appear.
6. Admin will fill all these fields.
7. Admin will click on “Add” button. System will provide empty fields which
8. Each row has a delete button Admin click on include.
delete button which he want to delete and xvii. Name.
after the confirmation message are shown xviii. Quantity etc.
after it remove the database
xix. System will check the fields.
xx. Page has “Add” button at bottom.
xxi. System will check all the fields and data to

Page | 18
 database.

Alternate Flow: 4a. In step 3 of normal flow Admin selects “Delete” from the options

1. System will delete that Record.

Includes: UC-01, UC-02

Special
Requirements:

Assumptions: 3 User can understand the English language.

4 Internet connection is available.
Notes and Issues:

Table 4.8Manage Member

Use Case ID: UC-08

Use Case Name: Manage Member

Actors: Admin
Description: In this use case Admin will manage Member.
Trigger: Admin clicks on the “Manage Member” option
Preconditions:  Admin is logged-in to the system.
 Admin must have internet connection.
Post conditions:  Admin successfully Add new Member.
 Admin successfully update Member information.
 Admin successfully Delete Member information.
 System will redirect the Admin to Index page.
Normal Flow

Admin System
a. Admin clicks “Manage Member “option. i. System displays the list of all the member
record.
ii. Each member record row has “Update” and
“Delete “button and top of the add entry
b. Admin will choose Member and click on button.
“Update Information” button.
iii. System will redirect Admin to member
page update page which includes:
a. Name.
b. Address
c. Sex

Page | 19
 d. Date of birth etc
c. Admin will make changes in given fields.
iv. Page has “Save Changes” button at bottom.
d. Admin will click on “Save Changes”. v. System will check all the fields.

vi. System will update changes.

e. Admin will click on “Add Member “button and
vii. System will redirect to index page.
the form are appear.
f. Admin will fill all these fields.
g. Admin will click on “Add “button.
h. Each record has a delete button Admin click on
delete button which he want to delete and after
the confirmation message are shown after it a. System will provide empty fields
remove the database which include.
viii. Name.
ix. Sex
x. Date of Birth
xi. Phone Number etc.

xii. System will check the fields.

xiii. Page has “Add” button at bottom.
xiv. System will check all the fields and data to
database.

Alternate Flow: 4a. In step 3 of normal flow Admin selects “Delete” from the options

1. System will delete that Record.

Includes: UC-01, UC-02

Special
Requirements:

Assumptions: 5 User can understand the English language.

6 Internet connection is available.
Notes and Issues:

Table 4.9Update NGO Status

Use Case ID: UC-09

Use Case Name: Update NGO Status

Page | 20
Actors: Admin
Description: In this use case Admin update NGO Status.
Trigger: Admin clicks on the “New Registration Status” option then all new user
whose status is pending is shown then admin update it.
Preconditions: I.Admin is logged-in to the system.
II.Admin must have internet connection.
Post conditions: I.Admin successfully update NGO Status.

Normal Flow

NGO System
1. Admin clicks on “New Registration” button 1. System displays the list of new NGO
or link. registration.

2. The new NGO registration pages are

displayed then admin update the status.
2. Save data to database.

Alternate Flow:

Includes: UC-01, UC-02

Special
Requirements:

Assumptions: 1. Admin can understand the English language.

2. Internet connection is available.
Notes and Issues:

Table 4.10 Update Member Status

Use Case ID: UC-09

Use Case Name: Update Member Status

Page | 21
Actors: Admin
Description: In this use case Admin update Member Status.
Trigger: Admin clicks on the “New Member Registration” option then all new
user whose status is pending is shown then admin update it.
Preconditions: 1. Admin is logged-in to the system.
2. Admin must have internet connection.
Post conditions: 1. Admin successfully update Member Status.

Normal Flow

NGO System
I. Admin clicks on “New Member Registration” 1. System displays the list of new NGO
button or link. registration.

II. The new Member registration page are

displayed then admin update the status.
2. Save data to database.

Alternate Flow:

Includes: UC-01, UC-02

Special
Requirements:

Assumptions: 3. Admin can understand the English language.

4. Internet connection is available.
Notes and Issues:

1.6SUPPLEMENTARY REQUIREMENTS

1.6.1 Usability
Usability is the quality of a system that makes it useful in achieving a
user's goals, effective and easy to use, quick to learn, and like able, i.e.,

Page | 22
 subjectively pleasing to the user. Our Digital Academy is easy to use
and its user friendly.

1.6.2 Reliability
Application reliability is the probability of a piece of software
operating without failure while in a specified environment over a set
duration of time. In a perfect world, a reliable piece of software is
completely defect free, does not create downtime, and performs
correctly in every scenario.

1.6.3 Supportability
Customer Support uses registration page to help troubleshoot issues
with applications in this no need further installation just type url in the
brows

1.6.4 System Requirements

Mobile Phone or Computer
Internet

Page | 23
 CHAPTER 2
Planning the Project

II.1 INTRODUCTION
The application must be well designed to serve the needs of different users
and NGO. We providing them a platform to engage / interact with the
experience and best faculty for their appropriate domain. User and ngo see the
available medicine on the web application and register on it then apply for the

Page | 24
medicine. This platform can be run as a public service podium as well as for
pure business proposes.

2.2 METHODOLOGY

AVAILABLE METHODOLOGIES
CHOSEN METHODOLOGY
For making our software we adopted VU Process Model which is a
combination of waterfall and spiral models. The idea behind this model is that
to get the benefits of both these models. Essentially, Water Fall Model is a
framework for software development in which development proceeds
sequentially through a series of phases, starting with system requirements
analysis and leading up to product release and maintenance, whereas the key
characteristics of spiral model is risk management at regular stages in the
entire software development cycle. In VU Process Model we will be working in
phases to complete our given project.
Some of the phases are:
Requirement Analysis & Definition:
Risk analysis & Work Plan:
System Design
Implementation
Verification/Testing

REASONS FOR CHOSEN METHODOLOGY

Page | 25
WORK PLAN
PROJECT STRUCTURE

2.3.1 Team Structure

2.3.2 Project Schedule (Submission Calendar)

Task Name Start Date End date

Total estimate 13 May 2020 29 Sep 2020
SRS Document 13 May 2020 09 Jun 2020
Design Document 10 Jun 2020 20 July 2020
Test Phase 21 Jul 2020 30 Jul 2020
Final Deliverable 31 Jul 2020 29 Sep 2020

Page | 26
 CHAPTER 3
Designing the Project

Page | 27
3.1INTRODUCTION
A design document is a complete high-level solution to the problem
presented. It should be detailed enough that somebody who already
understands the problem could go out and code the project without
having to make any significant decisions.
This document will outline the software design and specification of
our workflow task management system in addition to system
architecture, system components, and software requirements as
agreed upon by the customer and the project team.
In this phase we’ll make the diagrams of the project, this will help to
a developer or any technical person who has the experience in
development to understand the flow of the project. We’ll make the
Entity Relation Diagram to understand the table and their relations
in database. Every diagram has its own purpose and definition.
Benefits of design document:
This keeps all team members on track during the project
development cycle. It is very difficult to keep focus to the point. But
design document helps team manager to keep the customer and

Page | 28
 development team on the track. When the design and development
team get buried in the details, it's beneficial to return to high-level
documentation to make sure every decision still aligns with the
larger vision for the product.
Design document is the recipe for replicating the good results of the
project. If the development team is getting stuck to any point in the
strategies then they can follow the design document to get rid from
the problem.

3.2 PURPOSE
The main purpose for creating such apps is to ensure best performance
for a mobile operating system as well as desktop computers. Smart
phones are becoming more preferred companions to users than
desktops or notebooks that’s why we create mobile responsive
application. Knowing that Smart phones are most popular, using Smart
phones to speed up the process of entering record and other stuff in the
system would save time of the users. This proposes a system that
based on an app, which is used by Admin, NGO and Member also.
3.3SCOPE
DEFINITIONS, ACRONYMS AND ABBREVIATIONS

ARCHITECTURAL REPRESENTATION (ARCHITECTURE DIAGRAM)

AN ARCHITECTURE DIAGRAM IS A GRAPHICAL REPRESENTATION OF A
SET OF CONCEPTS, WHICH ARE PART OF ARCHITECTURE, INCLUDING
THEIR PRINCIPLES, ELEMENTS AND COMPONENTS.

Page | 29
DYNAMIC MODEL: SEQUENCE DIAGRAMS
Sequence Diagrams are interaction diagrams that detail how
operations are carried out. They capture the interaction between
objects in the context of collaboration. Sequence Diagrams are time
focus and they show the order of the interaction visually by using
the vertical axis of the diagram to represent time what messages are
sent and when.

Page | 30
Member Registration

NGO Registration

Page | 31
Admin Login

Member Login

Page | 32
NGO Login

Manage NGO

Page | 33
 Manage Member

Check Delivery Status

Page | 34
Donate Medicine

Admin Logout

Page | 35
Member Logout

NGO Logout

Page | 36
OBJECT MODEL/LOGICAL MODEL: CLASS DIAGRAM

Page | 37
DATABASE MODEL (DATABASE DIAGRAM)

Page | 38
GRAPHICAL USER INTERFACES

Page | 39
Page | 40
 CHAPTER 4
Development

4.1 DEVELOPMENT PLAN (ARCHITECTURE DIAGRAM)

Page | 41
Page | 42
 REFERENCES

=> https://www.w3schools.com/
=>https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_filter_list
=>https://online.visual-paradigm.com/
=>https://sequencediagram.org/
=>https://codepen.io/
=>https://www.w3schools.com/tags/att_table_bgcolor.asp
=>https://w3layouts.com/

Page | 43
APPENDIX

Page | 44