In addition to dealing with a wide range of target audiences, the challenges for a Business Analyst include dealing with a wide range of target purposes. Switching your thinking, your headspace, to meet the type of modelling required for a given purpose can be difficult.
One of the biggest jumps is between business process and system requirements modelling because the goals (and often the audience as well) are so different. The two disciplines require different writing styles, and different tools.
Business process modelling is about goals. In the bluntest possible terms, goals are about money. What goals does a business need to achieve to make money. For a government agency this can be read as the things that the agency is funded by the government to do. "Show me the money!" Conversely, system requirements modelling is about testable and buildable details. In the bluntest possible terms, can a coder build it & can a tester prove that it is right.
However, BPM goals can come in many levels from way, way, up in the clouds (think mission statements) down to what individual staff members need to achieve. In my experience the lowest level of business process modelling is typically a task performed by a single business role, in a single sitting. The task should have identifiable value as a contributor to a higher level goal, and be described in those terms. These tasks can be a good way of identifying the system use cases that will hold the system requirements set together.
The risk of this approach is a levelling issue at the boundary. A valid but overly detailed requirement can so very easily be mistaken for a task and make an inappropriate appearance in a BPM as a result.
A good example is a life cycle, such as a UML State Diagram, which can be really useful for tracking a complex object through several use cases. This is particularly relevant if you are using object status as a trigger and/or precondition to a subsequent use case. Depending on the level of detail being included in the flows, some use case steps may even specify the status being set. In summary the status of something can be a critical requirement to understand.
However, barring very unusual circumstances, I wouldn't use a state chart in business modelling, nor would I be likely to need language that hints at it. This is because status is a system artefact created as a result of a task that is of value to the business. In a BPM I would describe the task, the business role responsible for the task, and how the task contributes to a higher level goal of the business.
I would also separately document the probable need for a life cycle, with a rough guess as to content, to give me a head start when it comes time to do the system requirements.