| Goal: | Handle interactive user request for bulk data satisfying cuts on certain variables. |
|---|---|
| Actors: | Interactive client, U1 (Event database extractor), D1 (Event database) tool | Preconditions: | U1 and D1 are alive; client has initiated connection to U1 |
| Inputs: | Specification of cuts |
| Outputs: | Status and, if successful, bulk data in FITS format. If unsuccessful, report (and log?) error condition. |
| Priority: | 1 (essential) |
| Error | Response |
|---|---|
| Invalid input | Parsing error reported to interactive client; operation aborted |
| No connection to U1 | Report error to interactive client; operation aborted |
| U1 or D1 tool hung or very slow | Allow interactive user to abort. Times out operation locally and sends abort message to U1. |
The initial Summary functions something like the fields in the existing use case document for D1. It is meant to give the reader an idea of what the use case is about at a coarse level as quickly as possible: what it is (Goal), what components are involved (Actors) and so forth. Any acronyms or obscure abbreviations used in the document should be written out at least once in full at their first mention.
I've omitted Trigger because I don't think it adds much at this level. Equivalent information can be found in the Walk-through section following. I omitted the References section because I couldn't make sense of it, but in principle it seems like a good idea. If we have such a section it should list fully-identified documents or sections within such documents. Web links should be included if possible. The Successful End and Failed End sections are here absorbed in Outputs.
The Walk-through section is just that. Imagine going through the activity in as great a level of detail as is useful given the current state of development, or a least specification, of the relevant components (actors, interfaces, etc.). It is somewhat analogous to Typical Course of Events. When we're further along with this, with a library of documented use cases, it might make sense for a top-level use case like this one to refer to use cases for other lower-level components, for example step 4 above might refer to a use case for D1.
If the walk-through is done thoughtfully, it will help in composing the last section on error conditions. Perhaps the error conditions in the table should be numbered so that the walk-through can refer to them. The walk-through does not itself discuss error-handling in any detail to avoid interrupting the flow.
Last modified: