SolutionsUseCase Health-Disaster Fire-Wildfire-Observation-Coverage 1a
Return to: Use_Cases
Plain Language Description
Short Definition
A user is responsible for tactical planning, analysis, and operations to combat fires of national importance, especially near inhabited areas or critical infrastructure assets. The name of this wiki entry will be SolutionsUseCase_Health-Disaster_Fire-Wildfire-Observation-Coverage_1 once it has been posted to the ESIP Federation wiki.
Purpose
A user searches for and finds specific types of fire data available from multiple sensor assets, such as satellites, unmanned aerial vehicles, and in-situ instruments, and creates user specified data products that are automatically generated and delivered to the user local client. At present, a user needs to know a lot about the types, locations and operating modes of instruments and their platforms to be able to locate, retrieve and use their data. This is especially true when the desired data is to be obtained from variable locations sometime in the future instead of from the archives or via a continuous sensor readout from a fixed location. A user would prefer to subscribe to their area of interest (AOI) for sensor web coverage, receive daily alerts for fire data available in their area, request specific taskings for future data collects, and be provided the latest imagery, derived data products, and in-situ sensor readings for fires in their AOI automatically, even for observations that will occur over the next few days.
The user does not necessarily have to know what assets are available to support sensor readouts in each region in their domain,...they are more focused on the task at hand (fire management/firefighter dispatch, etc.). The sensor web will identify large fires in the user AOI, locate the current locations of those fires, task various observing assets to target those fire locations in an optimized fashion, execute detection algorithms that process user-specific classification products and post alerts based on those observations, and deliver all products to a web map client for overlaying with other infrastructure and geographical information of the AOI.
Describe a scenario of expected use
A verbose (more detailed) description of one instance of a problem to be solved, what resources are generally needed (if known) and what a successful outcome and impact may be. In this case, who might be expected to do the work or provide the resources and who might be expected to benefit from the work. List any performance or metric requirements for this use case and another other considerations that a user would expect.
Definition of Success
Quick test that would show whether or not the case is working as described.
Formal Use Case Description
Use Case Identification
- Use Case Designation
- <ApplicationArea>.<SubArea>.<ReferenceNumber>
- Use Case Name
- <Insert short name and long name>
Revision Information
- Prepared by:
- <Author(s) with responsibility>
- <Affiliation>
- <Date/Time created>
- Version X.N.a (can be labeled draft if X=0)
- Modified by:
- <Modifier Name/Affil>, <Date/time>, <Brief Description>
Definition
First paragraph is short description, second paragraph, etc. may contain further details.
Through this use case, the system User locates and identifies datasets (collections of related grandules) for use or processing. This process results in the User having access to a subset of the datasets in the portal that meet the requirements of the User. Individual datasets, and their constituent granules, may then be identified for further action or processing (e.g. Visualization, analysis, download).
Successful Outcomes
- 1.Operation succeeds and user obtains QQQ.
Failure Outcomes
- 1.Operation fails to return any XXX. Should instead YYYY.
- 2.Illegal input of AAA, Should instead ZZZZ
General Diagrams
Schematic of Use case
A diagram of how the different elements and people/processes may fit together in the use case (if possible do not refer to specific technologies).
Use Case Elaboration
This section is intended to be completed with the details of the use case that are required for implementation. This section is not intended to be filled in by an application user.
Actors
Always identify primary actors, may be more than one. Also identify other actor including any other systems or services which are important. Primary actors are usually ones that invoke the use case and are beneficiaries of the result. They may be human or computer. They are actionable. Other actors are those that support the primary actor, i.e. would be part of the use case without the tasks, work flow, resource, or requirements implied by the needs of the primary actor.
Primary Actors
The actor that initiates this use case is the portal User. Providers may also initiate this use case as a precursor to use case EIE05, Manage Collections/datasets.
Other Actors
Security actor, who authenticates the user requests and issues authorizations for access to relevant data/resources.
Preconditions
- 1.Collection metadata have been entered into the system
- 2.Collection metadata have been validated
- 3.Collection metadata have been published
Postconditions
- 1.Datasets or granules have been identified within the system for further action
- 2.Appropriate action (i.e. Map, download, process) controls have been provided to the user to initiate that action.
- 3.Controls are provided to the user to refine the criteria used to 'discover' the dataset.
Normal Flow (Process Model)
- 1)The user selects the 'dataset discovery' tool collection from the user interface
- 2)The user performs a 'simple' search using a simple interface that searches commonly queries dataset attribute fields for matching text/terms.
- 3)The results of the search are presented to the user with appropriate action controls associated with the datasets.
- 4)The user selects one of the action controls to 'use' the identified dataset(s) in a specified action (i.e. Visualization, download, processing)
Alternative Flows
- 1)The user selects the 'dataset discovery' tool collection from the user interface
- 2)The user selects a control that provides access to an advanced search tool that supports spatial, temporal, and parametric search methods. Flow then extends to EIE11-EIE14.
Special Functional Requirements
None
Extension Points
- <Cluster>.<SubArea>.<number>.<letter+1> something added or a variant.
E.g. AQ.Smoke.1.b something added or a variant
- <Cluster>.<SubArea>.<number>.<letter+2> something added or a variant
- <Cluster>.<SubArea>.<number>.<letter+3> something added or a variant
Diagrams
Use Case Diagram
State Diagram
Activity Diagram
Other Diagrams
Non-Functional Requirements
Performance
Reliability
Scalability
Usability
Security
Other Non-functional Requirements
Selected Technology
Overall Technical Approach
Architecture
Technology A
Description
Benefits
Limitations
Technology B
Description
Benefits
Limitations
References
None