Eventually this page will contain the links to the specific use cases that the pipeline will handle.

The use cases should be specific enough so that the pipeline implementers know exactly what is required and how each step in the data processing should be handled. When properly specified, the use case is a recipe such that, when followed, the pipeline will get the result(s) that the author of the use case intended. As with any recipe, a use case should be clear as to what the data products expected from the pipeline are and what steps and ingredients are necessary to produce those products. The set of use cases define the requirements and end products to be produced by the pipeline. Each use case should cover unexpected conditions - for example, what should the pipeline do if the set of expected scans ends prematurely? Each individual use case should avoid trying to anticipate all related use cases. It is better to be clear and concise in each specific use case. Relations between use cases will be discovered later and will guide the pipeline implementation. Pipeline use cases may themselves be parts of larger observational use cases. These larger cases will cover observational configuration and control issues (e.g. Glen's initial use-case document which is a useful outline of an observational use case).

• Existing use-case related links
  • Use Cases Notes We need a link to Glen's initial use-case document. These notes are an early response to that document. Eventually these notes will be folded into the component descriptions elsewhere and as the use cases mature, this note will probably be eliminated. Note that Glen's document provides a good outline for one use case.
  • Example mapping reduction script

-- BobGarwood - 2009-07-15