I define an entity as anything that I can perceive or conceive. For example, I can call a person, a document, or a product an entity. In entity-relationship modeling, I mean an individual item that has its own identity. In addition, I mean that the item does not depend on another item for its identity. Thus, I treat an entity as a stable type with attributes and relationships.
I give entities attributes. For example, I assign a name, an ID, and other properties. I use attributes to describe the entity at a type level. Furthermore, I link entities with associations. For example, I connect a person with a company or with an identity card. Therefore, I can navigate the information model by following associations. Moreover, I name associations or use role names to avoid ambiguity when multiple links exist between two classes.
I pay close attention to multiplicities. For example, I read 0..* in several ways. First, I may interpret 0..* to mean that a person has many identity cards over time. Second, I may interpret 0 as meaning that the person does not need an identity card or has lost it. Third, I may interpret 0 as a temporary state. In that case, I create the person first and then the card later. Consequently, the person exists for a time without a card. Thus, multiplicities can lead to different understandings. Therefore, I discuss multiplicities with stakeholders. Otherwise, I risk incorrect requirements.
I note that an information model shows a static and consistent structure. However, I do not intend the model to resolve intermediate states. For example, I do not represent the exact moment when a person gets a new identity card. Instead, I model temporal aspects separately. For instance, I model versioning, history, and dynamics when I need to represent time. In addition, I can model a simple history by adding an entity like IdentityCardHistory or by timestamp attributes. Thus, I clarify whether multiplicities cover historical versions or only the current state.
I can specify exact constraints with a formal language. For example, I use OCL when I need precision. Specifically, I express a rule such as: if an order has a purchaser then that purchaser must have a delivery address. In practice, I keep such constraints simple for stakeholders. However, I use OCL when precision matters for implementation or validation.
I use generalization and specialization to simplify models. For example, I group common properties of several classes under a parent entity. Then, I link specialized entities to the parent with a generalization relationship. Consequently, I reduce duplication and increase clarity. Meanwhile, I keep names clear and short. Likewise, I choose role names when I write requirements so that readers understand the relationships.
When I work as a requirements engineer, I use entities to verify details. For example, I ask: Is the multiplicity correct? If the multiplicity is correct, then I ask: What should happen if I assign one related entity? Conversely, what should happen if I assign several related entities? For instance, if a person relates to several legal entities, then I decide how to select one for display. For example, I choose the one with the youngest or the oldest incorporation date. Therefore, I document selection rules.
Overall, I treat an entity as a fundamental building block. First, I define identity and attributes. Second, I define associations and multiplicities. Third, I clarify temporal needs such as history and versioning. Finally, I add constraints and rules to make the model usable for requirements and implementation.