Hb use template

From Earth Science Information Partners (ESIP)

Discusssion of Use Case preliminaries[edit | edit source]

Use Case "types"[edit | edit source]

Not sure we have the right category names for the two types of use cases we are collecting. Suggest changing "Application" Use Case to "ESIP" Use Case. Also, possibly change "Systems" Use Case to "Technical Solutions" Use Cases.

Wiki page naming convention[edit | edit source]

Current suggestion[edit | edit source]

Naming Format
Use Case <Cluster>.<SubArea>.<number>.<letter>: <Short Name>
Example usage
Use Case AQ.Smoke.1.a: Smoke plume event detection and related dataset discovery
{AQ, DM, EC, EF, PH, WM}
{1, 2, 3, ...}
{a, b, c, ...}

Burrows comments[edit | edit source]

This naming convention may put too much of our current conceptual model into the structure of the wiki. I'd prefer that we let each contributor assure that they have a unique pagename and not link the page names to current clusters and their current substructure.

Plain Language Description[edit | edit source]

Short Definition[edit | edit source]

Define the use case in plain sentences and wherever possible, avoid
specifying technical solutions or implementation choices. Concentrate
on the application aspects of the intended scenario.

Purpose[edit | edit source]

A plain language description of why this use case exists, what the problem is
to be solved, and what a successful outcome and impact may be.

Describe a scenario of expected use[edit | edit source]

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.

Definition of Success[edit | edit source]

Quick test that would show whether or not the case is working as described.

Formal Use Case Identification[edit | edit source]

Use Case Designation[edit | edit source]


Use Case Name[edit | edit source]

<Insert short name and long name>

Revision Information[edit | edit source]

Prepared by:
<Author(s) with responsibility>
<Date/Time created>
Version X.N.a (can be labeled draft if X=0)
Modified by:
<Modifier Name/Affil>, <Date/time>, <Brief Description>

Formal Use Case Description[edit | edit source]

Definition[edit | edit source]

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[edit | edit source]

  • 1.Operation succeeds and user obtains QQQ.

Failure Outcomes[edit | edit source]

  • 1.Operation fails to return any XXX. Should instead YYYY.
  • 2.Illegal input of AAA, Should instead ZZZZ

General Diagrams[edit | edit source]

Schematic of Use case[edit | edit source]

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).

General Requirements[edit | edit source]

List any performance or metric requirements for this use case and 
another other considerations that a user would expect.

Actors[edit | edit source]

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[edit | edit source]

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[edit | edit source]

Security actor, who authenticates the user requests and issues authorizations for access to relevant data/resources.

Preconditions[edit | edit source]

  • 1.Collection metadata have been entered into the system
  • 2.Collection metadata have been validated
  • 3.Collection metadata have been published

Postconditions[edit | edit source]

  • 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)[edit | edit source]

  • 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[edit | edit source]

  • 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[edit | edit source]


Extension Points[edit | edit source]

  • <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[edit | edit source]

Use Case Diagram[edit | edit source]

State Diagram[edit | edit source]

Activity Diagram[edit | edit source]

Other Diagrams[edit | edit source]

Non-Functional Requirements[edit | edit source]

Performance[edit | edit source]

Reliability[edit | edit source]

Scalability[edit | edit source]

Usability[edit | edit source]

Security[edit | edit source]

Other Non-functional Requirements[edit | edit source]

Selected Technology[edit | edit source]

Overall Technical Approach[edit | edit source]

Architecture[edit | edit source]

Technology A[edit | edit source]

Description[edit | edit source]

Benefits[edit | edit source]

Limitations[edit | edit source]

Technology B[edit | edit source]

Description[edit | edit source]

Benefits[edit | edit source]

Limitations[edit | edit source]

References[edit | edit source]