(see 1.4.2 of Object-Oriented Software Development Using Java)
"The system is an online, web-based bookstore. The bookstore sells books, music CDs, and software. Typically, a customer first logs on to the system, entering a customer ID and password. The customer can then browse for titles or search by keyword. The customer puts some of the titles into a "shopping cart" which keeps track of the desired titles. When the customer is done shopping, he/she confirms the order, shipping address, and billing address. The bookstore system then issues a shipping order, bills the customer, and issues an electronic receipt. At the end of the transaction, the customer logs off."
A scenario is a very specific sequence of actions and responses that detail how the system will interact with a user. It is useful for pinpointing vague or missing requirements, and for verifying that the system does what's expected. A complete system would have several top-level scenarios, each showing a typical interaction with the system.
In a real world system, the scenarios are the basis for the detailed requirements. You can walk clients through scenarios and see if the system behavior is what's desired. Typically scenarios change and expand over time.
This helps answer very high-level questions: What is part of the system, and what is not? What people interact with the system? What external systems will our system interact with?
(I drew the Warehouse Systema nd Billing System with square heads to remind me that they're not actual people, they're just external systems.)
Look for important nouns: Objects, people, organizations, places, events, concepts. Give them memorable names. Reflect real world objects where that is useful, and create new ones as needed to help support the scenarios.
OnLineBookstore, Customer, Book, MusicCD, Software, ...
Analyze the requirements to find the attributes of each class.
A Customer has a name, customerID, password, shippingAddress, and billingAddress.
An Address has a street, city, state, country, and postalCode.
etc.
Note that some attributes may be references to other objects.
Analyze the requirements to find relationships between classes. Draw relationships as lines between class boxes. Annotate the relationships: How many OrderItems for each Order are possible? Use symbols to indicate the kind of relationship: Generic, aggregation (has-a or owns-a), inheritance (is-a). For generic relationships, use an arrowhead to indicate whether the relationship is navigable: Does the source object know about the destination object?
After identifying candidate classes, see if there are any commonalities between them that might be an IS-A relationship. It may make sense to factor the common parts into a superclass, and create an inheritance relationship:
Draw the entire system on one page (hide details about classes if you run out of room, and display them on subsequent pages). Be sure to include all important relationships, especially where one class depends on another.
Now go back and check the system against the scenarios; are all the scenarios supported by the system? Is all data owned by some class? Is it clear which class will be responsible for which actions?