Scribd
Upload
12 views7 pages

Share Your Report (Feasibility, SRS)

Uploaded by

anilpython7877
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views7 pages

Share Your Report (Feasibility, SRS)

Uploaded by

anilpython7877
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Software Requirements Specification (SRS)

For

Robust Platform For Natural Disaster


Tracking

CS 210: Software Engineering

Under the Guidance of

Pradhan Sir & Deep Patel

Submitted by:

Mayank Pal (AD23B1031)

Hemant Parte (AD23B1022)

Sourav Kumar (CS23B1070)

Nikhil Nagar (AD23B1035)

Anil Kumar (AD23B1004)

Naumisharanya Tirth (CS23B1050)


Index
1. Introduction
● 1.1 Purpose
● 1.2 Scope
● 1.3 Definitions, Acronyms, and Abbreviations
● 1.4 Overview

2. Overall Description
● 2.1 Product Perspective
● 2.2 Product Features
● 2.3 User Classes and Characteristics
● 2.4 Design and Implementation Constraints
● 2.5 Assumptions and Dependencies

3. System Features
● 3.1 User Authentication
● 3.2 Social Media Data Collection
● 3.3 Sentiment Analysis
● 3.4 Location Extraction
● 3.5 Real-time Dashboard
● 3.6 User Alerts
● 3.7 Admin Dashboard

4. External Interface Requirements


● 4.1 User Interfaces
● 4.2 Hardware Interfaces
● 4.3 Software Interfaces
● 4.4 Communication Interfaces

5. System Non-functional Requirements


● 5.1 Performance Requirements
● 5.2 Security Requirements
● 5.3 Reliability Requirements
● 5.4 Usability Requirements

6. Other Requirements
● 6.1 Legal and Regulatory Requirements

7. Appendices
● A. Glossary
● B. Issues List

1. Introduction

1.1 Purpose

This SRS document describes the requirements for developing a disaster management platform
that leverages social media data (e.g., Twitter, Facebook) and sentiment analysis to aid in
real-time decision-making during disasters. The platform aims to assist rescuers and
government agencies by providing insights into affected areas, sentiment trends, and
emergency needs based on social media activity.

1.2 Scope

The platform will gather data from social media, analyze sentiments, and provide visualized
insights for disaster management. It will be used by emergency response teams, NGOs,
government agencies, and the public to enhance disaster response and recovery. Key features
include sentiment analysis, location extraction, real-time alerts, and an admin dashboard.

1.3 Definitions, Acronyms, and Abbreviations

● SRS: Software Requirements Specification


● NGO: Non-Governmental Organization
● API: Application Programming Interface
● Sentiment Analysis: A technique to determine the emotional tone behind a series of
words
● Real-time Alerts: Immediate notifications sent to users

1.4 Overview

This document provides a comprehensive overview of the system's functionality, user


interactions, constraints, and non-functional requirements. The following sections detail the
system features, interface requirements, performance metrics, and other related requirements.

2. Overall Description

2.1 Product Perspective

The platform will integrate with social media APIs (e.g., Twitter, Facebook) to retrieve posts
related to disasters. It will utilize sentiment analysis to determine the general emotional
response to disaster events and extract location data to map affected areas.
2.2 Product Features

● Sentiment Analysis: Classify social media posts as positive, negative, or neutral


regarding disaster events.
● Location Extraction: Extract geographical locations from posts to identify affected
areas.
● Real-time Dashboard: Display data and trends in real-time to assist with disaster
management.
● User Alerts: Send alerts to users based on predefined criteria (e.g., high levels of
negative sentiment in a specific location).

2.3 User Classes and Characteristics

● Rescuers: Need real-time updates and location-based insights.


● Government Agencies: Require data for decision-making and resource allocation.
● NGOs: Need to identify areas requiring aid and assistance.
● Public Users: May use the platform to stay informed about disaster situations.

2.4 Design and Implementation Constraints

● API Rate Limits: Limited number of API calls per hour may restrict real-time data
gathering.
● Data Privacy: Must comply with privacy laws and regulations related to social media
data.

2.5 Assumptions and Dependencies

● Social media platforms will provide access to necessary data through their APIs.
● Users will have access to the internet and modern web browsers.
● Third-party sentiment analysis tools and libraries will be available for integration.

3. System Features

3.1 User Authentication

● Description: Users must log in using credentials or social media accounts.


● Priority: High

3.2 Social Media Data Collection

● Description: The system will collect data from Twitter and Facebook APIs based on
disaster-related keywords.
● Priority: High

3.3 Sentiment Analysis


● Description: Analyze the sentiment of collected posts to classify them as positive,
negative, or neutral.
● Priority: High

3.4 Location Extraction

● Description: Extract location data from posts to map affected areas on a dashboard.
● Priority: High

3.5 Real-time Dashboard

● Description: Display real-time data, including sentiment trends and geographic locations
of disasters.
● Priority: High

3.6 User Alerts

● Description: Send alerts to users based on sentiment trends and geographic data.
● Priority: Medium

3.7 Admin Dashboard

● Description: Allow admins to manage the platform, view analytics, and configure alert
settings.
● Priority: Medium

4. External Interface Requirements

4.1 User Interfaces

● Description: The platform will have a web-based interface that includes dashboards,
maps, and sentiment analysis graphs.

4.2 Hardware Interfaces

● Description: The system should be compatible with standard desktop and mobile
devices.

4.3 Software Interfaces

● Description: Integration with Twitter and Facebook APIs for data collection, and
third-party sentiment analysis APIs for processing.

4.4 Communication Interfaces


● Description: The platform will communicate over the internet using standard
HTTP/HTTPS protocols.

5. System Non-functional Requirements

5.1 Performance Requirements

● Description: The system should be able to process and display data in real-time with
minimal latency.

5.2 Security Requirements

● Description: Data must be encrypted in transit and at rest. User authentication should
be secure, and access control should be enforced.

5.3 Reliability Requirements

● Description: The platform should have high availability during disaster situations with a
99.9% uptime guarantee.

5.4 Usability Requirements

● Description: The interface should be intuitive and easy to navigate for all user classes,
with clear instructions and visual aids.

6. Other Requirements

6.1 Legal and Regulatory Requirements

● Description: The platform must comply with GDPR and other relevant data protection
laws. It must also adhere to social media platforms' terms of service regarding data
usage.

7. Appendices

A. Glossary

● Sentiment Analysis: The process of determining the emotional tone behind a series of
words.
● API: Application Programming Interface, a set of rules that allows one piece of software
to interact with another.
B. Issues List

● Issue 1: Potential API rate limits affecting data collection frequency.


● Issue 2: Ensuring data privacy compliance while handling user data from social media
platforms.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy