I define an activity model as a visual model of the flow of actions in a part of a system. First, I use it to show how functions and tasks follow each other. Next, I show who does what. For example, I draw actions, decisions, and parallel flows. Moreover, I add swimlanes to show responsibility. Therefore, stakeholders see both flow and ownership.
I often use UML activity diagrams for this purpose. For example, I model system functions with UML activity diagrams. In addition, I can express control flow between actions. Also, I can show triggers and simple data flow. However, if I need explicit data flow, I choose other notations. For example, I use data flow diagrams (DFD) when data transformations matter. Similarly, I use BPMN when I model business or technical processes in detail. In particular, BPMN helps when the audience needs standard business-process elements.
I design activity models to support requirements engineering. First, I capture the required functions. Then, I describe the order of steps. After that, I clarify interactions with users and other systems. Consequently, I reduce ambiguity in requirements. Moreover, I use activity models to find missing requirements. For example, I spot unhandled decisions and parallel activities. Thus, I improve the quality of the requirements specification.
I keep models simple. First, I choose the right diagram type. Next, I limit the scope to relevant activities. Then, I add textual notes where necessary. In addition, I combine diagrams with textual model elements. For example, I add a short description for each action. Also, I document triggers and preconditions. Therefore, readers who do not master the modeling language can still understand the intent.
I pay attention to modeling language rules. First, I follow the syntax of the chosen language. Then, I apply semantics to avoid misinterpretation. Moreover, I consider pragmatics to ensure practical use. If I use UML, I follow UML notation and basics. If I use BPMN, I follow BPMN elements and rules. Consequently, other modelers can read and extend my models.
I know the limits of activity models. First, they show control flow well. However, they do not always show detailed data structures. In that case, I link the activity model to a data model or a DFD. Also, I do not try to model every detail. Instead, I model the essence. Therefore, I keep the model useful.
I follow practical tips. First, I involve stakeholders early. Next, I validate the model with users and developers. Then, I iterate the model until the team agrees. In addition, I version the diagrams with the requirements document. Finally, I use consistent notation across the project.
I base this entry on the provided context and common standards such as UML, BPMN, and DFD. Consequently, I recommend reading the relevant modeling-language documentation when you need more depth. Meanwhile, practice with example diagrams to become fluent.