Software Requirements

Specification (SRS)
Satellite Imaging Application
Version 1.0

Table of Contents
1. Introduction
 1.1 Purpose
 1.2 Scope
 1.3 Definitions, Acronyms, and Abbreviations
 1.4 References
2. Overall Description
 2.1 Product Perspective
 2.2 Product Functions
 2.3 User Classes and Characteristics
 2.4 Operating Environment
 2.5 Design and Implementation Constraints
 2.6 Assumptions and Dependencies
3. Specific Requirements
 3.1 Functional Requirements
 3.2 Non-Functional Requirements
 3.3 External Interface Requirements
4. Appendices
 4.1 Use Case Descriptions
 4.2 Glossary
1. Introduction
1.1 Purpose
The purpose of this Software Requirements Specification (SRS) is to define the
functional and non-functional requirements for a satellite imaging application developed
as a college project. This application allows users to:

 Select and mark geographical areas on an interactive map.

 View satellite imagery of the marked locations.
 Observe imaging data over time by selecting different dates.

The application takes inspiration from the SkyWatch Explore website, integrating similar
features to provide users with access to satellite imagery data. This document is
intended for the project development team, academic advisors, and stakeholders
involved in the project.

1.2 Scope
The satellite imaging application aims to provide an intuitive platform for users to
explore and analyze satellite imagery of specific locations over time. It serves
educational purposes and demonstrates key concepts in geospatial data handling, user
interface design, and integration with external data sources.

Key Features:

 Interactive map interface for area selection.

 Access to satellite imagery from multiple providers.
 Date-wise browsing of historical satellite images.
 Basic tools for image analysis and comparison.

1.3 Definitions, Acronyms, and Abbreviations

 API: Application Programming Interface
 GIS: Geographic Information System
 UI: User Interface
 Satellite Imagery: Images of Earth captured by satellites in orbit.
 SkyWatch Explore: A platform providing access to satellite imagery from
various providers.

1.4 References
 SkyWatch Explore Website
 Google Maps API Documentation
 NASA EarthData
 OpenStreetMap API
2. Overall Description
2.1 Product Perspective
This satellite imaging application is a standalone web-based system developed for
educational purposes within a college project. It integrates with external services such
as mapping APIs (e.g., Google Maps or OpenStreetMap) and satellite data providers
(e.g., NASA EarthData, SkyWatch Explore APIs) to retrieve and display satellite imagery.

The application is inspired by the SkyWatch Explore platform, aiming to replicate core
functionalities suitable for a small-scale project.

2.2 Product Functions

 Interactive Map Interface:
 Display an interactive map for users to navigate and explore.
 Provide tools for users to select and mark geographical areas.

 Area Selection:
 Allow users to select locations by:
 Clicking on the map.
 Drawing shapes (e.g., polygons, rectangles).
 Entering geographic coordinates.

 Satellite Imagery Retrieval:

 Fetch satellite images of the selected areas from external providers.
 Support multiple satellite data sources for comprehensive coverage.

 Date-wise Imaging:
 Enable users to select different dates to view historical imagery.
 Provide a timeline or date picker for easy navigation through time.

 Image Analysis Tools:

 Basic functionality to compare images from different dates.
 Highlight changes or differences between images.

2.3 User Classes and Characteristics

  General Users:
 Individuals interested in viewing satellite imagery.
 Basic computer literacy.
 No specialized GIS knowledge required.

 Educational Users:
 Students and educators utilizing the application for learning purposes.
 May require additional guidance or documentation.

2.4 Operating Environment

 Platform:
 Web application accessible through modern web browsers:
 Google Chrome
 Mozilla Firefox
 Microsoft Edge
 Safari

 Devices:
 Desktop computers
 Laptops
 Tablets (responsive design may be limited due to project scope)

 Internet Connection:
 Required for accessing maps and satellite imagery data.

2.5 Design and Implementation Constraints

 Technologies:
 Front-end development using HTML, CSS, JavaScript.
 Use of JavaScript libraries/frameworks like React or Vue.js (optional based
on project scope).
 Integration with mapping APIs (e.g., Google Maps API, OpenStreetMap).

 API Usage:
 Subject to terms and limitations of external APIs.
 Compliance with usage limits, licensing, and attribution requirements.

 Data Access:
 Reliance on freely available satellite imagery data to avoid costs.
  Possible use of public datasets from providers like NASA or ESA.

2.6 Assumptions and Dependencies

 External Services Availability:
 Continuous availability of mapping and satellite data APIs.
 Stable internet connection for both users and the application server.

 User Environment:
 Users have access to compatible web browsers.
 Users have sufficient bandwidth to load map tiles and imagery data.

3. Specific Requirements
3.1 Functional Requirements
3.1.1 Interactive Map Interface
 FR1: The system shall display an interactive map upon the user's access to the
application.
 FR2: The map shall support basic functionalities:
 Panning
 Zooming in and out

3.1.2 Area Selection

 FR3: Users shall be able to select a geographical location by:

 Clicking on a specific point on the map.
 Drawing shapes (e.g., polygons) to define an area.
 Entering latitude and longitude coordinates.

 FR4: The selected area shall be visually indicated on the map (e.g., markers,
outlined shapes).

3.1.3 Satellite Imagery Retrieval

 FR5: The system shall retrieve satellite imagery corresponding to the selected
area.
  FR6: The application shall integrate with external satellite data providers to fetch
imagery (e.g., NASA EarthData, SkyWatch APIs).
 FR7: The system shall handle imagery data from different providers and present
it uniformly to the user.

3.1.4 Date-wise Imaging

 FR8: Users shall be able to select a specific date or date range to view historical
imagery.
 FR9: The system shall provide a date picker or timeline slider for date selection.
 FR10: If imagery is not available for the selected date, the system shall notify
the user and suggest the nearest available date.

3.1.5 Image Analysis Tools

 FR11: The application shall allow users to compare images from different dates.

 FR12: Basic tools shall be provided to:

 Toggle between images.
 Display images side-by-side.
 Overlay images with adjustable transparency.

3.1.6 User Interface and Experience

 FR13: The UI shall be intuitive and user-friendly, following standard design
principles.
 FR14: Tooltips and help messages shall be provided to guide users through
functionalities.
 FR15: The application shall include branding elements as required by the college
project guidelines.

3.1.7 Error Handling and Notifications

 FR16: The system shall handle errors gracefully, providing informative messages
to the user in cases such as:
 Failed data retrieval from APIs.
 Invalid area selections.
 Network connectivity issues.

 FR17: Notifications shall be non-intrusive and assist the user in resolving issues.

3.2 Non-Functional Requirements

3.2.1 Performance Requirements
 NFR1: The interactive map shall load within 5 seconds over a standard internet
connection.
  NFR2: Satellite imagery shall load within 7 seconds after the user makes a
selection.

3.2.2 Usability Requirements

 NFR3: The application shall be accessible to users with basic computer skills.
 NFR4: The interface shall be responsive and adjust to different screen sizes
(within the project scope).

3.2.3 Reliability Requirements

 NFR5: The system shall be stable during demonstrations and testing periods.
 NFR6: The application shall handle unexpected inputs without crashing.

3.2.4 Supportability and Maintainability

 NFR7: The codebase shall be well-documented with comments and a README
file.
 NFR8: The application shall be structured to allow for future enhancements.

3.2.5 Security Requirements

 NFR9: Basic security practices shall be implemented to protect against common
web vulnerabilities (e.g., input sanitization).
 NFR10: Since user data collection is minimal, privacy concerns are limited.

3.2.6 Compliance
 NFR11: The application shall comply with the usage policies of external APIs and
data providers, including attribution requirements.

3.3 External Interface Requirements

3.3.1 User Interfaces

 EIR1: The UI shall consist of the following main components:

 Interactive map area.
 Control panel for area selection and date navigation.
 Display area for satellite imagery.

3.3.2 Hardware Interfaces

 EIR2: No specific hardware interfaces are required beyond standard input/output
devices (keyboard, mouse, display).

3.3.3 Software Interfaces

 EIR3: The application shall interface with:

  Mapping APIs: Google Maps API or OpenStreetMap API for map
functionalities.
 Satellite Data APIs: Publicly available APIs from providers like NASA
EarthData or SkyWatch Explore.

 EIR4: The system shall use standard web protocols (HTTP/HTTPS) for all network
communications.

4. Appendices
4.1 Use Case Descriptions
Use Case 1: Select and View Satellite Imagery of a Location

 Primary Actor: User

 Precondition: User has accessed the application via a web browser.

 Main Flow:
1. The user navigates the interactive map to find an area of interest.
2. The user selects the area by clicking on the map, drawing a shape, or
entering coordinates.
3. The system marks the selected area on the map.
4. The user selects a date using the date picker.
5. The system retrieves the satellite imagery for the selected area and date.
6. The system displays the imagery to the user alongside the map.

 Postcondition: The user views the satellite imagery for the specified area and
date.

Use Case 2: Compare Satellite Imagery Over Time

 Primary Actor: User

 Precondition: User has selected an area of interest.

 Main Flow:
1. The user selects two different dates using the date picker.
2. The system retrieves satellite images for both dates.
 3. The system displays the images side-by-side or overlays them if the user
chooses.
4. The user uses provided tools to analyze differences between the images.

 Postcondition: The user compares and analyzes changes in the selected area
over time.

4.2 Glossary
 API (Application Programming Interface): A set of protocols and tools for
building software applications, allowing communication between software
components.
 GIS (Geographic Information System): Systems designed to capture, store,
manipulate, analyze, manage, and present spatial or geographic data.
 Satellite Imagery: Photographs of Earth or other planets made by means of
artificial satellites.
 SkyWatch Explore: An online platform providing access to satellite imagery
data from various providers.

Notes and Considerations

 Inspiration from SkyWatch Explore:
 The application draws inspiration from SkyWatch Explore in terms of:
 User-friendly map interface for area selection.
 Access to satellite imagery from multiple sources.
 Ability to browse and compare historical imagery data.
 While full replication of SkyWatch Explore's capabilities is beyond the
scope of this project, key features have been adapted to fit the project's
objectives and constraints.

 Data Sources:
 Due to potential costs and licensing restrictions, the application will utilize
freely available satellite imagery data from sources such as:
 NASA EarthData: Offers free and open data, including imagery
from Landsat and MODIS satellites.
 ESA's Sentinel Program: Provides free access to high-resolution
imagery data.

 Attribution and Compliance:

 All use of external APIs and data shall comply with the providers' terms of
service.
 Proper attribution to data sources and APIs will be included within the
application as required.