Session: 2020-2021

Department of Computer Science

Shaheed Sukhdev College of Business Studies
University of Delhi

DISASTER MANAGEMENT PORTAL

SOFTWARE ENGINEERING PROJECT REPORT
(CSHP - 410)

Submitted By: Supervisor:

Hari Om Mishra (19513) Ms. Kavita Rastogi
Pratyush Srijan (19518) Associate Professor
Ishan Soni (19532) SSCBS, DU
 P age |2

1. Problem Statement………………………………………………………3
2. Process Model…………………………………………………………… 3
3. Software Requirement Specifications…………………………………. 3
3.1 Introduction……………………………………………………..….3
3.1.1 Purpose……………………………………………………….4
3.1.2 Scope………………………………………………………….4
3.1.3 Definitions and Abbreviations………………………………. 4
3.1.4 Overview……………………………………………………...4
3.1.5 References…………………………………………………….5
3.2 Overall Description…………………………………………………5
3.2.1 Product Functions…………………………………………… 5
3.2.2 User Characteristics…………………………………………. 6
3.2.3 General Constraints………………………………….……… 6
3.2.4 Assumptions and Dependencies…………………….……… 6
3.3 External Interface Requirements………………………….………6
3.3.1 User Interfaces………………………………………..………6
3.3.2 Hardware Interfaces…………………………………..……..10
3.3.3 Software Interfaces…………………………………..…….. 10
3.3.4 Communications Interfaces………………………….…….. 10
3.4 Functional Requirements…………………………………....……..11
3.5 Design Constraints…………………………………………. ……..19
3.6 Data Flow Diagrams……………………………………………….20
4. Estimations………………………………………………………..……. 28
4.1 Function Point……………………………………………………..28
4.2 Cost and Effort…………………………………………………….29
5. Scheduling……………………………………………………….. …….30
6. Risk Management……………………………………………………….31
7. Use Case Diagram and Description………………………………. ……33
8. Database Design…………………………………………………...…...39
9. Coding…………………………………………………………………...41
10. Control Flow Graph…………………………………………………….43
11. Cyclomatic Complexity…………………………………………………44
12. Boundary Value Analysis………………………………………………. 45
 P age |3

1. PROBLEM STATEMENT
In India, every year due to our varied terrain and landscapes different types of disaster
occurs because of which millions of people are affected. For ex. The floods that ravage
our country every year causes people to relocate to places which causes them a
tremendous amount of trouble. There is very less information among people related to
these disasters and they are still unknown about the methods through which they can
help other people and also put forward their complaints to the authorities.
Our aim with the help of this portal is to assimilate all the resources that we have at one
place (all the Gov. as well as private Sector) and then help the people provide them
with these at the time of their need like money, shelter. With this portal, we provide
people a complete interface which will help them in dealing with the disasters in a more
efficient and less devastating manner. Altogether, this portal will be state-of-the-art
mechanism making it near impossible to leave even the slightest of the matters related
to managing of the disasters.

2. PROCESS MODEL
The model chosen for our project is Incremental Model. This model is more flexible –
less costly to change scope and requirements. The project size is moderate and the
core requirements of the system are well known and there is no ambiguity in them. It is
easier to manage risk because risky pieces are identified and handled. This model is
chosen because the software engineering team is not very well skilled or trained, and
thus the Incremental Model would help to manage planning technical risks. With the
help of incremental model, the Web applications are developed in an easy and efficient
manner and the reusable components of web applications.

3. SOFTWARE REQUIREMENT SPECIFICATION (SRS)

3.1. INTRODUCTION
The Disaster Management portal will mitigate the damage and destruction caused by
natural and man-made disasters, through sustained and collective efforts of all
Government agencies, Non-Governmental Organizations and People’s participation.
This is planned to be accomplished by adopting a Technology-Driven, Pro-Active, Multi-
Hazard and Multi-Sectoral strategy for building a Safer, Disaster Resilient and Dynamic
India. The portal will serve as the one stop destination for everything ranging from
spreading awareness about the mitigation of the disaster to the telling the people
about the policies and planning of the government to arranging the funding for various
emergency actions by the workforce (NDRF and others). We will also conduct various
Workshops/Seminars in various colleges and schools.
 P age |4

3.1.1 Purpose:
Our aim with the help of this portal is to assimilate all the resources that we have at one
place (all the Gov. as well as private Sector) and then help the people provide them
with these at the time of their need like money, shelter. With this portal, we provide
people a complete interface which will help them in dealing with the disasters in a more
efficient and less devastating manner. This portal also aims to keep tabs on all the
prediction and monitoring activities of the various agencies and to collab with them
from time to time in order to take necessary precautions to minimise the effects of the
upcoming disaster.

3.1.2 Scope:
This system will allow users to get the descriptive details of NDRF, SDRF, Civil Defence
and Fire Services and the activities undertaken by them like Training, Operations
conducted by them, conducting Workshops/Seminars, etc. Likewise, the users will get
to register themselves by providing necessary details for the exams conducted for the
induction into the Workforce. It also contains alerts hub which will function to predict
the upcoming disasters and disseminate warning messages to people. It also provides
individuals as well as organisations to donate in the disaster funds. Also, there will be
grievance section to register the complaints, Get Help section to contact us through e-
mail, chat or through complaint form, the sole purpose of this section will be to act as a
direct link between the complainant and the admin for faster redressal of the
grievance. Resources section that will contain the details about Annual Reports, Case
Studies and Awareness information related to disasters.

3.1.3 Definition and Abbreviation:

NDRF: National Disaster Response Force
SDRF: State Disaster Response Force
3.1.4 Overview:
Once the user lands on our system, he/she will be able to:
 Know about a Basic Description of how the Force (NDRF, SDRF) functions and
other details about its conception.
 Register to workshops by providing details after which E-Invite containing details
of the workshop will be sent to respective e-mail and Phone No.
 Conduct workshops to spread awareness about different disasters.
 Get Latest News and Circulars about the Force.
 P age |5

 Access various Training activities undertaken by the Force

 Access the list of all Honours or Awards awarded for extraordinary bravery
 Register to upcoming exams available and view or print the admit card.
 Fetch the details of weather reports and anomalies and prediction of upcoming
disaster
 Receive warning messages via SMS in case of upcoming disaster
 Donate in the Disaster funds and print its receipt
 Register the complaint in the time of specific disaster and can track its progress
 Analyse Study Reports and Case Studies of disaster that took place in the past

3.1.5 References:

 SOFTWARE ENGINEERING, A PRACTITIONER'S APPROACH

-By Roger S. Pressman
 AN INTEGRATED APPROACH TO SOFTWARE ENGINEERING
-By Pankaj Jalote

3.2. OVERALL DESCRIPTION

3.2.1 Product Function: The Functions of our software include:

 An Examination Module where the users (mainly Registrants for an Exam) will be
able to register for an upcoming exam and also print the admit cards for that
exam.
 Donation Module which does various tasks from making a donation (either
individually or by an organisation) to handling specific problems which the user
may face while making a donation (like payment failure)
 Workshop Module which will act as a host for the registration for a workshop
and also for generating e-invites.
 A Get Help Module to provide ease to users in registering complains and asking
queries
 An Employee Login Module which provides a platform to Employees who can
keep their records updated and apply for leave with a single click.
 Weather prediction platform which will display the weather information for any
part of the country requested and also if there are any critical conditions.
 P age |6

3.2.2 User Characteristics:

 Users: The entity User will have privileges to access nearly everything in front-
end in our system and can also register for some special purposes like e.g.
applying for exams, filing complaints, donation for specific disaster, attending
workshops.
 Employee: The entity Employee will login to the portal and check their profile
and apply for leave.
 Admin: There will be an administrator who will maintain and handle the
software and resolve all queries of public.

3.2.3 General Constraint:

 This portal will be only available in English.
 This portal may behave inappropriately in Internet Explorer 9 or previous
version.

3.2.4 Assumption & Dependencies:

 All facilities will be available 24*7 online.
 Users should be connected to the internet to access the system.
 Budget availability: The determined budget is accurate and covers all project
expenses.
 Human resource availability: All key project team members are available and have
the necessary skills and knowledge to work on the project.
 There might be a delay in receiving the funds from the prospective client because
of which lies the risk of Budget Deficiency.

3.3. External Interface Requirements:

3.3.1 User Interface:

UI Screens are:
Examination Registration Portal: - Displaying all the upcoming exams
for recruitment. Also, an HTML based form to enter details for
printing the Admit card.
 P age |7

Employee Login Portal: - HTML or PHP based login portal to login

employee by taking necessary login details

Donation Portal: - Displaying all the information related to donation including

buttons for printing receipts and registering grievances.
 P age |8

Workshop Portal: - Displaying the details of the Upcoming Workshops with

options to search for a workshop, getting your E-Certificate and also Conducting
a Workshop.

Get-Help Portal: Options for Tracking your Application for Complaint as well a
Chatbot for instant replies to issues. Also, a HTML based for registering a new
complaint with details of the User.
P age |9
 P a g e | 10

Weather Alerts Portal: Displaying hyperlinks for Various Individual Weather

Conditions Display.

3.3.2 Hardware Interface:

Operating System: Windows and UNIX based/Android
Processor: Intel i3 or above
RAM: 2GB or above
Hard Disk: 128GB or above

3.3.3 Software Interface:

HTML, PHP, JAVASCRIPT, CSS, MYSQL

3.3.4 Communication Interface:

E-mail, Chat Box
 P a g e | 11

3.4. Functional Requirements:

The Functions of our software include:

 An Examination Module
 Donation Module
 Workshop Module.
 A Get Help Module
 An Employee Login Module
 Weather prediction Module

3.4.1 Examination module

 It will display the list of all the upcoming exams available, with their exam
code, Exam name, Year, Date of exam, Closing date for forms, Part 1
Registration (with a register button).
On clicking on register for Part 1, a page will be opened containing all
the instructions for filling up the application form and after that, we
will be directed to the details page.

Step 1: Registration: All the personal details to be filled

Step 2: Photo, Sign and Photo Identity Card upload.
Step 3: Centre selection and Agreeing to declaration.
Step 4: Payment gateway.

On successful submission of the form, a verification mail along with

the complete form will be sent to the respective mail id containing the
Registration ID.

 On entering the registration ID, DOB and Captcha, you will be able to see your
application and an option for print admit card will be available 15-20 days prior
to the exam.
 P a g e | 12

COMPLETED REGISTRATION FORM

APPLICATION NUMBER/REGISTRATION ID:

PERSONAL DETAILS

Candidate’s Name: Date of Birth:

Mother’s Name: Category:

Father’s Name: Gender:

PwD: State of Eligibility:

CENTRE DETAILS

Exam City 1st Exam City 2nd

Exam City 3rd Exam City 4th

CONTACT DETAILS

Address: Locality:

City: District:

State/ UT: Pin Code:

Email Address: Mobile No.:

FEE PAYMENT DETAILS

Payment mode: Transaction ID:

Exam fee: Date of Transaction:

IMAGES UPLOADED BY CANDIDATE

Photograph Signature
 P a g e | 13

ADMIT CARD

Roll Number: Registration number: Photograph

Candidate’s name: Father’s Name:

Gender: Date of Birth:

Category: State of Eligibility:

Person with Disability: Scribe:

(PwD)

Candidate’s
Signature:

TEST DETAILS
Question Paper Medium:

Paper Name:

Date of Examination:

Shift:

Reporting Time:

Timing of Test:

Test Centre No.:

Venue of Test:

3.4.2 Donation module

 Donate as an Individual

Choose Payment type (Domestic/International), Name, Email- ID, Mobile No.,

Donation amount in INR, Checkboxes (Agreement to Communications and Terms
and Conditions), Verification through Captcha, Submit these details.
After Successful Submission of the above Details, Payment Portal Opens up -
Payer Name, Details, Submission -> Payment Gateway opens -> Proceed with
Payment.
 P a g e | 14

On Successful Payment: Display Name, Current System/Server Time, Date, Token

No., Print Receipt.

 Donate as a group:

After the registration, the Organisation will login with their Username and
Password and can add their Member details: (Name, Employee ID, Ph. Number,
email ID) and amount received from them
After entering all the member details, Organisation can pay online the amount as
a single transaction
After successful transaction, organisation can login and print receipt containing
list of all the members who has donated.
Receipt will be sent to all the members via the E-Mail and WhatsApp

 Print Receipt: Input your details such as E-Mail, Token Number and Donated
Amount to search and print the receipt

INDIVIDUAL DONATION RECEIPT

Receipt No.

Donated By:

Street Address:

City: State: Pincode:

Date of Donation:

Donation Value:

Description of donation:

Authorized signature:

Thank you for your generosity. We appreciate your support!

 P a g e | 15

ORGANIZATION DONATION RECEIPT FORMAT

Receipt No.

Organization Donated By:

Address
Website Street Address:
email
Tax ID ########## City: State: Pincode:

Date of Donation:

Donation Value:

Description of donation:

Authorized signature:

Thank you for your generosity. We appreciate your support!

 Grievances

Register your Complaint:

o Complaint Registration Form: Enter Payment Mode, Transaction ID,

Amount, Complaint Description, Details of the Donor(Name, Email-ID,
Mobile No.), Details of Complaint(if any)
o On Successful Submission of the Above Form a Token No. Will be
generated.

Track your Complaint: Dialogue box opens in which enter your Token No. And
submit to track the status of your complaint token.
 P a g e | 16

3.4.3 Workshop module

 Conduct a workshop/seminar
o For all the schools, colleges and coaching institutions.
 The institution will get themselves registered on the website
and give details of the workshop they want to conduct: -
o Organisation Name
o Contact details
o Number of attendees(expected)
o Address
o Date and Mode of workshop(online/offline)
o Theme of the workshop

GENERATED WORKSHOP DETAILS FOR CONDUCTING ORGANISATION

Generated on:

XX/XX/20XX

ISSUED ON BEHALF OF:

NATIONAL DISASTER MANAGEMENT AUTHORITY

DATE OF WORKSHOP: ________________________ MODE: _______________________________________

WORKSHOP ON: ____________________________________________________________________________

ORGANISATION NAME: ______________________________________________________________________

VENUE: ___________________________________________________________________________________

__________________________________________________________________________________________

EXPECTED FOOTFALL: _______________________________________________________________________

ORGANISATION EMAIL: ____________________________ PH. NO.: __________________________________

PLACE:
AUTORISED SIGNATORY:
_____________________
_____________________
 P a g e | 17

Certificate of Participation
This certificate is awarded to
Mr./Mrs. Abc Xyz
in recognition of his/her participation in training workshop entitled
Strengthening National Response Capabilities that was held at Tomar Hospitality,
New Delhi - 110005 during 07-11 June, 2021
National Disaster Management Authority
(a govt. of India initiative)

 Get your e-certificate: Upload all the necessary documents and an e-

certificate will be generated for that particular institution.

 Apply for workshop/seminar

o The user is required to enter the basic details like State, City, Pin code
and click on search.
o A list of all the available workshops in that particular city will be
displayed with a REGISTER button besides all of them.
o After clicking on Register, a form of personal details will be opened and
on successful submission of the form, an e-invite will be sent via
email/WhatsApp and the database will be updated.

E-INVITE

National Disaster Management Authority Where 17 A/2 w.e.a Karol Bagh, Basement Hotel,
SPB 87, near Metro Pillar 98, New Delhi-
cordially invites you to join the 110005

Workshop When xx/xx/20xx, 12:00 PM onwards

on RSVP ABC XYZ through Mobile +91-

XXXXXXXXXX until xx/xx/20xx
Strengthening National Response Capabilities
 P a g e | 18

3.4.4 Get Help module

 Fill a complaint form

After filling this form containing all the personal details (Name, Phone no.,
State, City, Pin code, Address) along with the type of complaint and the type
of disaster, a token code will be generated.
This complaint will be looked upon by the concerned person and will revert
back as soon as possible.
An option for Track My Application will be given where the user can enter
their token code and track the status of their complaint.

 Chat with us:

Here an option will be given to the user in which his/her queries will be
addressed by a specialist.

 Contact with us
Telephone number, email id and address will be given in this section for any
other Complaints or queries.

3.4.5 Employee Login module

 Employee Corner: This particular sub-section is meant for the ease of access
for the employees of the Force. On visiting this section, the employees will
be able to login using their User-Id and Password (also verifying through a
captcha code).

After Successful Log-In: Name, Date of Birth, Date of Joining, PF

Details, Number of Leaves Taken, and Total Number of Leaves Permitted will
be displayed.
The User will also be given the option for applying for a leave:

Apply Online: A form will be presented to the User in which he/she has to
enter the following details: Name, Employee ID, Date on which his/her leave
begins, re-joining after the leave date, Type of the leave (Personal/Medical)
etc., Supporting Valid Documents needs to uploaded, Submit the application.
After the successful submission this application will be forwarded to the
competent authority
 P a g e | 19

3.4.6. Weather prediction Module

 User requests info about the type of disaster which he/she wants to receive from
the live weather conditions database.
 Weather conditions display then request the required data from the Data Store
database and return the requested info to the users.
 User can request for critical weather display who in turn requests data from data
store and retrieves the data from it and transmit it to the user who requested it.
 User can also request for SMS service in which a SMS regarding details of disaster
or critical weather is sent to registered user with necessary guidelines and
measures to be taken.
 Admin collects weather details from accounts of various researchers and
scientists and update them and then categorize them into critical/serious
weather conditions and normal/mild weather conditions and send the data
accordingly to data store.
 Data Store collects latest information about disasters and weather details from
Government Sources like NDRF, SDRF, Fire Department, etc.
 Info from these organisations are collected and transferred to Data Store.
 Also, when latest development occurs through various researchers and scientists
then their data is also updated in systematic categorised manner and then sent it
to Data Store

3.5. Design Constraint:

System will run on windows/Unix based platforms as well as android
platform.
 P a g e | 20

3.6. Data Flow Diagrams

P a g e | 21
P a g e | 22
P a g e | 23
P a g e | 24
P a g e | 25
P a g e | 26
P a g e | 27
 P a g e | 28

4.ESTIMATION
4.1 FUNCTION POINTS

S.no QUESTIONS GRADE

VALUE
1 Does the system require reliable backup and recovery? 5
2 Are specialized data communication required to transfer information to or from 4
the application?
3 Are there distributed processing functions 3
4 Is performance Critical? 2
5 Will the system run in an existing, heavily utilized operational environment? 5
6 Does the system require online data entry? 5
7 Does the online data entry require the input transaction to be built over multiple 3
screens or operations?
8 Are the ILFs updated online? 5
9 Are the inputs, outputs, files, or inquiries complex? 1
10 Is the internal processing complex? 3
11 Is the code designed to be reusable? 3
12 Are conversions and installations included in different organizations? 3
13 Is the system designed for multiple installations in different organizations? 4
14 Is the application designed to facilitate change and for ease of use by the user? 3

VALUE ADJUSTMENT FACTOR: Σfi =49

Rate on each factor on scale 0 to 5:

0: No influence
1: Incidental
2: Moderate
3: Average
4: Significant
5: Essential
 P a g e | 29

Information Domain Estimation Count Weighting Factor Total

Simple Average Complex Simple Average Complex
External Input 2 3 1 3 4 6 24
External Output 6 2 1 4 5 7 41
External inquiries 3 0 1 3 4 6 15
Number of logical files 5 1 0 7 10 15 45
External Interface 0 3 0 5 7 10 21
files

UNADJUSTED FUNCTION POINT (UFP): 24 + 41 + 15 + 45 + 21 = 146

COMPLEXITY ADJUSTMENT FACTOR (CAF): 0.65 + (0.01 * Σfi)
= 0.65 + (0.01 * 49)
= 1.14
FUNCTION POINT METRIC(FP): UFP * CAF
= 146 * 1.14
= 166.44

4.2 ESTIMATION OF COST AND EFFORT

Average Productivity rate in India = 14.00 FP/person-month z

Burdened labor rate = $8000 per/month
Cost per FP = Burdened labor rate / Productivity = $ 8000/14.00 FP = $571.42/FP
Total Cost = Cost per FP x FP = $ 571.42/FP x 166.44 FP = $ 95,108 = $ 95,000(approx.)
Total effort = FP/Productivity = 166.44/14.00 person-month = 11.88 person-month ≈ 12 person - month
 P a g e | 30

5.Scheduling

WK1 WK WK WK WK WK WK WK WK WK10
2 3 4 5 6 7 8 9
1. Identify Customer Requirements

Meet the Customer

Identify Needs and
Constraints
Establish Problem
Statement
Milestone: Problem
Statement Defined
2.Define Function Behaviour

Design DFD
Design Function Modules

Document SRS
Database Design
Milestone: System
Functions Defined
3.Estimations
Function Point Estimations

Effort Calculations
Milestone: Cost of Project
Defined
4.Perform Risk Analysis
Identify Risks Associated
with the proposed System
Developing Risk Tables
Developing RMMM Plans

Milestone: Risk
Management Complete
5.Testing
Coding
Control Flow Graph
Computing Cyclomatic
Complexity
Boundary Value Analysis

Milestone: Testing
Finished
 P a g e | 31

6. RISK MITIGATION, MONITORING & MANAGEMENT PLAN (RMMM-PLAN)

RISK TABLE
Sr. No Risk Category Probability Impact
1 Requirements are changed at a PD 50%` 2
later stage
2 Delay in Information Transfer TE 40% 2
3 Mis-Communication Between ST 35% 2
Staff
4 Staff may be inexperienced ST 30% 3
5 Technology doesn’t meet TE 30% 2
expectations
6 Budget may be too low BU 20% 4
7 Complex User Interface TE 20% 3
8 Loss of centralized weather data TE 10% 4
due to storage failure
LEGEND
PD Product Definition
PS Product Size
ST Staff Risk
BU Business Impact Risk
TE Technological Risk
PR Project Risk

RMMM – PLAN (For Risks above Cut-off Line)

a. Requirements are changed at a later stage:
1. Mitigation:
i. Communicate with the stakeholder to give all the requirements.
ii. If possible then new requirements should move to the next Phase of the
application. Stick to original requirements in the current Phase.
2. Monitoring:
i. Monitor any changes in requirements
3. Management:
i. Plan the changes so that no major cost is incurred in the new requirements
ii. Make sure that management and client understands the cost, schedules & impact
of changes in requirement and they are acceptable with the changes
 P a g e | 32

b. Mis-Communication Between Staff:

1. Mitigation:
i. In our portal, Miscommunication between staff is one of critical risks that occurs
due to staff members making assumptions, lack of accountability which may result
in an inefficient SRS.
2. Monitoring:
i. Miscommunication can be monitored by practicing active learning during a
conversation that will improve concentration, understanding, response &
memory of conversation
3. Management:
i. Management of this risk can be done by establishing a communicative
environment within employees.

c. Staff may be inexperienced

1. Mitigation:
i. Proper training to be given through workshops and presentation
ii. Ensure at least one experienced member in every team to guide the others
2. Monitoring:
i. Monitor the productivity of the team
3. Management:
i. Hold more training session to give hands-on experience

d. Delay in Information Transfer

1. Mitigation:
i. Proper channels of seamless transfer of data.
ii. Set up a reminder to external entities for fulfilment of data transfer
quota.
2. Monitoring:
i. A person should be authorised to oversee the co-ordination between
the system and the external entities (i.e., Weather Department, etc.)
He will be held accountable for any mis-information.
3. Management:
i. Communication channels between the parties should be made tassel-
free.
 P a g e | 33

7. Use Cases
1. Login
1.1 Brief description
This particular use case is meant for the ease of access for the employees of
the Force.
1.2 Actor
Employee and Admin can interact in this use case
1.3 Flow of events
1.3.1 Basic Flow

 The System request that the actor enter his/her user name,
password.
 The actor enters his/her Email, Password
 The system validates the entered data.
1.3.2 Alternative Flow

If in the basic Flow, the actor enters an invalid email, password the
system displays an error message. The actor can choose to either return
to basic flow or cancel the login.
1.4 Pre-condition
None
1.5 Post-condition
After successful signup, the Employee shall be able to login into the system
and can check out the details (Name, Date of Birth, Date of Joining, and PF
Details, Number of Leaves Taken, and Total Number of Leaves Permitted) and
an also apply for leave.

2. Recruitment
2.1 Brief description
This use case will describe how the actor will apply for exam
2.2 Actor
Users and Admin can interact in this use case
2.3 Flow of events
2.3.1 Basic Flow
 On clicking on register for Part 1, a page will be opened containing all
the instructions for filling up the application form and after that, we
will be directed to the details page where the user will enter all the
details and then he/she will be directed to the payment gateway.
 P a g e | 34

2.3.2 Alternative Flow

If the user in any circumstances fails to clear any of the steps, then
he/she will get error message and will be asked to complete it.

2.4Pre-condition
Users have to choose for the particular exam from the list of exams that
he/she wants to appear in it.
2.5 Post-condition
On successful submission of the form, a verification mail along with the
complete form will be sent to the respective mail id containing the
Registration ID. The system administrator will also generate the admit card
and update it in the database.

3. Making a donation
3.1 Brief description
This use case will describe how the actor will make donations on the portal
and how the system administrator handles those donations.
3.2 Actors
Users and Admin can interact in this use case.
3.3 Flow of events
3.3.1 Basic Flow
 Donate as an Individual:
The individual will be required to enter the details (Name, Email- ID,
and Mobile No.) along with the donation amount he/she wants to
donate and after successful submission of the details, the user will
be directed to the payment gateway and on successful payment, a
token number will be generated.

 Donate as a group:
After the registration, the Organisation will login with their Username
and Password and can add their Member details: (Name, Employee
ID, Ph. Number, email ID) and amount received from them. After
entering all the member details, Organisation can pay online the
amount as a single transaction.
 P a g e | 35

3.3.2 Alternative Flow

If the user in any circumstances fails to clear any of the steps mentioned
above then he/she will get error message and will be asked to complete it.
3.4 Pre-condition
Organization as well as individual can first check for which disaster or cause
they want to donate.

3.5 Post-condition
After successful transaction, individual as well as organisation can login and
print receipt. The admin will update the details of donation in the database for future
records.
4. Complaints

4.1 Brief description

This use case will describe how the actor will register for complaints and
how the admin will address those complaints.

4.2Actor
Users and admin can interact in this use case

4.3Flow of events

4.3.1 Basic Flow

Users are required to register their Complaint by filling up the
complaint registration form where he/she will be asked to enter his
/her personal details as well as the type of complaint and disaster.
After successful submission of the form, a token number will be
generated which the user can use to track the status of their
complaint
4.3.2 Alternative Flow

None
4.4 Pre-condition
None
4.5Post-condition
When the user registers their complaint, the admin will resolve the
complaint and update the complaint status in the database.
 P a g e | 36

User can also track their complaint by entering their respective token
number.

5. Conducting a Workshop

5.1 Brief description

This use case will describe how the actor will register for Workshop as an
Organization.

5.2 Actor
Users and admin can interact in this use case

5.3 Flow of event

5.3.1 Basic Flow
The institution will get themselves registered on the
Website and give details of the workshop they want
to conduct like the Name of organization, Contact
details, Number of attendees (expected), Venue, Date
and Mode of workshop and the theme of workshop.

5.4Pre-condition
None
5.5 Post-condition
After successfully conducting the workshop, the organization can get
their certificate by submitting the required documents.

6 Participating in a Workshop
6.1 Brief description
This use case will describe how the actor will apply for a Workshop and
how the admin after verifying all the details will generate an e – invite.

6.2Actor
Users and admin can interact in this use case

6.3Flow of events
6.3.1 Basic Flow
After clicking on Register, a form of personal details will
be opened and on successful submission of the form, the
admin will verify the details and generate an e – invite.
 P a g e | 37

6.3.2 Alternative Flow

None
6.4 Pre-condition
The user is required to enter the basic details like State, City, Pin code and click on
search. A list of all the available workshops in that particular city will be displayed
with a REGISTER button besides all of them. The user can now select any of the
workshop

6.5Post-condition
After applying for a particular workshop, an e – invite will be sent to the user via e
- mail and WhatsApp.

7 Accessing Weather Details

7.1 Brief description

This use case will describe how the actor will be accessing weather details

7.2 Actor
Users can interact in this use case

7.3 Flow of events

7.3.1 Basic Flow
After choosing the particular disaster which the user
wants to get notified and updated, he/she will now
choose between weather conditions display and critical
weather conditions and then will be redirected to it.

7.3.2 Alternative Flow

None
7.4Pre-condition
User must choose any disaster from the list of disasters

7.5 Post-condition

User now will be able to check any disaster details whether normal or
critical and will be getting SMS if his area comes under potential risk of
any disaster in near future.
P a g e | 38
 P a g e | 39

8. DATABASE DESIGN
WORKSHOP DATABASE

ATTRIBUTES DATA SIZE CONSTRAINT DESCRIPTION

TYPE
Worshop_ID INT 10 Primary Key Unique Workshop ID for the Workshop to be
conducted
Organisation_Name VARCHAR 30 Not NULL Name of the Organisation
Date DATE 8 Not NULL Date of the Workshop
Venue VARCHAR 10 NULL Venue where the Workshop will be
conducted
Theme VARCHAR 20 Not NULL Topic of the Workshop
Footfall INT 10 NULL Expected Footfall of the Workshop
Email VARCHAR 20 NULL E-Mail of the Conducting Organisation
Phone_Number INT 10 Not NULL Phone Number of the Conducting
Organisation
Supervisor_ID INT 10 Foreign Key Reference to Primary Key of the Employee ID
from Employee Table

WORKSHOP PARTICIPATION DATABASE

ATTRIBUTES DATA SIZE CONSTRAINT DESCRIPTION

TYPE
Worshop_ID INT 10 Foreign Key Reference to the Primary Key of the
Workshop Database (Organisation)
Participant_Name VARCHAR 30 NULL Name of the Attendee
Address VARCHAR 50 NULL Address of the Attendee
Mobile_Number INT 10 Not NULL Mobile Number of the Attendee
Email VARCHAR 20 Not NULL Email ID of the Attendee

PUBLIC COMPLAINT DATABASE

ATTRIBUTES DATA SIZE CONSTRAINT DESCRIPTION

TYPE
Name VARCHAR 30 NULL Name of the Complaint Filer
Mobile_Number INT 10 Not NULL Mobile Number of Complaint Filer
Address VARCHAR 50 Not NULL Address from where the complaint is filed
Complaint_Type VARCHAR 50 Not NULL Type of the Complaint
Dist_Type VARCHAR 20 Not NULL Type of the Disaster
Complaint_ID INT 10 Primary Key Unique ID Generated on Successful Lodging
of Complaint
Complaint_Status VARCHAR 20 NULL Status of the Complaint (resolved or not)
 P a g e | 40

EMPLOYEE DATABASE

ATTRIBUTES DATA SIZE CONSTRAINT DESCRIPTION

TYPE
Emp_Name VARCHAR 20 NULL Name of the Employee
DOB DATE 8 NULL Date of Birth of the Employee
DOJ DATE 8 NULL Date of Joining of the Employee
PF_Details FLOAT 10 NULL Provident Fund details of the Employee
Leaves INT 3 NULL No. of Leaves Taken by the Employee
Emp_ID INT 8 Primary Key Unique ID of the Employee
Complaint_ID INT 10 Foreign Key Reference to Complaint ID of the Complaint
Database

EXAMINATION DATABASE
Attribute Data Size Constraint Description
Type
Registration_Number INT 10 Primary Unique Registration Number for every
Key candidate
Candidate_Name VARCHAR 30 Not Null Name of the candidate
Mother_Name VARCHAR 30 Null Name of Candidate’s mother
Father_Name VARCHAR 30 Not Null Name of Candidate’s father
DOB DATE 8 Not Null Date of Birth of Candidate
Category VARCHAR 10 Not Null Category to which candidate belongs
Gender CHAR 1 Not Null Gender of candidate
State_of_Eligibility VARCHAR 20 Not Null State in which candidate resides
Examination_centres VARCHAR 20 Not Null First,Second,Third,Fourth choice of center
Address VARCHAR 50 Not Null Address of the candidate
Email ID VARCHAR 20 Null Email ID of candidate
Mobile No. INT 10 Not Null Mobile number of Candidate
Exam_fee FLOAT 8 Not Null Fees of exam candidate registered for
Transaction_ID INT 16 Not Null Transaction ID for every candidate
Date_of_Transaction DATE 8 Not Null Date when transaction took place

DONATION DATABASE

Attribute Data Type Size Constraint Description

Donor_ Name VARCHAR 30 Null Name of the donor
Organisation_Name VARCHAR 30 Null Name of organisation
Token_ID INT 10 Primary Key Unique Token ID generated for every donor
Address VARCHAR 50 Null Address of the donor
Date DATE 8 Not Null Date when donation took place
Amount FLOAT 20 Not Null Amount donated
 P a g e | 41

9. CODING

#include<iostream>
using namespace std;
int donation()
{
int choice;
char ch;
do //2
{
cout<<"\tDonation Portal\t\n"; //3
cout<<"\t\t1. Donate\t\n";
cout<<"\t\t2. Print Receipt\t\n";
cin>>ch;
if (ch == 1) //4
{ //5
cout<<"\t\t\t1.Donate As Individual\t\n"; //6
cout<<"\t\t\t2.Donate As Organisation\t\n";
cin>>ch2;
if(ch2 == 1) //7
{ //8
cout<<"\t\tEnter Personal Details: "; //9
InputPersonalDetails();
cout<<"\t\tEnter the Donation Amount: ";
cin>>amt;
bool a = Payment(amt);
if(a) //10
{
cout<<"Payment is Successfull"; //11
token = ReceiptGeneration();
cout<<"Token Number: "<<token;
}
else
cout<<"Error in Payment"; //12
} //13
else if (ch2 == 2) //14
{ //15
cout<<"\t\tEnter the details of the Organisation\n" //16
InputOrganisationdetails();
cout<<"\t\tEnter the total Amount by all members of the
Organisation: ";
cin>>amt;
 P a g e | 42

bool a = Payment(amt);
if(a) //17
{
cout<<"Payment is Successfull"; //18
token = ReceiptGeneration();
cout<<"Token Number: "<<token;
}
else
cout<<"Error in Payment"; //19
} //20
else //22
cout<<"Invalid choice"; //23
} //21
else if (ch == 2) //24
{
cout<<"Enter the token number for Printing the Receipt: " //25
cin>>token_no;
PrintReceipt(token_no);
}
else //26
cout<<"Invalid Input";
cout<<"Do you want to continue?(Y/N): " //27
cin>>ch3
}while(ch3 == 'Y'); //28
return 0; //29
}
 P a g e | 43

10. Control Flow Graph

 P a g e | 44

11. CYCLOMATIC COMPLEXITY

Number of Regions: 8
Predicate Nodes: 4,7,10,14,17,24,28
Number of Predicate Nodes (P) = 7
Number of Edges(E) = 35
Number of Nodes(N) = 29

Cyclomatic Complexity Calculations:

Method I:

V(G) = E – N + 2
= 35 – 29 + 2
=8

Method II: Predicate Node Formula

V(G) = P + 1
=7+1
=8

Method III:

Node Regions: V(G) = 8

INDEPENDENT PATHS:

PATH 1: 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 10 – 11 – 13 – 21 – 27 – 28 – 29
PATH 2: 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 10 – 12 – 13 – 21 – 27 – 28 – 29
PATH 3: 1 – 2 – 3 – 4 – 5 – 6 – 7 – 14 – 15 – 16 – 17 – 18 – 20 – 21 – 27 – 28 – 29
PATH 4: 1 – 2 – 3 – 4 – 5 – 6 – 7 – 14 – 15 – 16 – 17 – 19 – 20 – 21 – 27 – 28 – 29
PATH 5: 1 – 2 – 3 – 4 – 5 – 6 – 7 – 14 – 22 – 23 – 21 – 27 – 28 – 29
PATH 6: 1 – 2 – 3 – 4 – 24 – 25 – 27 – 28 – 29
PATH 7: 1 – 2 – 3 – 4 – 24 – 26 – 27 – 28 – 29
PATH 8: 1 – 2 – 3 – 4 – 24 – 26 – 27 – 28 – 2
 P a g e | 45

BOUNDARY VALUE ANALYSIS

 The two inputs that we take in our program are donation amount (x)
and the token number (y).

 The range for the input are: -

1 <= x <= 1, 00,000

100 <= y <= 999

 The expected output if both the inputs are correct is “Donation

successful and receipt printed” otherwise “Donation failed” or
“Receipt not printed” is printed.

 With single value assumption theory, 4n + 1 test cases can be designed

which are equal to 9
 P a g e | 46

 The boundary value analysis test cases are: -

TEST CASES DONATION TOKEN EXPECTED OUTPUT

AMOUNT (X) NUMBER
(Y)
1 50,000 100 Donation successful and
receipt printed
2 50,000 101 Donation successful and
receipt printed
3 50,000 500 Donation successful and
receipt printed
4 50,000 1000 Receipt not printed
5 50,000 999 Donation successful and
receipt printed
6 1 102 Donation successful and
receipt printed
7 1 998 Donation successful and
receipt printed
8 1,00,100 501 Donation failed
9 1,00,000 499 Donation successful and
receipt printed
 P a g e | 47

THE END