Month: November 2018

Requirements Analysis Using Event/Response and Use Cases: Validating the Model

Professor of Project Management Requirements Analysis , ,

Planning

In the prior posts on “Event Discovery”, you completed your initial Event Model. I say “initial” because in the process of validating the model, you may discover additional events.

In order to validate the model, you first compare it to your Project Objectives (the implementation deliverables that survive and are maintained after the project is considered complete). For each Project Objective you need to ensure that you have one or more Events and Business Processes that will contribute to reaching that objective. If you don’t find at least one, you are missing at least one event and must cycle back to event discovery to find it or them.

When you are finished validating against the Project Objectives, you will then validate against the Business Objectives. As a reminder, Business Objectives…

  • Contribute to the business strategy
  • Make or save money
  • Take advantage of opporunity
  • Provide competitive advantage
  • Respond to new laws and regulations
  • Are measurable

Compare the Event Model against the defined Business Objectives and ask the Core Team and the Project Sponsor if this scope will directly or indirectly address the objectives. If one or more objectives are not addressed, then you will continue with event discovery until you are satisfied the Business Objectives are satisfied by the model.

In the next post I will present how Use Cases are derived from the Event Model.

Advertisement

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

Professor of Project Management Requirements Analysis , , ,

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.

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

Professor of Project Management Requirements Analysis , , ,

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.