This Use Case Fundamentals mini-document was sent by someone who had read the Alistair Cockburn article "Structuring Use Cases with Goals", and wrote a digest of it for his group. It provides the following information.

• A section on the Use Case methodology used along with a description of the terms used.

• A detailed description of the Use Case Reports generated during the Use Case analysis of the proposed system.

• A brief description of how to validate these Use Cases.

(No graphics - you can save and print locally)

Four Roads to Use Case Discovery - There Is a Use (and a Case) for Each One by Gary A. Ham, Battelle Memorial Institute. Some graphics, print from:

A collection of Qs&As on clarifying "Structuring Use Cases with Goals" Contain hyperlinks. Access from:

PARTS: Precision, Accuracy, Relevance, Tolerance, Scale in Object Design. This document provides a good discussion about how to develop levels of detail as you move through your understanding of the use case.

(No graphics - you can save and print locally)

MS Word 97 Document contributed by Doug Mann. A highly detailed scenario describing an Emergency Room Results Retrieval.

Basic Use Case Template, MS Word document by Alistair Cockburn. a basic template for use cases matching the document "Structuring Use Cases with Goals" (usecases.htm). Provides annotation in the fields to describe how the template is filled out.

Microsoft Word template file (.dot) to provide blank template explained in uctempla.doc

Chapter 3, Use Cases, from "UML Distilled" by Martin fowler

Figures are .gif files. Print copy from:

Structuring Use Cases with Goals by Alistair Cockburn - good descriptive material for creating use cases. The author has personally encountered over 18 different definitions of use case, given by different, each expert, teachers and consultants. They differed along 4 dimensions: purpose, contents, plurality, and structure. His introduction to this paper addresses the fundamental problem that the Terminology and Content groups have been facing for use case construction.

Figures are .gif files. Print copy from:

Use cases are wonderful but confusing. People, when asked to write them, do not know what to include or how to structure them. There is no published theory for them. This paper introduces a theory based on a small model of communication, distinguishing "goals" as a key element of use cases. The result is an easily used, scaleable, recursive model that provides benefits outside requirements gathering: goals and goal failures can be explicitly discussed and tracked; the goals structure is useful for project management, project tracking, staffing, and business process reengineering. The model and techniques described here have been applied and evaluated on a relatively large (50 work-year, 200 use-case) project.