I define a class as a template or pattern. I use it to represent a set of objects that share the same structure and behavior. For example, I call “person” a class when I mean any person that appears in the requirements. In other words, a class names a type of thing. Therefore, I write class names in the singular. For example, I use “person” not “persons”.
First, I distinguish objects and classes. I treat objects as instances of a class. For example, Sally Brown is an object. Next, I treat the class person as the template that covers Sally and other people. In addition, I assign a unique identifier to each object. Thus, I can tell two objects apart even when they share many attributes. For instance, I give two cars owned by the same person unique names. As a result, I can clearly reference each car.
I draw a class as a rectangle. Moreover, I place the class name inside the rectangle. Then, I add attributes below the name when needed. For example, I show “dateOfBirth” as an attribute of person. In a UML class diagram, I also show dependencies and relationships. For example, I link person to company when a person represents a company. Therefore, class diagrams document terms, attributes, and links that the requirements mention.
When I model requirements, I identify classes from the nouns in the text. However, I do not turn every noun into a class. For example, I treat age and gender as attributes of a person. In addition, I treat car as a synonym for vehicle. Thus, I reduce duplicate or unnecessary classes. First, I list candidate nouns. Second, I ask whether each noun names an independent thing or a property of another thing. Third, I convert true properties into attributes. For example, I convert color into an attribute of vehicle.
Moreover, I apply heuristics to decide. For example, if a noun appears with a genitive form such as “date of the order”, I treat it as an attribute. In addition, if a noun only describes another noun, I add it as an attribute. On the other hand, if a noun names a domain entity that can exist on its own, I model it as a class. For example, I treat person and vehicle as classes.
I use class names consistently. Therefore, I prefer clear, singular names. I avoid synonyms. For example, I map car to vehicle and man to person. Thus, I keep the model compact and clear. In addition, I check relationships between classes. For example, I show that a company consists of departments and that a person can be a representative for a company.
Finally, I use class diagrams to improve other views. For example, I use the information model to inform functional and technical views. As a result, I discover missing information early. In conclusion, I use classes to structure requirements. Moreover, I use attributes and unique identifiers to make objects precise. Consequently, my requirements models stay clear, complete, and usable in design and testing.