Model

I call a model an abstract representation of a part of reality. For example, I represent an existing system. Likewise, I represent a system to be created. Therefore, I focus on the essential aspects. In addition, I leave out irrelevant details. Consequently, I make complexity manageable.

First, I make models for a clear purpose. Second, I set a specific context. Thus, I ensure it fits the stakeholder need. For instance, I use a model to specify requirements. Similarly, I use one to analyze the current situation. Moreover, I use it to explore design options.

I distinguish the original from the model. Namely, I call the modeled part the original. In contrast, the model contains constructs that represent the original. For example, I use classes and associations in a class diagram. Likewise, I use activities and transitions in an activity diagram. Furthermore, I can add textual elements. For instance, I add a use case trigger description.

In a modeling language, I find syntax, semantics, and pragmatics. Therefore, I learn the language rules. Otherwise, I risk misunderstanding a diagram. For example, if I do not master UML, then the model will not clarify the requirements. Thus, I always check that stakeholders understand the language.

Diagrams consist of model elements. Specifically, I include graphical elements and textual supplements. As a result, I form the atomic constituents of a model. Moreover, each diagram uses a specific diagram type. Consequently, the underlying modeling language defines the allowed constructs. For instance, UML defines class and association constructs. In addition, some fields use standardized languages, such as BIM for building models.

I use models in two main ways. First, I use descriptive modeling. In this case, I capture the current reality. Therefore, I document what now exists. Second, I use prescriptive modeling. Here, I describe a future reality. Hence, I indicate what the system should become. If I already have a descriptive model, then I derive a prescriptive one from it. Thus, I transform current state into required state.

Quality matters. For example, I check syntactic quality. Therefore, I follow the language syntax. Otherwise, stakeholders may misread the model. In addition, I check semantic quality. Specifically, I verify that the model matches the intended meaning. Furthermore, I use modeling tools. They help me check syntactic rules. Likewise, they help me maintain consistency across diagrams.

I recognize trade-offs. For example, models simplify reality. Therefore, they lose some detail. However, they help me focus on what matters. Moreover, different models show different views. Consequently, I combine views to get a full picture. In particular, I use context models to define system boundaries. Then, I use goal and business models to describe requirements.

Finally, I choose a model only when it adds value. Otherwise, I keep to concise text. Overall, I use models to communicate, to analyze, and to prescribe. In summary, I treat a model as a purposeful, contextual, and abstract tool that reduces complexity and supports requirements engineering.