Use Case Template

A use case describes what a user can do with a system, by specifying a sequence of interactions between user and system leading to a desirable outcome. It should not be confused with specifying the technology itself: a use case may allow for many alternatives to achieving user needs. To help analysis across use cases and to keep a consistent level of information, each use case should try to follow the template below, providing something for each non-optional field.

The rationale for the design of the template can be found here.

Please follow the Guidelines for curating use cases.

Name

The Wiki page URL should be of the form "Use_Case_Name", where Name is a short name by which we can refer to the use case in discussions. The Wiki page URL can act as a URI identifier for the use case.

Owner

The person responsible for maintaining the correctness/completeness of this use case. Most obviously, this would be the creator.

Provenance Dimensions

The primary dimension which this use case illustrates, and secondary dimensions which the use case also illustrates.

Background and Current Practice

Where this use case takes place in a specific domain, and so requires some prior information to understand, this section is used to describe that domain. As far as possible, please put explanation of the domain in here, to keep the scenario as short as possible.

If this scenario is best illustrated by showing how applying technology could replace current existing practice, then this section can be used to describe the current practice.

This section can also be used to document the provenance of the use case.

Goal

Two short statements stating (1) what is achieved in the scenario without reference to provenance, and (2) how we use provenance technology to achieve this goal.

Use Case Scenario

The use case scenario itself, described as a story in which actors interact with systems, each other etc. It should show who is using provenance information and for what purpose. Please mark the key steps which show requirements on provenance in italics.

Problems and Limitations

The key to why a use case is important often lies in what problem would occur if it was not achieved, or what problem means it is hard to achieve. This section lists reasons why this scenario is or may be difficult to achieve, including pre-requisites which may not be met, technological obstacles etc.

Important: Please explicitly list here the technical challenges (with regards to provenance) made apparent by this use case. This will aid in creating a roadmap to overcome those challenges.

Unanticipated Uses (optional)

The scenario above describes a particular case of using technology. However, by allowing this scenario to take place, the technology allows for other use cases. This section captures unanticipated uses of the same system apparent in the use case scenario.

Existing Work (optional)

This section is used to refer to existing technologies or approaches which achieve the use case.