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.

Advertisements

Requirements Analysis Using Event Response and Use Cases: Event Discovery Part 2

Planning

In the previous post I discussed how to use the Context Diagram for initial Event discovery. In this post I will present how to use the outputs from your Event List to discover more events.

The fifth column in your Event List (the one labeled “Which creates this…”) are the outputs of your business processes. You can use these outputs to discover more Events by asking the following questions for each output:

  • Does the output go to a “Customer”? (an entity outside of the center bubble in the Context Diagram). If yes, then that is where the output ends. If no, then that means it must be input to another event or the output has no purpose. Ask your SME’s (Subject Matter Experts) what other business processes use this data. For each identified business process, you can flesh out the Event List row for that process.
  • What are the “Create” Events for this output? These are the Events that result in the establishment of a new row (or rows) of data in the output in question. For example, the sale of a product creates a Sales Transaction record. Note there may be more than one Event that creates rows in this output.
  • What are the “Change” Events for this output? For this you may need to examine each data element in the output. For each element, ask the SME’s what business processes change this data. Use these answers to continue to build the Event List.
  • What are the “Delete” Events for this output? These are the Events that result in the logical or physical removal of a row in the output. For example, if the record retention requirement for the output is 5 years, then the time-based event “Record Retention Limit Reached” will be added to your Event List.

Now that you have added many more rows to your Event List, you will have more outputs to examine. Cycle back thru the Event List outputs and ask the same questions listed above. You will find your Event List grows very quickly!

In the next post I will continue to present additional techniques for Event Discovery.

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

Planning

In prior posts I introduced the Context Diagram and the Event List. In this and the upcoming series of posts, I will define some techniques you can use to discover events and complete the Event List and Context Diagram.

The very first place to start defining events is the Context Diagram. Every input arrow on the diagram represents an event to which your “business” must respond. Remember, our definition of your “business” is the boundary of the business area under study. Inside of the business bubble on the Context Diagram, you have control over the business processes and data flows. Outside the boundary, you can negotiate the interfaces with the Suppliers and Customers but have little or no control over their business processes.

Let’s examine an example of how the Context Diagram can provide events. For this example, let us say the Supplier is an Employee and the input arrow is “Travel Expense Details”.

Our first column on the Event List is “When this happens”. In this example, you would state “Travel Expense Report Submitted”.

The second and third columns are “This Source” and “Gives us This”. In this example, the Source is “Employee”, and “Gives us This” is “Travel Expense Details”.

The fourth column is “Then we do this”. These are the labels of the business processes your “business” will execute upon receipt of the “Travel Expense Details”. You might have a list of processes that looks like this:

  • Verify expenses comply with business policy
  • Approve/Reject Expenses

The fifth column is “Which creates this”. These are the outputs of each business process. The outputs of the first process listed above might be “Valid Expenses” and “Invalid Expenses”. The outputs of the second process listed above might be “Approved Expenses” and “Rejected Expenses”.

The sixth column is “… and we give it to …”. These are the recipients of the outputs listed in the fifth column. In this case the recipient of the Valid and Invalid Expenses could be “Employee’s Manager”. The recipient of “Rejected Expenses” would be the Employee while the recipient of “Approved Expenses” could be the Travel Expense Data Repository.

Be sure to keep implementation details out of this analysis. You don’t want solutions to be constrained by using specifics such as “email:, “reports”, “database”, etc.

In the next post, I will continue the discussion of Event Discovery and show how, once you have a few events listed, you can use these events to discover more events and get the complete scope of the project.