I define a requirements activity as a concrete action or a sequence of actions that a person or a group performs to accomplish a task. In short, an activity describes what people do. Therefore, an activity focuses on behavior. Moreover, an activity links to inputs, outputs, and responsibilities. For example, I model an activity as “Perform risk analysis” or “Display transaction list”.
First, I use activity diagrams to show activities. In these diagrams, I place each activity in a swim lane for the role responsible. However, I note that swim lanes usually show only the main responsible role. Consequently, I use a RACI matrix in addition to clarify who is Responsible, Accountable, Consulted, and Informed for each activity. In other words, the activity diagram shows flow and sequence. Meanwhile, the RACI matrix shows responsibility details.
Second, I use activity diagrams to document dependencies. For example, I show that risk analysis follows business process analysis. In addition, I can show parallel work. Thus, I make explicit which activities run in sequence and which run concurrently. Moreover, I can annotate activities with input and output objects. For example, I connect “Calculate Route” to a route input and a route output. Therefore, I link data flows to activity flows when I model information structure alongside behavior.
Third, I combine activity diagrams with Gantt charts when I need timing and duration. For example, I use a Gantt chart to show calendar weeks, start and end dates, and repeated work. In contrast, the activity diagram shows less detail about time. Nevertheless, the activity diagram clarifies dependencies more clearly in many cases. As a result, I often use both views together.
Furthermore, I handle signals and interruptions explicitly. For example, I model interruptible activity regions to indicate when a user action or a system event can stop the current action. Likewise, I model timer events for periodic functions such as heartbeats. Thus, I show that the system sends a sign of life every second and that a timer event triggers the loop. In addition, I specify the trigger types, such as “User action” or “System event”, to avoid ambiguity.
I specify activities further with refined diagrams or textual specifications. For example, I state exactly how and in which sequence transactions appear on a screen. Moreover, I list the user options for selecting another person. Therefore, I reduce ambiguity and support implementation and testing. In short, I turn a high-level activity into clear, testable steps.
Finally, I plan elicitation and other project activities defensively. First, I consider stakeholder availability. Second, I assess the availability of skilled Requirements Engineers. Third, I rank activities by value to the project. For example, I prioritize activities that resolve important conflicts or deliver high-value requirements. Consequently, I avoid wasted effort and adapt the schedule when new information arises.
In summary, I treat a requirements activity as a unit of work with actors, inputs, outputs, time, and dependencies. Moreover, I document activities with diagrams, responsibility matrices, and schedules. Therefore, I ensure clarity, traceability, and better coordination across the project.