I define an object as anything that I can perceive or conceive. In requirements engineering, I mean an individual item with identity. Moreover, I mean an item that has attributes. In addition, I mean an item that does not depend on another item. Therefore, I treat an object as an entity the system may use.
First, I distinguish object from class. A class is a template. Then, an object is an instance of that template. For example, I model the class person. Next, I create objects such as Peter Schulz and Sally Brown. In this way, the class shows common properties. Consequently, the objects show specific values for those properties. Also, I name classes in the singular. For example, I write “person” rather than “persons”. This keeps names clear.
Second, I give objects unique identities. Thus, I add a unique identifier. For example, I give a car a unique ID. Moreover, I use attribute combinations to ensure uniqueness. For instance, I might use first name, last name, and date of birth to identify a person. If two persons share a name, then the date of birth makes them distinct. Therefore, I always check that the combination of attribute values differs between objects of the same class.
Third, I model attributes. Attributes hold values such as text, dates, or numbers. For example, an application status attribute may have the value “approved”. However, I avoid treating the class itself as having that value. Instead, I assign the value to an attribute of the class. Thus, I keep semantics consistent.
Fourth, I use relationships and associations. Associations connect two classes or objects. In addition, they carry information such as multiplicity and role. For example, I state that one person may have one residence address and one correspondence address. Also, I may allow an address to relate to several people. Therefore, I add multiplicities to each association end. Consequently, I can navigate the information model. As a result, I derive precise functional requirements. For example, instead of “Show address” I write “Show the correspondence address of the person who is the contact for the company.” This gives context and reduces ambiguity.
Fifth, I handle class-versus-attribute decisions. If I doubt whether a term should be a class or an attribute, then I model it first as a class. Then, I refine the model. Conversely, if the term represents simple, unstructured data, then I model it as an attribute. For example, an address often appears as a class when I need structure and relationships. Meanwhile, a simple status code may remain an attribute.
Moreover, I represent classes visually as rectangles. Then, I add attributes inside the rectangle. Next, I attach associations and multiplicities. Thus, I form clear class diagrams for requirements modeling.
Finally, I remember that business objects exist in the real world. Therefore, the system uses them as input, to persist, and to produce output. As a result, I document objects, their attributes, and their relationships. In short, I treat objects as identifiable, attribute-bearing, independent items that the system must know, handle, and trace. Consequently, my models become precise, navigable, and useful for deriving requirements