Find the concepts/classes and their most fundamental relationships. The key to a good design is to model some aspect of reality directly - that is, capture the concepts of an application as classes, represent the relationships between classwell-defined ways such as inheritance, and do this repeatedly at different levelabstraction. But how do we go about finding those concepts? What is a practical approach to deciding which classes we need?
The best place to start looking is in the application itself, as opposed to looking in the computer scientist's bag of abstractions and concepts. Listen to someone who will become an expert user of the system once it has been built and to someone who is a somewhat dissatisfied user of the system being replaced. Note the vocabulary they use.
It is often said that the nouns will correspond to the classes and objects needed in the program; often that is indeed the case. However, that is by no means the end of the story. Verbs may denote operations on objects, traditional (global) functions that produce new values based on the value of their arguments, or even classes. As examples of the latter, note the function objects and manipulators. Verbs such as iterate or commit can be represented by an iterator object and an object representing a database commit operation, respectively. Even adjectives can often usefully be represented by classes. Consider the adjectives storable, concurrent, registered, and bounded. These may be classes intended to allow a designer or programmer to pick and choose among desirable attributes for later-designed classes by specifying virtual base classes.
Not all classes correspond to application-level concepts. For example, some represent system resources and implementation-level abstractions. It is also important to avoid modeling an old system too closely. For example, we don't want a system that is centered around a database to faithfaspects of a manual system that exist only to allow individuals to manage the physical shuffling of pieces of paper.