Requirements Analysis Using Event/Response and Use Cases: Event Discovery Part 7

Planning

The posts in this series so far have covered identifying External Events, which in most cases will constitute the majority of your Events. There are two other types of Events you also need to identify:

  • Time-based Events
  • System State Events

To identify Time-based Events you can simply ask your SME’s (Subject Matter Experts) if there are any processes that run based on time (e.g. “every X hours/days/weeks/months”, “First Monday of every month”, “Every other Friday”, etc). Some Events that run based on time are only done so due to technical limitations, either real or perceived. You do not want to classify these Events as time-based. For example, if they say “We run an interface from our HR system to our Time-Keeping system every two hours”, that is a choice, not a requirement. In an ideal world, those two systems would always be instantaneously in sync. Do not let technical limitations limit your requirements.

An example of a good time-based requirement is “We submit monthly tax reports to state and local governments”. The timing is a requirement of External Entities and must be honored.

System-State Events can be identified when you are reviewing the relevant data elements. You can ask if any change in the value of an element automatically triggers a process. For example, in an inventory system a System-State Event might be “When the on-hand quantity reaches 5, a reorder is triggered”. In an HR system, a promotion would trigger events related to pay, benefits, organization, etc.

Once you have added the Time-based Events and the System-State Events to the External Events in your Event Model, it is time to validate the model. That will be the subject of Part 8 in this series.

Advertisements

Requirements Analysis Using Event / Response and Use Case: Event Discovery Part 6

Planning

For those of you that are familiar with Data Modeling, there is a technique you can use involving the Entity Relationships that can help you discover events you may have missed. Entity Relationships are part of the Business Rules and are expressed in terms such as “A Customer may purchase one or more Products” and “A Product may be purchased by zero, one or more Customers“.

Whenever the term “zero” is expressed in an Entity Relationship, that is of special interest to the Business Analyst looking to discover events. In the above example, where a Product does not necessarily have to be purchased, that could lead you to questions such as “Is there an expiration date? If so, what then?”, or “Is there a point which the price is reduced to induce sales?”.

Also in the example above, the Customer-to-Product relationship did not have the “zero” (at least on the first pass at the model). Event Analysis may help you discover zero relationships where one was not initially defined. For example, you could ask the SME’s (Subject Matter Experts) “Can a Customer be someone who has not purchased a product?”. That goes to the very heart of what the organization considers a “Customer”. One answer might be “Well, we allow people to sign up for our mailing list even if they haven’t purchased anything yet”. In this case, that person is a Customer, so the relationship is revised to state “A Customer can purchase zero, one or many Products“.

Once you know the events that define that zero relationship you can ask follow up questions such as “Is creating and maintaining a mailing list in the scope of this project?”. I have found exploring these zero relationships very valuable in real world projects.