I use a modeling language to express models of a certain kind. In requirements engineering, I rely on modeling languages to make complex ideas clear. First, a modeling language gives me a set of constructs. Second, it gives me a syntax. Third, it gives me semantics and pragmatics. Therefore, I can build diagrams that people understand. For example, I pick UML when I need class or sequence diagrams. Moreover, I pick BPMN when I model business processes. In addition, I use SysML for system architecture views. Also, I may use EPC, ERM, or Petri nets depending on the problem.
A modeling language may use graphical symbols, text, or both. For instance, class diagrams use rectangles and lines. Meanwhile, textual model elements let me add details. As a result, I combine diagrams and short text to reduce ambiguity. I also use templates for consistent descriptions. For example, I add a use case trigger as a textual element. Thus, I keep each diagram focused on one view. Consequently, I make the models easier to read and to maintain.
I separate modeling languages from natural languages. Natural languages, such as English or German, serve daily communication. However, natural language can introduce ambiguity. Therefore, I use modeling languages to increase precision. Still, I also recognize formal languages. Formal languages focus on contradiction-free descriptions. In particular, I use formal notation or logic when I need unambiguous rules. For example, I may add OCL constraints to UML models. Hence, I combine modeling languages with formal elements when required.
I pay attention to diagram types. Each diagram type maps to a modeling language. For example, a class diagram belongs to UML. Thus, the modeling language defines which constructs I may use. For example, UML defines class and association. In contrast, BPMN defines tasks, events, and gateways. Consequently, I pick the right modeling language for the intended diagram type.
I manage views carefully. First, I select the system view I need. Second, I choose the appropriate diagram type. Third, I use the modeling constructs that fit the view. Furthermore, I keep the level of detail consistent. Otherwise, the model becomes hard to maintain. Therefore, I define early which requirement types I persist. In addition, I document solution dependencies and detail levels. This approach helps me with requirements management.
I use standardized modeling languages when possible. For instance, I choose UML or BPMN when teams need a widely known notation. Moreover, standardization improves communication across teams. Also, it helps tool support and automation. Specifically, standardized languages often come with defined syntax, semantics, and toolchains. Therefore, I gain consistency and repeatability.
I write models with clarity. First, I prefer short elements. Second, I avoid unnecessary complexity. Third, I add explanations only where needed. In particular, I supplement diagrams with short textual descriptions. As a result, I make the model easier to translate. Finally, I review models with stakeholders. Consequently, I reduce misunderstandings and improve the requirements documentation.
« Back to Glossary Index