In a previous post, I showed the context diagramme. I then continued by saying that each of the arrows that flow to and fro the bubble in the middle can be translated as use cases.
But one may take a slightly different view: each of these arrows are either business events or time events. A business event is then understood as an action from outside the system that invokes a flow of information (=an arrow to/fro the bubble in the context diagramme). Likewise a time event is understood as a time event that invokes an information stream to/fro the bubble.
Hence in a business event or a time event, one explicitly mentions the reason, why the event starts.
Suppose, the time vent is (e.g. a monthly moment ) whereby data are sent to the reporting enevironment.
One has:
- Story, begin condition. The time indicates that data must be sent to the reporting environment
- step1: Collect data in data warehouse.
- step2: System sends data to Reporting Environment.
- step3: Reporting System stores the data in its own environment.
- end condition. Reporting System contains the data for reporting environment.
One sees: it a slightly different approach from a use case. The reason, why the event starts is better indicated.
Why is it important to stress the reason for starting the business event/ time event. Because it shows the boundaries of the system. One is forced to think of what starts a certain flow of information. Is it time that starts a flow of information from the system to the reporting environment. Or is it the availability of data that can be sent to the reporting environment? Or is it a signal of the end user to have the data? Or.. etc..
When this done, one gets a:
- clear list of the actors (a user who requires a report, a system that delivers data etc)
- a clear list of actions that must be covered by the work process (store data, provide reports etc).