ServiceValidation

From Earth Science Information Partners (ESIP)
Revision as of 17:02, December 13, 2011 by Rduerr (talk | contribs) (Created page with " == Service Validation == Point of contact name (i.e., author name): Ruth Duerr === Goal === Determine whether or not my OpenSearch service or casts are compliant with some ve...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Service Validation

Point of contact name (i.e., author name): Ruth Duerr

Goal

Determine whether or not my OpenSearch service or casts are compliant with some version of the ESIP discovery protocol.

Summary

I, someone whose organization is trying to develop an OpenSearch server or cast generator that wishes to be compliant with some version of the ESIP discovery protocols, use the ESIP testbed to test whether or not my service or cast actually is compliant.

Actors

User - primary actor, someone with a service or cast they wish to verify ESIP testbed portal - the version of the Esri Geoportal Server that has been installed on the ESIP testbed and configured to be able to validate an OpenSearch service or cast URL - the URL of the OpenSearch service or cast to be validated

Preconditions

The ESIP testbed portal is up and running and has been configured to accept a range of ESIP specifications that it can validate against. There is a publicly accessible URL for the service or cast to be validated.

Triggers

Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.

Basic Flow

Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)

Alternate Flows

Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.

Post Conditions

Here we give any conditions that will be true of the state of the system after the use case has been completed.

Activity Diagram

Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case. However often a picture speaks a 1000 words

Notes

There is always some piece of information that is required that has no other place to go. This is the place for that information.