NGO Management System Documentation PDF

RESEARCH PROJECT
NGO MANAGEMENT SYSTEM
1
2
DEDICATION
First of all I thanks to “ Almighty”, for everything that makes me possible to complete this project. I
dedicate this project to my parents, teachers because of their co-ordination, patience, understanding,
constant encouragement, support and guidance has given me the strength and knowledge to surpass all the
difficulties in life. Thank you for your in-finite helpful attitude on all the challenges for the completion of
this work.
3
ACKNOWLEDGEMENT
Starting in the Name of AlMIGHTY, the Most Beneficent, the Most Merciful.
This project is a result of dedicated effort. It gives me immense pleasure to prepare this project report on
“NGO MANAGEMENT SYSTEM”. I would like to thanks to our project supervisor to help and
constructive suggestions on the matter in this project. I would like to thank my parents and teachers who
have helped me in making this project successful.
4
PREFACE
This project attempt to bring under one cover the entire hard-work and dedication put in, by me, in the
completion of the project. And many thanks to Virtual University of Pakistan, where I learned how to do
research work. I hope this report will be beneficial for others in future.
5
TABLE OF CONTENTS
CHAPTER NO. 1
1.1 INTRODUCTION
1.2 PURPOSE
1.3 SCOPE
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
1.5 USE CASES AND USAGE SCENARIOS
1.5.1 Use Case Diagrams
1.5.2 Usage Scenarios

1.6 SUPPLEMENTARY REQUIREMENTS
1.6.1 Usability
1.6.2 Reliability
1.6.3 Supportability
1.6.4 System Requirements
CHAPTER NO. 2
PLANNING THE PROJECT........................................................................................21
2.1 INTRODUCTION
2.2 METHODOLOGY
2.3 AVAILABLE METHODOLOGIES
2.4 CHOSEN METHODOLOGY
2.5 REASONS FOR CHOSEN METHODOLOGY
2.6 WORK PLAN
2.7 PROJECT STRUCTURE
2.7.1 Team Structure
6
2.7.2 Project Schedule (Submission Calendar)
CHAPTER NO. 3
DESIGNING THE PROJECT........................................................................................28
3.1 INTRODUCTION
3.2 PURPOSE
3.3 SCOPE
3.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
3.5 ARCHITECTURAL REPRESENTATION (ARCHITECTURE DIAGRAM)
3.6 DYNAMIC MODEL: SEQUENCE DIAGRAMS
3.7 ENTITY RELATIONSHIP DIAGRAM
3.8 DATABASE MODEL (DATABASE DIAGRAM)
3.9 GRAPHICAL USER INTERFACES
CHAPTER NO.4
DEVELOPMENT...........................................................................................................44
4.1 DEVELOPMENT PLAN (ARCHITECTURE DIAGRAM)
7
CHAPTER 1
Gathering & Analyzing Info
8
1.1 INTRODUCTION:
It is a web-based application, which will keep record of all the users/companies by the maintaining
their accounts record separately and the web application will provide an immediate access to the user
through the proper login and logout functionality, whenever he/she wants to access the website to
perform any task. For example, he/she wants to donate money for charity purposes and the user can
also view his/her online records.
1.2 PURPOSE:
The purpose of software requirement specification is to define the overall structure of the application.
What is the use of application? What is the main functionality of the application? and how the user
will use it. We will make an online web-based application called “NGO MANAGEMENT
SYSTEM”. It is a desktop based application, which is used to provide the different secure features to
the users for their privacy. The “NGO MANAGEMENT SYSTEM” application will give an
opportunity to those people who want to donate their money, assets or want to work as voluntarily
(free of cost) online. In this phase, our purpose is gathering and analyzing information about the
project. In this phase, we identify the user and the using criteria.
1.3 SCOPE:
This project is very much helpful for those people who want to donate their money or any valuable
asset online without hesitation. This project application will create a proper mechanism where every
single user will have an opportunity to create their own account and perform their tasks and the users
will updated for their every single donation.
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS:

 SRS: Software Requirement Specification.
 NGOMS: Non-governmental Organization Management System.
 ERD: Entity Relationship Diagram.
 DBD: Database Diagram.
9
1.5 USE CASES AND UASGAE SCENARIOS:
1.5.1 Use Case Diagrams:
1.2
Not Successful
<<inclu
Generaliz de>> 1.1
ation 1.0 <<include>> 6.0
Use Registe Track
r r Successful Campaigns
<<includ
2.0 e>>
Login 8.0
7.0
Send Events
Confirme
d
3.0
Logout
Donor 9.0
Send Reminders
<<include>> 10.0
Send Batch Emails
4.0 11.0
Syste
Company Donation Import Record
m
Admi
<<inclu 4.1 12.0
<<include> de>> n
Successfu Track
>
l Donations
4.2
Not
Successful
5.0
Provide Services
Volunteer
10
1.5.2 Usage Scenarios:
Use Case Scenario
Use Case title Registration

Use Case Id NGOMS-Reg-1.0
Actors Donor/ Company /Volunteer/Administrator
Description This use case is used to register the user after providing all the
information to the registration form
by the user.
Alternative In case of any misfield the system shows an error to
Paths the user.
Pre Conditions User needs to fill the registration form to get the
benefits of a registered user.
Post After now, the registered user will be able to access all
Conditions the information available on the website.
Author S160246546 (BC110400325)
Exception Invalid Credentials/Database exceptions.
Modification Version 1.0
History
Use Case Scenario
Use Case title Successful <<include>>

Use Case Id NGOMS-Suc-1.1
Description The system shows the successful message to the
user, who registers in the website.
Alternative All actors are optional to cancel or use the go back
Paths option.
Pre Conditions User needs to be properly placed his or her
information to get the successful message.
Post Conditions After filling all required field and press the submit button without
any error, user will get successful
message.
Author S160246546 (BC110400325)
History
11
Use Case Scenario
Use Case title Not Successful <<include>>

Use Case Id NGOMS-NSuc-1.2
Description The system show the not successful message to the user, who
wants to register in the website but due to
some particular reasons got an error.
Paths option.
information to avoid the not successful message.
Post Conditions After filling all required field and press the submit button, user will
get not successful message due to
some database limitations etc.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Login

Use Case Id NGOMS-login-2.0
Description This use case performs necessary user authentication in order to
give access to the user to required
information.
Paths option.
Pre Conditions User need correct id and password in the system to
enter in his/her account.
Post Conditions After successfully login the donor, volunteer or administrator enter
his account and can perform any
task.
Author S160246546 (BC110400325)
History
12
Use Case Scenario
Use Case title Logout

Use Case Id NGOMS-logout-3.0
Description When any user donor, volunteer or administrator press logout
button the online system suddenly close the account and user
can’t use online system option
any more.
Paths option.
Pre Conditions For using logout option first you must login in your
account on online NGO management system.
Post Conditions After logout the donor, volunteer or administrator can’t use the
option of online NGO management
system and need to login again in his/her account.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Donation

Use Case Id NGOMS-Don-4.0
Description Any registered donor user will click on donation
button then enter into donor page for donation.
Paths option.
Pre Conditions Donor user need correct id and password for login in
the system.
Post After donor user login it will click on donation button.
Conditions
Author S160246546 (BC110400325)
History
13
Use Case Scenario
Use Case title Successful <<include>>

Use Case Id NGOMS-Suc-4.1
Description The system shows the successful message to the
user, when he/she will does any kind of donation.
Paths option.
information to get the successful message.
Post Conditions After filling all required field and press the submit button without
any error, user will get successful
message.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Not Successful <<include>>

Use Case Id NGOMS-NSuc-4.2
Description The system shows the not successful message to the user, when
he/she wants to donate in the website but
due to some particular reasons got an error.
Paths option.
information to avoid the not successful message.
Post Conditions After filling all required field and press the submit button, user will
get not successful message due to
some database limitations etc.
Author S160246546 (BC110400325)
History
14
Use Case Scenario
Use Case title Provide Services

Use Case Id NGOMS-PSer-5.0
Description Volunteer user after successfully login into the system, it will
provide any kind of free services for the NGO management
system for their social or
management improvement.
Paths option.
Pre Conditions User need to be properly placed his or her correct id and password
in order to login into the system after
registration.
Post The user will provide his or her free services without
Conditions any wages/salary.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Track Campaigns

Use Case Id NGOMS-TCam-6.0
Description This use case describes that system should be able to
track the fund raising campaigns from website.
Alternative N/A
Paths
Pre Conditions The system should be able to track different
fundraising campaigns from website.
Post This online fundraising track campaigns update the
Conditions online NGO management systems automatically.
Author S160246546 (BC110400325)
History
15
Use Case Scenario
Use Case title Confirmed

Use Case Id NGOMS-Con-7.0
Description The system sends the confirmation email to all
successful users.
Alternative N/A
Paths
information to get the confirmation email.
Post Wrong information provided by the user will lead to
Conditions the not successful message.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Send Events

Use Case Id NGOMS-SEve-8.0
Description This use case describes that how system sends invitation event like
fund raising program to all
regular donor users.
Alternative The system admin is optional to cancel event
Paths information or use the go back option.
Pre Conditions User need to make an online donation to get the
invitation events information.
Post The invitation events will update the registered users
Conditions about online system updates.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Send Reminders
16
Use Case Id NGOMS-SRem-9.0
Description This use case describes that system should remind
the user for scheduled tasks and appointments.
Alternative The system admin is optional to cancel reminder
Pre Conditions The user needs to have an account to receive
reminder emails.
Post The registered users get alert of reminder email on
Conditions scheduled basis.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Send Batch Emails

Use Case Id NGOMS-SBEma-10.0
send all emails in a batch to the user contacts.
Alternative The system admin is optional to cancel batch email
Pre Conditions The user needs to have an account to receive batch
emails.
Post The batch email sends to the registered user to their
Conditions contacts.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Import Record

Use Case Id NGOMS-IRec-11.0
Description This use case describes that system should be able to import the
17
registered users donation record and
online donations.
Alternative N/A
Paths
Pre Conditions The system should be able to import the user’s record
from the website.
Post This online imported record should be open easily
Conditions without giving an error.
Author S160246546 (BC110400325)
History
Use Case Scenario
Use Case title Track Donations

Use Case Id NGOMS-TDon-12.0
track the user donations from the website.
Alternative N/A
Paths
Pre Conditions The system should be able to track different users
from website.
Post This online web-system tracks all users from online
Conditions NGO management systems automatically.
Author S160246546 (BC110400325)
History
18
1.6 SUPPLEMENTARY REQUIREMENTS:
1.6.1 Usability:
The word usability means that user-centered approach for which effort required to learn,
operate, prepare input, and interpret output of a program. Both the design and development
process are focused around the prospective user — to make sure their goals, mental models,
and requirements are met — to build the features that are simple and much helpful for user
e.g. during registration to make their account, during session login or logout etc.
1.6.2 Reliability:
The extent to which a program can be expected to perform its intended function with required
precision, it means, the application should not take much consumption of time to load pages.
1.6.3 Supportability:
The web app system supports simple user interface with English language, which can be
easily understandable by everyone.
1.6.4 System Requirements:

1. Operating system : Windows 8/Windows 8.1/Windows 10
2. RAM : 512 MB/1GB
3. Processor : Pentium(R)Dual-core CPU or Above
19
CHAPTER 2
Planning the Project
20
2.1 INTRODUCTION:
Planning is the process of organizing tasks and activities to achieve the goals. In any web or software
development its means to set the activities like which methodology should be selected for developing
project , what should be the work plan of the project, what should be the structure of the
development team, who will perform the which task , Planning also contain the project time table or
schedule of the activities of project.
2.2 METHODOLOGY:
In software engineering, a software development methodology is a splitting of software development
work into distinct phases or stages containing activities with the intent of better planning and
management. It is often considered a subset of the systems development life cycle. The methodology
may include the pre- definition of specific deliverables and artifacts that are created and completed
by a project team to develop or maintain an application.
2.3 AVAILABLE METHODOLOGY:

a. THE WATERFALL PROCESS MODEL:
The waterfall model as it is clear from its name is a software development model in which
development is carried out as water flows progressively downwards. Different phases of project,
such as requirements analysis, design, implementation, testing, integration, and maintenance are
carried out in a predefined sequence. Thus, the waterfall model is also known as linear sequential
model, in which every next phase of the project is started after completion of the earlier phase. This
model is depicted in the following diagram.
21
Advantages of the Waterfall Model:
 Easy to understand and implement.
 It is easier to set schedule for the tasks to be completed within a specified time period.
 The other advantage of this model is that only after the work for a particular phase is over,
does the other phase start, due to which there is no overlapping of phases or the product does
not have to go through different iterative steps.
 This model is the easiest to implement in the eyes of most of the mangers, due to its linear
model. Since the processes of this model are carried out in linear manner, the cost of
resources is reduced to a large extent, which in turn helps in reducing the cost of the project
considerably.
 Lastly, the documentation and testing happens at the end of each phase, which helps in
maintaining the quality of the project.
Disadvantages of the Waterfall Model:

 Idealized, doesn’t match reality well.
 Difficult to integrate risk management.
 The problems with one phase are never solved completely during that phase and in fact many
problems arise after that phase is signed off.
 The partition in different phases is not quit flexible.
 As the requirements of the customer go on getting added to the list, not all the requirements
are fulfilled, this results in development of a newer version of the system; this increases the
cost of system development.
b. THE SPIRAL PROCESS MODEL:

The Spiral Process Model is a process which combines the iterative nature of prototype with the
linear nature waterfall model. The spiral model has four phases: Planning, Risk Analysis,
Engineering and Evaluation. The spiral model also caters risk management explicitly within software
development. Thus it is helpful to identify major risks of both technical and managerial nature and
how to avoid or minimize these risks to keep the software development process under control. In
Spiral Process Model the project life cycle is divided into phases, and each phase is executed in all of
the iteration of the Spiral Model. The diagram for this model is as given below:
22
Advantages of Spiral Process Model:
 High amount of risk analysis.
 Good for large and mission-critical projects.
 Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses,
because important issues are discovered earlier.
 It is more able to cope with the changes that software development generally entails.
 Working on the project gets started earlier, which is good to make a designer interested in the
project.
Disadvantages of Spiral Process Model:

 Highly custom-made limiting re-usability.
 Applied differently for each application.
 Risk of not meeting budget or schedule
 Doesn’t work well for smaller projects
2.4 CHOSEN METHODOLOGY:

The chosen Methodology for NGO Management System is VU Process Model. The VU process
model is combination of waterfall and spiral models. The waterfall model is a sequential design
process, in which every next phase of the project is started after completion of the earlier phase
where as the spiral model is helpful to identifying major risks of both technical and managerial
nature and how to avoid or minimize these risks to keep the software development process under
control. The VU Process model has properties of both process models such as sequential process
nature of waterfall model and risk management nature of spiral model.
23
Requirement Analysis
Planning Risk Analysis
Software requirement
specification and Costminimum
with Effectiveness
risk
work plan
Client Evaluation Development

Design
Project
qualitydelivery with
otherwise Designing coding
recycle again for Testing
further evaluation
Coding
Testing
Acceptance
2.5 REASONS FOR CHOSEN METHODOLOGY:

The reasons are due to which VU Process Model is preferred as a working methodology.
These are listed below:
 Due to no prior experience or expertise of such software project. As it is easy to revert back
to an earlier in VU model.
 It is also facilitate to take feedback from clients and incorporate changes needed accordingly.
 It facilitates performing risk analysis effectively to eliminate losses occurs due to doubtful
development models, resource requirements, project constraints, and time.
24
 The VU Process Model allows addition of product element at later stage when they become
available or recognized ensuring that there is no conflict between requirements and design.
 The VU Process Model facilitates early user involvement in the system development effort.
User's knowledge about the project rises as the project mature, so user can interface
effectively with management.
 This method is consistent with approaches that have multiple software builds and releases and
allows for making an orderly transition to a maintenance activity.
 The VU Process Model is suitable for projects with heavy user interfacing, such as
Production Rejection Assessment System (PRAS).
 The VU Process Model provides the flexibility to implement changes in design at several
stages of the project.
 The VU Process Model facilitates constriction of large systems in easy small segments.
2.6 WORK PLAN:
25
2.7 Project Structure:
2.7.1 Team Structure:
Team Structure
MUHAMMAD SALMAN BC110400325
Key Responsibilities
 Software Requirement Specification.

 Methodology and Work Plan.
 Preparation of Design Documents.
 Development.
 Preparation of Final Deliverables.
2.7.2 Project Schedule (Submission Calendar):
S.NO TITLE START DATE END DATE
01 SRS Document Wed 22 Jun, 2016 Mon 15 Aug, 2016

02 Design Document Tue 16 Aug, 2016 Fri 23 Sep, 2016
03 Final Deliverables Sat 24 Sep, 2016 Wed 25 Jan, 2017
26
CHAPTER 3
Designing the Project
27
3.1 INTRODUCTION:
The detailed study about different operations that are performed by a system and the relationship
between them within or outside of the system is called Analysis of a system or the given project. A
design document is a complete high-level solution to the problem presented. The design
documentation is in general for anyone who wants to understand the system architecture and design
of system. The goal of this document is to cover the high-level system architecture and design. 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. Further, if this somebody happens
to be an experienced coder, they should be able to use the design document to code the solution in a
few hours.
3.2 PURPOSE:
The main purpose of this design document is to analyze and understanding the system in detail. In
this way the features and constitute parts of at least feasible solution are identified and then
documented.
During design phase, the focus shifts from “what to how” i.e. in which we try to answer the
questions of how to build the system.
3.3 SCOPE:
The design activity provides a roadmap to progressively transform the requirements through a
number of stages into the final product by describing the structure of the system to be implemented.
It enables the user to organize IT requirements for a business and make the blue print of the software
that is built by the person to facilitate the business operations. This document describes in detail the
working of the system and its design related to the functional and Non- functional requirements. This
document also contains ERD, Architecture design of system Class Diagram, Database design,
Interface design and Test Cases of the software testing.
3.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS:

SRS: Software Requirement Specification.
NGOMS: Non-governmental Organization Management System. ERD: Entity
Relationship Diagram.
SD: Sequence Diagram.
ADD: Architecture Design Diagram. CD:
Class Diagram.
DD: Database Diagram.
28
3.5 ARCHITECTURAL REPRESENTATION (ARCHITECTURE DIAGRAM):
PRESENTATION LAYER
CLIENT (WEB-BROWSER)
INPUT FORM OUTPUT FORM
HTTP request HTTP

(Form Submit) response
BUSINESS LAYER
IMPLEMENT SYSTEM FUNCTIONALITY
WEB SERVER WEB SCRIPT

SQL (query) Result set
DATABASE LAYER
Database
Server
Database
29
3.6 DYNAMIC MODEL: SEQUENCE DIAGRAMS
1: User Registration (Donor/Volunteer/Company)
Case 1: (Normal flow for Registration)
User :RegistrationGUI :Database

open register page()
registration save donor

opened() informaton() process()
saved()
show message()
Case 2: (Exceptional flow for Registration)

open register page()
registration opened() save donor informaton()

process()
not saved()
show message()
30
2: User Login in Web (Donor/Volunteer/Company/Admin)
Case 1: (Normal flow for User Login)
Admin User :LoginInterface :Database :WebGU

I
enter ID and password()
login()
verification()
process()
verified()
open web GUI()
perform task()
perform task()
Case 2: (Exceptional flow for User Login)
Admin User :LoginInterf :Databa :WebGUI

ace se
enter ID and password()
login()
verification()
process()
not verified()
show message()
show message()
31
3: User Make Donation (Donor/Volunteer/Company)
UserAsDonor :UserAccount :Database :NGOM-

serAsDon :UserAccount :Database :NGOM-
System
System
open account()
process()
account opened()
add account detail()
add()
show message()
transfer amount()
process()
show message()
Transaction successful()
send email()
4: System Sends Invitation to Donors
Administrator :WebGUI :NGOM- :Donors

System
generate events()
send events detail()
update()
update successful() send invitation()

invitation received()
how message()
s
32
5: User Donate Things
UserAsDonor :UserAccount :Database :NGOM-

serAsDon :UserAccount :Database :NGOM-
System
System
open account()
process()
account opened()
add assets detail()
add()
show message()
transfer assets()
process()
show message() assets added

successful()
send email()
6: Volunteer User
UserAsVolunteer
UserAsVolunteer :UserAccount
:UserAccount :Database
:Database :NGOM-
:NGOM-
System
System
open account()
process()
account opened()
add volunteer detail()
add()
show message()
Detail added
successful()
send email()
33
7: System Allows Organization Donation
NGO :OrganizationLevel :WebGUI

M-
Syst
em
allow
donations() availability
possible() process()
show message()
8: System Sends Reminders & Appointments
:Database :Users
Admin
Admin :Database :Users
access user information()

process()
information available()
send reminders & batch emails()
update()
successfully send()
34
9: System Import Online Records
:Database
Admin
Admin :Database :WebGUI
access user information()

process()
information available()
import donations()
process()
successfully imported()
10: System Track Campaigns
NGOM-System :DifferentEvents :WebGUI
track()
forward()
process()
events found successfully()

show message()
35
11. Admin Manage Users
Admin :Users :Database

Admi :Users :Database
n
perform
CRUD manage users profile()
operation() process()
saved()
show message()
36
3.7 ENTITY RELATIONSHIP DIAGRAM
adminID adminNa password

me
usersDetail donationRecord
Administrator generate Events
WebDatabase
userID
registers
has UserName
email
NGOM System
has has User password
country
MailServer track Campaign fundRaisi

s ng contactInfo
UserTy
pe
donorID volunteerID
mailID sends donorReco volunteerReco
senderEm rd
Donor rd skills
ail donations
subject Volunteer
donate
Mails Company org_nam
s
e
message
receiverE mail
37
companyI D provide
Online
FreeServices
donationID donationDate donationStatus donationRecord
38
3.8 DATABASE MODEL (DATABASE DIAGRAM): WITH NON-IDENTIFYING
RELATIONSHIP TYPE
Campaigns Volunteer
PK Campaign_ID
PK
title Volunteer_ID
PK description Tangible
Events address
status title PK Tangible_ID
Events_I date descriptio
D user_email
n status item_name
FK1 Home_ID
date item_address
title
user_emai status
descriptio
l date
n address
user_email
FK status
1 date
user_emai
l
Home_I
D
Users
PK User_ID
Home Batch_email
Countries role:
PK PK batch_email_ID
Country_ID [Admin/User]
PK Home_ID
user_full_name
country_code title
user_email
country_name title description
Home_ID user_password
descriptio date
user_country
FK1 n image user_email
user_type
category user_phone_no
status
FK user_date
date Home_ID Bank_donation
1
user_emai
FK batch_email_I
l D
Reminder 2
s FK Reminder_ID
3
PK PK FK1 tion transaction_id

Reminder_ID amount currency
paypal_do
user_email
nation_ID
description User_ID
start_date_time
user_
end_date_time
Paypal_dona date
user_email
39
FK4 FK5 FK6 FK7 Events_I PK ban unt_title
D k_d account
Campaign ona _no
_ID tion iban_acc
Volunteer _ID ount_no.
_ID swift_c
Tangible b ode
_ID a currenc
n y_type
k amount
_ your_ba
n nk_nam
a e
m your_acc
e ount_titl
e
b your_acc
r ount_no.
FK1 a status
n d
c a
h t
_ e
c u
o s
d e
e r
_
b e
r m
a a
n i
c l
h U
_ s
a e
d r
d _
r I
e D
s
s
a
c
c
o
40
3.9 DATABASE MODEL (DATABASE DIAGRAM): WITH IDENTIFYING
RELATIONSHIP TYPE
Campaigns
PK
Volunteer
Campaign_ID
PK,F Home_I Tangible

PK
Events K1 D
Volunteer_ID PK Tangible_ID
PK title
descripti title
Events_ID on
PK,F Home_I address descripti item_name
K1 D status on item_address
date status status
user_emai date date
title
l user_emai user_emai
descripti
l l
on
address
status
date
user_emai
l
Users
Batch_email
PK User_ID
PK batch_email_ID
Home PK,FK1,FK4,F Home_ID
Countries
K5 PK,FK2 batch_email_I title
PK Country_ID PK Home_ID
PK,F D description
PK,FK1 Home_ID
title K3 Reminder_I date
country_code PK,F D
descripti user_email
country_name
on K4 Events_ID
image PK,F Campaign_
K5 ID Bank_donation
category
status PK,F Volunteer_I PK bank_donation_ID
date K6 D
PK,F Tangible_I
K7 D
role:
[Admin/User]
user_full_na
me
41
Reminders user_email user_email PK,F batch_email_ID
user_passwor K1 Campaign_ID
PK
d PK,F Events_ID
Reminder_ID
user_countr K1 Tangible_ID
y user_type PK,F Volunteer_ID
description
user_phone_n K1 User_ID
start_date_tim
o user_date PK,F Home_ID
e
K1 Reminder_ID
end_date_tim
PK,F
e
Paypal_donation K1 bank_nam
user_email
PK,F e
PK K1 branch_cod
PK,F e
paypal_donation_ID K1
PK,F
K1
PK,F Reminder_I branch_address
K1 D account_title
PK,F batch_email_I account_no
K1 D iban_account_no.
PK,F Campaign_I swift_code
K1 D currency_type
PK,F Events_ID amount
K1 Tangible_ID your_bank_name
PK,F Volunteer_I your_account_title
K1 D User_ID your_account_no.
PK,F Home_ID status
K1 date
PK,F user_email
user_date
K1 transaction_
PK,F id amount
K1 currency
user_email
42
3.9 GRAPHICAL USER INTERFACES
Dashboard of Admin Panel Screenshot 1
43
Send New Event of Admin Panel Screenshot 2
44
All Campaigns of Admin Panel Screenshot 3
45
CHAPTER 4
Development
46
REFERENCES
 Software Engineering-I (CS504)
 Software Engineering-II (CS605)
 Software Project Management (CS615)
 Web Design and Development (CS506)
 Database Management System (CS403)
47
APPENDIX
48

NGO Management System Documentation PDF

Uploaded by

Copyright:

Available Formats

NGO Management System Documentation PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NGO Management System Documentation PDF

Uploaded by

Copyright:

Available Formats

RESEARCH PROJECT

NGO MANAGEMENT SYSTEM

1.5.1 Use Case Diagrams

1.5.2 Usage Scenarios

1.6.4 System Requirements

2.7.1 Team Structure

1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS:

Use Case Scenario

Use Case title Registration

Use Case Scenario

Use Case title Successful <<include>>

Use Case title Not Successful <<include>>

Use Case Scenario

Use Case title Login

Use Case title Logout

Use Case Scenario

Use Case title Donation

Use Case title Successful <<include>>

Use Case Scenario

Use Case title Not Successful <<include>>

Use Case title Provide Services

Use Case Scenario

Use Case title Track Campaigns

Use Case title Confirmed

Use Case Scenario

Use Case title Send Events

Use Case Scenario

Use Case title Send Reminders

Use Case Scenario

Use Case title Send Batch Emails

Use Case Scenario

Use Case title Import Record

Use Case Scenario

Use Case title Track Donations

1.6.4 System Requirements:

2.3 AVAILABLE METHODOLOGY:

Disadvantages of the Waterfall Model:

b. THE SPIRAL PROCESS MODEL:

Disadvantages of Spiral Process Model:

2.4 CHOSEN METHODOLOGY:

Planning Risk Analysis

Client Evaluation Development

2.5 REASONS FOR CHOSEN METHODOLOGY:

2.6 WORK PLAN:

MUHAMMAD SALMAN BC110400325

 Software Requirement Specification.

2.7.2 Project Schedule (Submission Calendar):

S.NO TITLE START DATE END DATE

01 SRS Document Wed 22 Jun, 2016 Mon 15 Aug, 2016

3.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS:

INPUT FORM OUTPUT FORM

HTTP request HTTP

WEB SERVER WEB SCRIPT

User :RegistrationGUI :Database

open register page()

registration save donor

Case 2: (Exceptional flow for Registration)

User :RegistrationGUI :Database

open register page()