B.S.

A COLLEGE OF ENGINEERING
AND TECHNOLOGY
MATHURA

SOFTWARE ENGINEERING
(KCA 352)

MCA 2ND Year

Session 2024-25

Submitted By: Submitted To:

ROBY Ms. Jyoti Kashyap Ma’am
Roll no. 2300650140018
 INDEX
Sr. no. Objective Page No. Submission Sign
Date
 Experiment No. -01

AIM: - To prepare " PROBLEM STATEMENT " for Weather App Interface (weather
App).
Hardware Interfaces: -
 Device name: - DESKTOP-AOGLKLE
 Processor: - Dell intel i5 4.00 GHz
 Installed RAM: - 16.0 GB (11.0 GB usable)
 System type: - 64-bit operating system, x64-based processor
Software Interfaces: -
Window Specifications
 Edition: - Windows 10 Pro
 Version: - 22H2
 Installed on: - 04-10-2023
 OS build: - 19045.4898
We are using Microsoft Office word for explaining this Project.
Theory: -
The Weather App Interface project aims to design a user-friendly and
visually appealing interface that provides real-time weather information in an
intuitive and accessible manner. The app will display key weather metrics such as
temperature, humidity, wind speed, and precipitation forecasts, while also
offering features like location-based weather updates, hourly and weekly
forecasts, and customizable alerts for severe weather conditions. The interface
will prioritize simplicity, ensuring that users can quickly interpret weather data
and navigate seamlessly between different sections, whether on mobile or
desktop platforms. The project will focus on both functionality
and aesthetics toenhance the overall user experience.

Conclusion: -
The problem statement was written successfully by
following thesteps described above.
 Experiment No. 2
Software Requirements Specification (SRS)
AIM: Write the Software Requirement Specification (SRS) of the project “Weather Website”.
REQUIREMENTS:
Hardware Interfaces
pentium(R) D CPU 2.80GHz 2.79GHz.1.99GB of RAM
Screen resolution of at least 800*600 required for proper and complete viewing of screens.
Higher resolution would not be a problem.
CD ROM Driver
Software Interfaces
Any window-based operating system(Windows95/98/200/XP/NT/7/8/10/11)).
WordPad or Microsoft Word
Theory

1. Introduction
1.1 Purpose

The purpose of this document is to define the requirements for a weather website that provides
real-time weather information to users. This SRS will detail the functionality, performance, user
interface, and system requirements for the weather website. The target audience includes
developers, project managers, and stakeholders involved in this project.

1.2 Scope

The weather website will deliver real-time weather updates, forecasts, and alerts for various
locations. The site will provide current temperature, humidity, wind speed, and detailed forecast
information. The primary users of this website include general internet users interested in
weather data and travelers needing real-time updates.

1.3 Definitions, Acronyms, and Abbreviations

 API: Application Programming Interface

 HTTP: Hypertext Transfer Protocol
 HTTPS: Secure Hypertext Transfer Protocol
 UI: User Interface
 UX: User Experience
1.4 References

 IEEE SRS Standard Document Template

 HTML, CSS, JavaScript, and Weather API documentation

1.5 Overview

This document provides a detailed description of the weather website project requirements. It
includes functional and non-functional requirements, system features, and design constraints.

2. Overall Description
2.1 Product Perspective

The weather website will be a standalone web application that uses an external weather API to
fetch real-time weather data. It will support responsive design for accessibility across various
devices (desktop, tablet, mobile).

2.1.1 System Interfaces

 The website will integrate with a weather API (e.g., OpenWeatherMap, WeatherStack)
for real-time weather data.
 The site will interact with the API using HTTPS requests and JSON responses.

2.1.2 User Interfaces

 Homepage: Displays current weather for the user’s location and search functionality.
 Forecast Page: Displays a detailed 7-day forecast and weather trends.
 Alerts Page: Displays any weather alerts or warnings.

2.1.3 Hardware Interfaces

 The weather website should be accessible via any device with internet connectivity.

2.1.4 Software Interfaces

 Frontend: HTML, CSS, JavaScript

 Backend: JavaScript ([Link] for server-side rendering if applicable)
 Database: Optional for user preferences (e.g., MongoDB, Firebase)
 Weather API: RESTful API for weather data

2.1.5 Communications Interfaces

  The system will use HTTPS protocol for secure API communication.

2.2 Product Functions

 Current Weather: Display current weather conditions based on user location or search
query.
 Weather Forecast: Display daily forecasts for the next 7 days.
 Weather Alerts: Display real-time weather alerts and warnings for the selected location.
 Search Functionality: Allow users to search for weather information by city or location.
 User Preferences (Optional): Save user preferences, such as preferred temperature units
(Celsius or Fahrenheit).

2.3 User Characteristics

The primary users include:

 General Internet Users: People interested in checking weather information for a

particular area.
 Travelers: Users looking for up-to-date weather information for their travel destinations.

2.4 Constraints

 Dependency on third-party weather API for real-time data.

 Limited control over weather API response time and data accuracy.
 Requirement to implement responsive design.

2.5 Assumptions and Dependencies

 The weather website will be accessible via modern browsers.

 A reliable weather API will be available and accessible at all times.
 Users will have a stable internet connection to access the website.

3. Specific Requirements
3.1 Functional Requirements

3.1.1 Weather Information Display

 Description: The website should display current weather data such as temperature,
humidity, wind speed, and a summary description.
 Inputs: User's location or search query (city name).
 Outputs: Real-time weather data for the selected location.
 Preconditions: The user has provided a valid location or city name.
  Postconditions: Display updated weather data on the website.

3.1.2 Forecast Information

 Description: Provide a 7-day weather forecast for the selected location.

 Inputs: User's location or search query.
 Outputs: Forecast data including temperature, humidity, and weather conditions for each
day.
 Preconditions: The user has chosen a location.
 Postconditions: Display the forecast data on the forecast page.

3.1.3 Search Functionality

 Description: Allow users to search for weather information for specific locations.
 Inputs: City name or geographical coordinates.
 Outputs: Weather data for the specified location.
 Preconditions: The user has entered a valid location in the search box.
 Postconditions: Display weather data for the queried location.

3.1.4 Alert Notifications

 Description: Display alerts or warnings for severe weather conditions.

 Inputs: Weather alert data from the weather API.
 Outputs: Visual alerts on the website.
 Preconditions: The selected location has active weather alerts.
 Postconditions: Display alert notifications on the alerts page.

3.1.5 Unit Preferences

 Description: Allow users to toggle between Celsius and Fahrenheit temperature units.
 Inputs: User selection (Celsius or Fahrenheit).
 Outputs: Updated temperature values.
 Preconditions: The user has chosen a temperature unit.
 Postconditions: Display temperature in the selected unit.

3.2 Non-functional Requirements

3.2.1 Performance Requirements

 Response Time: Weather data should be displayed within 2-3 seconds of user input.
 Availability: The website should be accessible 24/7.
 Scalability: Support up to 10,000 concurrent users without performance degradation.

3.2.2 Usability Requirements

  User-Friendly Interface: The website should have an intuitive layout and accessible
design for ease of use.
 Responsive Design: The site should adapt seamlessly to various screen sizes and
resolutions.

3.2.3 Security Requirements

 Data Protection: Secure API calls to protect user data.

 HTTPS Protocol: All communication with the weather API should be over HTTPS.

3.2.4 Reliability Requirements

 Data Accuracy: Weather data should be up-to-date and reliable.

 Error Handling: Provide error messages in case of invalid user input or API failures.

3.3 Software System Attributes

3.3.1 Maintainability

 The system should have well-documented code for easy maintenance and updates.

3.3.2 Portability

 The website should be accessible across different web browsers (Chrome, Firefox, Safari,
Edge) and operating systems (Windows, macOS, Linux).

4. Conclusion: SRS made successfully.

4.1 References

 Weather API Documentation: API used for real-time data.

 Responsive Web Design Guidelines: Best practices for designing responsive websites.
 Usability Standards: Principles to improve user interface and user experience.

4.2 Glossary

 Weather API: A service that provides weather data, which can be integrated into
applications.
 Forecast: Prediction of future weather conditions based on meteorological data.
 Experiment No. 3
AIM: Data flow diagram(DFD) of the project “Weather Website”.
Hardware Interfaces
pentium(R) D CPU 2.80GHz 2.79GHz.1.99GB of RAM
Screen resolution of at least 800*600 required for proper and complete viewing of screens.
Higher resolution would not be a problem.
CD ROM Driver
Software Interfaces
Any window-based operating system(Windows95/98/200/XP/NT/7/8/10/11)).
WordPad or Microsoft Word

DFD Context and Levels

1. Context Diagram (Level 0): Shows the entire system as a single process, with external
entities and the main data flows.
2. Level 1 Diagram: Expands the context diagram by breaking down the main system
processes into sub-processes, showing how data flows between them.
3. Level 2 Diagram: Further details each sub-process, showing internal data flow within
each primary process.

Context Diagram (Level 0)

In the context diagram, the weather website system is represented as a single process. The
system interacts with external entities like the User and Weather API.

 External Entities:
o User: Interacts with the system by entering locations and viewing weather data.
o Weather API: Provides weather data to the system.
 Data Flows:
o Location Request: User provides location input to search for weather data.
o Weather Data Request: The system sends requests to the Weather API for
weather information.
o Weather Data: Weather API responds with the requested weather data.
o Weather Forecast and Alerts: The system displays weather forecast, alerts, and
other relevant information to the user.
Level 1 Diagram

In Level 1, we break down the main "Weather Forecast Website System" process into key sub-
processes to show the internal flow of data.

Main Processes in Level 1:

1. Process 1.0: Search Location

o Input: User enters a location.
o Output: Location query is passed to the Retrieve Weather Data process.
2. Process 2.0: Retrieve Weather Data
o Input: Location query.
o Process: Sends an API request to the Weather API for the specified location’s weather
data.
o Output: Receives real-time weather data from the API.
3. Process 3.0: Display Weather Forecast and Alerts
o Input: Weather data (received from the Weather API).
 o Output: Presents weather forecast, temperature, alerts, and other relevant data to the
user.
4. Process 4.0: Manage User Profile (for Registered Users)
o Input: User preferences (saved locations, alert settings).
o Output: Updates user preferences in the profile and allows customization of displayed
data.
 Experiment No. 4
AIM: ER diagram of the project “Weather Website”.
Hardware Interfaces
pentium(R) D CPU 2.80GHz 2.79GHz.1.99GB of RAM
Screen resolution of at least 800*600 required for proper and complete viewing of screens.
Higher resolution would not be a problem.
CD ROM Driver
Software Interfaces
Any window-based operating system(Windows95/98/200/XP/NT/7/8/10/11)).
WordPad or Microsoft Word

Entities and Attributes

1. User
o Attributes:
 UserID (Primary Key)
 Name
 Email
 Password
 LocationPreferences
 NotificationPreferences
2. Location
o Attributes:
 LocationID (Primary Key)
 CityName
 CountryCode
 Latitude
 Longitude
3. WeatherData
o Attributes:
 WeatherDataID (Primary Key)
 LocationID (Foreign Key)
 Temperature
 Humidity
 WindSpeed
 WeatherCondition
 Timestamp
4. Forecast
o Attributes:
 ForecastID (Primary Key)
 LocationID (Foreign Key)
  Date
 TemperatureHigh
 TemperatureLow
 Humidity
 PrecipitationChance
5. Alert
o Attributes:
 AlertID (Primary Key)
 LocationID (Foreign Key)
 AlertType (e.g., storm, heavy rainfall)
 Description
 SeverityLevel
 StartTime
 EndTime
6. UserLocation
o Attributes:
 UserLocationID (Primary Key)
 UserID (Foreign Key)
 LocationID (Foreign Key)

Relationships

 User – Location (Many-to-Many): Users can have multiple locations in their

preferences, and each location can be preferred by multiple users. This relationship is
managed by the UserLocation entity.
 Location – WeatherData (One-to-Many): Each location can have multiple weather data
entries over time (e.g., each entry is a record of real-time weather data for that location).
 Location – Forecast (One-to-Many): Each location can have multiple forecast records,
typically for different dates in the future.
 Location – Alert (One-to-Many): Each location can have multiple alerts, especially in
cases of severe weather conditions that span multiple time periods.

ER Diagram Description

In the ER diagram:

 User entity is connected to UserLocation with a one-to-many relationship.

 UserLocation is a linking entity that connects User and Location in a many-to-many
relationship.
 Location entity is connected to WeatherData, Forecast, and Alert entities with one-to-
many relationships.
  WeatherData, Forecast, and Alert entities store dynamic data for each location and
have foreign keys pointing to LocationID.

ER diagram for Weather Website

 Experiment No. 5
AIM: Use Case of the project “Weather Website”.
Hardware Interfaces
pentium(R) D CPU 2.80GHz 2.79GHz.1.99GB of RAM
Screen resolution of at least 800*600 required for proper and complete viewing of screens.
Higher resolution would not be a problem.
CD ROM Driver
Software Interfaces
Any window-based operating system(Windows95/98/200/XP/NT/7/8/10/11)).
WordPad or Microsoft Word

Use Case Model for Weather Website

Actors

1. Guest User: A non-registered visitor who can view basic weather data.
2. Registered User: A user with an account who can save preferences and receive
personalized data.
3. Weather API: An external system providing real-time weather data.

Use Cases

1. Search for Weather by Location

 Actors: Guest User, Registered User

 Description: The user enters a location to retrieve the current weather details.
 Preconditions: User has access to the website.
 Postconditions: Displayed weather information for the specified location.
 Main Flow:
1. User enters a location (city name or postal code).
2. System sends a request to the Weather API.
3. Weather API returns real-time weather data for the location.
4. System displays the weather data to the user.

2. View Hourly and Weekly Forecast

 Actors: Guest User, Registered User

 Description: Users view detailed hourly or weekly weather forecasts for a selected
location.
  Preconditions: Location weather is retrieved.
 Postconditions: Displayed hourly and weekly forecast.
 Main Flow:
1. User selects a location.
2. System requests forecast data from the Weather API.
3. API returns forecast details for the next few hours/days.
4. System displays forecast details to the user.

3. Receive Severe Weather Alerts

 Actors: Registered User, Weather API

 Description: Registered users are notified of severe weather conditions in their saved
locations.
 Preconditions: User has a saved location with alerts enabled.
 Postconditions: User receives alert notification.
 Main Flow:
1. System checks the Weather API for alerts at regular intervals.
2. If a severe weather alert is available, the system sends a notification to the user.

4. Register and Manage Profile

 Actors: Guest User

 Description: A new user registers and creates an account to save locations and set alert
preferences.
 Preconditions: User accesses the registration page.
 Postconditions: User account created with stored preferences.
 Main Flow:
1. User enters registration information (name, email, password).
2. System validates and stores user data.
3. System creates a new user profile with default settings.

5. Save and Manage Locations

 Actors: Registered User

 Description: Allows users to save preferred locations and access weather data for those
locations easily.
 Preconditions: User is logged in.
 Postconditions: Locations saved to the user’s profile.
 Main Flow:
1. User selects a location and chooses to save it.
2. System adds location to the user’s profile preferences.
3. User can access saved locations on subsequent visits.

6. View Weather History (Optional)

 Actors: Registered User

  Description: Allows registered users to view historical weather data for a specific
location.
 Preconditions: User is logged in and has selected a location.
 Postconditions: Displayed historical weather data.
 Main Flow:
1. User selects a saved location.
2. System retrieves historical data from the Weather API or local database.
3. System displays historical weather data for the user.

Use Case Diagram Summary

1. Search for Weather by Location ↔ Guest User, Registered User

2. View Hourly and Weekly Forecast ↔ Guest User, Registered User
3. Receive Severe Weather Alerts ↔ Registered User
4. Register and Manage Profile ↔ Guest User
5. Save and Manage Locations ↔ Registered User
6. View Weather History (optional) ↔ Registered User