Overview of Use Cases

A use case consists of an actor and a headline. The actor's name plus the use case title should form an active voice sentence. An actor is always somebody or something outside the system you are developing. The purpose of use cases is to help define the first boundary, the system boundary, of the product you are trying to create.

A use case reads like a headline in a newspaper. It is not meant to provide a detailed specification. Use cases just provide an informal collection of headlines that suggest the system boundary. Actors are always outside that boundary.

A use case describes something of value from the point of view of an actor. Thus, we should never have a use case called "Customer logs in". No customer would ever pay money just for the privilege of supplying a user name and a password. "Customer purchases product", "Customer deposits cash", and "Customer borrows money" are all better use cases. They describe something a customer finds valuable. "Regulator audits compliance" is a similar good example.

It is useful to translate each use case into a collection of analysis classes.