Monthly Archives: October 2014

Use Case, Business Events and Time Events

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:

  1. Story, begin condition. The time indicates that data must be sent to the reporting environment
    1. step1: Collect data in data warehouse.
    2. step2: System sends data to Reporting Environment.
    3. step3: Reporting System stores the data in its own environment.
    4. 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).